19. Entity & Encoding(2)

2022 우아한스터디 "HTTP 완벽가이드"를 진행하면서

'HTTP 완벽 가이드' 책을 읽고, 글쓴이의 생각을 정리하는 글 입니다.

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980 

HTTP 완벽 가이드

1. Content Encoding

HTTP로 데이터를 전송할 때, 이 전송시간을 단축하기 위해서 Data를 압축해서 보낼 수도 있고, 아니면 중간에 데이터 유출을 막기 위해서 콘텐츠를 암호화해서 보낼 수도 있습니다.

 

1_1. Content Encoding 순서

순서는 간단합니다.

1-. Client가 Content를 특정 압축 알고리즘으로 압축하고, 이 압축 정보를 Content-header에 명시하고, Content Length를 수정한다.

2-. 압축된 Data가 Binary 형식으로 TCP/IP를 통해서 전달된다.

3-. Server에서 Content를 정해진 압축 알고리즘으로 풀고, HTTP Message를 복원한다.

예시로 간단히 나타내면, 아래와 같습니다.

<Client>     ------------------>     <TCP/IP>     ------------------->     <Server>
Content-type :text/html      Content-type : text/html               Content-type :text/html
Content-length :12480        Content-length : 3907                  Content-length :12480
                             Content-encoding : gzip

결국, Client와 Server가 동일한 HTTP Message를 본다는것이 중요합니다.

 

Content를 Encoding 하는 방법은 다양한 방법이 있지만, 흔하게 사용되는 4가지 방법은 아래와 같습니다.

콘텐츠 인코딩 값	설명
gzip	Entity가 GNU zip 압축
compress	Entity가 Unix 'compress'로 압축
deflate	Entity가 zlib 포맷으로 압축
identity	아무런 압축이 되지 않음

 

주의할 점은, Client가 어떤 Encoding을 처리할 수 있는지를 Requests에 명시를 해 줘야 합니다.

(이게 없다면, Server에서는 Encoding해서 보내야할지 정하기가 어렵죠)

 

이 정보는 Accept-Encoding 헤더에 포함되며, 아래 예시를 보면 이해가 빠릅니다.

Accept-Encoding 예시
#compress, gzip만을 받겠다는 표시
Accept-Encoding : compress, gzip
#모든 Encoding에 대한 가능 표시
Accept-Encoding : *
#gzip과 compress모두 받으나, gzip을 선호한다는 표시
Accept-Encoding : compress;q=0.5, gzip;q = 1.0


[Client]  ----------Request-----------> [Server] : Request에 gzip으로된
Get /log.gif HTTP/1.1                              압축만을 받을 것이라고 표기
Accept-encoding : gzip
...


[Client]  <---------Response----------- [Server] : Response에 Content-encoding을 명시
HTTP/1.1 200 OK
Content-type : image/gif
Contetn-encoding : gzip
...

2. Transfer Encoding

TE : 어떤 Transfer Encoding을 받을 수 있는지 Request에 포함시켜서 보내는 헤더

 

Transfer-Encoding : 어떠한 전송 Encoding을 사용할 지에 대해서 명시하는 Header입니다.

 

아래 예시를 보시면 이해가 빠릅니다.

Request
GET /new_products.html HTTP/1.1
Host: www.joes.com
User-Agent: Mozilla/4.61 [en] (WinNT;)
#Transfer Encoding을 Trailers와 chuncked 형식으로 받을 것이란것을 명시
TE : Trailers, chunked
....


Response
HTTP/1.1 200 OK
#Transfer Encoding을 chunk 방식으로 보낸다는 것을 명시
Transfer-Encoding: chunked
Server: Apache/3.0
...

 

3. Chunk Encoding

Chunk Encoding은 HTTP Message를 일정 크기로 쪼개고, 쪼갠 Data를 Server에서 순차적으로 보내는 방법 입니다.

 

Chunk Encoding은 Transfer Encoding의 속성중 하나인 점은 유의해주세요!

 

Chunk Encoding이 시작되면 처음에 HTTP Header 부분이 도착 한 뒤

 

Chuck가 순차적으로 전송되고, 마지막 청크가 도착한 다음 Trailer가 옵션으로 따른 뒤에 커넥션이 마무리됩니다.

 

아래 예시를 보시죠

[Client] ------------Request--------------> [Server] Client의 Request도착

[Client] <-----------Response-------------- [Server] HTTP 응답
HTTP/1.1 200 OK<CR><LF>
Content-type : text/plain<CR><LF>
Transfer-encoding: chunked<CR><LF>
Trailer: Content-MD5<CR><LF>
<CR><LF>

[Client] <-----------Response-------------- [Server] Chunk 1
↓16진수의 27이라, 실제 39글자를 의미
27<CR><LF>
We hold these truths to be self-evident<CR><LF>

[Client] <-----------Response-------------- [Server] Chunk 2
26<CR><LF>
, that all men are created equal, that<CR><LF>

[Client] <-----------Response-------------- [Server] Chunk 3
84<CR><LF>
......

[Client] <-----------Response-------------- [Server] last Chunk
0<CR><LF>

[Client] <-----------Response-------------- [Server] Trailer
Content-MD5:qjqei54p26tjisgj3p4utjgrj53<CR><LF>

이때, 마지막 Trailer의 경우 MD5 뿐만 아니라 Transfer-Encoding, Trailer, Content-Length를 제외한 다른 헤더들이 사용이 가능합니다.

 

이제 위의 결과를 종합해서,

 

Content -> Content Encoding -> Chunk Encoding ->  전송 -> Chuck Decoding -> Content Decoding -> Content

 

순으로 데이터가 이동하는 것을 예상해 볼 수 있습니다.