▲

GN⁺: 빠른 인터넷에서도 충분히 빠르지 않은 QUIC 기술

 (arxiv.org)
2P by neo 1달전 | favorite | 댓글 1개

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

  • 연구 배경

    • QUIC은 웹 애플리케이션 성능을 향상시키는 데 중요한 역할을 할 것으로 기대됨.
    • 이 논문은 고속 네트워크에서 QUIC의 성능을 체계적으로 조사함.

  • 주요 발견

    • 고속 인터넷에서 UDP+QUIC+HTTP/3 스택은 TCP+TLS+HTTP/2에 비해 데이터 전송 속도가 최대 45.2% 감소함.
    • 기본 대역폭이 증가할수록 QUIC과 HTTP/2 간의 성능 차이가 커짐.
    • 이 문제는 파일 전송뿐만 아니라 비디오 스트리밍(최대 9.8% 비디오 비트레이트 감소) 및 웹 브라우징 등 다양한 애플리케이션에 영향을 미침.

  • 분석 방법

    • 패킷 추적 분석 및 커널 및 사용자 공간 프로파일링을 통해 문제의 근본 원인을 식별함.
    • 수신 측 처리 오버헤드가 높고, 특히 과도한 데이터 패킷과 QUIC의 사용자 공간 ACK가 문제의 원인임.

  • 개선 권장 사항

    • 관찰된 성능 문제를 완화하기 위한 구체적인 권장 사항을 제시함.

GN⁺의 정리

  • 이 논문은 QUIC의 성능 문제를 고속 네트워크 환경에서 분석하여, 웹 애플리케이션 성능 향상에 기여할 수 있는 중요한 인사이트를 제공함.
  • QUIC의 성능 저하 원인을 수신 측 처리 오버헤드로 규명하고, 이를 해결하기 위한 구체적인 방안을 제시함으로써, 네트워크 엔지니어 및 개발자에게 유용한 정보를 제공함.
  • 비슷한 기능을 가진 다른 프로토콜로는 HTTP/2가 있으며, 이와의 성능 비교를 통해 QUIC의 개선 방향을 제시함.
▲
neo 1달전  [-]
Hacker News 의견

  • 산업계는 경량 웹사이트를 만드는 것 외에는 모든 것을 시도하고 있음. 90년대 후반에는 빠른 인터넷 연결이 있다면 페이지가 작고 자바스크립트가 거의 없었음. 오늘날에도 이러한 빠르게 로딩되는 경량 페이지를 찾을 수 있으며, 경험은 거의 초현실적임. 사용자 경험이 더 좋았다면 더 견딜 수 있었을 것임.

  • Google에서 순수 JS Speedtest를 작업했음. 당시 Ookla는 Flash 기반이어서 Chromebooks에서 작동하지 않았음. TCP가 다양한 요소에 어떻게 반응하는지 많이 배웠음. 이 기사를 보고 결과가 예상대로라고 생각함. 왜냐하면 흐름 제어를 커널에서 사용자 공간으로 밀어내기 때문임. TCP는 흐름 제어와 시퀀싱을 가지고 있음. QUIC은 이를 스스로 관리하게 함. TCP 혼잡 제어는 현대 연결 속도와 맞지 않아 BRR과 같은 새로운 알고리즘이 필요하지만 비용이 듦. 가장 큰 교훈은 네트워크 테스트에서 지연 시간의 중요성을 간과하지 말아야 한다는 것임. 아시아나 호주에 사는 사람들은 100ms RTT 지연 시간이 얼마나 치명적인지 알 것임. QUIC의 오버헤드가 실질적으로 중요하지 않을 수 있음. 왜냐하면 단일 TCP 연결이나 QUIC 스트림을 통한 실제 대역폭이 원시 대역폭보다 훨씬 낮을 수 있기 때문임.

  • Curl의 창시자이자 유지보수자인 Daniel Stenberg가 HTTP/3에 대해 블로그에 글을 올렸음. HTTP/3의 높은 CPU 사용률을 강조했으며, CPU가 처리량을 제한할 수 있다고 언급함. 이는 구현의 미성숙함 때문인지, QUIC의 설계 방식 때문인지 궁금함.

  • 빠른 인터넷에서 UDP+QUIC+HTTP/3 스택이 TCP+TLS+HTTP/2에 비해 데이터 전송 속도가 최대 45.2% 감소한다고 함. 아직 논문을 다 읽지는 않았지만, 600 Mbit/s 이하가 "느린 인터넷"으로 간주됨.

  • QUIC은 빠른 인터넷에서 충분히 빠르지 않다고 함. 900mbps 속도를 quic+http3에서 달성했으며, TLS 구현이 나쁜 것인지, 초기 구현이 비효율적인 것인지 의문임. CPU 사용률은 gen 2 epyc 코어에서 평균 5% 정도였음.

  • 여기서 "빠른 인터넷"은 500Mbps이며, quic이 CPU에 의존적이기 때문이라고 함. 테스트 시스템이 기본 소비자 시스템인지 고성능 데스크탑에서도 문제인지 확인하지 않았음.

  • QUIC은 지연 시간에 최적화되어 있다고 생각했음. 웹페이지와 비디오 게임에서 작은 패킷을 많이 로드하는 데 최적화되어 있음. 전체 처리량만 측정할 때는 부족할 수 있음. 프로토콜 수준에서 대용량 파일 전송이나 고대역폭 비디오 스트리밍을 감지하여 덜 CPU 집약적인 것으로 전환할 수 있는지 궁금함. QUIC이 TCP보다 하드웨어/OS 수준에서 최적화가 덜 된 것인지 궁금함.

  • QUIC이 TLS 모드가 없는 것을 바람. 로컬에서 개발할 때 가끔은 전송되는 것을 보고 싶고, 이는 불필요한 마찰을 추가함.

답변달기