HTTP/3 Adalah: Cara Kerja QUIC, Manfaat & Cara Ceknya

Setiap kali browser membuka halaman, ada dua lapisan aturan yang bekerja bersamaan. Lapisan pertama mengatur isi percakapan: permintaan apa yang dikirim, jawaban apa yang diharapkan. Aturan itu bernama HTTP (HyperText Transfer Protocol).

Lapisan kedua jarang disebut, padahal justru menentukan kecepatan. Ia mengatur bagaimana percakapan tadi diantar melintasi internet: bagaimana data dipecah jadi paket, dan apa yang terjadi kalau satu paket hilang di jalan. Selama tiga dekade, tugas itu dipegang satu protokol yang sama: TCP (Transmission Control Protocol).

TCP menjamin semua paket sampai berurutan, dan jaminan itu punya harga. Satu paket yang hilang membuat seluruh antrean menunggu sampai paket tersebut dikirim ulang, meskipun paket setelahnya sudah tiba dengan selamat.

HTTP/3 adalah jawaban atas keterbatasan tersebut, dan jawabannya cukup radikal: bukan HTTP-nya yang dirombak, melainkan jalur pengantarnya yang diganti.

HTTP/3 Adalah Versi Ketiga Protokol Web

HTTP/3 adalah versi ketiga protokol HTTP yang meninggalkan TCP dan berjalan di atas protokol transport baru bernama QUIC, yang pada gilirannya memakai UDP. Nama pendeknya h3, dan sesekali masih ditulis "HTTP 3.0" — penulisan yang tidak dipakai spesifikasinya.

Riwayatnya berawal dari Google. Pada 2012 Google mengujicobakan protokol transport eksperimental bernama gQUIC di Chrome, untuk membuktikan bahwa memindahkan tanggung jawab dari TCP ke UDP memang memangkas waktu pendirian koneksi. Hasilnya meyakinkan. IETF lalu mengambil alih pengembangannya, merombaknya cukup dalam, dan pada November 2018 mengganti nama "HTTP-over-QUIC" menjadi HTTP/3.

Pembakuannya selesai pada Juni 2022 lewat RFC 9114. Tidak seperti HTTP/2 yang spesifikasinya sempat digantikan dokumen lain, RFC 9114 tidak mencabut RFC mana pun. Ia memetakan semantik HTTP yang sudah ada ke atas QUIC.

Adopsinya hari ini jauh dari tahap percobaan. W3Techs mencatat pada September 2026 bahwa 40,4% website memakai HTTP/3, sementara caniuse.com mencatat dukungan browser mencapai 94,53% pengguna global. Chrome dan Edge mendukungnya sejak versi 87, Firefox sejak 88, Opera sejak 74, dan Safari sejak versi 16.

QUIC Adalah Fondasi yang Membuat HTTP/3 Berbeda

Membahas HTTP/3 tanpa membahas QUIC lebih dulu akan menyesatkan, karena hampir semua yang berubah sebenarnya terjadi di QUIC.

QUIC adalah protokol transport yang dibakukan lewat RFC 9000 pada Mei 2021, yang menyediakan stream terkendali, pendirian koneksi berlatensi rendah, dan kemampuan berpindah jalur jaringan. Satu koreksi kecil: banyak tulisan menyebut QUIC sebagai singkatan "Quick UDP Internet Connections". Itu perluasan dari protokol Google yang lama; pada versi IETF, QUIC adalah nama, bukan akronim.

Tiga hal membedakan QUIC dari TCP.

