HTTP 헤더 구조편집자 확인

HTTP 헤더 필드는 "필드 이름: 필드 값"의 기본 형식을 따른다. 필드 이름은 대소문자를 구분하지 않는 토큰으로 구성되며, 필드 값은 필드 이름 뒤에 콜론(':')과 공백(옵션)을 두고 기술한다. 필드 값은 필드의 종류에 따라 다양한 구문을 가질 수 있다. 예를 들어, Content-Type 헤더의 값은 'text/html; charset=UTF-8'과 같이 미디어 타입과 매개변수로 구성된다.

헤더 필드는 여러 줄에 걸쳐 작성될 수 있으며, 이때 연속되는 줄은 공백(스페이스 또는 탭)으로 시작해야 한다. 이를 '줄 접기'라고 한다. 그러나 현대의 HTTP/2와 HTTP/3에서는 이진 프레임을 사용하여 헤더를 전송하므로, 텍스트 기반의 줄 접기 방식은 더 이상 사용되지 않는다.

하나의 HTTP 메시지에는 동일한 이름의 헤더 필드가 여러 개 존재할 수 있다. 이 경우, 그 의미는 헤더 필드에 따라 다르게 해석된다. 예를 들어, 여러 개의 Set-Cookie 헤더는 각각 별도의 쿠키를 설정하지만, X-Forwarded-For 헤더처럼 쉼표로 연결된 값들을 하나의 헤더로 합쳐서 보내는 것이 일반적이다.

HTTP 메시지에서 헤더 필드와 본문을 구분하는 데 사용되는 기호는 빈 줄(Empty Line)이다. 정확히는 캐리지 리턴과 라인 피드로 구성된 CRLF(Carriage Return Line Feed) 시퀀스가 두 번 연속으로 등장하는 부분, 즉 \r\n\r\n이 구분자 역할을 한다.

이 빈 줄은 HTTP 메시지의 구조에서 필수적인 요소이다. 요청이나 응답 메시지는 시작 줄(Start-Line), 헤더(Header), 본문(Body)의 세 부분으로 구성되며, 헤더의 끝을 알리고 본문의 시작을 표시하는 것이 바로 이 구분 기호이다. 만약 메시지에 본문이 존재하지 않더라도, 헤더의 끝을 명시적으로 나타내기 위해 빈 줄은 반드시 존재해야 한다. 이 규칙은 HTTP/1.1 명세(RFC 7230)에 정의되어 있다.

구분 기호의 처리 방식은 다음과 같다.

프로그래밍적으로, 클라이언트나 서버는 네트워크 스트림에서 데이터를 읽으면서 \r\n\r\n 시퀀스를 찾아 헤더 파싱을 중단하고 본문 처리를 시작한다. 이 구분 기호를 올바르게 처리하지 못하면 메시지를 잘못 해석하여 프로토콜 오류가 발생할 수 있다.

일반 헤더는 HTTP 요청과 HTTP 응답 메시지 모두에서 사용될 수 있는 헤더 필드이다. 이 헤더들은 메시지의 전송 자체와 관련된 정보를 제공하며, 특정 요청이나 응답의 콘텐츠와는 직접적인 연관이 없다. 일반 헤더의 주요 역할은 메시지의 날짜, 연결 관리, 캐싱 지시 등의 통신 매개변수를 제어하는 것이다.

주요 일반 헤더 필드로는 다음과 같은 것들이 있다.

일반 헤더는 클라이언트와 서버 간의 통신 흐름을 관리하는 데 필수적이다. 예를 들어, Cache-Control 헤더는 중간 프록시나 브라우저 캐시가 응답을 저장하고 재사용하는 방식을 결정하며, Connection 헤더는 TCP 연결을 유지할지 닫을지 제어하여 네트워크 효율성에 영향을 미친다. 이러한 헤더들은 애플리케이션 데이터를 운반하는 메시지의 '운송 수단'에 대한 메타데이터를 제공한다고 볼 수 있다.

