Performa dan Efisiensi: Bekerja dengan HTTP/3

HTTP/3 ada di depan mata, mengikuti jejak HTTP/2—yang bisa dibilang masih sangat muda. Mengingat butuh 16 tahun untuk beralih dari HTTP/1.1 ke HTTP/2, haruskah ada orang yang benar-benar peduli dengan HTTP/3?

Jawaban singkatnya: Ya, ini penting, dan Anda harus mempercepatnya. Ini seperti bagaimana HTTP/2 membuat perubahan signifikan dari HTTP/1.1 dengan beralih dari ASCII ke biner. HTTP/3 kembali membuat perubahan signifikan, kali ini dengan mengalihkan transport yang mendasarinya dari TCP ke UDP.

Meskipun HTTP/3 masih dalam tahap desain dengan spesifikasi resmi masih berupa draf, itu sudah diterapkan dan ada kemungkinan besar Anda akan menemukan versi itu berjalan di jaringan Anda hari ini.

Tetapi ada beberapa dilema baru yang ditimbulkan oleh cara kerja HTTP/3. Juga, apa manfaatnya? Dan apa yang perlu diketahui oleh para insinyur jaringan, administrator sistem, dan pengembang?

Masalah Utama: Kinerja dan Efisiensi

Pengembang situs dan aplikasi umumnya membangun dengan maksud agar kreasi mereka benar-benar digunakan. Terkadang basis audiens terbatas, tetapi seringkali idenya hanya untuk mendapatkan pengguna sebanyak mungkin. Secara alami, semakin populer sebuah situs web, semakin banyak pendapatan yang dapat dihasilkannya.

Penundaan 100 milidetik dalam waktu buka situs web dapat mengurangi tingkat konversi sebesar 7 persen.

Laporan Kinerja Ritel Online Akamai: Milidetik Sangat Penting (2017)

Dengan kata lain, situs eCommerce dengan penjualan $40.000 per hari akan kehilangan satu juta dolar per tahun karena penundaan seperti itu.

Bukan rahasia lagi bahwa kinerja situs sangat penting untuk membuat situs menjadi lebih populer. Penelitian belanja online terus menemukan hubungan antara peningkatan rasio pentalan dan waktu pemuatan yang lebih lama, dan antara loyalitas pembeli dan kinerja situs web selama pengalaman berbelanja.

Penelitian juga menemukan bahwa:

• 47% konsumen mengharapkan halaman web dimuat dalam 2 detik atau kurang.
• 40% orang meninggalkan situs web yang memuat lebih dari 3 detik.

Dan itulah keadaan kesabaran pembelanja online sejak lebih dari satu dekade yang lalu . Jadi kinerja sangat penting, dan HTTP/2 dan HTTP/3 keduanya berarti kinerja situs web yang lebih baik.

HTTP/2? …Apa itu?

Pemahaman yang baik tentang protokol HTTP/2 sangat penting untuk memahami HTTP/3. Pertama-tama, mengapa ada kebutuhan untuk HTTP/2?

HTTP/2 dimulai sebagai proyek Google bernama SPDY, hasil penelitian yang melaporkan bahwa masalah kinerja terbesar di web adalah latensi . Penulis menyimpulkan bahwa “lebih banyak bandwidth tidak masalah (banyak)”:

Jika kita membuat analogi antara pipa ledeng dan Internet, kita dapat menganggap bandwidth Internet seperti diameter pipa air. Pipa yang lebih besar membawa volume air yang lebih besar, dan karenanya Anda dapat mengalirkan lebih banyak air di antara dua titik.

Pada saat yang sama, tidak peduli seberapa besar pipa Anda, jika pipa itu kosong, dan Anda ingin mengalirkan air dari satu titik ke titik lainnya, dibutuhkan waktu agar air dapat mengalir melalui pipa. Dalam bahasa Internet, waktu yang diperlukan air untuk mengalir dari satu ujung pipa ke ujung lainnya dan kembali lagi disebut waktu pulang pergi , atau RTT .

Mike Belshe

