HTTP/3: Opsi Penerapan Praktis (Bagian 3)

Halo, dan selamat datang di angsuran terakhir dari seri tiga bagian ini pada protokol HTTP/3 dan QUIC yang baru! Jika setelah dua bagian sebelumnya — riwayat HTTP/3 dan konsep inti serta fitur kinerja HTTP/3 — Anda yakin bahwa mulai menggunakan protokol baru adalah ide yang bagus (dan memang seharusnya demikian!), maka bagian terakhir ini mencakup semua Anda perlu tahu untuk memulai!

Pertama, kita akan membahas perubahan mana yang perlu Anda buat pada halaman dan sumber daya Anda untuk menggunakan protokol baru secara optimal (itulah bagian yang mudah). Selanjutnya, kita akan melihat cara menyiapkan server dan klien (itulah bagian yang sulit kecuali Anda menggunakan jaringan pengiriman konten (CDN)). Terakhir, kita akan melihat alat mana yang dapat Anda gunakan untuk mengevaluasi dampak kinerja protokol baru (itu bagian yang hampir mustahil, setidaknya untuk saat ini).

Perubahan Pada Halaman Dan Sumber Daya

Mari kita mulai dengan kabar baik: Jika Anda sudah menggunakan HTTP/2, Anda mungkin tidak perlu mengubah apa pun pada halaman atau sumber daya Anda saat pindah ke HTTP/3! . Ini karena, seperti yang telah kami jelaskan di bagian 1 dan bagian 2, HTTP/3 benar-benar lebih mirip HTTP/2-over-QUIC, dan fitur tingkat tinggi dari kedua versi tetap sama. Dengan demikian, setiap perubahan atau pengoptimalan yang dilakukan untuk HTTP/2 akan tetap berfungsi untuk HTTP/3 dan sebaliknya.

Namun, jika Anda masih menggunakan HTTP/1.1, atau Anda lupa tentang transisi Anda ke HTTP/2, atau Anda tidak pernah benar-benar mengubah sesuatu untuk HTTP/2, maka Anda mungkin bertanya-tanya apa perubahan itu dan mengapa itu diperlukan. Namun, Anda akan kesulitan bahkan hari ini untuk menemukan artikel bagus yang merinci praktik terbaik bernuansa . Ini karena, seperti yang saya nyatakan dalam pengantar bagian 1, sebagian besar konten HTTP/2 awal terlalu optimis tentang seberapa baik praktiknya akan berhasil, dan beberapa di antaranya, sejujurnya, memiliki kesalahan besar dan saran yang buruk. Sayangnya, banyak dari informasi yang salah ini berlanjut hingga hari ini. Itulah salah satu motivasi utama saya dalam menulis seri ini di HTTP/3, untuk membantu mencegah hal itu terjadi lagi.

Sumber bernuansa all-in-one terbaik untuk HTTP/2 yang dapat saya rekomendasikan saat ini adalah buku HTTP/2 in Action oleh Barry Pollard. Namun, karena itu adalah sumber daya berbayar dan saya tidak ingin Anda menebak-nebak di sini, saya telah mencantumkan beberapa poin utama di bawah ini, bersama dengan bagaimana kaitannya dengan HTTP/3:

1. Koneksi Tunggal

Perbedaan terbesar antara HTTP/1.1 dan HTTP/2 adalah peralihan dari 6 ke 30 koneksi TCP paralel ke satu koneksi TCP yang mendasarinya. Kami membahas sedikit di bagian 2 bagaimana satu koneksi masih bisa secepat beberapa koneksi, karena bagaimana kontrol kemacetan dapat menyebabkan lebih banyak atau lebih awal kehilangan paket dengan lebih banyak koneksi (yang membatalkan manfaat dari awal agregat mereka yang lebih cepat). HTTP/3 melanjutkan pendekatan ini, tetapi "hanya" beralih dari satu TCP ke satu koneksi QUIC. Perbedaan ini sendiri tidak terlalu berpengaruh (terutama mengurangi overhead di sisi server), tetapi mengarah ke sebagian besar poin berikut.

2. Sharding Server dan Penggabungan Koneksi

Peralihan ke pengaturan koneksi tunggal cukup sulit dalam praktiknya karena banyak halaman di-sharding di berbagai nama host dan bahkan server (seperti img1.example.com dan img2.example.com ). Ini karena browser hanya membuka hingga enam koneksi untuk setiap nama host individu, jadi memiliki banyak koneksi memungkinkan lebih banyak koneksi! Tanpa perubahan pada pengaturan HTTP/1.1 ini, HTTP/2 masih akan membuka banyak koneksi, mengurangi seberapa baik fitur lain, seperti prioritas (lihat di bawah), sebenarnya dapat berfungsi.

Dengan demikian, rekomendasi awal adalah untuk membatalkan sharding server dan mengkonsolidasikan sumber daya pada satu server sebanyak mungkin. HTTP/2 bahkan menyediakan fitur untuk membuat transisi dari pengaturan HTTP/1.1 menjadi lebih mudah, yang disebut penggabungan koneksi. Secara kasar, jika dua nama host menyelesaikan ke IP server yang sama (menggunakan DNS) dan menggunakan sertifikat TLS yang serupa, maka browser dapat menggunakan kembali satu koneksi bahkan di dua nama host .

Dalam praktiknya, penggabungan koneksi bisa jadi sulit untuk dilakukan dengan benar, misalnya karena beberapa masalah keamanan halus yang melibatkan CORS. Bahkan jika Anda mengaturnya dengan benar, Anda masih dapat dengan mudah berakhir dengan dua koneksi terpisah. Masalahnya, itu tidak selalu buruk . Pertama, karena penerapan prioritas dan multiplexing yang buruk (lihat di bawah), koneksi tunggal dapat dengan mudah menjadi lebih lambat daripada menggunakan dua atau lebih. Kedua, menggunakan terlalu banyak koneksi dapat menyebabkan kehilangan paket awal karena pengontrol kemacetan yang bersaing. Namun, menggunakan hanya beberapa (tetapi masih lebih dari satu), dapat menyeimbangkan pertumbuhan kemacetan dengan kinerja yang lebih baik, terutama pada jaringan berkecepatan tinggi. Untuk alasan ini, saya percaya bahwa sedikit sharding masih merupakan ide yang bagus (katakanlah, dua hingga empat koneksi), bahkan dengan HTTP/2. Faktanya, saya pikir sebagian besar pengaturan HTTP/2 modern berkinerja sebaik yang mereka lakukan karena mereka masih memiliki beberapa koneksi tambahan atau beban pihak ketiga di jalur kritis mereka.

3. Bundling dan Inlining Sumber Daya

Di HTTP/1.1, Anda hanya dapat memiliki satu sumber daya aktif per koneksi, yang mengarah ke pemblokiran head-of-line (HoL) tingkat HTTP. Karena jumlah koneksi dibatasi hanya 6 hingga 30, bundling sumber daya (di mana subsumber daya yang lebih kecil digabungkan menjadi satu sumber daya yang lebih besar) adalah praktik terbaik untuk waktu yang lama. Kami masih melihat ini hari ini di bundler seperti Webpack. Demikian pula, sumber daya sering digarisbawahi di sumber daya lain (misalnya, CSS penting digarisbawahi dalam HTML).