요청 헤더는 클라이언트가 서버에게 요청을 보낼 때 사용하는 헤더 필드이다. 이 헤더들은 요청의 컨텍스트를 정의하고, 클라이언트의 능력, 선호도, 요청 대상에 대한 추가 정보를 서버에 제공하는 역할을 한다. 주로 HTTP 메서드와 함께 사용되며, 서버가 요청을 적절히 처리하고 최적의 응답을 생성할 수 있도록 돕는다.

요청 헤더는 크게 몇 가지 범주로 나눌 수 있다. 첫째, 요청 자체에 대한 정보를 제공하는 헤더들이다. 대표적으로 User-Agent는 요청을 보내는 클라이언트 소프트웨어(브라우저, 운영체제 등)의 식별 정보를 담는다. Accept 헤더는 클라이언트가 이해할 수 있는 콘텐츠 유형(MIME 타입)을, Accept-Language는 선호 언어를, Accept-Encoding은 선호 압축 방식을 서버에 알려준다. 이를 통해 서버는 콘텐츠 협상을 수행하여 가장 적합한 형식의 응답을 반환할 수 있다.

둘째, 요청의 조건을 지정하거나 캐싱 동작을 제어하는 헤더들이 있다. If-Modified-Since나 If-None-Match와 같은 조건부 요청 헤더는 서버 리소스의 특정 버전(수정 시간이나 ETag 값)을 기준으로 요청을 제한한다. 이는 불필요한 데이터 전송을 줄이고 캐시 효율성을 높이는 데 기여한다. Cache-Control 헤더의 no-cache나 max-age 같은 지시어를 요청에 포함시켜 클라이언트 측 캐시의 동작을 명시적으로 제어할 수도 있다.

셋째, 요청 대상에 대한 정보를 제공하는 헤더도 포함된다. Host 헤더는 요청이 전송되는 호스트와 포트 번호를 지정하며, 하나의 IP 주소에서 여러 도메인이 호스팅되는 가상 호스팅 환경에서 필수적이다. Referer 헤더는 현재 요청을 유발한 이전 웹 페이지의 주소를 나타낸다. Authorization 헤더는 서버의 보호된 리소스에 접근하기 위한 자격 증명(예: 베어러 토큰)을 포함한다.

응답 헤더는 서버가 클라이언트에게 요청에 대한 결과를 전달할 때 사용하는 헤더이다. 이 헤더들은 요청의 처리 상태, 서버 정보, 응답 본문에 대한 메타데이터 등을 포함하여 클라이언트가 응답을 올바르게 해석하고 처리할 수 있도록 돕는다.

주요 응답 헤더로는 상태 코드를 나타내는 Status Code와 상태 메시지를 포함하는 Server, 응답 생성 시간을 알려주는 Date, 응답 본문의 MIME 타입을 지정하는 Content-Type, 본문의 길이를 바이트 단위로 알려주는 Content-Length 등이 있다. 또한, 클라이언트가 특정 리소스를 캐시할 수 있는 기간을 지정하는 Cache-Control과 Expires 헤더, 리소스가 이동된 경우 새로운 위치를 알려주는 Location 헤더, 인증이 필요한 리소스에 접근 시 필요한 인증 방식을 알리는 WWW-Authenticate 헤더도 중요한 응답 헤더에 속한다.

다음은 몇 가지 대표적인 응답 헤더의 예시와 용도를 정리한 표이다.

이러한 응답 헤더들은 클라이언트와 서버 간의 효율적인 통신을 보장하고, 캐싱, 세션 관리, 콘텐츠 협상 등 다양한 부가 기능을 구현하는 데 필수적인 역할을 한다.

엔터티 헤더는 HTTP 메시지의 본문, 즉 엔터티 바디에 포함된 리소스 자체에 대한 메타데이터를 설명한다. 이 헤더들은 요청과 응답 메시지 모두에서 사용될 수 있으며, 전송되는 데이터의 특성, 형식, 크기, 수정 시간 등을 나타낸다. 엔터티 헤더는 리소스의 표현(Representation)에 관한 정보를 제공하여, 클라이언트가 콘텐츠를 어떻게 해석하고 처리해야 하는지 결정하는 데 도움을 준다.

