1.Introduction
Hypertext Transfer Protocol 은 아주 성공한 프로토콜이다. 그러나 오늘날 HTTP/1.1 은 잘드러나지 않는 Application의 성능에 전반적으로 좋지않은 영향을 끼치는 몇가지 방법을 이용한다.
특히, HTTP/1.0 에서는 주어진 TCP connection 에 한번에 1개의 요청만 선점하여 허용한다. HTTP/1.1에는 Request Pipelining이 추가되었지만 동시에 실행되는 주소를 가진 request에만 적용된다. 그리고 여전히 HOL Blocking 의 영향을 받는다. 그러므로 HTTP/1.0, HTTP/1.1 사용자들은 동시처리로 지연을 줄이는 다중 connection을 사용하는 많은 요청을 만들어내는것이 필요해졌다.
뿐만아니라 HTTP 헤더 필드들은 자주 반복되고, 초기 TCP congestion window를 채우는 현상을 야기할 뿐만 아니라 불필요한 네트워크 트래픽을 야기시킨다. 다중 request가 새로운 TCP connection을 만들 때 극심한 지연을 발생시킬 수 있다.
HTTP/2는 이 문제들을 HTTP’s 의미들을 최적화한 정의를 통해 다룬다. 특별히 HTTP2는 request와 response 메시지들을 같은 connection에 보내는 것을 허용하고, HTTP header필드들을 위한 효과적인 코딩을 사용한다. 또한 request에 가중치를 두어 중요한 request는 더 빠르게 완료하여 성능을 더욱 향상시킨다.
프로토콜의 결실은 네트워크에 좀더 친화적인 것이다. HTTP 1.x에 비교했을 때 TCP connection을 더 줄일 수 있기 때문이다. 이는 다른 연결들과 경쟁이 줄어들고 connection을 오래 지속시킨다는 것을 의미한다. 오래 지속되는 connection은 네트워크 가용성을 더욱 향상시켜 줄 수 있다.
결론적으로, HTTP/2는 binary message framing을 사용함으로
써 메시지들을 좀더 효율적으로 사용 할 수 있도록 한다.
2.HTTP/2 Protocol Overview
HTTP/2는 HTTP의 의미(semantics)를 위한 최적화된 전송을 제공한다. 또한 HTTP/1.1의 핵심적인 특징들을 지원하지만 몇가지 방법들을 통해 보다 효율적인 성능을 목표로 한다.
HTTP/2의 기본 프로토콜 단위는 frame이다. 각각의 frame type은 다른 목적들을 지원한다. 예를 들어 HEDERS와 DATA 프레임은 requst와 response의 기본구조를 형성한다. SETTING, WINDOW_UPDATE PUSH_PROMISE와 같은 다른 프레임들은 HTTP/2의 특성을 지원하는데 사용된다.
request의 다중분할은 각각의 HTTP request/response들이 자신의 Stream에서 통신을 하여 구현된다. Stream들은 각각 독립적이고 다른 Stream의 request, response가 블럭되거나 정지되더라도 영향을 받지 않는다.
흐름제어와 가중치는 다중분할된 stream들을 효율적으로 만든다. 흐름제어는 데이터가 수신자에 의해서만 사용 될 수 있도록 도와준다. 가중치는 제한된 자원에서 더 중요한 Stream들을 먼저 전송되도록 할 수 있다.
HTTP/2 는 서버가 client에게 response를 강제하는 새로운 교환모드를 추가했다. Server push는 서버가 추측을 하여 client가 필요로 것 같은 데이터를 client에게 데이터를 보낸다. 잠재적으로 지연이 발생할 수는 있다. 서버는 request를 조작해서 push를 수행한다. 서버는 PUSH_PRIMISE프레임으로 데이터를 보낸다. 그리고 서버는 다른 stream으로 조작한 response를 보낼수 있다.
Connection에서 HTTP Header 필드들은 많은 반복된 데이터들을 포함할수 있기 때문에 frame들은 압축된 Header들을 포함시킨다. 보통의 경우 Header 압축을 통해 request의 크기에 큰 장점을 갖을 수 있고 이로인해 한 패킷에 압축된 많은 요청들을 포함시킬 수 있게한다.