Namun, dengan HTTP/2, koneksi tunggal menggandakan sumber daya, sehingga Anda dapat memiliki lebih banyak permintaan file yang luar biasa (dengan kata lain, satu permintaan tidak lagi memakan salah satu dari sedikit koneksi Anda yang berharga). Ini awalnya ditafsirkan sebagai, " Kami tidak perlu lagi menggabungkan atau memasukkan sumber daya kami untuk HTTP/2 ". Pendekatan ini disebut-sebut lebih baik untuk caching berbutir halus karena setiap subsumber daya dapat di-cache secara individual dan bundel lengkap tidak perlu diunduh ulang jika salah satunya berubah. Ini benar, tetapi hanya sampai batas yang relatif terbatas.

Misalnya, Anda dapat mengurangi efisiensi kompresi, karena itu bekerja lebih baik dengan lebih banyak data. Selain itu, setiap permintaan atau file tambahan memiliki overhead yang melekat karena perlu ditangani oleh browser dan server. Biaya ini dapat bertambah, katakanlah, ratusan file kecil dibandingkan dengan beberapa file besar. Dalam pengujian awal kami sendiri, saya menemukan pengembalian yang sangat berkurang pada sekitar 40 file. Meskipun angka tersebut mungkin sedikit lebih tinggi sekarang, permintaan file masih tidak semurah di HTTP/2 seperti yang diperkirakan semula . Terakhir, sumber daya yang tidak disisipkan memiliki biaya latensi tambahan karena file perlu diminta. Ini, dikombinasikan dengan prioritas dan masalah server push (lihat di bawah), berarti bahwa bahkan hari ini Anda masih lebih baik memasukkan beberapa CSS penting Anda. Mungkin suatu hari nanti proposal Kumpulan Sumber Daya akan membantu dalam hal ini, tetapi belum.

Semua ini, tentu saja, masih berlaku untuk HTTP/3 juga. Namun, saya telah membaca orang mengklaim bahwa banyak file kecil akan lebih baik daripada QUIC karena lebih banyak aliran independen yang aktif secara bersamaan berarti lebih banyak keuntungan dari penghapusan pemblokiran HoL (seperti yang kita bahas di bagian 2). Saya pikir mungkin ada beberapa kebenaran untuk ini, tetapi, seperti yang juga kita lihat di bagian 2, ini adalah masalah yang sangat kompleks dengan banyak parameter yang bergerak. Saya tidak berpikir manfaatnya akan lebih besar daripada biaya lain yang dibahas, tetapi penelitian lebih lanjut diperlukan. (Pemikiran yang keterlaluan adalah agar setiap file berukuran tepat agar sesuai dengan satu paket QUIC, melewati pemblokiran HoL sepenuhnya. Saya akan menerima royalti dari startup mana pun yang mengimplementasikan bundler sumber daya yang melakukan ini. ;))

4. Prioritas

Untuk dapat mengunduh banyak file pada satu koneksi, Anda perlu menggandakannya. Seperti yang dibahas di bagian 2, di HTTP/2, multiplexing ini dikendalikan menggunakan sistem prioritasnya. Inilah mengapa penting untuk meminta sumber daya sebanyak mungkin pada koneksi yang sama juga — untuk dapat memprioritaskannya dengan benar di antara satu sama lain! Akan tetapi, seperti yang juga kita lihat, sistem ini sangat kompleks , menyebabkannya sering digunakan dan diimplementasikan dengan buruk dalam praktiknya (lihat gambar di bawah). Ini, pada gilirannya, berarti bahwa beberapa rekomendasi lain untuk HTTP/2 — seperti pengurangan bundling, karena permintaannya murah, dan pengurangan server sharding, untuk memanfaatkan koneksi tunggal secara optimal (lihat di atas) — ternyata berkinerja buruk di praktek.

Sayangnya, ini adalah sesuatu yang Anda, sebagai pengembang web rata-rata, tidak dapat berbuat banyak, karena ini terutama merupakan masalah di browser dan server itu sendiri. Namun, Anda dapat mencoba mengurangi masalah dengan tidak menggunakan terlalu banyak file individual (yang akan menurunkan peluang untuk prioritas yang bersaing) dan dengan tetap menggunakan sharding (terbatas). Opsi lainnya adalah menggunakan berbagai teknik yang memengaruhi prioritas, seperti pemuatan lambat, JavaScript async dan defer , dan petunjuk sumber daya seperti preload . Secara internal, ini terutama mengubah prioritas sumber daya sehingga dikirim lebih awal atau lebih lambat. Namun, mekanisme ini dapat (dan memang) menderita bug. Selain itu, jangan berharap untuk menambahkan preload pada banyak sumber daya dan membuat segalanya lebih cepat: Jika semuanya tiba-tiba menjadi prioritas tinggi, maka tidak ada apa-apa! Bahkan sangat mudah untuk menunda sumber daya yang sangat penting dengan menggunakan hal-hal seperti preload .

Seperti yang juga dijelaskan di bagian 2, HTTP/3 secara mendasar mengubah internal sistem prioritas ini. Kami berharap ini berarti akan ada lebih sedikit bug dan masalah dengan penerapan praktisnya, jadi setidaknya beberapa di antaranya harus diselesaikan. Namun, kami belum dapat memastikannya, karena beberapa server dan klien HTTP/3 sepenuhnya menerapkan sistem ini saat ini. Namun demikian, konsep dasar penentuan prioritas tidak akan berubah . Anda tetap tidak akan dapat menggunakan teknik seperti preload tanpa benar-benar memahami apa yang terjadi secara internal, karena mungkin masih salah memprioritaskan sumber daya Anda.

5. Dorong Server dan Penerbangan Pertama

Server push memungkinkan server untuk mengirim data respons tanpa terlebih dahulu menunggu permintaan dari klien. Sekali lagi, ini kedengarannya bagus secara teori, dan ini bisa digunakan sebagai pengganti sumber daya inlining (lihat di atas). Namun, seperti yang dibahas di bagian 2, push sangat sulit digunakan dengan benar karena masalah dengan kontrol kemacetan, caching, prioritas, dan buffering. Secara keseluruhan, yang terbaik adalah tidak menggunakannya untuk memuat halaman web umum kecuali Anda benar- benar tahu apa yang Anda lakukan, dan bahkan itu mungkin akan menjadi optimasi mikro. Saya masih percaya itu bisa memiliki tempat dengan (REST) ​​API, meskipun, di mana Anda dapat mendorong subsumber daya yang ditautkan ke dalam respons (JSON) pada koneksi yang dihangatkan. Ini berlaku untuk HTTP/2 dan HTTP/3.

