HTTP 학습 (3-1) - 일반 헤더 필드

* HTTP/1.1을 기준으로 작성되었습니다.

 

일반 헤더 필드

 

1. Cache-Control

HTTP 요청 시 매번 서버에게 보내지 않고 받았던 HTTP 응답을 재활용할 수가 있다. 즉 HTTP 요청/응답과 관련하여 캐싱을 할 수 있다는 것인데, 이와 관련된 헤더가 Cache-Control이다.

Cache-Control은 캐싱과 관련된 여러 명령(Directive)을 할 수 있는 헤더 필드이다. Cache-Control의 값에다 명령을 나열하여 캐싱을 어떻게 할 지를 결정하는데,  HTTP 요청과 응답 모두 사용할 수 있지만 각각 나열할 수 있는 명령들이 조금씩 다르다.

Cache-Control과 관련된 더 자세한 내용은 지금 이론으로 공부해봤자 결국 도루묵이 될 것 같아서 일단은 해당 블로그를 통해 간단하게 이론을 살펴보고 나중에 실제로 사용할 일이 생길때 직접 학습하겠다.

 

< Pragma  헤더 필드  >

HTTP/1.1 보다 오래된 버젼에서 사용했던 것으로, 클라이언트가 캐시된 리소스의 리스폰스를 원하지 않는다는 것을 중간 서버에 알리기 위해 사용되었다. 
모든 중간 서버가 HTTP/1.1이면 Cache-Control: no-cache로 보내면 되지만, 모든 중간 서버의 HTTP 버전을 확신할 수 없으므로 Cache-Control과 함께 Pragma: no-cache를 같이 보내는 경우도 있다

 

 

2. Warning

리스폰스에 관한 추가 정보를 전달하는 것으로 기본적으로 캐시에 관한 문제의 경고를 유저에 전달한다. 

Warning: 113 http://www.example.com "Response is stale"

 

위와 같이 첫 번째 필드에는 경고 코드, 다음 필드는 경고코드가 생성된 프록시 서버, 다음 필드는 경고에 대한 텍스트 문구이다. 

경고코드는 110, 111, 112...등이 있는데 자세한 것은 MDN으로 가서 살펴보면 되겠다.

 

3. Connection

Connection 헤더는 두 가지 기능이 있다. hop by hop 헤드 필드를 Connection에 나열하여 특정 헤더를 다음 서버에 더 이상 전송하지 않거나, Close 혹은 Keep-Alive를 사용하여 지속적 접속 관리를 할 수 있다. 

지속적 접속이란 서버와 클라이언트가 TCP 연결을 한 번 하면 그 뒤로 별개의 TCP 연결을 하지 않아도 HTTP 통신이 가능하게 해주는 것이다. HTTP/1.0에서는 HTTP 요청 후 서버가 응답을 보내면 TCP도 연결이 끊어졌으나, HTTP/1.1 이후로는 연결을 지속적으로 접속하게 해주는 Keep-Alive가 디폴트가 되었다. 만약 서버에 요청을 끊고 싶다면 close를 명시하면 된다.

< 참조 >

HTTP/2.0에서는 클라이언트와 서버의 연결 상태를 광리하는 방법이 달라졌기때문에 더이상 Connection에서 사용되었던 Keep-Alive의 기능은 무의미해졌다. 일단은 2.0에서는 Keep-Alive가 사용되지 않는다만 알아두고 더 자세한 사항은 나중에 HTTP/1.1과 HTTP/2.0을 비교해보면서 알아보도록 하겠다.

 

4. Date

HTTP 메시지를 생성한 날짜를 나타낸다.

 

 

5. Transfer-Encoding

HTTP 메시지 바디의 전송 코딩 형식을 지정하는 경우 사용된다. 

값에는 chunked, compress, deflate, gzip이 있는데, 이 중 chunked를 제외한 나머지는 바디 내용을 압축하여 보내는 것이고, chunked는 분해하여 보내는 것이다.

< 청크 전송 인코딩 >

청크(chunk)는 덩어리라는 뜻으로, 청크 전송 인코딩이란 서버에서 보낼 메시지를 일정 크기의 청크로 쪼개고 순서대로 클라이언트에 보내는 전송 방식이다. 