1. Berjalan di atas UDP, bukan menggantikannya: UDP (User Datagram Protocol) sengaja dipilih karena sudah didukung setiap perangkat jaringan di dunia. Semua kecerdasan — pengurutan ulang, kendali kemacetan, pengiriman ulang paket hilang — dipindahkan ke dalam QUIC di atasnya.
2. Enkripsi menyatu di dalam protokol: QUIC membawa TLS 1.3 di dalam dirinya sendiri lewat RFC 9001. Tidak ada mode polos. Kalau HTTP/1.1 dan HTTP/2 secara teknis masih punya varian tanpa enkripsi, HTTP/3 tidak. Konsekuensinya, sertifikat SSL yang valid bukan lagi sekadar anjuran melainkan syarat hidup — sesuatu yang sudah kita kenal lewat TLS.
3. Berjalan di userspace, bukan di kernel: TCP tertanam di kernel dan sudah dioptimasi puluhan tahun. QUIC dijalankan sebagai kode biasa di dalam browser atau web server. Ini membuatnya cepat berevolusi, sekaligus lebih mahal secara CPU.

Soal nomor port, angkanya tidak berubah: HTTP/3 tetap memakai 443. Yang berubah jenisnya. HTTPS biasa memakai TCP 443, sedangkan HTTP/3 memakai UDP 443. Perbedaan satu kata ini penyebab paling umum HTTP/3 gagal bekerja di jaringan tertentu.

Cara Kerja HTTP/3 dari Handshake sampai Perpindahan Jaringan

Empat mekanisme berikut yang benar-benar membedakan pengalaman memakai HTTP/3.

Handshake yang digabung menjadi satu perjalanan

Pada HTTPS konvensional ada dua perkenalan berurutan: TCP melakukan three-way handshake untuk membuka jalur, lalu TLS menyepakati kunci enkripsi. Dua ronde perjalanan pulang-pergi, sebelum satu byte data pun terkirim.

QUIC menggabungkan keduanya. Karena TLS 1.3 sudah menjadi bagian dari protokol, negosiasi jalur dan negosiasi kunci berlangsung dalam perjalanan yang sama. Untuk pengunjung yang sudah pernah terhubung, tersedia 0-RTT — data permintaan dititipkan bersama paket pertama, sehingga jawaban bisa mulai mengalir tanpa perkenalan ulang sama sekali.

0-RTT punya syarat yang sering dilewatkan: data yang dikirim di dalamnya bisa direkam dan dikirim ulang oleh penyerang. Karena itu ia hanya aman untuk permintaan idempoten — permintaan yang hasilnya sama meski dijalankan berulang kali, seperti membaca halaman. Jangan dipakai untuk mengirim pesanan atau mengubah kata sandi.

Paket yang hilang tidak lagi menahan seluruh antrean

Inilah masalah yang paling sering disebut dengan nama head-of-line blocking (antrean tertahan oleh yang paling depan).

HTTP/2 sudah mampu mengalirkan banyak berkas bersamaan dalam satu koneksi. Namun TCP di bawahnya tidak tahu apa-apa soal pembagian itu; ia hanya melihat satu aliran byte yang harus berurutan. Ketika satu paket hilang, TCP menahan semua data sesudahnya sampai paket itu dikirim ulang — termasuk data berkas lain yang sudah lengkap.

QUIC mengenal batas antar stream sejak awal. Paket yang hilang hanya menahan stream miliknya sendiri. Gambar yang paketnya hilang akan menunggu, sementara berkas CSS dan JavaScript tetap diserahkan ke browser.

Koneksi bertahan saat Anda berpindah jaringan

Koneksi TCP dikenali dari kombinasi alamat IP dan port di kedua ujung. Begitu ponsel Anda beralih dari Wi-Fi kantor ke jaringan seluler, alamat IP-nya berubah dan seluruh koneksi mati. Unduhan terputus, panggilan video terhenti, semuanya dimulai dari nol.

QUIC memberi setiap koneksi sebuah connection ID yang tidak terikat pada alamat IP. Saat alamat berubah, klien melanjutkan memakai ID yang sama dan koneksi tetap hidup. Untuk pengguna yang sehari-hari berpindah antara Wi-Fi dan seluler, ini keuntungan yang paling terasa dan paling jarang disadari.

Bagaimana browser tahu sebuah situs melayani HTTP/3

Browser tidak bisa menebak. Ia harus diberi tahu, dan mekanismenya unik: permintaan pertama justru tetap lewat TCP.

