HTTP/3 (QUIC): Pengertian dan Dampaknya pada API Anda

HTTP/3 dan QUIC: Dampaknya bagi API Anda

Setiap permintaan HTTP yang dilayani API berjalan di lapisan transport yang jarang dipikirkan developer. Selama 25 tahun, jawabannya adalah TCP. Kemudian Google membangun QUIC di atas UDP, dan IETF menjadikannya standar. HTTP/3 adalah versi HTTP yang dirancang untuk berjalan di atas QUIC.

Coba Apidog hari ini

Perubahan ini memengaruhi kecepatan koneksi API, stabilitas pada jaringan seluler, dan cara permintaan paralel berbagi koneksi. Jika Anda merancang atau mengoperasikan API, penting untuk memahami apa yang berubah, apa yang tetap sama, dan cara memeriksa protokol yang digunakan endpoint Anda.

Hal yang tetap sama pada HTTP/1.1, HTTP/2, dan HTTP/3 adalah semantik API: permintaan, respons, kode status, header, dan payload JSON. Alat seperti Apidog tetap dapat digunakan untuk menguji dan men-debug perilaku endpoint, apa pun versi transport yang dinegosiasikan infrastruktur Anda. Artikel ini melanjutkan pembahasan apa itu HTTP/2 dan cara menguji API HTTP/2.

Apa itu protokol QUIC?

QUIC adalah protokol transport yang distandarisasi dalam RFC 9000. QUIC berjalan di atas UDP, bukan TCP, dan membangun fitur-fitur seperti keandalan, pengurutan, serta kontrol kongesti di ruang pengguna. Enkripsi TLS 1.3 juga terintegrasi sejak paket pertama.

Empat keputusan desain utama mendefinisikan QUIC:

1. Berjalan di atas UDP

TCP diimplementasikan di kernel sistem operasi dan middlebox internet, sehingga sulit dikembangkan. UDP adalah lapisan tipis tanpa jaminan pengiriman. QUIC membangun lapisan keandalannya sendiri di atas UDP dan dapat dikembangkan melalui pembaruan pustaka, tanpa menunggu peningkatan sistem operasi.

2. TLS 1.3 terintegrasi

Pada TCP, klien menyelesaikan jabat tangan TCP lalu jabat tangan TLS secara terpisah. QUIC menggabungkan keduanya. Koneksi aman baru biasanya siap setelah satu round trip.

QUIC tanpa enkripsi bukan pilihan yang valid.

3. Stream bersifat independen

Satu koneksi QUIC dapat membawa banyak stream. Paket yang hilang hanya memblokir stream tempat paket tersebut berada, bukan seluruh koneksi. Ini mengatasi masalah head-of-line blocking pada tingkat transport.

4. Koneksi dapat bertahan saat jaringan berubah

TCP mengidentifikasi koneksi berdasarkan alamat IP dan port. Ketika perangkat berpindah dari Wi-Fi ke 5G, koneksi TCP biasanya terputus dan harus dibuat ulang.

QUIC menggunakan connection ID. Klien dapat berpindah jaringan sambil mempertahankan koneksi logis yang sama—tanpa koneksi ulang dan jabat tangan baru.

HTTP/3, yang didefinisikan dalam RFC 9114, memetakan semantik HTTP ke stream QUIC. Metode, header, kode status, dan body tetap sama; format wire serta transport-nya berbeda.

HTTP/3 vs HTTP/2: apa yang berubah?

HTTP/2 memperkenalkan multiplexing. Banyak permintaan dapat berbagi satu koneksi TCP, tanpa harus mengantri atau membuka banyak socket paralel.

Namun, TCP tetap menjamin satu stream byte yang berurutan. Jika satu paket hilang, TCP menahan semua byte setelahnya sampai paket tersebut ditransmisikan ulang—termasuk byte dari stream HTTP/2 lain yang tidak terkait.

Akibatnya, satu paket yang hilang dapat membekukan 20 permintaan yang sedang dimultipleks pada koneksi tersebut. Inilah head-of-line blocking tingkat transport.

HTTP/3 memetakan setiap permintaan ke stream QUIC yang independen. Jika paket pada stream 5 hilang, stream 6 hingga 24 tetap dapat mengalir.

Perbandingan jabat tangan dan perilaku