Dalam studi tersebut, mengurangi waktu buka halaman adalah tujuannya. Ini menunjukkan bahwa peningkatan bandwidth membantu pada awalnya, karena beralih dari 1 Mbps ke 2 Mbps mengurangi separuh waktu buka halaman. Namun, manfaatnya sangat cepat.

Sebaliknya, penurunan latensi memiliki manfaat konstan dan mencapai hasil terbaik.

HTTP HOL: Masalah Pemblokiran Head-of-line

Penyebab utama latensi dalam protokol HTTP/1 adalah masalah pemblokiran head-of-line. Halaman web (hampir selalu) membutuhkan banyak sumber daya: CSS, JavaScript, font, gambar, AJAX/XMR, dll. Ini berarti browser web perlu membuat beberapa permintaan ke server. Namun, tidak semua sumber daya diperlukan agar halaman menjadi berguna.

Dengan HTTP/1.0, browser perlu menyelesaikan permintaan sepenuhnya, termasuk menerima respons sepenuhnya, sebelum memulai permintaan berikutnya. Semuanya harus dilakukan secara berurutan. Setiap permintaan akan memblokir baris permintaan, oleh karena itu namanya.

Dalam upaya untuk mengkompensasi masalah pemblokiran HOL, browser web membuat beberapa koneksi simultan ke satu server. Tetapi mereka harus secara sewenang-wenang membatasi perilaku ini: Server, workstation, dan jaringan dapat menjadi kelebihan beban dengan terlalu banyak koneksi.

HTTP/1.1 memperkenalkan beberapa peningkatan untuk membantu mengatasi masalah tersebut. Yang utama adalah pipelining , memungkinkan browser web untuk memulai permintaan baru tanpa perlu menunggu permintaan sebelumnya selesai. Ini meningkatkan waktu pemuatan secara signifikan di lingkungan dengan latensi rendah.

Tetapi masih membutuhkan semua tanggapan untuk tiba secara berurutan dalam urutan yang dibuat, sehingga kepala garis masih terhalang. Anehnya, banyak server masih belum memanfaatkan fitur ini.

Menariknya, HTTP/1.1 juga memperkenalkan keep-alive , yang memungkinkan browser menghindari overhead membuat koneksi TCP baru untuk setiap permintaan HTTP. Ini adalah upaya awal untuk memecahkan masalah kinerja yang diturunkan dari TCP. Itu sangat tidak efektif sehingga sebagian besar pakar kinerja benar-benar mencegahnya karena menghambat server dengan terlalu banyak koneksi tidak aktif. Kami akan melihat lebih dekat TCP di bawah ini, serta bagaimana masalah ini diperbaiki oleh HTTP/2.

Solusi Pemblokiran HTTP HOL HTTP/2

HTTP/2 memperkenalkan multiplexing permintaan-respons melalui satu koneksi. Peramban tidak hanya dapat memulai permintaan baru kapan saja, tetapi tanggapan dapat diterima dalam urutan apa pun — pemblokiran sepenuhnya dihilangkan di tingkat aplikasi.

Sebagai akibat langsung, ini berarti server web yang memahami HTTP/2 dapat memaksimalkan efisiensi—lebih lanjut tentang itu nanti.

Meskipun multiplexing permintaan-respons adalah fitur utama untuk HTTP/2, ini mencakup beberapa fitur penting lainnya. Pembaca mungkin mencatat bahwa mereka semua agak terkait.

Pembingkaian Biner HTTP/2

HTTP/2 mengalihkan standar protokol HTTP dari model permintaan-respons ASCII yang tidak dapat dibaca manusia menjadi pembingkaian biner yang efisien . Ini bukan lagi sekadar permintaan dan tanggapan:

Dengan HTTP/2, browser berbicara dengan server melalui aliran dua arah dengan beberapa pesan, masing-masing terdiri dari beberapa frame.

HTTP/2 HPACK (Kompresi Header)

Kompresi header baru HTTP/2, menggunakan format HPACK, menghemat banyak bandwidth untuk sebagian besar situs. Ini karena sebagian besar header sama untuk permintaan yang dikirim dalam koneksi.

