Apa itu HTTP/3 – Lowdown pada Protokol Berbasis UDP Baru yang Cepat

TL;DR

Pada November 2018, Internet Engineering Task Force (IETF) bertemu di Bangkok, dan Internet-Draft baru diadopsi. Protokol transport QUIC, penerus HTTP/2, diubah namanya menjadi HTTP/3.

HTTP/3 dibangun di atas User Datagram Protocol (UDP), dan sudah digunakan oleh perusahaan internet terkemuka seperti Google dan Facebook. Jika Anda menggunakan Chrome dan terhubung ke layanan Google, Anda mungkin sudah menggunakan QUIC.

Versi baru dari protokol HTTP mendapat manfaat dari protokol UDP bare-metal, tingkat rendah, dan mendefinisikan banyak fitur baru yang ada di versi HTTP sebelumnya di lapisan TCP. Ini menyediakan cara untuk memecahkan kendala dalam infrastruktur internet yang ada.

Hasil pertama menjanjikan, dan ketika Internet Draft oleh IETF berakhir, pada Agustus 2021, kita dapat mengharapkan HTTP/3 dipromosikan sebagai standar HTTP generasi ketiga yang baru.

Kemajuan HTTP/3 pada tahun 2022

Beberapa orang mengatakan bahwa keinginan industri web untuk kecepatan lebih dan latensi lebih rendah hanya cocok dengan keinginan Google Chrome untuk lebih banyak RAM.

Beberapa tahun yang lalu, kami menerbitkan artikel tentang HTTP/2, standar yang, menurut W3Techs, kini telah mencapai tingkat adopsi dunia sekitar 45%. Dan menurut Can I Use, itu juga didukung oleh semua browser web modern. Namun di sinilah kita, menulis artikel tentang versi protokol berikutnya, HTTP/3.

HTTP/3, pada saat penulisan ini, adalah IETF Internet-Draft atau ID, yang berarti bahwa saat ini sedang dipertimbangkan untuk standar internet yang akan datang oleh Internet Engineering Task Force – badan standar internet internasional, yang bertanggung jawab untuk mendefinisikan dan mempromosikan standar protokol internet yang disepakati, seperti TCP, IPv6, VoIP, Internet of Things, dll.

Ini adalah badan terbuka yang menyatukan industri web dan memfasilitasi diskusi tentang arah internet. Saat ini, fase "Draf Internet" HTTP/3 adalah fase terakhir sebelum proposal dipromosikan ke tingkat Permintaan-untuk-Komentar (atau RFC), yang dapat kami pertimbangkan, untuk semua maksud dan tujuan, definisi protokol internet resmi.

Meskipun HTTP/3 belum menjadi protokol Internet resmi, banyak perusahaan dan proyek telah mulai menambahkan dukungan HTTP/3 ke dalam produk mereka.

Dukungan Peramban Web untuk HTTP/3

Di bagian depan browser web, Chrome v87, Firefox v88, dan Edge v87 semuanya memiliki HTTP/3 yang diaktifkan secara default. Untuk pengguna Safari, opsi untuk mengaktifkan HTTP/3 telah ditambahkan ke Pratinjau Teknologi Safari v104. Namun, dukungan HTTP/3 saat ini tidak tersedia di Safari versi stabil.

Dukungan Perpustakaan untuk HTTP/3

Untuk pengembang yang ingin memanfaatkan teknologi HTTP/3, banyak perpustakaan populer telah menambahkan dukungan untuk HTTP/3. Karena HTTP/3 masih dalam tahap Konsep Internet, Anda pasti ingin memastikan bahwa Anda mengikuti pembaruan terbaru saat bekerja dengan salah satu pustaka di bawah ini.

• Python – http3 dan aioquic
• Karat – quiche, neqo, dan quinn
• C – nghttp3 dan lsquic
• Pergi – quicgo
• JavaScript – Node.js

Dukungan Infrastruktur untuk HTTP/3

Di sisi infrastruktur, Cloudflare telah memimpin dengan dukungan untuk HTTP/3 di seluruh jaringan edge-nya. Ini berarti situs dengan Cloudflare diaktifkan dapat memanfaatkan keamanan HTTP/3 dan peningkatan kinerja tanpa pekerjaan tambahan.

