Hvernig einn proxy-portur getur tekið við bæði HTTP og SOCKS

Blandaður proxy-hlustandi getur tekið við HTTP og SOCKS á einum TCP-porti því netþjónninn skoðar fyrstu samskiptareglubætin. Portunúmerið framkvæmir ekki þá greiningu.

HTTP-proxybeiðni hefst með HTTP-aðferð, svo sem GET eða CONNECT. SOCKS-kveðja hefst með tvíundarsamskiptareglusviðum. Hugbúnaður sem hannaður er fyrir þessar inntök getur sent tenginguna til viðeigandi handfangs.

Þetta er skýr útfærslueiginleiki. Venjulegur Squid HTTP-hlustandi verður ekki blandaður af því að portið hans er breytt í 1080, og hlustandi sem aðeins talar SOCKS lærir ekki HTTP af stillingu vafra.

TLS bætir við annarri mörk: dulkóðuð proxy-tenging hefst með TLS, ekki sýnilegri HTTP-aðferð. Að styðja hana á sama endapunkti krefst frekari viljandi meðferðar; að þekkja venjulegt HTTP og SOCKS staðfestir ekki þá getu.

Notaðu biðlarasamskiptareglurnar sem eru skjalfestar fyrir endapunktinn. Ef bæði virka er það sönnun um blandaðan hlustanda þess netþjóns, ekki ástæða til að láta samskiptareglurnar ótilgreindar í hverjum biðlara.

Blandaður hlustandi Glider gefur áþreifanlegt dæmi: hann kíkir á eitt bæti án þess að neyta þess, sendir 0x05 til SOCKS5-handfangsins síns og kallar annars á HTTP-þáttarann sinn. Sá þáttari staðfestir samt innkomna beiðnina; valið um sendingu gerir ekki handahófskennt inntak að gildri HTTP.

Að deila TCP-hlustandanum veitir ekki sjálft SOCKS5 UDP-tengingu. Glider ræsir UDP-hlustandann sinn sér. Val á TCP-samskiptareglum og síðari gagnagrindarflutningur eru aðskilin geta.