HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화되었다. 그러다 보니 성능은 어느 정도 희생시키지 않을 수 없었다. 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 HTTP의 메시지 교환 방식은 단순함 면에서는 더할 나위 없었지만, 응답을 받아야지 그다음 요청을 보낼 수 있기 때문에 심각한 회전 지연을 피할 수 없었다.
이를 해결하기 위해 구글에서는 SPDY라는 프로토콜을 내놓았고 SPDY를 기반으로 HTTP/2.0을 설계하기로 결정했다.
HTTP/2.0은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작한다. 이때 TCP 커넥션을 초기화하는 것은 클라이언트다.
1) 프레임
HTTP/2.0에서 모든 메시지는 프레임에 담겨 전송된다. 모든 프레임은 8바이트 크기의 헤더로 시작하며, 뒤이어 최대 16383바이트 크기의 페이로드가 온다.
2) 스트림과 멀티플렉싱
스트림은 HTTP/2.0 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스다.
HTTP/2.0에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있다. 뿐만 아니라 우선순위도 가질 수 있다. 그러나 우선순위에 따르는 것은 의무 사항이 아니기 때문에, 요청이 우선순위대로 처리된다는 보장은 없다.
3) 헤더 압축
HTTP/1.1에서 헤더는 아무런 압축 없이 그래도 전송되었다. 과거에는 웹페이지 하나를 방문할 때의 요청이 많지 않았기 때문에 헤더의 크기가 그다지 큰 문제가 되지 않았지만 지금은 다르다. 이를 해결하기 위해 HTTP/2.0에서는 HTTP 메시지의 헤더를 압축하여 전송한다.
4) 서버 푸시
HTTP/2.0은 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해준다. 이 기능은 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유용하다.
1) 중개자 캡슐화 공격
HTTP/2.0 메시지를 중간의 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있다.다행히 HTTP/1.1 메시지를 HTTP/2.0 메시지로 번역하는 과정에서는 이런 문제가 발생하지 않는다.
2) 긴 커넥션 유지로 인한 개인정보 누출 우려
HTTP/2.0은 사용자가 요청을 보낼 때의 회전 지연을 줄이기 위해 클라이언트와 서버사이의 커넥션을 오래 유지하는 것을 염두에 두고 있다. 이것은 개인 정보의 유출에 악용될 가능성이 있다.