- QUIC은 웹 애플리케이션 성능 향상에 획기적인 변화를 가져올 것으로 기대되는 프로토콜이지만, 성능이 기대에 못 미침
- 이 논문에서는 고속 네트워크에서 QUIC의 성능을 체계적으로 분석함
초록
- 고속 인터넷에서 UDP+QUIC+HTTP/3 스택은 TCP+TLS+HTTP/2에 비해 최대 45.2%의 데이터 전송률 감소를 보임
- QUIC과 HTTP/2 간 성능 격차는 기본 대역폭이 증가할수록 커짐
- 이 문제는 경량 데이터 전송 클라이언트와 주요 웹 브라우저(Chrome, Edge, Firefox, Opera), 다양한 호스트(데스크톱, 모바일), 다양한 네트워크(유선 브로드밴드, 셀룰러)에서 관찰됨
- 파일 전송뿐 아니라 비디오 스트리밍(최대 9.8% 비디오 비트레이트 감소), 웹 브라우징 등 다양한 애플리케이션에 영향을 미침
- 엄격한 패킷 추적 분석과 커널 및 사용자 공간 프로파일링을 통해 근본 원인을 확인함
- 특히 과도한 데이터 패킷과 QUIC의 사용자 공간 ACK로 인한 수신자 측 처리 오버헤드가 높음
- 관찰된 성능 문제를 완화하기 위한 구체적인 권장 사항을 제시함
성능 저하의 근본 원인
- 수신자 측 커널 수준에서 과도한 패킷 처리 오버헤드 발생
- QUIC은 UDP GRO(Generic Receive Offload)를 사용하지 않아 TCP에 비해 훨씬 더 많은 패킷을 처리해야 함
- 이는 netif_receive_skb 함수 호출 횟수가 QUIC에서 훨씬 많은 것으로 확인됨
- 사용자 공간에서도 QUIC의 과도한 패킷 처리 오버헤드 발생
- 커널에서 전달된 많은 수의 패킷들을 처리하는 데 오버헤드가 큼
- QUIC ACK를 사용자 공간에서 생성하는 것도 오버헤드의 원인
성능 저하 완화를 위한 제안
- 수신자 측에서 UDP GRO 도입
- UDP 스택에서 처리해야 할 패킷 수를 줄여 커널 및 사용자 공간 오버헤드 감소
- 그러나 다양한 클라이언트 환경에서 UDP GRO 배포하는 것은 쉽지 않을 수 있음
- GSO/GRO와 같은 오프로딩 솔루션을 QUIC에 맞게 개선
- 서로 다른 크기의 UDP 패킷 트레인도 오프로딩할 수 있도록 지원
- GSO에 적절한 페이싱 설정 추가하여 네트워크 혼잡 방지
- 수신자 측 QUIC 로직 최적화
- QUIC ACK 전송을 지연시켜 응답 생성 오버헤드 감소
- recvmmsg를 사용하여 한 번에 여러 UDP 패킷을 읽어 성능 개선
- 멀티 스레드 다운로드 사용
- 대용량 파일의 경우 여러 CPU 코어를 활용한 멀티 스레드 다운로드로 수신 성능 향상 가능
- 그러나 공정성 문제 고려해야 함