Proksi SOCKS dan HTTP: perbedaan, kecepatan, dan pemilihan protokol
Proksi HTTP dan SOCKS menghubungkan aplikasi ke tujuan melalui perantara. Untuk browser, pengumpul data web, atau klien API, proksi HTTP dengan CONNECT merupakan pilihan awal yang praktis. SOCKS5 berguna ketika aplikasi mengharapkan SOCKS, memerlukan protokol TCP lain, atau mendukung penerusan UDP. Keduanya dapat membawa trafik ke situs HTTPS.
Protokol menentukan cara program berkomunikasi dengan proksi. Asal IP keluar, rotasi, serta akses bersama atau khusus merupakan pilihan terpisah yang dijelaskan dalam panduan jenis proksi dan pemilihan konfigurasi. Beralih dari HTTP ke SOCKS tidak dengan sendirinya mengubah sifat tersebut.
Cara HTTP dan SOCKS menangani koneksi
Penerusan HTTP: proksi menangani permintaan web
Untuk permintaan HTTP biasa yang tidak terenkripsi, klien mengirim URL tujuan, metode, dan header ke proksi. Proksi memproses permintaan itu dan memperoleh respons dari tujuan. Proksi dapat menerapkan aturan HTTP, mengubah header, atau menggunakan cache jika dikonfigurasi demikian. Ini adalah fungsi yang mungkin dimiliki proksi HTTP; layanan belum tentu mengaktifkan semuanya.
SOCKS5: proksi membuka koneksi untuk aplikasi
Klien menyepakati metode autentikasi, melakukan autentikasi jika diwajibkan, lalu memberikan alamat dan port tujuan. Proksi kemudian membentuk koneksi TCP yang diminta dan meneruskan bita aplikasi. Mekanisme yang sama dapat membawa HTTPS, SSH, atau protokol aplikasi TCP lain yang didukung. Proksi tidak perlu menafsirkan permintaan HTTP untuk meneruskannya.
HTTPS melalui CONNECT: kedua pendekatan menjadi lebih mirip
Saat membuka situs HTTPS melalui proksi HTTP konvensional, klien biasanya mengirim permintaan CONNECT. Setelah proksi menerima terowongan, klien membentuk TLS dengan situs di dalamnya. Proksi meneruskan data terenkripsi. SOCKS5 dapat meneruskan pertukaran TLS yang sama setelah tahap pembentukannya sendiri.
Ini penting saat membandingkan kecepatan dan privasi: proksi HTTP yang membawa HTTPS dalam terowongan tidak mengurai setiap permintaan halaman terenkripsi. Kedua jenis meneruskan trafik yang terlindungi. Urutan serta perbedaan antara penerusan HTTP dan terowongan dijelaskan dalam Proksi HTTP dan HTTPS.
Sekilas tentang HTTP dan SOCKS5
Perbandingan di bawah menggunakan SOCKS5. SOCKS4 dan SOCKS4a yang lebih lama memiliki kemampuan lebih sedikit dan terutama relevan jika perangkat lunak yang ada memerlukannya.
| Kemampuan | Proksi HTTP / HTTPS | Proksi SOCKS5 |
|---|---|---|
| Permintaan web | Penerusan HTTP; HTTPS umumnya menggunakan terowongan CONNECT. | Aplikasi mengirim HTTP atau HTTPS melalui koneksi yang terbentuk. |
| Aplikasi TCP lain | Dapat dilakukan melalui CONNECT jika klien mendukungnya dan port tujuan diizinkan. | Sesuai untuk aplikasi dengan dukungan SOCKS; aturan layanan tetap berlaku. |
| DNS tujuan | Proksi dapat meresolusi nama host yang diberikan dalam permintaan atau tujuan CONNECT. | Klien dapat mengirim nama host untuk resolusi jarak jauh atau meresolusinya secara lokal terlebih dahulu. |
| Perlindungan ke proksi | Proksi HTTPS menggunakan TLS pada koneksi ini. Proksi HTTP biasa tidak. | Mode biasa tanpa autentikasi dan nama pengguna/kata sandi tidak mengenkripsi koneksi ini. |
| Kendali akses | Metode autentikasi HTTP dan/atau aturan akses layanan seperti daftar IP yang diizinkan. | Metode autentikasi yang dinegosiasikan dan/atau aturan akses layanan seperti daftar IP yang diizinkan. |
| UDP | CONNECT biasa tidak cukup. UDP memerlukan mekanisme terowongan tambahan yang didukung. | Didefinisikan oleh protokol, tetapi harus diterapkan oleh klien dan layanan. |
| Kinerja | Untuk terowongan HTTPS baru, pembentukan dapat memerlukan lebih sedikit perjalanan bolak-balik. Kecepatan transfer juga bergantung pada implementasi dan rute. | Memiliki pertukaran pembentukannya sendiri. Tidak adanya penguraian HTTP tidak menjamin transfer HTTPS lebih cepat. |
Mana lebih cepat: HTTP atau SOCKS5?
Koneksi HTTPS baru dapat siap lebih cepat melalui HTTP CONNECT karena pembentukan biasa memerlukan lebih sedikit pertukaran dengan proksi. Perbandingan di bawah menunjukkan asumsi di balik perbedaan itu. Setelah terowongan terbuka, unduhan panjang atau permintaan berikutnya dapat menggunakannya kembali. Tidak ada protokol yang memiliki keunggulan tetap dalam kecepatan transfer berkelanjutan.
Koneksi baru: hitung pertukarannya
Hitung pesan pembentukan setelah koneksi TCP ke proksi siap, dengan setiap permintaan menunggu balasannya. Perbandingan ini tidak menggunakan lapisan TLS ke proksi. Autentikasi HTTP tidak diperlukan atau berhasil dengan kredensial yang disertakan dalam permintaan CONNECT pertama.
| Metode koneksi | Pertukaran sebelum terowongan siap |
|---|---|
HTTP CONNECT | 1: permintaan CONNECT dan respons berhasil. |
| SOCKS5 tanpa autentikasi protokol | 2: pemilihan metode, kemudian permintaan koneksi dan balasan. |
| SOCKS5 dengan nama pengguna dan kata sandi | 3: pemilihan metode, verifikasi nama pengguna/kata sandi, kemudian permintaan koneksi dan balasan. |
Karena itu, dengan asumsi ini SOCKS5 menambahkan satu perjalanan bolak-balik klien-ke-proksi pada kasus tanpa autentikasi, atau dua dengan autentikasi nama pengguna/kata sandi standar. Perjalanan bolak-balik, atau RTT, adalah waktu bagi pesan untuk mencapai proksi dan balasannya kembali. Pada RTT ilustratif 50 ms, pertukaran tambahan itu menyumbang sekitar 50 atau 100 ms. Ini merupakan perkiraan dari urutan protokol, bukan tolok ukur layanan proksi atau total waktu permintaan.
Kedua jalur juga mengharuskan proksi terhubung ke tujuan dan klien menyelesaikan pembentukan TLS situs. Waktu DNS, pemrosesan, dan kepadatan dapat berbeda. Tantangan autentikasi HTTP menambah pertukaran; TLS ke proksi HTTPS menambahkan pembentukannya sendiri. Kasus itu perlu dimasukkan saat membandingkan konfigurasi sebenarnya.
Koneksi yang digunakan ulang: perbedaan awal tersebar ke berbagai permintaan
Kumpulan koneksi mempertahankan koneksi yang sesuai agar tersedia untuk permintaan berikutnya. Menggunakan ulang koneksi HTTPS menghindari pengulangan TCP, negosiasi proksi, dan jabat tangan TLS situs untuk setiap permintaan. Dengan dukungan HTTP/2 pada klien dan tujuan, beberapa aliran permintaan dapat berbagi satu koneksi terbentuk. Ini dapat bekerja di dalam terowongan HTTP CONNECT maupun koneksi SOCKS5; proksi tidak perlu mengurai pesan HTTP/2 di dalam TLS.
Membuat objek klien HTTP baru untuk setiap URL dapat membuang kumpulan koneksinya. Di sini, menggunakan ulang klien berarti mempertahankan objek perangkat lunak beserta koneksinya, bukan meminta proksi mempertahankan IP keluar. Ketika satu kelompok pekerjaan berulang kali menghubungi host yang sama, penggunaan ulang koneksi itu dapat menghemat lebih banyak pekerjaan pembentukan daripada mengganti protokol proksi. Tujuan baru, koneksi tertutup, dan pengaturan proksi yang berubah tetap dapat memerlukan terowongan baru.
Transfer besar: lihat lebar pita yang tersedia
Setelah terowongan terbentuk, kecepatan unduh bergantung pada rute, kehilangan paket, lebar pita tersedia, beban proksi, dan batas layanan. Meneruskan HTTPS melalui CONNECT memang sudah berupa tugas penerusan bita. Menyebut SOCKS5 lebih cepat karena “tidak membaca HTTP” mengabaikan kasus ini.
Untuk HTTP tidak terenkripsi, cache atau pemrosesan konten yang dikonfigurasi dapat mengubah hasil. Respons dari cache adalah beban kerja berbeda dari mengunduh konten yang sama dari server asal. Perbandingan yang adil harus memperhitungkan perbedaan itu.
Protokol apa yang sebaiknya digunakan skrip web besar?
Skrip web tetap membuat permintaan HTTP ketika menggunakan SOCKS5; pilihan proksi mengubah cara skrip mencapai server. Untuk skrip baru yang mengambil halaman web atau memanggil API HTTPS, mulai dengan klien HTTP yang matang dan HTTP CONNECT, kecuali ada kebutuhan khusus yang mengarah ke pilihan lain. Simpan pilihan proksi dalam konfigurasi agar SOCKS5 dapat diuji dengan logika permintaan yang sama. Pilih pustaka yang mendukung keduanya jika perbandingan ini penting bagi proyek.
| Beban kerja | Pilihan awal praktis |
|---|---|
| Banyak permintaan singkat, sering ke host baru | Coba HTTP CONNECT terlebih dahulu. Negosiasinya yang lebih singkat dapat membantu ketika terowongan baru sering dibuat. Ukur permintaan lengkap yang berhasil. |
| Banyak permintaan ke sejumlah kecil API atau situs | Gunakan klien persisten, kumpulan koneksi, dan HTTP/2 jika didukung. Bandingkan HTTP dan SOCKS5 setelah memeriksa penggunaan ulang. |
| Berkas besar atau sesi TCP berumur panjang | Pilih protokol yang didukung dengan baik dan uji laju transfer berkelanjutan serta gangguannya. Waktu pembentukan menjadi bagian lebih kecil dari pekerjaan. |
| Protokol TCP lain atau fitur UDP yang diperlukan | Pertimbangkan SOCKS5 jika aplikasi mendukung mode yang diperlukan. Jika UDP penting, verifikasi bahwa aplikasi dan layanan dapat bertukar datagram melalui proksi. |
HTTP maupun SOCKS5 dapat digunakan oleh perangkat lunak asinkron. Protokol proksi tidak menentukan apakah permintaan berjalan bersamaan. Periksa apakah pustaka klien dapat menggunakan mode proksi terpilih untuk permintaan bersamaan, mempertahankan kumpulan koneksi, dan membatasi jumlah operasi yang sedang berlangsung. Tingkatkan aktivitas bersamaan sambil memantau pekerjaan selesai dan kesalahan: ketika proksi, jaringan, atau tujuan mencapai batasnya, lebih banyak koneksi dapat berarti antrean lebih panjang dan lebih banyak percobaan ulang.
Cara membandingkan kecepatan sebelum memperbesar skala
- Gunakan program, permintaan tujuan, ukuran respons, dan tingkat aktivitas bersamaan yang sama. Jika memungkinkan, bandingkan titik koneksi protokol dengan IP keluar dan rute yang sama; jika tidak, buat wilayah keluar dan batas layanan sebanding serta catat perbedaannya.
- Jalankan satu seri dengan koneksi baru dan seri lain dengan kumpulan koneksi normal setelah pemanasan. Pertahankan perilaku DNS, perlindungan TLS, autentikasi, versi HTTP, dan kebijakan percobaan ulang yang setara atau dokumentasikan alasan perbedaannya.
- Ukur operasi berhasil yang selesai per detik dan waktu seluruh kelompok pekerjaan, termasuk percobaan ulang. Catat pula median dan waktu penyelesaian persentil ke-95, batas waktu terlampaui, serta operasi gagal. Persentil ke-95 menunjukkan waktu ketika 95% operasi terukur telah selesai.
- Untuk unduhan, catat bita berguna yang diterima per detik. Untuk permintaan singkat, pisahkan pembentukan koneksi dari waktu hingga bita pertama dan waktu respons penuh. Waktu hingga bita pertama juga mencakup penantian tujuan menghasilkan respons.
- Ulangi proses secara bergantian melalui kedua konfigurasi dan verifikasi rute proksi yang dimaksud. Jika satu pengujian menggunakan kumpulan keluar berbeda atau beralih ke koneksi langsung, hasilnya tidak mengisolasi protokol proksi.
Pilih konfigurasi yang menyelesaikan pekerjaan nyata lebih cepat dengan tingkat kesalahan yang dapat diterima. Kegagalan autentikasi yang cepat atau respons tidak lengkap bukan laju hasil berguna. Jika kinerja keduanya serupa, pilih yang lebih sederhana untuk didukung dalam aplikasi terpilih.
Mengapa dukungan aplikasi harus didahulukan
Kolom berlabel “proksi” tidak menjanjikan semua protokol atau metode autentikasi. Misalnya, penanganan SOCKS5 bawaan Chrome mendukung permintaan TCP tetapi tidak menerapkan autentikasi nama pengguna/kata sandi SOCKS5 atau penerusan UDP. Layanan SOCKS5 dengan fitur tersebut tidak dapat membuat mode browser yang tidak mendukungnya menggunakan fitur itu.
Untuk SSH, transfer berkas, atau aplikasi TCP lain, dukungan SOCKS bawaan dapat memudahkan. HTTP CONNECT juga dapat membawa protokol TCP lain, asalkan program dapat membuat terowongan dan proksi mengizinkan port tujuan. Karena itu, “proksi HTTP” tidak selalu berarti “hanya trafik web”.
Pengaturan proksi browser juga tidak otomatis mencakup program lain atau setiap fitur di dalam browser. Adaptor eksternal memiliki cakupan dan pembatasannya sendiri. Perbedaan versi dan negosiasi dibahas dalam Proksi SOCKS5 dan SOCKS4.
Siapa yang meresolusi nama host tujuan?
Dengan SOCKS5, aplikasi dapat meresolusi tujuan secara lokal lalu mengirim alamat IP, atau mengirim nama host agar proksi meresolusinya. Dalam curl, socks5:// memilih resolusi tujuan lokal, sementara socks5h:// meminta resolusi melalui proksi. Huruf tambahan memilih perilaku klien; huruf itu tidak menciptakan protokol SOCKS baru.
Proksi HTTP juga dapat mencari nama tujuan yang diterima dalam URL atau permintaan CONNECT. Karena itu, DNS tujuan jarak jauh tersedia pada kedua protokol. Pencarian dari sisi proksi mungkin menghasilkan alamat server berbeda dan menghindari pencarian lokal untuk tujuan tersebut. Klien mungkin tetap perlu meresolusi nama host proksi itu sendiri, dan aplikasi lain mempertahankan pengaturan DNS sendiri. Pilih perilaku DNS di klien alih-alih menyimpulkannya dari protokol proksi.
Koneksi mana yang dienkripsi?
Pisahkan perlindungan konten situs dari perlindungan koneksi ke proksi. Situs HTTPS biasanya menjaga data aplikasi terenkripsi antara klien dan situs melalui kedua jenis terowongan. Ini mengasumsikan validasi sertifikat normal dan tidak ada intersepsi TLS yang dikonfigurasi.
Proksi HTTPS menambahkan TLS antara klien dan proksi. TLS melindungi permintaan proksi dan kredensial pada bagian rute itu. Dalam alamat proksi, https:// biasanya menunjukkan koneksi terlindungi ini. Pengaturan yang hanya disebut “proksi untuk situs HTTPS” mungkin justru berarti proksi HTTP biasa yang mendukung CONNECT.
Kredensial HTTP Basic yang dikirim ke proksi HTTP biasa, serta pertukaran nama pengguna/kata sandi SOCKS5 standar, dapat dibaca pihak yang dapat mengamati jalur jaringan tidak terlindungi itu. Koneksi TLS ke situs yang dibentuk kemudian tidak melindungi login proksi secara surut. SOCKS5 biasa memerlukan transport aman terpisah ketika perlindungan ini diperlukan.
Proksi tetap merupakan titik akhir koneksi TLS-nya sendiri dan mengetahui ke mana ia diminta terhubung. Jika tujuan akhir menggunakan HTTP biasa, TLS ke proksi tidak mengenkripsi koneksi HTTP selanjutnya. Demikian pula, penerusan SOCKS tidak menyembunyikan konten teks biasa hanya karena proksi tidak perlu mengurainya.
Apakah UDP atau HTTP/3 mengubah pilihan?
Untuk aplikasi yang benar-benar memerlukan UDP, SOCKS5 mendefinisikan UDP ASSOCIATE. Klien dan layanan harus menerapkannya, dan jalur jaringan harus membawa datagramnya. HTTP CONNECT biasa membawa terowongan TCP. Penerusan UDP berbasis HTTP dapat dilakukan melalui mekanisme tambahan seperti CONNECT-UDP, tetapi kedua ujung harus menerapkannya.
HTTP/3 menggunakan QUIC melalui UDP. Halaman HTTPS yang berhasil dimuat melalui proksi tidak membuktikan HTTP/3 berfungsi: klien mungkin telah menggunakan HTTP/2 atau HTTP/1.1 melalui TCP. Pilihan pengganti itu dapat sesuai untuk skrip web; pilihan itu tidak dapat menggantikan UDP untuk fitur yang memerlukan datagram. Lihat UDP dan QUIC melalui proksi untuk jalur penerusan dan keterbatasannya.
Apakah SOCKS menyembunyikan klien dengan lebih baik?
Untuk penerusan HTTP tidak terenkripsi, proksi dapat menambahkan header seperti Forwarded yang membawa informasi tentang klien asli. Terowongan HTTPS CONNECT konvensional tidak dapat menyisipkan header itu ke permintaan terenkripsi tanpa mengakhiri koneksi TLS situs. SOCKS5 juga tidak otomatis menambahkan header HTTP.
Ini tidak membuat kedua protokol menjamin anonimitas atau penerimaan situs. Operator proksi dapat mengamati metadata koneksi, sementara tujuan dapat mengenali akun, cookie, atau perilaku aplikasi. Reputasi IP keluar dan jumlah pengguna yang membaginya merupakan faktor terpisah. Beralih dari HTTP ke SOCKS pada layanan yang sama tidak otomatis menghapus pemblokiran atau mengatur ulang sesi situs.
Cara membuat pilihan akhir
Mulai dari protokol dan metode akses yang didukung aplikasi. Untuk otomatisasi web biasa, HTTP CONNECT merupakan pilihan pertama yang baik; untuk aplikasi yang dibangun di sekitar SOCKS atau mode UDP yang didukung, SOCKS5 mungkin lebih sesuai. Kemudian pilih perilaku DNS dan perlindungan ke proksi yang diperlukan, lalu bandingkan kinerja dengan beban kerja sebenarnya.
Gunakan nama host dan port sebenarnya milik layanan untuk protokol terpilih. Mengganti http:// dengan socks5:// dalam konfigurasi tidak mengaktifkan SOCKS pada server yang tidak menyediakannya. Sebelum memperbesar skala, pastikan permintaan keluar melalui proksi yang diharapkan dan proksi yang gagal tidak diam-diam memicu rute langsung yang tidak diinginkan.