Di Kinsta, semua situs yang kami host dilindungi oleh integrasi Cloudflare gratis kami. Selain firewall tingkat perusahaan dan perlindungan DDoS, pelanggan Kinsta juga memiliki akses ke HTTP/3!

Untuk menguji apakah situs Anda mendukung HTTP/3, Anda dapat menggunakan Alat Pengujian HTTP/3 Geekflare. Cukup ketik domain Anda dan tekan tombol "Periksa HTTP/3", dan alat ini akan memberi tahu Anda apakah situs Anda mendukung HTTP/3.

Jika situs Anda mendukung HTTP/3, Anda akan melihat pesan seperti di bawah ini. Karena kinstalife.com dihosting di Kinsta, HTTP/3 didukung penuh berkat integrasi Cloudflare kami.

Anda juga dapat menggunakan pemeriksa browser untuk memeriksa dukungan HTTP/3. Untuk contoh ini, kami akan menggunakan versi terbaru Google Chrome yang mendukung HTTP/3.

Untuk membuka inspektur, klik kanan pada halaman dan klik "Periksa" dan navigasikan ke tab "Jaringan". Di kolom “Protocol”, Anda dapat melihat protokol HTTP yang digunakan untuk koneksi. Koneksi HTTP/2 muncul sebagai “h2”, sedangkan koneksi HTTP/3 muncul sebagai “h3-XX” (XX mengacu pada draf HTTP/3 tertentu). Seperti yang Anda lihat pada gambar di bawah, kinstalife.com mendukung koneksi melalui "h3-29", yang berarti "HTTP/3 Draft 29".

Sekarang setelah kita membahas status HTTP/3 saat ini, mari selami beberapa perbedaan antara HTTP/2 vs HTTP/3!

Sedikit Latar Belakang – Dimulai dengan HTTP/2

HTTP/2 membawa beberapa peningkatan serius dengan unduhan non-blocking, pipelining, dan server push yang telah membantu kami mengatasi beberapa keterbatasan protokol TCP yang mendasarinya. Ini memungkinkan kami untuk meminimalkan jumlah siklus permintaan-tanggapan dan jabat tangan.

HTTP/2 memungkinkan untuk mendorong lebih dari satu sumber daya dalam satu koneksi TCP – multiplexing. Kami juga mendapatkan lebih banyak fleksibilitas dalam pengurutan unduhan statis, dan halaman kami sekarang tidak lagi dibatasi oleh perkembangan linier unduhan.

Dalam praktiknya, ini berarti bahwa sekarang satu sumber daya javascript besar tidak selalu sama dengan titik tersedak untuk semua sumber daya statis lainnya yang menunggu giliran.

Tambahkan ke hal-hal ini kompresi HPACK header HTTP/2 dan format biner default dari transfer data, dan kami memiliki, dalam banyak kasus, protokol yang jauh lebih efisien.

Implementasi browser utama mengharuskan situs web untuk menerapkan enkripsi – SSL – untuk dapat memperoleh manfaat dari HTTP/2 – dan terkadang hal ini menimbulkan biaya komputasi yang membuat peningkatan kecepatan tidak terlalu terlihat. Bahkan ada beberapa kasus di mana pengguna melaporkan pelambatan setelah beralih ke HTTP/2.

Anggap saja hari-hari awal adopsi versi ini bukan untuk yang lemah hati.

Implementasi Nginx juga tidak memiliki fitur server-push, bergantung pada modul. Dan modul Nginx bukanlah modul drop-in Apache yang biasa Anda salin – NGINX harus dikompilasi ulang dengan modul ini.

Sementara beberapa dari masalah ini diselesaikan sekarang, jika kita melihat seluruh tumpukan protokol, kita melihat bahwa kendala utama terletak pada tingkat yang lebih rendah daripada yang berani dihadapi HTTP/2.

Untuk menguraikan ini, kami akan membedah tumpukan protokol internet hari ini dari lapisan bawah ke atas. Jika Anda ingin mempelajari lebih lanjut tentang latar belakang HTTP/2, pastikan untuk membaca panduan HTTP/2 utama kami.

Protokol Internet (IP)

