HTTP/2, HTTP/3, dan QUIC Melalui Proksi: Apa yang Berfungsi, Apa yang Rusak, dan Mengapa

HTTP/2 melewati proksi tanpa kesulitan karena berjalan di atas TCP, dan TCP adalah apa yang dibawa oleh terowongan CONNECT atau koneksi SOCKS5. HTTP/3 tidak: ia berjalan di atas QUIC, yang berbasis UDP, dan proksi HTTP biasa tidak dapat menerowongkan UDP sama sekali sementara kebanyakan penerapan SOCKS5 juga tidak. Konsekuensi praktisnya adalah bahwa klien yang diproksikan hampir selalu berbicara HTTP/2 (atau HTTP/1.1) ke sebuah situs bahkan ketika situs tersebut mendukung HTTP/3 — browser melakukan fallback secara senyap. Itu baik untuk sebagian besar pekerjaan, tetapi itu mengubah apa yang dilihat oleh tujuan, dan layak dipahami daripada menemukannya secara tidak sengaja.

Tiga protokol dalam satu menit

HTTP/1.1 (1997): berbasis teks, satu permintaan pada satu waktu per koneksi; browser membuka beberapa koneksi secara paralel untuk mengompensasi.
HTTP/2 (2015): framing biner, banyak aliran bersamaan yang multipleks di atas satu koneksi TCP, kompresi header (HPACK), server push (sekarang sebagian besar ditinggalkan). TCP + TLS yang sama di bawahnya seperti HTTP/1.1.
HTTP/3 (2022): semantik yang sama dengan HTTP/2 tetapi dibawa oleh QUIC, sebuah transport yang berjalan di atas UDP, membangun TLS 1.3 ke dalam jabat tangannya, menghindari head-of-line blocking TCP, dan memungkinkan koneksi bertahan saat IP berubah (ponsel berpindah dari Wi-Fi ke 4G).

Browser mengetahui bahwa sebuah situs menawarkan HTTP/3 dengan salah satu dari dua cara: header respons Alt-Svc: h3=":443" pada respons HTTP/2 sebelumnya, atau catatan DNS HTTPS yang mengiklankannya. Setelah mengetahuinya, ia mencoba QUIC pada koneksi berikutnya dan mengingat hasilnya.

Bagaimana proksi membawa masing-masing

Proksi HTTP

Untuk tujuan HTTPS, klien mengirim CONNECT host:443, proksi membuka koneksi TCP ke tujuan dan berubah menjadi pipa byte yang bodoh. Apa pun yang dinegosiasikan klien dan tujuan di dalam pipa itu — TLS 1.3, lalu HTTP/1.1 atau HTTP/2 melalui ALPN — tidak terlihat oleh proksi dan berfungsi tanpa perubahan. HTTP/2 melalui proksi HTTP karena itu sepenuhnya normal.

UDP tidak memiliki tempat dalam model ini. CONNECT membuat terowongan TCP; tidak ada cara standar bagi proksi HTTP/1.1 biasa untuk mengatakan “teruskan datagram UDP saya ke host ini.” Browser yang dikonfigurasi dengan proksi HTTP tidak mencoba QUIC ke origin — Chrome dan Firefox menonaktifkan HTTP/3 untuk koneksi yang diproksikan — dan menggunakan HTTP/2 melalui terowongan sebagai gantinya. Tidak ada kesalahan, tidak ada peringatan.

Proksi SOCKS5

SOCKS5 memang mendefinisikan perintah UDP ASSOCIATE untuk menyampaikan datagram. Secara prinsip, proksi SOCKS5 dapat membawa QUIC. Dalam praktiknya:

banyak proksi SOCKS5 komersial hanya mengimplementasikan CONNECT (TCP) dan menolak atau mengabaikan UDP ASSOCIATE;
relay UDP melalui SOCKS5 mengharuskan proksi memiliki port UDP yang dapat dijangkau dan klien mendukung tarian asosiasi, yang tidak dilakukan browser untuk HTTP/3;
Chrome dan Firefox memperlakukan proksi SOCKS sama seperti proksi HTTP untuk tujuan ini: HTTP/3 tidak dicoba.

