HTTP/2는 HTTP 의미론을 유지하면서 여러 스트림을 하나의 연결에 다중화했다

HTTP/1.1은 요청마다 새 연결을 열거나 몇 개를 재사용했기 때문에, 브라우저는 사이트에 약 6개의 병렬 연결을 열어야 했다. 각 연결은 별도의 핸드셰이크 비용을 치렀고, 한 연결에서 느린 응답이 오면 그 뒤의 다른 응답들이 막혔다. 웹이 느린 것은 기술적 이유가 아니라 구조적 이유 때문이었다.

구글의 SPDY가 해법을 입증했다. HTTP의 메서드, 헤더, 상태 코드는 그대로 두되, 트래픽을 다중화된 많은 스트림을 나르는 단일 연결로 옮기는 것이다. IETF는 이 작업을 이어받아 이진 프레이밍과 HPACK 헤더 압축을 갖춘 HTTP/2로 RFC 7540에서 표준화했다.

의미론이 동일하게 유지되었기 때문에, 서버와 브라우저는 HTTP 요청이 무엇을 뜻하는지 다시 생각하지 않고도 이를 도입할 수 있었다. 전송 방식은 바뀌었지만 계약은 바뀌지 않았으므로, 모든 사이트가 속도 향상을 공짜로 얻었다.

HTTP의 의미론을 고정하고, 스트림을 하나의 연결 위에서 실행한다.

HTTP 의미론이 그대로였기 때문에, 기존 서버는 애플리케이션이 응답을 작성하는 방식을 바꾸지 않고도 지원을 추가할 수 있었다.

많은 스트림을 가진 하나의 연결은 6개 연결 병목과 모든 리소스에 대한 연결 설정 비용을 없앤다.

HPACK은 반복되는 헤더를 압축하므로, 동일한 쿠키와 사용자 에이전트 필드가 요청마다 다시 전송되지 않는다.

서버 푸시는 클라이언트가 요청하기 전에 서버가 자산을 보낼 수 있게 하여 왕복 한 번을 줄였다.

호환성을 유지하는 전송 방식은 의미론이 바뀌지 않더라도 승리할 수 있다. 계약은 유지하고 배관은 교체하라.

RFC 7540은 2015년 5월에 확정되어 사실상 모든 HTTPS 트래픽의 기본이 되었다. 남은 주요 문제는 TCP의 헤드오브라인 블로킹이었고, 이는 곧바로 QUIC과 HTTP/3로 이어졌다. HTTP/2는 또한 요청 밀수와 2023년에 발견된 HTTP/2 신속 재설정(rapid reset) DoS 패턴을 가능하게 했다.