동도리 개발 로그

HTTP/1.1 과 HTTP/2.0 와 HTTP/3 본문

개발/공통

HTTP/1.1 과 HTTP/2.0 와 HTTP/3

동돌이 2022. 1. 24. 11:24
반응형

gRPC를 이용한 앱을 구현하던 도중에 좀 되긴하였지만 HTTP/3 가 있고, 구글에서는 이미 사용중이라고 해서 비교 글을 적으려고한다.

나중에 이직에도 도움이 되길..

 

1. HTTP 1.1 - 표준 프로토콜

현재 가장 많이 사용되고 있는 표준 프로토콜이다. 

 

특징으로는

  • http 헤더 사용 - 여러정보 포함
  • TCP 커넥션 사용
  • 3-way-handshaking을 통한 신뢰성 확보
  • 커넥션 재사용
  • 파이프라이닝(piplining)

전반적인 흐름
파이프 라이닝

표준이긴 하지만 단점들이 있다. 

  • Head of Line Blocking 
    파이프라이닝을 이용한 데이터 전송 속도 향상을 이루었지만 '순차적'으로 받는 다는 한계에서 벗어나지 못해 선 요청에 대한 응답시간이 지연되면 이후의 요청들의 시간은 자연스럽게 늦춰진다. 
  • RTT(Rount Trip Time) 증가
    하나의 connection에 하나의 요청을 처리하기 때문에 connection이 발생 할 때마다 3-way-handshaking이 발생한다.
    이때문에 네트워크 지연이 생기게 된다.
  • 무거운 헤더(Header)
    헤더에는 많은 메타정보들이 포함되어있다. 매 요청마다 같은 헤더의 정보들을 담아서 보내줘야 하기 때문에 리소스 낭비가 생긴다. 

데이터보다 훨씬 큰 헤더

위 프로토콜의 단점을 보완해서 나온 프로토콜이 HTTP/2 이다. 

 

2. HTTP/2

Goolge에서 HTTP1.1의 개선으로 SPDY 프로토콜을 구현하였고 이는 HTTP/2의 기초가 된다.

 

  • 바이너리 프레이밍 추가

출처 : https://developers.google.com/web/fundamentals/performance/http2/?hl=ko

HTTP 메시지가 캡슐화되어 헤더와 DATA 프레임으로 전송된다.

기존의 텍스트가 아닌 바이너리로 인코딩되어 전송되기 때문에 처리 속도, 방식에 변화가 생기게되었다.

이때문에 HTTP1.1과 HTTP2는 소통이 안된다... ㅠㅠ

 

  • 스트림, 메시지 및 프레임

출처 : https://developers.google.com/web/fundamentals/performance/http2/?hl=ko

스트림: 연결내에 전달되는 바이트의 양방향 흐름, 하나이상의 메시지가 전달 가능

메시지: 논리적 요청 또는 응답 메시지에 매핑되는 프레임 전체 시퀀스

프레임: HTTP/2에서 통신의 최소 단위, 프레임헤더가 있어 스트림 식별 

스트림안에서 여러 메시지가 돌아다닐수 있으며, 메시지는 하나이상의 프레임으로 이루어져있다. 메시지는 우선순위를 매길 수 있으며, 인터리빙을 이용하여 HOL(Head-of-Line)을 해결할 수 있으며, 한번의 연결로 많은 데이터를 요청, 응답 할 수 있게된다.

HTTP/1.1에서 전송은 수명이 짧고, 많은 양이 만들어지지만 TCP는 한번의 connection으로 대량 전송에 최적화 되어있기때문에 맞디 않은 부분을 HTTP/2에서 스트림이라는 기술로 해결을 한 것이다. 대표적인 예로 gRPC를 이용한 통신 

 

  • 헤더 압축

HTTP/2는 중복되는 헤더의 내용을 압축, 인코딩하여 보낸다.  이를 HPACK 압축이라 한다. 

 

  • server push

클라이언트가 요청하지 않았지만 서버에서 데이터 전송이 필요하다고 판단이 되면 push로 데이터들을 넘겨주는 기능도 있다. 

하나를 달라고하면 열개를 챙겨주는식인가봄

 

 

3. HTTP/3

구글이 쓰고있으니 표준이 될 것인가? -QUIC

현재 구글에서는 현재 HTTP/3(QUIC)를 사용하고있다. 

h3 가 http3

HTTP/3 (QUIC)의 특징

  • UDT를 사용

기존 통신은 보안을 위한 TCP 통신을 기본으로 사용하고 있다. 하지만 TCP는 기본적으로 3-way-hanshake는 필요 하고, 헤더에 정보도 항상 많이 담겨져 있고, 태생으로 자원이 많이 필요하다. 거기에 TLS 암호화를 사용한다면 3-way-hanshake 를 총 3번 해야하는 경우가 발생하기도한다.

 

QUIC

에 대해 잘 설명하고 있는 블로그가 있어서 출처, url을 남기도록 하겠다. 

참고에 도움이 될 것 같다. 

https://evan-moon.github.io/2019/10/08/what-is-http3/

 

 

반응형