HTTP 2.0 이란?

지인호·2022년 1월 10일
0

TIL

목록 보기
16/28
post-thumbnail

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 의 목표

  1. 클라이언트나 서버가 HTTP 1.1, 2.0 또는 Non HTTP 프로토콜을 사용하더라도 Connecting 이 가능하도록 한다.
  2. HTTP 1.1 과의 호환성을 유지한다.
  3. 웹의 지연시간을 감소시켜 브라우저 페이지 로드속도를 개선한다
    이에 관련한 자세한 방법들은 HTTP 2 장점 에서 나온다.
  4. 데스크탑 브라우저, 모바일 웹 브라우저, 웹 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 즉 허프만 인코딩 방식으로 압축한다

허프만 인코딩 방식에 대해 자세히 알고싶다면?

profile
MSA 관련 기술에 관심이 많습니다

0개의 댓글