Header Alt-Svc inilah kunci penemuannya, dan angka ma di belakangnya adalah masa berlaku catatan itu dalam detik. Cloudflare mengiklankan ma=86400, artinya berlaku satu hari.

Ada jalan pintas yang lebih baru. RFC 9460 (Juni 2023) memperkenalkan rekaman DNS bertipe HTTPS, yang mengumumkan dukungan h3 lewat parameter alpn sebelum koneksi apa pun dibuka. Browser pun tidak perlu menempuh satu kunjungan lewat TCP lebih dulu.

Perbedaan HTTP/1.1, HTTP/2, dan HTTP/3

Ketiganya hidup berdampingan, bukan saling menggantikan. Server yang sehat melayani ketiganya dan membiarkan browser memilih.

Kolom tengah sengaja diringkas. Cara kerja multiplexing, kompresi HPACK, dan nasib fitur Server Push sudah dibahas terpisah di artikel HTTP/2.

Keunggulan yang Benar-Benar Terukur, Bukan Sekadar Janji

Kalimat "HTTP/3 lebih cepat" sering diucapkan tanpa menyebut apa yang lebih cepat. Ada tiga klaim berbeda di dalamnya, dan hanya satu yang bisa dijamin.

Yang terukur dan konsisten adalah waktu pendirian koneksi. Kami menjalankan curl 8.20.0 pada 8 September 2026, tiga kali per kombinasi, membandingkan time_appconnect — waktu sampai jalur terenkripsi siap dipakai.

Median keseluruhan turun dari 52,3 ms menjadi 31,5 ms, hemat sekitar 40%. Angka ini masuk akal secara mekanisme, karena memang satu ronde perjalanan yang dihilangkan.

Yang masuk akal tetapi tidak dijamin adalah ketahanan di jaringan buruk. Pada koneksi seluler dengan paket hilang, hilangnya antrean tertahan memberi keuntungan nyata. Besarnya bergantung tingkat kehilangan paket dan jumlah berkas di halaman Anda.

Yang sama sekali tidak dijamin adalah waktu muat halaman. Pada pengukuran yang sama, time_total tidak konsisten memihak HTTP/3. Untuk indowebsite.co.id, HTTP/2 berkisar 0,179–0,448 detik sementara HTTP/3 berkisar 0,192–0,206 detik. Ukuran halaman dan kualitas jaringan jauh lebih menentukan daripada versi protokolnya.

Kapan HTTP/3 Justru Lebih Lambat dan Apa Kelemahannya

Bagian berikut menentukan apakah HTTP/3 layak dinyalakan di kasus Anda.

Pada jaringan yang sangat cepat, HTTP/3 bisa kalah telak. Penelitian "QUIC is not Quick Enough over Fast Internet" dipresentasikan di ACM Web Conference 2024 oleh peneliti University of Michigan, USC, dan University of Minnesota. Mereka mengukur penurunan laju data hingga 45,2% dibanding TCP dengan HTTP/2 pada koneksi 1 Gbps di Chrome. Selisihnya mulai muncul saat bandwidth melewati sekitar 500 Mbps dan praktis setara di bawah 600 Mbps. Bitrate video ikut turun hingga 9,8%.

Penyebabnya beban pemrosesan di sisi penerima. Untuk mengunduh berkas yang sama, stack UDP melakukan 744 ribu pembacaan paket sementara TCP hanya 58 ribu, karena implementasi QUIC yang diuji belum memakai UDP GRO (Generic Receive Offload).

UDP 443 diblokir di banyak jaringan. Sejumlah firewall perusahaan hanya mengizinkan TCP pada port 443 karena lalu lintas UDP tidak bisa diperiksa perangkat inspeksi mereka. Saat kami menguji dua situs Indonesia yang tidak melayani HTTP/3, kegagalannya muncul dalam dua bentuk. Satu ditolak dalam 26 milidetik, satu lagi menggantung sampai batas waktu 10 detik habis. Bentuk kedua itulah yang menyulitkan, karena paket UDP dibuang diam-diam tanpa pemberitahuan apa pun.

