Vì sao HTTP/3 được hỗ trợ rộng rãi nhưng trên thực tế lại hầu như không được sử dụng

 (httptoolkit.com)
2 điểm bởi GN⁺ 2025-03-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • HTTP/3 đã được phát triển từ năm 2016, còn QUIC, giao thức nền tảng của nó, lần đầu được Google giới thiệu vào năm 2013
  • Hiện nay giao thức này đã được chuẩn hóa và nhận được sự hỗ trợ rộng rãi như sau
    • Được hỗ trợ trên 95% trình duyệt
    • 32% yêu cầu HTTP của Cloudflare dùng HTTP/3
    • 35% website hiển thị hỗ trợ HTTP/3 (thông qua alt-svc hoặc DNS)
  • Tuy nhiên, các thư viện chuẩn của những ngôn ngữ phổ biến lại thiếu hỗ trợ cho QUIC và HTTP/3
    • Không được tích hợp trong thư viện chuẩn của Node.js, Go, Rust, Python, Ruby, v.v.
    • Curl gần đây đã thêm hỗ trợ HTTP/3 nhưng vẫn ở trạng thái thử nghiệm và bị tắt mặc định
    • Máy chủ phổ biến Nginx cũng mới chỉ ở mức hỗ trợ thử nghiệm và bị tắt mặc định
    • Apache không có kế hoạch hỗ trợ HTTP/3
    • Ingress-Nginx của Kubernetes đã từ bỏ kế hoạch hỗ trợ HTTP/3

Nhu cầu sau HTTP/1.1

  • HTTP/3 hữu ích cho lưu lượng trình duyệt web và CDN có độ trễ cao
  • Những lợi ích chính mà HTTP/2 và HTTP/3 mang lại:
    • Multiplexing giúp giảm thời gian chờ phản hồi
    • Nén header HTTP giúp giảm lưu lượng (dùng HPACK, QPACK)
    • Streaming hai chiều cho phép trao đổi dữ liệu thời gian thực giữa client và server
    • Ưu tiên hóa cho phép xử lý các yêu cầu quan trọng trước
  • Các lợi ích bổ sung của HTTP/3:
    • Xử lý stream độc lập nên mất gói ở một stream không ảnh hưởng tới stream khác
    • Bắt tay TLS 0-RTT giúp tăng tốc quá trình khởi tạo kết nối
    • Di chuyển kết nối cho phép duy trì kết nối khi địa chỉ IP thay đổi
    • Cải thiện kiểm soát tắc nghẽn để nâng cao hiệu năng và độ ổn định

Mức cải thiện hiệu năng của HTTP/3

  • Kết quả benchmark của RequestMetric:
    • HTTP/3 cho tốc độ phản hồi nhanh hơn HTTP/1.1 và HTTP/2
  • Trường hợp thực tế từ Fastly:
    • Thời gian đến byte đầu tiên trên HTTP/3 giảm 18%

Vấn đề thiếu hỗ trợ cho HTTP/3

  • HTTP/3 được hỗ trợ rộng rãi ở trình duyệt và CDN, nhưng lập trình viên thông thường lại khó sử dụng
  • Hiện nay có hai loại lưu lượng web:
    • Web hyperscale: dựa trên các trình duyệt lớn và hạ tầng máy chủ quy mô lớn (Google, Meta, Amazon, v.v.)
    • Web long-tail: dựa trên các máy chủ và client quy mô vừa và nhỏ (backend API, ứng dụng di động, IoT, v.v.)
  • Những khác biệt chính:
    • Lưu lượng long-tail chiếm 67% tổng lưu lượng
    • Hyperscale có thể phát triển và triển khai nhanh, còn long-tail thiếu tài nguyên và ưu tiên tính ổn định
    • Phụ thuộc nhiều vào các công cụ mã nguồn mở

Vấn đề OpenSSL và QUIC

  • OpenSSL là nền tảng của hầu hết các công cụ mạng mã nguồn mở
  • BoringSSL đã phát hành API hỗ trợ QUIC từ năm 2018, nhưng OpenSSL lại đưa ra API QUIC riêng
  • Các vấn đề chính:
    • Không tương thích với các triển khai hiện có dựa trên BoringSSL
    • Curl và các ngôn ngữ lớn khó thay đổi phụ thuộc OpenSSL
    • Node.js từng xem xét dùng BoringSSL thay vì OpenSSL nhưng không thành hiện thực

