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

 (arxiv.org)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 고속 유선망, WiFi 6/7, 5G처럼 연결당 500Mbps~1Gbps 이상이 가능한 환경에서 UDP+QUIC+HTTP/3 스택은 TCP+TLS+HTTP/2보다 최대 45.2% 낮은 데이터 전송률을 보임
  • 단순 파일 다운로드를 넘어 Chrome, Edge, Firefox, Opera와 데스크톱·모바일 환경에서 대역폭이 높아질수록 QUIC와 HTTP/2의 성능 격차가 커짐
  • 패킷 추적과 커널·사용자 공간 프로파일링 결과, 병목은 송신 측보다 수신 측 처리 오버헤드에 가까우며 QUIC 수신 시 더 많은 패킷과 사용자 공간 ACK 처리가 발생함
  • 애플리케이션 영향은 DASH 비디오의 최대 9.8% 비트레이트 감소, 100개 대표 웹사이트 평균 3.0% 긴 페이지 로드 시간으로 이어짐
  • 완화에는 수신 측 UDP GRO 배포, GSO/GRO의 QUIC 친화적 개선, 수신 로직 개선, 여러 CPU 코어 활용이 필요하지만 클라이언트 기기와 OS의 다양성이 실현을 어렵게 함

고속 네트워크에서 드러난 QUIC 성능 격차

  • QUIC는 UDP 위의 다중화 전송 계층 프로토콜이며, HTTP/3의 전송 기반으로 IETF 표준화됨
  • Google, Akamai, Meta, Cloudflare 등 여러 회사가 2013년 이후 QUIC를 상용 배포해 왔고, HTTP/3와 함께 웹 성능을 바꿀 후보로 주목받아 왔음
  • 기존 QUIC 성능 연구는 구현체, 컴퓨팅 환경, 네트워크 조건이 다양했고, 다수는 저처리량 사용 사례에 집중함
  • 측정의 초점은 고속 유선 링크, WiFi 6/7, 5G처럼 연결당 500Mbps 이상 또는 1Gbps 이상에 도달하는 고속 네트워크에서의 QUIC 동작임
  • 비교 대상은 단일 프로토콜이 아니라 전체 스택임
    • QUIC 쪽: UDP+QUIC+HTTP/3
    • 기존 쪽: TCP+TLS+HTTP/2
    • 요약상 각각 QUIC와 HTTP/2로 부름

파일 다운로드 실험에서 확인된 차이

  • cURL과 Chromium 기반 quic_client를 사용한 단순 파일 다운로드 실험에서, 혼잡 제어 알고리듬, 서버 구성, 네트워크 조건을 맞춰 비교함
  • 대역폭이 비교적 낮은 약 600Mbps 미만에서는 QUIC와 HTTP/2 성능이 비슷했지만, 더 높은 대역폭에서는 QUIC 처리량이 HTTP/2보다 최대 15.7% 낮음
  • 대역폭이 커질수록 성능 격차가 더 뚜렷해졌고, 패킷 수신 중 QUIC가 최신 클라이언트 호스트에서 HTTP/2보다 훨씬 높은 CPU 사용량을 보임
  • 주요 브라우저 실험에서는 격차가 더 커짐
    • 대상 브라우저는 Chrome, Edge, Firefox, Opera
    • Chrome에서는 대역폭이 약 500Mbps를 넘으면 QUIC가 뒤처지기 시작함
    • 대역폭이 1Gbps에 도달하면 QUIC가 HTTP/2보다 45.2% 느려짐
    • 모바일처럼 더 약한 클라이언트에서는 격차가 더 커짐

