10장 HTTP/2.0

10.1 HTTP/2.0 등장 배경

• HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 주안점을 두고 최적화되었다.
• 커넥션 하나를 통해 요청 하나를 보내고 그에 대한 응답 하나만을 받는 HTTP 메시지 교환 방식은 단순함 면에서는 좋았지만, 회전 지연(latency) 을 피할 수 없다.
• 이 회전 지연을 줄이기 위하여 새로운 프로토콜이 만들어졌고, 그것이 HTTP/2.0이다.

10.2 개요

• HTTP/2.0은 TCP 커넥션 위에서 동작한다.
• HTTP/2.0 요청과 응답은 길이가 정의된 한 개 이상의 프레임에 담긴다.
• 프레임에 담긴 요청과 응답은 스트림을 통해 보내지며, 한 개의 스트림이 한 쌍의 요청과 응답을 처리한다.
• 하나의 커넥션 위에 여러 개의 스트림이 동시에 만들어질 수 있으므로, 여러 개의 요청과 응답을 동시에 처리하는 것도 가능하다.
• HTTP/2.0 은 기존 웹 애플리케이션들과의 호환성을 최대한 유지하기 위하여 요청과 응답 메시지의 의미를 HTTP/1.1과 동일하도록 유지한다.
  • 다만, 이를 표현하는 문법은 조금씩 변경되었다.

10.3 HTTP/1.1과의 차이점

10.3.1 프레임

• HTTP/2.0의 모든 메시지는 프레임에 담겨 전송된다.
• 모든 프레임은 8바이트 크기의 헤더로 시작하며, 뒤이어 최대 16383 바이트 크기의 페이로드가 온다.
• 프레임의 헤더는 다음과 같은 필드로 구성된다.
  • R: 예약된 2비트로 반드시 0이어야 한다.
  • 길이: 페이로드 길이를 나타내는 14비트 무부호 정수
  • 종류: 프레임 종류
  • 플래그: 프레임의 종류에 따라 사용되는 8비트 플래그
  • R: 예약된 1비트로 반드시 0이어야 한다.
  • 스트림 식별자: 스트림을 식별하는 31비트 식별자. 특별히 0은 커넥션 전체와 연관된 프레임을 의미한다.

10.3.2 스트림과 멀티 플렉싱

• 스트림은 프레임들의 독립된 양방향 시퀀스이다.
• HTTP/2.0 에서는 하나의 커넥션에 여러 개의 스트림이 동시에 열릴 수 있다.
• 각 스트림은 우선순위를 가질 수 있다. 단, 우선순위에 따르는 것은 의무사항이 아니기 때문에, 요청이 우선순위대로 처리된다는 보장은 없다.
• 모든 스트림은 31비트의 무부호 정수로 된 고유한 식별자를 갖는다.
• 새로 만들어지는 스트림의 식별자는 이전에 만들어졌거나 예약된 스트림들의 식별자보다 커야 한다.
• 한번 사용한 스트림 식별자는 다시 사용할 수 없고, 식별자가 고갈되면, 커넥션을 닫고 새로 열어야 한다.
• 동시에 여러 스트림을 사용하여 스트림이 블록될 우려를 막기 위하여 WINDOW_UPDATE 프레임을 이용한 흐름제어를 사용한다.

10.3.3 헤더 압축

• 요즈음에는 웹 페이지 하나를 방문할 때 수십-수백 번의 요청을 보내기 때문에 헤더의 크기가 회전 지연과 대역폭 모두에 영향을 끼친다.
• 이를 개선하기 위하여 HPACK이라는 헤더 압축 방법으로 압축된 뒤, '헤더 블록 조각'으로 쪼개져서 전송된다.
• HPACK 은 헤더를 압축하고 해제할 때 압축 콘텍스트(compression context)라는 것을 사용한다.

10.3.4 서버 푸시

• HTTP/2.0에서는 서버가 클라이언트의 요청 없이도 클라이언트에게 리소스를 푸시할 수 있다.
• 이렇게 되면 클라이언트가 필요한 리소스를 다시 요청하여 발생하게 되는 트래픽과 회전 지연을 줄여준다.
• 리소스를 푸시하려는 서버는 클라이언트에게 미리 PUSH_PROMISE 프레임을 보내고, 클라이언트는가 이를 받게 되면 '예약됨' 상태가 된다.
• 만약 클라이언트가 RST_STREAM 프레임을 보내면, 서버 푸시를 거절할 수 있다.
• 클라이언트가 별도로 또 요청하게 되는 상황을 피하기 위하여 사전에 PUSH_PROMISE 프레임을 보내는 것이다.

• 주의할 점

• 푸시할 리소스는 클라이언트가 요청한 리소스와 관련된 것들로 제한된다.
• 중간 프락시 서버가 추가 리소스를 전달하지 않을 수도 있고, 반대로 아무 추가 리소스를 받지 않았는데도 클라이언트에게 전달할 수도 있다.
• 클라이언트는 반드시 서버가 푸시한 리소스를 동일 출처 정책(Same-origin policy, RFC6454)에 따라 검사해야 한다.
• 서버는 오직 안전하고, 캐싱 가능하고, 본문을 포함하지 않은 요청에 대해서만 푸시할 수 있다.

10.4 알려진 보안 이슈

10.4.1 중개자 캡슐화 공격(Intermediary encapsulation attack)

• HTTP/2.0 메시지를 중간의 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있다.
• HTTP/2.0은 헤더를 바이너리로 인코딩하는데, 이는 어떤 문자열이든 사용할 수 있게 해준다.
• 이는 정상적인 요청이나 응답이 불법적이거나 위조된 HTTP/1.1 메시지로 번역되는 것을 유발할 수 있다.

10.4.2 긴 커넥션 유지로 인한 개인정보 누출 우려

• HTTP/2.0은 사용자가 요청을 보낼 때의 회전 지연을 줄이기 위해 클라이언트와 서버 사이 커넥션을 오래 유지하는 것을 염두에 두고 있다.
• 이것은 개인 정보의 유출에 악용될 가능성이 있다.

See Also

• https://hpbn.co/http2/
• https://freecontent.manning.com/animation-http-1-1-vs-http-2-vs-http-2-with-push/