Kinerja TLS: QUIC dan HTTP/3

HTTP/2 memultiplekskan beberapa aliran melalui satu koneksi TCP, sehingga mengatasi pemblokiran bagian depan antrean per koneksi pada HTTP/1.1. Namun, TCP sendiri menyebabkan pemblokiran bagian depan antrean pada lapisan transportasi: jika satu segmen TCP hilang, semua data di belakangnya dalam antrean menunggu pengiriman ulang, sehingga secara bersamaan memblokir semua aliran HTTP/2. Kehilangan paket sebesar 1% dapat menurunkan kinerja HTTP/2 hingga di bawah HTTP/1.1 dengan beberapa koneksi. QUIC (Koneksi UDP Cepat) mengatasi masalah ini dengan menerapkan aliran multipleks melalui UDP, sehingga pemulihan kehilangan pada tingkat aliran tidak memblokir aliran lain.

QUIC adalah protokol transportasi berbasis UDP, dikembangkan oleh Google (2012-2015) dan distandardisasi oleh IETF sebagai RFC 9000 (2021). QUIC mengintegrasikan TLS 1.3 pada lapisan transportasi—tidak ada jabat tangan TLS terpisah di atas QUIC; TLS dipadukan ke dalam jabat tangan QUIC itu sendiri. QUIC menyediakan: aliran multipleks tanpa pemblokiran bagian depan antrean, migrasi koneksi (mempertahankan koneksi ketika berpindah jaringan, misalnya dari WiFi ke LTE), pembentukan koneksi 0-RTT untuk koneksi ulang, serta deteksi kehilangan dan pengendalian kemacetan bawaan. HTTP/3 (RFC 9114) adalah semantik HTTP di atas aliran QUIC.

Jabat tangan QUIC menggabungkan pembentukan koneksi dan negosiasi TLS. Pada pengiriman pertama (0 RTT dalam terminologi QUIC), klien mengirim paket Initial yang berisi TLS ClientHello. Server merespons dengan Initial miliknya sendiri (ServerHello), ditambah paket Handshake (ekstensi terenkripsi, sertifikat, Finished). Klien mengirim Handshake Finished dan kemudian siap mengirim data aplikasi—ini adalah 1-RTT. Untuk koneksi 0-RTT, klien mengirim paket 0-RTT (data aplikasi) bersamaan dengan ClientHello menggunakan kunci yang diturunkan dari rahasia pemulihan sesi sebelumnya, sehingga tidak memerlukan perjalanan pulang-pergi tambahan untuk sesi yang tersimpan.

QUIC menggunakan empat tingkat enkripsi berbeda yang sesuai dengan tahap-tahap jadwal kunci TLS: Initial (AEAD turunan QUIC yang menggunakan kunci konstan yang telah diketahui—memberikan integritas, tetapi tidak memberikan kerahasiaan terhadap penyerang canggih), Handshake (diturunkan dari TLS handshake_secret—memberikan kerahasiaan untuk pesan jabat tangan TLS), 0-RTT (diturunkan dari early_secret sesi sebelumnya—mengenkripsi data aplikasi 0-RTT), dan 1-RTT (diturunkan dari master_secret TLS—mengenkripsi semua data aplikasi). Tajuk QUIC dienkripsi sebagian: nomor paket dan muatan dienkripsi, tetapi sebagian informasi perutean (ID Koneksi) tetap terlihat oleh penyeimbang beban.

Koneksi QUIC diidentifikasi oleh ID Koneksi (CID), bukan 4-tupel (IP sumber, port sumber, IP tujuan, port tujuan). Hal ini memungkinkan koneksi bertahan saat jaringan berubah: ketika klien seluler berpindah dari WiFi ke LTE, alamat IP berubah, tetapi CID tetap sama. Klien mengirim bingkai PATH_CHALLENGE melalui jalur baru; server merespons dengan PATH_RESPONSE untuk memvalidasi alamat baru tersebut. Koneksi berlanjut tanpa hambatan dan tanpa negosiasi ulang. TCP tidak dapat mendukung hal ini—koneksi TCP terikat pada 4-tupelnya dan harus dibangun ulang ketika jaringan berubah, sehingga memerlukan jabat tangan TLS baru. Migrasi QUIC meningkatkan kinerja yang dirasakan pengguna seluler secara signifikan.

HTTP/3 memetakan semantik HTTP ke aliran QUIC. Setiap pasangan permintaan dan respons HTTP menempati satu aliran QUIC dua arah. Aliran QUIC bersifat independen: kehilangan pada aliran 3 tidak memblokir aliran 7. HTTP/3 menggunakan QPACK untuk kompresi tajuk (menggantikan HPACK milik HTTP/2)—QPACK didesain ulang agar dapat bekerja tanpa memerlukan pengiriman secara berurutan. Dua aliran kontrol satu arah khusus membawa pengaturan dan instruksi penyandi/pengurai. Server push dalam HTTP/3 menggunakan aliran push (satu arah). Secara keseluruhan, HTTP/3 paling signifikan mengungguli HTTP/2 dalam kondisi kehilangan paket (jaringan seluler, jalur yang padat), ketika pemblokiran bagian depan antrean TCP paling merugikan.

