HTTP/1.1 vs HTTP/2

HTTP/1.1 기본 동작 방식 

 

Connection당 하나의 요청을 처리하도록 설계, 동시 전송 불가하며 요청과 응답이 순차적으로 진행한다. 그렇다보니 다음 전송 되어야할 파일이 기다려야하는 레이턴시가 발생한다.

 

HTTP 1.1의 단점 

 HOLB 

pipelining이란?
한번의 Connection에서 여러 요청이 가능한 기법 

파이프라이닝의 단점은 한 요청이 오래 걸리면, 다음 요청이 지연된다. 이것을 Head of Line Blocking라고 한다.

RTT 

일반적으로 HTTP 1.1은 한번의 커넥션에 한번의 요청과 응답을 처리하다보니, HandShaking 과정이 반복된다. 그렇다보니 불필요한 RTT가 증가하게 되어 성능이 저하된다.

 

RTT란? 
패킷이 목적지에 도달하고 나서 해당 패킷에 대한 응답이 출발지로 다시 돌아오기까지의 시간. 즉, RTT는 패킷 왕복 시간입니다.

 

무거운 Header 

http/1.1의 헤더에는 많은 메타정보들이 저장되어져 있다.  사용자가 방문한 웹페이지는 다수의 http요청이 발생하게 되는데 이 경우 매 요청시 마다 중복된 헤더값을 전송하게 되며 또한 해당 domain에 설정된 cookie 정보도 매 요청시 마다 헤더에 포함되어 어쩔땐 요청을 통해서 전송하려는 값보다 헤더 값이 더 큰 경우도 비일비재 하다.

위의 단점을 해결하기 위한 노력들 

 Image Spriting 

아이콘을 하나의 큰 이미지 파일로 만들어, 아이콘 이미지 파일 요청 횟수 자체를 줄이는 방식이다. 

CSS에서 해당 이미지 파일의 아이콘 좌표 값을 이용하여 표현한다.

 Domain Sharding 

다수의 Connection을 사용하여 병렬로 요청한다. 브라우저 별로 Connection 개수 제한이 존재한다.

 Minify CSS/javascript 

CSS, Javascript 소스코드를 축소하여 전달한다.

 Data URI Scheme 

Data URI Scheme은 HTML문서내 이미지 리소스를 Base64로 인코딩된 이미지 데이터로 직접 기술하는 방식이고 이를 통해 요청 수를 줄이기도 한다.

 Load Faster 

스타일시트를 HTML 문서 상위에 배치

스크립트를 HTML문서 하단에 배치

 

 

 

SPDY의 등장 

HTTP 1.1의 단점을 극복하기 위한 노력들은 아쉽게도 근본적인 해결책을 제시하지는 못했다. Google은 Latency 관점에서 HTTP를 고속화한 SPDY라는 새로운 프로토콜을 구현했다. HTTP를 대치하는 프로토콜이 아닌, HTTP를 통한 전송을 재정의하는 방식으로 구현되었다. 결국 HTTP2 초안은 Google의 SPDY를 참고하여 만들어지게 된다.

 

HTTP 2의 탄생

HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol. The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.

요약하자면, HTTP 메소드, 상태 코드 및 의미는 동일하며 프로토콜을 나타 내기 위해 HTTP/ 1.x와 동일한 API (일부 작은 추가 기능 포함)를 사용 할 수 있어야 한다. 프로토콜의 중점은 성능, 특히 최종 사용자가 인지하는 대기 시간, 네트워크 및 서버 리소스 사용량에 있다. 

HTTP2의 개선점 

Multiplexed Streams

HTTP/2는 Multiplexed Streams를 이용하여 Connection 한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며 응답은 순서에 상관없이 Stream으로 주고 받는다. HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선 버전이라 보면 된다.

Stream Prioritization

순서에 상관 없이 Stream으로 주고 받게 되면 만약 당장 필요한 파일의 순서가 뒤로 밀려나면 화면 렌더링에 문제가 발생할 수도 있다. 이를 방지하기 위해서 HTTP/2에서는 리소스에간 의존관계에 따라 우선순위를 부여해 해당 문제를 방지한다.

 Server Push

서버가 브라우저가 요청하지 않더라도 우선 필요한 파일을 자체적으로  전송할 수 있다.  이를 PUSH_PROMISE 라고 부르며 PUSH_PROMISE를 통해서 서버가 전송한 리소스에 대해선 클라이언트는 요청을 하지 않는다. 이렇게 하게 되면 후에 HTML 문서에서 특정 파일이 필요하더라도 클라이언트에서 자체적으로 다운로드를 받게 함으로써 요청 횟수를 줄일 수 있다. 

 Header Compression  

HTTP/2는 Header 정보를 압축하기 위해 Header Table과 Huffman Encoding 기법을 사용하여 처리하는데 이를 HPACK 압축방식이라 부르며 별도의 명세서(RFC 7531)로 관리하고 있다. 위 그림처럼 클라이언트가 두번의 요청을 보낸다고 가정하면 HTTP/1.x의 경우 두개의 요청 Header에 중복값이 존재해도 그냥 중복 전송한다. 

 

하지만 HTTP/2에선 Header에 중복값이 존재하는 경우 Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고 중복된 Header는 index값만 전송하고 중복되지 않은 Header정보의 값은  Huffman Encoding 기법으로 인코딩 처리 하여 전송한다.

 

 

REFERENCE

https://seokbeomkim.github.io/posts/http1-http2/

HTTP/1.1과 HTTP/2의 차이점

https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/

나만 모르고 있던 - HTTP/2 | Popit