주요 엔터티 헤더 필드로는 Content-Type, Content-Length, Content-Encoding, Content-Language, Last-Modified 등이 있다. Content-Type 헤더는 엔터티 바디의 미디어 타입(예: text/html, application/json)을 명시한다. Content-Length는 바디의 크기를 바이트 단위로 나타내어 메시지의 끝을 판단하는 데 사용된다. Content-Encoding은 적용된 압축 방식(예: gzip, deflate)을, Content-Language는 콘텐츠가 대상으로 하는 자연어를 나타낸다. Last-Modified는 서버에서 해당 리소스가 마지막으로 수정된 날짜와 시간을 제공한다.

이러한 헤더들은 캐싱 메커니즘과 밀접한 관련이 있다. 예를 들어, Last-Modified 헤더는 클라이언트가 이후 요청 시 If-Modified-Since 조건부 요청 헤더를 통해 캐시 유효성을 재확인하는 데 사용된다. 마찬가지로, Content-Type에 지정된 문자 인코딩 정보는 브라우저가 페이지를 올바르게 렌더링하는 데 필수적이다. 엔터티 헤더는 HTTP/1.1 명세에서 정의되었으나, HTTP/2와 HTTP/3에서도 그 의미와 기능은 유지되며, 메시지 프레이밍 방식만 변화했다.

콘텐츠 타입 헤더는 전송되는 데이터의 미디어 유형을 지정한다. 예를 들어, text/html; charset=UTF-8은 HTML 문서이며 문자 인코딩이 UTF-8임을 나타낸다. 이 헤더는 클라이언트가 데이터를 올바르게 해석하고 렌더링하는 데 필수적이다.

콘텐츠 길이 헤더는 메시지 본문의 크기를 바이트 단위로 명시한다. 이는 특히 POST 요청이나 응답에서 연결 종료 시점을 판단하는 데 사용된다. 콘텐츠 인코딩 헤더는 본문 데이터가 gzip이나 deflate와 같은 방식으로 압축되었음을 알린다.

콘텐츠 언어 헤더는 문서가 어떤 언어로 되어 있는지를 나타내며, 다국어 지원 사이트에서 중요하다. 콘텐츠 위치 헤더는 요청에 대한 응답으로 반환된 리소스의 실제 위치가 요청된 URL과 다를 때 사용된다[4].

캐싱 관련 헤더는 웹 캐시의 동작을 제어하여 네트워크 대역폭을 절약하고 서버 부하를 줄이며 사용자 경험을 향상시키는 역할을 한다. 이 헤더들은 리소스의 신선도(Freshness)와 유효성(Validation)을 관리하는 규칙을 클라이언트와 서버 간에 전달한다. 주요 목표는 불필요한 데이터 전송을 방지하고, 캐시에 저장된 리소스의 최신성을 보장하는 것이다.

캐싱 정책을 정의하는 핵심 헤더는 다음과 같다.

캐싱 흐름은 조건부 요청(Conditional Request)을 통해 이루어진다. 클라이언트가 캐시에 저장된 리소스를 재사용하려 할 때, Cache-Control: max-age=0이 설정되었거나 캐시가 신선하지 않다고 판단하면, 서버에 유효성 재검증 요청을 보낸다. 이때 캐시된 리소스의 ETag 값을 If-None-Match 헤더에 담거나, Last-Modified 값을 If-Modified-Since 헤더에 담아 요청한다. 서버는 이 값을 검사하여 리소스가 변경되지 않았다면 본문 없이 304 Not Modified 상태 코드로 응답하고, 변경되었다면 새로운 리소스와 함께 200 OK로 응답한다.

