savearoundtrip: Công bố bản ghi DNS HTTPS và bỏ qua 1 vòng RTT

 (savearoundtrip.com)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Nếu một website công bố bản ghi DNS HTTPS cho biết hỗ trợ HTTP/3, trình duyệt có thể dùng QUIC/HTTP/3 ngay từ kết nối đầu tiên, giúp giảm 1 vòng khứ hồi kết nối
  • Trình duyệt phát hiện hỗ trợ HTTP/3 bằng cách либо kết nối trước qua HTTP/1 hoặc HTTP/2 để đọc header Alt-Svc, hoặc đọc bản ghi HTTPS ở bước tra cứu DNS
  • Trong phép đo của Firefox Nightly, 31,4% kết nối chỉ quảng bá HTTP/3 qua header Alt-Svc; trong trường hợp này HTTP/3 chỉ được dùng từ các kết nối sau {p:31}
  • Bản ghi HTTPS chứa alpn, ech, ipv4hint, ipv6hint, cho phép xử lý việc chọn giao thức của kết nối đầu tiên, ECH và gợi ý địa chỉ ngay trong phản hồi DNS
  • Bản ghi HTTPS hoạt động theo kiểu bổ sung cho client hiện có, còn Alt-Svc vẫn nên được giữ làm fallback cho các client không nhận được bản ghi

Khái niệm cốt lõi

  • Trình duyệt phát hiện việc một site hỗ trợ HTTP/3 theo hai cách
    • Kết nối trước bằng HTTP/1 hoặc HTTP/2 rồi đọc header HTTP Alt-Svc
    • Kiểm tra trực tiếp qua bản ghi DNS HTTPS trước khi mở kết nối
  • Chỉ khi dùng bản ghi DNS HTTPS, trình duyệt mới có thể dùng HTTP/3 ngay từ kết nối đầu tiên và giảm 1 vòng khứ hồi nhờ QUIC
  • Theo ước tính trung bình từ các bản build gần đây của Firefox Nightly, 31,4% kết nối chỉ thông báo HTTP/3 qua header Alt-Svc, không phải qua DNS
  • Hiện tại, 1 vòng khứ hồi đến máy chủ này được đo khoảng 28ms

Kiểm tra tên miền

  • savearoundtrip.com tự công bố bản ghi HTTPS có h3, gợi ý IP và ECH
  • Bản ghi HTTPS của tên miền bạn nhập được tra cứu trong trình duyệt thông qua endpoint DNS-over-HTTPS của Cloudflare
  • Không thể kiểm tra trực tiếp header Alt-Svc và bắt tay HTTP/3 thực tế từ trong trình duyệt
    • CORS che giấu các header khác nguồn gốc
    • Trình duyệt không thể bị ép tạo một kết nối QUIC lạnh
  • Tên miền bạn nhập được gửi tới một backend mã nguồn mở nhỏ, backend này chỉ thực hiện kiểm tra Alt-Svc và kiểm tra bắt tay HTTP/3 thực tế
  • Dữ liệu không được lưu lại, và bắt tay HTTP/3 thực tế được thực hiện bằng quic-go

Chi phí của 1 vòng RTT

  • 1 vòng RTT là quá trình gửi một thông điệp đến máy chủ và nhận lại phản hồi, bị giới hạn bởi tốc độ ánh sáng
  • Thời gian RTT gần đúng là 5–20ms trong cùng thành phố, 40–80ms giữa các quốc gia, và hơn 150ms khi vượt đại dương hoặc trên mạng di động
  • Cloudflare Radar cung cấp số liệu thời gian thực
  • Tương tác dưới khoảng 100ms thường tạo cảm giác tức thì, còn cao hơn thì sẽ có cảm giác phải chờ
  • Trang này mất khoảng 41ms từ lúc bắt đầu kết nối đến lần vẽ đầu tiên, và RTT thời gian thực đến máy chủ này là khoảng 28ms
  • Một bản ghi HTTPS đã được công bố có thể khiến trình duyệt dùng QUIC thay vì TCP ở kết nối đầu tiên, từ đó cắt bỏ thời gian RTT đó
  • Trang này là trang tĩnh và nhỏ nên tổng ngân sách thời gian thấp, nhưng trong ứng dụng thực tế, 1 vòng RTT vẫn là chi phí cố định phải trả ở đầu luồng và có thể lặp lại trên nhiều nguồn gốc

