1. HTTP로 제어할 수 있는 것
HTTP는 원래 단순히 문서 주고받는 프로토콜이었는데, 지금은 다양한 기능을 헤더나 쿠키 등을 통해 제어할 수 있게 확장되었다.
캐시 혹은 인증 메서드는 HTTP초기부터 발전해온기능이며
origin 제약사항을 완화시키는 조치가 2010년에 들어옴.
1. 캐시
서버: “이 문서는 1시간 동안 저장해둬”라고 지시 가능.
클라이언트: “저장된 거 말고 최신 걸 가져와”라고 요청 가능.
(문서를 저장시키고 처리 및 사용 가능하게끔 확장된 기능)
2. Origin 제약 완화 (CORS 관련)
기본: 브라우저는 보안을 위해 **같은 출처(origin)**에서 온 페이지만 접근 허용.
하지만 필요할 때 서버가 헤더(Access-Control-Allow-Origin)를 줘서 다른 출처 데이터도 사용 가능하게 해줌.
3. 인증
“이 페이지는 로그인한 사람만 볼 수 있어.”
방법: HTTP 헤더(WWW-Authenticate)나 쿠키 기반 세션으로 제어.
4. 프록시와 터널링
네트워크 장벽을 넘을 때 프록시 서버를 거침.
HTTP 요청을 다른 주소로 전달하거나, HTTPS 통신을 프록시를 통해 터널링할 수 있음.
+ 프록시란? = 서버와 클라이언트 사이 중간자 역할을 하는 서버임.
클라이언트 - 프록시 - 서버 로 가운데 프록시가 통신을 양방향 전달하며 통신함
+ 터널링이란? = 한 통신 "채널"을 통해 다른 프로토콜 트래픽을 안전하게 통과시키는것
비밀통로 ( 암호화 된 터널 ) 을 만들어 숨겨 전달하는 식
+터널링 예시(어떻게 쓰이는가)
HTTPS CONNECT: 브라우저가 프록시에 CONNECT host:443 요청을 보내면 프록시는 대상 서버와 TCP 연결을 만들고 클라이언트와 서버 사이에 암호화된 터널을 생성. 즉 프록시는 TLS를 풀어보지 못하고 단순히 바이트를 중계함(기본 동작).
5. 세션
원래 HTTP는 요청/응답만 하고 “상태 없음”
+ 상태가 없다? = HTTP의 기본동작은 요청 1번 => 응답1번하고 끝임.
이 요청이 누가보낸건지, 전에 어떤 요청을 보냈었는지 기억하지 않음.
이러한걸 "상태 없다" 라고 표현함
상태가 없으면 로그인을 한 상태인지? 어떤 페이지에서 넘어가는지? 등등 기술적으로 문제가 되는 경우들이 있음.
그래서 나온게 세션+쿠키 임.
쿠키: 브라우저가 작은 데이터를 저장하고, 매 요청마다 서버에 보내줌.
세션: 서버가 사용자별 상태를 따로 기록해두고, 쿠키에 세션ID를 넣어 이어줌.
→ 이렇게 하면 서버가 “이 요청은 아까 로그인한 A 사용자”라고 구분 가능.
2. HTTP 흐름
클라이언트가 서버와 통신하고자 할 때, 최종 서버가 됐든 중간 프록시가 됐든 다음 단계의 과정을 수행한다.
1. TCP 연결을 연다 (이때 전에 배운 3핸드 셰이크 과정이 자동으로 일어남)
TCP는 요청을 보내거나 응답을 받을때 사용된다.
클라이언트는 TCP로 새연결을 열거나, 전의 연결을 재사용하거나, 서버에 여러개의 TCP연결을 열 수 있다.
2. TCP연결 후 HTTP 메시지를 전송한다.
HTTP/2 이전은 인간이 읽을 수 있지만 HTTP/2에선 이런 간단한 메시지도 프레임속 캡슐화되어 읽을 순 없지만 원칙은 동일하다.
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
3. 서버가 응답을하며 이 응답을 클라이언트가 받아들여온다.
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
4. 연결을 닫거나 다른 응답들을 위해 재사용한다.
++ HTTP 파이프라이닝이란?
HTTP/1.1에서 추가된 기능으로, 쉽게 말해 "응답을 기다리지 않고 여러 요청을 한 번에 보내는 방식" 이다.
기본동작으로 파이프라이닝이 없는경우엔 아래와 같다.
- 클라이언트가 요청 A를 보냄 → 서버 응답 A를 기다림.
- 응답 A가 오면, 그제서야 요청 B를 보냄 → 응답 B 기다림.
👉 즉, 요청과 응답이 순차적으로만 진행됨.
다만 파이프라이닝의 한계와 문제점으로
서버나 프록시에서 이 기능을 제대로 지원하지 않을시 역효과로 성능이 더 나빠졌고
일부 오래된 프록시, 게이트웨이가 이 기능을 제대로 지원하지 못했음.
그래서 거의 제한적으로 사용하거나 기능을 사용하지 않았는데
요즘 등장한 HTTP/2에서 멀티플렉싱 이란 더 좋은 기능이 생겨나면서 이 기능을 대체하여 사용중임.
그래서 HTTP 파이프라이닝은 사실상 사장되고, 현재는 거의 쓰이지 않음.
3. HTTP 메시지
Method : 응답 메시지의 형태로는 GET이나 POST등과 같은 동사나 OPTIONS나 HEAD와 같은 명사이다.
Path : 가져오는 리소스의 경로.
Protocol version : 프로토콜의 버전
일반적으로, 클라이언트는 리소스를 가져오거나(GET을 사용하여) HTML 폼의 데이터를 전송(POST를 사용하여)하려고 하지만,
다른 경우에는 다른 동작이 요구될 수도 있다.
( 요즘 버그바운티 하면서 봐왔던 PATCH 와 같은 동사들!!!!! 직접 많이 접해보지 못한 메서드를 다지려고 이글을 작성한 이유)
https://ilsancityboy.tistory.com/106
HTTP 메서드
1.OPTIONS 메서드https://developer.mozilla.org/ko/docs/Web/HTTP/Reference/Methods/OPTIONS OPTIONS - HTTP | MDNOPTIONS /index.html HTTP/1.1 OPTIONS * HTTP/1.1 서버가 지원하는 요청 방법을 찾으려면 아래와 같이 curl 명령어을 사용
ilsancityboy.tistory.com
4. HTTP 기반 API
- 웹 브라우저(클라이언트)와 서버가 HTTP 프로토콜을 이용해서 데이터를 주고받는 방식의 API.
- 자바스크립트에서 서버와 데이터를 교환할 때 많이 쓰여.
무슨소리인가? => 자바스크립트 코드가 XHR이나 fetch() 같은 함수를 통해 서버랑 HTTP 통신을 쉽게 하도록 브라우저가 제공하는 도구
API란? = Appliction Programming Interface 의 약자로써 한 프로그램에서 다른 프로그램으로 데이터를 주고받기 위한 방법
쉽게 생각해보자. 자바스크립트 란건 한페이지 내에서 볼륨소리 조절하거나 마우스 올리면 애니메이션이나 이벤트가 등장하는 등, 서버와 통신없이도 이벤트를 실행할수 있잖아?
그리고 HTTP 프로토콜을 사용할땐 언제야? => 서버와 클라이언트가 통신하고 요청/응답이 오고갈때 사용된다
그럼 HTTP기반 API 라는걸로 자바스크립트, HTTP 두개의 프로그램으로 데이터를 주고받기 위한 방법을 사용해서
자바스크립트처럼 한페이지 내에서 새로고침등 없이 돌아가되 서버랑 요청/응답이 오고가게끔 할 수 있는것이다.
예를들자면 사용자 프로필 수정 페이지 => 수정 페이지 내의 사용자 전화번호 변경하는 곳만 입력후 수정 => 새로고침없이 서버와 통신이 되며 해당 필드만 수정이 완료됨.
그럼이때 API라는건? html페이지를 받아 통째로 렌더링해서 돌려받아 새로고침되는방식을 쓰지않고
그대로 부드럽게 페이지내에서 상호작용하기위해 "데이터"만을 돌려받아 다른프로그램들이 가공하여 화면내에 뿌려지는것.
이러기위해서 HTTP방식 API가 사용됨.
그냥 HTTP 동작 (웹 초기 방식)
사용자가 /login URL을 열면 서버가 HTML 페이지를 통째로 돌려줌.
브라우저는 그 HTML을 렌더링해서 화면을 보여줌.
여기서는 “사람이 읽는 페이지”를 주고받는 게 목적.
2. HTTP 기반 API (현대 방식)
같은 /users/123 URL이라도, 브라우저나 앱이 요청을 보내면 **HTML이 아니라 JSON/XML 등 “데이터”**를 돌려줌.
이 데이터는 사람이 직접 보는 용도가 아니라, 다른 프로그램(클라이언트)이 가공해서 화면에 뿌리도록 하는 것.
즉, **"사람 눈 대신 프로그램이 이해할 수 있게 설계된 HTTP 엔드포인트"**가 API.
3. 관계 정리
/login, /users/123 같은 URL로 요청하는 건 원래 HTTP의 기본 방식임 ✅
그런데 그 응답을 페이지(HTML)가 아니라 데이터(JSON 등)로 주도록 규칙을 만든 것 → 이게 HTTP 기반 API
AJAX나 fetch() 같은 기술은 → 그 API를 호출해서 데이터만 받아서 화면 일부를 업데이트하는 용도로 사용됨.
이러한 예시를 들때말한 새로고침없이 호출하는 기술의 명은 AJAX이다.
AJAX를 구현하는 방법으론 XHR과 fetch() 등등이 있다. (요즘엔 XHR보단 fetch()를 사용하는 추세)
POST방식 (예전부터 사용된 주된 방식) 으로 회원정보 수정할때의 상황
(회원정보가 수정되었다며 페이지가 새로고침되거나 코드상의 정해진 주소로 이동되게끔됨.)
AJAX방식으로 회원정보 수정할때의 상황
페이지 새로고침없이 자바스크립트가 실행된거마냥 페이지 내에서의 상호작용이 이루어지며 서버와의 통신도 되어 정보가 수정됨.
자료참고 : https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/Overview?utm_source=chatgpt.com
HTTP 개요 - HTTP | MDN
HTTP는 클라이언트-서버 프로토콜입니다. 요청은 하나의 개체, 사용자 에이전트(또는 그것을 대신하는 프록시)에 의해 전송됩니다. 대부분의 경우, 사용자 에이전트는 브라우저지만, 무엇이든 될
developer.mozilla.org
'과제' 카테고리의 다른 글
| HTTP 메서드 (0) | 2025.09.22 |
|---|---|
| 추가 공부 계획 (0) | 2025.09.21 |
| 그누보드 대상 주요정보통신기반 웹 취약점 항목 진단 (5) | 2024.12.07 |
| ffuf 설치 및 사용 (0) | 2024.11.15 |
| 정보보안기사 준비 (필기 2022 버전) (0) | 2024.11.09 |