Jadi bahkan jika proksi dapat meneruskan UDP, browser tidak akan memintanya. Klien QUIC baris perintah dan beberapa pustaka dapat diarahkan ke proksi SOCKS5 yang mendukung UDP, tetapi itu adalah konfigurasi khusus, bukan default. Perbandingan SOCKS5 vs HTTP kami mencakup perbedaan TCP/UDP secara lebih luas.

Apa yang akan membawa HTTP/3: MASQUE dan CONNECT-UDP

Kelompok kerja MASQUE IETF menstandarkan CONNECT-UDP (RFC 9298), sebuah ekstensi yang memungkinkan proksi HTTP/3 (atau HTTP/2) menerowongkan payload UDP — dan dengan demikian QUIC ke origin. Ini yang digunakan oleh iCloud Private Relay Apple dan beberapa proksi privasi yang lebih baru. Dukungan di proksi komersial tujuan umum dan di pengaturan proksi browser masih jarang; ketika penyedia mengiklankan “dukungan HTTP/3”, ada baiknya bertanya apakah yang mereka maksud adalah proksi berbicara HTTP/3 kepada Anda atau dapat menerowongkan HTTP/3 ke origin — itu adalah hal yang berbeda.

Apa yang sebenarnya terjadi, langkah demi langkah

Browser yang diproksikan Anda meminta https://example.com. Ia membuka CONNECT example.com:443 melalui proksi.
Di dalam terowongan, ia melakukan jabat tangan TLS 1.3, menawarkan ALPN h2 dan http/1.1. Origin memilih h2. Anda berada di HTTP/2.
Respons membawa Alt-Svc: h3=":443". Browser mencatatnya — dan, karena proksi dikonfigurasi, mengabaikannya untuk tujuan koneksi.
Setiap permintaan berikutnya ke origin itu berlanjut melalui HTTP/2 melalui terowongan.

Matikan proksi dan muat ulang: browser sekarang menghormati Alt-Svc dan situs yang sama dilayani melalui HTTP/3. Tidak ada yang rusak dalam kedua kasus; protokolnya hanya berbeda.

Mengapa itu penting

Kinerja

Keunggulan HTTP/3 — jabat tangan lebih cepat, tanpa head-of-line blocking pada tautan yang lossy, migrasi koneksi — hilang melalui proksi. Untuk proksi pusat data pada tautan yang baik, perbedaannya kecil. Untuk proksi seluler, di mana hop terakhir adalah tautan seluler yang lossy, QUIC akan paling membantu dan justru di situlah Anda tidak dapat memilikinya. Anggarkan sedikit lebih banyak latensi daripada yang ditunjukkan koneksi HTTP/3 langsung; lihat metodologi di cara mengukur kecepatan proksi.

Fingerprinting dan konsistensi

Ini yang halus. Sistem anti-bot mencatat protokol mana yang digunakan klien dan seperti apa pengaturan HTTP/2-nya (lihat cara kerja sistem anti-bot). Chrome modern pada koneksi langsung mencapai sebagian besar situs besar melalui HTTP/3. Chrome yang sama melalui proksi tiba melalui HTTP/2. Dengan sendirinya itu tidak mencurigakan — banyak pengguna nyata berada di belakang proksi perusahaan dan tidak pernah menggunakan HTTP/3 — tetapi itu adalah satu titik data lagi, dan itu berarti sidik jari HTTP/2 Anda (nilai SETTINGS, urutan header) sekarang selalu terekspos dan harus konsisten dengan browser yang diklaim. Klien HTTP yang meniru browser harus meniru lapisan HTTP/2, bukan hanya lapisan TLS, untuk alasan ini; artikel fingerprinting TLS menjelaskan tumpukannya.

Alat scraping

