savearoundtrip: Publikasikan catatan DNS HTTPS dan lewati satu round trip

 (savearoundtrip.com)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Jika sebuah situs web memublikasikan catatan DNS HTTPS yang menyatakan dukungan HTTP/3, browser dapat menggunakan QUIC/HTTP/3 sejak koneksi pertama sehingga mengurangi satu round trip koneksi
  • Browser menemukan dukungan HTTP/3 dengan terlebih dahulu terhubung lewat HTTP/1 atau HTTP/2 lalu membaca header Alt-Svc, atau dengan membaca catatan HTTPS pada tahap lookup DNS
  • Dalam pengukuran Firefox Nightly, 31,4% koneksi mengumumkan HTTP/3 hanya melalui header Alt-Svc, sehingga dalam kasus ini HTTP/3 baru digunakan pada koneksi berikutnya {p:31}
  • Catatan HTTPS memuat alpn, ech, ipv4hint, ipv6hint, sehingga pemilihan protokol koneksi pertama, ECH, dan petunjuk alamat dapat ditangani di dalam respons DNS
  • Catatan HTTPS bekerja sebagai tambahan bagi klien yang sudah ada, dan Alt-Svc harus tetap dipertahankan sebagai fallback untuk klien yang tidak menerima catatan tersebut

Konsep inti

  • Browser menemukan dukungan HTTP/3 suatu situs dengan dua cara
    • Ada cara dengan terlebih dahulu terhubung memakai HTTP/1 atau HTTP/2 lalu membaca header HTTP Alt-Svc
    • Ada juga cara dengan langsung memeriksanya dari catatan DNS HTTPS sebelum koneksi dibuka
  • Hanya saat menggunakan catatan DNS HTTPS browser dapat memakai HTTP/3 sejak koneksi pertama, dan menghemat satu round trip melalui QUIC
  • Dalam estimasi rata-rata build terbaru Firefox Nightly, 31,4% koneksi mengetahui HTTP/3 hanya dari header Alt-Svc, bukan dari DNS
  • Saat ini satu round trip ke server ini terukur sekitar 28ms

Pemeriksaan domain

  • savearoundtrip.com sendiri memublikasikan catatan HTTPS dengan h3, petunjuk IP, dan ECH
  • Catatan HTTPS untuk domain yang dimasukkan diambil di browser melalui endpoint DNS-over-HTTPS milik Cloudflare
  • Header Alt-Svc dan handshake HTTP/3 yang sebenarnya tidak dapat diperiksa langsung dari browser
    • CORS menyembunyikan header lintas asal
    • Browser tidak dapat dipaksa membuat koneksi QUIC dingin
  • Domain yang dimasukkan dikirim ke backend open source kecil, dan backend itu hanya memeriksa Alt-Svc serta handshake HTTP/3 yang sebenarnya
  • Data tidak disimpan, dan handshake HTTP/3 yang sebenarnya dilakukan dengan quic-go

Biaya satu round trip

  • Satu round trip adalah proses mengirim pesan ke server lalu menerima balasannya, dan dibatasi oleh kecepatan cahaya
  • Perkiraan waktu round trip adalah 5~20ms di dalam kota, 40~80ms antarnegara, dan 150ms atau lebih saat melintasi samudra atau di jaringan seluler
  • Cloudflare Radar menyediakan angka real-time
  • Interaksi sekitar di bawah 100ms terasa instan, sedangkan di atas itu mulai terasa seperti menunggu
  • Halaman ini memerlukan sekitar 41ms dari mulai koneksi hingga first paint, dan round trip real-time ke server ini sekitar 28ms
  • Catatan HTTPS yang dipublikasikan dapat membuat browser memakai QUIC alih-alih TCP pada koneksi pertama, sehingga memangkas waktu round trip tersebut
  • Halaman ini statis dan kecil sehingga total anggaran waktunya kecil, tetapi pada aplikasi nyata pun satu round trip adalah biaya tetap di awal dan dapat berulang di banyak origin

Round trip yang terbuang

  • Alt-Svc adalah header respons HTTP dari RFC 7838
  • Agar dapat membaca Alt-Svc, klien harus sudah membuka koneksi TCP, menyelesaikan handshake TLS, lalu menuntaskan permintaan lewat HTTP/1.1 atau HTTP/2
  • Dengan cara ini, fakta bahwa server juga mendukung HTTP/3 baru diketahui setelah koneksi sebelumnya selesai, sehingga upgrade ke HTTP/3 baru terjadi pada koneksi berikutnya
  • Catatan HTTPS dari RFC 9460 menaruh sinyal dukungan HTTP/3 yang sama di DNS
  • Klien membaca catatan ini selama resolusi nama yang memang sudah dilakukan, sehingga dukungan HTTP/3 dapat diketahui sebelum koneksi dibuka
  • Dengan memakai catatan DNS HTTPS, QUIC/HTTP/3 dapat digunakan sejak koneksi pertama tanpa harus lebih dulu menghabiskan koneksi HTTP/1 atau HTTP/2