Cloudflare melaporkan penghematan bandwidth yang signifikan berkat HPACK saja:

• Kompresi 76% untuk header masuk
• Pengurangan 53% dalam total lalu lintas masuk
• Kompresi 69% untuk header jalan keluar
• 1,4% hingga 15% pengurangan total lalu lintas jalan keluar

Tentu saja, menggunakan bandwidth yang lebih sedikit umumnya berarti situs web yang lebih cepat.

Prioritas Aliran HTTP/2 dan Server Push

Di sinilah multiplexing HTTP/2 benar-benar memungkinkan server untuk memaksimalkan efisiensi. Multiplexing memang membantu menyajikan sumber daya yang lebih cepat (misalnya, JavaScript yang di-cache memori) sebelum yang lebih lambat (misalnya, gambar besar, JSON yang dibuat basis data, dll.). Tetapi ini juga memungkinkan peningkatan kinerja tambahan melalui prioritas aliran HTTP/2 .

Prioritas aliran membantu memastikan bahwa aspek halaman yang hampir siap diselesaikan secara penuh tanpa harus menunggu permintaan intensif sumber daya lainnya selesai. Hal ini dicapai melalui pohon ketergantungan tertimbang. Pohon ini digunakan untuk menginformasikan server tanggapan mana yang harus mengalokasikan sebagian besar sumber daya sistem untuk dilayani.

Ini sangat penting untuk aplikasi web progresif (PWA). Misalnya, halaman memiliki empat file JavaScript. Dua untuk fungsionalitas halaman dan dua untuk iklan. Skenario kasus terburuk adalah memuat setengah dari JS fungsional dan setengah dari JS periklanan dan kemudian memuat gambar besar, sebelum memuat JS yang tersisa. Dalam hal ini, tidak ada halaman yang berfungsi pada awalnya, karena semuanya harus menunggu sumber daya paling lambat.

Dengan prioritas aliran, browser web dapat menginstruksikan server untuk mengirim kedua file JS fungsionalitas halaman sebelum mengirim file JavaScript iklan apa pun. Dengan cara ini pengguna tidak perlu menunggu iklan dimuat sepenuhnya sebelum menggunakan fungsionalitas halaman. Meskipun waktu pemuatan keseluruhan belum membaik, kinerja yang dirasakan telah meningkat secara signifikan. Sayangnya, perilaku dalam browser web ini sebagian besar masih merupakan masalah algoritme, bukan sesuatu yang ditentukan oleh pengembang web.

Sejalan dengan itu, fitur push server HTTP/2 memungkinkan server mengirim respons ke browser untuk permintaan yang belum dibuat! Server dapat memanfaatkan celah dalam transmisi, secara efisien menggunakan bandwidth dengan melakukan pramuat ke sumber daya browser yang diketahui server akan segera diminta. Sebagian dari harapan di sini adalah untuk menghilangkan praktik inlining sumber daya, yang hanya membuat sumber daya membengkak dan membuat mereka membutuhkan waktu lebih lama untuk dimuat.

Sayangnya, kedua fitur ini membutuhkan banyak konfigurasi yang cermat oleh pengembang web untuk benar-benar berhasil. Mengaktifkannya saja tidak cukup.

HTTP/2 jelas membawa banyak keuntungan potensial—beberapa di antaranya lebih murah untuk dimanfaatkan daripada yang lain. Bagaimana nasib mereka di dunia nyata?

HTTP vs HTTP/2 Adopsi

SPDY dibuat pada tahun 2009. HTTP/2 distandarisasi pada tahun 2015. SPDY menjadi nama cabang pengembangan kode yang tidak stabil, dengan HTTP/2 menjadi versi final. Hasilnya adalah SPDY menjadi usang, dan HTTP/2 umumnya merupakan standar yang diikuti semua orang.

Setelah standarisasi, adopsi HTTP/2 (atau “h2”) berkembang pesat menjadi sekitar 40% dari 1.000 situs web teratas. Ini sebagian besar didorong oleh penyedia hosting dan cloud besar yang menyebarkan dukungan atas nama pelanggan mereka. Sayangnya, beberapa tahun kemudian, adopsi HTTP/2 melambat dan sebagian besar internet masih menggunakan HTTP/1.