Internet Protocol (IP) mendefinisikan bagian bawah dari seluruh topologi internet. Ini adalah bagian dari tumpukan internet yang, bisa kita katakan dengan aman, benar-benar tidak dapat dinegosiasikan tanpa mengubah segalanya, termasuk mengganti seluruh infrastruktur perangkat keras, dari router ke server dan bahkan mesin pengguna akhir.

Jadi, sementara perombakan protokol mungkin dilakukan, upaya yang luas seperti itu tidak ada di cakrawala saat ini, terutama karena kami belum menemukan alternatif yang layak, inovatif, namun kompatibel ke belakang.

Kita dapat melacak awal protokol IP kembali ke tahun 1974, ke makalah yang diterbitkan oleh Institute of Electrical and Electronics Engineers dan ditulis oleh Vint Cerf dan Bob Cahn. Ini merinci paket yang dikirim melalui jaringan, merutekannya melintasi alamat IP, dan alamat node yang ditentukan secara numerik dalam jaringan/jaringan. Protokol mendefinisikan format paket-paket ini, atau datagram – header dan payload-nya.

Setelah definisi RFC 760 dari tahun 1980, IETF menetapkan definisi yang digunakan secara luas hingga hari ini, dalam Request For Comments 791. Ini adalah versi keempat dari protokol, tetapi dapat dikatakan ini adalah versi produksi pertama.

Ini menggunakan alamat 32-bit, yang membatasi jumlah alamat menjadi sekitar 4 miliar. Keterbatasan ini menjelaskan misteri mengapa pengguna internet non-bisnis mendapatkan "alamat IP dinamis" oleh ISP mereka, dan IP statis dianggap sebagai "nilai tambah" dan sering dikenakan biaya tambahan.

Mereka penjatahan.

Tidak lama kemudian disadari bahwa alamat 32-bit tidak cukup, dan kekurangan itu menjulang, begitu banyak RFC diterbitkan untuk mencoba menangani ini. Meskipun solusi ini banyak digunakan saat ini, dan merupakan bagian dari kehidupan kita sehari-hari, mungkin aman untuk mengatakan jumlah ini sebagai peretasan.

Mendaftar Untuk Buletin

Ingin tahu bagaimana kami meningkatkan lalu lintas kami lebih dari 1000%?

Bergabunglah dengan 20.000+ orang lain yang mendapatkan buletin mingguan kami dengan kiat-kiat WordPress orang dalam!

Berlangganan sekarang

Internet Protocol versi 6 atau IPv6 hadir sebagai cara untuk mengatasi keterbatasan ini, termasuk secara bertahap diadopsi dari versi sebelumnya. Itu dibuat menjadi Draf dokumen Standar untuk IETF pada tahun 1998, dan dinaikkan menjadi Standar Internet pada tahun 2017.

Sementara ruang alamat IPv4 dibatasi oleh panjang alamat 32-bit, standar IPv6 diberikan 128 bit, atau 3,4 * 10 ^ 38 kemungkinan alamat. Ini seharusnya cukup untuk membuat kita bertahan cukup lama.

Menurut konektivitas Google dan IPv6 di antara penggunanya, adopsi IPv6 hanya lebih dari 35% pada Juni 2021.

IP adalah lapisan dasar dari tumpukan internet, mendefinisikan hal-hal yang paling dasar, tanpa jaminan pengiriman, integritas data, atau pemesanan paket yang ditransmisikan. Sendiri itu tidak bisa diandalkan. Format header IPv4 menyediakan checksum header, yang digunakan node transmisi untuk memverifikasi integritas header. Ini membuatnya berbeda dari versi IPv6, yang mengandalkan lapisan tautan di bawahnya, sehingga membuatnya lebih cepat.

Memahami Peran TCP dan UDP

Sekarang saatnya untuk mengeksplorasi di mana HTTP/3 cocok dengan TCP dan UDP.

TCP

Sementara IP adalah lapisan yang mendasari semua komunikasi online kami hari ini, TCP (Transmission Control Protocol) adalah bagian tingkat yang lebih tinggi dari suite protokol internet, memberikan keandalan yang diperlukan untuk web, email, transfer file (FTP) – untuk lapisan aplikasi/protokol internet.