웹 애플리케이션에서의 영향

  • 성능 저하는 대량 파일 전송에만 한정되지 않고, 간헐적 트래픽 패턴을 가진 애플리케이션에서도 나타남
  • DASH 비디오 청크를 고속 Ethernet과 5G에서 전달할 때 QUIC는 HTTP/2 대비 최대 9.8% 낮은 비디오 비트레이트를 보임
  • 이 QoE 저하는 기반 대역폭이 충분히 높을 때만 드러남
    • 4G에서는 영향이 가려짐
    • 5G에서는 영향이 나타남
  • 웹 브라우징 실험에서는 100개 대표 웹사이트 평균 기준 QUIC의 페이지 로드 시간(PLT) 이 HTTP/2보다 3.0% 길어짐
  • 긴 꼬리에서는 페이지 로드 시간 격차가 50%를 넘는 사례도 있음

병목 원인: 수신 측 처리와 사용자 공간 ACK

  • 패킷 추적과 성능 데이터를 보면 QUIC 클라이언트는 HTTP/2 다운로드 때보다 훨씬 많은 패킷을 수신함
  • QUIC가 높은 데이터 전송률로 수신할 때 들어오는 데이터 패킷과 대응하는 ACK 패킷 사이의 지연이 커져, QUIC 패킷 처리 시간이 늘어남
  • 두 관찰은 고속 인터넷에서 QUIC 성능 저하의 원인이 수신 측 처리 능력 한계에 있음을 가리킴
  • 수신 측이 병목으로 지목되는 이유는 두 가지임
    • 서버는 일반적으로 데스크톱, 노트북, 스마트폰 같은 클라이언트보다 강력함
    • QUIC 설계상 데이터 수신 처리에는 고유한 어려움이 있음
  • 깊은 프로파일링에서 두 가지 주요 원인이 확인됨
    • 과도한 데이터 패킷
      • 같은 파일을 다운로드할 때 커널 내부 UDP 스택은 TCP보다 훨씬 많은 netif_receive_skb 패킷 읽기를 발생시킴
      • 조사한 QUIC 구현체 중 어느 것도 UDP generic receive offload, 즉 UDP GRO를 사용하지 않음
      • UDP GRO는 링크 계층 모듈이 여러 수신 UDP 데이터그램을 전송 계층으로 넘기기 전에 하나의 큰 데이터그램으로 합치는 방식임
      • 이는 TCP segmentation offload가 널리 배포되고 UDP 송신 측 오프로딩인 GSO가 최근 강조되는 상황과 대비됨
    • 사용자 공간 ACK 처리
      • 사용자 공간에서 QUIC는 수신 패킷 처리와 응답 생성에 더 높은 오버헤드를 가짐
      • 원인에는 커널에서 넘어오는 과도한 패킷, QUIC ACK의 사용자 공간 처리, QUIC의 delayed ACK 같은 일부 최적화 부재가 포함됨

