[HTTP 완벽 가이드] 10장 HTTP/2.0

HTTP/2.0의 등장 배경

HTTP/1.1에서 병렬 커넥션이나 파이프라인 커넥션이 도입되었지만 성능 개선에 대한 근본적인 해결책이 되지 못했음. 구글에서 2009년 SPDY 프로토콜을 통해 헤더를 압축하거나 하나의 TCP 커넥션에 여러 요청을 동시에 보냄으로써 회전 지연을 줄이고자 했다. 그리고 2012년 SPDY를 기반으로 HTTP/2.0의 초안을 만들게 되었다.

HTTP/2.0

TCP 커넥션 위에서 동작하며, 스트림을 통해 보내진다. HTTP/2.0은 스트림에 대한 프름 제어와 우선순위 부여 기능을 제공한다. 또한 서버푸시를 도입했는데, 서버가 클라이언트에서 필요하다고 생각하는 리소스라고 판단하는 경우, 클라이언트가 요청을 하지 않더라도 능동적으로 클라이언트에게 리소스를 보내는 것을 의미한다. 그러면서도 1.1과 거의 비슷한 형태를 유지하며 웹 애플리케이션들과의 호환성을 유지하려고 했다.

HTTP/2.0에서 모든 메시지는 프레임에 담겨 전송되며 8바이트 크기의 헤더로 시작해서 최대 16383바이트 크기의 페이로드가 온다. HTTP/1.1에서는 한 TCP 커넥션을 통해 요청을 보냈을 때, 그에 대한 응답이 도착하고 나서야 같은 TCP 커넥션으로 다시 요청을 보낼 수 있었지만, HTTP/2.0에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있고 우선순위 또한 가질 수 있다. 하지만 의무사항이 아니기 때문에 요청이 우선순위대로 처리되는 보장은 없다고 한다.

HTTP/2.0은 헤더 압축이 가능하다. 압축 콘텍스트를 사용하여 헤더를 압축한 뒤 헤더 블록 조각의 형태로 쪼개서 전송한다. 그리고 받는 곳에서는 조각들을 이은 뒤에 압축을 풀어서 원래의 헤더 집합으로 복원하는 방식으로 진행된다.

알려진 보안 이슈

• 중개자 캡슐화 공격 : HTTP/2.0 메시지를 중간의 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있다. 이는 HTTP/2.0이 헤더 필드의 이름과 값을 바이너리로 인코딩하기 때문이다. 때문에 정상적인 요청이 불법적 혹은 위조된 메시지로 번역되는 것을 유발할 수 있다는 문제가 있다. (반대의 경우는 이런 문제가 발생하지 않는다.)
• 긴 커넥션 유지로 인한 개인정도 누출 우려 : 회전 지연을 줄이기 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 경우, 개인 정보의 유출에 악용될 가능성이 있다. 사용자가 이전에 무엇을 했는지 알아낼 가능성도 발생하게 된다.