Mengapa catatan HTTPS lebih baik

  • Menemukan HTTP/3 sebelum byte pertama

    • SvcParam alpn mencantumkan ID protokol ALPN yang didukung endpoint
    • Contohnya adalah h3 untuk HTTP/3 dan h2
    • Karena informasi ini datang saat resolusi nama, klien dapat memilih QUIC sejak koneksi pertama alih-alih baru menemukan h3 setelah koneksi HTTP/1 atau HTTP/2 sebelumnya

  • ECH: Client Hello terenkripsi

    • SvcParam ech memuat kunci publik ECHConfigList milik endpoint
    • ECH mengenkripsi TLS ClientHello termasuk nama server SNI agar pengamat jaringan tidak dapat melihat situs yang dikunjungi
    • Masalah ini tidak bisa diselesaikan lewat header HTTP karena kunci publik dibutuhkan sebelum ClientHello pertama dikirim
    • Karena kunci dibutuhkan saat koneksi belum ada, hanya kanal di luar band seperti catatan HTTPS di DNS yang dapat melakukan bootstrap ECH
    • Tanpa HTTPS RR, ECH juga tidak dapat digunakan

  • Memulai koneksi lebih cepat dengan petunjuk IP

    • Happy Eyeballs v3 menjalankan kueri A, AAAA, dan HTTPS secara paralel
    • ipv4hint dan ipv6hint di dalam respons HTTPS menyediakan alamat kandidat koneksi saat tiba lebih dulu daripada catatan A/AAAA
    • Klien dapat mulai terhubung ke alamat petunjuk itu alih-alih menunggu respons A/AAAA
    • Catatan A/AAAA tetap akan datang, dan setelah tiba akan menggantikan petunjuk tersebut
    • Alt-Svc tidak memiliki fitur yang setara untuk hal ini

  • Satu sumber otoritatif dan caching

    • Informasi reachability dapat tetap berada di DNS dengan TTL normal
    • Pendekatan Alt-Svc membuat informasi tersebar di cache header HTTP per-origin dan menimbulkan dilema max-age
    • Jika max-age terlalu panjang, klien memakai alternatif yang sudah usang; jika terlalu pendek, klien lebih sering kembali ke protokol sebelumnya
    • Browser bagaimanapun juga melakukan lookup DNS, jadi catatan HTTPS membuat lookup tersebut sekaligus membawa informasi koneksi optimal

  • Perbandingan fitur

    • | Fitur | Header HTTP Alt-Svc (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | Kapan diketahui | Setelah koneksi penuh | Saat resolusi DNS |
    • | h3 pada koneksi pertama | Tidak bisa | Bisa |
    • | Petunjuk IP | Tidak ada | ipv4hint / ipv6hint |
    • | Kunci ECH | Tidak mungkin | parameter ech |
    • | Sumber kebenaran | Header HTTP dan cache yang rapuh | DNS dengan TTL |

Pengukuran browser nyata

  • Dalam pengukuran Firefox Nightly, browser dapat mengetahui dukungan HTTP/3 dari header respons HTTP Alt-Svc atau dari catatan DNS HTTPS
  • Alt-Svc hanya terlihat setelah koneksi sudah terjadi, sedangkan catatan DNS HTTPS terlihat sebelum koneksi
  • Semua koneksi masuk ke salah satu dari empat grup
    • Neither adalah koneksi yang sama sekali tidak mengiklankan HTTP/3
    • Alt-Svc only adalah koneksi yang diiklankan hanya lewat header sehingga tidak bisa memakai HTTP/3 pada koneksi pertama
    • HTTPS record only adalah koneksi yang diiklankan di DNS sehingga dapat langsung memakai HTTP/3 sejak koneksi pertama
    • Both adalah koneksi yang diiklankan baik di DNS maupun di header
  • Proporsi koneksi yang diukur adalah Neither 59,8%, Alt-Svc only 31,4%, HTTPS record only 2,8%, dan Both 6% {b:60,31,3,6}
  • Keempat grup itu mencakup seluruh koneksi sehingga totalnya 100%
  • HTTPS record only dan Both memiliki catatan HTTPS yang dapat dipakai, sedangkan Alt-Svc only adalah celah yang seharusnya dapat dikurangi jika catatan tersebut ada
  • Angka-angka ini adalah estimasi per koneksi yang direkonstruksi dari histogram GLAM Firefox Nightly dan merupakan rata-rata build terbaru sehingga bersifat perkiraan

Mempublikasikan catatan HTTPS

  • Catatan HTTPS ServiceMode yang mengiklankan h3 dan petunjuk alamat dapat dipublikasikan dalam satu baris
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. adalah nama yang memublikasikan catatan, dan titik di akhir berarti nama domain lengkap
  • 3600 adalah TTL dalam detik selama resolver dapat menyimpan cache catatan tersebut
  • IN adalah kelas DNS internet yang sama seperti semua catatan web
  • HTTPS adalah tipe catatan dari RFC 9460
  • 1 adalah prioritas, dan 1 atau lebih berarti ServiceMode yang memuat parameter
  • 0 adalah AliasMode yang hanya menunjuk ke target lain
  • . adalah host target, yang berarti nama pemilik itu sendiri yaitu example.com
  • alpn="h3,h2" mencantumkan protokol yang didukung server dalam urutan yang baik, dengan h3 untuk HTTP/3 dan h2 untuk HTTP/2
  • ipv4hint dan ipv6hint adalah alamat yang dapat langsung dipakai klien untuk mulai terhubung bersamaan dengan lookup A/AAAA
  • Sebagian besar penyedia DNS terkelola seperti Cloudflare dan Route 53 menyediakan tipe catatan HTTPS secara langsung
  • Dukungan domain dapat diperiksa lewat checker

Fitur yang benar-benar dibawa catatan HTTPS

  • Pada koneksi yang melihat catatan HTTPS di Firefox Nightly, diukur proporsi fitur yang ada di dalamnya
  • h3 pada ALPN adalah 80,3%, dan petunjuk IPv4 adalah 52,9%
  • Petunjuk IPv6 adalah 49,4%, dan ECH adalah 12,8% {b:80,53,49,13}
  • Angka ini adalah estimasi per koneksi yang direkonstruksi dari histogram GLAM sehingga bersifat perkiraan

FAQ

  • Apakah CDN memublikasikannya secara otomatis

    • Beberapa CDN memang memublikasikan catatan HTTPS secara otomatis
    • Cloudflare secara otomatis menyediakan catatan HTTPS dengan alpn="h3" untuk zone yang diproksi
    • CDN lain mengharuskan pengguna mengaturnya sendiri
    • Cara tercepat untuk memeriksa adalah memakai pemeriksaan domain di atas

  • Apakah catatan HTTPS merusak klien lama

    • Klien yang tidak memahami catatan HTTPS akan mengabaikannya dan kembali ke lookup A/AAAA biasa
    • Jika Anda masih mengirim header Alt-Svc, klien seperti itu tetap bisa memakai header tersebut
    • Cara memublikasikan catatan HTTPS adalah tambahan di atas perilaku yang sudah ada

  • Bagaimana saat kunjungan ulang

    • Setelah klien sekali berkomunikasi lewat HTTP/3, pada kunjungan ulang koneksi QUIC dapat dilanjutkan kembali dengan 0-RTT
    • Dengan 0-RTT, permintaan pertama dapat langsung dikirim tanpa round trip handshake
    • Catatan HTTPS sendiri juga di-cache selama TTL seperti respons DNS lainnya, sehingga pada kunjungan ulang lookup pun biasanya dilewati

  • Browser mana yang memakai catatan HTTPS

    • Mesin browser utama mendukung catatan HTTPS dengan aktif secara default
    • Catatan dibaca terlepas dari apakah pengunjung mengaktifkan DNS-over-HTTPS atau tidak
    • Safari memakai resolver sistem operasi
    • Chrome memakai resolver bawaannya sendiri, dan bekerja melalui DoH maupun DNS biasa
    • Firefox dapat memakai keduanya

  • Apakah header Alt-Svc harus dihapus

    • Header Alt-Svc tidak boleh dihapus
    • Header itu harus tetap dikirim sebagai fallback untuk klien lama serta resolver atau jaringan yang tidak menyampaikan catatan HTTPS
    • Browser yang membaca catatan HTTPS akan mengetahui HTTP/3 dari DNS, sehingga tidak perlu menghabiskan satu round trip untuk menemukan HTTP/3

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Lobste.rs
  • Penyedia web hosting itu belum mendukung H3, tetapi bisa diuji dengan upgrade gratis ke versi server baru
    Setelah selesai, rencananya akan mengatur rekor DNS HTTPS
  • dig milik Apple ada di versi 9.10.6, jadi tampaknya lebih tua daripada jenis rekor ini
    Rasanya Apple perlu menyediakan dig yang lebih baru, dan saya penasaran apakah ada alat yang lebih disukai untuk kueri DNS di macOS

    • Saya sering memakai doggo di berbagai platform
      Memang tidak sempurna, tetapi secara umum berjalan cukup baik dan memenuhi banyak kebutuhan saya

    • Saya memakai drill dari ldns yang diinstal lewat 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
  • Jika ada rekor resource HTTPS, semua klien yang membacanya akan terhubung dengan aman
    Hal itu tetap berlaku meskipun tidak mendukung QUIC
  • Saya tidak tahu kenapa tulisan ini diberi tag vibe coding
    Hampir satu-satunya alasannya mungkin karena CSS-nya terlihat seperti hasil keluaran LLM
    • Commit pertamanya memang tampak jelas dibuat lewat LLM: https://github.com/mxinden-bot/savearoundtrip/…
      Dan tulisannya bertele-tele. Ada banyak pengulangan, isi yang tidak berguna, dan visualisasi aneh, sehingga dengan sekitar 1700 kata panjang halaman lebar penuhnya sampai lebih dari 7300px
      Akan jauh lebih baik kalau dipangkas jadi sekitar 500 kata, 2 diagram, dan panjang total kurang dari 2000px