TCP/UDP 의 차이를 공부하면서 HTTP 통신은 TCP의 사용예제 중 하나로 생각하고 있었다.
그런데 HTTP 3.0 버전은 UDP기반의 프로토콜로 사용된다는 정보를 들었고, 이전까지 HTTP의 버전별 특징에 대해 알아본 게시글이 없어 이번 기회에 정리해보려 한다.

HTTP

HyperText Transfer Protocol
하이퍼 미디어 문서를 전송하기 위한 애플리케이션 레이어 프로토콜

HTTP 1.0

• 커넥션 하나당 요청 하나와 응답 하나만 처리함
• 매번 요청마다 커넥션 수립 (매번 새로운 연결)
  • TCP 연결과정 한번 진행 시 정보를 주고받고 다시 연결을 해제해야하는 구조이다.
  • 서버에 오버헤드 발생, 시간의 지연

HTTP 1.1

• 전송 계층 프로토콜 TCP를 사용
• http 1.0의 문제를 해결하기 위해 출시
  • TCP 연결 후 필요한 모든 정보를 받은 후 연결을 해제한다.
  • 필요한 모든 정보를 다 보낸 후 차례로 응답하는 파이프라이닝 기법을 도입해 지연을 줄임
• 2.0 출시전까지 약 15년간 주로 사용될 정도로 안정적으로 사용된 만큼 좋은 프로토콜이었다.

단점

1. HOL Blocking(Head Of Line Blocking) 발생
   

• 파이프라이닝 때문에 발생하는 문제로 앞선 요청이 응답이 오래걸리는 요청이면 그 뒤의 요청들도 계속 대기를 해야하는 문제이다.
• TCP는 순서를 보장하기 때문에 앞선 요청에 대한 응답이 완료되면 다음 요청의 응답이 진행된다.

2. 중복 헤더
   

• HTTP 헤더에는 중복되는 자료들이 많은데 두개의 다른 요청이 하나의 정보 말고는 모두 같아도 계속 똑같이 보내준다.

HTTP 2.0

1. 바이너리 프레이밍
   

• HTTP 1.1은 텍스트로 모든 정보를 주고받았지만 2.0에서는 바이너리로 인코딩을 해 처리속도가 빨라졌다.
  
• 바이너리로 프레이밍 된 데이터를 여러개의 프레임으로 쪼개서 멀티플렉싱이 가능해지게 한다.
• A의 응답은 크고(7개) B, C는 상대적으로 작을 때(2개) 쪼개져 있기 때문에 A의 7개를 한번에 보내는 것이 아닌 A -> B -> C -> A -> A -> C -> B 순서로 보내고 클라이언트에서는 미리 B와 C에 대한 응답을 완료하고 미리 처리할 수 있다. 후에 크기가 컸던 응답인 A의 응답이 오면 처리하므로 HOL Blocking 문제를 해결한다.

2. COMPRESSION HEADER (중복헤더 문제 해결)
   

• 내가 어떤 정보를 사전에 보냈는지를 캐싱을 해놓는다. 그래서 필요하고 겹치치 않는 정보만 빼서 전송하게 되어 헤더의 크기가 엄청나게 줄어들었다.
• 또한, 허프만 코딩이라는 방법으로 인코딩을 한 번 더 해서 크기를 줄였다.
• HTTP 1.1에 비해 2.0은 헤더의 크기가 약 85% 로 줄어들었다고 한다.

단점

HTTP 2.0 이 1.1을 완전히 대체하려고 나온 것이 아닌 1.1의 성능을 향상시키자(지연을 줄이자)는 목적으로 나왔다. 하지만 생각보다 지연이 줄어들지 않았다.

1. TCP HOL Blocking
   

