HTTP2 란 ?

HTTP2

Hypertext Transfer Protocol Version 2
2015년 IETF에 의해 공식적으로 발표된 HTTP/1.1(기존 표준)의 차기 버전이다.

IETF: Internet Engineering Task Force, 국제 인터넷 표준화 기구를 의미하며, 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 작업기구

평문을 사용하는 HTTP/1.* 프로토콜과 달리,
HTTP/2에서는 바이너리 포맷으로 인코딩 된 Message, Frame 으로 구성된다.

• Stream: 구성된 연결 내에서 전달되는 바이트의 양방향 흐름, 하나 이상의 메시지가 전달 가능하다
• Message: 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스이다.
• Frame: HTTP/2에서 통신의 최소 단위. 각 최소 단위에는 하나의 프레임 헤더가 포함된다. 이 프레임 헤더는 최소한으로 프레임이 속하는 스트림을 식별한다. HEADERS Type Frame, DATA Type Frame이 존재한다.

HTTP/2 주요 특징

HTTP/2는 HTTP/1.1을 완전하게 재작성한 것이 아니라 프로토콜의 성능에 초점을 맞추어 수정한 버전이라 생각하면 된다.
특히 End-user가 느끼는 latency나 네트워크, 서버 리소스 사용량 등과 같은 성능 위주로 개선했다.
아래는 HTTP/2의 주요 특징들이다.

Multiplexed Streams

HTTP/2는 Multiplexed Streams를 이용하여 Connection 한 개로 동시에 여러 개의 메시지를 주고받을 수 있으며 응답은 순서에 상관없이 Stream으로 주고받는다. HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선 버전이라 보면 된다.

Keep-Alive

하나의 요청마다 통신을 닫지 않고 연속된 요청에는 접속을 다시 이용한다.
이로써 TCP/IP는 접속까지의 대기 시간이 줄어들고, 통신 처리량이 많아지므로 속도가 올라간 것처럼 느껴진다.

HTTP/1.1부터는 이 동작이 기본으로 되어있다.
Keep-Alive를 이용하면 핸드셰이크 횟수를 줄일 수 있다.
여러 번 반복되는 핸드셰이크를 줄임으로써 응답 시간을 개선할 수 있다.
Keep-Alive를 이용한 통신은 클라이언트나 서버 중 한쪽이 다음 헤더를 부여해 접속을 끊거나 타임 아웃될 때까지 연결이 유지된다. Connection: CloseKeep-Alive
지속 시간은 클라이언트와 서버 모두 가지고 있다. 한쪽이 TCP/IP 연결을 끊는 순간에 통신은 완료되므로, 어느 쪽이든 짧은 쪽이 사용된다.

Pipelining

최초의 요청이 완료되기 전에 다음 요청을 보내는 기술이다.
다음 요청까,지의 대기 시간을 없앰으로써, 네트워크 가동률을 높이고 성능을 향상한다.
Keep-Alive 이용을 전제로 하며, 서버는 요청이 들어온 순서대로 응답을 반환한다.

그대로 동작한다면 왕복 시간이 걸리는 모바일 통신에서 큰 효과가 나지만, 여러 이유로 동작이 제대로 되지 않는 경우가 많다.
그리고 성능이 거의 좋아지지 않는 경우도 있다.
요청받은 순서대로 응답해야만 하므로, 응답 생성에 시간이 걸리거나 크기가 큰 파일을 반환하는 처리가 있으면 다른 응답에 영향을 준다.

Stream Priority

HTTP/2의 Stream은 Weight 기반 Priority 기능을 제공한다.
Stream Priority 기능을 통해서 우선순위가 높은 Message를 먼저 보낼 수 있다.
[그림 5]는 각 Stream의 Weight 값과 Stream 사이의 Weight 관계를 나타내고 있다.
Stream 사이의 Weight 관계는 Tree 형태를 이룬다. Weight는 1부터 256까지의 값을 가질 수 있다.
기본적으로 Weight에 비례하여 Stream에 할당되는 Resource양이 결정된다.
여기서 Resource는 CPU, Memory, Network Bandwidth 같은 Message 전송에 필요한 자원을 의미한다.
[그림 5]에서 Stream A의 Weight는 12, Stream B에는 4의 Weight가 설정되어 있기 때문에, Stream A와 Stream B의 Resource 비율은 3:1이 된다.
Stream B의 하위 Stream은 Stream C 밖에 없기 때문에 Stream B와 Stream C의 Resource 비율은 1:1이 된다.
Stream C의 하위 Stream은 Weight가 8인 Stream D와 Weight가 4인 Stream E가 존재하기 때문에 Stream D는 Stream C가 이용할 수 있는 Resource의 2/3만큼 쓸 수 있고, Stream C는 Stream D가 이용할 수 있는 Resource의 1/3만큼 쓸수 있다.
따라서 Stream C, D, E의 비율은 3:2:1이 된다. 종합하면 Stream A, B, C, D, E의 Resource 비율은 9:3:3:2:1이 된다.

Server Push

HTTP/2에서 Server는 Client의 요청 Message를 받으면 요청에 대한 응답 Message 뿐만 아니라, Client에서 아직 요청하지 않았지만 Client에게 필요할 걸로 예상되는 다른 Message도 함께 전송하는 Server Push 기능을 제공한다.
[그림 6]은 Server Push 동작을 나타내고 있다.
Client는 /index.html 파일만 Server에게 요청했지만 Server는 /index.html을 그리는데 필요한 PNG 파일들도 별도의 Strema을 통해서 동시에 같이 Client에게 전송하는 것을 확인할 수 있다.
[그림 4]에서 PUSH_PROMISE Type의 Frame을 확인할 수 있는데, Server Push의 시작을 Client에게 알리는 역할을 수행한다. PUSH_PROMISE Type의 Frame에는 Message를 전송할 Stream을 명시하여 Client가 해당 Stream을 통해서 Message를 수신할 수 있도록 만든다.

Header Compression

HTTP/2는 헤더 정보를 압축하기 위해 Static Table, Dynamic Table과 Huffman Encoding 기법을 사용하여 처리하는데 이를 HPACK 압축방식이라 부르며 별도의 명세서(RFC 7531)로 관리하고 있다.

Huffman Coding 방식: 데이터 문자의 빈도에 따라서 다른 길이의 부호를 사용하는 알고리즘

클라이언트가 요청을 두 번 보낸다고 가정할 때 HTTP/1.x의 경우 헤더 중복이 발생해도 중복 전송한다. 하지만 HTTP/2에서는 헤더에 중복이 있는 경우 Static/Dynamic Header Table 개념을 이용하여 중복을 검출해내고 해당 테이블에서의 index값 + 중복되지 않은 Header 정보를 Huffman Encoding 방식으로 인코딩한 데이터를 전송한다

Static Table
HTTP/2 Spec에 정의된 Table로 HTTP/2 Header로 자주 사용되는 Key-value 값 쌍을 저장하고 있는 Table이다.

Dynamic Table
한번 전송/수신한 Header의 Key-value 값을 임의로 저장하는 Buffer 역할을 수행하는 Table이다.

참조
https://ssup2.github.io/theory_analysis/HTTP2/

HTTP/2