Protokol QUIC
QUIC adalah protokol transport yang dibuat Google untuk membuat web lebih cepat, kemudian diserahkan ke IETF, kemudian diluncurkan ke separuh Internet dengan nama HTTP/3. Ini berjalan pada UDP, bukan TCP, mengintegrasikan enkripsi dari paket pertama, dan menghilangkan frustrasi era TCP selama beberapa dekade dalam satu desain.
Badan artikel selengkapnya disediakan dalam bahasa Inggris di bawah ini.
QUIC (awalnya "Koneksi Internet UDP Cepat") adalah protokol transport serba guna yang dirancang oleh Google mulai sekitar tahun 2012 dan distandarisasi oleh IETF sebagai RFC 9000 pada tahun 2021. Protokol ini berjalan melalui UDP, membawa aliran data, menangani enkripsi dan kontrol kemacetannya sendiri, dan berfungsi sebagai dasar HTTP/3. Pada akhir tahun 2025, QUIC membawa lebih dari 30% lalu lintas Internet berdasarkan volume di jaringan utama.
Mengapa TCP tidak cukup
TCP dirancang pada tahun 1981 dan tidak berubah pada intinya sejak saat itu. Tiga masalah menjadi semakin menyakitkan:
- Pemblokiran head-of-line. Satu paket yang dijatuhkan menghentikan semua data di belakangnya dalam koneksi TCP yang sama, bahkan jika paket yang hilang milik satu aliran dan aliran lainnya baik-baik saja. HTTP/2 menggandakan banyak aliran melalui satu koneksi TCP, yang membuat pemblokiran head-of-line menjadi lebih buruk, bukan lebih baik.
- Jabat tangan lambat. TCP memerlukan 1,5 perjalanan bolak-balik sebelum data mengalir; menambahkan TLS di atas menjadikannya 2,5+ perjalanan pulang pergi. Pada koneksi seluler, latensi ini terlihat oleh pengguna. Migrasi koneksi
- . Koneksi TCP diidentifikasi oleh 5-tuple (IP sumber, port sumber, IP tujuan, port tujuan, protokol). Saat ponsel Anda beralih dari Wi-Fi ke seluler, IP berubah dan setiap koneksi TCP terputus.
QUIC dirancang untuk memperbaiki ketiganya.
Streaming tanpa pemblokiran head-of-line
QUIC membawa beberapa aliran independen dalam satu koneksi. Setiap aliran memiliki keteraturan dan keandalannya sendiri. Jika sebuah paket hilang, hanya aliran yang terkena dampak yang terhenti — aliran lainnya melanjutkan. Ini adalah fitur utama, dan merupakan properti yang membuat HTTP/3 terasa lebih cepat daripada HTTP/2 pada koneksi lossy.
Enkripsi dimasukkan ke dalam
Setiap paket QUIC setelah jabat tangan pertama dienkripsi dengan kunci TLS 1.3, termasuk header tingkat transport. Jika TCP memaparkan nomor urut dan flag ke kotak tengah, QUIC mengenkripsinya. Jabat tangan selesai dalam satu perjalanan bolak-balik, atau nol jika klien memiliki status sesi cache (0-RTT, dengan peringatan untuk perlindungan pemutaran ulang).
Ini memiliki efek samping yang signifikan: middlebox — termasuk sistem DPI, proxy transparan, dan firewall perusahaan — tidak dapat lagi mengubah lalu lintas QUIC seperti yang mereka lakukan pada TCP. Mereka dapat melihat lalu lintas bahwa QUIC sedang mengalir, namun mereka tidak dapat memecahkan kodenya. Bagi operator jaringan, hal ini mengganggu; bagi pengguna akhir, ini adalah kemenangan privasi yang jelas.
Migrasi koneksi
Koneksi QUIC diidentifikasi oleh ID Koneksi 64-bit yang tertanam di setiap paket, bukan oleh 5-tuple jaringan. Saat IP Anda berubah — ponsel berpindah antar sel, laptop berpindah jaringan, rebinding NAT — koneksi QUIC berlanjut dengan lancar. Pustaka membuktikan kepada server bahwa IP/port baru masih merupakan klien yang sama dengan menyelesaikan jabat tangan validasi kecil, dan lalu lintas dilanjutkan.
Untuk pengguna seluler di kereta komuter dan Wi-Fi pesawat, ini menghilangkan seluruh kelas kegagalan "panggilan video saya terputus karena saya berbelok di tikungan". kontrol kemacetan — biasanya Reno, Cubic, atau BBR. Karena QUIC adalah protokol ruang pengguna (bukan dalam kernel OS seperti TCP), peningkatan kontrol kemacetan diterapkan sebagai pembaruan aplikasi, bukan peningkatan OS. Google telah menggunakan ini untuk meluncurkan BBRv2 di seluruh koneksi Chrome+QUIC lebih cepat daripada algoritme yang sama yang dapat diterapkan melalui peningkatan OS.
Di mana QUIC digunakan dan tidak digunakan
QUIC mendominasi lalu lintas browser-ke-server untuk tujuan yang mendukung HTTP/3: Google, Meta, Cloudflare, Fastly, Akamai. Browser kembali ke HTTP/2 melalui TCP jika QUIC gagal (beberapa jaringan memblokir UDP/443, beberapa firewall menghapus UDP yang tidak diketahui, dan kehilangan paket QUIC bisa sangat tinggi pada jaringan yang disetel untuk TCP).
Di luar HTTP, QUIC membawa lalu lintas RPC Google, bagian dari iCloud Apple, gRPC melalui QUIC untuk beberapa pengguna, dan semakin banyak DNS-over-QUIC. QUIC adalah dasar untuk WebTransport — API tingkat rendah bagi browser untuk melakukan streaming dua arah melalui QUIC. Dalam jangka panjang, diperkirakan akan ada lebih banyak protokol aplikasi yang di-porting ke QUIC.
Peringatan operasional
QUIC mempersulit operasi jaringan:
- Pembentukan lalu lintas berbasis
- DPI tidak bekerja dengan cara yang sama. ISP yang membatasi laju YouTube melalui DPI menemukan bahwa lalu lintas QUIC buram. Perilaku batas waktu
- NAT berbeda — NAT UDP biasanya memiliki batas waktu 30 detik dibandingkan menit TCP, sehingga QUIC mengirimkan keepalives dengan lebih agresif.
- Beberapa firewall langsung menghapus QUIC; klien harus mendeteksi ini dan mundur. Penundaan fallback dibatasi tetapi terlihat.
- Debugging QUIC memerlukan alat yang berbeda dari tcpdump; Output
qlogdan Wireshark dengan kunci TLS adalah pengaturan modern.
Pertanyaan yang sering diajukan
- Apakah QUIC lebih cepat dari TCP?
- Untuk beban kerja nyata, biasanya ya — biasanya 10–30% lebih cepat pada jaringan seluler dan jaringan lossy, lebih sedikit manfaat pada tautan kabel yang bersih. Peningkatan ini berasal dari multiplexing tanpa pemblokiran head-of-line, jabat tangan yang lebih cepat, dan migrasi koneksi. Pada jaringan yang sempurna tanpa kehilangan, kesenjangannya mengecil.
- Apakah QUIC mengenkripsi lalu lintas?
- Ya, wajib dan end-to-end. Setiap paket QUIC setelah jabat tangan dienkripsi dengan kunci TLS 1.3. Tidak ada mode "QUIC biasa". Pengamat jaringan melihat UDP terenkripsi dengan ID koneksi QUIC; mereka tidak bisa membaca aliran di dalamnya.
- Mengapa QUIC berjalan pada UDP, bukan protokol IP-nya sendiri?
- Kemampuan penerapan. Protokol IP baru memerlukan pembaruan pada setiap NAT, firewall, dan router ISP di Internet — pengerjaan selama puluhan tahun. UDP sudah didukung secara universal. QUIC mengimplementasikan keandalannya sendiri, pengendalian kemacetan, dan pemesanan di atas datagram upaya terbaik UDP.
- Bisakah terowongan VPN QUIC?
- Ya — QUIC hanyalah paket UDP ke VPN, yang merangkumnya dalam terowongannya sendiri seperti halnya dengan lalu lintas lainnya. WireGuard menanganinya dengan bersih; OpenVPN juga baik-baik saja. Lalu lintas QUIC di dalam terowongan dienkripsi ganda (lapisan QUIC + lapisan VPN), dengan overhead kecil.
- Apakah HTTP/3 memerlukan QUIC?
- Ya, menurut definisi. HTTP/3 adalah HTTP melalui QUIC; tidak ada HTTP/3-over-TCP. Penamaannya agak membingungkan karena HTTP/2 juga memiliki prototipe "over QUIC" (gQUIC), tetapi HTTP/3 versi IETF yang dikirimkan pada tahun 2021.