Ini termasuk pembentukan koneksi multi-langkah, dengan jabat tangan, urutan paket yang terjamin, dan transmisi ulang paket yang hilang. Ini memberikan umpan balik (Acks) pengiriman ke pengirim dan sebagainya. Ada juga perhitungan checksum untuk mendeteksi kesalahan.

Semua hal ini menunjukkan banyak langkah yang menjadikan TCP protokol yang andal, menjadikannya dasar dari layanan internet paling terkenal yang kita gunakan saat ini.

Spesifikasinya sejak 1974 (RFC 675) dan 1981 (RFC 793) tidak berubah secara substansial hingga hari ini.

Keandalan yang disediakan TCP tidak datang tanpa biaya. Overhead dari semua perjalanan pulang pergi yang diperlukan oleh jabat tangan, umpan balik pengiriman, jaminan pemesanan, dan checksum yang dapat dianggap lemah dan berlebihan. Itu telah membuat TCP menjadi penghambat tumpukan protokol modern. HTTP/2 telah mencapai puncak peningkatan kecepatan yang dapat dicapai di atas TCP.

UDP

User Datagram Protocol (UDP) juga merupakan salah satu bagian dari Internet Protocol Suite, dengan spesifikasi sejak tahun 1980 (RFC 768).

Seperti namanya, protokol connectionless berbasis datagram. Yang berarti tidak ada jabat tangan dan tidak ada jaminan pemesanan atau pengiriman. Ini berarti bahwa setiap langkah yang mungkin untuk memastikan pengiriman, integritas data, dan hal-hal lain diserahkan kepada lapisan aplikasi. Ini berarti bahwa bangunan aplikasi di atas UDP dapat memilih strategi yang akan digunakan tergantung pada kasus konkret, atau mungkin dapat memanfaatkan elemen lapisan tautan, seperti checksum, untuk menghindari overhead.

Karena UDP tersebar luas seperti TCP, memungkinkan untuk mencapai peningkatan tanpa memerlukan pembaruan firmware pada beragam perangkat yang terhubung ke internet, atau perubahan signifikan dalam sistem operasi.

Penyebaran protokol baru terhambat oleh banyak firewall, NAT, router, dan kotak tengah lainnya yang hanya mengizinkan TCP atau UDP disebarkan antara pengguna dan server yang perlu mereka jangkau. – HTTP/3 dijelaskan

Utas di Berita Peretas ini dapat membantu kami mulai memahami alasan di balik pembuatan versi HTTP baru di atas tumpukan jaringan yang ada, daripada menciptakannya kembali (walaupun ada lebih dari itu).

Spesifikasi format paket UDP agak minim, header-nya terdiri dari port sumber, port tujuan, panjang, dalam byte, header paket dan data paket, dan checksum. Checksum dapat digunakan untuk memverifikasi integritas data baik untuk header dan bagian data dari paket.

Checksum adalah opsional ketika lapisan protokol yang mendasarinya adalah IPv4, dan wajib dengan IPv6. Sejauh ini, UDP telah digunakan untuk hal-hal seperti sinkronisasi jam sistem komputer (NTP), aplikasi VoIP, streaming video, sistem DNS, dan protokol DHCP.

QUIC dan HTTP/3

QUIC (Quick UDP Internet Connections) pertama kali digunakan oleh Google pada tahun 2012. Ini mendefinisikan ulang batas lapisan jaringan, mengandalkan protokol UDP tingkat yang lebih rendah, mendefinisikan ulang jabat tangan, fitur keandalan, dan fitur keamanan di "ruang pengguna", menghindari kebutuhan untuk memutakhirkan kernel sistem di seluruh internet.

Sama seperti HTTP/2, sebuah kemajuan yang dipelopori oleh Google SPDY atau speedy, HTTP/3 akan kembali membangun pencapaian ini.

Meskipun HTTP/2 memang memberi kami multiplexing, dan mengurangi pemblokiran head-of-line, itu dibatasi oleh TCP. Anda dapat menggunakan koneksi TCP tunggal untuk beberapa aliran yang dimultipleks bersama untuk mentransfer data, tetapi ketika salah satu aliran tersebut mengalami kehilangan paket, seluruh koneksi (dan semua alirannya) disandera, jadi katakanlah, sampai TCP melakukan tugasnya ( mentransmisi ulang paket yang hilang).

