QUIC vẫn chưa đủ nhanh ngay cả trên Internet tốc độ cao

 (arxiv.org)
2 điểm bởi GN⁺ 2024-10-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong các môi trường có thể đạt 500Mbps~1Gbps trở lên cho mỗi kết nối như mạng có dây tốc độ cao, WiFi 6/7 và 5G, ngăn xếp UDP+QUIC+HTTP/3 cho thấy thông lượng truyền dữ liệu thấp hơn tới 45,2% so với TCP+TLS+HTTP/2
  • Không chỉ ở tải xuống tệp đơn giản, mà trên Chrome, Edge, Firefox, Opera cùng các môi trường desktop và di động, khoảng cách hiệu năng giữa QUIC và HTTP/2 càng tăng khi băng thông càng cao
  • Kết quả theo dõi gói và profiling kernel/user space cho thấy nút thắt gần với overhead xử lý phía nhận hơn là phía gửi; khi nhận QUIC sẽ phát sinh nhiều gói hơn và nhiều xử lý ACK trong user space hơn
  • Tác động ở cấp ứng dụng dẫn tới bitrate giảm tới 9,8% với video DASH và thời gian tải trang dài hơn trung bình 3,0% trên 100 website tiêu biểu
  • Để giảm thiểu, cần triển khai UDP GRO ở phía nhận, cải tiến GSO/GRO theo hướng thân thiện với QUIC, cải thiện logic nhận và tận dụng nhiều lõi CPU, nhưng sự đa dạng của thiết bị khách và hệ điều hành khiến việc hiện thực hóa trở nên khó khăn

Khoảng cách hiệu năng của QUIC bộc lộ trên mạng tốc độ cao

  • QUIC là giao thức tầng truyền tải đa hợp chạy trên UDP và đã được IETF chuẩn hóa làm nền tảng truyền tải cho HTTP/3
  • Nhiều công ty như Google, Akamai, Meta và Cloudflare đã triển khai QUIC thương mại từ năm 2013, và cùng với HTTP/3, nó được chú ý như một ứng viên có thể thay đổi hiệu năng web
  • Các nghiên cứu trước đây về hiệu năng QUIC có sự khác nhau lớn về implementation, môi trường tính toán và điều kiện mạng, và nhiều nghiên cứu tập trung vào các trường hợp sử dụng thông lượng thấp
  • Trọng tâm của phép đo là hành vi của QUIC trên các mạng tốc độ cao, nơi có thể đạt 500Mbps trở lên hoặc 1Gbps trở lên cho mỗi kết nối, như đường truyền có dây tốc độ cao, WiFi 6/7 và 5G
  • Đối tượng so sánh không phải một giao thức đơn lẻ mà là toàn bộ ngăn xếp
    • Phía QUIC: UDP+QUIC+HTTP/3
    • Phía truyền thống: TCP+TLS+HTTP/2
    • Trong phần tóm tắt, lần lượt gọi là QUIC và HTTP/2

Khác biệt được xác nhận trong thí nghiệm tải xuống tệp

  • Trong thí nghiệm tải xuống tệp đơn giản dùng cURL và quic_client dựa trên Chromium, việc so sánh được thực hiện với cùng thuật toán kiểm soát tắc nghẽn, cấu hình máy chủ và điều kiện mạng
  • Ở mức băng thông tương đối thấp, dưới khoảng 600Mbps, hiệu năng của QUIC và HTTP/2 khá tương tự nhau, nhưng ở băng thông cao hơn, thông lượng của QUIC thấp hơn tối đa 15,7% so với HTTP/2
  • Khi băng thông tăng, khoảng cách hiệu năng càng rõ rệt hơn, và trong quá trình nhận gói, QUIC cho thấy mức sử dụng CPU cao hơn nhiều so với HTTP/2 trên các máy khách hiện đại
  • Trong thí nghiệm với các trình duyệt chính, khoảng cách còn lớn hơn
    • Các trình duyệt mục tiêu là Chrome, Edge, Firefox, Opera
    • Trên Chrome, khi băng thông vượt khoảng 500Mbps, QUIC bắt đầu tụt lại phía sau
    • Khi băng thông đạt 1Gbps, QUIC chậm hơn 45,2% so với HTTP/2
    • Trên các máy khách yếu hơn như thiết bị di động, khoảng cách còn lớn hơn nữa

