Cum poate un singur port de proxy să accepte atât HTTP, cât și SOCKS
Explică modul în care un ascultător deliberat mixt poate distinge HTTP de SOCKS, în timp ce un ascultător normal cu un singur protocol nu poate.
Un ascultător de proxy mixt poate accepta HTTP și SOCKS pe un singur port TCP pentru că serverul inspectează primii octeți ai protocolului. Numărul portului nu face acea detectare.
O cerere de proxy HTTP începe cu o metodă HTTP, cum ar fi GET sau CONNECT. Un salut SOCKS începe cu câmpuri binare de protocol. Software-ul conceput pentru aceste intrări poate trimite conexiunea către handlerul potrivit.
Aceasta este o caracteristică explicită de implementare. Un ascultător HTTP normal al Squid nu devine mixt pentru că portul său este schimbat în 1080, iar un ascultător doar SOCKS nu învață HTTP dintr-o setare a browserului.
TLS adaugă o altă graniță: o conexiune de proxy criptată începe cu TLS, nu cu o metodă HTTP vizibilă. Suportarea ei pe același endpoint necesită o manipulare deliberată suplimentară; recunoașterea HTTP în clar și SOCKS nu stabilește această capacitate.
Folosiți protocolul de client documentat pentru endpoint. Dacă ambele funcționează, aceasta este o dovadă despre ascultătorul mixt al acelui server, nu un motiv pentru a lăsa protocolul nespecificat în fiecare client.
Ascultătorul mixt al Glider oferă un exemplu concret: se uită la un octet fără a-l consuma, trimite 0x05 către handlerul său SOCKS5 și, în caz contrar, își invocă parserul HTTP. Acel parser validează în continuare cererea primită; alegerea trimiterii nu face dintr-o intrare arbitrară un HTTP valid.
Partajarea ascultătorului TCP nu oferă prin sine asocierea UDP a SOCKS5. Glider își pornește ascultătorul UDP separat. Selectarea protocolului TCP și retransmiterea ulterioară a datagramelor sunt capacități separate.