Aspek	HTTP/2 melalui TCP + TLS 1.3	HTTP/3 melalui QUIC
Koneksi baru	2 round trip: TCP + TLS	1 round trip
Koneksi dilanjutkan	1 round trip	0 round trip dengan 0-RTT
Dampak paket hilang	Memblokir semua stream	Memblokir satu stream
Wi-Fi ke 5G	Koneksi terputus dan harus dibuat ulang	Koneksi dapat bermigrasi
Enkripsi	Lapisan terpisah, secara teori opsional	Wajib dan terintegrasi dengan TLS 1.3

Baris 0-RTT perlu diperhatikan. Saat klien terhubung kembali ke server yang pernah dikenalnya, QUIC dapat mengirim data aplikasi pada paket pertama, sebelum jabat tangan selesai.

Namun, data 0-RTT dapat ditangkap dan diputar ulang oleh penyerang. Server hanya boleh menerima permintaan idempoten melalui 0-RTT:

• GET yang diputar ulang biasanya tidak berbahaya.
• POST yang diputar ulang dan menagih kartu kredit dapat menyebabkan transaksi ganda.

Jika Anda mengaktifkan 0-RTT di edge, pastikan permintaan non-idempoten dikecualikan atau pastikan CDN Anda menangani pembatasan tersebut.

Apa arti HTTP/3 bagi API?

Peningkatan protokol hanya penting jika menghasilkan perubahan yang dapat diukur. Berikut dampak HTTP/3 yang paling relevan bagi lalu lintas API.

Penyiapan koneksi menjadi lebih murah

Pada koneksi dengan RTT 60 ms, klien seluler biasanya menghabiskan sekitar 120 ms untuk penyiapan TCP + TLS sebelum permintaan API pertama dikirim.

HTTP/3 memangkas penyiapan tersebut menjadi sekitar 60 ms, dan mendekati nol saat koneksi dilanjutkan. Ini bermanfaat untuk:

• Cold start aplikasi seluler
• Background wakeup
• Sesi berumur pendek
• API yang sering membuka koneksi baru

Untuk integrasi server-ke-server dengan koneksi yang tetap hangat, biaya jabat tangan sudah diamortisasi sehingga perbedaannya mungkin tidak terlihat.

Klien seluler dapat berpindah jaringan

Bayangkan pengguna memulai permintaan di Wi-Fi kantor, lalu berjalan menuju lift dan perangkat berpindah ke jaringan seluler.

Dengan TCP, permintaan yang sedang berjalan dapat gagal dan klien harus melakukan koneksi ulang penuh. Dengan QUIC, koneksi dapat mengikuti perangkat ke jaringan baru.

Dampaknya dapat berupa:

• Lebih sedikit timeout di sisi klien
• Lebih sedikit percobaan ulang
• Lebih sedikit operasi yang selesai sebagian

Multiplexing tanpa satu titik kegagalan

Perbaikan head-of-line blocking paling penting ketika klien mengirim banyak permintaan paralel, misalnya:

• Dashboard dengan 15 widget
• Mesin sinkronisasi yang mengirim banyak pembaruan
• Halaman web yang memuat banyak resource API

Pada jaringan yang bersih, HTTP/2 dan HTTP/3 biasanya memiliki kinerja yang hampir sama. Namun, dengan kehilangan paket 1–2%—misalnya pada Wi-Fi konferensi atau jaringan seluler di kereta bawah tanah—HTTP/3 menjaga permintaan paralel tetap independen, sementara HTTP/2 dapat menghentikannya secara bersamaan.

gRPC masih banyak menggunakan HTTP/2

gRPC terikat pada HTTP/2 berdasarkan desain. Kontrak wire-nya bergantung pada framing dan trailer HTTP/2.

Ekosistem gRPC belum memiliki pemetaan HTTP/3 yang terstandardisasi. Implementasi utama Go, Java, Python, dan Node.js juga belum mengirim gRPC melalui HTTP/3 secara umum.

Server Kestrel .NET memiliki dukungan gRPC melalui HTTP/3 yang bersifat eksperimental. Jika arsitektur Anda menggunakan gRPC dan HTTP/2 untuk API internal, migrasi ke HTTP/3 belum menjadi prioritas utama. Pertimbangkan HTTP/3 terlebih dahulu untuk endpoint REST publik, endpoint yang diakses browser, dan endpoint yang banyak digunakan perangkat seluler.

Streaming dan lalu lintas real-time

Server-Sent Events (SSE) dapat berjalan di atas HTTP/3 tanpa perubahan karena SSE adalah respons HTTP biasa yang berumur panjang.

