HTTP 2.0과 특징

 

HTTP 2.0이라고도 불리는 HTTP/2는 Hypertext Transfer Protocol Version 2의 약자이다. 

 

2015년 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구, 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 작업 기구)에 의해 공식적으로 발표된 HTTP/1.1(기존 표준)의 차기 버전이다. 

 

HTTP/1.x이 느린 이유

 

HTTP/1.x이 느린 이유, 바꿔 말하면 HTTP 2.0이 등장하게 된 배경은 아래와 같다. 

 

 

위의 사진만 봐도 알 수 있듯, HTTP 1.0버전대만 하더라도, Request를 날릴 때마다 Connection을 새로 생성했다. 

 

Short-lived connections는 너무 비효율적이어서, HTTP 1.1에서는 Persistent Connection이라는 개념과 HTTP Pipelining이라는 개념이 만들어졌다. 

 

커넥션을 재사용할 수 있고, request를 미리 여러 개 서버에 날릴수도 있게 되었다. 

 

그러나 이러한 개선에도 불구하고, request를 보낸 순서대로 response를 받을 수 있다는 지점에서 문제가 발생했다. 

 

HOL(Head of line) blocking (특정 응답 지연)

만약, 처음에 요청한 request에 문제가 발생해 응답이 늦어질 경우, 

 

2번째, 3번째에 요청한 request의 응답도 같이 늦어진다는 문제점이 발생한다. 

 

RTT(Round Trip Time) 증가 (양방향 지연) 

Round Trip Time은 네트워크 시작 지점에서 대상 지점으로 이동하고 시작 지점으로 다시 이동하는 데 걸리는 시간이다. 

 

앞서 말한 것처럼 매 요청별로 connection을 만들게 되고, TCP 상에서 동작하는 HTTP의 특성상 3-way-Handshake가 반복적으로 일어나게 되며, 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 저하시키게 된다. 

 

무거운 헤더(특히 쿠키)

HTTP 1.x의 헤더에는 많은 메타 정보들이 저장되어 있다. 

 

사용자가 방문한 웹페이지는 다수의 http 요청이 발생하게 되는데, 이 경우 매 요청마다 중복된 헤더 값을 전송하게 되며, 각 도메인에 설정된 쿠키 정보도 매 요청마다 헤더에 포함되어 전송된다. (전송값보다 헤더가 더 큰 경우도 있다) 

 

 

문제점들을 해결하기 위한 UI & 프론트엔드 개발자의 노력

 

• 이미지 스프라이트 
  • 여러 개의 이미지를 하나의 이미지로 합쳐서 관리하는 이미지(사용할 때는 좌표 범위로 구분해 사용)

• 도메인 샤딩
  • 리소스를 여러 개의 도메인으로 나누어 저장하여, 페이지 로드 시간을 빠르게 하는 일종의 트릭 혹은 방법
  • 여러 개의 도메인으로 나누어진 리소스를 다운받기 때문에 브라우저는 더 많은 리소스를 한 번에 받을 수 있다. 
  • 최신 브라우저들은 보통 한 도메인에 약 6개의 동시 다운로드를 제공한다. 
  • 이 개수를 초과하는 페이지의 경우, 초과하는 개수를 6으로 나눈 도메인에 리소를 뿌려두면, 병렬적으로 리소스들을 다운 받을 수 있다. 

• CSS/JavaScript 압축
• Data URI

 

HTTP 2.0의 등장 

SPDY

구글은 더 빠른 WEB을 실형하기 위해 Latency 관점에서 HTTP를 고속화한 SPDY라 불리는 새 프로토콜을 만들었다. 

 

SPDY는 HTTP를 대치하는 프로토콜이 아니라, HTTP를 통한 전송을 재정의하는 형태로 만들어졌다. 

 

SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고, 이는 HTTP/2.0 초안의 참고 규격이 되었다. 

 

 

 

HTTP 2.0은 완전히 새로운 프로토콜이 아니라 SPDY의 개선사항을 적용해 성능 향상에 초점을 맞춘 프로토콜이라고 생각하면 될 것 같다. 

 

HTTP 2.0이 빠른 이유 

1. Multiplexed Streams - 한 커넥션에 여러개의 메시지를 동시에 주고받을 수 있고, 응답은 순서에 상관없이 stream으로 주고 받는다. 
2. 요청이 커넥션 상에서 다중화되므로 HOL(Head Of Line) Blocking이 발생하지 않음 
3. Stream Prioritization(요청 리소스 간 의존관계를 설정) - 클라이언트가 요청한 HTML 문서 안에 CSS 파일 1개와 Image 파일 2개가 존재하고, 이를 클라이언트가 각각 요청한 후, Image 파일 보다 CSS 파일의 수신이 늦어지는 경우, 브라우저의 렌더링이 늦어지는 문제가 발생한다. HTTP/2의 경우 리소스 간 의존 관계(우선 순위)를 설정해 이런 문제를 해결했다. 
4. Header Compression(Header 정보를 HPACK 압축 방식을 이용하여 압축 전송) - HTTP/2에서는 Header에 중복값이 존재하는 경우, Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고, 중복된 Header는 index 값만 전송하고 중복되지 않은 Header 정보의 값은 Huffman Encoding 기법으로 인코딩 처리하여 전송한다. 
5. Server Push(HTML 문서 상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음) - 클라이언트가 HTML 문서를 요청하고 해당 HTML에 여러 개의 리소스(CSS, Image,...)가 포함되어 있는 경우, HTTP/1.1에서는 클라이언트는 요청한 HTML 문서를 수신한 후, HTML 문서를 해석하면서 필요한 리소스를 재요청하는 반면, HTTP/2에서는 Server Push 기법을 통해 클라이언트가 요청하지 않은 리소스를 push해주는 방법으로 클라이언트의 요청을 최소화하여 성능 향상을 이끌어냈다. PUSH_PROMISE라고 부르며, PUSH_PROMISE를 통해 서버가 전송한 리소스에 대해서 클라이언트는 요청하지 않는다. 
6. 프로토콜 협상 메커니즘 - 프로토콜 선택. like HTTP / 1.1, HTTP / 2 또는 기타 
7. HTTP / 1.1과의 높은 수준의 호환성 - 메소드, 상태코드, URI 및 헤더 필드
8. 페이지 로딩 속도 향상

 

하지만, HTTP/2는 여전히 TCP를 이용하기 때문에 HandShake의 RTT(Round Trip Time)로 인한 Latency(지연 시간), TCP의 HOL Blocking은 해결할 수 없다. 

 

그래서 HTTP/3가 등장했다. 

 

다음 포스팅에서는 HTTP/3에 대해 알아보자.