HTTP/2
- HTTP/1.1 이후 새로운 첫 번째 HTTP 버전
- HTTP/2 가 발표된 이후 2020년 기준 주요 웹사이트 천만 개가 해당 버전을 사용
- 구글 크롬, 인터넷 익스플로러, 사파리, 오페라, 파이오폭스 등이 지원
- HTTP/2는 클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경
- 상태 코드, URL, 헤더 필드 등 HTTP 메서드 자체를 변경하진 않음
HTTP/2의 주요 목표
- 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 것
- 요청 우선순위화, 서버 푸시, HTTP 헤더 필드의 효율적인 압축 기능 등을 제공
- 하나의 웹 페이지를 전송하기 위해 병렬 TCP의 수를 줄이는 것
- 서버를 열고 유지하는데 필요한 소켓을 줄일 수 있다.
- TCP 혼잡 제어를 제어할 수 있다.
- But, 웹 페이지를 전송하기 위해 오직 하나의 TCP 연결만 사용할 경우,
HOL 블로킹을 피하게 위해 신중하게 메커니즘을 구현해야 한다.
TCP 혼잡 제어
- TCP 연결이 공정하게 병목 링크를 공유하여 가용한 대역폭을 공평하게 나눠줌
- 하나의 웹 페이지를 전송하기 위해 여러 개의 병렬 TCP 연결을 열게 함
→ 브라우저는 링크 대역폭의 많은 부분을 받게 된다.
HOL(Head of Line) 블로킹 문제
- 하나의 TCP 상에서 웹페이지에 있는 모든 객체를 보내면 발생할 수 있는 문제
- 큰 객체가 병목 링크를 통과하는데 오래 걸려, 그 뒤에 있는 작은 객체들까지 지연되는 것
- HTTP/1.1에서의 해결 방법
- 여러 개의 병렬 TCP 연결을 열어서 해결
- 같은 웹페이지에 있는 객체들은 브라우저로 병렬적으로 전송하기 때문에
작은 객체들도 훨씬 빠르게 전달되어 지연이 줄어듦 - 많은 수의 TCP가 사용되기 때문에 부담
- 같은 웹페이지에 있는 객체들은 브라우저로 병렬적으로 전송하기 때문에
- 여러 개의 병렬 TCP 연결을 열어서 해결
HTTP/2 프레이밍 - HTTP/2의 필요성
- HOL 블로킹 문제의 해결책으로 등장
- 각 메시지를 작은 프레임으로 나누고, 같은 TCP 연결에서의 요청/응답 메시지를 인터리빙함
인터리빙: 여러 프로세스들이 번갈아가며 수행되는 것- 병렬성을 제공하는 것은 x, 동시성(병행성)은 제공
- 병렬성을 제공하는 것은 x, 동시성(병행성)은 제공
- 프레이밍은 HTTP/2 프로토콜의 프레임으로 구현된 다른 프레이밍 서브 계층에서 이뤄짐
프레이밍 과정 - 웹 페이지 예시
- 가정
- 하나의 큰 비디오 클립과 8개의 작은 객체로 이루어진 웹페이지
- 모든 프레임은 고정된 길이를 갖는다.
- 비디오 클립은 1000개의 프레임으로 구성
- 작은 객체는 2개의 프레임으로 구성됨
- 과정
- 서버는 해당 웹페이지를 확인하기 위해 브라우저를 통해 9개의 병렬 요청
→ 각 요청마다 서버는 9개의 경쟁적은 HTTP 응답 메시지를 보내야 함 - 비디오 클립으로부터 하나의 프레임을 전송한다.
- 이후, 프레임 인터리빙을 이용해 각 소형 객체의 첫 번째 프레임을 보낸다.
- 이후 두 번째 비디오 클립 프레임을 보내고 나서, 각 소형 객체의 마지막 프레임을 보냄
→ 즉, 모든 소형 객체는 18개의 프레임이 보내진 후에 전송된다.
- 만약 인터리빙을 사용하지 않는 경우
→ 소형 객체들은 1016개의 프레임이 보내준 후에야 전송됨
- 만약 인터리빙을 사용하지 않는 경우
- 서버는 해당 웹페이지를 확인하기 위해 브라우저를 통해 9개의 병렬 요청
HTTP/2 프레이밍에 의해 발생하는 재조립
- HTTP 메시지를 독립된 프레임으로 쪼개고 인터리빙 하면 반대편에서 재조립해야 함
← HTTP/2의 가장 중요한 개선점 - 서버가 HTTP 응답을 보낼 때
→ 응답은 프레이밍 서브 계층에 의해 처리되며 프레임들로 나눠진다.- 응답 헤더 필드는 하나의 프레임이 되며, 메시지 본문은 하나의 프레임으로 쪼개짐
- 응답 프레임들은 서버의 프레이밍 서브 계층에 의해 인터리빙 됨
이후, 지속적인 TCP 연결상에서 전송됨
- 프레임들이 클라이언트에 도착할 때
- 프레이밍 서브 계층에서 처음 응답 메시지로 재조립되며 브라우저로 의해 처리
- 클라이언트의 HTTP 요청은 프레임으로 쪼개지고 인터리빙 됨
- 프레이밍 서브 계층에서 처음 응답 메시지로 재조립되며 브라우저로 의해 처리
바이너리 인코딩
- 프레이밍 서브 계층은 프레임을 바이너리 인코딩한다.
- 바이너리 프로토콜의 장점
- 파싱 하기에 더 효율적
- 좀 더 작은 프레임 크기를 갖고, 에러에 더 강건함
메시지 우선순위화 및 서버 푸싱
메시지 우선순위화(message prioritization)
- 개발자들로 하여금 요청들의 상대적 우선순위를 조정할 수 있게 한다.
→ 애플리케이션의 성능을 최적화할 수 있게 해 준다. - 프레이밍 서브 계층은 같은 요청자로 향하는 메시지들을 병렬적인 데이터 스트림으로 쪼개줌
- 클라이언트가 특정 서버로 동시에 여러 개의 요청을 하는 경우
→ 각 메시지에 1 ~ 256 사이의 가중치를 부여하여 요청에 우선순위를 매김
→ 서버는 가장 높은 우선순위의 요청을 위한 프레임을 가장 먼저 보냄- 높은 수치일수록 높은 우선순위를 의미
- 높은 수치일수록 높은 우선순위를 의미
- 클라이언트는 각 의존도에 따라 메시지의 ID를 지정함
→ 서로 다른 메시지들 간의 의존성을 나타낼 수 있다.
서버 푸싱
- HTTP/2는 서버로 하여금 특정 클라이언트 요청에 대해 여러 개의 응답을 보낼 수 있게 한다.
- 서버는 클라이언트의 요청 없이도 추가적인 객체를 클라이언트에게 푸시하여 보낼 수 있다.
- 가능한 이유
- HTML 기반 페이지가 웹 페이지를 구동시킬 필요가 있는 객체들을 가리킬 수 있기 때문
- 이러한 객체에 대한 HTTP 요청을 기다리는 대신 서버는 HTML를 분석할 수 있다.
- 해당 객체들에 대한 요청이 도착하기 전에, 해당 객체들을 클라이언트로 보낸다.
- 가능한 이유
- 서버는 해당 요청들을 기다리는데 소요되는 추가 지연을 없앤다.
HTTP/3
- HTTP/3는 QUIC 위에서 작동하도록 설계된 새로운 HTTP 프로토콜이다.
- HTTP/2 특징들을 QUIC에 의해 포함되어 HTTP/3을 위한 더 간단한 설계를 가능케 함.
- 2020년 기준, 인터넷 드래프트로 나와 있으나 완전히 표준화된 상태는 아님
QUIC
- UDP 프로토콜 위에 위치하는 애플리케이션 계층에 구현되어 있음
- HTTP에 의미 있는 여러 특징을 갖는다.
- → 메시지 멀티플렉싱(인터리빙), 스트림별 흐름 제어, 저지연 연결 확립 등