Come un solo proxy può accettare HTTP e SOCKS sulla stessa porta
Spiega come un listener volutamente misto possa distinguere HTTP da SOCKS, mentre un normale listener a singolo protocollo non può.
Un listener proxy misto può accettare HTTP e SOCKS su un'unica porta TCP perché il server ispeziona i byte iniziali del protocollo. Il numero di porta non esegue quel riconoscimento.
Una richiesta proxy HTTP inizia con un metodo HTTP, come GET o CONNECT. Un saluto SOCKS inizia con campi di protocollo binari. Un software progettato per questi input può inoltrare la connessione al gestore appropriato.
Questa è una caratteristica esplicita dell'implementazione. Un normale listener HTTP di Squid non diventa misto perché la sua porta viene cambiata in 1080, e un listener solo SOCKS non impara HTTP da un'impostazione del browser.
TLS aggiunge un altro confine: una connessione proxy cifrata inizia con TLS, non con un metodo HTTP visibile. Supportarlo sullo stesso endpoint richiede una gestione deliberata aggiuntiva; riconoscere HTTP in chiaro e SOCKS non dimostra questa capacità.
Usate il protocollo client documentato per l'endpoint. Se funzionano entrambi, è una prova sul listener misto di quel server, non un motivo per lasciare il protocollo non specificato in ogni client.
Il listener misto di Glider offre un esempio concreto: sbircia un byte senza consumarlo, invia 0x05 al suo gestore SOCKS5 e, altrimenti, richiama il suo parser HTTP. Quel parser convalida comunque la richiesta in arrivo; la scelta di invio non rende un input arbitrario HTTP valido.
Condividere il listener TCP non fornisce di per sé l'associazione UDP di SOCKS5. Glider avvia il suo listener UDP separatamente. La selezione del protocollo TCP e il successivo inoltro dei datagrammi sono capacità separate.