[2. HTTP 아키텍처] 10장) HTTP/2.0

HTTP/2.0

- 등장 배경

: HTTP/1.1의 커넥션 하나를 통해 요청 하나를 보내고 그에 대해 응답 하나만을 받는 메시지 교환 방식은 응답을 받아야만 다음 요청을 보낼 수 있기 때문에 심각한 회전 지연이 발생한다. 이를 해결하기 위해 병렬 커넥션, 파이프라인 등이 도입되었지만 성능 개선에 근본적인 해결책이 되지 못했다.

2009년, 구글은 웹을 더 빠르게 하겠다는 목표로 SPDY 프로토콜을 내놓았다. 헤더를 압축하여 대역폭을 절약하고 하나의 TCP 커넥션에 여러 요청을 동시에 보내는 것이 가능했다.

마침내 12년 10월 3일, SPDY를 기반으로 HTTP/2.0 프로토콜을 설계하기로 결정하였다.

velog.io/@taesunny/HTTP2HTTP-2.0-%EC%A0%95%EB%A6%AC

HTTP/2(HTTP 2.0) 정리

 

- 개요

: HTTP/2.0은 서버와 클라이언트 사이의 TCP 커넥션 위에서 동작한다.

프레임들에 담긴 요청과 응답은 스트림을 통해 보내지고, 한 개의 스트림이 한 쌍의 요청과 응답을 처리한다. 스트림에 대한 흐름 제어와 우선순위 부여 기능도 제공한다.

기존 웹 앱과 호환성을 유지하기 위해, 요청과 응답 메시지의 의미를 HTTP/1.1과 같도록 유지하고 있다.

 

- HTTP/1.1과의 차이점

프레임

: HTTP/2.0에서 모든 메시지는 프레임에 담겨 전송된다. 8바이트의 헤더로 시작하고, 최대 16383바이트 크기의 페이로드가 온다.

DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, PING, GOAWAY, WINDOW_UPDATE, CONTINUATION 10가지 프레임을 정의하고 있으며, 페이로드의 형식이나 내용은 프레임의 종류에 따라 다르다.

 

스트림과 멀티플렉싱

: 스트림은 HTTP/2.0커넥션을 통해 클라이언트와 서버 사이 교환되는 프레임들의 독립된 양방향 시퀀스다.

서버와 클라이언트는 스트림을 만들 때 협상을 위해 TCP 패킷을 주고받느라 시간을 낭비하지 않고 협상없이 일방적으로 만든다.

 

헤더 압축

: HTTP/1.1과 달리 헤더를 압축하여 전송한다. HPACK명세에 정의된 헤더 압축 방법으로 압축된 뒤 '헤더 블록 조각'들로 쪼개져서 전송된다.

 

서버 푸시

: 서버가 하나의 요청에 대해 응답으로 여러 개의 리소스를 보낼 수 있도록 해준다. 서버가 클라이언트에 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유용하다.

 

- 알려진 보안 이슈

• 중개자 캡슐화 공격: 2.0메시지를 중간의 프락시가 1.1메시지로 변환할 때 메시지의 의미가 변질 될 가능성이있다. (1.1 -> 2.0으로 번역하는 과정에서는 문제가 발생하지 않음)
• 긴 커넥션 유지로 인한 개인정보 누출 우려