10년넘게 유지되던 HTTP1.1 의 장벽을 깨뜨린 장본인
HTTP 2.0 은 국제 인터넷 표준화 기구(IETF)에서 2015년 정식 발표한 HTTP/1.1 의 차기 버전이다.
since HTTP 1.1
HTTP 2가 나온 이유
텍스트 위주의 전송 프로토콜인 HTTP/1.1 이 웹기술의 발전으로 인한 고용량 멀티미디어 데이터 전송량 증대에 따라가지 못하며, 후술할 여러 문제점들에 대한 근본적인 해결책을 제시하지 못하자, Google 이 개발한 SPDY 를 기반으로 HTTP 2를 발표하게 되었다.
HTTP 1.1 의 문제점
- Head Of Line Blocking
HTTP 1.1 에서는 Connection 당 여러개의 요청을 처리하기위해 위 사진과 같은 Pipelining 을 채택하였었다. 이때, 요청 순서에 따라 응답 순서가 결정되는데 중간요청에 대한 응답이 지연될 경우, 이후에 반환해야할 응답들 또한 같이 지연되게 된다. (Blocking)
- RTT 증가
RTT 는 Round Trip Time 의 약자로, 요청 패킷이 Client(출발지) 에서 Server(목적지) 를 거쳐 해당 요청 패킷에 대한 응답이 Client까지 도달하는 시간을 의미한다. HTTP 1.1 은 TCP 기반 프로토콜이기 때문에, Connection을 만들 때 마다 3-way Handshaking 이 일어나게 된다. 따라서, 불필요한 RTT 가 증가되고 네트워크 지연을 발생시킨다
즉, 성능을 저하시킨다
- Header 중복 HTTP 1.1 은 헤더를 통해 많은 메타 데이터를 저장하게 된다. 매 요청시마다 Header 를 첨부해 주어야 하는데 인증헤더 같이 매 요청마다 동일한 값을 가지는 헤더가 중복되어, 헤더가 불필요하게 커지는 경우가 많았다.
많은 서비스들이 이러한 HTTP 1.1 의 단점을 극복하고자, Image Spriting, Domain Sharding, Data URI Scheme 등을 적용하였지만, 전술하였듯이 근본적인 해결책이 되지는 못하였다.
그 와중, Google 이 더 빠른 웹을 위해, throughput(처리량) 이 아닌 latency(지연율) 관점에서 HTTP 를 고속화한 SPDY 라는 새로운 프로토콜을 구현하였다.
SPDY 란?
TLS (SSL 의 차기버전) 과 HTTP 사이에서 동작하는 프로토콜이다.
SPDY 프로토콜은 HTTP 대처하는것이 아닌, HTTP 전송을 재정의 하는방식으로 구현되었다.
즉, Converter 라고 보면 편하다.
HTTP 2 두둥등장!
2015년 5월 14일, 이러한 HTTP 1.1 의 문제점과 SPDY 의 등장을 계기로, IETF 에서 SPDY를 기반으로 한 HTTP 2.0 프로토콜을 발표하였다.
이렇게 개발돤 HTTP 2.0 은 다음과 같은 목표를 두고 개발되었다.
HTTP 2 의 목표
- 클라이언트나 서버가 HTTP 1.1, 2.0 또는 Non HTTP 프로토콜을 사용하더라도 Connecting 이 가능하도록 한다.
- HTTP 1.1 과의 호환성을 유지한다.
- 웹의 지연시간을 감소시켜 브라우저 페이지 로드속도를 개선한다
이에 관련한 자세한 방법들은HTTP 2 장점에서 나온다. - 데스크탑 브라우저, 모바일 웹 브라우저, 웹 API, 웹서버, 방화벽 등, 자주 쓰이는 개념들을 지원한다.
HTTP 2 주요 개념
Stream
Connection 내에서 Client 와 Server 간의 데이터 전달 흐름을 의미한다.
하나의 스트림에서는 하나 이상의 메세지가 전달될 수 있다.
Message
요청/응답에 매핑되는 프레임의 집합을 의미한다.
Frame
HTTP 2.0 에서의 최소 통신단위 로, 하나의 프레임 헤더가 포함된다.
프레임 해더는 프레임이 속하는 스트림을 최소한의 자원으로 식별할 수 있게 한다.
또한 Frame 내에는 실제 요청이나 응답에 대한 파편화된 정보들 이 기록되어있다.
Stream, Message, Frame 간의 관계
- 하나의 출처(CORS 아티클 참조)에 대한 모든 통신은 하나의 TCP Connection 을 통해 수행되며, 전달될 수 있는 양방향
Stream의 수는 제한이 없다 (하나의 Connection, 하나 또는 여러개의 Stream) - 각
Stream에는 양방향 메세지 전달에 사용되는 고유식별자와 우선순위 정보가 있다.
우선순위 정보는 없을 수도 있다. - 각
Message는 하나의 논리적 HTTP 메세지 (요청, 응답 등) 이며, 하나 이상의Frame으로 구성된다. (하나의 Message, 하나 또는 여러개의 Frame) Frame은 통신의 최소단위이며 특적 유형의 데이터(헤더, 메시지 Payload = Body 등) 를 전달한다. 각기 다른Stream들에 프레임을 끼워넣고, 각 프레임의 헤더에 삽입된 식별자로 Frame 을 조립한다.
HTTP 2 장점
Binary Framing
기존에 설명하였던 Frame 은 text 가 아닌 binary 로 전송된다.
따라서, 파싱 및 전송속도가 높아지고, 오류 발생 가능성이 낮아진다.
하나의 Stream 마다 각기다른 Frame (프레임이 속한 메세지 또한 다를 수 있다) 을 조합하여 전송한다.
Multiplexing
각 Stream에서, 요청 순서와 관계없이 Frame 을 조합하므로 HTTP 1.1 Pipeline 방식과는 다르게, 요청 순서대로 응답을 보낼 필요가 사라진다.
즉, Head On Line Blocking 에 대한 근본적인 해결책이 된다
Stream Prioritization
HTTP 1.1 과는 달리, 하나의 HTTP 메세지(요청, 응답 등)가 많은 개별 프레임으로 나뉘어, 여러 스트림에 나뉘어 보내짐에 따라, 요청/응답의 처리 순서를 지정하기가 어려워지게 되었다.
따라서 이를 해결하기위해, 1부터 256까지의 Stream Prioritization 값을 설정하여, 어떤 요청이 더욱 빨리 처이해야하는지를 알려줄 수 있다.
하지만, HTTP 1.1 과는 다르게, 우선순위에 따라 순차적으로 처리하는것이 아닌, 우선순위에 따라 자원의 할당을 다르게 하여, 처리 성능을 향상시키는 방식으로 진행된다.
PC 에서 자원을 덜먹는 브라우저가 자원을 많이먹는 중량IDE 보다 자원을 덜 할당하는 방식을 떠올리면 된다
즉, 우선순위가 높다고 해서, 무조건적으로 빨리 처리되는것이 아니다. 처리해야할 양이 다를 수 있기 떄문이다.
Server Push
서버가 클라이언트의 요청과 관계없이, 단일 Client 에게 리소스를 전송(Push)할 수 있다.
(단일 Client 라 표현한 이유 : notice 가 아닌 direct message 라고 생각하면 편하다)
이를 통해 클라이언트의 요청을 미리 예측하여 응답을 보낼 수 있다
예를들어,
- 사용자가 /script.js 와 /index.css 파일을 참조하는 /page.html 자원을 요청하였다면
- Server 에서 Client가 이후 /index.css 와 /page.html 파일을 요청할 것이라는것을 예측하여
- 미리 client 에 push 하여 요청/응답 으로 인한 지연시간을 줄일 수 있다.
Header Compression
HTTP 2.0에서는 Header 중복 문제를 해결하기 위해, Header 를 압축하여 전송한다.
이때, Header 의 압축에서는 HPACK 즉 허프만 인코딩 방식으로 압축한다