Kurangnya Dukungan Browser untuk HTTP/2 Clear Text Mode

Ada banyak panggilan untuk HTTP/2 untuk menjadikan enkripsi sebagai bagian standar yang diperlukan. Sebagai gantinya, standar mendefinisikan mode terenkripsi (h2) dan teks jelas (h2c). Dengan demikian, HTTP/2 dapat menggantikan HTTP/1 sepenuhnya.

Meskipun standar, semua browser web saat ini hanya mendukung HTTP/2 melalui koneksi terenkripsi dan sengaja tidak menerapkan mode teks yang jelas. Sebaliknya, browser mengandalkan mode kompatibilitas mundur HTTP/1 untuk mengakses server yang tidak aman. Ini adalah akibat langsung dari dorongan ideologis untuk membuat web aman secara default.

Mengapa HTTP/3? Dan Apa Bedanya?

Dengan masalah pemblokiran head-of-line HTTP yang sekarang diperbaiki oleh HTTP/2, pengembang protokol telah mengalihkan perhatian mereka ke driver latensi terbesar berikutnya: masalah pemblokiran head-of-line TCP .

Protokol Kontrol Transmisi (TCP)

Jaringan IP (protokol internet) didasarkan pada gagasan bahwa komputer saling mengirim paket. Paket hanyalah data dengan beberapa informasi pengalamatan yang dilampirkan di atasnya.

Tetapi aplikasi biasanya perlu berurusan dengan aliran data. Untuk mencapai ilusi ini, protokol kontrol transmisi (TCP) menyajikan aplikasi sebuah pipa di mana aliran data dapat mengalir. Seperti kebanyakan pipa, ada jaminan bahwa data akan keluar dari pipa dalam urutan yang sama saat masuk, juga dikenal sebagai "masuk pertama, keluar pertama" (FIFO). Karakteristik ini membuat TCP sangat berguna dan diadopsi secara luas.

Sebagai bagian dari jaminan pengiriman data yang disediakan TCP, TCP harus mampu menangani berbagai macam situasi. Salah satu masalah yang paling kompleks adalah bagaimana mengirimkan semua data ketika jaringan kelebihan beban, tanpa memperburuk situasi untuk semua orang. Algoritme untuk ini disebut kontrol kemacetan dan merupakan bagian spesifikasi internet yang terus berkembang. Tanpa kontrol kemacetan yang memadai, internet terhenti.

Pada bulan Oktober '86, Internet memiliki yang pertama dari apa yang menjadi serangkaian 'runtuhnya kemacetan.' Selama periode ini, throughput data dari LBL ke UC Berkeley (situs yang dipisahkan oleh 400 yard dan tiga hop IMP) turun dari 32 Kbps menjadi 40 bps.

V. Jacobson (1988)

Di situlah masalah pemblokiran head-of-line TCP masuk.

Masalah Pemblokiran TCP HOL

Kontrol kongesti TCP bekerja dengan menerapkan mekanisme backoff dan transmisi ulang untuk paket, digunakan setiap kali kehilangan paket terdeteksi. Backoff dimaksudkan untuk membantu menenangkan jaringan. Transmisi ulang memastikan bahwa data akhirnya terkirim.

Ini berarti bahwa data TCP dapat tiba di tujuan secara tidak berurutan, dan merupakan tanggung jawab pihak penerima untuk menyusun ulang paket-paket tersebut sebelum memasangnya kembali ke dalam aliran. Sayangnya, ini berarti bahwa satu paket yang hilang dapat menyebabkan seluruh aliran TCP dijeda sementara server menunggu pengiriman ulang. Oleh karena itu, kepala garis diblokir.

Proyek lain dari Google bertujuan untuk memecahkan masalah ini dengan memperkenalkan protokol yang disebut QUIC.

Protokol QUIC dibangun di atas UDP, bukan TCP, dan QUIC membentuk dasar untuk HTTP/3.

Apa itu UDP?