예비 측정과 완화 방향

  • Chrome 브라우저에서 1GB 파일을 다운로드한 예비 실험은 QUIC 활성화 시 다운로드 시간이 대략 두 배로 늘어나는 모습을 보임
  • 표본 결과는 10회 실행 평균임
    • 데스크톱 Ethernet: HTTP/2 9.32초, HTTP/3 18.60초로 99% 증가, CPU 사용량은 77.5%에서 96.9%로 증가
    • Pixel 5 low-band 5G: HTTP/2 37.11초, HTTP/3 78.65초로 112% 증가, CPU 사용량은 121.55%에서 161.77%로 증가
    • Pixel 5 mmWave 5G: HTTP/2 30.10초, HTTP/3 63.20초로 110% 증가, CPU 사용량은 128.43%에서 165.20%로 증가
  • 데스크톱 CPU 사용량은 브라우저 네트워크 서비스 기준이고, 스마트폰 측정은 전체 브라우저 프로세스 기준임
  • CPU 사용량이 100%를 넘는 값은 멀티코어 시스템에서 브라우저 프로세스가 하나 이상의 코어를 사용했다는 뜻임
  • 제안된 완화책은 수신 측 UDP GRO 배포, GSO와 GRO의 QUIC 친화적 개선, 수신 측 QUIC 로직 개선, 여러 CPU 코어를 통한 QUIC 데이터 수신임
  • 클라이언트 호스트는 PC, 모바일 기기, 임베디드 기기와 다양한 OS로 구성되어 서버보다 이질성이 크기 때문에, 완화책 실현에는 실무적 어려움이 있음
  • 측정 데이터와 소스 코드는 해당 연구와 함께 공개됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 업계는 가벼운 사이트를 만드는 것만 빼고는 뭐든 하려는 듯함
    90년대 후반에도 빠른 회선만 있으면 인터넷은 즉각적이었고, 페이지는 작았으며 JavaScript도 거의 없었음
    지금도 그런 빠른 경량 페이지를 찾을 수 있는데, 마우스 버튼을 떼기도 전에 페이지가 다 로드된 것처럼 느껴져 거의 초현실적임
    사용자 경험이라도 좋아졌다면 참을 만했겠지만, 그것도 얻지 못함

    • 지금 작업 중인 프로젝트의 React 앱에서 JavaScript를 걷어내는 중인데 아주 즐거움
      더 빠르고 훨씬 견고해졌고, 프런트엔드와 백엔드 사이의 상태 불일치도 사라짐
      편의를 위해 최소한의 JavaScript는 인정하고 있으며 현재 몇백 줄 정도이고, 여전히 단일 페이지 앱처럼 보이게 약간 더 추가할 예정임
      이렇게 해서 React 약 4만 줄과 Kotlin 약 2만 줄을 없앨 수 있지만, 백엔드 코드는 약 3만 줄 다시 써야 함
      그래도 마음에 듦
    • 대학을 마칠 무렵 프레임워크 기반 웹 개발 유행을 그대로 믿었고, “엔터프라이즈” 웹 개발은 그렇게 해야 한다고 생각했음
      그래서 내 홈페이지를 정적 VUE.JS 버전으로 옮겨 보며 경험을 쌓았는데, 변수 이름을 문자열로 넘겨 뷰와 상태를 묶는 방식은 이상했고, 빌드 환경 확장은 불필요하게 복잡했으며, 모든 것이 느리고 특정 방식으로만 해야 했음
      모두가 쓰니 맞겠거니 했지만, 이제는 그 관점을 벗어났고 새 버전은 원시 HTML과 정적 사이트 생성기 템플릿으로 끝냈음
      HTML 크기는 90% 줄고, JS 사용량은 97% 줄었으며, 빌드 시간은 20초에서 2초가 됨
      사용자 경험도 좋아졌고 새 버전 이후 방문도 30% 늘었음
      웹을 덜 쓰면 웹은 훨씬 멋질 수 있음
    • 가벼운 사이트는 화려한 이력서가 되지 못함
      백엔드에서도 요즘 황금알은 API로 연결되는 headless SaaS 제품을 통해 마이크로서비스를 파는 것이고, 성능은 당연히 좋아질 거라는 식임
      https://macharchitecture.com/
      사람들이 그런 삽을 사려 한다면 우리도 그런 삽을 쌓아둘 수밖에 없는 것이 IT 세상임
    • 개인 프로젝트는 전부 서버 렌더링 HTML로 만듦
      블로그는 정적으로 렌더링되는 Hugo 사이트라 JS가 전혀 없고, 프로젝트는 Rails와 서버 렌더링 HTML 기반이며 있으면 좋은 기능만 더하는 최소한의 JS만 있음
      JS가 없어도 동작함
      내 사이트라서 하는 말일 수도 있지만, 웹 대부분보다 경험이 훨씬 낫고 우리는 너무 많은 것을 잃었음
    • 오늘날 거의 즉시 뜨는 웹페이지 예시: https://www.mcmaster.com/

  • Google에서 순수 JS 기반 Speedtest를 만든 적이 있음
    당시 Ookla는 아직 Flash 기반이라 Chromebook에서 작동하지 않았고, 설치 담당자가 설치 상태를 검증하는 데 문제가 됐음
    그 과정에서 TCP가 여러 요인에 어떻게 반응하는지 많이 배웠음
    이 글의 결과는 거의 예상대로인데, 흐름 제어를 커널과 어쩌면 네트워크 어댑터에서 사용자 공간으로 밀어냈기 때문임
    TCP에는 흐름 제어와 순서 보장이 있고, QUIC은 그것을 직접 관리하게 만드는 셈임
    물론 그럴 좋은 이유도 있음
    TCP 혼잡 제어는 현대적인 연결 속도에 뒤처진 것으로 유명하고 BBR 같은 새 알고리즘도 나왔지만 비용이 따름 [1]
    네트워크 테스트나 웹 애플리케이션 테스트에서 너무 자주 빠지는 핵심은 지연 시간임
    아시아나 호주에 사는 사람이라면 100ms 왕복 지연이 얼마나 치명적인지 알 것임
    완전히 반응성 있던 것을 전혀 못 쓸 정도로 만들 수 있고, 윈도우 때문에 연결이 지원할 수 있는 대역폭을 낮추며 오류와 혼잡 제어에도 둔하게 만듦
    네트워크나 웹 앱을 테스트한다면 무작위로 지연 시간에 100ms를 추가하는 테스트를 강력히 권함 [2]
    그래서 QUIC의 오버헤드는 실제로 중요하지 않을 수도 있음
    단일 TCP 연결 또는 QUIC 스트림에서의 유효 대역폭은 실제 원시 대역폭보다 훨씬 낮을 수 있기 때문임
    달리 말하면 45% 추가 데이터가 있어도, 직접 혼잡 제어를 관리함으로써 두 지점 사이의 유효 속도가 더 높아진다면 이득일 수 있음
    [1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
    [2]: https://bencane.com/simulating-network-latency-for-testing-i...

    • 내 파일 전송 앱[1]으로 실제 환경 테스트를 많이 했고, 처음에는 QUIC이 굉장할 것이라 기대했지만 여러 이유로 좌절하고 TCP로 돌아갔음
      뒤돌아보면 당연하지만 TCP에서는 “커널아 이 거대한 버퍼 좀 보내줘”라고 하면 되는 반면, UDP는 패킷 교환 방식이라 0을 보내는 것조차 대부분의 운영체제와 소비자용 하드웨어에서 모드 전환 때문에 CPU 비용이 큼
      우회 방법은 있지만 쉽지도 않고 내 경험상 준비도 덜 됐으며, 사용할 언어·라이브러리·플랫폼 선택도 제한함
      덤으로 MacBook을 배터리로 쓸 때 처리량이 크게 떨어지는 것을 봤는데, 아마 효율 코어와 관련 있어 보임
      둘째, QUIC은 혼잡 제어를 잘 못했음
      quic-go를 썼으니 환경마다 다를 수 있지만, 어떤 튜닝도 크게 도움이 되지 않았고 TCP 스트림과 함께 있으면 TCP가 더 많은 대역폭을 가져갔음
      셋째, API가 이상함
      QUIC 자체는 여러 스트림을 갖기 때문에 TCP의 그대로 끼워 넣는 대체품이 아님
      다만 HTTP/3를 더 높은 계층에서 끼워 넣는 대체품으로 만들려는 의도인데, 그건 해보지 않아서 말할 수 없음
      스트림 수준에서 작업한다면 염두에 둘 만함
      결론적으로 꽤 패배한 기분이었지만, 동시에 오래된 친구 TCP의 최적화와 복원력에 새삼 존경심이 생김
      정말 놀라운 기술이고, 운영체제가 항상 무료로 제공해 줌
      TCP의 주요 문제 중 일부도 설계 결함이라기보다 보수적이거나 레거시 기본값 때문임
      Linux의 버퍼 제한, Nagle 같은 것들임
      바퀴를 다시 발명하기보다 그냥 TCP를 개선할 수 있으면 좋겠음
      [1]: https://payload.app/
    • “흐름 제어를 커널과 네트워크 어댑터에서 사용자 공간으로 밀어냈기 때문”이라는 건 QUIC 프로토콜의 본질적 속성은 아니고 구현 결정일 뿐임
      QUIC이 출발하려면 꼭 필요했던 결정이지만, 이제 존재하게 됐으니 다시 검토할 수도 있음
      QUIC을 커널에서 구현하는 데 기술적 장애물은 없고, 성능 이점이 크다면 누군가는 조만간 거의 확실히 할 것임
    • 중국에서 중국 밖 서버까지의 지연 시간이 종종 300ms를 넘는 입장에서는 QUIC을 강하게 지지함
      차이가 하늘과 땅임
    • Chrome 개발자 도구의 Network 탭에서 연결 품질을 낮출 수 있음
      Slow/Fast 4G, 3G 프리셋이 있고, 직접 다운로드·업로드 속도, ms 단위 지연 시간, 패킷 손실률, 패킷 큐 길이를 지정하고 패킷 재정렬도 켤 수 있는 사용자 지정 프리셋을 만들 수 있음
    • 사용자 공간이 느리다는 전제가 깔려 있지만, 가장 빠른 고성능 TCP/IP 스택 중 일부 또는 대부분은 사용자 공간에서 만들어짐

  • curl 제작자이자 유지관리자인 Daniel Stenberg가 몇 달 전 curl의 HTTP/3에 대해 쓴 글이 있음: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
    그가 강조한 것 중 하나는 HTTP/3의 더 높은 CPU 사용률이고, CPU가 처리량을 제한할 정도였음
    이 중 얼마나 구현의 미성숙 때문이고, 얼마나 QUIC 설계 자체의 속성인지 궁금함

    • 권고 중 두 가지는 수신 측 구현 개선, 즉 최적화와 다중 스레드화를 말하고 있어서 구현이 아직 미성숙하다는 신호로 보임
      세 번째 권고는 UDP GRO인데, 수신 UDP 패킷을 묶어 패킷별 작업을 줄이고 그룹별 작업으로 바꾸도록 커널, 이상적으로는 NIC 하드웨어를 수정하는 것임
      TCP에는 이미 있고 송신 측에도 TSO, Linux의 GSO 같은 비슷한 것이 있음
      이것도 미성숙처럼 느껴지지만 하드웨어 기능 부족 가능성을 생각하면 고치기 더 어려울 수 있음
      초록은 QUIC의 ACK 방식 비용을 말하지만 그 주장은 자세히 보지 않았음
      현대 TCP 기반 서버에서 볼 수 있는 또 다른 기능은 TLS를 하드웨어로 오프로딩하는 것임
      동시에 많은 TCP 스트림을 보내는 서버에서는 더 중요해 보임
      Linux에서는 사용자 공간 네트워킹을 쓰거나 ‘kernel tls’를 통해 가능하고, 가능하면 하드웨어로 오프로딩됨
      이 기능은 TCP 스트림을 ‘메시지’로 쪼개 다른 스레드로 보낼 수 있게 하는 Linux의 특이한 기능과도 관련 있는데, 앞선 패킷이 손실됐을 때 뒤쪽 메시지를 미리 넘길 수 있는지는 모르겠음
    • QUIC은 안정적이거나 빠르다고 보장되지 않는 연결, 예컨대 모바일 네트워크를 위해 설계됐다고 늘 이해해 왔음
      모든 연결을 더 빠르게 만들려는 의도였다는 인상은 받지 못했음
      그런 관점에서 보면 절충이 말이 됨
      전문가는 아니니 더 잘 아는 사람이 바로잡아 주길 바람
    • 여기서 “구현의 미성숙”이라는 표현은 재미있음
      QUIC은 인터넷 곳곳의 모든 하드웨어, 미들웨어 포함, 가 새 TCP나 TLS 표준을 지원하게 만들 방법이 전혀 없기 때문에 만들어졌음
      그래서 QUIC은 UDP 위에서 새 전송 표준을 레거시 인터넷 하드웨어 위에 올리는 우아한 해법임
      이상적인 세계라면 새 TCP와 TLS 표준을 만들고 전 세계 모든 인터넷 라우터와 하드웨어를 교체하거나 업데이트해서 더 낮은 CPU 사용률로 구현했을 것임
    • 그 성능 결과는 나도 놀랐음
      테스트에서 CPU에 묶인 quiche는 200MB/s 미만이고 nghttp2는 900MB/s를 넘었음
      CPU가 스로틀링됐는지 궁금함
      HTTP/3 구현이 CPU를 4배 쓴다면 흥미롭지만, 절대값이 애초에 매우 낮았다면 꼭 큰 문제는 아닐 수 있음

  • “빠른 인터넷에서 UDP+QUIC+HTTP/3 스택은 TCP+TLS+HTTP/2 대비 데이터 속도가 최대 45.2% 감소한다”는 부분이 핵심인데, 아직 논문 전체는 읽지 않았지만 서론에서는 600Mbit/s 미만을 느린 인터넷으로 보는 듯함

    • 달리 말하면 클라이언트 브라우저 <> 에지 구간에는 HTTP/3 + QUIC을 켜고, 에지 <> 원본 구간은 HTTP/2나 HTTP/1로 제한하라는 뜻임
      Cloudflare를 예로 들면 클라이언트 <> 에지 사이에서만 QUIC을 지원하고 원본 연결에는 지원하지 않음
      에지 <> 원본 연결이 재사용 가능하고 안정적이며 “빠르다”면 말이 됨
      https://developers.cloudflare.com/speed/optimization/protoco...
    • 그만큼 중요한 부분은 원인이 높은 수신 측 처리 오버헤드, 특히 과도한 데이터 패킷과 QUIC의 사용자 공간 ACK라는 점임
      프로토콜 자체에 근본적인 문제가 있는 것처럼 들리진 않음
    • 주로 브라우저 구현에서 비효율적이거나 너무 많은 시스템 호출 때문에 생기는 지연 시간 문제로 처리량 감소가 나타난 것으로 봄
      하지만 이런 지연 문제는 CPU를 부스트하게 만드는 CPU 사용 문제와 달리 배터리 사용량을 크게 늘리지는 않음
      서버 간 통신에서도 문제가 아님
      기본적으로 최종 사용자 기기에서, 2024년 기준으로도 매우 빠른 연결을 쓸 때 고대역폭 전송이 “느려지는” 정도임
      여기서 말하는 속도는 광고로 산 속도가 아니라 실제 기기에서 서버까지의 유효 속도 기준임
      논문이 쓸모없다는 뜻은 아니고, 브라우저 구현은 개선되어야 하며 그 점을 잘 보여줌
      다만 논문 제목은 거의 100% 클릭베이트임
    • 인터넷 접속은 앞으로 더 빨라질 수밖에 없음
      기가비트 인터넷이 확산되는 시점에 더 느린 전송 방식으로 바꾸는 건 명백히 실수임
    • 스위스에서는 월 60달러에 25Gbit/s를 쓸 수 있음
      30년 뒤에는 더 빨라질 텐데, 회선 속도를 다 쓰려고 더 오래된 프로토콜을 써야 한다면 어리석은 일임

  • 9월에도 같은 글이 올라왔음: QUIC is not quick enough over fast internet (acm.org)
    https://news.ycombinator.com/item?id=41484991 (댓글 327개)

    • 개인적으로는 Google이 Chromium을 통해 인터넷 프로토콜 사용을 사실상 일방적으로 설계·강제하게 둬서는 안 된다는 결론이었음
      Brave/Vivaldi/Opera 등은 의식적으로 선택해야 함
    • QUIC은 광고 회사가 소비자에게 광고 전달을 보장하려는 것에 관한 기술임
      광고만 빨리 도착하면 나머지는 중요하지 않다는 식임

  • 이건 정말 많이 이상하게 들림
    QUIC+HTTP/3만으로도, 그냥 QUIC만으로도 900mbps 속도를 달성한 적이 있음
    나쁜 TLS 구현이거나 효율적이지 않은 초기 구현 같음
    CPU 사용률은 2세대 EPYC 코어에서 약 5% 정도로 꽤 평균적이었음

    • 사실 잘 알려진 일인데, 브라우저의 현재 QUIC 구현은 안정적이지 않고 rustls 기반이거나 비슷하게 땜질한 방식으로 만들어져 있음

  • 일화로, wordpress.org 접속에 문제가 있었음
    Wordpress를 처음 쓸 때는 문서를 잘 볼 수 있었는데 어느 순간 웹사이트에 전혀 접속할 수 없게 됨
    Linux와 듀얼 부팅을 하니 Windows 문제도 아니었고, ping은 잘 됐으며, 브라우저 세 개를 바꿔도 같았음
    사이트에 들어가면 멈춘 채 전혀 로드되지 않거나, 가끔 페이지가 중간에 로드를 멈췄음
    오늘 해결책을 찾았는데 Chrome 설정에서 Experimental QUIC Protocol을 끄는 것이었음
    몇 달 동안 wordpress.org에 접속 문제가 있었는데, 이것이 QUIC 때문이라는 표시가 전혀 없어서 걱정됨
    개발자 도구에 QUIC 관련 오류가 가끔만 나타난 덕분에 겨우 알아챘음
    이 프로토콜 때문에 접근 불가능해졌는데 사용자들은 원인을 모르는 웹사이트가 또 얼마나 있을지 궁금함

  • 여기서 빠른 인터넷은 500Mbps이고, 이유는 QUIC이 그 이상에서 CPU에 묶이는 것처럼 보이기 때문임
    테스트 시스템이 일반 소비자용인지, 고성능 데스크톱에서도 여전히 문제인지 확인할 만큼 자세히 보지는 않았음

  • 웃긴 건 우리가 자세한 내용은 잘 모르면서도 빠르다 = 좋다는 이유로 “QUIC이 새 HTTP/2” 같은 생각을 암묵적으로 받아들인다는 점임
    새 5G 휴대폰이 4G보다 몇 배 빠르다니까 사는 것과 비슷함
    정작 1) 내 4G 휴대폰은 한 번도 4G 최대 속도로 동작한 적이 없고, 2) 연결 문제는 거의 항상 인터넷 회선 속도 때문이 아니라 DNS 서버, 대상 웹사이트, 통신사 쪽 연결 다중화 장비가 말썽인 경우임
    그래도 “하지만 5G잖아”가 됨
    “광섬유 broadband” 광고에서 사람들이 TV를 보며 머리카락이 바람에 날리는 것처럼 연출하는 것도 웃김
    실제로 그런 식으로 작동하지 않음
    예전에는 8Mb 연결로도 스트리밍했으니 300Mb가 어떤 일에는 좋겠지만, 큰 차이를 체감할지는 의문임

  • QUIC에 비-TLS 모드가 있었으면 좋겠음
    로컬 개발 중에는 때때로 선 위로 무엇이 오가는지 그냥 보고 싶을 뿐인데, 이게 불필요한 마찰을 많이 추가함

    • 서버의 개인 키를 Wireshark에 추가하면 패킷을 자동으로 복호화해 줌
    • QUIC은 TLS 명세의 일부, 예를 들어 핸드셰이크와 전송 상태 등을 재사용함
      그래서 그것 없이는 동작할 수 없음
답변달기