Dukungan web server masih timpang. Perlu diketahui sebelum berencana:

1. Apache 2.4 belum mendukungnya sama sekali: dokumentasi mod_http2 per September 2026 tidak menyebut HTTP/3 maupun QUIC satu kali pun. Dukungannya berhenti di h2 dan h2c.
2. Nginx mendukung tetapi tidak aktif begitu saja: modul HTTP/3 masuk sejak versi 1.25.0 (23 Mei 2023) dan sampai kini tidak dibangun secara default. Anda perlu paket yang dikompilasi dengan --with-http_v3_module.
3. LiteSpeed dan Caddy paling mudah: keduanya menyalakan HTTP/3 tanpa konfigurasi tambahan.

Rekomendasi praktisnya berangka. Kalau mayoritas pengunjung Anda datang dari perangkat seluler dan halaman Anda memuat lebih dari 30 berkas, HTTP/3 layak dinyalakan berdampingan dengan HTTP/2. Kalau situs Anda melayani unduhan berkas besar ke pengguna fiber di atas 500 Mbps, ujilah dulu. Dan jangan pernah mematikan HTTP/2 — ia jaring pengaman ketika UDP diblokir.

Risiko Keamanan HTTP/3 pada 2026

Protokol yang lebih baru berarti kode yang lebih muda, dan kode muda punya lebih banyak cacat yang belum ditemukan. Tiga hal berikut tercatat setahun terakhir.

Dua kerentanan khusus HTTP/3 di nginx tahun ini. Pada 13 Mei 2026, rilis 1.31.0 menambal CVE-2026-40460: pemrosesan perpindahan koneksi dapat membuat stream QUIC baru menerima alamat klien baru sebelum divalidasi, sehingga penyerang bisa memalsukan alamat. Lalu pada 17 Juni 2026, rilis 1.31.2 menambal CVE-2026-42530, sebuah use-after-free saat memproses sesi QUIC yang disusun khusus, yang dapat merusak memori proses pekerja. Rilis 1.31.5 pada 2 September 2026 masih memuat perbaikan HTTP/3 lainnya.

Penerjemahan HTTP/3 ke HTTP/1.1 di CDN bisa dijadikan pengganda serangan. Pada 20 Agustus 2026, peneliti dari National University of Singapore, Fuzhou University, University of Sheffield, dan Johns Hopkins University mengumumkan teknik bernama CDN Tsunami. Ia memanfaatkan tabel dinamis QPACK: header terkompresi dari klien harus dimekarkan CDN sebelum diteruskan ke server asal yang berbahasa HTTP/1.1. Faktor penggandaannya terukur 36,41 kali hingga 66,06 kali pada enam CDN besar.

Kewajiban idempoten pada 0-RTT. RFC 9001 Bagian 9.2 menyatakan terus terang bahwa data 0-RTT dapat diputar ulang penyerang. Kalau Anda menyalakannya, pastikan hanya permintaan aman yang boleh lewat.

Kesimpulan praktisnya sederhana: perbarui web server Anda. Untuk situs di belakang CDN, mitigasi ketiga hal di atas ada di tangan penyedia CDN.

Cara Memeriksa Website Anda Sudah HTTP/3 atau Belum

Ada tiga cara, disusun dari yang termudah. Semuanya sudah kami jalankan sendiri.

Cara pertama: baca header Alt-Svc. Cara ini bekerja bahkan dengan curl bawaan sistem yang belum mendukung HTTP/3, karena yang dibaca hanyalah pengumuman dari server:

curl -sSI https://domain-anda.com/ \
  | grep -i alt-svc

Kalau server melayani HTTP/3, keluarannya seperti ini:

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

Kalau perintah itu tidak mengembalikan apa pun, situs Anda belum mengumumkan HTTP/3.

Cara kedua: paksa koneksi HTTP/3 dan lihat hasilnya. Cara ini butuh curl yang dibangun dengan dukungan HTTP/3. Periksa dulu:

curl --version | grep -o HTTP3

