Perbandingan kinerja HTTP / 3 dan HTTP / 2

Kami di Cloudflare mengumumkan dukungan HTTP / 3 September lalu ketika kami merayakan ulang tahun kesembilan kami . Tujuan kami selalu untuk meningkatkan Internet. Kolaborasi dalam bidang standar merupakan bagian penting dari proses, dan kami beruntung terlibat dalam pengembangan HTTP / 3.

Meskipun HTTP / 3 masih dalam tahap konsep, kami melihat minat yang besar pada protokol baru dari pengguna kami (infrastruktur Cloudflare melayani lebih dari 10% situs Internet - sekitar Per.). Hingga saat ini, lebih dari 113.000 zona telah mengaktifkan dukungan HTTP / 3, dan jika Anda memiliki browser eksperimental, sekarang Anda dapat mengakses zona ini menggunakan protokol baru! Sangat bagus karena begitu banyak orang memasukkannya: bekerja dengan HTTP / 3 dari sejumlah besar situs web nyata berarti Anda dapat menguji lebih banyak properti dari browser.

Kami awalnya meluncurkan HTTP / 3 dalam kemitraan dengan Google, yang juga termasuk dukungan eksperimental untuk Chrome Canary. Sejak itu, semakin banyak browser telah menambahkan dukungan eksperimental: itu muncul di Firefox Nightly builds , di berbagai browser berbasis Chromium seperti Opera dan Edge (melalui engine basis Chromium), dan pada build Safari awal . Kami memantau dengan cermat perkembangan ini dan membantu di mana pun kami bisa. Memiliki jaringan besar situs yang telah mengaktifkan HTTP / 3 memberikan pengembang browser tempat pengujian yang sangat baik untuk memvalidasi kode.

Jadi apa status saat ini?

Proses standardisasi IETF melibatkan serangkaian draft untuk mempersiapkan “draft final” yang siap untuk dilabeli sebagai standar RFC. Anggota tim QUIC bekerja bersama dalam analisis, implementasi, dan interoperabilitas untuk mengidentifikasi masalah potensial. Kami meluncurkan dukungan protokol pada tahap versi draft ke - 23 , dan kemudian kami mengikuti semua perubahan, dan pada saat penulisan (14 April 2020) yang terakhir adalah versi ke - 27. Dengan setiap draft, kualitas definisi QUIC meningkat dan mendekati "konsensus kasar" tentang bagaimana protokol seharusnya berperilaku. Untuk menghindari analisis terus-menerus dengan pengaturan dopilivaniya tanpa henti ke ideal, dengan setiap versi baru dari draft bilah untuk membuat perubahan pada spesifikasi meningkat. Ini berarti bahwa dengan setiap versi ada lebih sedikit perubahan, dan RFC akhir akan berhubungan erat dengan protokol yang telah kami luncurkan dalam produksi.

Manfaat

Salah satu keunggulan utama HTTP / 3 adalah peningkatan kinerja, terutama ketika meminta beberapa objek sekaligus. Dalam HTTP / 2, setiap gangguan (packet loss) dalam koneksi TCP memblokir semua aliran sekaligus (memblokir bagian awal baris). Karena HTTP / 3 didasarkan pada UDP, hanya satu aliran yang terputus ketika sebuah paket hilang, tetapi tidak semua.

Selain itu, HTTP / 3 mendukung 0-RTT (nol waktu penerimaan-transmisi), yaitu koneksi berikutnya dapat mulai jauh lebih cepat daripada yang pertama, sehingga menghilangkan kebutuhan untuk mengkonfirmasi TLS dari server ketika membuat koneksi. Ini berarti bahwa klien mulai meminta data jauh lebih awal daripada dengan negosiasi TLS penuh, yaitu, situs web mulai memuat di browser sebelumnya.

Animasi di bawah ini menunjukkan efek packet loss. Dalam contoh pertama, permintaan diterima dari klien ke server melalui HTTP / 2 untuk menerima dua sumber daya. Permintaan dan respons terkait diwarnai hijau dan kuning. Respons dipecah menjadi beberapa paket. Sayangnya, satu paket hilang - akibatnya, transfer kedua sumber daya tertunda.



Dalam contoh kedua, permintaan dua sumber daya diterima melalui HTTP / 3. Satu paket hilang, menghalangi transfer sumber daya kuning, tetapi tanpa mempengaruhi yang hijau.



Perbaikan dalam prosedur negosiasi sesi berarti bahwa "koneksi" dengan server dibuat lebih cepat, yaitu, data tiba lebih cepat di browser. Kami ingin tahu berapa banyak ini tercermin dalam lalu lintas nyata, jadi kami melakukan beberapa tes. Untuk mengevaluasi kontribusi 0-RTT, kami meluncurkan beberapa tes kontrol untuk mengukur waktu ke byte pertama (waktu ke byte pertama, TTFB). Rata-rata, lebih dari HTTP / 3, byte pertama muncul setelah 176 ms. Dalam hal HTTP / 2, kita melihat 201 ms, yaitu, HTTP / 3 di sini mengurangi penundaan sebesar 12,4%!