Tác động trong các ứng dụng web

  • Sự suy giảm hiệu năng không chỉ giới hạn ở truyền tệp dung lượng lớn mà còn xuất hiện trong các ứng dụng có mẫu lưu lượng ngắt quãng
  • Khi truyền các chunk video DASH qua Ethernet tốc độ cao và 5G, QUIC cho thấy bitrate video thấp hơn tối đa 9,8% so với HTTP/2
  • Sự suy giảm QoE này chỉ bộc lộ khi băng thông nền đủ cao
    • Trên 4G, tác động bị che lấp
    • Trên 5G, tác động xuất hiện
  • Trong thí nghiệm duyệt web, xét trung bình trên 100 website tiêu biểu, thời gian tải trang (PLT) của QUIC dài hơn 3,0% so với HTTP/2
  • Ở phần đuôi dài, cũng có các trường hợp khoảng cách thời gian tải trang vượt quá 50%

Nguyên nhân nút thắt: xử lý phía nhận và ACK trong user space

  • Dữ liệu theo dõi gói và hiệu năng cho thấy client QUIC nhận nhiều gói hơn rất nhiều so với khi tải xuống bằng HTTP/2
  • Khi QUIC nhận ở tốc độ dữ liệu cao, độ trễ giữa các gói dữ liệu đến và các gói ACK tương ứng tăng lên, làm thời gian xử lý gói QUIC kéo dài hơn
  • Hai quan sát này cho thấy nguyên nhân suy giảm hiệu năng của QUIC trên Internet tốc độ cao nằm ở giới hạn năng lực xử lý phía nhận
  • Có hai lý do khiến phía nhận được xác định là nút thắt
    • Máy chủ thường mạnh hơn client như desktop, laptop và smartphone
    • Theo thiết kế của QUIC, xử lý nhận dữ liệu có những khó khăn riêng
  • Profiling chuyên sâu xác nhận hai nguyên nhân chính
    • Quá nhiều gói dữ liệu
      • Khi tải cùng một tệp, ngăn xếp UDP trong kernel tạo ra nhiều lần đọc gói netif_receive_skb hơn rất nhiều so với TCP
      • Không implementation QUIC nào được khảo sát sử dụng UDP generic receive offload, tức UDP GRO
      • UDP GRO là cơ chế trong đó mô-đun tầng liên kết gộp nhiều datagram UDP nhận được thành một datagram lớn trước khi chuyển lên tầng truyền tải
      • Điều này tương phản với thực tế là TCP segmentation offload đã được triển khai rộng rãi, còn GSO — offload phía gửi cho UDP — gần đây cũng được nhấn mạnh
    • Xử lý ACK trong user space
      • Trong user space, QUIC có overhead cao hơn cho việc xử lý gói nhận và tạo phản hồi
      • Nguyên nhân bao gồm số lượng gói quá nhiều từ kernel chuyển lên, xử lý ACK của QUIC trong user space và việc thiếu một số tối ưu hóa như delayed ACK của QUIC