Untuk sedikit menggeneralisasi, saya merasa bahwa komentar serupa dapat dibuat untuk dimulainya kembali sesi TLS dan 0-RTT, baik melalui TCP + TLS atau melalui QUIC. Seperti yang dibahas di bagian 2, 0-RTT mirip dengan server push (seperti yang biasanya digunakan) karena mencoba mempercepat tahap pertama pemuatan halaman. Namun, itu berarti sama- sama terbatas dalam apa yang dapat dicapai pada saat itu (bahkan lebih di QUIC, karena masalah keamanan). Dengan demikian, optimasi mikro adalah, sekali lagi, bagaimana Anda mungkin perlu menyempurnakan hal-hal pada tingkat rendah untuk benar-benar mendapat manfaat darinya. Dan untuk berpikir saya pernah sangat bersemangat untuk mencoba menggabungkan server push dengan 0-RTT.

Apa Artinya Semua?

Semua hal di atas bermuara pada aturan praktis sederhana: Terapkan sebagian besar rekomendasi HTTP/2 khas yang Anda temukan online, tetapi jangan berlebihan .

Berikut adalah beberapa poin konkret yang sebagian besar berlaku untuk HTTP/2 dan HTTP/3:

1. Pecahkan sumber daya melalui sekitar satu hingga tiga koneksi di jalur kritis (kecuali sebagian besar pengguna Anda berada di jaringan bandwidth rendah), menggunakan preconnect dan dns-prefetch jika diperlukan.
2. Bundel subsumber daya secara logis per jalur atau fitur, atau per frekuensi perubahan. Lima hingga sepuluh JavaScript dan lima hingga sepuluh sumber daya CSS per halaman seharusnya baik-baik saja. Menyisipkan CSS penting masih bisa menjadi pengoptimalan yang baik.
3. Gunakan fitur kompleks, seperti preload , hemat.
4. Gunakan server yang mendukung prioritas HTTP/2 dengan benar. Untuk HTTP/2, saya merekomendasikan H2O. Apache dan NGINX sebagian besar OK (walaupun bisa lebih baik), sementara Node.js harus dihindari untuk HTTP/2. Untuk HTTP/3, hal-hal yang kurang jelas saat ini (lihat di bawah).
5. Pastikan TLS 1.3 diaktifkan di server web HTTP/2 Anda.

Seperti yang Anda lihat, meskipun jauh dari sederhana, mengoptimalkan halaman untuk HTTP/3 (dan HTTP/2) bukanlah ilmu roket. Namun, yang lebih sulit adalah menyiapkan server, klien, dan alat HTTP/3 dengan benar.

Server dan Jaringan

Seperti yang mungkin Anda pahami sekarang, QUIC dan HTTP/3 adalah protokol yang cukup kompleks. Menerapkannya dari awal akan melibatkan membaca (dan memahami!) ratusan halaman yang tersebar di lebih dari tujuh dokumen. Untungnya, beberapa perusahaan telah mengerjakan implementasi QUIC dan HTTP/3 open-source selama lebih dari lima tahun sekarang, jadi kami memiliki beberapa opsi yang matang dan stabil untuk dipilih.

Beberapa yang paling penting dan stabil adalah sebagai berikut:

Namun, banyak (mungkin sebagian besar) dari implementasi ini terutama menangani hal-hal HTTP/3 dan QUIC; mereka tidak benar-benar server web yang lengkap sendiri . Ketika datang ke server khas Anda (pikirkan NGINX, Apache, Node.js), semuanya menjadi sedikit lebih lambat, karena beberapa alasan. Pertama, beberapa pengembang mereka terlibat dengan HTTP/3 sejak awal, dan sekarang mereka harus mengejar ketinggalan. Banyak yang melewati ini dengan menggunakan salah satu implementasi yang tercantum di atas secara internal sebagai perpustakaan, tetapi integrasi itu pun sulit.

Kedua, banyak server bergantung pada perpustakaan TLS pihak ketiga seperti OpenSSL. Sekali lagi, ini karena TLS sangat kompleks dan harus aman, jadi sebaiknya gunakan kembali pekerjaan yang sudah ada dan terverifikasi. Namun, meskipun QUIC terintegrasi dengan TLS 1.3, QUIC menggunakannya dengan cara yang jauh berbeda dari cara TLS dan TCP berinteraksi . Ini berarti bahwa perpustakaan TLS harus menyediakan API khusus QUIC, yang telah lama enggan atau lambat dilakukan oleh pengembangnya. Masalah di sini terutama adalah OpenSSL, yang telah menunda dukungan QUIC, tetapi juga digunakan oleh banyak server. Masalah ini menjadi sangat buruk sehingga Akamai memutuskan untuk memulai fork OpenSSL khusus QUIC, yang disebut quictls. Sementara opsi dan solusi lain ada, dukungan TLS 1.3 untuk QUIC masih menjadi pemblokir untuk banyak server, dan diperkirakan akan tetap demikian untuk beberapa waktu.

Daftar sebagian server web lengkap yang seharusnya dapat Anda gunakan langsung, bersama dengan dukungan HTTP/3 mereka saat ini, adalah sebagai berikut:

• apache
  Dukungan tidak jelas saat ini. Tidak ada yang diumumkan. Kemungkinan juga membutuhkan OpenSSL. (Perhatikan bahwa ada implementasi Apache Traffic Server.)
• NGINX
  Ini adalah implementasi kustom. Ini relatif baru dan masih sangat eksperimental. Diharapkan akan bergabung ke NGINX arus utama pada akhir tahun 2021. Ini relatif baru dan masih sangat eksperimental. Perhatikan bahwa ada tambalan untuk menjalankan pustaka quiche Cloudflare di NGINX juga, yang mungkin lebih stabil untuk saat ini.
• Node.js
  Ini menggunakan perpustakaan ngtcp2 secara internal. Itu diblokir oleh kemajuan OpenSSL, meskipun mereka berencana untuk beralih ke garpu QUIC-TLS agar sesuatu bekerja lebih cepat.
• IIS
  Dukungan tidak jelas saat ini, dan tidak ada yang diumumkan. Ini kemungkinan akan menggunakan perpustakaan MsQuic secara internal.
• Hypercorn
  Ini mengintegrasikan aioquic, dengan dukungan eksperimental.
• kedi
  Ini menggunakan quic-go, dengan dukungan penuh.
• H2O
  Ini menggunakan dengan cepat, dengan dukungan penuh.
• Kecepatan Lite
  Ini menggunakan LSQUIC, dengan dukungan penuh.

Perhatikan beberapa nuansa penting:

• Bahkan "dukungan penuh" berarti "sebaik yang didapat saat ini", belum tentu "siap produksi". Misalnya, banyak implementasi yang belum sepenuhnya mendukung migrasi koneksi, 0-RTT, server push, atau prioritas HTTP/3 .
• Server lain yang tidak terdaftar, seperti Tomcat, (setahu saya) belum membuat pengumuman.
• Dari server web yang terdaftar, hanya Litespeed, patch NGINX Cloudflare, dan H2O yang dibuat oleh orang-orang yang terlibat erat dalam standarisasi QUIC dan HTTP/3, jadi ini kemungkinan besar akan bekerja paling baik sejak awal.
  

