HTTP/1.1, /2, /3 의 차이점

zzzz465·2021년 1월 22일
1

우리가 알고 있는 HTTP는 다음과 같이 생겼다
(사실 대부분 HTTP 1.1로 알고있다)

HTTP/1.x (표준 프로토콜)

우리가 알고있는 HTTP 1.x 는 다음과 같이 이루어져있다.

  • HTTP 헤더 + 바디로 구성
  • 헤더에는 URI, Request method, 여러 헤더 정보가 포함
  • 사람이 읽을 수 있는 문자열이 그대로 전송됨
  • TCP 커넥션을 이용함
    • 3-way-handshake를 사용하게 되어있음
  • 커넥션 재사용
    • 통신에 사용된 커넥션을 즉시 끊지 않고, 대기하였다가 추가 요청이 있을 경우 재활용
  • 파이프라이닝 추가
    • 요청에 대한 응답이 끝나기 전에 다음 데이터를 미리 요청함
  • 등등등...

HTTP/2 (성능 향상 버전)

사실 HTTP 1.1은 많은 문제를 갖고있다.

  • 바이너리가 아닌 텍스트로 데이터를 보낸다던가
  • TCP를 쓴다던가
  • 여전히 요청 데이터가 동기적으로 진행된다던가 (1개 요청하고 대기, 도착하면 그다음 데이터 요청)
  • 헤더에 중복된 데이터가 있다던가

이를 개선하기 위해, 2010년 초중반, 구글에서 SPDY 프로토콜을 개발했다.

스트림, 메세지 및 프레임

차이점을 얘기하기 전에 알아야 할 단어들이 몇가지 있다.

  1. 스트림
    구성된 연결 내에서 전달되는 바이트의 양방향 흐름이며, 하나 이상의 메세지가 전달 가능함
  2. 메세지
    요청 / 응답에 해당하는 프레임의 전체 시퀸스(??)
  3. 프레임
    HTTP/2 통신에서의 최소 단위이며, 각 프레임에는 하나의 프레임 헤더가 포함된다.

즉 정리하자면

  • 스트림은 하나 이상의 메세지를 전송한다
  • 하나의 HTTP Request / Respond는 하나의 메세지에 해당한다
  • 메세지는 한 개 또는 여러 개의 프레임으로 구성될 수 있다
  • 각 프레임은 프레임 헤더를 가지고 있으며, 프레임 헤더를 이용하여 어느 스트림에 속하는 지를 알아낸다

특징으로는

  • 모든 통신은 단일 TCP 연결을 통해 이뤄질 수 있고, 스트림의 개수는 제한이 없다
  • 각 스트림은 고유 식별자와 우선순위 정보(선택사항) 이 있다
  • 프레임은 통신의 최소 단위이다. TCP가 데이터를 쪼개서 보낸 다음 헤더를 보고 재조립 하는것과 비슷하다.

사진으로 보면 이런 개념이다

HTTP 1.x 과 2.0 의 차이점으로

1. HTTP Body가 이진 데이터다

기존 HTTP 는 Body가 문자열로 이루어져 있지만, HTTP 2.0 부터는 binary framing layer 라고 하는 공간에 이진 데이터로 전송된다.

HTTP Req Method, 헤더 등은 여전히 문자열로 전송되지만, 밑 바디 부분이 변경되는 것이 가장 큰 변경점 중 하나다.

이미지로 보면 이런 모습이다

위 이미지를 보자.
좌측은 HTTP 1.1 로 구성된 메세지이고, 우측은 HTTP 2.0 으로 만들어진 메세지이다.
헤더와 바디 프레임으로 나뉘어 들어간다는 것을 알 수 있다.

2. 멀티플렉싱

1.0 에서 1.1으로 넘어오며 pipelining 기술을 도입하였지만, 여전히 HOL(Head-of-line) Blocking 문제가 있다.

HOL blocking 은 패킷이 순서대로 도착해야 하므로, 패킷이 도착할 때 까지, 그 이후의 패킷은 전송되지 못하는 것을 의미한다.

위의 스트림의 개념을 사용하자면, 1.x 버전에서는 1개의 TCP 연결 당 1개의 스트림만 이용 가능하다. 따라서 하나의 메세지가 응답될 때 까지 다른 메세지를 요청하지 못한다.
그래서 여러 TCP 연결을 수립하여 여러 요청을 수행한다.

