[Network] HTTP/1,2,3(QUIC)

오늘 공부한 HTTP 프로토콜에 대한 기록이다.

개요

HTTP는 HTTP/0.9부터 1, 1.1, 2, 그리고 구글에서 자체적으로 배포한 QUIC프로토콜을 사용한 3까지 꾸준히 발전했다.

이 글은 HTTP/1부터 각 버전에 대한 문제점과 어떻게 이를 해결했는지에 대한 기록이다.

 

먼저, 들어가기 앞서 web에 대한 간단한 설명과 client와 server의 관계에 대해 알아보자.

Web

Web은 여러 객체들로 이루어져 있다.

여기서 객체는 HTML file, image file, JS file 등을 말한다.

Client/Server

Client

말 그대로 고객이다.

client는 server에게 위의 web 객체들을 요청하고, 수신한다.

 

그리고 수신한 객체들을 보여주는 역할을 한다.

Server

server는 client가 요청한 객체들을 응답으로 보내준다.

HTTP/1

HTTP/1부터 HTTP/2까지는 TCP를 사용해 신뢰성을 보장한다.
때문에 데이터의 무결함에 대해서는 문제가 없지만, 속도에 대한 문제로 계속 발전을 거듭한다.

특징

초기 HTTP/1의 특징은 non-persistent이다.

즉, 지속성이 없다. TCP를 사용하기 때문에 3-way-handshake 과정을 거쳐 연결을 한다.

TCP에 대한 설명은 아래의 기록을 참고하자.

[Network] TCP(TCP 설명, 혼잡 제어)

문제점

지속성이 없기 때문에 동일한 과정을 반복해야 한다.

3-way-handshake를 통한 연결, 요청, 응답 과정을 하나의 객체를 받을 때마다 해야 한다는 것이다.

 

문제는 하나의 객체를 받았을 때, 이 객체의 관련 객체도 요청을 보내야 하는데

관련 객체에 관해서도 똑같은 과정을 반복해야 한다는 것이다.

 

예를 들어 html 파일을 요청했다고 가정해보자.

1. 서버와의 3-way-handshake를 통한 연결
2. html 파일 요청
3. 응답
4. server의 연결 해제
5. client는 html 파일을 받고, 해당 페이지의 사진 등의 관련 객체가 필요해짐
6. 각각의 객체에 대한 1~4까지의 과정을 반복

위에서 보는 것처럼 HTTP/1은 매우 비효율적으로 동작하고 있다.

HTTP/1.1

특징

HTTP/1.1은 위의 문제를 해결하기 위해 어느 정도의 Persistent 특성을 가진다.

이에 더해 Pipeline을 사용하여 한 번에 여러 요청을 받고, 여러 응답을 주는 방법을 채택한다.

문제점

연결을 지속함으로써 반복되는 3-way-handshake 과정을 생략했지만,

하나의 객체에 대한 관련 객체를 따로 똑같은 요청-응답 과정을 통해 받는다는 문제점은 해결하지 못했다.

 

이를 HTTP/2에서는 어떻게 해결했을까?

HTTP/2

특징

HTTP/2에서는 HTTP/1.1과 구분되는 2가지의 특성을 가지고,
이를 통해 위의 문제를 해결한다.

1. Multiplexing
   • HTTP/2에서는 하나의 요청에 대해 여러 응답을 보낼 수 있는 Multiplexing 기술을 사용한다.
2. Server Push
   • 하나의 요청에 대한 관련 객체들의 데이터를 함께 주는 Server Push를 사용한다.
   • 위의 예시로 보면, HTML 객체에 대한 요청에 추가 객체 정보를 같이 주는 것이다.

신뢰성
HTTP는 TCP를 사용함으로써 신뢰성을 보장한다고 했는데
여기서 신뢰성은 보안에 관한 문제가 아닌 에러에 대한 재전송 즉, 데이터의 무결함에 대한 신뢰성이다.

보안에 관한 문제는 Application Layer와 Transport Layer 사이의 Session Layer에서 TLS를 이용해 해결한다.

문제점

비록 HTTP/1.1까지의 문제는 해결했지만

근본적으로 TCP의 3-way-handshake 과정을 완전히 없앨 수는 없다.

 

따라서 속도에 대한 문제를 아직도 가지고 있다.

 

HTTP/3

특징

HTTP/3는 기존 HTTP들과 다르게 TCP가 아닌 UDP 기반의 통신을 한다.
UDP 기반의 QUIC(Quick UDP Internet Connection)을 만들어 이를 사용하는 것이다.

비록 UDP에 기반한 통신을 하지만,

데이터의 무결함을 포기할 수 없으므로 UDP 커스터마이징을 통해 이 기능을 구현했다.

 

UDP를 채택한 이유도 커스터마이징에 용이하기 때문이었다.

TCP는 수정이 어려운 프로토콜임에 반해 UDP는 백지 상태나 다름없어 수정하기가 쉽다.

 

Quick은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way-handshake 과정을 거치지 않는다.

TCP와 다르게 Quick은 연결 설정에 필요한 정보와 함께 필요한 데이터도 보낸다.