Seperti yang Anda lihat, lanskap server belum sepenuhnya ada, tetapi tentu saja sudah ada opsi untuk menyiapkan server HTTP/3. Namun, menjalankan server hanyalah langkah pertama. Mengonfigurasinya dan seluruh jaringan Anda lebih sulit.

konfigurasi jaringan

Seperti yang dijelaskan di bagian 1, QUIC berjalan di atas protokol UDP untuk mempermudah penerapan. Namun, ini hanya berarti bahwa sebagian besar perangkat jaringan dapat menguraikan dan memahami UDP. Sayangnya, itu tidak berarti bahwa UDP diperbolehkan secara universal . Karena UDP sering digunakan untuk serangan dan tidak penting untuk pekerjaan normal sehari-hari selain DNS, banyak jaringan (perusahaan) dan firewall memblokir protokol hampir seluruhnya. Dengan demikian, UDP mungkin perlu secara eksplisit diizinkan ke/dari server HTTP/3 Anda . QUIC dapat berjalan pada port UDP mana pun tetapi mengharapkan port 443 (yang biasanya juga digunakan untuk HTTPS melalui TCP) menjadi yang paling umum.

Namun, banyak administrator jaringan tidak ingin hanya mengizinkan grosir UDP. Sebagai gantinya, mereka secara khusus ingin mengizinkan QUIC melalui UDP. Masalahnya adalah, seperti yang telah kita lihat, QUIC hampir seluruhnya dienkripsi. Ini termasuk metadata tingkat QUIC seperti nomor paket, tetapi juga, misalnya, sinyal yang menunjukkan penutupan koneksi. Untuk TCP, firewall secara aktif melacak semua metadata ini untuk memeriksa perilaku yang diharapkan. (Apakah kita melihat jabat tangan penuh sebelum paket pembawa data? Apakah paket mengikuti pola yang diharapkan? Berapa banyak koneksi terbuka yang ada?) Seperti yang kita lihat di bagian 1, inilah salah satu alasan mengapa TCP praktis tidak lagi dapat berevolusi. Namun, karena enkripsi QUIC, firewall dapat melakukan lebih sedikit logika pelacakan tingkat koneksi ini , dan beberapa bit yang dapat mereka periksa relatif kompleks.

Karena itu, banyak vendor firewall saat ini merekomendasikan pemblokiran QUIC hingga mereka dapat memperbarui perangkat lunak mereka. Bahkan setelah itu, banyak perusahaan mungkin tidak mengizinkannya, karena dukungan firewall QUIC akan selalu jauh lebih sedikit daripada fitur TCP yang biasa mereka gunakan.

Ini semua menjadi lebih rumit dengan fitur migrasi koneksi. Seperti yang telah kita lihat, fitur ini memungkinkan koneksi untuk melanjutkan dari alamat IP baru tanpa harus melakukan jabat tangan baru, dengan menggunakan ID koneksi (CID). Namun, untuk firewall, ini akan terlihat seolah-olah koneksi baru sedang digunakan tanpa terlebih dahulu menggunakan jabat tangan, yang mungkin juga merupakan penyerang yang mengirimkan lalu lintas berbahaya. Firewall tidak bisa hanya menggunakan QUIC CID, karena mereka juga berubah seiring waktu untuk melindungi privasi pengguna! Dengan demikian, akan ada beberapa kebutuhan bagi server untuk berkomunikasi dengan firewall tentang CID mana yang diharapkan , tetapi hal-hal ini belum ada.

Ada kekhawatiran serupa untuk penyeimbang beban untuk pengaturan skala yang lebih besar. Mesin-mesin ini mendistribusikan koneksi masuk melalui sejumlah besar server back-end. Lalu lintas untuk satu koneksi harus, tentu saja, selalu diarahkan ke server back-end yang sama (yang lain tidak akan tahu apa yang harus dilakukan dengannya!). Untuk TCP, ini hanya bisa dilakukan berdasarkan 4-tupel, karena itu tidak pernah berubah. Namun, dengan migrasi koneksi QUIC, itu bukan lagi pilihan. Sekali lagi, server dan penyeimbang beban perlu menyepakati CID mana yang harus dipilih untuk mengizinkan perutean deterministik . Tidak seperti untuk konfigurasi firewall, bagaimanapun, sudah ada proposal untuk mengatur ini (walaupun ini jauh dari implementasi secara luas).

Terakhir, ada pertimbangan keamanan tingkat tinggi lainnya, terutama seputar serangan 0-RTT dan penyangkalan layanan (DDoS). Seperti yang dibahas di bagian 2, QUIC sudah menyertakan beberapa mitigasi untuk masalah ini, tetapi idealnya, mereka juga akan menggunakan garis pertahanan ekstra di jaringan. Misalnya, server proxy atau tepi mungkin memblokir permintaan 0-RTT tertentu agar tidak mencapai ujung belakang yang sebenarnya untuk mencegah serangan pemutaran ulang. Alternatifnya, untuk mencegah serangan refleksi atau serangan DDoS yang hanya mengirim paket handshake pertama dan kemudian berhenti membalas (disebut SYN flood di TCP), QUIC menyertakan fitur coba lagi. Ini memungkinkan server untuk memvalidasi bahwa itu adalah klien yang berperilaku baik, tanpa harus mempertahankan status apa pun untuk sementara (setara dengan cookie TCP SYN). Proses coba ulang ini paling baik terjadi, tentu saja, di suatu tempat sebelum server back-end — misalnya, di penyeimbang beban. Sekali lagi, ini membutuhkan konfigurasi dan komunikasi tambahan untuk diatur.

Ini hanya masalah paling menonjol yang akan dimiliki administrator jaringan dan sistem dengan QUIC dan HTTP/3. Ada beberapa lagi, beberapa di antaranya telah saya bicarakan. Ada juga dua dokumen terpisah yang menyertai untuk RFC QUIC yang membahas masalah ini dan kemungkinan mitigasinya (sebagian).

Apa Artinya Semua?

HTTP/3 dan QUIC adalah protokol kompleks yang mengandalkan banyak mesin internal. Tidak semua itu siap untuk prime time dulu , meskipun Anda sudah memiliki beberapa opsi untuk menerapkan protokol baru di ujung belakang Anda. Namun, mungkin perlu beberapa bulan hingga bertahun-tahun untuk server yang paling menonjol dan pustaka yang mendasarinya (seperti OpenSSL) untuk diperbarui.

Meskipun demikian, mengonfigurasi server dan perantara jaringan lainnya dengan benar, sehingga protokol dapat digunakan dengan cara yang aman dan optimal, tidak akan sepele dalam pengaturan skala yang lebih besar. Anda akan membutuhkan tim pengembangan dan operasi yang baik untuk melakukan transisi ini dengan benar.