Cache-Control의 공용 캐시(Public Cache)와 사적 캐시(Private Cache) 제어도 중요하다. public 지시자는 응답이 어떤 캐시에도 저장될 수 있음을 의미하며, private 지시자는 응답이 특정 사용자(예: 브라우저 캐시)만을 위한 것이므로 공유 캐시(예: 프록시 서버)에 저장되어서는 안 됨을 나타낸다. 또한 no-cache는 캐시 저장은 허용하지만, 사용 전 반드시 서버에 재검증을 요구해야 함을 의미하며, no-store는 어떠한 형태로도 캐시에 저장하는 것을 완전히 금지한다.

인증 관련 헤더는 클라이언트의 신원을 확인하고 접근 권한을 부여하는 데 사용된다. 대표적인 헤더로는 Authorization과 WWW-Authenticate가 있다. 클라이언트가 보호된 자원을 요청할 때 서버는 401 Unauthorized 응답과 함께 WWW-Authenticate 헤더를 보내어 필요한 인증 방식을 알린다. 이후 클라이언트는 자격 증명(예: 사용자명과 비밀번호)을 Authorization 헤더에 담아 다시 요청한다. OAuth나 JWT를 사용하는 경우에도 이 헤더 필드를 통해 Bearer Token 등을 전송한다.

보안 강화를 위한 헤더는 다양한 공격을 방어하고 정보 보안을 개선하는 역할을 한다. Strict-Transport-Security(HSTS) 헤더는 브라우저가 해당 사이트에 향후 모든 접속을 HTTPS로 강제하도록 지시한다. Content-Security-Policy(CSP) 헤더는 크로스 사이트 스크립팅(XSS) 공격을 완화하기 위해 스크립트, 이미지 등 리소스의 로드 출처를 제한하는 정책을 정의한다.

쿠키 기반 세션 관리와 관련된 보안 헤더도 중요하다. Set-Cookie 헤더에 Secure, HttpOnly, SameSite 속성을 설정하면 쿠키의 안전성을 높일 수 있다. 또한 X-Frame-Options 헤더는 페이지가 <frame>, <iframe>, <embed>, <object> 내에서 렌더링되는 것을 방지하여 클릭재킹 공격을 차단한다.

연결 관리 헤더는 HTTP 세션의 연결 상태와 지속성을 제어하는 데 사용된다. 특히 HTTP/1.1에서 도입된 지속 연결(Persistent Connection)의 효율적인 관리를 위해 중요한 역할을 한다. 주요 목적은 클라이언트와 서버 간의 TCP 연결을 재사용할지 여부를 협상하고, 연결을 정상적으로 종료하는 방법을 지정하는 것이다.

가장 대표적인 연결 관리 헤더는 Connection과 Keep-Alive이다. Connection 헤더는 현재 연결에 대한 제어 옵션을 지정한다. 값이 "close"이면 현재 요청-응답 트랜잭션 후 연결을 종료해야 함을 의미한다. 반면 "keep-alive"는 연결을 유지하겠다는 의사를 나타내지만, HTTP/1.1에서는 지속 연결이 기본값이므로 명시적 사용이 줄었다. 또한 이 헤더는 프록시를 통해 전달되지 말아야 할 헤더(예: Keep-Alive)를 지정하는 데에도 사용된다[5].

Keep-Alive 헤더는 지속 연결의 매개변수를 설정한다. 이 헤더는 연결이 유지될 최대 시간(timeout)과 해당 연결에서 허용될 최대 추가 요청 수(max)를 지정할 수 있다. 예를 들어, Keep-Alive: timeout=5, max=1000은 연결이 5초간 유휴 상태를 유지할 수 있고, 최대 1000개의 추가 요청을 처리할 수 있음을 의미한다. 이 헤더는 HTTP/1.0에서 지속 연결을 활성화하기 위해 필요했지만, HTTP/1.1부터는 기본 동작이므로 주로 매개변수 조정용으로 사용된다.

