[모의 면접 CS 스터디] HTTP/1.1 ~ HTTP/3

1. HTTP/1.1

 

0.9 버전까지 오직 단순한 html 파일을 주고 받는 용도였던 HTTP는 1.0에 이르러 메소드의 종류가 다양화 되고  HTTP 헤더가 추가되었으며 요청할 때 어떤 형태의 파일을 원하는지 명시할 수 있는 content-type을 정의할 수 있게 되었다.

 

하지만 HTTP는 각 한 요청-응답 사이클마다 TCP 커넥션을 연결하고 끊어야 하는 제약이 있었기 때문에 서버 입장에서 부하가 컸고 동시에 클라이언트 입장에서도 응답시간이 느린 문제가 있었다.

 

이러한 문제를 해결하기 위해 등장한 것이 바로 persistent connection과  pipelining이다.

 

 

1)  persistent connection

 

매 요청마다 TCP 연결을 재설정하는 기존 방식과 달리 일정시간 동안 TCP 연결을 계속 유지하면서 재활용하는 persistent connection 방식이 도입되었다.이는 http 헤더에 유저가 Keep-alive 옵션을 통해 몇 초 동안 TCP 연결을 유지할지, 이 연결이 최대 몇 개의 요청을 처리할 지를 정의하여 세밀한 설정이 가능하다. 

 

2) Pipelining

 

기존의 http는 하나의 요청을 보낸 뒤 상대의 응답이 도달한 후에 다시 또 다른 요청을 순차적으로 보내는 모델을 사용하였지만 네트워크 응답시간 지연 등의 문제 때문에 하나의 패킷으로 다수의 요청과 응답을 한꺼번에 처리하는 기법이 도입되었는데, 이를 Pipelining이라고 한다.

 

http/1.1의 문제점

 

Head Of Line blocking

 

1) HOL(Head Of Line blocking)

하지만 pipelining이 도입되고 나서도 여전히 http 요청은 순차적으로 처리되었기 때문에 앞 순서의 처리 시간이 오래 걸리면 그 뒤에 있는 http 요청의 처리도 늦어지는 문제가 있었다.  따라서 이러한 문제를 해결하고자 하나의 클라이언트가 서버와 다수의 TCP 연결을 유지하여 병렬적 처리를 가능하게 했지만 여전히 네트워크 자원이 낭비된다는 단점을 안고 있었다. 

 

2) 헤더 구조의 중복

그리고 다수의 요청과 응답을 주고 받을 때 각 메시지의 헤더 구조가 중복됨에도 여전히 이를 매번 parsing 해야 했기 때문에 불필요한 부분에 throghput을 낭비하는 문제가 있었다.

 

 

2. HTTP/2

 

이러한 1.1 버전의 문제를 해결하고자 HTTP/2 버전에서는 여러 최적화 기법을 사용해 성능 향상을 이루었다.

 

 

1) 바이너리 프레임

 

기존의 HTTP 요청과 응답은 하나의 메시지를 통해 이루어졌는데, HTTP/2에서는 메세지를 바이너리 프레임으로 분할하여 전송하도록 바뀌었다. 즉 HTTP 메시지의 헤더와 데이터를 프레임이라는 단위로 분리한 뒤 바이너리로 인코딩되어 다수의 스트림으로 전송된다. 이러한 인코딩 및 분할 작업은 어플리케이션 레이어 내부에 추가된 바이너리 프레이밍 레이어에서 이루어진다.

2) 다중화 및 커넥션 갯수의 단일화

 

이전에는 병렬적 처리를 위해 다수의 TCP 커넥션을 사용했지만, 그럴 필요 없이 서버와 클라이언트는 하나의 TCP 연결만을 유지하며 TCP 대역폭을 다수의 스트림으로 나누어 처리하여 병렬적인 데이터의 전송이 가능해졌고, 또한 서버입장에서는 커넥션의 갯수가 감소하여 네트워크 대역폭의 낭비를 줄일 수 있었다.

 

 

3) 헤더 압축 및 중복 제거

 

헤더 구조의 중복 문제로 인한 오버헤드를 줄이기 위해 HTTP/2에서는 HPACK이라는 형식을 통해 헤더를 압축하여 전송하는 방식을 채택하였다. 그리고 또한 서버와 클라이언트 모두 이전 요청의 헤더 항목들을 테이블로 저장하여 클라이언트는 이전 요청의 헤더에서 중복되는 항목을 인덱스로 두어요청을 보내고, 서버 측에서는 테이블을 통해 데이터를 조회하여 복원하는 방식을 통해 헤더 구조의 중복 문제를 해결했다. 

 

 

4) 서버 푸시

 

이를테면 클라이언트 측에  서버에 html 문서를 요청할 때 해당 html 내에 명시되어 있는 CSS 파일이나 js 파일은 어차피 필요할 것이다. 서버 푸시란 클라이언트가 명시하지 않아도 서버 측에 미리 사용될 것이라 예측되는 파일을 전송하여 응답시간을 높이는 기법을 말한다.

 