Pengukuran dunia nyata terhadap kinerja QUIC dan HTTP/3 menunjukkan hasil yang beragam, bergantung pada kondisi jaringan. Pada jaringan berkualitas tinggi (latensi rendah, kehilangan paket rendah), HTTP/3 dan HTTP/2 memiliki kinerja yang serupa—beban tambahan QUIC (tajuk yang lebih besar dan beban pemrosesan UDP tambahan) bahkan dapat membuat HTTP/3 sedikit lebih lambat. Pada jaringan dengan banyak kehilangan paket (lebih dari 1%, yang umum pada jaringan seluler dan satelit), HTTP/3 mengungguli HTTP/2 secara signifikan. Google melaporkan penurunan buffering ulang sebesar 7-8% di YouTube ketika beralih ke QUIC. Facebook (Meta) melaporkan perbaikan latensi permintaan sebesar 7-15% untuk umpan Instagram melalui QUIC. Peningkatan paling terlihat pada latensi ekor (p95, p99), saat penghentian sementara akibat pengiriman ulang TCP paling berdampak.

Penyeimbangan beban QUIC lebih kompleks daripada TCP karena QUIC berbasis UDP dan penyeimbang beban UDP tanpa status tidak dapat mempertahankan afinitas koneksi. IETF draft-ietf-quic-load-balancers mendefinisikan sebuah pendekatan: server menyandikan informasi perutean ke dalam ID Koneksi agar penyeimbang beban dapat merutekan paket dari koneksi yang sama ke server yang sama tanpa melacak status setiap koneksi. ID Koneksi membawa ID server terenkripsi menggunakan kunci bersama antara penyeimbang beban dan server. Cloudflare, Fastly, dan Nginx menerapkan variasi pendekatan ini. Pelintasan NAT juga menjadi perhatian: koneksi QUIC harus dapat bertahan dari pengikatan ulang NAT, yang ditangani oleh mekanisme migrasi koneksi.

CDN utama telah menerapkan QUIC dan HTTP/3 secara luas. Cloudflare telah melayani HTTP/3 sejak 2019 dan melaporkan bahwa sekitar 20% lalu lintas menggunakan QUIC jika didukung oleh klien dan server. Fastly, Akamai, dan AWS CloudFront mendukung HTTP/3 di titik tepi masing-masing. Infrastruktur Google sendiri (Penelusuran, YouTube, Gmail) telah menggunakan QUIC secara internal sejak 2013 dan menyediakan HTTP/3 untuk umum. Penerapan CDN mendapat manfaat dari penyambungan kembali 0-RTT QUIC: pengunjung berulang dapat membuat koneksi lebih cepat, dan migrasi koneksi meningkatkan kinerja pengguna seluler yang berpindah-pindah di antara titik akses selama pengiriman konten.

Desain QUIC yang berbasis UDP menimbulkan pertimbangan keamanan tertentu. Serangan amplifikasi: penyerang dapat memalsukan IP sumber dan mengirim paket Initial kecil, sehingga server mengirim respons Handshake besar kepada korban—QUIC memitigasi hal ini dengan membatasi respons server hingga 3x data yang diterima sampai validasi alamat selesai (melalui mekanisme RETRY). Pembanjiran koneksi: server QUIC harus membatasi laju percobaan koneksi baru dari IP yang sama. Serangan negosiasi versi dicegah dengan menyertakan versi dalam jabat tangan yang dilindungi secara kriptografis. Enkripsi bawaan QUIC berarti perangkat inspeksi tidak dapat menganalisis muatan QUIC tanpa berada di jalur dan memiliki sertifikat server—hal ini meningkatkan privasi dibandingkan lalu lintas TCP yang dapat diinspeksi.

Penerapan HTTP/3 memerlukan: (1) Server yang mendukung QUIC (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed, atau pada tingkat aplikasi melalui pustaka quic-go, aioquic, ngtcp2). (2) Port UDP 443 terbuka pada firewall—banyak firewall perusahaan memblokir UDP 443, sehingga QUIC beralih kembali ke TCP/TLS. (3) Mengumumkan dukungan HTTP/3 melalui tajuk respons Alt-Svc: Alt-Svc: h3=":443"; ma=86400, sehingga klien HTTP/2 dapat beralih ke sana. (4) Penyeimbang beban yang memahami QUIC atau penerusan langsung UDP L4. (5) Memantau metrik khusus QUIC: peristiwa migrasi koneksi, tingkat penerimaan 0-RTT, dan tingkat pengalihan kembali protokol. Penerapan bertahap dengan pengalihan kembali ke HTTPS berlangsung tanpa terlihat oleh klien yang tidak mendukung QUIC.

QUIC mengintegrasikan TLS 1.3 pada lapisan transportasi melalui UDP, sehingga menghilangkan pemblokiran bagian depan antrean TCP dengan pemulihan kehilangan yang independen untuk tiap aliran. ID Koneksi memungkinkan migrasi ketika jaringan berubah tanpa negosiasi ulang. HTTP/3 memetakan HTTP ke aliran QUIC menggunakan kompresi tajuk QPACK. Penyambungan kembali koneksi 0-RTT menggunakan kembali rahasia sesi TLS. QUIC paling signifikan mengungguli HTTP/2 ketika terjadi kehilangan paket (jaringan seluler dan jaringan yang padat). Penyeimbangan beban QUIC memerlukan penyandian perutean server dalam ID Koneksi. Penerapan memerlukan UDP 443, server yang mendukung QUIC, dan tajuk Alt-Svc untuk mengumumkan protokol.