HTTP/2 vs HTTP/3 Apa yang Benar-Benar Berubah (dan Apakah API Anda Perlu Menyadarinya)

Jawaban singkat: jika Anda berada di balik CDN, kemungkinan besar HTTP/3 sudah ditangani secara otomatis dan tidak perlu dikonfigurasi. Jika Anda menjalankan server sendiri, HTTP/2 sudah menangani kasus 95%, dan HTTP/3 adalah peningkatan yang bermanfaat namun tidak mendesak.

Versi yang lebih panjang, karena perbedaan teknis di baliknya sebenarnya menarik — dan mengetahui hal ini membantu Anda membuat keputusan yang lebih baik tentang di mana versi protokol benar-benar penting.

Apa yang Diperbaiki oleh HTTP/2

HTTP/1.1 memiliki dua masalah yang berhasil diperbaiki oleh HTTP/2.

Terlalu banyak koneksi TCP untuk memuat satu halaman. Browser membuka 6 hingga 8 koneksi TCP per asal hanya untuk mengunduh aset secara paralel. Setiap koneksi memiliki biaya pengaturan (handshake TCP, negosiasi TLS), dan pendekatan ini tidak efisien pada skala besar. HTTP/2 menggantinya dengan multiplexing: satu koneksi TCP, beberapa aliran permintaan/respons berjalan secara paralel. Tidak lagi perlu mengatur koneksi.

Kepala header yang berlebihan pada setiap permintaan. Pada HTTP/1.1, setiap permintaan mengirimkan seluruh header — User-Agent, Accept-Encoding, Authorization, semua itu — bahkan ketika tidak ada perubahan dari permintaan sebelumnya. HTTP/2 dengan kompresi HPACK menduplikasi header dengan mempertahankan tabel pencarian bersama antara klien dan server. Pada API di mana Anda mengirimkan token yang sama pada setiap panggilan, ini mengurangi beban secara signifikan pada lalu lintas tinggi. Authorization: Bearer ... Pengiriman server seharusnya menjadi kemenangan ketiga (mengirimkan sumber daya yang dibutuhkan oleh klien sebelum diminta), tetapi tidak pernah bekerja secara nyata. Chrome menghapus dukungan pada tahun 2022. Pertimbangkan ini sebagai fitur yang sudah usang dan jangan bangun sesuatu di sekitarnya.

Masalah yang Tidak Diperbaiki oleh HTTP/2

Bagian ini sering kali dilupakan: multiplexing di atas TCP memiliki batas keras. Ketika paket TCP hilang dalam perjalanan, TCP menghentikan seluruh koneksi sampai paket tersebut dikirim ulang dan dikonfirmasi. Semua aliran HTTP/2 paralel — terlepas dari aliran mana yang sebenarnya memiliki paket hilang — berhenti berjalan. Ini adalah blokade kepala (HOL) pada tingkat TCP, dan ini bukan bug pada HTTP/2 — ini adalah cara kerja TCP.

Pada koneksi kabel yang stabil, tingkat kehilangan paket cukup rendah sehingga ini jarang merugikan. Namun pada jaringan seluler, koneksi satelit, atau jalur mana pun memiliki kehilangan paket yang signifikan, keunggulan multiplexing HTTP/2 runtuh. Anda bisa memiliki 20 aliran yang dimultiplex di satu koneksi, dan satu paket yang hilang akan menghentikan semua 20 aliran tersebut.

Pada koneksi terhubung yang stabil, tingkat kehilangan paket cukup rendah sehingga hal ini jarang merugikan. Namun pada jaringan seluler, koneksi satelit, atau jalur mana pun yang memiliki kehilangan paket yang signifikan, keunggulan multiplexing HTTP/2 runtuh. Anda dapat memiliki 20 aliran yang dikompressi dalam satu koneksi, dan satu paket yang hilang akan menghentikan semua 20. 😬

Apa yang Diperbaiki oleh HTTP/3

HTTP/3 tidak hanya menyesuaikan format kerangka atau menambahkan flag fitur baru. Ini menggantikan TCP dengan QUIC — sebuah protokol transportasi yang berjalan di atas UDP.

QUIC menangani multiplexing pada lapisan transportasi, sehingga kehilangan paket hanya menghentikan aliran yang dimilikinya, bukan semua aliran lain di koneksi tersebut. Masalah blokade kepala diperbaiki pada tingkat yang tepat di dalam stack. Ini adalah inti dari hal tersebut.

Beberapa hal lain yang dibawa oleh QUIC:

Pindah koneksi.

• QUIC mengidentifikasi koneksi dengan ID koneksi, bukan 4-tuple dari IP sumber, port sumber, IP tujuan, port tujuan. Pindah dari Wi-Fi ke jaringan seluler saat transfer berlangsung, dan koneksi tetap berlangsung. Ini penting untuk aplikasi seluler; untuk panggilan API antar server, ini hampir tidak relevan. Pengaturan tangan 0-RTT.
• Untuk koneksi ke server yang diketahui, QUIC dapat melewatkan negosiasi TLS satu putaran dan mengirimkan data secara langsung. Peningkatan latency nyata saat reconnect. Catatan: 0-RTT memiliki risiko serangan replay — jangan gunakan untuk endpoint yang tidak idempoten tanpa memahami trade-off. Kewajiban TLS 1.3.
• QUIC tidak mendukung koneksi tanpa enkripsi. Tidak ada HTTP/3 tanpa TLS, berhenti sepenuhnya. Kompresi header juga berubah: HTTP/3 menggunakan QPACK alih-alih HPACK. Perbedaan ini bersifat teknis — QPACK menghindari masalah blok pada HPACK saat header dikompresi di antara aliran. Secara praktik, Anda tidak akan mengamati perbedaan; ini adalah perbaikan infrastruktur.