Upgrade 헤더는 프로토콜 전환을 요청하는 데 사용된다. 예를 들어, HTTP/1.1 연결을 HTTP/2나 WebSocket으로 업그레이드할 때 이 헤더를 활용한다. 서버가 101 Switching Protocols 응답을 보내면 협상된 프로토콜로 전환이 이루어진다. Transfer-Encoding과 TE 헤더도 연결 관리와 관련이 깊다. Transfer-Encoding은 메시지 본문의 전송 인코딩 방식을 지정하며(예: chunked), TE 헤더는 클라이언트가 응답에서 받아들일 수 있는 전송 인코딩 확장을 서버에 알린다.

HPACK은 HTTP/2 프로토콜에서 HTTP 헤더를 효율적으로 압축하기 위해 설계된 이진 형식의 압축 방법이다. 이전 HTTP/1.x에서는 헤더가 반복적으로 전송되어도 텍스트 형식 그대로 전송되었지만, HPACK은 헤더 필드의 크기를 줄여 대역폭을 절약하고 지연 시간을 감소시킨다. HPACK의 설계 목표는 보안 취약점을 방지하는 것이었는데, 이는 CRIME과 같은 공격이 TLS 레벨의 압축을 악용하는 것을 차단하기 위함이었다[6].

HPACK의 동작 방식은 크게 정적 테이블, 동적 테이블, 허프만 코딩의 세 가지 요소로 구성된다. 정적 테이블은 자주 사용되는 61개의 공통 헤더 필드와 값(예: :method: GET, :scheme: https)을 미리 정의해 놓은 것이다. 동적 테이블은 통신 중에 새롭게 등장하는 헤더 필드와 값을 인덱싱하여 추가하며, 최근 사용된 순서로 관리되어 캐시처럼 동작한다. 허프만 코딩은 문자열 리터럴을 효율적으로 이진 인코딩하는 데 사용된다.

인코더는 헤더 목록을 처리할 때, 정적 테이블이나 동적 테이블에 완전히 일치하는 항목이 있으면 해당 인덱스만 전송한다. 값이 일부 다른 경우 '인덱스된 헤더 필드'로, 완전히 새로운 헤더는 '리터럴 헤더 필드'로 인코딩한다. 수신측 디코더는 동일한 테이블 상태를 유지하며 전송된 인덱스나 리터럴을 원래 헤더 목록으로 복원한다. 이 방식은 중복된 헤더의 전송을 극적으로 줄여, 특히 웹 페이지 로드 시 여러 동일한 헤더를 반복적으로 보내야 하는 상황에서 성능 향상 효과가 크다.

QPACK은 HTTP/3 프로토콜에서 HTTP 헤더를 압축하기 위해 설계된 효율적인 압축 형식이다. HTTP/2에서 사용되던 HPACK 압축 방식은 단일 TCP 연결을 전제로 하여 헤더 블록이 순서대로 도착한다고 가정한다. 그러나 HTTP/3의 기반이 되는 QUIC 프로토콜은 다중 스트림을 사용하고 패킷 손실 시 특정 스트림만 영향을 받기 때문에, 헤더 블록의 전송 순서가 보장되지 않는다. QPACK은 이러한 비순차적 전송 환경에서도 안정적으로 헤더 압축을 수행할 수 있도록 HPACK을 확장 및 수정한 것이다.

QPACK의 핵심 메커니즘은 동적 테이블 관리와 명시적 피드백을 통한 동기화에 있다. 인코더(일반적으로 서버)와 디코더(일반적으로 클라이언트)는 각각 독립적인 동적 테이블을 유지한다. 인코더는 헤더를 압축하여 스트림을 통해 보낼 때, 해당 헤더가 자신의 동적 테이블의 어떤 인덱스를 참조하는지 함께 알린다. 디코더는 패킷 손실로 인해 자신의 동적 테이블이 인코더의 테이블 상태와 달라질 수 있으므로, 특정 테이블 항목의 수신 및 처리 완료 여부를 별도의 제어 스트림을 통해 인코더에게 피드백한다. 이를 통해 인코더는 디코더가 안전하게 디코딩할 수 있는 테이블 인덱스 범위를 파악하고, 그에 맞춰 압축 방식을 조정한다.

