▲

QUIC은 빠른 인터넷에서 충분히 빠르지 않다

 (arxiv.org)
13P by GN⁺ | ★ favorite | 댓글 1개
  • 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 코어를 활용한 멀티 스레드 다운로드로 수신 성능 향상 가능
    • 그러나 공정성 문제 고려해야 함
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견
  • 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 파일 제공
  • 연결 프로토콜을 사용자 공간으로 이동하는 것이 좋은 계획이 아닐 수 있음
답변달기