[HTTP] HTTP 헤더1 - 일반 헤더(1)

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

HTTP 헤더 개요

HTTP 헤더는 클라이언트와 서버가 HTTP 메시지를 주고받을 때 다양한 메타데이터를 포함하는 영역이다. HTTP 메시지는 헤더 필드와 메시지 본문으로 구성되며, 헤더 필드는 여러 용도로 사용된다.

 

HTTP 헤더 기본 구조

• header-field = field-name ":" OWS field-value OWS
  (OWS: 띄어쓰기 허용)
• field-name은 대소문자를 구분하지 않는다.

HTTP 헤더의 용도

HTTP 헤더는 다음과 같은 정보를 포함할 수 있다.

• 메시지 바디의 내용 유형(Content-Type)
• 메시지 바디의 크기(Content-Length)
• 압축 관련 정보(Content-Encoding)
• 인증 정보(Authentication)
• 요청 클라이언트 정보(User-Agent)
• 서버 정보(Server)
• 캐시 관리 정보(Cache-Control)
• 추가적으로 필요한 경우, 사용자 정의 헤더를 추가할 수 있다.
  예: helloworld: hihi

HTTP 헤더 분류

과거 RFC2616 기준에 따른 HTTP 헤더 분류

 

• General 헤더: 메시지 전체에 적용되는 정보
  • 예: Connection: close
• Request 헤더: 클라이언트의 요청 정보
  • 예: User-Agent: Mozilla/5.0 (Macintosh; ...)
• Response 헤더: 서버의 응답 정보
  • 예: Server: Apache
• Entity 헤더: 엔티티(본문) 정보
  • 예: Content-Type: text/html, Content-Length: 3423

 

HTTP BODY

HTTP 메시지 본문은 엔티티 본문을 전달하기 위해 사용된다. 엔티티 본문은 실제 데이터를 포함하며, 엔티티 헤더는 이를 해석할 수 있는 정보를 제공한다.

 

• 데이터 유형: html, json
• 데이터 길이: Content-Length
• 압축 정보: Content-Encoding

 

HTTP 표준의 변화 (RFC2616 → RFC7230)

1999년 발행된 RFC2616은 폐기되고, 2014년 새로운 표준인 RFC7230~7235가 등장했다. 이 과정에서 주요한 용어가 변경되었다.

 

RFC723x의 변화

• 엔티티(Entity) → 표현(Representation)
  표현이란, 표현 메타데이터와 표현 데이터로 구성된다.
  • Representation = Representation Metadata + Representation Data

HTTP BODY - 최신 RFC7230 기준

HTTP 메시지 본문은 표현 데이터를 전달하며, 이 메시지 본문을 페이로드(payload)라고도 부른다. 표현 헤더는 이러한 표현 데이터를 해석할 수 있는 정보를 제공하며, 예를 들어 데이터 유형(html, json), 데이터 길이, 압축 정보 등이 포함된다.

참고: 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분할 필요가 있지만, 여기서는 생략한다.

 

표현 헤더

HTTP 표현 헤더는 서버나 클라이언트가 메시지 본문에 대한 구체적인 정보를 전달하는 데 사용된다. 이를 통해 메시지 본문을 올바르게 해석하고 처리할 수 있다. 주요한 표현 헤더에는 Content-Type, Content-Encoding, Content-Language, Content-Length가 포함된다.

 

1. Content-Type

Content-Type 헤더는 메시지 본문의 미디어 타입과 문자 인코딩을 명시한다.

• 미디어 타입: 메시지 본문의 데이터 형식 (HTML, JSON, 이미지 등).
• 문자 인코딩: 문자의 인코딩 방식 (UTF-8, ISO-8859-1 등).

예시

• Content-Type: text/html; charset=utf-8
• Content-Type: application/json
• Content-Type: image/png

2. Content-Encoding

Content-Encoding 헤더는 메시지 본문을 압축하는 데 사용된 인코딩 방식을 나타낸다.

• 이 헤더는 데이터를 전송하는 쪽에서 압축 후 추가되며, 데이터를 수신한 쪽에서 해당 압축 방식을 기반으로 데이터를 해제한다.

예시

• Content-Encoding: gzip (데이터가 gzip으로 압축됨)
• Content-Encoding: deflate
• Content-Encoding: identity (압축이 없음)

3. Content-Language

Content-Language 헤더는 메시지 본문이 어떤 자연 언어로 작성되었는지 설명한다.

• 이 헤더를 통해 클라이언트는 어떤 언어로 된 데이터를 수신했는지 파악할 수 있다.

예시

• Content-Language: ko (한국어)
• Content-Language: en (영어)
• Content-Language: en-US (미국 영어)

4. Content-Length

Content-Length 헤더는 메시지 본문의 길이를 바이트 단위로 나타낸다.

• 이 값은 메시지 본문을 얼마나 읽어야 하는지 클라이언트나 서버에게 알려준다.
• 주의: 만약 Transfer-Encoding 헤더를 사용하는 경우 Content-Length 헤더는 사용할 수 없다.

예시

• Content-Length: 3423 (메시지 본문의 길이가 3423 바이트)
• Content-Length: 5 (메시지 본문의 길이가 5 바이트)