이러한 설계는 복잡성을 증가시키지만, HTTP/3의 핵심 장점인 독립적인 스트림 처리와 멀티플렉싱을 해치지 않으면서 헤더 압축의 이점을 유지할 수 있게 한다. 결과적으로 QPACK은 HPACK과 유사한 높은 압축률을 제공하면서도, QUIC의 패킷 손실 회복성과 낮은 지연 시간 특성에 잘 부합한다. 표준은 필수 명령어 세트와 선택적 명령어 세트를 정의하여 구현의 유연성을 보장한다[7].

CSP(Content Security Policy)는 XSS(Cross-Site Scripting), 데이터 주입 공격 등 특정 유형의 웹 기반 공격을 탐지하고 완화하기 위해 설계된 컴퓨터 보안 표준이다. 웹 개발자는 CSP를 사용하여 브라우저가 페이지에 대해 유효한 실행 가능한 스크립트의 출처를 제어할 수 있다. 이 정책은 Content-Security-Policy HTTP 헤더를 통해 서버에서 클라이언트로 전달된다.

CSP는 허용 목록 방식으로 작동한다. 정책은 하나 이상의 지시문(directive)으로 구성되며, 각 지시문은 특정 리소스 유형에 대해 허용된 출처를 정의한다. 주요 지시문으로는 default-src, script-src, style-src, img-src, connect-src, font-src, object-src, media-src, frame-src 등이 있다. 예를 들어, Content-Security-Policy: script-src 'self' https://trusted.cdn.com과 같은 헤더는 스크립트를 현재 페이지의 출처('self')와 https://trusted.cdn.com 도메인에서만 로드하도록 허용한다. 정책을 위반하는 리소스는 브라우저에 의해 차단된다.

정책은 보고(reporting)와 시행(enforcement)을 위해 별도 또는 함께 사용될 수 있다. Content-Security-Policy 헤더를 사용하면 정책이 시행되며 위반 사항이 발생하면 리소스가 차단된다. 반면, Content-Security-Policy-Report-Only 헤더를 사용하면 정책은 시행되지 않고 위반 사항만 지정된 report-uri 또는 report-to 지시문으로 정의된 엔드포인트에 보고된다[8]. CSP는 또한 'nonce-{값}'이나 'sha256-{해시값}'과 같은 인라인 스크립트나 스타일을 허용하기 위한 메커니즘을 제공하여 보안을 유지하면서도 필요한 인라인 코드의 실행을 가능하게 한다.

HSTS(HTTP Strict Transport Security)는 웹사이트가 HTTPS를 통해서만 접근되어야 함을 브라우저에 알리는 보안 메커니즘이다. 이 정책은 HTTP 응답 헤더인 Strict-Transport-Security를 통해 전달된다. HSTS가 활성화되면, 브라우저는 해당 사이트에 대한 모든 연결을 자동으로 암호화된 HTTPS로 업그레이드하며, 유효 기간 동안은 안전하지 않은 HTTP 연결을 시도하지 않는다.

HSTS 헤더의 주요 지시어(directive)는 다음과 같다.

이 메커니즘은 중간자 공격(MITM)이나 프로토콜 다운그레이드 공격을 방지하는 데 핵심적인 역할을 한다. 사용자가 http://example.com을 입력하거나 안전하지 않은 링크를 클릭하더라도, 브라우저는 내부적으로 https://example.com으로 요청을 변경한다. 또한, 브라우저는 유효한 인증서 검증을 우회하는 사용자 경고를 표시하지 않도록 한다[10].

HSTS를 구현하려면 웹 서버(예: Apache, Nginx)의 설정 파일에 Strict-Transport-Security 헤더를 추가해야 한다. 사이트를 브라우저의 HSTS 사전 로드 목록에 제출하려면, 공식 HSTS Preload List 사이트를 통해 등록 절차를 완료해야 하며, 이는 모든 주요 브라우저에 정책이 영구적으로 적용되는 효과를 가져온다.