HTTP/2

구글 2009년 HTTP/1.1의 한계를 극복하기 위해 SPDY 프로토콜 개발, 이후 2015년, SPDY 기반으로 하는 HTTP/2 프로토콜 만들었다.

바이너리 포맷 계층

애플리케이션 계층과 전송 계층 사이에 바이너리 포맷 계층을 추가.
HTTP 1.0은 일반 텍스트 메세지를 전송학 ㅗ줄 바꿈으로 데이터를 나눴다면 HTTP 2.0과 0과 1로 이루어진 바이너리 데이터로 변경,
더 작은 메세지가 프레임으로 캡술화 되어 전송된다.

멀티플렉싱

단일 TCP 연결의 여러 스트림에서 여러 HTTP 요청과 응답을 비동기적으로 보낼 수 있습니다.
이를 통해 HOL을 해결합니다.
HTTP1.1에서는 병렬요청을 하려면 다중TCP연결을 통해서 하고 일반적으로는 TCP 연결 하나당 병렬요청은 불가능.
이를 HTTP/2.0에서는 리소스를 작은 프레임으로 나누고 이를 스트림으로 프레임을 전달.
각각의 프레임은 스트림ID, 해당 청크의 크기를 나타내는 프레임이 추가되었기 때문에 작게 나눠서 다운로드가 되더라도 결과적으로는 응답데이터에서는 올바른 순서로 재조립 할 수 있게 되었다.

HTTP1.1

응답 하고 응답 받고
응답 하고 응답 받는 방식으로 통신

TCP 병렬 연결도 되긴했지만
1,2,3,이 있으면 순서대로 오지 않고 2,3,1, 이런 순서로 오게되는데 이렇게 되면 의미가 없다.

하지만 2.0은 데이터를 프레임으로 잘개 쪼개서

이름을 붙여 병렬적으로 보낸다.

스트림 아이디, 길이 같이 보내기 때문에 병렬적으로 다운로드 받고 나중에 조립하게 된다.

서버푸시

서버가 리소스를 클라이언트에 푸시를 할 수 있습니다. 요청한 HTML파일과함께 다른 개체를 별도로 보낼 수 있습니다. 만약 요청한 HTML에 CSS가 포함되어있다면 별도 요청없이 CSS를 같이 보낼 수 있습니다.

헤더압축

HTTP/1.1에서는 무거운 헤더가 있었지만 이를 허프만 인코딩 압축 방법 등으로 압축시킨다.
똑같은 서버에서 2개의 이미지를준다고 했을 때 중복되는 헤더는 제외한채 보내고 해당 공통 필드로 헤더를 재구성하며 중복되지 않은 헤더값은 허프만 인코딩 압축 방법으로 압축해 전송합니다.

HTTP/3

HTTP/2는 여전히 TCP를 사용하기 때문에 초기 연결에 대한 RTT로 인한 지연시간 문제점이 있는데 이를 해결한 버전.

QUIC(QUICK UDP INTERNET CONNECTIONS)라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아 가며 HTTP/2에서 장점이었던 멀티플렉싱 등을 가지고 있으며 초기연결설정시 지연시간 감소라는 대표적인 특성을 가지고 잇습니다.

TCP를 사용하지 않고 UDP를 사용한다는 것이 핵심.