Menariknya, draft dan RFC tidak mengatur semua aspek protokol. Sebagai contoh, metode transfer paket mempengaruhi kinerja.dan algoritma kontrol kemacetan lalu lintas. Kontrol kemacetan adalah metode adaptasi ke jaringan yang macet di sisi klien dan server: ketika paket hilang, kualitas komunikasi menurun. Karena QUIC adalah protokol baru, eksperimen dan penyetelan diperlukan untuk merancang dan menerapkan sistem manajemen kelebihan beban dengan benar.

Sebagai titik awal yang sederhana dan aman, spesifikasi Deteksi Kehilangan dan Kontrol Kemacetan merekomendasikan algoritma Reno , tetapi yang lainnya dapat digunakan. Kami mulai dengan algoritma New Reno , tetapi berdasarkan pengalaman, kami berasumsi bahwa itu tidak optimal. Kami baru saja beralih ke CUBIC - Dan dalam jaringan dengan transmisi besar dan kehilangan paket lebih besar, CUBIC berkinerja lebih baik daripada New Reno. Segera kita akan membicarakan lebih lanjut tentang ini, tetap ikuti perkembangan blog.

Dalam tumpukan HTTP / 2 saat ini, kami memiliki BBR v1 (TCP). Ini berarti bahwa pengujian tidak melakukan perbandingan yang tepat antara apel dengan apel, karena algoritma kontrol kemacetan ini berperilaku berbeda pada ukuran gigi yang berbeda. Namun, ketika beralih dari HTTP / 2 ke HTTP / 3, kami sudah melihat peningkatan pada situs yang lebih kecil. Di area yang luas, kinerja cemerlang ditunjukkan oleh tumpukan HTTP / 2 kami yang disetel dengan halus dan dioptimalkan.

Halaman pengujian kecil 15K memuat lebih dari HTTP / 3 rata-rata dalam 443 ms, dibandingkan dengan 458 ms untuk HTTP / 2. Tetapi jika Anda meningkatkan ukuran halaman menjadi 1 MB, keuntungan ini menghilang: khususnya di jaringan kami, protokol HTTP / 3 sekarang bekerja sedikit lebih lambat daripada HTTP / 2 - 2.33 s dibandingkan 2.30 s.







Benchmark sintetis memang menarik, tetapi menarik bagaimana HTTP / 3 menunjukkan dirinya di dunia nyata.

Sebagai perbandingan, kami ingin menarik layanan pihak ketiga yang dapat mengunduh situs dari jaringan kami, mensimulasikan peramban web. WebPageTest adalah kerangka kerja umum untuk mengukur waktu buka halaman, dengan diagram cascading yang baik (air terjun). Untuk menganalisis backend, kami menggunakan sistem Wawasan Browser kami sendiri , memperbaiki pengaturan waktu di tepi jaringan kami. Kemudian mereka menghubungkan kedua bagian dengan sedikit otomatisasi.

Sebagai ujian untuk mengukur kinerja, kami mengambil blog kami sendiri . Kami menyiapkan instance WebPageTest kami untuk memuat situs dari lokasi di seluruh dunia, baik melalui HTTP / 2 dan melalui HTTP / 3. Termasuk HTTP / 3 dan Wawasan Browser. Dengan demikian, setiap kali browser dengan dukungan HTTP / 3 memuat halaman, skrip pengujian meminta data analitik yang dikumpulkan dari browser. Prosedur yang sama diulang untuk HTTP / 2 sehingga dapat dibandingkan.

Grafik berikut menunjukkan waktu pemuatan halaman blog.cloudflare.com yang sebenarnya dengan perbandingan metrik HTTP / 3 dan HTTP / 2. Kami memiliki metrik tersebut untuk titik geografis yang berbeda.



Seperti yang Anda lihat, kinerja HTTP / 3 masih kalah dengan kinerja HTTP / 2. Perbedaannya adalah sekitar 1-4% rata-rata di Amerika Utara. Hasil serupa di Eropa, Asia dan Amerika Selatan. Kami menduga bahwa ini mungkin karena perbedaan dalam algoritma kontrol kemacetan: BBR v1 bekerja pada HTTP / 2, dan CUBIC pada HTTP / 3. Di masa mendatang, kami akan mencoba menerapkan algoritma kontrol kelebihan beban yang sama pada kedua protokol untuk mendapatkan perbandingan apel dengan apel yang lebih akurat.

Kesimpulan

Secara keseluruhan, kami sangat senang membantu memajukan standar baru. Implementasi kami berjalan baik, dalam beberapa situasi menunjukkan kinerja yang lebih baik, dan dalam kasus terburuk - HTTP / 2 yang serupa. Ketika standar ini selesai, kami berharap browser menambahkan dukungan HTTP / 3 dalam versi utama. Bagi kami, kami akan mendukung draf terbaru dan akan mencari cara baru untuk mengoptimalkan HTTP / 3 untuk lebih meningkatkan kinerja, apakah itu mengatur kontrol kemacetan, penentuan prioritas atau konfigurasi sistem (CPU dan bandwidth saluran).

Sementara itu, jika Anda ingin mencoba HTTP / 3 beraksi, cukup aktifkannya di dashboard kami dan unduh unit uji (Nightly, Canary) dari salah satu browser utama. Lihat dokumentasi pengembang kami untuk instruksi mengaktifkan HTTP / 3 .