Perbandingan Fitur

HTTP/1.1

Fitur	HTTP/2	HTTP/3	Protokol transportasi
QUIC (UDP)	TCP	TCP	Multiplexing permintaan
Tidak (beberapa koneksi)	Blokade kepala (HOL)	Ya	Ya
Tingkat permintaan	Tingkat transportasi (masih ada)	Kompresi header	Tidak ada
HPACK	Tidak ada	QPACK	Diperlukan TLS
Tidak (spesifikasi), ya (pada browser)	TIDAK	Ya (wajib)	Pengaturan tangan 0-RTT
Pindah koneksi	TIDAK	TIDAK	Ya
Pengiriman server	TIDAK	TIDAK	Ya
Ya (dikurangi)	TIDAK	Tidak (dihapus)	Apa yang Berarti untuk Latensi API

HTTP/3 membantu paling banyak dalam kondisi tertentu. Ini tidak meningkatkan segala sesuatu secara universal.

Jaringan yang rentan terhadap kehilangan paket.

Klien mobile yang mengakses API Anda melalui LTE atau 5G dengan koneksi yang tidak optimal akan mengalami peningkatan yang terukur. Panggilan API antar pusat data di jaringan pribadi yang stabil dengan kehilangan paket yang hampir nol? Perbedaannya dapat diabaikan. Koneksi dingin dan reconnect.

Jika klien API Anda sering reconnect — fungsi serverless berdurasi pendek, ulang aplikasi mobile, container sementara — 0-RTT mengurangi biaya pengaturan. Koneksi yang berlangsung lama selama menit tidak mendapatkan manfaat dari hal ini. Volume permintaan berpengaruh.

HTTP/2 dan HTTP/3 berlaku baik saat klien membuat banyak permintaan paralel. Browser yang memuat 80 aset secara paralel akan mengalami peningkatan besar dari multiplexing. API REST yang mengirimkan 3 permintaan secara berurutan hanya mengalami peningkatan yang lebih kecil. Semakin banyak permintaan paralel yang dilakukan klien, semakin besar manfaat dari perbaikan transportasi tersebut. Cara CDN Menangani Ini

Cloudflare telah mendukung HTTP/3 sejak 2019 dan mengaktifkannya secara default. AWS CloudFront menambahkan dukungan pada tahun 2022. Fastly, Akamai, BunnyCDN — semua mendukungnya.

Arsitektur ini penting: CDN mengakhiri koneksi klien di tepi mereka. Bahkan ketika klien menghubungi CDN melalui HTTP/3 menggunakan QUIC, bagian dari CDN ke sumber adalah hampir pasti HTTP/1.1 atau HTTP/2 di atas TCP. Jadi, "mengaktifkan HTTP/3" di CDN tidak memerlukan perubahan pada server sumber Anda.

Jika Anda menggunakan Cloudflare, periksa pengaturan Speed → Optimization — HTTP/3 (dengan QUIC) adalah toggle yang diaktifkan secara default untuk kebanyakan zona. CDNs lainnya bervariasi. Ini adalah perubahan yang paling menguntungkan yang dapat dilakukan oleh tim: tidak perlu perubahan pada sumber, manfaat langsung bagi klien di mobile atau jalur dengan latensi tinggi.

Apakah Anda Harus Melakukan Sesuatu?

Di balik CDN:

Periksa bahwa HTTP/3 diaktifkan dan lanjutkan. Butuh waktu 30 detik. Menjalankan nginx sendiri:

HTTP/3 membutuhkan nginx 1.25+ (cabang utama — versi stabil tertinggal pada QUIC). Anda akan membutuhkan flag kompilasi dan direktif bersama dengan pendengar TCP yang ada. Pastikan port UDP 443 terbuka di firewall Anda — beberapa konfigurasi jaringan memblokirnya. Nilai ini layak dilakukan jika Anda menyediakan pengguna di mobile; tidak layak untuk mengalami gangguan upgrade jika Anda hanya menangani komunikasi antar server. Menggunakan Caddy: --with-http_v3_module HTTP/3 diaktifkan secara default tanpa konfigurasi. Tidak ada yang harus dilakukan. listen 443 quic reuseport Membangun klien yang memanggil API pihak ketiga:

Apakah Anda mendapatkan HTTP/3 tergantung pada server yang Anda panggil, bukan pada kode Anda. curl mendukung HTTP/3 sejak versi 7.86.0 dengan backend yang kompatibel (nghttp3 atau quiche). Sebagian besar klien HTTP dalam Python dan Node belum mendukung HTTP/3 secara native. Go tidak mendukungnya secara standar; ada library terpisah jika Anda membutuhkannya. Catatan praktis: jika Anda menguji versi HTTP yang sebenarnya disepakati oleh server, atau membuat perintah curl dengan

flag, pada iotools.cloud berguna untuk membuat perintah yang tepat tanpa mencari sintaks flag secara berulang. net/http tidak mendukungnya; ada library terpisah jika Anda membutuhkannya. quic-go perpustakaan jika Anda membutuhkannya.

Catatan praktis: jika Anda menguji versi HTTP yang sebenarnya disepakati oleh server, atau membuat perintah curl dengan --http3 flag, Pembuat Perintah cURL pada iotools.cloud berguna untuk membangun perintah yang tepat tanpa harus mencari sintaks flag secara terus-menerus.

Anda mungkin juga menyukai