HTTP/1.1 vs HTTP/2.0

 

 

HTTP/1.1

Connection

Connection 일반 헤더는 현재의 전송이 완료된 후 네트워크 접속을 유지할지 말지를 제어한다..

만약 전송된 값이 keep-alive면, 연결은 지속되고 끊기지 않으며, 동일한 서버에 대한 후속 요청을 수행할 수 있습니다.

http/1.1의 경우 일반적으로 하나의 connection에 하나의 요청을 처리 한다.

그러므로 요청마다 connection을 만들게 되고 TCP 특성상 매 연결마다 3 Way Handshake 가 반복적으로 일어나 불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 저하 시키게 된다.

http/1.0 에서는 요청 헤더에 Connection: Keep-Alive를 추가하면 이용할 수 있다.

http/1.1 에서는 기본으로 동작한다.

 

3 Way Handshake

TCP 프로토콜에서 통신을 시작할 때 서로 준비가 되어있는지 물어보고 패킷 순서를 정한 후에 본격적인 통신을 시작하기 위한 과정이며 이를 통해 신뢰성 있는 연결을 생성한다.

시작할때의 과정을 3 Way HandShake 라고 하고 종료할 때 과정을 4 Way HandShake라고 한다.

클라이언트 -> 서버 -> 클라이언트 순서로 3번의 통신을 이후에 본격적인 통신을 시작하기 때문에 매 connection마다 발생한다면 Latency는 늘어날 수 밖에 없다.

 

Pipelining

http/1.1에서 도입되었다.

하나의 TCP 안에 두개 이상의 요청을 보내 Network Latency(지연 시간)를 줄인다.

Keep-Alive 이용을 전제로 하며, 서버는 요청이 들어온 순서대로 응답을 반환한다.

하지만 실제로  구현이 어려워 성능이 거의 좋아지지 않기도 하고 HOL Blocking이 발생합니다.

 

HOL Blocking (Head of Line Blocking)

앞선 요청에 의해 뒤의 요청이 지연되는 일

서버는 완료된 요청부터 응답하지 않고 요청된 순서대로 응답한다.

즉, 하나의 TCP 안에 두개 이상의 요청을 보내도 앞선 요청이 완료되지 않으면 뒤의 요청은 지연되어 성능이 거의 좋아지지 않기도 한다.

 

RTT (Round Trip Time)

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

네트워크 성능을 측정할 때, RTT는 네트워크 연결의 속도와 안정성을 진단할 때 일반적으로 사용된다.

 

HTTP/1.1 의 한계를 극복하기 위한 노력

Image Spriting

여러 이미지 파일을 한번의 요청으로 받아오기 위해 여러 이미지를 모아 하나의 큰 이미지를 만든 후, CSS로 해당 이미지의 좌표값을 지정해서 사용한다.

카카오 맵 api를 사용할 때, 하나의 이미지에서 좌표를 이용해 원하는 아이콘을 찾아 쓴 적이 있는데 적절한 예시인듯 하다.

 

Domain Sharding

하나의 도메인에 대해 여러 개의 Connection을 생성하여 병렬로 요청을 보내는 방법이다.

그러나 브라우저 별로 도메인당 Connection 갯수 제한이 존재한여 근본적인 해결책이 될 수 없다.

 

CSS, Javascript 최소화

전송되는 데이터의 용량을 줄이기 위해 CSS, Javascript 파일을 최소화하여 통신한다.

 

 

HTTP/2.0

 

Multiplexed Streams

HTTP 1.1의 HTTP Pipelining 의 개선안으로 하나의 Connection으로 동시에 여러 개의 메세지를 주고 받을 수 있다.

http/1.1 에서는 요청과 응답은 각각 하나의 메시지가 하나의 오브젝트의 요청과 응답을 담당한다.

http/2.0 에서는 Stream 하나가 다수개의 요청, 다수개의 응답 정보를 포함하므로 동시에 요청 및 응답할 수 있는 오브젝트 개수가 늘어나며 요청 순서에 상관없이 Stream으로 받기 때문에 HOL Blocking이 발생하지 않는다.

 

• Frame: http/2.0 통신상의 제일 작은 정보의 단위, Header 또는 Data
• Message: 요청 또는 응답의 단위, 다수의 Frame
• Stream: 클라이언트와 서버 사이에 맺어진 연결을 통해 양방향으로 주고 받는 하나 또는 다수의 Message

Stream Prioritization

응답에 대한 우선순위를 정해 우선순위가 높을수록 응답을 빨리 한다.

예를 들어 하나의 html 문서에 css 파일과 여러 img 파일이 있는 경우 css 파일의 우선순위를 올려 브라우저는 렌더링을 우선적으로 진행하고 이후 img파일이 도착하는 대로 이미지를 띄운다.

 

Server Push

클라이언트(브라우저)가 html문서를 요청했고 해당 html에 여러개의 리소스(css, img...) 가 포함되어 있는경우 http/1.1에서 클라이언트는 요청한 http문서를 수신한 후  http문서를 해석하면서 필요한 리소스를 재 요청한다.

그러나 http/2에선 Server Push기법을 통해서 html 문서에 포함된 리소스를 서버가 알아서 클라이언트에 push 해주어 클라이언트 요청을 최소화 한다.

이를 PUSH_PROMISE 라고 부르며 PUSH_PROMISE를 통해서 서버가 전송한 리소스에 대해선 클라이언트는 요청을 하지 않는다.

 

Header Compression

http/1.1의 경우 이전 요청과 중복되는 Header도 똑같이 전송하느라 네트워크 자원을 불필요하게 낭비했다.

http/2.0의 경우, Header Table과 Huffman Encoding(허프먼 부호화)을 사용하는 HPACK 압축방식으로 이를 개선하였다.

Static/Dynamic Header Table 개념을 사용하여 중복된 Header를 검출하고 중복된 Header는 table의 index만 보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경령화 하였다.

 

정리

내가 접속해 있는 웹사이트가 http/2.0을 지원하는지 쉽게 알아볼 수 있는 크롬 익스텐션이 있다.

HTTP/2 and SPDY indicator

http/2를 지원하지 않는 경우 회색, http/2를 지원하는 경우 파란색, http/3를 지원하는 경우 연두색 번개 아이콘이 나타난다.

 

http/3.0은 블로그 글을 쓰고 있는 2022년 2월 25일 기준 w3techs에 따르면 http/2.0의 사용이 50%에 조금 못미치는 수준임에도 불구하고 벌써 http/3.0을 지원하는 웹사이트가 25%씩이나 된다.

대충 훑어본 결과 http/3.0은 tcp 프로토콜이 아닌 udp 프로토콜을 사용해 3 way handshake로 인한 latency를 줄였다고 하는데 그렇다면 어떻게 신뢰성 있는 연결을 할 수 있을지에 대해 궁금해졌다.

조만간 http/3.0에 대해서와 실제로 어떻게 사용할 수 있는지도 공부해봐야겠다.

http/2.0의 점유율

http/3.0의 점유율

 

추가자료

LucidChart에서 http/2.0를 지원하며 생긴 문제점

https://www.lucidchart.com/techblog/2019/04/10/why-turning-on-http2-was-a-mistake/

 

http2를 지원하는 브라우저

https://caniuse.com/http2

 

참고자료

https://seonghui.github.io/TIL/docs/http/keep-alive-and-pipelining.html

 

https://ssungkang.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-HTTP-11-VS-HTTP-20

 

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/

 

https://developers.google.com/web/fundamentals/performance/http2?hl=ko​