본문 바로가기
네트워크

[네트워크] Chap 3.9 - Evolution of transport-layer functionality (QUIC)

by 개발 고양이 2024. 11. 27.

Evolving transport-layer functionality

TCP, UDP는 등장한지 40년이 넘은 오래된 프로토콜이다.

 

Transport layer의 기능들이 진화함에 따라, TCP에서 UDP를 쓰는 Applicatin layer로 넘어가게 되었다.


QUIC: Quick UDP Internet Connections

QUIC은 UDP 위에 있는 application 계층의 프로토콜이다.

HTTP의 성능을 향상시키기 위한 목적으로 등장했다.

(→ 정확히 말하자면 HTTP/2의 한계를 극복하는 것이 목표였다.)

현재 많은 Google server와 app들에 구현되어있다. (ex. Chrome, Youtube 모바일 앱 등)

 

HTTP/2 over TCP

위에서 왼쪽 그림을 보자.

HTTP/2는 loss-sensitive => TCP를 사용한다.

L3에 IP가 있고,

그 위 L4에 TCP가 있고,

그 위에 TLS (sercurity 목적. 여기서는 다루지 않는다)와 HTTP/2가 있다.

 

 

HTTP/2 over QUIC over UDP

오른쪽 그림을 보자.

IP 위에 TCP 대신 UDP가 오게 되었고,

기존에 있던 TLS가 없어졌다. 

=> 아까 TLS는 security 목적이라고 했는데, QUIC이 등장하게 되면서, TCP의 reliable service와 TLS의 sercurity 기능을 QUIC을 통해서 하겠다는 의미라고 이해하면 된다. 

 

간소화시킨 HTTP/2 (slimmed) 와 QUIC을 통합한 것이 HTTP/3이다.

 


 

QUIC은 기존의 TCP에서 사용되던 connection establishment, error control, congestion control 및 네트워크 안정성 기술을 바탕으로 설계되었다. 즉, 데이터를 효율적으로 송수신하기 위해 TCP에서 검증된 기법을 새롭게 최적화하여 UDP 기반의 프로토콜로 구현한 것이라고 보면 된다.

 

Error Control

QUIC은 loss를 감지하고 재전송하는 알고리즘을 사용한다.

TCP의 loss detection 방식(timer, duplicate ACK)과 유사하지만, UDP 위에서 동작하도록 최적화되었다.

 

Congestion Control

QUIC은 네트워크 혼잡 상태를 탐지하고, 전송 속도를 조절하는 알고리즘 사용

TCP의 혼잡 제어 방식(Tahoe, Reno, CUBIC 등)과 비슷함.

하지만 QUIC은 application layer에서 동작하기 때문에 더 유연하게 설계 가능

 

Connection establishment:

reliablity, congestion control, authentication, encryption, state establised 등이 한 번의 RTT(Round Trip Time) 안에 설정되었다.

 

 

single QUIC connection에는 multiple한 applicaion-level "stream" 이 multiplex된다.

즉 하나의 QUIC connection에는 하나의 UDP socket이 있는데, 그 socket을 통해 여러 stream들을 처리할 수 있다.

TCP를 사용하는 HTTP/2는 pakcet loss가 발생했을 때 pipelining이 crash되어 데이터를 더이상 보낼 수 없게 된다.

하지만 UDP를 사용하는 QUIC을 쓰게 되면, 여러 stream들을 처리할 수 있기 때문에 한군데가 망가진다고 해도 다른 stream으로 보내는 것이 가능하다!

- Reliable Data transfer (rdt)와 Security를 분리시켰다.

- 그러나, TCP와 마찬가지로 congestion control은 여전히 존재한다.


QUIC: Connection establishment

TCP

TCP는 2 serial handshakes (= 3-way handshake) 방식을 사용하였다. 

1 RTT에서 TCP handshake를 하고

2 RTT에서 TLS handshake를 한다.

(TCP는 기본적으로 암호화되거나 인증되어있지 않으므로, 별도의 TLS handshake 과정을 거쳐야 한다.)

 

=> 2 RTT가 지나야 데이터 전송이 가능하다.

 


QUIC

QUIC은 1 handshake을 사용해도 충분하다!

QUIC은 TCP에서 필요했던 암호화 과정, 즉 TLS handshake 과정을 거칠 필요가 없다.

UDP를 사용하기 때문에, 한번에 TCP연결할때 필요했던 데이터와 암호화 관련 데이터까지 보낼 수 있다. 

 

=> 1 RTT만 지나도 데이터 전송이 가능하다!