requests Python hanya berbicara HTTP/1.1; httpx dapat melakukan HTTP/2 dengan ekstra h2; aiohttp adalah HTTP/1.1. Tidak ada yang melakukan HTTP/3 melalui proksi. Karena browser yang diproksikan berada di HTTP/2, menggunakan HTTP/2 di klien Anda (jika pustaka mendukungnya) membuat Anda paling dekat dengan tampilan pengguna yang diproksikan sebenarnya. Contoh di Proksi di Python.

Panduan praktis

Situasi	Apa yang Anda dapatkan	Tindakan
Browser + proksi HTTP, situs HTTP/3	HTTP/2 melalui terowongan CONNECT	Tidak perlu melakukan apa pun; ini normal
Browser + proksi SOCKS5, situs HTTP/3	HTTP/2 (browser tidak mencoba QUIC melalui SOCKS)	Tidak perlu melakukan apa pun
Anda perlu HTTP/3 ke origin melalui proksi	Memerlukan dukungan CONNECT-UDP/MASQUE dari ujung ke ujung	Tanyakan penyedia secara spesifik; anggap tidak ada kecuali dikonfirmasi
Situs berperilaku berbeda saat diproksikan vs langsung	Mungkin terkait protokol, lebih mungkin terkait IP	Bandingkan dengan browser asli pada proksi yang sama sebelum menyalahkan HTTP/3
Meniru klien untuk situs yang dilindungi	Harus cocok dengan SETTINGS HTTP/2 dan urutan header browser	Gunakan klien yang meniru HTTP/2, bukan hanya TLS
Mengukur latensi proksi	Bandingkan yang sebanding: HTTP/2 langsung vs HTTP/2 diproksikan	Jangan bandingkan HTTP/3 langsung dengan HTTP/2 diproksikan

Pertanyaan yang sering diajukan

Apakah HTTP/2 berfungsi melalui proksi?

Ya. HTTP/2 berjalan di atas TCP dan TLS, yang dibawa secara transparan oleh terowongan CONNECT atau koneksi SOCKS5. Proksi tidak perlu memahami HTTP/2 sama sekali.

Apakah HTTP/3 berfungsi melalui proksi?

Umumnya tidak. HTTP/3 menggunakan QUIC melalui UDP; proksi HTTP tidak dapat menerowongkan UDP dan browser tidak mencoba QUIC ketika proksi dikonfigurasi. Browser secara otomatis melakukan fallback ke HTTP/2. Hanya proksi yang mendukung CONNECT-UDP (MASQUE) yang dapat membawa HTTP/3 ke origin, dan itu jarang.

Bisakah proksi SOCKS5 membawa QUIC?

Protokolnya memiliki perintah relay UDP, tetapi banyak layanan SOCKS5 komersial tidak mengimplementasikannya dan browser tidak menggunakannya untuk HTTP/3. Klien khusus dapat, jika proksi benar-benar mendukung UDP ASSOCIATE.

Apakah menggunakan HTTP/2 alih-alih HTTP/3 akan membuat saya terdeteksi?

Tidak dengan sendirinya — banyak pengguna sah berada di belakang proksi yang memaksa HTTP/2. Tetapi itu berarti sidik jari HTTP/2 Anda selalu terlihat, jadi harus konsisten dengan browser yang Anda klaim.

Apakah HTTP/3 lebih cepat melalui proksi?

Anda tidak mendapatkan HTTP/3 melalui proksi biasa, jadi pertanyaan itu tidak muncul; Anda mendapatkan HTTP/2, yang sedikit lebih lambat pada tautan yang lossy daripada HTTP/3. Pada tautan pusat data yang baik, perbedaannya dapat diabaikan.

Apa itu Alt-Svc?

Header respons HTTP yang digunakan situs untuk memberi tahu klien bahwa sumber daya yang sama tersedia melalui protokol atau port lain — biasanya h3=":443" untuk mengiklankan HTTP/3. Browser menghormatinya pada koneksi langsung dan mengabaikannya untuk tujuan koneksi ketika proksi dikonfigurasi.