Ini berarti bahwa semua paket, bahkan jika sudah ditransmisikan dan menunggu, di buffer node tujuan, diblokir sampai paket yang hilang ditransmisikan kembali. Daniel Stenberg dalam bukunya di http/3 menyebut ini sebagai "kepala blok garis berbasis TCP." Dia mengklaim bahwa, dengan kehilangan paket 2%, pengguna akan melakukan lebih baik dengan HTTP/1, dengan enam koneksi untuk melindungi risiko ini.

QUIC tidak dibatasi oleh ini. Dengan membangun QUIC pada protokol UDP tanpa koneksi, konsep koneksi tidak membawa batasan TCP dan kegagalan satu aliran tidak harus memengaruhi aliran lainnya.

Seperti yang dikatakan Lucas Pardue dari Cloudflare:

Dengan fokus pada aliran UDP , QUIC mencapai multiplexing tanpa harus membonceng satu koneksi TCP. QUIC membangun koneksinya pada tingkat yang lebih tinggi daripada TCP. Aliran baru dalam koneksi QUIC tidak dipaksa untuk menunggu yang lain selesai. Koneksi QUIC juga mendapat manfaat dari menghilangkan overhead handshake TCP, yang mengurangi latensi.

Orang-orang di Cisco membuat video menarik yang menjelaskan jabat tangan 3 arah TCP:

Sementara QUIC menghilangkan fitur keandalan TCP, QUIC menggantikannya di atas lapisan UDP, menyediakan pengiriman ulang paket, pemesanan, dan sebagainya. Google Cloud Platform memperkenalkan dukungan QUIC untuk load balancer mereka pada tahun 2018 dan mengalami peningkatan waktu muat halaman rata-rata sebesar 8% secara global , dan hingga 13% di wilayah dengan latensi lebih tinggi.

Di antara Google Chrome, YouTube, Gmail, pencarian Google, dan layanan lainnya, Google dapat menerapkan QUIC di sebagian besar internet, tanpa menunggu IETF. Insinyur Google mengklaim bahwa pada tahun 2017, 7% dari lalu lintas internet telah dilakukan melalui QUIC.

QUIC versi Google difokuskan hanya pada transport HTTP, menggunakan sintaks HTTP/2. Orang-orang dari IETF (mereka yang bertanggung jawab atas standarisasi QUIC), memutuskan bahwa versi IETF dari QUIC harus dapat mengangkut lebih dari sekadar HTTP. Namun, untuk saat ini, semua pekerjaan pada protokol non-HTTP melalui QUIC ditangguhkan.

Satu hal lagi yang diputuskan oleh kelompok kerja IETF adalah bahwa versi standar akan menggunakan enkripsi TLS 1.3 alih-alih solusi khusus Google. TLS 1.3, dibandingkan dengan versi yang lebih lama, juga berkontribusi pada kecepatan protokol, karena jabat tangannya membutuhkan lebih sedikit perjalanan pulang pergi. Kinsta mendukung TLS 1.3 di semua server kami dan CDN Kinsta kami.

Saat ini, Google terus menggunakan versi QUIC-nya sendiri dalam produknya, sambil mengarahkan upaya pengembangannya ke standar IETF. Sebagian besar pemain internet lainnya sedang membangun di atas versi IETF (keduanya berbeda dalam beberapa aspek lain selain enkripsi).

Jika kita membuka Alat Pengembang Chrome, dan memuat beberapa produk Google, seperti Gmail, di kolom Protokol pada tab Jaringan, kita akan melihat banyak sumber daya dimuat melalui protokol QUIC versi Google. Ini juga berlaku untuk produk Google seperti Analytics, Google Pengelola Tag, dll.

Cloudflare menerbitkan pembaruan yang sangat luas tentang kemajuan standardisasi.

Sementara UDP memberikan QUIC dan HTTP/3 beberapa keuntungan yang melekat, itu juga membawa beberapa tantangan.