Karena itu, terutama di masa-masa awal, mungkin yang terbaik adalah mengandalkan perusahaan hosting besar atau CDN untuk menyiapkan dan mengonfigurasi protokol untuk Anda. Seperti yang dibahas di bagian 2, di situlah QUIC kemungkinan besar akan membuahkan hasil, dan menggunakan CDN adalah salah satu pengoptimalan kinerja utama yang dapat Anda lakukan. Saya pribadi akan merekomendasikan menggunakan Cloudflare atau Fastly karena mereka telah terlibat erat dalam proses standardisasi dan akan memiliki implementasi yang paling canggih dan disetel dengan baik.

Klien dan QUIC Discovery

Sejauh ini, kami telah mempertimbangkan dukungan sisi server dan dalam jaringan untuk protokol baru. Namun, beberapa masalah juga harus diatasi di sisi klien.

Sebelum membahasnya, mari kita mulai dengan kabar baik: Sebagian besar browser populer sudah memiliki dukungan HTTP/3 (eksperimental)! Secara khusus, pada saat penulisan, berikut adalah status dukungan (lihat juga caniuse.com):

• Google Chrome (versi 91+) : Diaktifkan secara default.
• Mozilla Firefox (versi 89+) : Diaktifkan secara default.
• Microsoft Edge (versi 90+) : Diaktifkan secara default (menggunakan Chromium secara internal).
• Opera (versi 77+) : Diaktifkan secara default (menggunakan Chromium secara internal).
• Apple Safari (versi 14) : Di belakang bendera manual. Akan diaktifkan secara default di versi 15, yang saat ini dalam pratinjau teknologi.
• Peramban Lain : Belum ada sinyal yang saya ketahui (walaupun peramban lain yang menggunakan Chromium secara internal, seperti Brave, secara teori, dapat juga mulai mengaktifkannya).

Perhatikan beberapa nuansa:

• Sebagian besar browser diluncurkan secara bertahap, di mana tidak semua pengguna akan mendapatkan dukungan HTTP/3 yang diaktifkan secara default sejak awal. Ini dilakukan untuk membatasi risiko bahwa satu bug yang diabaikan dapat memengaruhi banyak pengguna atau bahwa penerapan server menjadi kelebihan beban. Dengan demikian, ada kemungkinan kecil bahwa, bahkan dalam versi browser terbaru, Anda tidak akan mendapatkan HTTP/3 secara default dan harus mengaktifkannya secara manual.
• Seperti halnya server, dukungan HTTP/3 tidak berarti bahwa semua fitur telah diimplementasikan atau sedang digunakan saat ini. Khususnya, 0-RTT, migrasi koneksi, server push, kompresi header QPACK dinamis, dan prioritas HTTP/3 mungkin masih hilang, dinonaktifkan, digunakan dengan hemat, atau dikonfigurasi dengan buruk.
• Jika Anda ingin menggunakan HTTP/3 sisi klien di luar browser (misalnya, di aplikasi asli Anda), maka Anda harus mengintegrasikan salah satu perpustakaan yang tercantum di atas atau menggunakan cURL. Apple akan segera menghadirkan dukungan HTTP/3 dan QUIC asli ke pustaka jaringan bawaannya di macOS dan iOS, dan Microsoft menambahkan QUIC ke kernel Windows dan lingkungan .NET mereka, tetapi dukungan asli yang serupa (sepengetahuan saya) belum diumumkan untuk sistem lain seperti Android.

Alt-Svc

Bahkan jika Anda telah menyiapkan server yang kompatibel dengan HTTP/3 dan menggunakan browser yang diperbarui, Anda mungkin terkejut menemukan bahwa HTTP/3 sebenarnya tidak digunakan secara konsisten . Untuk memahami alasannya, anggaplah Anda adalah browser sejenak. Pengguna Anda telah meminta Anda menavigasi ke example.com (situs web yang belum pernah Anda kunjungi sebelumnya), dan Anda telah menggunakan DNS untuk menyelesaikannya menjadi IP. Anda mengirim satu atau lebih paket jabat tangan QUIC ke IP itu. Sekarang beberapa hal bisa salah:

1. Server mungkin tidak mendukung QUIC.
2. Salah satu jaringan perantara atau firewall mungkin memblokir QUIC dan/atau UDP sepenuhnya.
3. Paket jabat tangan mungkin hilang dalam perjalanan.

Namun, bagaimana Anda tahu (yang mana) salah satu dari masalah ini telah terjadi ? Dalam ketiga kasus tersebut, Anda tidak akan pernah menerima balasan untuk paket jabat tangan Anda. Satu-satunya hal yang dapat Anda lakukan adalah menunggu, berharap balasan mungkin masih masuk. Kemudian, setelah beberapa waktu menunggu (batas waktu), Anda mungkin memutuskan bahwa memang ada masalah dengan HTTP/3. Pada saat itu, Anda akan mencoba membuka koneksi TCP ke server, berharap HTTP/2 atau HTTP/1.1 akan berfungsi.

Seperti yang Anda lihat, jenis pendekatan ini dapat menyebabkan penundaan besar, terutama di tahun-tahun awal ketika banyak server dan jaringan belum mendukung QUIC. Solusi yang mudah namun naif adalah dengan membuka koneksi QUIC dan TCP pada saat yang sama dan kemudian menggunakan handshake mana yang lebih dulu selesai . Metode ini disebut “connection racing” atau “happy eyeballs”. Meskipun ini tentu mungkin, itu memang memiliki overhead yang cukup besar. Meskipun koneksi yang terputus hampir segera ditutup, masih memakan beberapa memori dan waktu CPU pada klien dan server (terutama saat menggunakan TLS). Selain itu, ada juga masalah lain dengan metode ini yang melibatkan jaringan IPv4 versus IPv6 dan serangan replay yang telah dibahas sebelumnya (yang dibahas lebih detail).

Dengan demikian, untuk QUIC dan HTTP/3, browser lebih memilih untuk memainkannya dengan aman dan hanya mencoba QUIC jika mereka tahu server mendukungnya . Dengan demikian, pertama kali server baru dihubungi, browser hanya akan menggunakan HTTP/2 atau HTTP/1.1 melalui koneksi TCP. Server kemudian dapat memberi tahu browser bahwa ia juga mendukung HTTP/3 untuk koneksi berikutnya. Ini dilakukan dengan menyetel header HTTP khusus pada respons yang dikirim kembali melalui HTTP/2 atau HTTP/1.1. Header ini disebut Alt-Svc , yang merupakan singkatan dari "layanan alternatif". Alt-Svc dapat digunakan untuk memberi tahu browser bahwa layanan tertentu juga dapat dijangkau melalui server lain (IP dan/atau port), tetapi juga memungkinkan indikasi protokol alternatif. Hal ini dapat dilihat di bawah ini pada gambar 1.

