10. HTTP/2.0

HTTP/2.0 의 상세 내용은 공식 document를 보는 것이 좋습니다.

10.1 HTTP/2.0의 등장배경#

HTTP/1.1의 메시지 포맷은 구현의 단순성과 접근성에 초점이 있으므로 성능적으로는 문제가 있습니다.
SPDY는 회전 지연을 줄이기 위해 등장했으며 HTTP에 속도를 개선했습니다.

10.2 개요#

HTTP/2.0 서버와 클라이언트 사이의 TCP 커넥션 위에 동작합니다.
프레임들에 담긴 요청과 응답은 스트림을 통해 보내집니다.
HTTP/2.0 또한 HTTP/1.1 와의 호환성을 최대한 유지하기 위해 요청과 응답 메시지의 의미를 동이랗게 유지합니다.

10.3 HTTP/1.1과의 차이점#

프레임#

프레임 구조

R : 예약된 2비트 필드, 반드시 0이어야함.
길이 : 페이로드의 길이
종류 : 프레임의 종류
플래그 : 프레임의 종류에 따라 의미가 다름
R : 예약된 1비트 필드, 반드시 0이어야함.
스트림 식별자 : 31비트 스트림 식별자.

HTTP/2.0은 DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, PING, GOAWAY, WINDOW_UPDATE, CONTINUATION 이라는 총 10가지의 프레임을 지원하고 있습니다.

스트림과 멀티플렉싱#

스트림은 HTTP/2.0 커넥션을 통해 클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스입니다.
HTTP/2.0에서는 하나의 TCP 커넥션에 여러 개의 스트림이 동시에 열릴 수 있습니다. 이를 통해 여러 TCP 커넥션을 열어서 TCP 커넥션을 무한정으로 만드는 것을 방지할 수 있습니다.
스트림은 우선순위를 가질 수도 있습니다. (반드시 보장은 아닙니다.)
서버와 클라이언트는 스트림을 상대방과 협상 없이 일방적으로 만들기 대문에 시간 낭비를 줄입니다.
HTTP/2.0 커넥션에서 한번 사용한 스트림 식별자는 다시 사용할 수 없습니다. 따라서 오래 사용하는 경우 식별자가 고갈될 수 있으나 이 경우에는 커넥션을 새로 맺습니다.
동시에 여러개의 스트림을 사용하면 스트림이 블록되는 문제가 있을 수 있으나, WINDOW_UPDATE 프레임을 통해서 흐름 제어를 하여 스트림들이 서로 간섭해서 망가지는 것을 막아줍니다.

헤더 압축#

HTTP1.1에서 헤더는 압축없이 전송이 되었으나 이는 현대의 웹에 와서는 성능적 문제가 되었습니다.
이를 개선하기 위해서 HTTP/2.0에서는 HTTP 메시지의 헤더를 압축하여 전송합니다.
HPACK은 헤더를 압축하고 해제할 때, compression context를 사용합니다. 즉, 항상 올바른 압축 콘텍스트를 수행해야합니다.
헤더를 받은 수신 측은 어떤 경우에도 반드시 압축 해제를 수행해야하며, 안된다면 반드시 COMPRESSION_ERROR와 함께 커넥션을 끊어야합니다.

서버 푸시#

HTTP/2.0은 서버가 하나의 요청에 대해 응답으로 여러개의 리소스를 보낼 수 있도록 해줍니다.
리소스를 푸시하려는 서버는 먼저 클라이언트에게 자원을 푸시할 것임을 PUSH_PROMISE 프레임을 보내어 미리 알려주어야합니다.
이러한 PUSH_PROMISE를 먼저 보내는 이유는 서버가 푸시하려고 하는 자원을 클라이언트가 별도로 또 요청하는 상황을 피하기 위해서입니다.

다음을 주의합니다.

서버 푸시를 사용하기로 했더라도 중간 프락시가 전달을 안할 수도 있고 클라이언트에게 추가 리소스를 줄 수도 있습니다.
서버는 오직 안전하고, 캐시가 가능하고, 본문을 포함하지 않은 요청에 대해서만 푸시가 가능합니다.
푸시할 리소스는 클라이언트가 명시적으로 보낸 요청과 연관된 것이어야합니다.
클라이언트는 반드시 서버가 푸시한 리소스를 동일 출처 정책(Same-origin policy, RFC 6454 참고) 에 따라 검사해야합니다.
마지막으로 서버 푸시를 끄고 싶으면 SETTINGS_ENABLE_PUSH을 0으로 설정하면 됩니다.

HTTP 3.0

이 책은 과거의 책이기에 때문에 현재는 HTTP 3.0에 대한 이야기가 나오고 있습니다. 특징은 UDP를 사용하며 QUIC라는 전송 계층 통신 프로토콜을 사용합니다. (QUIC의 전환은 헤드 오브 라인 블로킹이라는 HTTP/2의 주된 문제를 해결하는 것이 목적입니다.)

HOL(Head-Of-Line Blocking)

HOL(Head-Of-Line) 블로킹 이란 네트워크에서 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상입니다.

10.4 알려진 보안 이슈#

중개자 캡슐화 공격(Intermediary Encapsulation Attacks)#

HTTP/2.0 메시지를 중간 프락시가 HTTP/1.1 메시지로 변환할 때 메시지의 의미가 변질될 가능성이 있스비낟.
HTTP/1.1 을 HTTP/2.0으로 변경할 때는 이러한 문제는 발생하지 않습니다.

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

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