HTTP 헤더 - 개요 및 자주 사용되는 헤더

HTTP 헤더란?

HTTP 헤더는 HTTP 메시지 구조 중 하나로, 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해주는 필드입니다. 헤더는 대소문자를 구분하지 않는 이름과 콜론(':'), 그리고 값으로 구성됩니다.

header-field = field-name ":" OWS field-value OWS  //OWS: 띄어쓰기 허용

 

HTTP 헤더는 아래와 같은 구조를 가집니다. 각 헤더는 별도의 라인에 위치하며, 헤더의 끝은 빈 라인으로 표시됩니다.

이러한 헤더는 개발자 도구(F12)에서 Network에 Headers에서 확인할 수 있습니다.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

 

HTTP 헤더 분류

HTTP 헤더 표준은 인터넷 기술의 공식 문서인 RFC(Request for Comments)를 통해 지속적으로 발전하고 있습니다.  다음은 HTTP 헤더 표준의 시대별 흐름에 대해 나타내고 있습니다. 이번 글에서는 RFC 7230-7235를 기준으로 자주 사용되는 헤더를 정리해 보겠습니다.

 

1. RFC 2616 (1999 ~ 2014)

• HTTP/1.1의 최초 표준화 문서
• 헤더를 4가지로 구분: General, Request, Response, Entity
• 웹의 기본 구조를 확립한 중요한 이정표

2. RFC 7230-7235 (2014 ~ 2022)

• HTTP/1.1의 현대화 및 명확화
• 보안 강화 및 웹 환경 변화 반영
• 헤더를 4가지로 명확히 구분: Representation, Request, Response, Payload
• 헤더의 용도별 구분이 뚜렷함
• RFC 2616에 있는 Entity 헤더를 Representation(표현) 헤더로 수정
  • 표현: 요청이나 응답에서 전송할 실제 데이터
  • 표현 데이터: 메시지 바디(=페이로드)에 담겨 전송
  • 표현 헤더: 표현 데이터를 해석할 수 있는 정보

3. RFC 9110-9111 (2022 ~ 현재)

• HTTP의 최신 표준
• HTTP/2, HTTP/3 통합으로 프로토콜 간 일관성 확보
• 현대 웹 아키텍처 고려한 업데이트
• 최신 보안 요구사항 반영(Zero Trust, HTTPS 기본값 등)
• RFC 7230-7235와 차이점
  • 엄격한 분류에서 유연한 구조로 전환
  • 다중 프로토콜 지원을 위한 설계
  • 필드의 재사용성 강화

---

자주 사용되는 HTTP 헤더 (RFC 7230-7235)

RFC 7230-7235에서는 HTTP 헤더를 표현 헤더 (Representation Header), 요청 헤더 (Request Header), 응답 헤더 (Response Header), 페이로드 헤더 (Payload Header) 4가지로 분류합니다. 이러한 헤더들을 자주 사용하는 역할과 방식에 따라 나눠서 설명하고자 합니다.

표현 헤더 (Representation Header)

표현 헤더(Representation Header)는 위에서 설명한 표현 데이터를 설명하는 헤더입니다: 표현 헤더는 전송, 응답 모두 사용할 수 있습니다.

• Content-Type
  • 표현 데이터 형식
  • 응답 본문의 미디어 타입이나 문자 인코딩 지정
  • 예시) Content-Type: application/json; charset=utf-8
• Content-Encoding
  • 표현 데이터 압축 방식
  • 전송 측에서 데이터 압축 및 Content-Encoding 헤더 추가
  • -> 수신 측에서 Content-Encoding 헤더 정보를 통해 압축 해제
  • 예시) Content-Encoding: gzip
• Content-Language
  • 표현 데이터 사용 언어(자연 언어)
  • 서버가 응답하는 컨텐츠의 실제 언어를 표시
  • 예시) Content-Language: ko
• Content-Length
  • 데이터(페이로드) 길이
  • Content-Length vs Transfer-Encoding
    • Transfer-Encoding:청크 단위로 데이터를 전송하는 방식 -> 전체 데이터 크기를 미리 알 수 없음
    • Content-Length: 전체 데이터 크기를 명시(바이트 단위) (예시) Content-Length: 10) 

---

협상(Content Negotiation) 헤더

협상 헤더는 요청 헤더 (Request Header)의 한 종류입니다. 협상 헤더는 클라이언트가 선호하는 표현을 서버 요청하여 클라이언트와 서버가 최적의 리소스를 결정하는 데 사용됩니다. 따라서 협상 헤더는 요청 시에만 사용됩니다.

