Setiap permintaan HTTP yang dilayani API Anda berjalan di lapisan transport yang sebagian besar developer tidak pernah memikirkannya. Selama 25 tahun, jawabannya adalah TCP. Kemudian Google bosan menunggu TCP untuk meningkatkan diri, membangun protokol QUIC di atas UDP, dan IETF menjadikannya standar. HTTP/3 adalah versi HTTP yang dibangun untuk berjalan di atasnya.
Itu terdengar seperti perpipaan. Memang sebagian besar begitu. Namun perpipaan ini mengubah seberapa cepat API Anda terhubung, bagaimana perilakunya pada jaringan seluler yang tidak stabil, dan bagaimana permintaan paralel berbagi koneksi. Jika Anda merancang atau mengoperasikan API, Anda harus tahu apa yang berubah, apa yang tidak, dan bagaimana cara memeriksa protokol yang digunakan endpoint Anda saat ini.
Satu hal tetap konstan di semua ini: permintaan, respons, kode status, dan payload JSON Anda terlihat identik pada HTTP/1.1, HTTP/2, dan HTTP/3. Alat seperti Apidog menguji dan men-debug pada lapisan API, sehingga semua yang Anda validasi tentang perilaku endpoint tetap berlaku tidak peduli versi transport mana yang dinegosiasikan infrastruktur Anda di bawahnya. Jika Anda sudah membaca ulasan kami tentang apa itu HTTP/2 dan cara menguji API HTTP/2, artikel ini melanjutkan dari bagian tersebut.
Apa itu protokol QUIC?
QUIC adalah protokol transport yang distandarisasi dalam RFC 9000. Ini berjalan di atas UDP, bukan TCP, dan membangun kembali fitur-fitur yang disediakan TCP (keandalan, pengurutan, kontrol kongesti) di ruang pengguna, per stream, dengan enkripsi yang sudah terintegrasi sejak paket pertama.
Empat keputusan desain mendefinisikannya:
Ini berjalan di atas UDP. TCP diimplementasikan di kernel sistem operasi dan middlebox di seluruh internet, yang membuatnya hampir mustahil untuk dikembangkan. UDP adalah lapisan tipis tanpa jaminan pengiriman, sehingga QUIC membangun lapisan keandalannya sendiri di atasnya dan dapat mengirimkan peningkatan sebagai pembaruan pustaka alih-alih peningkatan OS.
TLS 1.3 sudah terintegrasi, bukan ditambahkan kemudian. Dengan TCP, Anda menyelesaikan jabat tangan TCP, kemudian jabat tangan TLS terpisah di atasnya. QUIC menggabungkannya. Penyiapan kriptografi terjadi di dalam jabat tangan transport itu sendiri, sehingga koneksi aman baru siap setelah satu putaran perjalanan (round trip). Tidak ada yang namanya QUIC tanpa enkripsi.
Stream bersifat independen. Koneksi QUIC membawa banyak stream, dan setiap stream dikirimkan secara independen. Paket yang hilang hanya akan menghentikan stream tempat paket itu berada. Ini adalah perbaikan untuk head-of-line blocking TCP, yang akan kita bahas sebentar lagi.
Koneksi bertahan dari perubahan jaringan. TCP mengidentifikasi koneksi berdasarkan alamat IP dan port. Mengubah salah satunya (keluar dari jangkauan Wi-Fi, beralih ke 5G) dan koneksi akan terputus. QUIC mengidentifikasi koneksi berdasarkan ID koneksi, sehingga klien dapat berpindah ke jaringan baru dan menjaga koneksi logis yang sama tetap hidup. Tidak ada koneksi ulang, tidak ada jabat tangan baru.
HTTP/3, yang didefinisikan dalam RFC 9114, adalah pemetaan semantik HTTP ke stream QUIC. Metode yang sama, header yang sama, kode status yang sama. Format wire yang berbeda, transport yang berbeda.
HTTP/3 vs HTTP/2: apa yang berubah dalam praktik
HTTP/2 adalah langkah besar dari HTTP/1.1. Ini memperkenalkan multiplexing, sehingga banyak permintaan dapat berbagi satu koneksi TCP daripada mengantri atau membuka enam soket paralel. Namun, ia tetap menggunakan TCP di bawahnya, dan itu menciptakan masalah yang tidak dapat dipecahkan oleh HTTP/2 sendiri.
TCP menjamin pengiriman stream byte tunggal secara berurutan. Ketika satu paket hilang, TCP menahan setiap byte setelahnya sampai transmisi ulang tiba, bahkan byte yang termasuk dalam stream HTTP/2 yang sama sekali tidak terkait. Satu paket yang hilang membekukan semua 20 permintaan yang dimultipleks pada koneksi tersebut. Itu adalah head-of-line blocking tingkat transport, dan pada jaringan yang rentan kehilangan paket, itu dapat membuat HTTP/2 lebih lambat daripada HTTP/1.1 dengan beberapa koneksinya.
HTTP/3 menghilangkan stream byte bersama. Setiap permintaan dipetakan ke stream QUIC-nya sendiri dengan urutan pengirimannya sendiri. Kehilangan paket yang membawa stream 5, dan stream 6 hingga 24 tetap mengalir. Multiplexing akhirnya berfungsi sesuai dengan apa yang selalu diklaim oleh diagram HTTP/2.
Matematika jabat tangan juga berubah:
| HTTP/2 melalui TCP+TLS 1.3 | HTTP/3 melalui QUIC | |
|---|---|---|
| Penyiapan koneksi baru | 2 putaran perjalanan (TCP + TLS) | 1 putaran perjalanan |
| Koneksi yang dilanjutkan | 1 putaran perjalanan | 0 putaran perjalanan (0-RTT) |
| Dampak paket hilang | Memblokir semua stream | Memblokir satu stream |
| Perpindahan jaringan (Wi-Fi ke 5G) | Koneksi terputus, koneksi ulang penuh | Koneksi bermigrasi, tetap berjalan |
| Enkripsi | Opsional secara teori, lapisan terpisah | Wajib, TLS 1.3 terintegrasi |
Baris 0-RTT perlu diperhatikan. Ketika klien terhubung kembali ke server yang pernah dilihatnya sebelumnya, QUIC memungkinkannya mengirim data aplikasi dalam paket pertama, sebelum jabat tangan selesai. Ini sangat baik untuk latensi. Namun data 0-RTT dapat ditangkap dan diputar ulang oleh penyerang, sehingga server hanya boleh menerima permintaan idempoten dalam 0-RTT. Permintaan GET yang diputar ulang tidak berbahaya. Permintaan POST yang diputar ulang yang menagih kartu kredit tidak. Jika Anda mengaktifkan 0-RTT di edge Anda, pastikan panggilan API non-idempoten dikecualikan, atau konfirmasikan bahwa CDN Anda melakukan ini untuk Anda.
Apa Arti HTTP/3 bagi API Anda
Peningkatan protokol hanya penting jika mengubah sesuatu yang dapat Anda ukur. Berikut adalah di mana HTTP/3 membuat perbedaan untuk lalu lintas API, dan di mana tidak.
Penyiapan koneksi menjadi lebih murah
Klien seluler biasa pada koneksi RTT 60 ms menghabiskan sekitar 120 ms untuk penyiapan TCP+TLS sebelum permintaan API pertama bahkan meninggalkan perangkat. HTTP/3 memangkasnya menjadi sekitar 60 ms, dan mendekati nol pada saat melanjutkan koneksi. Untuk API yang dipanggil dari aplikasi seluler yang sering membuka koneksi baru (cold start, background wakeup, sesi berumur pendek), penghematan ini berlaku untuk setiap permintaan pertama tersebut. Untuk integrasi server-ke-server yang memiliki kumpulan koneksi hangat, jabat tangan diamortisasi hingga tidak relevan dan Anda tidak akan melihat perbedaannya.
Klien seluler berhenti memutus koneksi
Migrasi koneksi adalah fitur tersembunyi yang penting bagi tim API. Pengguna memulai permintaan di Wi-Fi kantor, berjalan ke lift, dan ponsel beralih ke jaringan seluler. Melalui TCP, permintaan yang sedang berjalan itu gagal dan logika percobaan ulang di sisi klien Anda (Anda punya logika percobaan ulang, bukan?) akan bekerja dengan koneksi ulang penuh. Melalui QUIC, koneksi mengikuti perangkat ke jaringan baru. Lebih sedikit kesalahan timeout di log klien Anda, lebih sedikit penulisan yang setengah selesai untuk dipertimbangkan.
Multiplexing tanpa mode kegagalan
Untuk API REST, perbaikan pemblokiran HOL paling penting ketika klien mengirim banyak permintaan secara paralel: sebuah dasbor yang memuat 15 widget, mesin sinkronisasi yang mendorong sejumlah pembaruan. Pada jaringan yang bersih, HTTP/2 dan HTTP/3 berkinerja hampir sama. Tambahkan kehilangan paket 1-2% (Wi-Fi konferensi yang ramai, seluler kereta bawah tanah), dan HTTP/3 menjaga permintaan paralel tetap independen sementara HTTP/2 menghentikannya secara bersamaan.
gRPC sebagian besar tetap pada HTTP/2 untuk saat ini
gRPC terikat pada HTTP/2 berdasarkan desain; kontrak wire-nya bergantung pada framing dan trailer HTTP/2. Ekosistem gRPC belum menstandarisasi pemetaan HTTP/3, dan implementasi utama (Go, Java, Python, Node) tidak mengirimkannya. Server Kestrel .NET dapat melayani gRPC melalui HTTP/3 sebagai kemampuan eksperimental, tetapi anggap itu sebagai pengecualian. Jika arsitektur Anda bergantung pada gRPC dan HTTP/2 untuk kinerja API internal, migrasi HTTP/3 bukanlah sesuatu yang perlu Anda rencanakan tahun ini.
Streaming dan lalu lintas real-time
Server-Sent Events bekerja di atas HTTP/3 tanpa perubahan, karena SSE adalah respons HTTP biasa yang berumur panjang. WebSockets lebih rumit: peningkatan WebSocket dirancang untuk TCP, dan padanannya di HTTP/3 (RFC 9220, ditambah API WebTransport yang sedang muncul) memiliki dukungan yang tidak merata. Jika Anda mempertimbangkan WebSockets versus HTTP biasa untuk fitur real-time, ketersediaan HTTP/3 seharusnya belum menjadi pendorong keputusan.
Bagian jujur: kapan HTTP/3 tidak akan membantu
Sebagian besar masalah latensi API tidak ada hubungannya dengan protokol transport. Jika endpoint Anda membutuhkan waktu 400 ms karena kueri database yang tidak terindeks, HTTP/3 akan mengirimkan respons lambat itu 60 ms lebih cepat. Caching, desain payload, kueri N+1, dan penggunaan kembali koneksi mendominasi kinerja API di dunia nyata, dan Anda harus mengoptimalkan itu sebelum memikirkan tentang transport. Sebuah uji kinerja API yang terstruktur biasanya akan menghasilkan peningkatan 10x lebih besar daripada peningkatan protokol.
HTTP/3 bersinar dalam kondisi tertentu:
- Link dengan latensi tinggi, di mana penghematan putaran perjalanan adalah keuntungan persentase tetap
- Jaringan yang rentan kehilangan paket, di mana eliminasi pemblokiran HOL sangat membantu
- Klien seluler yang berpindah jaringan di tengah sesi
- Banyak koneksi pendek daripada sedikit koneksi panjang
Untuk API JSON tipikal yang digunakan oleh server di wilayah yang sama melalui jaringan yang andal, perbedaannya terukur dalam benchmark tetapi tidak terlihat oleh pengguna. Dua catatan praktis lainnya: port UDP 443 diblokir di beberapa jaringan korporat (klien secara otomatis kembali ke HTTP/2, jadi tidak ada yang rusak), dan kripto user-space QUIC saat ini membutuhkan lebih banyak CPU server per koneksi daripada kernel TCP yang disetel.
Dukungan saat ini: siapa yang menggunakan HTTP/3 hari ini
Adopsinya lebih maju dari yang diasumsikan sebagian besar developer backend:
- Peramban: Chrome, Edge, Firefox, dan Safari semuanya mengirimkan HTTP/3 yang diaktifkan secara default.
- CDN dan edge: Cloudflare, Fastly, Akamai, dan CloudFront mendukungnya; di Cloudflare itu adalah toggle. Bagi sebagian besar tim, ini adalah jalur praktis: mengakhiri HTTP/3 di edge, menjaga HTTP/1.1 atau HTTP/2 dari edge ke origin.
- Server: Nginx menambahkan HTTP/3 eksperimental di 1.25 dengan
listen 443 quic;. Caddy mengaktifkannya secara default. LiteSpeed dan HAProxy mendukungnya. Apache httpd tidak. - Runtime: Node.js tidak memiliki dukungan server HTTP/3 bawaan yang stabil, yang merupakan alasan lain mengapa terminasi di edge adalah deployment umum.
- curl: mendukungnya dengan flag
--http3ketika dibangun dengan tumpukan TLS yang mampu HTTP/3; lihat dokumen HTTP/3 curl untuk build mana yang menyertakannya.
Cara memeriksa apakah API Anda melayani HTTP/3
Penemuan berfungsi melalui header respons Alt-Svc. Server yang mengiklankan HTTP/3 akan menjawab permintaan pertama Anda (HTTP/2) dengan sesuatu seperti:
alt-svc: h3=":443"; ma=86400
Itu memberitahu klien: layanan yang sama ini tersedia melalui HTTP/3 pada port UDP 443 selama 24 jam ke depan. Periksa dengan curl:
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Untuk membuat permintaan melalui HTTP/3 secara langsung (membutuhkan build curl yang mendukung HTTP/3):
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
Baris status melaporkan HTTP/3 alih-alih HTTP/2. Di Chrome DevTools, buka tab Jaringan, klik kanan header kolom, aktifkan kolom Protokol, dan cari h3 di samping panggilan API Anda. Dalam produksi, tambahkan protokol yang dinegosiasikan ke log akses Anda; pemisahan antara lalu lintas h2 dan h3 memberi tahu Anda berapa banyak klien Anda yang mendapatkan manfaatnya.
Saat Anda memverifikasi transport, verifikasi juga perilakunya. Arahkan Apidog ke endpoint yang sama dan pastikan kode status, skema respons, dan anggaran latensi. Kemenangan tingkat transport tidak ada gunanya jika kontrak API di bawahnya rusak, dan pemeriksaan kontrak adalah lapisan di mana perubahan protokol tidak dapat menyelamatkan Anda. Unduh Apidog secara gratis dan jalankan rangkaian pengujian yang sama sebelum dan setelah Anda mengaktifkan HTTP/3 di edge Anda; perbedaan waktu respons pada jaringan seluler adalah jawaban dunia nyata Anda, bukan judul berita benchmark.
FAQ
Apakah HTTP/3 lebih cepat dari HTTP/2?
Pada jaringan yang bersih dan berlatensi rendah: hampir tidak. Pada jaringan yang rentan kehilangan paket atau berlatensi tinggi: ya, seringkali terasa, karena HTTP/3 menghemat satu putaran perjalanan jabat tangan dan satu paket yang hilang tidak lagi menghentikan setiap permintaan multiplex. Ukur dengan profil lalu lintas Anda sendiri sebelum mengklaim kemenangan. Dan ingat HTTP/2 tetap sangat baik; jika Anda mengalami kesalahan koneksi di sana, biasanya itu adalah masalah lapisan TLS seperti masalah SSLV3_ALERT_HANDSHAKE_FAILURE daripada batasan protokol.
Apakah HTTP/3 menggunakan TCP?
Tidak. HTTP/3 berjalan di atas QUIC, yang berjalan di atas UDP, biasanya port 443. QUIC mengimplementasikan kembali keandalan, pengurutan, dan kontrol kongesti yang disediakan TCP, tetapi per stream dan di ruang pengguna. Jika UDP 443 diblokir di jaringan, klien secara otomatis kembali ke HTTP/2 melalui TCP.
Apakah saya perlu mengubah kode API saya untuk HTTP/3?
Hampir tidak pernah. Semantik HTTP tidak berubah: metode, header, kode status, dan body yang sama. Pekerjaan ada di infrastruktur (mengaktifkannya di CDN, load balancer, atau server Anda) ditambah satu pemeriksaan desain: pastikan data awal 0-RTT dibatasi untuk permintaan idempoten.
Bisakah saya menggunakan gRPC melalui HTTP/3?
Sebagian besar tidak, untuk saat ini. Format wire gRPC terikat pada HTTP/2, dan pustaka gRPC utama tidak menyediakan transport HTTP/3. .NET memiliki dukungan eksperimental. Pertahankan layanan gRPC pada HTTP/2 dan adopsi HTTP/3 di mana ia memberikan manfaat paling awal: endpoint REST publik, yang menghadap browser, dan yang menghadap seluler.