HTTP/2
- 탄생년도: 2015
- spec: RFC7540
- 탄생 배경: 기존 HTTP/1.x 버전의 성능 향상에 초점을 맞춘 프로토콜, 그러나 대체가 아닌 확장
- 모든 핵심 개념 유지
- 메서드, 상태 코드, URI 및 헤더 필드
- 모든 핵심 개념 유지
Binary framing layer
- HTTP/2가 제공하는 모든 기능의 핵심
- 메시지 전송 방식 변화: 텍스트로 이루어진 HTTP 메시지를 binary 데이터로 인코딩하여 통신
- 파싱, 전송 속도 향상 개선
용어
- 스트림: 하나 이상의 메시지를 전달 할 수 있는 커넥션 내의 바이트의 양방향 흐름
- 임의의 수의 스트림이 하나의 TCP 연결에 생성될 수 있으며, 이 TCP 연결을 통해 통신 수행
- 각 스트림은 식별자를 가지며, 선택적으로 메시지 우선순위 정보를 갖습니다.
- 메시지: 논리적 요청 또는 응답 메시지에 매핑되는 모든 프레임
- 각 메시지는 한 개 이상의 프레임으로 구성
- 프레임: HTTP/2에서 가장 작은 통신 단위. 각각 프레임이 속한 스트림을 식별하는 프레임 헤더를 포함
- HTTP 헤더, 메시지 페이로드와 같은 데이터를 포함
- 상이한 스트림에 인터리빙될 수 있고, 이후 프레임 헤더 정보로 재결합 가능
위 용어들을 사용하여 다시 HTTP/2의 통신 방식을 요약하자면, HTTP/2는 HTTP 메시지를 바이너리로 인코딩된 프레임으로 쪼개어 교환하는 방식이며, 각 프레임은 단일 TCP에 복수로 존재하는 스트림 중 어느 특정 스트림에 존재하는 메시지에 매핑됩니다.
기능
1) multiplexing
여러개의 메시지를 동시에 스트림으로 주고 받는 것
- HTTP 메세지를 프레임으로 쪼개어 스트림에 인터리빙하여 보낸뒤 받은쪽에서 재결합하는 방식으로 요청과 응답을 동시에 병렬 통신할 수 있음
- 인터리빙(Interleaving)이란 신호의 부분 부분들을 일정 규칙에 따라 끼워넣기하는 것을 의미. 위의 스트림에 담겨져있던 메시지들이 프레임 단위로 교차되며 끼워넣어져 직렬화되고 그 결과 아래와 같은 그림으로 데이터 통신이 이루어지게 됨.
- 이것을 하나의 TCP 커넥션에서 수행 가능
- HTTP/1.x에선 하나에 커넥션에서 동시에 여러개 메시지를 주고받는 것이 불가능 => 이를 구현하기 위해선 여러개의 TCP 커넥션을 맺어야하는 비효율성
- handshake 비용 절감 효과
- HTTP레벨의 HOLB 문제 해결
- 여러 요청과 응답이 병렬로 진행되므로 다른 요청이나 응답이 처리되는 것을 기다릴 필요가 없음
- 여러 요청과 응답이 병렬로 진행되므로 다른 요청이나 응답이 처리되는 것을 기다릴 필요가 없음
2) 헤더 압축
HPACK이란 기술을 사용하여 헤더 압축
- HPACK
- HTTP/2에서 사용하는 HTTP 헤더 필드를 효율적으로 나타내기 위한 압축 형식
- 다음 두 가지의 기술을 사용
- 전송된 헤더 필드를 허프만 코드를 통해 인코딩하여 개별 전송 크기 감소
- 허프만코드: 자주 등장하는 문자일수록 짧은 비트로 표현하여 데이터를 효율적으로 압축하는 탐욕적 알고리즘
- 중복되는 헤더 필드에 대해서 인덱스 목록을 사용
- 전송된 헤더 필드를 허프만 코드를 통해 인코딩하여 개별 전송 크기 감소
- HPACK 압축 결과는 정적 및 동적 테이블 두 가지로 구성
- 정적: 유명한 웹사이트에서 가장 빈번하게 사용되는 헤더 필드 + HTTP/2의 pseudo-header fields
- 동적: 특정연결 내에서 교환된 값 기반으로 업데이트
- 헤더 중복의 문제를 해결
3) Server Push
클라이언트가 요청하지 않은 리소스를 서버가 함께 보내야 한다고 판단되어 자동으로 함께 보내는 기능
- 하나의 요청에 다수의 응답이 가능해진 것
- 필요한 리소스에 대해서 클라이언트가 요청할 때까지 기다리지 않기 때문에 성능 개선 가능성
4) 스트림 우선순위 지정
스트림 종속성과 가중치의 조합을 통해 우선 순위 지정 트리를 구성하고 전달하여 스트림 처리 우선순위를 지정
- multiplexing 기능으로 인해 프레임이 전달되는 순서가 중요하기에 필요한 기능
장단점
장점
- 단일 TCP 연결로 모든 요청을 동시에 보내므로써, 클라이언트는 리소스를 더 빨리 받을 수 있음
- TCP연결을 통해 연결성 및 신뢰성을 확보
단점
- TCP 레벨의 HOLB 문제
패킷 전송 후 상대방으로부터 ACK 신호를 받지 못하면, ACK를 받을 때까지 재전송하며 이후의 패킷들은 모두 대기상태에 빠지는 TCP의 고질적인 문제 - 서버 부하 증가 위험
커넥션 하나에서 대규모 요청을 일괄 처리시 과도한 서버 부하 발생 위험- 특히 서버 간 통신에서 수많은 데이터가 오고 갈 때 HTTP/2의 단일 커넥션 통신은 부적절할 수 있음
- 이 경우 게이트웨이나 프록시 단에서 HTTP/2를 대체하거나, HTTP/3을 채택하여 UDP의 데이터그램 통신 방식을 사용하는 것이 대안이 될 수 있음
적합한 사용 사례
- 응답 시간이 중요하지 않은 애플리케이션 사용하는 경우
- 신뢰할 수 있는 연결이 필요한 곳
기타 주제
HTTP/1.2가 아닌 이유?
- HTTP/1.x 와 호환되지 않는 새로운 Binary Framing 계층 도입했기 때문
SPDY
- Google에서 개발되어 2009년 중반에 발표된 실험 프로토콜
- 주요목표
HTTP/1.1의 성능을 보완하여 웹 페이지 로딩 대기 시간(page load time, PLT)을 줄이는 것 - 많은 곳에서 사용되며 HTTP 워킹 그룹(HTTP-WG)은 SPDY를 HTTP/2의 시작점으로 채택
- 멀티플렉싱, 헤더 압축, 우선 순위 지정 및 프로토콜 협상과 같은 HTTP/2 의 일부 주요 기능은 SPDY의 그것들로부터 발전
- 현재는 HTTP/2 로 대체
HPACK의 정적 테이블
+-------+-----------------------------+---------------+
| Index | Header Name | Header Value |
+-------+-----------------------------+---------------+
| 1 | :authority | |
| 2 | :method | GET |
| 3 | :method | POST |
| 4 | :path | / |
| 5 | :path | /index.html |
| 6 | :scheme | http |
| 7 | :scheme | https |
| 8 | :status | 200 |
| 9 | :status | 204 |
| 10 | :status | 206 |
| 11 | :status | 304 |
| 12 | :status | 400 |
| 13 | :status | 404 |
| 14 | :status | 500 |
| 15 | accept-charset | |
| 16 | accept-encoding | gzip, deflate |
| 17 | accept-language | |
| 18 | accept-ranges | |
| 19 | accept | |
| 20 | access-control-allow-origin | |
| 21 | age | |
| 22 | allow | |
| 23 | authorization | |
| 24 | cache-control | |
| 25 | content-disposition | |
| 26 | content-encoding | |
| 27 | content-language | |
| 28 | content-length | |
| 29 | content-location | |
| 30 | content-range | |
| 31 | content-type | |
| 32 | cookie | |
| 33 | date | |
| 34 | etag | |
| 35 | expect | |
| 36 | expires | |
| 37 | from | |
| 38 | host | |
| 39 | if-match | |
| 40 | if-modified-since | |
| 41 | if-none-match | |
| 42 | if-range | |
| 43 | if-unmodified-since | |
| 44 | last-modified | |
| 45 | link | |
| 46 | location | |
| 47 | max-forwards | |
| 48 | proxy-authenticate | |
| 49 | proxy-authorization | |
| 50 | range | |
| 51 | referer | |
| 52 | refresh | |
| 53 | retry-after | |
| 54 | server | |
| 55 | set-cookie | |
| 56 | strict-transport-security | |
| 57 | transfer-encoding | |
| 58 | user-agent | |
| 59 | vary | |
| 60 | via | |
| 61 | www-authenticate | |
+-------+-----------------------------+---------------+
Table 1: Static Table Entries
- pseudo-header
- colon
:으로 시작하며, HTTP/2에서 사용되며 HTTP/1.x에선 사용되지 않는 헤더 (그래서 pseudo라는 이름과 colon이 붙는 것) - HTTP/1.x의 start-line을 대체
- request의 method, target URI...
- response의 status...
- 5개의 pseudo-headers
:method: 요청 메서드:path: 쿼리 스트링을 포함한 요청 path:authority: HTTP/1.x의Host헤더와 비슷:scheme: 요청 스키마.http혹은https값을 가짐status: 응답의 status code
- 왜 그랬을까?
- 요청/응답 정보 전달 방법에 대해 통일감을 주기 위해서
- 쉬운 HTTP의 헤더 방식(Key: Value)을 차용
- 이와 관련된 글
- colon
참고문헌은 시리즈 첫 번째 글에 있습니다.