# QUIC은 빠른 인터넷에서 충분히 빠르지 않다 > Clean Markdown view of GeekNews topic #16683. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=16683](https://news.hada.io/topic?id=16683) - GeekNews Markdown: [https://news.hada.io/topic/16683.md](https://news.hada.io/topic/16683.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2024-09-10T09:39:07+09:00 - Updated: 2024-09-10T09:39:07+09:00 - Original source: [arxiv.org](https://arxiv.org/pdf/2310.09423) - Points: 13 - Comments: 1 ## Summary QUIC 프로토콜은 웹 애플리케이션 성능 향상에 획기적인 변화를 가져올 것으로 기대되었으나, 고속 네트워크에서 성능이 기대에 미치지 못해 데이터 전송률이 최대 45.2% 감소하는 문제가 있습니다. 다양한 애플리케이션과 네트워크 환경에서 성능 저하가 관찰되었으며, 이는 과도한 데이터 패킷 처리와 사용자 공간 ACK로 인한 수신자 측 오버헤드가 주요 원인으로 밝혀졌습니다. 성능 문제를 완화하기 위해 UDP GRO 도입, QUIC 로직 최적화, 멀티 스레드 다운로드 사용 등 여러 가지 해결책을 제안합니다. ## Topic Body - 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 코어를 활용한 멀티 스레드 다운로드로 수신 성능 향상 가능 - 그러나 공정성 문제 고려해야 함 ## Comments ### Comment 28754 - Author: neo - Created: 2024-09-10T09:39:08+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=41484991) - syscall 인터페이스가 복잡하고, 기본 API가 일반 크기의 패킷(약 1500 바이트)에 비해 너무 느림 - GSO가 도움이 되지만 API가 복잡하고 최근에도 버그가 많음 - Spectre 완화로 인해 syscall 비용이 더 높아졌음 - BSD 소켓/ POSIX API를 대체할 필요가 있음 - uring은 복잡하지만, 중간 수준의 API가 필요함 - 시스템 UDP 버퍼가 기본적으로 너무 작음 - 전문가들만 사용하고 있으며, 전문가들은 설정을 조정함 - UDP 스택 최적화가 가능함 - GSO가 이를 보여주지만, GSO 자체가 비싸고 복잡함 - 현재 사용 가능한 몇 가지 최적화는 저/중간 규모에서만 작동함 - 예를 들어, 경로 조회를 피하기 위해 연결 바인딩 - GSO를 구현하면 성능이 크게 향상될 수 있음 - 플랫폼 측 버퍼 크기를 늘릴 필요가 있을 것임 - QUIC 초기에는 UDP 스택이 TCP 스택보다 최적화가 덜 되어 있었음 - UDP 일반 수신 오프로드 같은 최적화가 필요함 - HTTP/2도 서둘러 출시된 것 같음 - Chrome이 서버 푸시 지원을 제거함 - 더 많은 생각이 필요함 - QUIC와 HTTP/2는 네트워크 대역폭이 낮을 때 유사한 성능을 보임 - 대역폭이 500Mbps를 초과하면 QUIC 성능이 떨어짐 - 이는 주로 로컬 네트워크에서 문제가 됨 - Google이 사용자에게 처리 부담을 전가하는 경향이 있음 - 예를 들어, AV1 비디오 코덱은 소비자가 HW 디코딩 기능이 없을 때 배포됨 - 연구 논문이 arXiv에 있음 - - RTT가 0.23ms인 핑 언급 - 높은 지연 시간에서도 QUIC가 최고임 - RFC9000을 읽는 것이 어렵고 복잡함 - QUIC의 고수준 아이디어는 간단하지만, 사양은 많은 예외 처리를 요구함 - 연구의 무료 PDF 파일 제공 - - 연결 프로토콜을 사용자 공간으로 이동하는 것이 좋은 계획이 아닐 수 있음