Baca Delapan Byte, Lalu Serahkan Tunnel SOCKS4
Hindari menelan salam tujuan atau menunggu byte yang tidak ada dengan mengurai batas tetap respons SOCKS4.
Permintaan koneksi SOCKS4 berhasil, tetapi aplikasi tidak pernah melihat salam pembuka server. Salah satu tempat untuk diperiksa adalah pembacaan pertama konektor. Pembacaan enam belas byte terlalu besar untuk respons SOCKS4 delapan byte.
| Bidang respons | Byte |
|---|---|
| Bidang versi respons | 1 |
| Kode hasil | 1 |
| Bidang port | 2 |
| Bidang alamat | 4 |
Kode hasil 0x5a menunjukkan bahwa permintaan dikabulkan. SOCKS4a mengubah cara permintaan membawa nama host; itu tidak membuat respons menjadi enam belas byte.
Setelah respons, aliran TCP yang sama membawa protokol tujuan. Server surat dapat mengirim salamnya segera. Pembacaan yang menghabiskan enam belas byte yang tersedia karena itu dapat mengambil respons proxy lengkap plus delapan byte pertama salam tersebut. Jika belum ada yang menyusul, pembacaan blocking yang terlalu besar justru dapat menambah penantian yang tidak perlu.
Panjang tepat adalah tanggung jawab parser
Meminta delapan byte sekali tidak cukup bukti bahwa delapan byte telah tiba. Pembacaan aliran dapat mengembalikan lebih sedikit. Kumpulkan panjang respons dengan tepat dalam tenggat waktu, berhenti pada aliran tertutup atau gagal, periksa respons, dan sisakan byte berikutnya untuk aplikasi.
Jika konektor memakai pembacaan berpenyangga yang lebih besar, pertahankan semua yang ada setelah batas dan teruskan ke konsumen berikutnya. Membuang kelebihannya adalah kehilangan data yang sama dengan ukuran pembacaan berbeda.
SOCKS5 memerlukan parser sendiri. Alamat responsnya dapat memiliki panjang berbeda menurut jenis alamat. Mengganti setiap pembacaan proxy dengan pembacaan tetap delapan byte akan memperbaiki satu protokol sekaligus merusak protokol lain.