Setelah menerima header Alt-Svc yang valid yang menunjukkan dukungan HTTP/3, browser akan menyimpannya di cache dan mencoba mengatur koneksi QUIC sejak saat itu. Beberapa klien akan melakukan ini sesegera mungkin (bahkan selama pemuatan halaman awal — lihat di bawah), sementara yang lain akan menunggu hingga koneksi TCP yang ada ditutup. Ini berarti bahwa browser hanya akan menggunakan HTTP/3 setelah mengunduh setidaknya beberapa sumber melalui HTTP/2 atau HTTP/1.1 terlebih dahulu . Bahkan kemudian, itu tidak mulus. Browser sekarang mengetahui bahwa server mendukung HTTP/3, tetapi itu tidak berarti jaringan perantara tidak akan memblokirnya. Dengan demikian, balap koneksi masih diperlukan dalam praktik. Jadi, Anda mungkin masih berakhir dengan HTTP/2 jika jaringan entah bagaimana cukup menunda jabat tangan QUIC. Selain itu, jika koneksi QUIC gagal dibuat beberapa kali berturut-turut, beberapa browser akan menempatkan entri cache Alt-Svc pada daftar yang ditolak untuk beberapa waktu, tidak mencoba HTTP/3 untuk sementara waktu. Dengan demikian, akan sangat membantu jika Anda secara manual menghapus cache browser Anda jika ada yang salah karena itu juga akan mengosongkan binding Alt-Svc . Terakhir, Alt-Svc telah terbukti menimbulkan beberapa risiko keamanan yang serius. Karena alasan ini, beberapa browser memberikan batasan tambahan, misalnya, port mana yang dapat digunakan (di Chrome, server HTTP/2 dan HTTP/3 Anda harus berada pada port di bawah 1024 atau keduanya pada port di atas atau sama hingga 1024, jika tidak Alt-Svc akan diabaikan). Semua logika ini bervariasi dan berkembang pesat di antara browser, artinya mendapatkan koneksi HTTP/3 yang konsisten bisa jadi sulit , yang juga membuatnya sulit untuk menguji penyiapan baru.

Ada pekerjaan yang sedang berlangsung untuk meningkatkan proses Alt-Svc dua langkah ini. Idenya adalah menggunakan catatan DNS baru yang disebut SVCB dan HTTPS, yang akan berisi informasi yang mirip dengan apa yang ada di Alt-Svc . Dengan demikian, klien dapat menemukan bahwa server mendukung HTTP/3 selama langkah resolusi DNS, yang berarti bahwa ia dapat mencoba QUIC dari pemuatan halaman pertama alih-alih terlebih dahulu harus melalui HTTP/2 atau HTTP/1.1. Untuk informasi lebih lanjut tentang ini dan Alt-Svc , lihat bab Web Almanac tahun lalu tentang HTTP/2.

Seperti yang Anda lihat, Alt-Svc dan proses penemuan HTTP/3 menambahkan lapisan kompleksitas pada penerapan server QUIC Anda yang sudah menantang, karena:

• Anda akan selalu perlu menggunakan server HTTP/3 Anda di sebelah server HTTP/2 dan/atau HTTP/1.1;
• Anda perlu mengonfigurasi server HTTP/2 dan HTTP/1.1 Anda untuk menyetel header Alt-Svc yang benar pada respons mereka.

Meskipun itu harus dapat dikelola dalam pengaturan tingkat produksi (karena, misalnya, satu instance Apache atau NGINX kemungkinan akan mendukung ketiga versi HTTP secara bersamaan), itu mungkin jauh lebih mengganggu di set pengujian (lokal)- ups (saya sudah bisa melihat diri saya lupa menambahkan header Alt-Svc atau mengacaukannya). Masalah ini diperparah oleh kurangnya log kesalahan browser dan indikator DevTools (saat ini), yang berarti bahwa mencari tahu mengapa tepatnya pengaturan tidak berfungsi bisa jadi sulit.

Masalah Tambahan

Seolah itu belum cukup, masalah lain akan membuat pengujian lokal lebih sulit: Chrome mempersulit Anda menggunakan sertifikat TLS yang ditandatangani sendiri untuk QUIC . Ini karena sertifikat TLS tidak resmi sering digunakan oleh perusahaan untuk mendekripsi lalu lintas TLS karyawan mereka (sehingga mereka dapat, misalnya, firewall mereka memindai di dalam lalu lintas terenkripsi). Namun, jika perusahaan akan mulai melakukannya dengan QUIC, kami akan kembali memiliki implementasi middlebox khusus yang membuat asumsi mereka sendiri tentang protokol. Ini dapat menyebabkan mereka berpotensi melanggar dukungan protokol di masa depan, yang persis seperti yang kami coba cegah dengan mengenkripsi QUIC secara ekstensif sejak awal! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

Apa Artinya Semua?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Mercusuar Google

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog dan qvis

Seperti yang ditunjukkan oleh diskusi di atas, mungkin sulit untuk menganalisis perilaku HTTP/3 hanya dengan menggunakan Lighthouse atau WebPageTest pada saat ini. Untungnya, alat tingkat rendah lainnya tersedia untuk membantu dalam hal ini. Pertama, alat Wireshark yang luar biasa memiliki dukungan lanjutan untuk QUIC, dan juga dapat membedah HTTP/3 secara eksperimental. Ini memungkinkan Anda untuk mengamati paket QUIC dan HTTP/3 mana yang benar-benar melewati kabel. Namun, agar itu berfungsi, Anda perlu mendapatkan kunci dekripsi TLS untuk koneksi tertentu, yang sebagian besar implementasi (termasuk Chrome dan Firefox) memungkinkan Anda mengekstraknya dengan menggunakan variabel lingkungan SSLKEYLOGFILE . Meskipun ini dapat berguna untuk beberapa hal, benar-benar mencari tahu apa yang terjadi, terutama untuk koneksi yang lebih lama, dapat memerlukan banyak pekerjaan manual. Anda juga memerlukan pemahaman yang cukup maju tentang cara kerja protokol.

Untungnya, ada opsi kedua, qlog dan qvis. qlog adalah format logging berbasis JSON khusus untuk QUIC dan HTTP/3 yang didukung oleh sebagian besar implementasi QUIC. Alih-alih melihat paket yang melewati kabel, qlog menangkap informasi ini di klien dan server secara langsung, yang memungkinkannya memasukkan beberapa informasi tambahan (misalnya, detail kontrol kemacetan). Biasanya, Anda dapat memicu keluaran qlog saat memulai server dan klien dengan variabel lingkungan QLOGDIR . (Perhatikan bahwa di Firefox, Anda perlu menyetel preferensi network.http.http3.enable_qlog . Perangkat Apple dan Safari menggunakan QUIC_LOG_DIRECTORY sebagai gantinya. Chrome belum mendukung qlog.)

File qlog ini kemudian dapat diunggah ke qvis tool suite di qvis.quictools.info. Di sana, Anda akan mendapatkan sejumlah visualisasi interaktif lanjutan yang memudahkan interpretasi lalu lintas QUIC dan HTTP/3 . qvis juga memiliki dukungan untuk mengunggah tangkapan paket Wireshark (file .pcap ), dan memiliki dukungan eksperimental untuk file netlog Chrome, sehingga Anda juga dapat menganalisis perilaku Chrome. Sebuah tutorial lengkap tentang qlog dan qvis berada di luar cakupan artikel ini, tetapi rincian lebih lanjut dapat ditemukan dalam bentuk tutorial, sebagai makalah, dan bahkan dalam format talk-show. Anda juga bisa bertanya langsung kepada saya karena saya adalah pelaksana utama dari qlog dan qvis. ;)