Protokol datagram pengguna (UDP) adalah alternatif untuk TCP. Itu tidak memberikan ilusi aliran atau jaminan yang sama yang ditawarkan TCP. Sebaliknya, itu hanya menyediakan cara mudah untuk menempatkan data ke dalam sebuah paket, alamat ke komputer lain, dan mengirimkannya. Itu tidak dapat diandalkan , tidak teratur , dan tidak disertai dengan kontrol kemacetan dalam bentuk apa pun.

Tujuannya adalah untuk menjadi ringan dan menyediakan fitur minimum yang diperlukan untuk memungkinkan komunikasi. Dengan cara ini aplikasi dapat mengimplementasikan jaminannya sendiri. Ini sering sangat berguna dalam aplikasi waktu nyata. Misalnya, dalam panggilan telepon, pengguna umumnya lebih suka menerima 90% data dengan segera, daripada 100% data pada akhirnya.

Solusi TCP HOL HTTP/3

Memecahkan masalah pemblokiran TCP HOL membutuhkan lebih dari sekadar beralih ke UDP, karena masih diperlukan untuk menjamin pengiriman semua data dan menghindari kemacetan jaringan yang runtuh. Protokol QUIC dirancang untuk melakukan semua ini dengan menyediakan HTTP yang dioptimalkan melalui pengalaman tipe UDP.

Karena QUIC mengambil alih kendali manajemen aliran, pembingkaian biner, dll., tidak banyak yang harus dilakukan HTTP/2 saat dijalankan di atas QUIC. Ini adalah bagian dari faktor pendorong menuju kombinasi baru QUIC + HTTP yang distandarisasi sebagai HTTP/3.

Catatan: Ada banyak versi QUIC, karena protokol telah dikembangkan dan diterapkan di lingkungan produksi selama bertahun-tahun. Bahkan ada versi khusus Google yang disebut GQUIC. Karena itu, penting untuk membedakan antara protokol QUIC lama dan standar HTTP/3 yang baru.

Selalu Dienkripsi

HTTP/3 menyertakan enkripsi yang banyak meminjam dari TLS tetapi tidak menggunakannya secara langsung. Salah satu tantangan implementasi utama untuk HTTP/3 adalah pustaka TLS/SSL yang perlu dimodifikasi untuk menambahkan fungsionalitas baru yang diperlukan.

Perubahan ini karena HTTP/3 berbeda dari HTTPS dalam hal enkripsinya. Dengan protokol HTTPS yang lebih lama, hanya data itu sendiri yang dilindungi oleh TLS, sehingga banyak metadata transport terlihat. Dalam HTTP/3 baik data maupun protokol transport dilindungi. Ini mungkin terdengar seperti fitur keamanan, dan memang begitu. Tapi itu dilakukan dengan cara ini untuk menghindari banyak overhead yang ada di HTTP/2. Oleh karena itu, mengenkripsi protokol transport serta data sebenarnya membuat protokol lebih berkinerja.

Dampak HTTP/3 pada Infrastruktur Jaringan

HTTP/3 bukannya tanpa kontroversi. Perhatian utama adalah tentang infrastruktur jaringan.

HTTP/3 sisi klien

Di sisi klien, lalu lintas UDP cukup umum untuk dibatasi tarifnya dan/atau diblokir. Menerapkan pembatasan ini ke HTTP/3 mengalahkan inti dari protokol.

Kedua, HTTP cukup umum untuk dipantau dan/atau dicegat. Bahkan dengan lalu lintas HTTPS, jaringan secara teratur mengawasi elemen transpor teks yang jelas dari protokol untuk menentukan apakah mereka harus memutuskan koneksi untuk tujuan mencegah akses ke situs web tertentu dari jaringan tertentu atau dalam wilayah tertentu. Di beberapa negara, ini bahkan diamanatkan oleh undang-undang untuk penyedia layanan tertentu. Enkripsi wajib di HTTP/3 membuat ini tidak mungkin.

Ini bukan hanya penyaringan tingkat pemerintah. Banyak universitas, perpustakaan umum, sekolah, dan rumah dengan orang tua yang peduli secara aktif memilih untuk memblokir akses ke situs web tertentu atau setidaknya menyimpan log situs mana yang telah dikunjungi. Enkripsi wajib di HTTP/3 membuat ini tidak mungkin.