• Accept
  
  • 클라이언트가 선호하는 미디어 타입
  • 예시) Accept: text/html,application/xhtml+xml,*/*;q=0.9
• Accept-Charset
  
  • 클라이언트가 선호하는 문자 인코딩
  • 예시) Accept-Charset: utf-8;q=1.0,iso-8859-1;q=0.7
• Accept-Encoding
  
  • 클라이언트가 선호하는 압축 방식
  • 예시) Accept-Encoding: gzip,deflate;q=0.8
• Accept-Language
  
  • 클라이언트가 선호하는 자연 언어
  • 예시) 다중 언어를 지원하는 웹사이트에서 클라이언트가 보낸 Accept-Language 헤더를 확인하여 적절한 언어로 콘텐츠를 제공
  • 예시) Accept-Language: ko-KR,ko;q=0.9,en;q=0.8

 

Quality Values (q값): 우선순위

• 0~1 사이의 우선순위
• q=1 (기본값(생략 가능), 가장 높은 선호도)
• q=0 (해당 타입 수용 거부)

협상 헤더의 표현 예시를 보면 ko-KR,ko;q=0.9,en;q=0.8 과 같이 Quality Values(q값)을 사용한 걸 볼 수 있다. 우선순위는  Quality Values(q값)을 위와 같이 사용한다. 따라서 위에 예시를 보면 1위)ko-KR, 2위) ko, 3위) en 로 우선순위를 나눌 수 있다.

 

 

---

전송 방식 헤더 분류

전송 방식 헤더는 "데이터를 어떻게 전송할 것인가"에 초점을 맞춘 분류입니다. 전송 방식은 크게 단순 전송, 압축 전송, 분할 전송, 범위 전송으로 나눌 수 있습니다.

 

• 단순 전송: Content-Length 표현 헤더 사용
  
  • 데이터 크기를 미리 알 수 있을 때 사용
  • 장점: 구현 단순, 진행률 표시 가능
  • 단점: 전송 전 전체 데이터 준비 필요, 메모리 부담
  • 예시) Content-Length: 3423
• 압축 전송: Content-Encoding 표현 헤더 사용
  
  • gzip, deflate 등으로 압축
  • 장점: 전송 데이터 크기 감소, 대역폭 절약
  • 단점: 압축/해제 시 CPU 자원 사용
  • 예시) Content-Encoding: gzip
• 분할 전송: Transfer-Encoding: chunked 페이로드 헤더 사용
  
  • 데이터를 분할하여 순차적 전송
  • 전체 크기를 모를 때 유용
  • 장점: 메모리 효율적, 스트리밍 가능
  • 단점: 전체 크기 예측 불가, 청크 오버헤드

Transfer-Encoding: chunked

5\r\n
Hello\r\n
5\r\n
World\r\n
0\r\n\r\n   <- \r\n: HTTP에서 줄바꿈

• 범위 전송: Range, Content-Range 페이로드 헤더 사용
  
  • 특정 범위만 부분 전송
  • 장점: 다운로드 재시작 가능, 대용량 처리 용이
  • 단점: 서버/클라이언트 모두 지원 필요
  • Range 예시) Range: bytes=1001-2000
  • Content-Range 예시) Content-Range: bytes 1001-2000/67589

---

일반 정보 / 특별 정보 헤더

• 일반 정보 헤더: 통신의 부가적인 정보를 전달하는 헤더
• 특별 정보 헤더: HTTP 통신의 핵심 기능을 담당하는 헤더, 특정 상황에서 필수적으로 사용

일반 정보 헤더는 요청 헤더 (Request Headers)인 From, Referer, User-Agent와 응답 헤더 (Response Headers)인 Server, Date 헤더 등이 있습니다. 

• From
  • 요청을 보내는 사용자의 이메일 주소를 포함
  • 현재는 거의 사용되지 않음 (개인정보 보호 문제)
  • 주로 검색 엔진 봇에서 사용
  • 예시) From: webmaster@example.com
• Referer
  • 현재 요청된 페이지의 이전 웹 페이지 주소를 포함
  • 트래픽 분석이나 데이터 분석(유입 경로 등)에 활용
  • 예시) Referer: https://www.google.com/search?q=example
• User-Agent
  • 클라이언트 애플리케이션 정보(브라우저 종류와 버전, 운영체제 정보, 디바이스 정보 등)
  • 브라우저별 최적화, 장애 분석 등에 활용
  • 예시) User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
• Server
  
  • Origin 서버의 소프트웨어 정보를 포함
  • 보안상 최소한의 정보만 노출 권장
  • 예시) Server: nginx/1.18.0
• Date
  • 메시지 생성 시간
  • HTTP 응답에만 사용
  • GMT/UTC 시간으로 표시
  • 예시) Date: Wed, 21 Oct 2024 07:28:00 GMT

특별 정보 헤더는 요청 헤더 (Request Header)인 Host와 응답 헤더 (Response Header)인 Location, Allow, Retry-After 등이 있습니다.

• Host
  • 필수 헤더 (HTTP/1.1부터)
  • 가상 호스팅의 핵심 기능
    • 가상 호스팅: 하나의 물리적 서버에서 여러 웹사이트를 호스팅 하는 것 (현대의 웹 서버에서 일반적)
    • 문제점: 하나의 서버 IP에서 가상 호스팅을 할 경우 클라이언트의 요청이 어떤 웹사이트로 가야 하는지 모름
  • 이러한 문제를 해결하기 위해 Host 헤더로 클라이언트 요청의 라우팅을 결정

같은 IP(203.0.113.1)인 하나의 서버에 아래와 같은 3개의 웹사이트가 존재할 경우
- blog.example.com
- shop.example.com 
- mail.example.com

Host 헤더로 어떤 웹사이트로 라우팅할지 명시
GET /index.html HTTP/1.1
Host: blog.example.com

• Location
  • 300번대 응답에서 필수
  • 클라이언트의 다음 요청 위치를 지정
  • 자동 페이지 리다이렉션 유발
    • 리다이렉션: 클라이언트를 다른 URL로 보내는 메커니즘 (예시: 로그인 후 특정 페이지로 이동)
• Allow
  • 405 (Method Not Allowed) 응답에서 필수
  • 서버가 지원하는 HTTP 메서드를 명시
  • 리소스에 대한 가능한 작업 정의
• Retry-After
  • 503 (Service Unavailable) 응답에서 중요
  • 서버의 가용성 제어
  • 클라이언트 요청 타이밍 제어

---

마치며

이번 글에서는 HTTP 헤더의 개요와 분류 및 자주 사용되는 헤더를 역할 및 방식에 따라 정리해 보았습니다. 다음 글에서는 인증, 쿠키, 캐시에서 자주 사용되는 HTTP 헤더를 정리해 보겠습니다.

---

[참고자료]

강의: 모든 개발자를 위한 HTTP 웹 기본 지식