WebSockets lebih rumit. Peningkatan WebSocket awalnya dirancang untuk TCP, sedangkan padanannya di HTTP/3 melalui RFC 9220 dan API WebTransport masih memiliki dukungan yang tidak merata.

Jika Anda sedang memilih WebSockets versus HTTP biasa untuk fitur real-time, ketersediaan HTTP/3 sebaiknya belum menjadi faktor penentu.

Kapan HTTP/3 tidak membantu?

Sebagian besar masalah latensi API tidak disebabkan oleh protokol transport.

Jika endpoint membutuhkan 400 ms karena kueri database yang tidak memiliki indeks, HTTP/3 hanya mengirimkan respons lambat tersebut sekitar 60 ms lebih cepat. Caching, desain payload, kueri N+1, dan penggunaan ulang koneksi biasanya lebih dominan terhadap kinerja API dunia nyata.

Lakukan uji kinerja API sebelum mengoptimalkan transport. Hasil pengujian terstruktur sering kali menghasilkan peningkatan yang jauh lebih besar daripada perpindahan protokol.

HTTP/3 paling bermanfaat untuk:

• Link dengan latensi tinggi, karena penghematan round trip bersifat tetap secara persentase
• Jaringan dengan kehilangan paket
• Klien seluler yang berpindah jaringan di tengah sesi
• Banyak koneksi pendek, bukan sedikit koneksi panjang

Untuk API JSON tipikal yang digunakan server di wilayah yang sama melalui jaringan andal, perbedaan HTTP/3 mungkin terukur dalam benchmark, tetapi tidak terlihat oleh pengguna.

Dua catatan praktis:

1. UDP 443 diblokir pada sebagian jaringan korporat. Klien biasanya otomatis kembali ke HTTP/2, sehingga layanan tetap berfungsi.
2. Implementasi QUIC di ruang pengguna saat ini dapat menggunakan lebih banyak CPU server per koneksi dibandingkan TCP yang berjalan di kernel.

Dukungan HTTP/3 saat ini

Adopsi HTTP/3 sudah lebih maju daripada yang diasumsikan banyak developer backend:

• Browser: Chrome, Edge, Firefox, dan Safari mengaktifkan HTTP/3 secara default.
• CDN dan edge: Cloudflare, Fastly, Akamai, dan CloudFront mendukung HTTP/3. Di Cloudflare, fitur ini dapat diaktifkan melalui toggle. Pola deployment yang umum adalah mengakhiri HTTP/3 di edge, lalu menggunakan HTTP/1.1 atau HTTP/2 dari edge ke origin. Lihat penjelasan Cloudflare tentang HTTP/3.
• Server: Nginx menambahkan dukungan HTTP/3 eksperimental pada versi 1.25 melalui listen 443 quic;. Caddy mengaktifkannya secara default. LiteSpeed dan HAProxy juga mendukung HTTP/3, sedangkan Apache httpd belum.
• Runtime: Node.js belum memiliki dukungan server HTTP/3 bawaan yang stabil. Karena itu, terminasi HTTP/3 di edge sering menjadi pilihan deployment.
• curl: curl mendukung HTTP/3 melalui flag --http3 jika dibuat dengan stack TLS yang mendukung HTTP/3. Periksa dokumentasi HTTP/3 curl untuk mengetahui build yang kompatibel.

Cara memeriksa apakah API Anda melayani HTTP/3

Penemuan HTTP/3 biasanya dilakukan melalui header respons Alt-Svc. Server yang mendukung HTTP/3 dapat mengembalikan:

alt-svc: h3=":443"; ma=86400

Header tersebut memberi tahu klien bahwa layanan yang sama tersedia melalui HTTP/3 pada port UDP 443 selama 24 jam berikutnya.

Periksa header dengan curl:

curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

Untuk memaksa permintaan melalui HTTP/3, gunakan build curl yang mendukung HTTP/3:

curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200

Baris status akan melaporkan HTTP/3, bukan HTTP/2.

Di Chrome DevTools:

1. Buka tab Network.
2. Klik kanan header kolom.
3. Aktifkan kolom Protocol.
4. Cari h3 di samping panggilan API Anda.

Di lingkungan produksi, tambahkan protokol yang dinegosiasikan ke access log. Perbandingan lalu lintas h2 dan h3 membantu Anda mengetahui berapa banyak klien yang memperoleh manfaat HTTP/3.

Verifikasi API, bukan hanya transport

Saat memverifikasi transport, verifikasi juga perilaku endpoint. Arahkan Apidog ke endpoint yang sama dan periksa:

• Kode status
• Skema respons
• Payload
• Anggaran latensi
• Perilaku pada jaringan seluler

Kemenangan di tingkat transport tidak berguna jika kontrak API rusak. Jalankan rangkaian pengujian yang sama sebelum dan sesudah mengaktifkan HTTP/3 di edge Anda. Perbedaan waktu respons pada jaringan seluler adalah indikator yang lebih relevan daripada judul benchmark.

Unduh Apidog secara gratis untuk menjalankan pengujian tersebut.

FAQ

Apakah HTTP/3 lebih cepat daripada HTTP/2?

Pada jaringan yang bersih dan berlatensi rendah, perbedaannya hampir tidak terlihat.

Pada jaringan dengan kehilangan paket atau latensi tinggi, HTTP/3 sering terasa lebih cepat karena:

• Menghemat satu round trip saat jabat tangan koneksi baru
• Tidak membiarkan satu paket hilang menghentikan semua stream multiplex

Ukur menggunakan profil lalu lintas Anda sendiri. HTTP/2 tetap sangat baik. Jika Anda mengalami kesalahan koneksi, penyebabnya bisa berada di lapisan TLS, misalnya SSLV3_ALERT_HANDSHAKE_FAILURE, bukan keterbatasan HTTP/2.

Apakah HTTP/3 menggunakan TCP?

Tidak. HTTP/3 berjalan di atas QUIC, dan QUIC berjalan di atas UDP—biasanya pada port 443.

QUIC mengimplementasikan kembali keandalan, pengurutan, dan kontrol kongesti TCP, tetapi per stream dan di ruang pengguna. Jika UDP 443 diblokir, klien biasanya kembali ke HTTP/2 melalui TCP.

Apakah saya perlu mengubah kode API untuk HTTP/3?

Hampir tidak pernah. Semantik HTTP tetap sama:

• Metode
• Header
• Kode status
• Body

Pekerjaan utama berada di infrastruktur, seperti CDN, load balancer, atau server. Satu pemeriksaan desain yang penting adalah memastikan data 0-RTT hanya digunakan untuk permintaan idempoten.

Bisakah saya menggunakan gRPC melalui HTTP/3?

Sebagian besar belum.

Format wire gRPC terikat pada HTTP/2, dan pustaka gRPC utama belum menyediakan transport HTTP/3 secara umum. .NET memiliki dukungan eksperimental.

Pertahankan layanan gRPC pada HTTP/2 dan adopsi HTTP/3 terlebih dahulu pada endpoint REST publik, endpoint yang menghadap browser, dan endpoint yang banyak digunakan klien seluler.

Referensi

• Apidog
• Apa itu HTTP/2 dan cara menguji API HTTP/2
• RFC 9000: QUIC
• RFC 9114: HTTP/3
• gRPC dan HTTP/2 untuk kinerja API internal
• WebSockets versus HTTP biasa
• Tutorial uji kinerja API
• Cloudflare: Apa itu HTTP/3?
• Dokumentasi HTTP/3 curl
• Unduh Apidog
• Memahami SSLV3_ALERT_HANDSHAKE_FAILURE

Comments

[Kane Lim]

Hello, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.

Your explanation correctly focuses on where HTTP/3 actually creates architectural value rather than treating protocol migration as a universal performance optimization. I especially like the distinction between API semantics and transport behavior.

One additional approach I would recommend is measuring HTTP/2 versus HTTP/3 using controlled network impairment instead of relying on clean network benchmarks. Inject configurable RTT, packet loss, jitter, bandwidth constraints, and connection churn, then compare p50, p95, p99 latency, retransmission behavior, handshake cost, CPU utilization, and requests completed per connection.

I would also instrument negotiated protocol, QUIC connection migration events, handshake duration, 0 RTT acceptance, fallback frequency, and UDP 443 failures in your edge telemetry. This makes the decision data driven instead of anecdotal.

For production APIs, I would terminate QUIC at the edge and maintain HTTP/2 toward legacy origins unless end to end HTTP/3 provides a measurable benefit. Pair that with strict idempotency controls for 0 RTT and adaptive fallback when UDP connectivity is poor.

The most interesting opportunity is treating transport selection as an SLO optimization problem. Once you correlate protocol, network conditions, endpoint latency, and application behavior, you can identify exactly which workloads benefit from HTTP/3 rather than migrating everything blindly.

Excellent practical article. I would be glad to exchange ideas around QUIC observability and high latency API architecture.