Kaip vienas proxy prievadas gali priimti ir HTTP, ir SOCKS
Paaiškina, kaip sąmoningai mišrus klausytojas gali atskirti HTTP nuo SOCKS, o įprastas vieno protokolo klausytojas to negali.
Mišrus proxy klausytojas gali priimti HTTP ir SOCKS viename TCP prievade, nes serveris tikrina pradinius protokolo baitus. Prievado numeris to atpažinimo neatlieka.
HTTP proxy užklausa prasideda HTTP metodu, pavyzdžiui, GET arba CONNECT. SOCKS pasisveikinimas prasideda dvejetainiais protokolo laukais. Šiems įvestims sukurta programinė įranga gali nukreipti ryšį atitinkamam apdorotojui.
Tai aiški įgyvendinimo savybė. Įprastas Squid HTTP klausytojas netampa mišrus todėl, kad jo prievadas pakeičiamas į 1080, o tik SOCKS klausytojas neišmoksta HTTP iš naršyklės nustatymo.
TLS prideda dar vieną ribą: šifruotas proxy ryšys prasideda TLS, o ne matomu HTTP metodu. Jo palaikymas tame pačiame galiniame taške reikalauja papildomo sąmoningo apdorojimo; atviro HTTP ir SOCKS atpažinimas neįrodo šios galimybės.
Naudokite galiniam taškui dokumentuotą kliento protokolą. Jei veikia abu, tai įrodymas apie to serverio mišrų klausytoją, o ne priežastis palikti protokolą nenurodytą kiekviename kliente.
Glider mišrus klausytojas pateikia konkretų pavyzdį: jis žvilgteli į vieną baitą jo nesuvartodamas, siunčia 0x05 savo SOCKS5 apdorotojui, o kitu atveju iškviečia savo HTTP analizatorių. Tas analizatorius vis tiek tikrina gaunamą užklausą; siuntimo pasirinkimas nepadaro savavališkos įvesties galiojančiu HTTP.
TCP klausytojo bendrinimas pats savaime nesuteikia SOCKS5 UDP asociacijos. Glider atskirai paleidžia savo UDP klausytoją. TCP protokolo pasirinkimas ir vėlesnis datagramų perdavimas yra atskiros galimybės.