[Wireshark]QUIC 분석, QUIC vs TCP 속도비교

원본 포스팅: 내 네이버 블로그, 포스팅 날짜 2020-01-14

QUIC(Quick UDP Internet Connection)

구글에서 자체적으로 만들어서 크롬 브라우저에서 사용하는 UDP 기반 전송 프로토콜

​
​

컴퓨터 네트워크를 공부하다 보면, UDP는 TCP의 congestion control에 영향 받지 않기 때문에 TCP에 비해 속도에 대한 장점을 가지며, 따라서 데이터의 realiablity를 조금 버리더라도 빠른 속도가 필요한 멀티미디어/스트리밍 서비스 등에서 사용된다고 배울 것이다.

그러나 실제 멀티미디어/스트리밍 서비스를 와이어샤크로 캡쳐해 보면, UDP도 TCP도 아닌 웬 쌩뚱맞은 프로토콜이 등장한다. 이건 도대체 뭐지?

사용하는 포트는 443인데 UDP로 Encapsulation된 프로토콜이라니???

chromium.org/quic

​

크롬 공식 규격 문서에서 QUIC에 대한 설명을 찾을 수 있었다. 문서를 훑어보니, QUIC은 TCP의 특성상 발생하는 latency(전송 딜레이?)를 줄이기 위해 구글에서 만든 프로토콜이라 한다.

문서에서 설명하는 QUIC의 대표적인 특징들은 다음과 같다.

​

QUIC의 특징

전송 속도 향상

QUIC의 규격 문서 맨 윗줄에 나와있듯이, QUIC은 TCP의 지연 시간을 줄이기 위해 등장했다. 따라서 가장 큰 특징은 빠른 전송 속도에 있다. 이를 위해 QUIC은 UDP 위에서 동작하기 때문에, 이론적으로 RTT가 0이다.

즉, UDP 위에서 동작함으로써 TCP의 3-way handshake 과정, 암호화 통신인 TLS 통신을 위해 거치는 Client hello, Server hello, Certificate, Chiper Spec 등등의 과정이 생략되었기 때문에 Connection을 위한 속도 지연(overhead)를 획기적으로 감소시킬 수 있다.

또한, QUIC은 64비트 Connection ID라는 패킷 식별자(identifier)를 사용하므로 클라이언트와 서버가 한 번이라도 데이터 전송을 수행했다면 심지어 IP주소가 변경되어도 작동할 수 있다고 한다.

보안성 향상

그렇다면 TCP 기반에서 동작하는 암호화 통신인 TLS를 사용하지 않는다면 보안에 문제가 생기진 않을까?

QUIC은 TLS와 동등한 수준의 보안을 제공한다고 한다.

TLS 암호화 방식을 적용하는지 아니면 자체적으로 개발한 암호화 방식을 적용하는지는 (내가 영어를 못해서인지) 찾을 수 없었다. 그러나 서버의 포트가 443 port인 것으로 보아, 암호화 방식을 제공하고 있음은 확실히 알 수 있다.

또한, QUIC은 source address token을 이용해 client 주소를 검증함으로써 spoofing에 의해 출발지 IP가 변조된 것을 알아내고 방어(defense)한다. 이것은 TCP에서 SYN, ACK의 sequence number 교환을 통해 맞는 client인지 검증하는 것과 같은 기능을 한다.
​

Wireshark로 QUIC 분석하기

구글은 크롬으로 들어오는 약 50%의 요청을 QUIC으로 처리한다는 기사가 있다. 그렇다면, 실제로도 그런지Wireshark로 QUIC을 캡쳐해 보자.
​

우선, QUIC은 아직 실험 단계인 프로토콜이기 때문에 좀 더 정확한 패킷 캡쳐를 위해 크롬 실험실에서 QUIC을 Enable 상태로 바꿔준다.
​
속도에 대한 특성 때문에 gaming, multimedia streaming 등에 사용한다고 하니 크롬 브라우저를통해 유튜브에 접속하여 동영상을 재생할 경우를 측정해보았다.

wireshark [statistics - packet length]

크롬 브라우저를 통해 유튜브에 접속하는 전체 과정에서 대부분 QUIC 프로토콜을 사용함을 발견하였다.
​

dns 필터링 [dns contains youtube]

Youtube에 접속하기 위해 도메인 youtube.com을 사용했으므로 dns 필터를 통해 youtube 관련 IP를 찾는다. 이 때, 크롬의 주요 기능인 자동완성(이미 검색한 것은 저장되어 다음에 검색할 때 자동으로 완성되는 기능)을 통해 유튜브에 접속하면 youtube관련 dns가 잡히지 않으므로 꼭 youtube.com으로 검색한다.

Youtube에 관련된 많은 IP 주소가 캡쳐되었다.
​

wireshark [dns에서 얻은 유튜브 ip 주소를 필터링 - statistics - packet length]

일단 Youtube 관련된 IP 주소에서 쓰이는 패킷들이 QUIC임을 확인할 수 있다.
​

ipconfig

터미널에서 ipconfig 명령어를 이용하면 현재 자신이 사용하는 네트워크를 알 수 있다.

현재 내 노트북의 ip주소는 172.16.8.1 이다.

wireshark [statistics - conversation - udp - 특정 c-s 흐름 선택 - Follow stream]