HTTP/2의 문제점

 

HTTP/2는 1.1 버전에 비해서 많은 성능적 개선을 이루어냈다. 하지만 근본적으로 HTTP 통신의 기반이 되는 전송계층의 TCP는 이전의 HTTP가 가지고 있던 HOL 문제를 여전히 안고 있었기 때문에(자세한 내용은 TCP의 흐름제어 기법 대해 찾아보면 나올 것이다.) 근본적으로 병렬적 처리를 이루는데에는 한계가 있었다. 이를테면 하나의 스트림에서 전혀 관련이 없는 데이터들이 있을 때 앞에 있는 데이터의 전송이 지연되거나 유실되면 해당 스트림 내에 뒤에 있는 프레임의 전송은 이루어지지 않았다.

 

   

3. HTTP/3

 

그래서 구글은 TCP를 대체할만한 QUIC이라는 UDP 기반 전송 계층 프로토콜을 개발하여 이러한 문제를 해결하였다.

일반적으로 UDP는 낮은 신뢰성으로 인해 자주 사용되지는 않는다. 하지만 전송 속도가 빠르고 TCP에 비해 제어 정보가 적어서 커스텀할 여지도 많으며 헤더의 크기로 인한 오버헤드가 적다. 그렇기 때문에 패킷 손실의 영향이 적고 레이턴시의 감소가 중요한 게임 개발 쪽에서는 이런 식으로 UDP를 커스텀해서 사용하는 경우도 있다고 한다.

 

HTTP/3는 이러한 QUIC 기반 프로토콜에서 작동하는 HTTP/2라고 할 수 있다. 그렇다면 QUIC은 TCP에 비해 어떠한 점을 개선하였을까?

 

1) TCP, TLS handshake 과정의 간소화

TCP+TLS와 QUIC의 handshake 및 첫 데이터 전송 비교

 

 

일반적으로 대부분의 사이트에서는 HTTP에 TLS라는 암호화 프로토콜을 결합한 HTTPS 프로토콜이 사용된다. 이 때 연결 수립과정에서 TCP handshake 외에도 암호화를 위한 session 키를 교환하는 과정인 TLS handshake도 동반되는데 이 과정에서 3RTT(Round Trip Time, 요청/응답 사이클) 정도 걸린다.

 

QUIC은 이를 단축하여 처음부터 연결 설정에 필요한 데이터를 initial key라는 connection id를 이용한 암호화키로 암호화 하여 서버에게 전송하고 서버는 session키를 응답으로 전달하여 handshake를 1RTT만에 끝낼 수 있다.

게다가 최초 연결이 수립된 이후 다시 연결을 시도 할 때 저장된 connection id를 바탕으로 바로 연결을 수립할 수 있다고 한다.

 

2) 멀티플렉싱 지원

 

QUIC은 멀티 플렉싱을 지원하게 되면서 근본적인 HOL 문제를 해결할 수 있게 되었다. 이제는 각 요청이 별도의 독립된 스트림에서 이루어지기 때문에 하나의 데이터 전송이 다른 요청의 처리 지연에 의해 늦어지는 문제가 사라졌다.

 

3) IP 주소와 별개의 고유한 Connection Id 사용

 

현대에는 스마트폰 사용이 대중화되면서 LTE 데이터를 사용하다가도 Wi-fi를 사용하는 등 서비스를 사용하는 도중에 IP 주소가 변경되는 경우가 매우 잦다. TCP에서는 클라이언트와의 커넥션을 유지하는 데에 사용하는 식별자로 IP를 사용하게 되면 이러한 IP 주소 변경 과정에서 매번 handshake 과정을 거쳐야 하기 때문에 데이터 지연이 발생하게 된다.

 

따라서 QUIC에서는 이를 해결하고자 Connection id라는 것을 사용한다. 이는 마치 암호화 키 교환 과정처럼 첫 연결과정에서 클라이언트가 서버에게 자신의 connection id를 보내고 응답으로 서버의 connection id가 전달되어 이를 통해 서로를 식별하고 연결을 유지한다. 이는 클라이언트와 서버가 계속 가지고 있기 때문에 IP 주소가 바뀌어도 handshake 과정이 발생하지 않는다.

 

 

 

참고자료

HTTP/3는 왜 UDP를 선택한 것일까? | Evans Library

HTTP/2 소개  |  Articles  |  web.dev

[10분 테코톡] 포이의 HTTP1.1, HTTP2, 그리고 QUIC - YouTube

[10분 테코톡] 🧃쿨라임의 HTTP/1.1, HTTP/2, 그리고 QUIC - YouTube

HTTP/1 to HTTP/2 to HTTP/3 - YouTube