HTTP 프로토콜 Transfer-Encoding 헤더

Transfer-Encoding 헤더

• 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에게 알려줌
• Transfer-Encoding 헤더는 hop-by-hop 헤더로, 리소스 자체가 아닌 두 노드 사이에 메시지를 적용 
• 다중 노드 연결의 각각의 세그먼트는 Transfer-Encoding의 값을 다르게 사용 가능
  
  ※ 참고
  • 전체 연결에 있어 데이터를 압축하고자 한다면, Content-Encoding 헤더를 대신 사용하는 것을 추천
  • HEAD 요청에 대한 응답은 GET 요청에 적용될 값을 출력해줌

 

Transfer-Encoding 헤더 지시자

1. chunked

• Chunked 인코딩 전송방식은 HTTP 1.1에서 사용가능한 스트리밍 데이터 전송 방식
• 데이터가 일련의 청크(Chunked Message) 내에서 전송
• Content-Length 헤더는 생략
• 각 청크의 앞부분에 현재 청크의 길이가 16진수 형태로 오고 그 뒤에는 '\r\n'이 오고 그 다음에 청크 자체가 오며, 그 뒤에는 다시 '\r\n'이 옮
• 종료 청크는 길이가 0인 것을 제외하면 일반적인 청크와 다르지 않음
• (비어있을수도 있는) 연속된 엔티티 헤더 필드로 구성된 트레일러(Trailer)가 옮

 

2. compress

• Lempel-Ziv-Welch (LZW) 알고리즘을 사용하는 형식
• compress 값의 이름은 알고리즘을 구현한 UNIX compress 프로그램에서 차용된 것
• compress는 대부분의 UNIX 배포판에서 제외된 압축 프로그램
• content-encoding에서 compress는 특허 문제로 인해 오늘날 거의 대부분의 브라우저에서 사용되지 않고 있

3. deflate

• (RFC 1951에 정의된) deflate 압축 알고리즘과 함께 (RFC 1950에서 정의된) zlib 구조체를 사용

 

4. gzip

• 32비트 CRC를 이용한 Lempel-Ziv coding (LZ77)을 사용하는 형식
• gzip은 근본적으로 UNIX gzip 프로그램의 형식
• HTTP/1.1 표준에서 gzip을 content-encoding을 지원하는 서버는 호환성 목적을 위해 x-gzip을 별칭으로 인지할 것을 권고

 

5. identity

• 압축이나 수정이 없는 정체성 기능을 나타냄 
• 명시적으로 지정되는 경우를 제외하고 항상 허용 가능한 것으로 간주

 

 

Transfer-Encoding: chunked 헤더 사용 설명

• Chunked 방식은 전달하려는 컨텐츠의 사이즈가 큰 경우 서버의 처리 지연을 보완할수 있는 방법
• Transfer-Encoding 헤더는 Chunked 전송방식으로 데이터를 전달하려 할때 주로 사용되는 헤더
• HTTP 1.1에서는 Content-Length라는 헤더로 전달하고자 하는 컨텐츠의 사이즈 표시 필요
• 하나의 TCP 커넥션에 여러개의 요청이 가능하기 때문에 클라이언트는 요청마다 전달될 컨텐츠의 데이터 사이즈를 미리 알고 있어야 함 

 

• Content-Length 헤더로 웹서버에 데이터 처리 과정 → 컨텐츠의 사이즈가 엄청 큰 경우 문제가 발생
  
  1. 웹서버가 클라이언트의 요청을 받음
  2. 웹서버는 클라이언트에게 전달해 줄 컨텐츠의 사이즈를 먼저 계산 
  3. 계산된 컨텐츠의 전체 사이즈와 함께 데이터를 전달
     

     

     
     ※ 주의
     • 2번 과정에서 컨텐츠의 사이즈가 엄청 큰 경우 문제가 발생 가능
     • 컨텐츠가 큰 경우 전체 사이즈를 계산하는 과정이 오래 걸림 → 클라이언트가 느끼는 지연시간에 반영됨
     • 컨텐츠 사이즈가 큰 경우, 더 효율적인 다른 방식이 필요

 

• 컨텐츠의 사이즈가 매우 큰 경우 Content-Length 헤더 문제가 발생 가능 → "Chunked" 전송(청크 인코딩; Chunked transfer encoding))
  • Chunked 전송 방식 개념
    • 전체 Chunk를 한번에 주지 않고, Chunked 방식으로 조금씩 조금씩 전송하는 방식
    • 웹서버는 Chunked 방식으로 데이터를 전송하는 경우에는 전체 사이즈를 한번에 계산할 필요가 없음 
    • 보내려는 Chunked만 먼저 클라이언트에게 알리고 데이터를 보냄 → 본문이 동적으로 생성됨에 따라, 서버는 일부를 버퍼에 담은 뒤 한 청크를 크기와 함께 청크 메시지 전송
        
  • Chunked 전송 방식 설명
    
    • 클라이언트가 이미지를 요청하면, 웹서버는 전체 이미지의 일부분을 전달
    • 전체 이미지의 일부분 사이즈만 알려주면 되기 때문에 전체 사이즈를 계산하지 않아도 됨으로 기존 전송방식의 단점을 극복한 방식
    • 컨텐츠의 마지막 부분을 전송하고 나서는 "0" 을 보내어 데이터가 모두 전송되었음을 알림
    • Chunked 전송방식에는 Content-Length 헤더가 존재하지 않음
      

      

       
  • Chunked 방식의 장점
    • 큰 데이터 전송에도 HTTP 연결이 중간에 끊어지지 않게 유지할 수 있음 → HTTP 1.1 연결 유지(Connection: keep-alive, 지속 커넥션)가 활성화
    • Content-Length가 필요 없음 → 크기가 가변적인 데이터 전송에 유리(DB 쿼리 결과를 출력하는 HTML 테이블 / 큰 이미지 등에 사용)
    • 전체 컨텐츠를 생성할 때까지 대기하지 않음
       
  • Chunked 방식을 통해 데이터 전송 과정
    1. Transfer-Encoding: Chunked를 통해 Chunked 전송 방식으로 데이터를 전송할 것을 알림 
    2. Transfer-Encoding: Chunked를 보낸 이후 전송하려는 데이터의 부분적인 사이즈를 16진수로 표시하여 알림
    3. 실제 데이터에 16진수로 표시한 데이터양만큼 보냄 
    4. 위 2~3번 과정을 반복하여 전체 데이터를 전송
    5. 데이터의 마지막 끝부분에 "0" 을 표시하여 데이터 전송이 완료되었음을 알림 
       

       ### HTTP 응답
       HTTP/1.1 200 OK\r\n
       Content-type: text/plain\r\n
       Transfer-encoding: chunked\r\n
       \r\n
       
       ### 청크 #1
       9\r\n
       HI, Hippo\r\n
       
       ### 청크 #2
       25\r\n
       My name is Hippo. byebye~\r\n
       
       ### 마지막 청크
       0\r\n
       \r\n​

 

 

 

참고 자료 : 분도랑: [HTTP 프로토콜 강좌]#20 HTTP 일반 헤더 II - Transfer-Encoding, Upgrade, Warning, Trailer (withbundo.blogspot.com)

참고 자료 : Transfer-Encoding - HTTP | MDN (mozilla.org)

참고 자료 : 청크 인코딩(Chunked transfer e.. : 네이버블로그 (naver.com)