Vòng RTT bị lãng phí

  • Alt-Svc là một header phản hồi HTTP trong RFC 7838
  • Để đọc được Alt-Svc, client phải mở kết nối TCP, hoàn tất bắt tay TLS, rồi hoàn thành yêu cầu bằng HTTP/1.1 hoặc HTTP/2
  • Với cách này, client chỉ biết máy chủ còn hỗ trợ HTTP/3 sau khi kết nối trước đó đã diễn ra, nên việc nâng cấp lên HTTP/3 chỉ xảy ra ở kết nối tiếp theo
  • Bản ghi HTTPS trong RFC 9460 đưa cùng tín hiệu hỗ trợ HTTP/3 đó vào DNS
  • Client đọc bản ghi này trong lúc phân giải tên vốn dĩ đã phải thực hiện, nên có thể biết hỗ trợ HTTP/3 trước khi mở kết nối
  • Khi dùng bản ghi DNS HTTPS, client có thể dùng QUIC/HTTP/3 ngay từ kết nối đầu tiên và không cần tiêu tốn trước một kết nối HTTP/1 hoặc HTTP/2

Vì sao bản ghi HTTPS tốt hơn

  • Phát hiện HTTP/3 trước byte đầu tiên

    • SvcParam alpn liệt kê các protocol ID ALPN mà endpoint hỗ trợ
    • Ví dụ gồm HTTP/3 là h3 và h2
    • Vì thông tin này đến trong lúc phân giải tên, client có thể chọn QUIC ngay từ kết nối đầu tiên thay vì chỉ phát hiện h3 sau một kết nối HTTP/1 hoặc HTTP/2 trước đó

  • ECH: Client Hello được mã hóa

    • SvcParam ech chứa khóa công khai ECHConfigList của endpoint
    • ECH mã hóa TLS ClientHello, bao gồm cả tên máy chủ SNI, để người quan sát mạng không thể biết site nào đang được truy cập
    • Vấn đề này không thể giải quyết bằng header HTTP vì cần khóa công khai trước khi gửi ClientHello đầu tiên
    • Vì khóa là thứ cần có trước khi tồn tại kết nối, chỉ một kênh ngoài băng như bản ghi HTTPS trong DNS mới có thể bootstrap ECH
    • Không có HTTPS RR thì cũng không thể dùng ECH

  • Bắt đầu kết nối sớm hơn với gợi ý IP

    • Happy Eyeballs v3 thực hiện song song truy vấn A, AAAA và HTTPS
    • ipv4hint và ipv6hint trong phản hồi HTTPS cung cấp địa chỉ ứng viên để kết nối nếu chúng đến sớm hơn bản ghi A/AAAA
    • Client có thể bắt đầu kết nối bằng địa chỉ gợi ý thay vì chờ phản hồi A/AAAA
    • Bản ghi A/AAAA vẫn tiếp tục đến và sẽ thay thế gợi ý sau đó
    • Alt-Svc không có chức năng tương đương

  • Một nguồn thẩm quyền duy nhất và khả năng cache

    • Thông tin khả dụng có thể được giữ trong DNS với TTL thông thường
    • Cách dùng Alt-Svc làm thông tin bị phân tán vào cache header HTTP theo từng origin và phát sinh bài toán max-age
    • Nếu max-age quá dài, client có thể dùng lựa chọn thay thế đã lỗi thời; nếu quá ngắn, client sẽ thường xuyên quay lại giao thức cũ hơn
    • Trình duyệt vốn dĩ phải thực hiện tra cứu DNS, nên bản ghi HTTPS cho phép lần tra cứu đó mang theo luôn thông tin kết nối tối ưu

  • So sánh tính năng

    • | Tính năng | Header HTTP Alt-Svc (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | Thời điểm học được | Sau toàn bộ kết nối | Trong lúc phân giải DNS |
    • | h3 ở kết nối đầu tiên | Không thể | Có thể |
    • | Gợi ý IP | Không có | ipv4hint / ipv6hint |
    • | Khóa ECH | Không thể | tham số ech |
    • | Nguồn chân lý | Header HTTP và cache mong manh | DNS có TTL |

Đo lường thực tế trên trình duyệt

  • Trong phép đo của Firefox Nightly, trình duyệt có thể biết hỗ trợ HTTP/3 qua header phản hồi HTTP Alt-Svc hoặc qua bản ghi DNS HTTPS
  • Alt-Svc chỉ thấy được sau khi đã kết nối, còn bản ghi DNS HTTPS thấy được trước khi kết nối
  • Mọi kết nối thuộc một trong bốn nhóm
    • Neither là kết nối hoàn toàn không quảng bá HTTP/3
    • Alt-Svc only là chỉ quảng bá qua header nên không thể dùng HTTP/3 ở kết nối đầu tiên
    • HTTPS record only là quảng bá trong DNS nên có thể đi bằng HTTP/3 ngay từ kết nối đầu tiên
    • Both là quảng bá ở cả DNS lẫn header
  • Tỷ lệ kết nối đo được là Neither 59,8%, Alt-Svc only 31,4%, HTTPS record only 2,8%, Both 6% {b:60,31,3,6}
  • Bốn nhóm này bao phủ toàn bộ kết nối nên tổng cộng là 100%
  • HTTPS record only và Both là các trường hợp có bản ghi HTTPS khả dụng, còn Alt-Svc only là phần khoảng cách có thể được giảm nếu có bản ghi
  • Các số liệu được tái dựng từ histogram GLAM của Firefox Nightly thành ước tính theo từng kết nối, nên là giá trị gần đúng

Công bố bản ghi HTTPS

  • Có thể công bố bản ghi HTTPS ở chế độ ServiceMode để quảng bá h3 và gợi ý địa chỉ chỉ bằng một dòng
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. là tên công bố bản ghi, dấu chấm cuối biểu thị đây là tên miền đầy đủ
  • 3600 là TTL tính bằng giây mà resolver có thể cache bản ghi
  • IN là lớp DNS Internet giống như các bản ghi web khác
  • HTTPS là kiểu bản ghi trong RFC 9460
  • 1 là độ ưu tiên, và từ 1 trở lên là ServiceMode chứa tham số
  • 0 là AliasMode chỉ trỏ đến một mục tiêu khác
  • . là host đích, nghĩa là chính tên owner example.com
  • alpn="h3,h2" liệt kê các giao thức máy chủ hỗ trợ theo thứ tự ưu tiên tốt, trong đó h3 là HTTP/3 và h2 là HTTP/2
  • ipv4hint và ipv6hint là các địa chỉ để client có thể bắt đầu kết nối ngay song song với việc tra cứu A/AAAA
  • Hầu hết nhà cung cấp DNS được quản lý như Cloudflare, Route 53 đều hỗ trợ trực tiếp kiểu bản ghi HTTPS
  • Có thể kiểm tra tên miền có hỗ trợ hay không bằng checker

Những tính năng thực tế mà bản ghi HTTPS chứa

  • Trên Firefox Nightly, tỷ lệ các tính năng xuất hiện trong những kết nối nhìn thấy bản ghi HTTPS đã được đo lường
  • ALPN h3 chiếm 80,3%, còn gợi ý IPv4 là 52,9%
  • Gợi ý IPv6 là 49,4%, còn ECH là 12,8% {b:80,53,49,13}
  • Những con số này là ước tính theo từng kết nối được tái dựng từ histogram GLAM nên chỉ mang tính gần đúng

FAQ

  • CDN có tự động công bố không

    • Một số CDN tự động công bố bản ghi HTTPS
    • Cloudflare tự động cung cấp bản ghi HTTPS có alpn="h3" cho các zone được proxy
    • Các CDN khác có thể yêu cầu người dùng tự cấu hình
    • Cách kiểm tra nhanh nhất là dùng kiểm tra tên miền ở trên

  • Bản ghi HTTPS có làm hỏng client cũ không

    • Client không hiểu bản ghi HTTPS sẽ bỏ qua nó và quay về tra cứu A/AAAA thông thường
    • Nếu bạn vẫn gửi header Alt-Svc thì các client đó vẫn có thể dùng header này
    • Cách công bố bản ghi HTTPS là bổ sung thêm vào hành vi hiện có

  • Khi truy cập lại thì sao

    • Sau khi client đã giao tiếp bằng HTTP/3 một lần, ở lần truy cập lại có thể tiếp tục kết nối QUIC bằng 0-RTT
    • Với 0-RTT, yêu cầu đầu tiên có thể được gửi ngay mà không cần vòng bắt tay khứ hồi
    • Bản ghi HTTPS cũng được cache theo TTL như các phản hồi DNS khác, nên ở lần truy cập lại thường cả việc tra cứu cũng được bỏ qua

  • Trình duyệt nào dùng bản ghi HTTPS

    • Các engine chính đều hỗ trợ bản ghi HTTPS ở trạng thái bật mặc định
    • Chúng đọc bản ghi bất kể người truy cập có bật DNS-over-HTTPS hay không
    • Safari dùng resolver của hệ điều hành
    • Chrome dùng resolver tích hợp sẵn, hoạt động qua DoH hoặc DNS thường
    • Firefox có thể dùng cả hai cách

  • Có nên bỏ header Alt-Svc không

    • Không nên bỏ header Alt-Svc
    • Nó vẫn nên tiếp tục được gửi như một fallback cho client cũ và cho các resolver hoặc mạng không chuyển tiếp bản ghi HTTPS
    • Các trình duyệt đọc được bản ghi HTTPS sẽ biết HTTP/3 từ DNS và không phải tốn thêm 1 vòng RTT để phát hiện HTTP/3

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Lobste.rs
  • Nhà cung cấp web hosting vẫn chưa hỗ trợ H3, nhưng có thể nâng cấp miễn phí lên phiên bản máy chủ mới để thử nghiệm
    Khi xong sẽ thiết lập bản ghi DNS HTTPS
  • dig của Apple là 9.10.6, có vẻ là phiên bản cũ hơn loại bản ghi này
    Có lẽ Apple nên cung cấp dig mới hơn, và tôi cũng tò mò mọi người thích dùng công cụ nào để tra cứu DNS trên macOS

    • Tôi hay dùng doggo trên nhiều nền tảng
      Nó không hoàn hảo, nhưng nhìn chung hoạt động khá tốt và đáp ứng được khá nhiều nhu cầu tôi cần

    • Tôi dùng drill của ldns cài qua Homebrew

      % drill -Q https savearoundtrip.com  
1 . alpn=h3,h2 ipv4hint=104.21.20.43,172.67.191.84 ech=AEX+DQBBzwAgACAdG3AfYFkusczSXA/kky1bgK67QViv5mNKyS3ITnrWbAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3030::ac43:bf54,2606:4700:3037::6815:142b
  • Nếu có bản ghi tài nguyên HTTPS, mọi client đọc được nó sẽ kết nối an toàn
    Kể cả khi không hỗ trợ QUIC cũng vậy
  • Tôi không hiểu vì sao bài này lại bị gắn thẻ vibecoding
    Gần như chỉ có việc CSS trông như được tạo ra từ LLM
    • Commit đầu tiên đúng là có vẻ được tạo bằng LLM: https://github.com/mxinden-bot/savearoundtrip/…
      Và bài viết thì dài dòng. Có nhiều lặp lại, nội dung vô ích và hình minh họa kỳ lạ, nên khoảng 1700 từ mà chiều dài trang ở chế độ full width vượt quá 7300px
      Nếu rút xuống còn 500 từ, 2 sơ đồ và tổng chiều dài dưới 2000px thì sẽ tốt hơn nhiều