Kalau kata HTTP3 tidak muncul, curl Anda belum mendukungnya — curl 8.7.1 bawaan macOS pun belum. Kalau sudah, jalankan:

curl -sS -o /dev/null --http3-only \
  -w 'versi %{http_version}\n' \
  https://domain-anda.com/

Perhatikan bahwa yang dipakai adalah --http3-only, bukan --http3. Opsi --http3 mengizinkan curl turun ke HTTP/1.1 secara diam-diam bila QUIC gagal, dan status 200 yang muncul membuat orang menyimpulkan HTTP/3 aktif padahal tidak. Kami menemukannya pada nginx.org: --http3 mengembalikan 200 lewat HTTP/1.1.

Cara ketiga: tab Network di DevTools browser. Buka DevTools, pilih tab Network, klik kanan pada baris judul kolom, lalu aktifkan kolom Protocol. Nilai h3 menandakan permintaan itu dilayani HTTP/3. Kunjungan pertama ke sebuah domain biasanya masih tercatat h2 — muat ulang sekali lagi.

Cara Mengaktifkan HTTP/3 di CDN dan Web Server

Satu temuan dari pemeriksaan kami mengubah urutan langkah yang masuk akal. Kami memeriksa lima penyedia hosting Indonesia pada 8 September 2026. Semuanya melayani HTTP/3, dan semuanya mengembalikan header server: cloudflare — HTTP/3-nya datang dari tepi jaringan CDN, bukan dari web server mereka sendiri.

Artinya, untuk sebagian besar pemilik website, mengaktifkan HTTP/3 bukan pekerjaan kompilasi ulang.

Lewat CDN — paling realistis. Kalau situs Anda sudah berada di belakang Cloudflare atau CDN sejenis, HTTP/3 tersedia sebagai satu tombol di panel, dan pada banyak paket ia menyala secara bawaan. Pengunjung terhubung ke edge lewat HTTP/3, sementara sambungan dari edge ke server asal Anda tetap memakai protokol lama. Tidak ada yang perlu diubah di web server Anda.

Di server sendiri. Kalau Anda mengelola VPS atau dedicated server tanpa CDN, langkahnya bergantung pada web servernya:

1. Nginx: pastikan biner Anda dikompilasi dengan --with-http_v3_module (nginx -V akan memperlihatkannya), lalu tambahkan baris listen khusus QUIC berdampingan dengan yang lama. Untuk 0-RTT dibutuhkan OpenSSL 3.5.1 ke atas, BoringSSL, LibreSSL, atau QuicTLS. Modul ini tidak dapat dibangun di Windows.
2. OpenLiteSpeed dan LiteSpeed Enterprise: QUIC aktif secara bawaan sejak OpenLiteSpeed 1.6 dan LiteSpeed Enterprise 5.4. Biasanya Anda tidak perlu melakukan apa pun selain memastikan HTTPS aktif — lihat pembahasan OpenLiteSpeed.
3. Caddy: opsi protocols bawaannya sudah h1 h2 h3. HTTP/3 hidup tanpa konfigurasi.
4. Apache: belum tersedia. Jalan yang lazim ditempuh adalah memasang pemantul di depannya atau memakai CDN.

Berikut bentuk minimal konfigurasi Nginx yang melayani HTTP/2 dan HTTP/3 bersamaan:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;

    ssl_certificate     /path/fullchain.pem;
    ssl_certificate_key /path/privkey.pem;

    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Baris add_header Alt-Svc itu wajib. Tanpa pengumuman tersebut, browser tidak akan tahu jalur QUIC tersedia, dan konfigurasi Anda diam tanpa dipakai siapa pun.

Jangan lupa firewall. Membuka TCP 443 saja tidak cukup. Anda perlu mengizinkan UDP 443 juga, di firewall sistem operasi maupun di grup keamanan penyedia cloud. Inilah penyebab tersering konfigurasi yang tampak benar tetapi tidak pernah berhasil.

HTTP/3 dan SEO: Yang Dikatakan Dokumentasi Google

Banyak yang menyalakan HTTP/3 dengan harapan peringkat naik. Dokumentasi Google menutup harapan itu cukup jelas.