Namun, saya tidak yakin bahwa sebagian besar pembaca di sini harus pernah menggunakan Wireshark atau qvis, karena ini adalah alat tingkat rendah. Namun, karena kami memiliki beberapa alternatif saat ini, saya sangat menyarankan untuk tidak menguji kinerja HTTP/3 secara ekstensif tanpa menggunakan alat jenis ini , untuk memastikan Anda benar-benar tahu apa yang terjadi dan apakah yang Anda lihat benar-benar dijelaskan oleh internal protokol dan bukan oleh faktor lain.

Apa Artinya Semua?

Seperti yang telah kita lihat, menyiapkan dan menggunakan HTTP/3 melalui QUIC bisa menjadi urusan yang rumit, dan banyak hal bisa salah. Sayangnya, tidak ada alat atau visualisasi yang baik tersedia yang memaparkan detail yang diperlukan pada tingkat abstraksi yang sesuai. Hal ini mempersulit sebagian besar pengembang untuk menilai potensi manfaat yang dapat dibawa HTTP/3 ke situs web mereka saat ini atau bahkan untuk memvalidasi bahwa penyiapan mereka berfungsi seperti yang diharapkan.

Mengandalkan hanya pada metrik tingkat tinggi sangat berbahaya karena dapat dipengaruhi oleh banyak faktor (seperti emulasi jaringan yang tidak realistis, kurangnya fitur pada klien atau server, hanya sebagian penggunaan HTTP/3, dll.). Bahkan jika semuanya bekerja lebih baik, seperti yang telah kita lihat di bagian 2, perbedaan antara HTTP/2 dan HTTP/3 kemungkinan akan relatif kecil dalam banyak kasus, yang membuatnya semakin sulit untuk mendapatkan informasi yang diperlukan dari tingkat tinggi. alat tanpa dukungan HTTP/3 yang ditargetkan.

Karena itu, saya sarankan untuk membiarkan pengukuran kinerja HTTP/2 versus HTTP/3 sendiri selama beberapa bulan lagi dan sebagai gantinya berfokus untuk memastikan bahwa penyiapan sisi server kami berfungsi seperti yang diharapkan . Untuk ini, paling mudah menggunakan WebPageTest dalam kombinasi dengan parameter baris perintah Google Chrome, dengan fallback to curl untuk kemungkinan masalah — ini adalah penyiapan paling konsisten yang dapat saya temukan saat ini.

Kesimpulan dan Takeaways

Pembaca yang budiman, jika Anda telah membaca seri tiga bagian penuh dan berhasil sampai di sini, saya salut ! Bahkan jika Anda hanya membaca beberapa bagian, saya berterima kasih atas minat Anda pada protokol baru dan menarik ini. Sekarang, saya akan merangkum hal-hal penting dari seri ini, memberikan beberapa rekomendasi utama untuk bulan dan tahun mendatang, dan akhirnya memberi Anda beberapa sumber tambahan, jika Anda ingin tahu lebih banyak.

Ringkasan

Pertama, di bagian 1, kita membahas bahwa HTTP/3 diperlukan terutama karena protokol transport QUIC baru yang mendasarinya . QUIC adalah penerus spiritual TCP, dan mengintegrasikan semua praktik terbaiknya, serta TLS 1.3. Ini terutama diperlukan karena TCP, karena penyebaran dan integrasinya di mana-mana di kotak tengah, menjadi terlalu tidak fleksibel untuk berkembang. Penggunaan UDP oleh QUIC dan enkripsi yang hampir penuh berarti bahwa kami (semoga) hanya perlu memperbarui titik akhir di masa mendatang untuk menambahkan fitur baru, yang seharusnya lebih mudah. QUIC, bagaimanapun, juga menambahkan beberapa kemampuan baru yang menarik. Pertama, transpor gabungan dan jabat tangan kriptografis QUIC lebih cepat daripada TCP + TLS, dan dapat memanfaatkan fitur 0-RTT dengan baik. Kedua, QUIC mengetahui bahwa ia membawa beberapa aliran byte independen dan dapat lebih cerdas dalam menangani kehilangan dan penundaan, mengurangi masalah pemblokiran head-of-line. Ketiga, koneksi QUIC dapat bertahan dari pengguna yang pindah ke jaringan yang berbeda (disebut migrasi koneksi) dengan menandai setiap paket dengan ID koneksi. Akhirnya, struktur paket fleksibel QUIC (menggunakan frame) membuatnya lebih efisien tetapi juga lebih fleksibel dan dapat diperluas di masa depan. Kesimpulannya, jelas bahwa QUIC adalah protokol transport generasi berikutnya dan akan digunakan dan diperpanjang selama bertahun-tahun yang akan datang .

Kedua, di bagian 2, kami melihat secara kritis fitur-fitur baru ini, terutama implikasi kinerjanya . Pertama, kami melihat bahwa penggunaan UDP oleh QUIC tidak secara ajaib membuatnya lebih cepat (atau lebih lambat) karena QUIC menggunakan mekanisme kontrol kemacetan yang sangat mirip dengan TCP untuk mencegah kelebihan beban jaringan. Kedua, jabat tangan yang lebih cepat dan 0-RTT lebih merupakan pengoptimalan mikro, karena keduanya benar-benar hanya satu perjalanan pulang pergi lebih cepat daripada tumpukan TCP + TLS yang dioptimalkan, dan 0-RTT QUIC yang sebenarnya lebih jauh dipengaruhi oleh berbagai masalah keamanan yang dapat membatasi kegunaannya. Ketiga, migrasi koneksi benar-benar hanya diperlukan dalam beberapa kasus tertentu, dan itu masih berarti mengatur ulang kecepatan pengiriman karena kontrol kemacetan tidak mengetahui berapa banyak data yang dapat ditangani oleh jaringan baru. Keempat, keefektifan penghapusan pemblokiran head-of-line QUIC sangat bergantung pada bagaimana data aliran dimultipleks dan diprioritaskan. Pendekatan yang optimal untuk memulihkan dari packet loss tampaknya merugikan kasus penggunaan umum kinerja pemuatan halaman web dan sebaliknya, meskipun penelitian lebih lanjut diperlukan. Kelima, QUIC dapat dengan mudah mengirim paket lebih lambat daripada TCP + TLS, karena API UDP kurang matang dan QUIC mengenkripsi setiap paket secara individual, meskipun ini sebagian besar dapat dikurangi pada waktunya. Keenam, HTTP/3 sendiri tidak benar-benar menghadirkan fitur kinerja baru yang utama, tetapi terutama mengerjakan ulang dan menyederhanakan internal fitur HTTP/2 yang diketahui. Terakhir, beberapa fitur terkait kinerja paling menarik yang memungkinkan QUIC (multipath, data yang tidak dapat diandalkan, WebTransport, koreksi kesalahan penerusan, dll.) bukan merupakan bagian dari standar inti QUIC dan HTTP/3, melainkan merupakan ekstensi yang diusulkan yang akan mengambil beberapa waktu lagi yang akan tersedia. Kesimpulannya, ini berarti QUIC mungkin tidak akan banyak meningkatkan kinerja bagi pengguna di jaringan berkecepatan tinggi, tetapi terutama akan penting bagi mereka yang berada di jaringan yang lambat dan kurang stabil .

