HTTP/2.0 의 특징과 등장 배경

일반적인 HTTP/1.1의 메시지 포맷은 한개의 커넥션에 요청을 보내고 응답을 처리 후 다음 커넥션이 진행되므로 성능에 대한 지연을 완벽하게 피할 수 없다. 

HTTP/1.1의 성능 향상을 위한 여러 해결책들이 도입되었음에도 불구하고, HTTP/1.1이 가진 요청/응답 방식의 특성은 성능의 한계를 보여주었다. 

 

HTTP/1.1 의 성능 개선과 관련된 포스팅은 아래 글을 참고

https://kuveminton.tistory.com/50

HTTP 커넥션 관리(HTTP Parallel connection/Persistent Connection/Pipelined Connection)

 

 

HTTP/2.0은 구글의 SPDY 프로토콜을 기본적으로 따르는데 SPDY는

1) HTTP의 속도 개선을 위해서 헤더를 압축하여 bandwidth를 절약하고,

2) 하나의 TCP 커넥션에 여러 요청을 동시에 보내며,

3) 클라이언트가 요청을 보내지 않더라도 서버가 리소스를 푸쉬하는 기능이 있다. 

 

 

HTTP/2.0 프레임 형식

    +--------------------------------+
    | 길이(24) |
    +---------------+---------------+---------------+
    | 유형(8) | 플래그 (8) |
    +-+-------------+---------------+----------------- --------------+
    |R| 스트림 식별자(31) |
    ++====================================================== ==============+
    | 프레임 페이로드(0...) ...
    +------------------------------------------------- --------------+

 

길이 : unsigned로 표현되는 프레임 페이로드의 길이

유형 : 프레임의 형식과 의미

플래그 : 특정 플래그용으로 예약된 8비트 필드

R : 예약된 1비트 필드. 이 비트의 의미 체계는 정의되지 않았습니다.

Stream Identifier: 표현된 스트림 식별자

 

 

1)의 헤더 압축은 Huffman coding 방식으로 이루어지며 rfc7541을 따른다. 

3)에 해당하는 기능을 부연 설명하면, 

클라이언트의 요청을 받은 서버는 관련된 리소스를 푸쉬하기 위해서 PUSH_PROMISE 프레임을 전송한다.

이 때, 요청과 관련된 리소스란 예를 들어 클라이언트에서 naver.com에 접속하였을 때, 메인 페이지에 포함, 링크된 이미지 , 소리, 자바스크립트 파일 등이 해당된다. 

클라이언트는 PUSH_PROMISE를 전달받으면 서버 푸쉬를 받을 수 있는데 원하는 리소스가 아닐 경우 RST_STREAM 프레임 을 전송하여 푸쉬 리소스를 거절 할 수 있다. 

 

 

RFC 참조 

https://www.rfc-editor.org/rfc/rfc7540

RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)

 

https://www.rfc-editor.org/rfc/rfc7541

RFC 7541: HPACK: Header Compression for HTTP/2