QUIC 프로토콜이 느릴 수 밖에 없는 이유

(Last Updated On: February 22, 2020)

기존의 HTTP의 경우 TCP 프로토콜을 사용하여 오류제어 및 재전송, 혼잡제어등으로 안정적으로 데이터를 송・수신 할 수 있지만, 최근에 LAN및 패킷 스위칭과정에 오류가 별로 없고 속도도 빵빵한 환경에서는 이러한 과정이 제성능을 못 내는 원인일 수 있다.

QUIC 프로토콜은 UDP 기반의 프로토콜로서, 패킷을 간단하게 전송하므로 아무튼 빠르다..!! 그런 논리인 것이다.

그러나 실제로 반응속도(latency)는 빠르겠지만 Throughput은 느리다!!

TEST

P2P 환경에서 TCP와 UDP의 성능측정을 해보았다.

1. TCP (receive)

이 테스트에서는 다운로드 속도가 약 460 Mbps 정도 나온다는 것을 알 수 있다.

2. UDP 400 Mbps

TCP에서 각종 제어알고리즘이 작동해서 460 Mbps가 나온다면, UDP로 400 Mbps 정도 보내도 별 탈이 없을 것이다.

그러나 테스트 결과 TCP실험에서 나왔던 460 Mbps는 어디 간곳없이 400 Mbps 치 보냈는데, 받은 데이터그램은 270 Mbps 만 도착했다. 총 31%의 데이터그램 패킷은 대체 어디갔는가?

3. UDP 100Mbps

일반 인터넷 속도인 100 Mbps로 받아보겠다.

100 Mbps 또한, 패킷로스가 15%가량 발생했다.

4. UDP 50 Mbps

50 Mbps는 인터넷 웹서핑할 때 종종 burst 될 수 있는 속도이다.  방금 네이버를 들어가보니까, 3.0 MB 데이터 수신이 발생했다. 그런데 패킷로스가 발생하면 QUIC 프로토콜에서 재전송 프로세스가 일어나지 않겠는가?  당연히 느려지겠다!!!

5. UDP 10 Mbps

10 Mbps 리시브 테스트에서는 패킷손실이 발생하지 않았다. QUIC을 자랑하시는 Google 님의 메인 싸이트에 접속 해 보니, 실제로 1.2MB의 패킷 수신이 발생하였다.
구글이 TCP 놔두고 QUIC을 왜 밀고있는지, 구글의 웹사이트를 보면 알 수 있어보인다.

요약(?)

QUIC 는 빠를 수도 있고 느릴 수도 있다.
UDP 프로토콜은 flood에 취약하기 때문에, ISP단에서 조절되는 것으로 보인다. TLSv1.3 0-RTT 최고