1. HTTP/2.0이란?
HTTP/2는 Hypertext Transfer Protocol Version 2를 뜻하며, 구글이 제안했던 SPDY의 아이디어를 바탕으로 표준화된 프로토콜이다.
HTTP/1.1의 기반이 된 RFC 2616은 발표된 이래 인터넷이 성장하는 바탕이 되었지만, 웹 페이지가 복잡해지고 실시간에 가까운 응답 속도를 요구하는 등 시대가 변하면서 대대적인 개선이 필요해졌다.
HTTP/2는 기존 HTTP의 의미론, 즉 메서드, 상태 코드, URI, 헤더 필드의 개념은 유지하면서 전송 방식을 개선한다. 그래서 애플리케이션 입장에서는 HTTP를 그대로 사용하되, 내부적으로는 더 효율적인 바이너리 프레이밍 계층을 사용한다고 이해하면 쉽다.
2. 목표
요청과 응답의 멀티플렉싱을 통하여 레이턴시를 줄이고, HTTP header 필드를 압축하여 프로토콜 오버헤드를 최소화하며, 요청 우선순위와 서버 푸시 기능을 지원하는 것이 목표이다.
특히 HTTP/1.1에서는 하나의 연결에서 요청과 응답이 순서에 묶이거나, 이를 피하기 위해 여러 TCP 연결을 열어야 하는 문제가 있었다. HTTP/2는 하나의 연결 안에서 여러 요청과 응답을 동시에 주고받을 수 있도록 하여 이런 비효율을 줄인다.
3. HTTP/2.0에서 새로 나온 개념
frame은 HTTP/2 통신에서 사용되는 가장 작은 단위이다. HTTP/2의 모든 메시지는 frame 단위로 쪼개져 전송된다.
stream은 하나의 HTTP 요청과 응답을 주고받기 위한 논리적인 흐름이다. 하나의 stream 안에는 HEADERS frame, DATA frame 등 여러 frame이 포함될 수 있다. 예) HEADERS frame + DATA frame => 하나의 stream을 구성하는 frame들
header에는 HTTP 상태 코드, 메서드, 경로, 서버 등의 메타데이터가 들어간다.
data에는 실제 응답 본문이나 요청 본문 같은 payload가 들어간다.
즉, HTTP/2에서는 여러 stream의 frame들이 하나의 TCP 연결 안에서 섞여 전송될 수 있고, 수신 측은 stream ID를 기준으로 다시 조립한다. 이것이 멀티플렉싱의 핵심이다.
4. HTTP/2.0에서의 header 압축 방법
4-1. 중복 제거
HTTP/2에서는 HPACK이라는 방식으로 header를 압축한다. HTTP/1.1에서는 요청에 중복된 필드가 있더라도 매번 같은 header 데이터를 다시 보내는 경우가 많았다. 하지만 HTTP/2에서는 정적 테이블과 동적 테이블을 활용해 자주 등장하거나 이전에 보낸 header 필드를 인덱스로 참조할 수 있다.
-> 같은 요청을 반복해서 폴링하는 경우에는 헤더가 거의 변하지 않으므로, 변경된 값만 보내거나 기존 값을 참조하는 방식으로 header 오버헤드를 크게 줄일 수 있다. 다만 실제 전송량이 항상 0바이트가 되는 것은 아니며, frame 정보나 변경된 header 값 등은 여전히 전송될 수 있다.
4-2. Huffman coding 방식으로 한 번 더 압축 진행
Huffman coding은 1952년에 발표된 대표적인 무손실 압축 알고리즘이다.
압축 알고리즘은 크게 무손실 압축과 손실 압축으로 나눌 수 있다.
HTTP header 압축에는 원본 값을 정확히 복원해야 하므로 무손실 압축이 필요하다. Entropy encoding 방식의 대표적인 예로는 Huffman coding, Arithmetic coding(산술 부호화), Range encoding(범위 부호화)이 있다. Arithmetic coding과 Range encoding은 비슷한 계열이며, Arithmetic coding은 Huffman보다 압축률이 좋을 수 있지만 단문의 메시지에서는 압축률이 더 떨어질 수 있고 연산량이 커질 수 있다.
HTTP/2에서 압축을 하는 이유는 전송 비용을 줄이기 위해서이다. 따라서 압축에 시간이 오래 걸리는 알고리즘보다는 속도와 크기 측면에서 효율적인 Huffman coding을 함께 사용하도록 설계되었다고 볼 수 있다.
정리하면 HTTP/2의 header 압축은 단순히 문자열을 압축하는 것만이 아니라, 이전에 보낸 header를 테이블에 저장해 재사용하고 필요한 경우 Huffman coding을 적용하는 방식이다.
5. 웹사이트에서 HTTP/2.0(혹은 SPDY)을 지원하는지 확인하고 싶다면?
크롬 웹스토어에서 HTTP/2 and SPDY indicator 같은 확장 프로그램을 통해 확인할 수 있다. 설치 후 브라우저 우측 상단에 번개 모양이 생기는데, 파란색이면 HTTP/2 지원, 빨간색이면 SPDY 지원, 둘 다 아니면 둘 다 지원하지 않는 것으로 표시된다.
확장 프로그램을 사용하지 않는다면 Chrome DevTools의 Network 탭에서도 확인할 수 있다. 요청 목록에서 Protocol 컬럼을 표시하면 h2처럼 HTTP/2 사용 여부를 확인할 수 있다. 다만 브라우저와 서버 설정, TLS 설정에 따라 결과가 달라질 수 있으므로 실제 접속한 환경에서 확인하는 것이 좋다.
6. gRPC
gRPC는 구글에서 개발하였으며, 구글 내외부 시스템 및 여러 엔드포인트 간의 통신을 위해 사용되는 오픈 소스 RPC 프레임워크이다.
이 gRPC는 HTTP/2 기반으로 통신한다. HTTP/2가 양방향 스트리밍을 지원하기 때문에 서버와 클라이언트가 서로 데이터를 스트리밍 방식으로 주고받을 수 있다.
또 HTTP/2는 header 압축 효율이 좋다. 더욱이 HTTP/2에 의한 header 압축뿐 아니라 Protocol Buffers에 의해 메시지 크기도 줄어든다. 이에 따라 네트워크 트래픽이 줄어들고, 사용하는 리소스가 감소하며 성능 개선을 기대할 수 있다.
예를 들어 REST API에서 JSON을 주고받는 경우에는 사람이 읽기 쉬운 대신 메시지 크기가 커질 수 있다. 반면 gRPC는 보통 .proto 파일로 서비스와 메시지 구조를 정의하고, 이를 기반으로 생성된 코드를 통해 바이너리 형식의 메시지를 주고받는다. 이 점이 HTTP/2의 멀티플렉싱, 스트리밍 기능과 잘 맞는다.