HTTP/1.0에서의 전송 방식은 하나의 HTTP 요청이 완료될 시 TCP가 바로 끊어지기 때문에 이를 바로 요청의 완료로 볼 수 있다.

하지만 HTTP/1.1은 하나의 TCP 연결에서 여러 HTTP 요청이 이루어지기 때문에 하나의 요청에 대한 완료 시기를 알 수가 없다. 그렇기에 서버는 Content-Length라는 헤더로 하나의 HTTP 요청이 보내고자하는 컨텐츠의 사이즈를 먼저 알려준 후 컨텐츠를 전달하는데, 이 때 용량이 큰 컨텐츠의 경우 사전에 컨텐츠 사이즈를 계산하는 것이 오래 걸리게 되고 이는 곧 전송이 느려지게 되는 원인이 된다.

이런 경우에 쓰이는 것이 청크 전송 인코딩이다. 말했듯 컨텐츠를 일정 크기의 덩어리로 나눠 보내기에 서버는 컨텐츠의 전체 사이즈를 미리 계산할 필요가 없고 당장 보내려는 작은 덩어리의 크기만 알려주면 된다. 그리고 컨텐츠의 모든 전송이 완료되면 0을 보내어 데이터가 모두 전송되었음을 알린다. 따라서 청크 전송 인코딩 방식에는 Content-Length 헤더가 존재하지 않게된다.

클라이언트가 서버로부터 응답을 수신하려면 서버가 전체 응답 메시지를 모두 생성할 때 까지 기다려야했는데, 청크 인코딩을 사용함으로써 더 빠르게 전송할 수 있게 되었다.

< 전송 방식에 대해  >

메시지 바디를 전송하는 방법은 일반 전송, 압축 전송, 분할 전송, 범위 전송으로 크게 4가지 형태로 나눌 수 있다. 
1. 일반 전송: 일반 전송은 별도의 처리없이 그냥 데이터를 통으로 전송하는 방식이다. 클라이언트는 Content-Length 헤더로 데이터의 총 크기를 알 수 있다.
2. 압축 전송: 데이터를 압축하여 전송하는 방식으로, Content-Encoding 헤더에 압축 방식을 클라이언트에게 알려줌으로써 데이터를 받을 수 있게 한다.
3. 분할 전송: 데이터를 쪼개서 하나하나 보내는 방식이다. Transfer-Encoding 헤더에 데이터를 쪼개 보낼 것이라는 것을 클라이언트에 알려줌으로써 데이터를 받을 수 있게 한다.
4. 범위 전송: 데이터의 범위를 정해서 보내는 방식이다. 클라이언트가 Range 헤더를 이용하여 범위를 지정하면 서버는 해당 범위의 데이터를 보내준다.

 

 

6. Trailer

청크 전송 인코딩을 사용하고 있는 경우 사용되는 헤더로, 청크 전송 인코딩을 사용하게 되면 데이터가 덩어리로 분리되어 순차적으로 오게 되는데, Trailer 헤더를 사용하여 메시지 바디 끝에 추가 헤더 정보를 넣어서 클라이언트가 미리 알아야하는 내용을 적어 보낼 수가 있다. 

Trailer로 보낼 수 있는 헤더 필드는 Transfer-Encoding, Trailer, Content-Length를 제외한 모든 HTTP 헤더 필드이다.

 

 

7. Upgrade

HTTP 프로토콜의 새로운 버전이나 다른 프로토콜이 통신에 이용되는 경우, 이를 바꾸려고 할 때 사용하는 헤더이다.

 

 

8. Via

클라이언트와 서버 간의 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 위해서 사용된다. 중간 경유 서버들은 자신의 서버 정보를 이 헤더 필드에 추가한 뒤에 메시지를 전송합니다.

Via 헤더 필드는 전송된 메시지의 추적과 리퀘스트 루프의 회피 등에 사용되기 때문에 중간 서버를 경유하는 경우에는 반드시 부가할 필요가 있다. 

형식)
Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>

ex)
Via: 1.1 example.com, 1.1 proxy.example.org

 

 

 

 

---

참고 문서

• 엔티티와 인코딩 - https://feel5ny.github.io/2020/01/05/HTTP_015_01/
• [HTTP 프로코톨 강좌] #20 HTTP 일반 헤더2 - https://withbundo.blogspot.com/2017/08/http-20-http-ii-transfer-encoding.html