HTTP/2란 무엇인가?

아래 내용은 Popit에서 소개된 “나만 모르고 있던 http2”를 요약 + 첨언한 내용입니다.

각 그림은 해당 글에서 가져온 것이며, 구글 이미지 검색에서 가져온 것도 있음을 미리 언급합니다.

HTTP/1.1 동작방식

HTTP/1.1은 기본적으로 1번의 연결로 1개의 리소스를 요청할 수 있다. 그래서 동시 요청이 어렵고 느리다.

HOL(Head Of Line) Blocking

TCP의 HOL Blocking은 HTTP의 HOL Blocking과 유사하나 다른 부분이 있다. 이 부분은 여기서 언급하지 않기로 한다.

HTTP/1.1은 기본적으로 하나의 요청당 하나의 리소스만 처리할 수 있다. TCP 연결 당 하나의 리소스만 받을 수 있는데, 파이프라이닝(Pipelining) 기법으로 여러 리소스를 받을 수도 있다.

예를 들어 a.png, b.png, c.png 파일을 하나의 연결에서 받는다고 가정하자.

| --- a.png — |              | --- b.png — |                          | --- c.png --- |

순차적으로 a, b, c 이미지를 요청하게 된다. 이 때 a.png 요청에 대한 응답이 지연되면 어떻게 될까?

| ------------------------------- a.png --------------- — |                                                                          | -b.png- |                                                                                      | --c.png-- |

위처럼 b.png, c.png 요청이 지연된다. 이런 현상을 HTTP의 HOL Blocking이라고 한다.

RTT(Round Trip Time) 증가

HTTP 연결을 위해서는 TCP 3-way Handshake를 하게 된다. 각 리소스를 받아오기 위해서 HTTP 연결을 맺고 끊음을 반복하기 때문에 불필요한 RTT 증가와 네트워크 지연이 발생하게 되어 느려진다.

무거운 Header 구조

HTTP 헤더에는 많은 정보가 있는데, 그 중 쿠키는 매번 요청시 마다 헤더에 담겨 전송된다.(중복된 값) HTTP 바디에 담겨 있는 내용보다 헤더가 더 큰 경우도 있다.

User-Agent 정보만 해도 120Byte가 넘는다고 한다. 

HTTP/1.1 개선 노력

Image Spriting

웹 페이지를 보면 수 많은 아이콘과 이미지들이 나온다. 이런 이미지들을 각각 요청해서 받는다면 RTT 증가와 HOL Blocking 이슈가 발생할 수 있다. 이를 보완하기 위해 아이콘이나 이미지를 하나의 큰 이미지로 만들어 CSS에서 이미지 좌표로 지정해 표시한다.

출처: 네이버 블로그

Domain Sharding

HTTP/1.1에서 하나의 연결에 하나의 리소스만 받아오는 단점을 극복하기 위해 브라우저에서 여러 개의 연결을 생성해 요청을 보내기도 한다.

하지만 Domain당 연결이 제한적이다.(크롬은 10개 제한)

http://www.browserscope.org/?category=network&v=top

Minify CSS/Javascript

서버에서 클라이언트로 보내주는 리소스의 용량을 줄이기 위해 CSS나 Javascript 코드를 최소화한다.

코드를 최소화 해 주는 툴은 많이 있다.

출처: 네이버 카페

Data URI Scheme

HTML 문서내에 이미지 리소스를 Base64로 인코딩된 데이터로 직접 기술하는 방식으로 이를 통해 HTTP 요청을 줄인다.

예제는 https://hyeonseok.com/soojung/webstandards/2011/02/17/641.html에서 확인할 수 있다.

Load Faster

• CSS는 HTML 상단에
• javascript는 HTML 하단에

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. The basis of the work was SPDY, but HTTP/2 has evolved to take the community’s input into account, incorporating several improvements in the process.

HTTP/2 공식 github 페이지에서 위와 같이 소개하고 있다. 요약해 보면 새로운 프로토콜을 만든 것이 아니라 HTTP/1.1에서 성능을 집중적으로 개선한 것을 알 수 있다.

브라우저와 웹 사이트 간의 단일 연결을 허용하는 것이 주요 목적이라고 언급하고 있다.(정확히 이해는 안 가지만 성능을 위한 내용이지 않을까 생각한다.)

HTTP/2 특징

Header Compression

HTTP/1.1의 단점인 무거운 헤더 정보를 개선하기 위해 HTTP/2는 Hashtable과 Huffman Encoding 기법을 사용하여 헤더 크기를 줄인다. 이런 압축 방식을 HPACK이라 부르며, https://http2.github.io/http2-spec/compression.html 에서 상세히 확인 할 수 있다.

HTTP/2는 중복된 헤더 정보인 경우 Index만 전송하고 중복이 아닌 경우는 Huffman Encoding을 통해 데이터를 줄인다.(아래 그림 참조)

마지막 인코딩 된 헤더를 보면 일부 인덱스만 전송되는 것을 확인할 수 있다.

Multiplexed Streams

하나의 연결에 여러 개의 메시지를 전달 받게되며 순서에 상관없이 Stream으로 받을 수 있다.(아래 그림 참조)

Server Push

서버는 클라이언트가 요청하지 않은 리소스를 임의로 보내 줄 수 있다.

예를 들어 HTML 문서를 요청 했을 때 그 문서가 렌더링 되기 위해 필요한 리소스들(이미지, CSS, script 등)을 있을 것이다. HTTP/1.1에서는 HTML 문서를 받은 후 클라이언트가 재요청을 하게 된다.(RTT 증가) 하지만 HTTP/2에서는 서버가 미리 필요로하는 리소스들을 보내주게 되는 것이다. 이를 PUSH_PROMISE라고 하며 서버가 보내준 리소스에 대해서는 클라이언트가 다시 요청하지 않는다.

Stream Priority

리소스 간의 우선순위를 지정할 수 있다. 이는 script보다 CSS를 먼저 받을 수 있도록 지정할 수 있어 화면 렌더링을 좀 더 빠르게 할 수 있는 장점이 있다.

지원 브라우저

대부분의 브라우저는 모두 지원하고 있다.

• Chrome
• Firefox
• IE 11(Window 10), Edge
• Opera
• Safari 9

---

참고

• http://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://www.slideshare.net/eungjun/http2-40582114
  
• https://ko.wikipedia.org/wiki/HTTP/2
  
• https://http2.github.io/
  
• https://hyeonseok.com/soojung/webstandards/2011/02/17/641.html