Triển vọng sắp tới

  • Khi web hyperscale áp dụng HTTP/3, có thể xuất hiện khoảng cách hiệu năng với web long-tail
  • Việc thiếu hỗ trợ HTTP/3 có thể gây ra các vấn đề như sau:
    • Củng cố lợi thế về tốc độ và độ ổn định của các website hyperscale
    • Nếu các framework dựa trên HTTP/3 trở nên phổ biến, web long-tail sẽ khó tiếp cận
    • Việc không hỗ trợ HTTP/3 có thể bị dùng làm tiêu chí chặn client
  • Hướng giải quyết:
    • Cần xử lý vấn đề API QUIC của OpenSSL
    • Cần phát triển các công cụ và adapter để tăng khả năng tương thích với các triển khai QUIC và HTTP/3 hiện có
    • Cần mở rộng nỗ lực hỗ trợ HTTP/3 trong các công cụ mã nguồn mở

Kết luận

  • HTTP/3 rõ ràng mang lại lợi ích về hiệu năng và độ ổn định, nhưng hiện tại mới là thứ mà chỉ các công ty hyperscale mới có thể dễ dàng sử dụng
  • Cần cải thiện công cụ và tiêu chuẩn để web long-tail cũng có thể dễ dàng sử dụng HTTP/3

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-03-18
Ý kiến Hacker News

  • Có ý kiến cho rằng rất khó tìm được các công cụ mã nguồn mở phổ biến hỗ trợ đầy đủ HTTP/3

    • Quản trị viên IT và kỹ sư DevOps chủ yếu kết thúc kết nối HTTP/3 tại load balancer, kết thúc SSL rồi chuyển tiếp HTTP 1.1 tới các dịch vụ backend
    • HTTP/3 và IPv6 là các công nghệ thiên về di động, hữu ích hơn trong các kết nối tạm thời và không ổn định so với trong trung tâm dữ liệu

  • QUIC hoặc HTTP/3 không được đưa vào thư viện chuẩn của các ngôn ngữ chính

    • .NET đang cung cấp mức hỗ trợ khá tốt cho HTTP/3
    • Phần lớn các nhóm phát triển không xây dựng sản phẩm tập trung vào mạng, nên HTTP/3 có mức ưu tiên thấp

  • Vấn đề lớn nhất khi triển khai HTTP/3 ở quy mô lớn là làm tăng bề mặt của mã có khả năng tồn tại lỗ hổng

    • Việc hệ điều hành cung cấp lớp socket an toàn và thư viện SSL liên kết động sẽ đáng mong muốn hơn
    • Trong hầu hết ứng dụng phía client, độ trễ vài mili giây của request không phải vấn đề lớn

  • Việc QUIC được chấp nhận chậm là do OpenSSL không cung cấp các thành phần nền tảng cần thiết cho các triển khai QUIC hiện có

    • Gần đây OpenSSL 3.5 đã bắt đầu cung cấp API cho các QUIC stack của bên thứ ba

  • HTTP/2 và HTTP/3 không còn được nhìn nhận là giao thức tầng ứng dụng nữa, mà ở mức TCP và TLS

    • Các lập trình viên vẫn đang sống trong thế giới "HTTP 1.1 thuần văn bản"

  • nginx vẫn chưa cung cấp hỗ trợ HTTP/3 sẵn sàng cho production

  • Có người đang dùng niquests trong Python và nó hỗ trợ HTTP/3

    • Hệ sinh thái Python đã ở lại với gói requests do quán tính

  • Node.js đã công bố bản cập nhật về trạng thái của QUIC và đang gặp khó khăn vì OpenSSL hỗ trợ API chậm

  • Nếu dùng load balancer của các nhà cung cấp public cloud thì mặc định sẽ dùng HTTP/3

    • Các trang web sử dụng máy chủ tự vận hành đang không tận dụng được lợi ích của HTTP/3

  • Mọi dự án đều ở một mức độ nào đó được thúc đẩy bởi mã nguồn mở và cộng đồng

    • Không cảm thấy cần thiết phải hỗ trợ HTTP/3 một cách nhanh chóng