Halaman "Google Crawler Overview" di Search Central menyatakan bahwa perayap dan pengambil Google mendukung HTTP/1.1 dan HTTP/2. HTTP/3 tidak disebut sama sekali, dan protokol bawaan perayapnya justru masih HTTP/1.1. Google juga menyatakan HTTP/2 tidak memberi keunggulan peringkat.

Kesimpulan jujurnya: menyalakan HTTP/3 tidak mempercepat perayapan dan bukan faktor peringkat langsung. Yang tetap berlaku adalah pengaruh tidak langsungnya. Pengunjung nyata memakai browser yang mendukung HTTP/3, sehingga perbaikan waktu koneksi terasa oleh mereka dan terbaca pada metrik pengalaman halaman. Anggap HTTP/3 sebagai keputusan pengalaman pengguna, bukan keputusan SEO.

Pertanyaan yang Sering Muncul Seputar HTTP/3

Apakah HTTP/3 memakai UDP atau TCP?

UDP. HTTP/3 berjalan di atas QUIC, dan QUIC memakai UDP sebagai pembungkusnya. Jaminan urutan dan pengiriman ulang yang dahulu disediakan TCP kini disediakan QUIC sendiri di atas UDP.

Apakah port HTTP/3 tetap 443?

Angkanya tetap 443, jenisnya yang berbeda. HTTPS konvensional memakai TCP 443, sedangkan HTTP/3 memakai UDP 443. Keduanya perlu terbuka di firewall bila Anda ingin melayani kedua protokol.

Kalau HTTP/3 sudah aktif, HTTP/2 boleh dimatikan?

Sebaiknya tidak. HTTP/2 adalah jaring pengaman ketika UDP diblokir jaringan pengunjung. Mematikannya berarti membiarkan pengunjung di jaringan seperti itu jatuh sampai ke HTTP/1.1, yang justru membuat halaman Anda lebih lambat bagi mereka.

Kenapa HTTP/3 tidak jalan di jaringan kantor saya?

Kemungkinan besar UDP 443 diblokir atau dibuang perangkat inspeksi lalu lintas. Gejalanya khas: situs tetap terbuka normal, tetapi kolom Protocol di DevTools selalu menampilkan h2. Ini bukan kerusakan di situs Anda.

Bagaimana cara mematikan HTTP/3 di browser untuk pengujian?

Di Firefox, buka about:config lalu ubah network.http.http3.enable menjadi false. Di Chrome, jalankan dengan opsi --disable-quic. Cara ini berguna untuk memastikan sebuah gangguan memang berasal dari lapisan QUIC.

Apakah HTTP/3 wajib memakai HTTPS?

Wajib, tanpa pengecualian. QUIC membawa TLS 1.3 di dalam protokolnya dan tidak menyediakan mode tanpa enkripsi. Ini berbeda dengan HTTP/1.1 dan HTTP/2 yang secara spesifikasi masih mengenal varian polos.

Kesimpulan

HTTP/3 adalah versi ketiga protokol web yang memindahkan pekerjaan transport dari TCP ke QUIC di atas UDP. Tiga akibatnya: perkenalan koneksi menyatu dengan negosiasi enkripsi, paket yang hilang tidak lagi menahan berkas lain, dan koneksi bertahan saat pengunjung berpindah jaringan. Yang benar-benar dijamin lebih cepat hanyalah pendirian koneksinya — pada pengukuran kami sekitar 40% lebih singkat. Waktu muat halaman tidak dijamin, dan pada koneksi di atas 500 Mbps ia justru bisa lebih lambat.

Untuk sebagian besar pemilik website di Indonesia, mengaktifkannya berarti menyalakan satu opsi di CDN, bukan menyentuh web server. Nyalakan berdampingan dengan HTTP/2, dan pastikan UDP 443 terbuka di firewall. Mulailah dengan satu perintah curl di atas — cukup besar kemungkinan situs Anda sudah melayaninya tanpa Anda sadari.

Semoga artikel ini membantu.