5. 표현 헤더의 역할

• Content-Type: 데이터의 형식
• Content-Encoding: 데이터의 압축 방식
• Content-Language: 데이터의 언어
• Content-Length: 데이터의 크기

이러한 헤더들은 HTTP 응답과 요청 모두에 사용되어 데이터를 올바르게 전송하고 처리할 수 있게 한다.

 

콘텐츠 협상

콘텐츠 협상은 클라이언트가 선호하는 데이터 형식과 서버가 제공할 수 있는 데이터 형식 간의 조정을 의미한다. HTTP 요청 시 클라이언트는 다양한 헤더를 통해 서버에 선호하는 미디어 타입, 인코딩, 언어 등을 전달할 수 있으며, 서버는 이를 참고해 가장 적합한 형식으로 응답을 반환한다.

 

콘텐츠 협상에 사용되는 주요 헤더

1. Accept: 클라이언트가 선호하는 미디어 타입 (예: text/html, application/json)
2. Accept-Charset: 클라이언트가 선호하는 문자 인코딩 (예: UTF-8, ISO-8859-1)
3. Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 방식 (예: gzip, deflate)
4. Accept-Language: 클라이언트가 선호하는 자연 언어 (예: ko, en-US)

* 협상 헤더는 HTTP 요청 시에만 사용된다.

 

Accept-Language 적용 전

클라이언트가 한국어 브라우저를 사용하고 있지만, 서버는 기본적으로 영어를 제공한다. 클라이언트는 별도의 언어를 명시하지 않기 때문에 서버는 기본 언어로 응답한다.

 

Accept-Language 적용 후

클라이언트가 요청 시 Accept-Language: ko 헤더를 명시하면, 서버는 한국어 응답을 제공한다.

 

Accept-Language 복잡한 예시

클라이언트가 여러 언어를 요청하는 경우, 서버는 가장 우선순위가 높은 언어로 응답한다.
예를 들어, Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7와 같은 헤더가 있으면 서버는 ko-KR 또는 ko로 응답하고, 그 다음으로는 en-US, 마지막으로는 en을 고려한다.

협상과 우선순위1

Quality Values(q)는 클라이언트가 선호하는 콘텐츠에 대한 우선순위를 나타내는 값으로, 0에서 1까지의 값으로 표현된다. 값이 클수록 우선순위가 높다. 클라이언트는 각 언어에 대해 q 값을 설정하여 우선순위를 부여할 수 있다.

 

Accept-Language 복잡한 예시

 

• ko-KR (q 값 생략, 1로 간주)
• ko (q=0.9)
• en-US (q=0.8)
• en (q=0.7)

이 경우 서버는 가장 높은 우선순위인 ko-KR을 우선으로 응답하고, 해당 언어가 없을 경우 순차적으로 우선순위가 낮은 언어로 응답한다.

 

협상과 우선순위2

일반적으로 구체적인 설정이 우선한다. 즉, 보다 명확하게 정의된 미디어 타입이 우선순위가 높다.

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

위의 경우, 구체적으로 정의된 text/plain;format=flowed가 가장 높은 우선순위를 가지며, 그 뒤를 text/plain이 따른다. 마지막으로 text/*와 모든 타입을 허용하는 \*/\*가 가장 낮은 우선순위에 놓인다.

협상과 우선순위3

미디어 타입도 마찬가지로 구체적인 정의가 우선된다. 클라이언트는 각 미디어 타입에 대해 q 값을 설정해 우선순위를 명시할 수 있다.

 

• Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,text/html;level=2;q=0.4, */*;q=0.5

구체적으로 설정된 미디어 타입 text/html;level=1이 가장 높은 우선순위를 가지며, 그다음으로는 q 값에 따라 text/html, text/html;level=2, 그리고 모든 타입인 \*/\*, 마지막으로 text/*가 우선된다.

 

전송 방식

 

1. 단순 전송 (Content-Length)

Content-Length 헤더를 통해 서버는 클라이언트에게 전송되는 데이터의 전체 길이를 바이트 단위로 명시한다. 클라이언트는 이 정보를 바탕으로 데이터를 모두 수신했는지 확인할 수 있다.

2. 압축 전송 (Content-Encoding)

서버는 Content-Encoding 헤더를 사용하여 클라이언트에게 전송되는 데이터가 압축되었음을 알린다. 클라이언트는 이 정보를 바탕으로 데이터를 압축 해제한 후 본문을 처리한다.

 

3. 분할 전송 (Transfer-Encoding: chunked)

분할 전송(Chunked Transfer Encoding)은 서버가 데이터를 나누어 전송할 때 사용된다. 데이터가 여러 개의 청크로 분할되어 전송되며, 각 청크는 자신의 크기를 명시한다.

4. 범위 전송 (Range)

범위 전송은 클라이언트가 요청한 특정 바이트 범위만을 서버로부터 전송받는 방식이다. 이는 대용량 파일을 다운로드할 때 유용하다.

Range 헤더를 통해 클라이언트는 요청할 범위를 지정할 수 있으며, 서버는 Content-Range 헤더로 해당 범위를 응답한다.