또 통신 시간을 단축하기 위해 pipelining이라는 기술을 도입했는데
이전의 통신 방법은 클라이언트가 보낸 요청에 의해 응답이 오기 전까지 다른 요청을 보내지 못했지만 pipelining을 도입함으로써 클라이언트는 일단 요청을 마구 보내놓고 순서대로 서버에게서 응답을 받아 대기 시간을 단축시키는 방법이다.
이 pipelining도 문제점이 있었는데 클라이언트의 첫 요청이 시간이 오래 걸리거나, 문제가 생겼을 경우 두 번째 요청이 아무리 빠르게 응답할 수 있는 요청이어도 응답할 수 없는 현상. 이 때문에 전체적인 응답 시간이 지연된다.
TCP는 하나의 연결에 하나의 응답만 전달받을 수 있도록 보장되기 때문에 여러개의 응답을 병렬적으로 받기 위해서 서버와 여러개의 TCP 통신을 연결한다.
이러한 다중 연결은 HOL를 불러오고 TCP 연결의 비효율적인 사용을 초래한다.
1.1에서 성능을 항샹 버전
기존 1.1 버전에서는 Plain Text를 사용하고 개행을 통해 헤더와 본문을 구분했다면 2.0에서는 바이너리 포맷으로 인코딩된 메시지와 프레임으로 구성된다.
이를 이용함으로써 파싱, 전송속도가 빨라지게 됐다.
2.0에서는 프레임으로 구성된 메시지를 하나의 커넥션에서 여러개의 스트림으로 다중 전송이 가능해졌다.
덕분에 비효율적인 TCP연결 부분이 해결되었으며 각 프레임마다 식별자를 가지고 있어서 꼭 순서대로 응답이 돌아오지 않아도 되게 되었고 따라서 HOL문제가 해결됐다.
하지만 http 2.0의 스트림을 이용한 통신도 TCP 프로토콜을 사용하기 때문에 TCP 자체에 있는 HOL의 문제는 해결할 수가 없다.
순서대로 오지 않는 응답 프레임에 따라서 클라이언트가 우선순위 지정 트리를 구성하고 통신할 수 있다. 이 트리는 클라이언트가 선호하는 응답 수신 방식을 나타내며 서버에서 이 트리 정보를 사용해서 스트림 처리의 우선순위를 지정해 높은 순위에 따라 클라리언트에게 최적으로 전달하도록 대역폭을 할당한다.
클라이언트가 요청하지 않은 정보에 대해서 서버가 알아서 데이터를 보내주는 것.
index.html에서 참조하고 있는 css나 js 파일들이 있다면 클라이언트가 index.html만 요청하고 나머지 파일들을 요청하지 않아도 어짜피 필요할 것이라 판단하고 서버측에서 css와 js파일을 자체적으로 보낸다.
static dynamic table을 이용하여 중복되는 정보는 table의 인덱스만 남기고 중복되지 않은 정보는 Huffman 인코딩을 하여 헤더를 압축해서 요청할 때 마다 중복되는 헤더를 줄여서 헤더를 압축해 헤더의 크기를 최대 85%까지 줄였다.
2.0의 문제를 탈피하기 위해서 UDP를 기반으로 통신하는 프로토콜
TCP는 신뢰성을 확보하기 위해 이미 너무 많은 기능들이 들어가있어서 그 자체를 손보기 힘들다고 판단해서 새하얀 백지같은 UDP에다가 개발자가 신뢰성을 불어넣으면서 지연 시간을 더 줄일 수 있다.
구글은 데이터 전송의 신뢰성을 어플리케이션 계층에 구현했고 따라서 3-way handshake를 사용할 필요가 없다.
2.0은 하나의 TCP 연결 내부에서 스트림 통신을 하기 때문에 HOL를 근본적으로 해결할 수 없었지만 QUIC은 스트림 자체가 여러개이기 때문에 하나의 스트림에서 병목현상이 생기더라도 다른 스트림에 영향을 주지 않는다.
https://victorydntmd.tistory.com/286
https://jins-dev.tistory.com/entry/HTTP11-%EC%9D%98-HTTP-Pipelining-%EA%B3%BC-Persistent-Connection-%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC
https://developers.google.com/web/fundamentals/performance/http2?hl=ko