Terakhir, di bagian 3 ini, kita melihat cara praktis menggunakan dan menerapkan QUIC dan HTTP/3 . Pertama, kami melihat bahwa sebagian besar praktik terbaik dan pelajaran yang dipetik dari HTTP/2 seharusnya diteruskan ke HTTP/3. Tidak perlu mengubah strategi bundling atau inlining Anda, atau mengkonsolidasikan atau memisahkan server farm Anda. Server push masih bukan fitur terbaik untuk digunakan, dan preload juga bisa menjadi footgun yang kuat. Kedua, kami telah membahas bahwa mungkin perlu beberapa saat sebelum paket server web siap pakai menyediakan dukungan HTTP/3 penuh (sebagian karena masalah dukungan pustaka TLS), meskipun banyak opsi sumber terbuka tersedia untuk pengguna awal dan beberapa CDN utama memiliki penawaran yang matang. Ketiga, jelas bahwa sebagian besar browser utama memiliki dukungan HTTP/3 (dasar), bahkan diaktifkan secara default. Ada perbedaan besar dalam bagaimana dan kapan mereka menggunakan HTTP/3 dan fitur-fitur barunya secara praktis, jadi memahami perilaku mereka bisa jadi menantang. Keempat, kita telah membahas bahwa hal ini diperburuk oleh kurangnya dukungan HTTP/3 eksplisit pada alat populer seperti Lighthouse dan WebPageTest, sehingga sangat sulit untuk membandingkan kinerja HTTP/3 dengan HTTP/2 dan HTTP/1.1 saat ini. Kesimpulannya, HTTP/3 dan QUIC mungkin belum siap untuk primetime, tetapi mereka akan segera .

Rekomendasi

Dari ringkasan di atas, sepertinya saya membuat argumen yang kuat untuk tidak menggunakan QUIC atau HTTP/3. Namun, itu sangat berlawanan dengan poin yang ingin saya sampaikan.

Pertama, seperti yang dibahas di akhir bagian 2, meskipun pengguna "rata-rata" Anda mungkin tidak mengalami peningkatan kinerja yang besar (bergantung pada target pasar Anda), sebagian besar audiens Anda kemungkinan akan melihat peningkatan yang mengesankan . 0-RTT mungkin hanya menghemat satu perjalanan pulang pergi, tetapi itu masih bisa berarti beberapa ratus milidetik untuk beberapa pengguna. Migrasi koneksi mungkin tidak mendukung unduhan cepat secara konsisten, tetapi pasti akan membantu orang yang mencoba mengambil PDF itu di kereta berkecepatan tinggi. Kehilangan paket pada kabel mungkin meledak, tetapi tautan nirkabel mungkin lebih diuntungkan dari penghapusan pemblokiran head-of-line QUIC. Terlebih lagi, pengguna ini adalah mereka yang biasanya akan menghadapi kinerja terburuk dari produk Anda dan, akibatnya, paling terpengaruh olehnya. Jika Anda bertanya-tanya mengapa itu penting, baca anekdot kinerja web Chris Zacharias yang terkenal.

Kedua, QUIC dan HTTP/3 hanya akan menjadi lebih baik dan lebih cepat dari waktu ke waktu . Versi 1 telah berfokus untuk menyelesaikan protokol dasar, menjaga fitur kinerja yang lebih canggih untuk nanti. Karena itu, saya merasa membayar untuk mulai berinvestasi dalam protokol sekarang, untuk memastikan Anda dapat menggunakannya dan fitur-fitur baru untuk efek yang optimal ketika tersedia di telepon. Mengingat kerumitan protokol dan aspek penerapannya, akan lebih baik jika Anda meluangkan waktu untuk mengenal kebiasaan mereka. Bahkan jika Anda belum ingin mengotori tangan Anda, beberapa penyedia CDN utama menawarkan dukungan HTTP/3 “flip the switch” yang matang (khususnya, Cloudflare dan Fastly). Saya berjuang untuk menemukan alasan untuk tidak mencobanya jika Anda menggunakan CDN (yang, jika Anda peduli dengan kinerja, Anda seharusnya begitu).

Karena itu, meskipun saya tidak akan mengatakan bahwa sangat penting untuk mulai menggunakan QUIC dan HTTP/3 sesegera mungkin, saya merasa ada banyak manfaat yang bisa didapat, dan itu hanya akan meningkat di masa mendatang .

Bacaan lebih lanjut

Meskipun ini merupakan kumpulan teks yang panjang, sayangnya, ini benar-benar hanya menggores permukaan teknis dari protokol kompleks seperti QUIC dan HTTP/3.

Di bawah ini Anda akan menemukan daftar sumber daya tambahan untuk pembelajaran lanjutan, kurang lebih dalam urutan kedalaman teknis:

• “HTTP/3 Dijelaskan,” Daniel Stenberg
  E-book ini, oleh pencipta cURL, merangkum protokol.
• “HTTP/2 beraksi,” Barry Pollard
  Buku serba bagus tentang HTTP/2 ini memiliki saran yang dapat digunakan kembali dan bagian tentang HTTP/3.
• @programmingart, Twitter
  Tweet saya sebagian besar didedikasikan untuk QUIC, HTTP/3, dan kinerja web (termasuk berita) secara umum. Lihat misalnya utas terbaru saya tentang fitur QUIC.
• “YouTube,” Robin Marx
  Lebih dari 10 pembicaraan mendalam saya mencakup berbagai aspek protokol.
• “Blog Cloudlare”
  Ini adalah produk utama dari perusahaan yang juga menjalankan CDN di samping.
• “Blog Cepat”
  Blog ini memiliki diskusi yang sangat baik tentang aspek teknis, tertanam dalam konteks yang lebih luas.
• QUIC, RFC yang sebenarnya
  Anda akan menemukan tautan ke dokumen IETF QUIC dan HTTP/3 RFC dan ekstensi resmi lainnya.
• Blog Insinyur IIJ: Penjelasan teknis mendalam yang luar biasa tentang detail fitur QUIC.
• Makalah akademik HTTP/3 dan QUIC, Robin Marx
  Makalah penelitian saya mencakup multiplexing aliran dan prioritas, perkakas, dan perbedaan implementasi.
• QUIPS, EPIQ 2018, dan EPIQ 2020
  Makalah dari lokakarya akademik ini berisi penelitian mendalam tentang keamanan, kinerja, dan perluasan protokol.

Dengan itu, saya meninggalkan Anda, pembaca yang budiman, dengan pemahaman yang diharapkan jauh lebih baik tentang dunia baru yang berani ini. Saya selalu terbuka untuk umpan balik, jadi beri tahu saya pendapat Anda tentang seri ini!