현재 와이어샤크로 [크롬 브라우저 접속 - 유튜브 도메인 입력 - 유튜브 홈에서 한 동영상 재생]한 과정을 캡쳐했기 때문에 동영상 재생에서 가장 많은 패킷이 발생하였을 것이라 짐작하고, 내 노트북 ip(client)으로 가장 많은 패킷을 전송한 서버 주소를 따라가 보자.
​

Follow stream을 눌렀을 때 보이는 한 client - server 간 패킷의 흐름

내 노트북이 203.233.96.18 주소로 요청(빨간색)하면, 203.223.96.18에서 패킷을 보내고 있다(파란색). 요청하는 주소의 이름을 들여다보면 r7---sn-ab02a0nfpgxapox-bh2es.googlevideo.comm인데, 이를 통해 이 주소가 유튜브 플랫폼에 올라와 있는 한 동영상의 서버 주소임을 알 수 있다.
​

유튜브 동영상으로부터 패킷을 얻는 모든 과정은 QUIC 프로토콜을 사용하여 이루어지고 있다.
​

두 번째로 많은 패킷을 주고받은 주소 216.58.200.22의 이름은 i.ytimg.com이다. 위 주소와 통신하기 직전에 dns를 통해 위 주소를 얻어왔으며, 즉시 통신을 시작한 것을 알 수 있다.

ytimg는 유튜브 이미지의 표준이라고 한다.

유튜브에 접속을 시작한 7초대(dns에서 유튜브 도메인 주소 변환을 7.241초에 요청하였다.)부터 i.ytimg.com과 통신하고 있는 것으로 미루어 유튜브에 접속하면 초기 화면(피드)에 떠 있는 많은 동영상의 미리보기 이미지를 얻어오는 과정임을 추측할 수 있다.

QUIC - TCP 속도 비교

이제 QUIC의 가장 큰 장점인 속도 성능을 평가하기 위해 각각 크롬 브라우저(QUIC 사용)와 익스플로러 브라우저(TCP 사용)로 유튜브에 접속해 보았다.

유튜브 접속

1-1. 크롬 유튜브 접속

먼저 크롬 브라우저의 경우, dns로 유튜브 IP를 요청하고(2.934339) 받은 주소로부터 QUIC 프로토콜로 데이터를 받기 시작(2.958152)하기까지0.023813초소요되었다.
​
1-2. 익스플로러 유튜브 접속

익스플로러 브라우저의 경우, dns로 유튜브 IP를 요청하고(12.780423) 받은 주소와 3-way handshake 및 TLS 통신 과정을 거쳐 TLS 프로토콜로 데이터를 받기 시작(12.910182)하기까지0.129759초소요되었다.
​

유튜브 동영상 재생

2-1. 크롬으로 재생

위에서 r7---sn-ab02a0nfpgxapox-bh2es.googlevideo.comm따위의 이름을 갖는 것이 동영상 서버임을 알았다. 가장 많은 패킷을 보낸 주소를 따라가보면

즉, r1---/googlevideo.com의 이름을 갖는 서버가 동영상 서버임을 알 수 있다.

두 번째로 많은 패킷을 보낸 주소 또한 비슷한 이름인 r5---/googlevideo.com의 이름을 갖지만, 이는 4초에 시작해서 6초에 종료된다. 이는 동영상 시작 전 3초짜리 광고의 서버라고 추측하였다.

그러나 광고가 먼저 시작한 후 동영상이 재생되기 때문에, 광고에 대한 패킷을 받고 있는 도중에 동영상에 대한 IP정보를 요청하고 있어서 정확한 시간을 측정하는 데 어려움이 따른다.

따라서 광고 서버의 주소를 요청하고 얻은 주소의 동영상을 재생하는 데 걸리는 시간을 측정하는 것으로 대체했다.

위에서 찾은 유튜브 플랫폼 내의 한 광고 동영상 서버(r1/googlevideo.com)의 주소를 요청하고 응답받은 주소와 QUIC으로 통신하기 시작한다.

4.708021초에 주소를 요청해서, 서버로부터 데이터를 받기 시작한 것이 4.730308초(1392B)로, 동영상 접속까지0.022287초가 걸렸다.
​
2-2. 익스플로러로 재생

같은 방법으로 가장 많은 패킷을 보낸 주소를 따라가 보았을 때, 가장 많은 패킷을 보낸 주소의 이름이 r4---/googlevideo.com임을 알았다.

1.577561초에 동영상 서버의 주소를 요청하고, 해당 IP 주소를 받는다.

동영상 서버의 IP와 통신을 시작하기 전, 3-way handshake 과정 및 TLS 통신 과정을 거쳐, 서버로부터 동영상 패킷(1514B)을 1.780369초부터 받기 시작한다.

동영상에 접속하기까지총 0.202808초소요되었다.
​

결론

단위 : second	Chrome(QUIC 사용)	IE(TCP 사용)
유튜브 접속(도메인 입력~접속)	0.023813	0.129759
동영상 접속(동영상 클릭~재생)	0.022287	0.202808

위 분석 결과를 통해 어떤 웹 사이트를 얻어 올 때와 멀티미디어 동영상을 재생할 때 모두 QUIC을 사용한 크롬 브라우저의 속도가 월등히 빠름을 알 수 있었다.

또한, TCP의 경우 한 패킷의 최대 데이터가 배운대로 1514B인 반면, QUIC 프로토콜의 경우 한 패킷의 최대 데이터가 1392B으로 상당히 짧았는데, 이는 UDP 위에서 동작하는 QUIC 프로토콜이 적은 헤더 크기를 갖기 때문임을 알 수 있다.