하지만 HTTP 2.0 을 이용하면 스트림을 이용하여 다음과 같은 장점이 있다.

  • 여러 요청/응답을 병렬로 처리 (하나의 TCP 연결에 여러 스트림 사용)
  • TCP 연결이 1개이므로 3-way-handshake 오버헤드가 없음
  • 네트워크 가용성 증가로 속도 상승 및 이미지 스프라이트 등을 사용하지 않아도 됨
  • 등등등

3. 스트림 우선순위 지정

사실 이건 Optional한 기능이다.
이제 1개의 TCP에 여러 개의 스트림을 사용할 수 있게 되었으므로, 각각의 스트림에 우선순위를 둘 수 있게 되었다.

이것을 이용하여 전송 순서를 임의로 고정시킬 수는 없으나, 중요한 데이터를 먼저 보낼 수 있도록 설정하는 것이 가능하다

4. 헤더 압축

HTTP 1.x 에서는...

  • 헤더가 문자열로 전송됨
  • 적게는 500~800바이트, 크게는 수 KB를 소모

이러한 성능 이슈를 해결하기 위하여...
HTTP/2 는 HPACK 압축을 이용하여 헤더를 압축하여 보냄

5. Server push

클라이언트에게 필요한 데이터가 있을 때, 직접 요청하기 전에 서버가 미리 데이터를 전송하여 받아볼 수 있게 함

위와 같은 개선들이 다수 포함되어 있으며, 자세한 내용은
구글 HTTP/2 소개 문서 을 읽자.

3. HTTP/3

HTTP/2 를 도입하면서 구글은 많은 문제를 해결했다.

여러 TCP 연결을 1개로 합치고, HOL 문제도 해결하고...
하지만 TCP 프로토콜 자체의 한계 때문에 더이상 성능 개선에도 한계가 오게 된 것이다.

그러면 TCP를 쓰지 않는다면, 무엇을 쓸까? 당연히 UDP 를 쓰게 될 것이다. (둘 다 전송 계층에 있으므로)

UDP와 TCP의 차이는?

TCPUDP
연결 방식연결 지향형 프로토콜비 연결 지향형 프로토콜
전송 순서보장함보장하지 않음
신뢰성높음낮음
전송속도(상대적)느림빠름
혼잡제어OX
헤더크기20 바이트8 바이트

사진으로 보면 아래와 같다.

즉 구글은 TCP의 모든 것을 내다 버리고, UDP를 이용하여 완전히 새로운 프로토콜을 설계하여 얹겠다는 이야기이다.

구글이 UDP 위에 올린 프로토콜 QUIC

구글은 QUIC를 다음과 같이 소개하고 있다.

Google has been using QUIC, a UDP-based encrypted transport protocol optimized for HTTPS, to deliver traffic for our products

주요 기능으로 다음과 같은 것들을 소개하고 있다.

QUIC’s key features include establishing connections faster, stream-based multiplexing, improved loss recovery, and no head-of-line blocking. QUIC is designed with mobility in mind, and supports migrating connections from WiFi to Cellular and back.

출처: 구글 블로그

QUIC 장점

1. 딜레이 감소

2. 멀티플렉싱 지원

멀티플렉싱을 지원하며, 이로 인하여 HOL Blocking이 없음
(멀티플렉싱은 단일 연결로 여러 신호를 전송하는 것, 참고 링크)

3. 네트워크 스위칭 속도가 개선됨

매 요청마다 클라이언트 - 서버의 아이피가 필요한 것이 아니고, QUIC는 Unique connection ID를 사용해서 모든 패킷이 잘 구별될 수 있도록 한다.
따라서 휴대폰으로 인터넷을 할 때, 중간에 와이파이에서 LTE로 변경해도 스트림이 계속 유지가 된다.
(TCP의 경우에는 처음부터 다시 데이터를 받아야 함)

자세한 내용은

some quic benefits of http/3 (영문)
HTTP/3는 왜 UDP를 선택한 걸까?
Introducing QUIC support for HTTPS load balancing (영문)

에서 더 자세히 읽어볼 수 있다.

참고자료

https://developers.google.com/web/fundamentals/performance/http2?hl=ko
https://thewonder.site/http-1-vs-http-1-1-vs-http2/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages
https://www.digitalocean.com/community/tutorials/http-1-1-vs-http-2-what-s-the-difference

profile
안녕하세요

0개의 댓글