HTTP 패킷 구조, 요청 헤더/바디

브라우저가 서버로 요청을 보낼 때는 HTTP 요청 메시지(패킷) 형태로 전송됩니다. 이를 네트워크 계층 기준으로 뜯어보면 다음과 같이 구성됩니다.

---

1. 패킷 구조 (네트워크 계층 관점)

• L2 (데이터링크 계층): Ethernet 헤더 (MAC 주소, CRC 등)
• L3 (네트워크 계층): IP 헤더 (출발지 IP, 목적지 IP 등)
• L4 (전송 계층): TCP 헤더 (출발지 포트, 목적지 포트, 순번, ACK 등)
• L7 (애플리케이션 계층): HTTP 메시지 (실제 요청)

우리가 보통 "HTTP 요청 패킷"이라 말할 때는 L7 HTTP 메시지를 의미합니다.

---

2. HTTP 요청 메시지 구성

HTTP 요청은 크게 Request Line, Headers, Body 세 부분으로 나눌 수 있습니다.

 

(1) Request Line

GET /index.html HTTP/1.1

• GET: 메서드 (동작)
• /index.html: 요청 URI
• HTTP/1.1: 프로토콜 버전

(2) Headers (메타데이터)

Host: www.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept: text/html,application/xhtml+xml
Accept-Language: ko-KR,ko;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: session_id=abc123

• Host: 요청 대상 서버의 도메인
• User-Agent: 브라우저/OS 정보
• Accept: 클라이언트가 처리 가능한 콘텐츠 타입
• Accept-Language: 선호하는 언어
• Cookie: 로그인/세션 정보
• Connection: keep-alive 여부

(3) Body (선택적)

• GET 요청은 보통 Body 없음
• POST/PUT 요청에서는 데이터 포함:

POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

username=seoyeon&password=1234

---

3. 예시: 실제 HTTP 요청 패킷 (Wireshark 캡처 느낌)

Frame 52: 548 bytes on wire
Ethernet II, Src: 00:1a:2b:xx:yy:zz, Dst: 11:22:33:44:55:66
Internet Protocol Version 4, Src: 192.168.0.10, Dst: 93.184.216.34
Transmission Control Protocol, Src Port: 52345, Dst Port: 80
Hypertext Transfer Protocol
    GET /index.html HTTP/1.1\r\n
    Host: example.com\r\n
    User-Agent: Mozilla/5.0 ...\r\n
    Accept: text/html\r\n
    \r\n

 

• 패킷의 최상단은 HTTP 요청 메시지이며, 브라우저가 어떤 리소스를 요청하고, 어떤 환경에서 요청하는지에 대한 정보(Headers)와 필요 시 Body(데이터)를 담습니다.
• 네트워크 도구(Wireshark, Chrome 개발자 도구 → Network 탭)로 직접 캡처해서 분석할 수 있습니다.

---

🧩 HTTP 헤더의 주요 분류

https://developer.mozilla.org/ko/docs/Glossary/HTTP_header

 

MDN Web Docs 에 따르면 HTTP 헤더는 크게 네 가지 그룹으로 나눌 수 있습니다.

 

• Request Header → 클라이언트가 원하는 조건/환경 전달
• Response Header → 서버와 응답 자체에 대한 메타데이터 제공
• Representation Header → 메시지 본문(리소스)의 특성 설명
• Fetch Metadata Request Header → 요청 컨텍스트/보안 관련 정보

 

 

---

1. Request Header (요청 헤더)

클라이언트(브라우저)가 서버에 요청을 보낼 때 자신의 환경이나 원하는 리소스 조건을 설명하는 헤더입니다.

예시

• Host: 요청 대상 서버 도메인 (예: Host: www.example.com)
• User-Agent: 클라이언트 정보 (브라우저, OS)
• Accept: 클라이언트가 처리 가능한 MIME 타입 (예: text/html, application/json)
• Accept-Language: 선호 언어 (예: ko-KR, en-US;q=0.8)
• Authorization: 인증 토큰 (예: Bearer <token>)
• Cookie: 클라이언트 세션 쿠키

👉 목적: 서버가 클라이언트를 이해할 수 있게 해줌

---

2. Response Header (응답 헤더)

서버가 응답할 때, 서버나 응답 자체에 대한 메타데이터를 담습니다. (본문의 내용 자체가 아니라 부가 정보)

예시

• Server: 서버 소프트웨어 정보 (예: nginx/1.20.0)
• Location: 리소스가 이동된 주소 (리다이렉트)
• Set-Cookie: 클라이언트에 쿠키 저장 요청
• WWW-Authenticate: 인증 방법 지정 (예: Basic, Bearer)

👉 목적: 클라이언트가 서버 응답을 해석할 수 있도록 도움

---

3. Representation Header (표현 헤더, 엔티티 헤더라고도 부름)

메시지 본문(body)의 콘텐츠 자체에 대한 메타데이터입니다. 본문이 없으면 이 헤더들도 거의 없음.

예시

• Content-Type: 본문의 MIME 타입 (예: text/html; charset=UTF-8)
• Content-Length: 본문 길이 (바이트 단위)
• Content-Encoding: 압축 방식 (예: gzip, br)
• Content-Language: 본문의 언어
• Content-Range: 전체 중 어느 범위인지 (부분 응답)

👉 목적: 본문 데이터의 구조와 특성을 설명

---

4. Fetch Metadata Request Header (보안 관련 메타데이터 헤더)

최근에 도입된 헤더로, 브라우저가 요청의 맥락(context)을 서버에 알려줍니다. 보안 정책(CORS, CSRF 방지 등)에서 활용됩니다.

예시

• Sec-Fetch-Site: 요청이 같은 사이트인지, 크로스 사이트인지 (same-origin, cross-site)
• Sec-Fetch-Mode: 요청 모드 (navigate, cors, no-cors)
• Sec-Fetch-User: 사용자가 명시적으로 트리거한 요청인지 (?1)
• Sec-Fetch-Dest: 리소스 목적 (document, image, script)

👉 목적: 서버가 요청의 출처와 목적을 분석하여 보안 결정을 내릴 수 있게 함