Đo đạc sơ bộ và hướng giảm thiểu

  • Thí nghiệm sơ bộ tải xuống tệp 1GB trên trình duyệt Chrome cho thấy khi bật QUIC, thời gian tải xuống tăng gần gấp đôi
  • Kết quả mẫu là trung bình của 10 lần chạy
    • Desktop Ethernet: HTTP/2 9,32 giây, HTTP/3 18,60 giây, tăng 99%; mức sử dụng CPU tăng từ 77,5% lên 96,9%
    • Pixel 5 low-band 5G: HTTP/2 37,11 giây, HTTP/3 78,65 giây, tăng 112%; mức sử dụng CPU tăng từ 121,55% lên 161,77%
    • Pixel 5 mmWave 5G: HTTP/2 30,10 giây, HTTP/3 63,20 giây, tăng 110%; mức sử dụng CPU tăng từ 128,43% lên 165,20%
  • Mức sử dụng CPU trên desktop được tính theo dịch vụ mạng của trình duyệt, còn phép đo trên smartphone dựa trên toàn bộ tiến trình trình duyệt
  • Giá trị sử dụng CPU vượt 100% có nghĩa là trên hệ thống đa lõi, tiến trình trình duyệt đã dùng nhiều hơn một lõi
  • Các biện pháp giảm thiểu được đề xuất gồm triển khai UDP GRO ở phía nhận, cải tiến GSO và GRO theo hướng thân thiện với QUIC, cải thiện logic QUIC phía nhận và nhận dữ liệu QUIC bằng nhiều lõi CPU
  • Do các máy khách bao gồm PC, thiết bị di động, thiết bị nhúng và nhiều hệ điều hành khác nhau nên có mức độ không đồng nhất cao hơn máy chủ, việc hiện thực hóa các biện pháp giảm thiểu gặp nhiều khó khăn thực tế
  • Dữ liệu đo đạc và mã nguồn đã được công bố cùng nghiên cứu này

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-20
Ý kiến trên Hacker News

  • Có vẻ như ngành này muốn làm mọi thứ, trừ việc tạo ra các trang web nhẹ
    Ngay cả vào cuối thập niên 90, chỉ cần đường truyền nhanh là internet đã phản hồi gần như tức thì, trang thì nhỏ và hầu như không có JavaScript
    Bây giờ vẫn có thể tìm thấy những trang nhẹ và nhanh như vậy; cảm giác như trang đã tải xong trước cả khi bạn nhả nút chuột, gần như siêu thực
    Giá mà trải nghiệm người dùng tốt hơn thì còn có thể chấp nhận được, nhưng ngay cả điều đó cũng không đạt được

    • Tôi đang loại bỏ JavaScript khỏi ứng dụng React trong dự án hiện tại, và việc đó rất thú vị
      Nó nhanh hơn, ổn định hơn rất nhiều, và sự lệch trạng thái giữa frontend và backend cũng biến mất
      Tôi vẫn chấp nhận một lượng JavaScript tối thiểu vì tính tiện dụng, hiện chỉ còn vài trăm dòng, và dự định thêm một chút nữa để nó vẫn trông như ứng dụng một trang
      Làm vậy có thể xóa khoảng 40.000 dòng React và 20.000 dòng Kotlin, nhưng sẽ phải viết lại khoảng 30.000 dòng mã backend
      Dù vậy tôi vẫn rất thích
    • Vào thời điểm sắp tốt nghiệp đại học, tôi đã tin hoàn toàn vào trào lưu phát triển web dựa trên framework, và nghĩ rằng phát triển web “enterprise” thì phải làm như vậy
      Vì thế tôi đã chuyển trang chủ cá nhân sang phiên bản VUE.JS tĩnh để lấy kinh nghiệm, nhưng cách truyền tên biến dưới dạng chuỗi để liên kết view với state thật kỳ quặc, việc mở rộng môi trường build thì phức tạp một cách không cần thiết, và mọi thứ đều chậm chạp, lại bị ép phải làm theo một kiểu nhất định
      Vì ai cũng dùng nên tôi nghĩ chắc là đúng, nhưng giờ tôi đã thoát khỏi góc nhìn đó, và bản mới chỉ dùng HTML thuần với template của trình tạo trang tĩnh
      Kích thước HTML giảm 90%, lượng JS giảm 97%, và thời gian build từ 20 giây xuống còn 2 giây
      Trải nghiệm người dùng cũng tốt hơn, và sau bản mới thì lượng truy cập tăng 30%
      Dùng web ít hơn thì web có thể tuyệt vời hơn rất nhiều
    • Các trang nhẹ không thể trở thành một mục thật hào nhoáng trong CV
      Ngay cả ở backend, “con ngỗng đẻ trứng vàng” ngày nay cũng là bán microservice thông qua các sản phẩm headless SaaS được kết nối bằng API, như thể hiệu năng đương nhiên sẽ tốt lên
      https://macharchitecture.com/
      Nếu người ta muốn mua những cái xẻng như thế, thì trong thế giới IT chúng ta cũng chẳng còn cách nào khác ngoài việc chất đầy những cái xẻng đó
    • Tôi làm tất cả dự án cá nhân bằng HTML render phía máy chủ
      Blog là một trang Hugo được render tĩnh nên hoàn toàn không có JS, còn các dự án thì dựa trên Rails và HTML render phía máy chủ, chỉ thêm lượng JS tối thiểu cho những tính năng có thì tốt
      Vẫn hoạt động ngay cả khi không có JS
      Có thể vì đó là trang của tôi nên tôi mới nói vậy, nhưng trải nghiệm tốt hơn rất nhiều so với phần lớn web hiện nay, và chúng ta đã đánh mất quá nhiều
    • Ví dụ về một trang web ngày nay gần như hiện ra ngay lập tức: https://www.mcmaster.com/

  • Google từng tạo Speedtest thuần JS
    Khi đó Ookla vẫn còn dựa trên Flash nên không chạy được trên Chromebook, và điều đó gây vấn đề cho kỹ thuật viên triển khai khi cần xác minh trạng thái cài đặt
    Trong quá trình đó họ đã học được rất nhiều về cách TCP phản ứng với nhiều yếu tố khác nhau
    Kết quả của bài viết này hầu như đúng như dự đoán, vì điều khiển luồng đã bị đẩy từ kernel và có lẽ cả bộ điều hợp mạng lên không gian người dùng
    TCP có điều khiển luồng và bảo đảm thứ tự, còn QUIC thì về cơ bản khiến bạn phải tự quản lý những thứ đó
    Tất nhiên cũng có lý do chính đáng để làm vậy
    Điều khiển tắc nghẽn của TCP nổi tiếng là bị tụt lại so với tốc độ kết nối hiện đại, và dù đã có các thuật toán mới như BBR thì vẫn phải trả giá [1]
    Điều cốt lõi nhưng quá thường bị bỏ qua trong kiểm thử mạng hay ứng dụng web là độ trễ
    Nếu sống ở châu Á hoặc Úc thì bạn sẽ biết RTT 100ms tai hại đến mức nào
    Nó có thể biến một thứ hoàn toàn phản hồi tốt thành gần như không dùng được, đồng thời do cửa sổ truyền mà làm giảm băng thông kết nối có thể hỗ trợ và khiến hệ thống phản ứng chậm hơn với lỗi cũng như điều khiển tắc nghẽn
    Nếu bạn đang kiểm thử mạng hoặc ứng dụng web, tôi rất khuyến nghị thử thêm ngẫu nhiên 100ms độ trễ [2]
    Vì vậy overhead của QUIC có thể trên thực tế lại không quan trọng
    Bởi băng thông hiệu dụng trên một kết nối TCP đơn hoặc một stream QUIC có thể thấp hơn rất nhiều so với băng thông thô thực tế
    Nói cách khác, ngay cả khi có thêm 45% dữ liệu, nếu tự quản lý điều khiển tắc nghẽn giúp tốc độ hiệu dụng giữa hai điểm cao hơn thì vẫn có thể có lợi
    [1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
    [2]: https://bencane.com/simulating-network-latency-for-testing-i...

    • Tôi đã chạy rất nhiều thử nghiệm trong môi trường thực với ứng dụng truyền tệp của mình[1], và ban đầu kỳ vọng QUIC sẽ cực kỳ ấn tượng, nhưng cuối cùng thất vọng vì nhiều lý do và quay lại với TCP
      Nghĩ lại thì điều này là hiển nhiên: với TCP bạn chỉ cần nói kiểu “kernel ơi, gửi giúp tôi cái buffer khổng lồ này”, còn UDP là kiểu chuyển mạch gói nên ngay cả việc gửi số 0 cũng tốn CPU trên hầu hết hệ điều hành và phần cứng tiêu dùng do chi phí chuyển chế độ
      Có cách lách, nhưng không dễ, theo kinh nghiệm của tôi cũng chưa thật sự sẵn sàng, và còn giới hạn lựa chọn ngôn ngữ, thư viện và nền tảng có thể dùng
      Ngoài ra tôi còn thấy thông lượng giảm mạnh khi MacBook chạy bằng pin, có lẽ liên quan đến các nhân tiết kiệm điện
      Thứ hai, QUIC xử lý điều khiển tắc nghẽn không tốt
      Tôi dùng quic-go nên có thể khác tùy môi trường, nhưng không có tinh chỉnh nào giúp được nhiều, và khi đứng cạnh một luồng TCP thì TCP giành được nhiều băng thông hơn
      Thứ ba, API khá kỳ quặc
      Bản thân QUIC có nhiều stream, nên nó không phải là một bản thay thế cắm-vào-là-chạy cho TCP
      Tuy vậy, dường như ý định là biến HTTP/3 thành bản thay thế cắm-vào-là-chạy ở tầng cao hơn, nhưng tôi chưa thử nên không thể nói
      Nếu bạn làm việc ở cấp stream thì đây là điều đáng để lưu ý
      Kết lại, tôi có cảm giác thất bại khá nặng nề, nhưng đồng thời lại thêm phần kính trọng trước mức độ tối ưu hóa và khả năng phục hồi của người bạn cũ TCP
      Đây thực sự là công nghệ đáng kinh ngạc, và hệ điều hành luôn cung cấp miễn phí cho bạn
      Một số vấn đề lớn của TCP cũng không hẳn là lỗi thiết kế mà là do các giá trị mặc định quá bảo thủ hoặc mang tính di sản
      Ví dụ như giới hạn buffer của Linux, Nagle và những thứ tương tự
      Thay vì phát minh lại bánh xe, sẽ tốt hơn nếu ta chỉ cải thiện TCP
      [1]: https://payload.app/
    • Việc “đẩy điều khiển luồng từ kernel và bộ điều hợp mạng lên không gian người dùng” không phải thuộc tính bản chất của giao thức QUIC, mà chỉ là một quyết định triển khai
      Đó là quyết định cần thiết để QUIC có thể khởi đầu, nhưng giờ nó đã tồn tại rồi thì hoàn toàn có thể xem xét lại
      Không có rào cản kỹ thuật nào đối với việc triển khai QUIC trong kernel, và nếu lợi ích hiệu năng đủ lớn thì gần như chắc chắn sẽ sớm có người làm điều đó
    • Từ góc nhìn của người thường xuyên thấy độ trễ từ Trung Quốc đến máy chủ bên ngoài Trung Quốc vượt quá 300ms, tôi ủng hộ QUIC mạnh mẽ
      Khác biệt là một trời một vực
    • Trong tab Network của công cụ dành cho nhà phát triển Chrome, bạn có thể hạ chất lượng kết nối
      Có các preset Slow/Fast 4G và 3G, đồng thời bạn có thể tạo preset tùy chỉnh để đặt tốc độ tải xuống/tải lên, độ trễ tính bằng ms, tỷ lệ mất gói, độ dài hàng đợi gói, và thậm chí bật cả việc sắp xếp lại gói tin
    • Có giả định ngầm rằng không gian người dùng thì chậm, nhưng một phần hoặc thậm chí phần lớn các TCP/IP stack hiệu năng cao nhanh nhất lại được xây dựng trong không gian người dùng

  • Daniel Stenberg, người tạo ra và cũng là người duy trì curl, đã có một bài viết vài tháng trước về HTTP/3 trong curl: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
    Một trong những điều ông nhấn mạnh là mức sử dụng CPU cao hơn của HTTP/3, đến mức CPU trở thành yếu tố giới hạn thông lượng
    Tôi tự hỏi bao nhiêu phần trong đó là do triển khai còn non, và bao nhiêu là thuộc tính vốn có của chính thiết kế QUIC

    • Hai trong số các khuyến nghị nói về việc cải thiện triển khai phía nhận, tức là tối ưu hóa và đa luồng, nên có vẻ là dấu hiệu cho thấy việc triển khai vẫn còn chưa trưởng thành
      Khuyến nghị thứ ba là UDP GRO, tức sửa kernel, lý tưởng nhất là cả phần cứng NIC, để gộp các gói UDP nhận được, giảm công việc theo từng gói và chuyển thành công việc theo nhóm
      TCP đã có sẵn điều này, và phía gửi cũng có những cơ chế tương tự như TSO hay GSO của Linux
      Điều này cũng tạo cảm giác như còn non, nhưng nếu nghĩ đến khả năng thiếu hỗ trợ phần cứng thì có thể sẽ khó sửa hơn
      Phần tóm tắt có nói về chi phí của cơ chế ACK trong QUIC, nhưng tôi chưa xem kỹ lập luận đó
      Một tính năng khác có trên các máy chủ TCP hiện đại là offload TLS sang phần cứng
      Với các máy chủ đồng thời gửi nhiều luồng TCP, điều đó có vẻ càng quan trọng hơn
      Trên Linux, việc này có thể thực hiện bằng mạng không gian người dùng hoặc qua ‘kernel tls’, và nếu có thể thì sẽ được offload xuống phần cứng
      Tính năng này cũng liên quan đến một khả năng khá lạ của Linux cho phép chia luồng TCP thành các ‘message’ để gửi sang luồng khác, nhưng tôi không biết liệu có thể chuyển trước các message phía sau khi các gói đi trước bị mất hay không
    • Tôi luôn hiểu rằng QUIC được thiết kế cho những kết nối không được đảm bảo ổn định hay nhanh, chẳng hạn như mạng di động
      Tôi chưa từng có ấn tượng rằng mục tiêu của nó là làm mọi kết nối nhanh hơn
      Nhìn từ góc đó thì sự đánh đổi là hợp lý
      Tôi không phải chuyên gia nên mong ai biết rõ hơn sẽ sửa lại nếu tôi sai
    • Cách nói “triển khai còn non” ở đây khá thú vị
      QUIC được tạo ra vì hoàn toàn không có cách nào buộc mọi phần cứng trên Internet, kể cả middleware, hỗ trợ các tiêu chuẩn TCP hay TLS mới
      Vì thế QUIC là một lời giải thanh lịch để đặt một tiêu chuẩn truyền tải mới trên UDP lên trên lớp phần cứng Internet cũ kỹ
      Trong một thế giới lý tưởng, người ta đã tạo ra các tiêu chuẩn TCP và TLS mới rồi thay thế hoặc cập nhật mọi router Internet và phần cứng trên toàn thế giới để triển khai với mức dùng CPU thấp hơn
    • Kết quả hiệu năng đó cũng làm tôi ngạc nhiên
      Trong bài test, quiche bị giới hạn bởi CPU ở dưới 200MB/s còn nghttp2 vượt quá 900MB/s
      Tôi tự hỏi CPU có bị throttling hay không
      Nếu triển khai HTTP/3 dùng CPU gấp 4 lần thì đúng là đáng chú ý, nhưng nếu giá trị tuyệt đối ban đầu vốn đã rất thấp thì chưa chắc đó đã là vấn đề lớn

  • Điểm mấu chốt là câu “trên Internet nhanh, stack UDP+QUIC+HTTP/3 làm tốc độ dữ liệu giảm tới 45,2% so với TCP+TLS+HTTP/2”, nhưng dù tôi vẫn chưa đọc toàn bộ bài báo, phần mở đầu có vẻ xem mọi thứ dưới 600Mbit/s là Internet chậm

    • Nói cách khác, ý ở đây là hãy bật HTTP/3 + QUIC cho đoạn trình duyệt khách <> edge, còn đoạn edge <> origin thì giới hạn ở HTTP/2 hoặc HTTP/1
      Lấy Cloudflare làm ví dụ, họ chỉ hỗ trợ QUIC giữa client <> edge chứ không dùng cho kết nối tới origin
      Điều này hợp lý nếu kết nối edge <> origin có thể tái sử dụng, ổn định và “nhanh”
      https://developers.cloudflare.com/speed/optimization/protoco...
    • Điểm quan trọng tương ứng là nguyên nhân nằm ở overhead xử lý phía nhận cao, đặc biệt là quá nhiều gói dữ liệu và ACK của QUIC ở không gian người dùng
      Không có vẻ như đây là một vấn đề mang tính nền tảng của chính giao thức
    • Tôi cho rằng sự suy giảm thông lượng chủ yếu xuất hiện dưới dạng vấn đề độ trễ do triển khai trình duyệt kém hiệu quả hoặc có quá nhiều system call
      Tuy nhiên các vấn đề độ trễ kiểu này, khác với vấn đề sử dụng CPU làm CPU phải boost, sẽ không làm tăng đáng kể mức tiêu thụ pin
      Nó cũng không phải vấn đề trong giao tiếp server-to-server
      Về cơ bản, đây là việc trên thiết bị người dùng cuối, ngay cả trong năm 2024, truyền tải băng thông cao sẽ “chậm đi” khi dùng các kết nối cực nhanh
      Tốc độ ở đây là tốc độ hiệu dụng thực tế từ thiết bị đến máy chủ, không phải tốc độ quảng cáo mà bạn mua
      Không phải bài báo này vô dụng; triển khai trình duyệt cần được cải thiện và bài báo đã cho thấy điều đó rất rõ
      Chỉ là tiêu đề bài báo gần như clickbait 100%
    • Kết nối Internet về sau chắc chắn sẽ còn nhanh hơn nữa
      Chuyển sang một phương thức truyền tải chậm hơn đúng vào lúc Internet gigabit đang phổ biến rõ ràng là một sai lầm
    • Ở Thụy Sĩ, bạn có thể dùng 25Gbit/s với giá 60 USD mỗi tháng
      30 năm nữa còn nhanh hơn nữa, và sẽ thật ngớ ngẩn nếu phải dùng một giao thức cũ hơn chỉ để tận dụng hết tốc độ đường truyền

  • Tháng 9 cũng đã có bài này được đăng: QUIC is not quick enough over fast internet (acm.org)
    https://news.ycombinator.com/item?id=41484991 (327 bình luận)

    • Cá nhân tôi rút ra kết luận rằng không nên để Google, thông qua Chromium, trên thực tế đơn phương thiết kế và áp đặt việc sử dụng các giao thức Internet
      Brave/Vivaldi/Opera là những lựa chọn nên được cân nhắc một cách có chủ đích
    • QUIC là công nghệ phục vụ việc một công ty quảng cáo muốn đảm bảo quảng cáo được phân phối tới người tiêu dùng
      Miễn quảng cáo tới nhanh là được, còn mọi thứ khác không quan trọng

  • Điều này nghe thực sự rất kỳ lạ
    Chỉ riêng QUIC+HTTP/3, thậm chí chỉ QUIC thôi, cũng đã từng đạt tốc độ 900mbps
    Có vẻ như là một triển khai TLS tệ hoặc một triển khai ban đầu chưa hiệu quả
    Mức sử dụng CPU vào khoảng 5% trên lõi EPYC thế hệ 2, khá là trung bình

    • Thật ra đây là điều khá ai cũng biết, rằng triển khai QUIC hiện tại trong trình duyệt không ổn định và được xây trên rustls hoặc một kiểu vá víu tương tự

  • Có một giai thoại là đã từng gặp sự cố khi truy cập wordpress.org
    Lúc mới dùng Wordpress thì vẫn xem tài liệu bình thường, nhưng đến một thời điểm nào đó lại hoàn toàn không thể vào website được nữa
    Vì máy đang dual-boot với Linux nên không phải vấn đề của Windows, ping vẫn hoạt động tốt, và đổi qua ba trình duyệt khác nhau cũng vẫn vậy
    Khi vào trang thì либо bị treo và không tải gì cả, hoặc thỉnh thoảng trang dừng tải giữa chừng
    Hôm nay cuối cùng đã tìm ra cách khắc phục, đó là tắt Experimental QUIC Protocol trong phần cài đặt của Chrome
    Đã gặp vấn đề truy cập wordpress.org suốt nhiều tháng, nhưng hoàn toàn không có dấu hiệu nào cho thấy nguyên nhân là QUIC nên khá đáng lo
    Chỉ nhờ thỉnh thoảng xuất hiện lỗi liên quan đến QUIC trong công cụ dành cho nhà phát triển nên mới kịp nhận ra
    Không biết còn bao nhiêu website khác cũng trở nên không thể truy cập vì giao thức này mà người dùng lại không hề biết nguyên nhân

  • Ở đây internet nhanh là 500Mbps, và lý do là vì QUIC có vẻ bị giới hạn bởi CPU ở mức cao hơn thế
    Chưa xem kỹ đến mức xác nhận hệ thống thử nghiệm có phải máy phổ thông cho người dùng hay liệu trên desktop hiệu năng cao vẫn còn vấn đề này hay không

  • Điều buồn cười là dù không thực sự hiểu rõ chi tiết, chúng ta vẫn ngầm chấp nhận kiểu suy nghĩ như nhanh hơn = tốt hơn, kiểu “QUIC là HTTP/2 mới”
    Nó cũng giống như việc mua điện thoại 5G mới vì nghe nói nó nhanh hơn 4G gấp nhiều lần
    Trong khi thực tế 1) điện thoại 4G của tôi chưa bao giờ chạy ở tốc độ tối đa của 4G, và 2) các vấn đề kết nối hầu như lúc nào cũng không phải do tốc độ đường truyền internet mà do máy chủ DNS, website đích, hoặc thiết bị ghép kênh kết nối phía nhà mạng gặp trục trặc
    Thế mà cuối cùng vẫn thành kiểu “nhưng đây là 5G mà”
    Quảng cáo “fiber broadband” cũng buồn cười khi dựng cảnh mọi người xem TV với tóc bay phần phật trong gió
    Thực tế nó đâu hoạt động như thế
    Trước đây với kết nối 8Mb vẫn stream được, nên 300Mb có thể tốt hơn cho một số việc, nhưng không rõ liệu có cảm nhận được khác biệt lớn hay không

  • Tôi ước QUIC có chế độ không TLS
    Khi phát triển cục bộ, đôi khi chỉ muốn nhìn xem dữ liệu gì đang đi qua đường truyền, nhưng thứ này lại tạo thêm khá nhiều ma sát không cần thiết

    • Nếu thêm khóa riêng của máy chủ vào Wireshark thì nó sẽ tự động giải mã gói tin
    • QUIC tái sử dụng một phần của đặc tả TLS, chẳng hạn như handshake và trạng thái truyền tải
      Vì vậy nếu không có nó thì QUIC không thể hoạt động