Perlu dicatat bahwa pemfilteran terbatas saat ini dimungkinkan. Ini karena bidang indikasi nama server (SNI)—yang membawa nama host situs web tetapi bukan jalur, parameter kueri, dll.—masih belum dienkripsi. Tapi ini akan berubah dalam waktu dekat dengan diperkenalkannya ESNI (SNI terenkripsi), yang baru-baru ini ditambahkan ke standar TLS.

HTTP/3 sisi server

Di sisi server, praktik terbaik adalah memblokir port dan protokol apa pun yang tidak mengharapkan lalu lintas, yang berarti bahwa administrator server sekarang perlu membuka UDP 443 untuk HTTP/3, daripada mengandalkan aturan TCP 443 yang ada.

Kedua, infrastruktur jaringan dapat membuat sesi TCP menjadi lengket , artinya sesi tersebut akan selalu dirutekan ke server yang sama meskipun prioritas perutean berubah. Saat HTTP/3 berjalan di atas UDP—yang tidak memiliki sesi—infrastruktur jaringan perlu diperbarui untuk melacak ID koneksi khusus HTTP/3, yang dibiarkan tidak terenkripsi secara khusus untuk membantu perutean yang lengket.

Ketiga, HTTP diperiksa untuk mendeteksi penyalahgunaan, memantau masalah keamanan umum, mendeteksi dan mencegah penyebaran malware dan virus, dll. Ini tidak mungkin dilakukan dengan HTTP/3 karena enkripsinya. Namun, opsi di mana perangkat penyadap memiliki salinan kunci keamanan masih dimungkinkan, dengan asumsi perangkat menerapkan dukungan HTTP/3.

Akhirnya, banyak administrator keberatan karena harus mengelola lebih banyak sertifikat SSL, meskipun itu bukan masalah sekarang dengan layanan seperti Let's Encrypt yang tersedia.

Sampai ada solusi terkenal yang diterima secara luas untuk mengatasi masalah ini, saya pikir kemungkinan banyak jaringan besar hanya akan memblokir HTTP/3.

Dampak HTTP/3 pada Pengembangan Web

Tidak banyak yang perlu dikhawatirkan di bagian depan ini. Prioritas aliran HTTP/2 dan fitur server push masih ada di HTTP/3. Sangatlah berharga bagi pengembang web untuk membiasakan diri dengan fitur-fitur ini jika mereka ingin benar-benar mengoptimalkan kinerja situs mereka.

Menggunakan HTTP/3 Saat Ini

Pengguna Google Chrome, atau browser Chromium sumber terbuka, sudah disetel untuk menggunakan HTTP/3. Rilis kualitas produksi server HTTP/3 masih jauh—spesifikasinya belum sepenuhnya selesai pada tulisan ini. Tetapi sementara itu ada banyak alat untuk dimainkan, dan baik Google maupun Cloudflare telah mendorong dukungan ke lingkungan produksi mereka.

Cara termudah untuk mencobanya adalah dengan menggunakan Caddy di Docker. Sertifikat SSL diperlukan untuk ini, jadi alamat IP yang dapat diakses publik membuat segalanya menjadi mudah. Langkah-langkahnya adalah:

1. pengaturan DNS. Dapatkan nama host yang berfungsi yang aktif di internet, misalnya yourhostname.example.com IN A 192.0.2.1 .
2. pembuatan file Caddy. Itu harus berisi baris-baris ini:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Menjalankan Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —atau di luar Docker, caddy --quic .
2. Menjalankan chromium dengan QUIC diaktifkan: chromium --enable-quic
3. (Opsional) Memasang ekstensi Indikator Protokol.
4. Menavigasi ke server yang mendukung QUIC , tempat browser file akan terlihat.

Pengembang juga dapat menguji server mereka dengan alat berguna berikut:

• Tes HTTP/2 Keycdn
• HTTP3Check LiteSpeed
• Uji Server SSL Qualys

Terima kasih sudah membaca!