TCP telah menjadi protokol utama selama bertahun-tahun, sedangkan UDP belum, jadi sistem operasi dan tumpukan perangkat lunak untuk itu, secara umum, tidak dioptimalkan. Akibatnya, ada beban/persyaratan CPU yang jauh lebih tinggi dengan QUIC, menurut beberapa perkiraan, dua kali lipat dengan HTTP/2.

Pengoptimalan masuk jauh ke dalam kernel sistem operasi, dan berbagai router dan firmware perangkat. Panduan tuning Red Hat ini dapat menjelaskan lebih banyak topik bagi mereka yang cenderung secara teknis.

Kita dapat mengatakan bahwa QUIC mencoba untuk merekayasa ulang fitur TCP di atas protokol yang lebih minimal dan lebih fleksibel.

Koneksi QUIC, yang kami sebutkan sebelumnya, menggabungkan TLS dan jabat tangan transportasi. Setelah dibuat, mereka diidentifikasi oleh CID unik (ID koneksi). ID ini tetap ada di seluruh perubahan IP dan dapat membantu mengamankan unduhan tanpa gangguan, misalnya, peralihan dari 4G ke WiFi. Ini relevan, terutama karena semakin banyak lalu lintas internet dilakukan di perangkat seluler. Pertanyaan mungkin muncul apakah elemen ini dirancang oleh Google untuk memfasilitasi pelacakan pengguna yang lebih baik di berbagai koneksi dan penyedia internet.

TLS adalah wajib, dan dimaksudkan untuk mempersulit perangkat di tengah untuk mengutak-atik, atau mengendus lalu lintas. Itulah mengapa tidak jarang melihat penyedia firewall dan vendor seperti Cisco melihat protokol UDP sebagai masalah, dan menyediakan cara untuk menonaktifkannya. Lebih sulit bagi perantara untuk memeriksa dan mengawasi atau menyaring lalu lintas QUIC.

Aliran QUIC dikirim melalui koneksi QUIC, searah atau dua arah. Aliran memiliki ID yang mengidentifikasi inisiator, dan apakah aliran itu searah atau dua arah, dan juga melayani kontrol aliran dalam aliran.

Sementara QUIC adalah protokol lapisan transport, HTTP adalah lapisan di atasnya, protokol lapisan aplikasi, atau protokol aplikasi.

Karena kompatibilitas mundur adalah yang paling penting, IETF mempromosikan implementasi HTTP/3, dan akan menyertakan versi lama (HTT1 atau HTTP/2) sebagai tanggapan. Ini akan menyertakan header yang memberi tahu klien bahwa HTTP/3 tersedia, bersama dengan informasi port/host, seperti yang dijelaskan dalam RFC 7838.

Ini berbeda dari HTTP/2, di mana transport dapat dinegosiasikan dalam handshake TLS. Tetapi karena IETF telah mengadopsi HTTP/3 berbasis QUIC sebagai standar berikutnya, kami dapat mengharapkan klien web untuk mengantisipasi dukungan HTTP/3 lebih banyak dan lebih banyak lagi. Dimungkinkan bagi klien untuk menyimpan data dari koneksi HTTP/3 sebelumnya, dan untuk terhubung secara langsung (zero-round-trip, atau 0-RTT) pada kunjungan berikutnya ke host yang sama.

Ringkasan

Ada orang yang berpikir bahwa, dengan standar HTTP/2 yang belum sepenuhnya diadopsi, mungkin terlalu dini untuk mendorong HTTP/3 secara luas. Ini adalah poin yang valid, tetapi, seperti yang kami sebutkan, protokol ini telah melihat pengujian dan implementasi skala besar. Google mulai mengujinya pada awal 2015, serta Facebook pada 2017.

Pada tahun 2022, kami memiliki dukungan HTTP/3 dari browser utama seperti Google Chrome dan Brave. Di sisi infrastruktur, server web seperti Litespeed dan Nginx keduanya memiliki implementasi HTTP/3 yang berfungsi, sementara penyedia jaringan seperti Cloudflare telah menerapkan dukungan penuh untuk HTTP/3.

Saat ini, HTTP/3 masih dalam fase Konsep Internet, dan revisi terbaru akan berakhir pada Agustus 2021. Tahun ini akan menarik, karena kita dapat melihat langkah vendor perangkat lunak besar untuk menerapkan yang baru. standar.