• TCP에서도 HTTP에서 발생한 HOL Blocking 문제가 동일하게 발생한다.
  TCP에서 스트림이 멀티플랙싱이 돼서 전송이 진행되는데 중간에 패킷이 손실이 되었을 때 다음 패킷들이 Block 상태가 된다.
  TCP는 신뢰성을 중요하게 여기는 프로토콜이라 손실된 패킷이 재전송될때까지 다음 패킷들도 대기를 한다.

HTTP 3.0

기존의 HTTP/1.x와 HTTP/2와는 다르게 UDP 기반의 프로토콜 QUIC(Quick UDP Internet Connections)를 사용해서 통신
QUID 위에서 동작하는 http를 http/3 이라고 한다.

QUIC

• TCP기반의 HTTP로는 단점들을 해결할 수 없어 구글에서 아예 전송계층 프로토콜을 새로 만들었다.
• UDP 위에서 동작하는 전송계층 프로토콜이다.(UCP 위에 QUIC 위에 HTTP를 올렸다.)

1. 독립 스트림
   

• 요청별로 다른 스트림을 사용하는 방식으로 나눠버려 A 응답이 Block이 되어도 다른 B, C는 영향을 받지 않아 TCP HOL Blocking을 해결한다.

2. RTT(Round Trip Time) 최소화

• QUIC에 TLS를 탑재
  TCP 같은 경우는 TCP 연결 과정이 필요하다.
  현실적으로 HTTP보다 보안성이 더 뛰어난 HTTPS를 더 많이 사용한다.
  HTTPS를 사용하면 TLS 연결과정이 한번 더 필요한데, QUIC에서는 그 TLS를 애초부터 탑재한다.
  게다가 데이터의 본문만 암호화가 되었던 TCP의 TLS와는 다르게 헤더까지 암호화에 포함시킬 수 있어 보안을 더욱 강화시켰다.
  애초부터 TLS가 탑재되었기 때문에 TLS 연결과정이 없어 훨씬 빠르게 된다.

• 클라이언트에 Connection ID 부여
  기존의 TCP는 IP랑 포트번호로 클라이언트와 서버가 서로를 구별한다. 예를들어 인터넷 권역이 바뀌게 된다면 IP와 포트번호가 바뀌게 되고 서버입장에서는 새로운 클라이언트라고 인식하고 다시 TLS 정보를 요청하게 되면서 연결과정을 똑같이 체결하게 된다.

  
  하지만 QUIC는 처음 연결 시 Connection ID를 클라이언트에게 부여를 해준다.
  그렇게 되면 인터넷이 변경이 되어도 Connection ID로 구별되기 때문에 기존에 연결이 되었던 클라이언트라면 신뢰성이 있다고 판단해 연결과정 없이 응답을 주고받을 수 있다.

  
  또한, 한번쓰고 버리는 것이 아닌 클라이언트가 캐싱을 해 다음 요청부터는 연결과정 없이 효율적으로 응답을 주고받을 수 있다.

정리

• HTTP 1.0 은 매 요청마다 TCP 연결은 수행하고 연결을 해제해야함
• HTTP 1.1 은 필요한 모든 정보를 다 보낸 후 차례로 응답하는 파이프라이닝 기법을 도입해 1.0의 단점을 해결함, 하지만 HOL Blocking, 중복 헤더라는 단점이 있음
• HTTP 2.0은 바이너리 프레이밍, COMPRESSION HEADER 로 1.1의 단점을 해결함, 그러나 TCP HOL Blocking이라는 단점이 있음
• HTTP 3.0은 UDP 위에서 동작하는 전송계층 프로토콜인 QUIC를 사용해 통신함, 독립 스트림, TLS 탑재, Connection Id 부여를 통해 매우 효율적인 응답을 주고 받을 수 있도록 함

출처 : https://www.youtube.com/watch?v=Zyv1Sj43ykw
https://velog.io/@sweet_sumin/HTTP-%EB%B2%84%EC%A0%84%EB%B3%84-%EC%B0%A8%EC%9D%B4-1.0-1.1-2.0-3
https://velog.io/@jeongbeom4693/HTTP-HTTP3