Wie ein einzelner Proxy-Port sowohl HTTP als auch SOCKS annehmen kann
Erklärt, wie ein bewusst gemischter Listener HTTP und SOCKS unterscheiden kann, während ein normaler Listener mit einem einzigen Protokoll dazu nicht in der Lage ist.
Ein gemischter Proxy-Listener kann HTTP und SOCKS auf einem einzigen TCP-Port annehmen, weil der Server die ersten Protokollbytes prüft. Die Portnummer leistet diese Erkennung nicht.
Eine HTTP-Proxy-Anfrage beginnt mit einer HTTP-Methode, etwa GET oder CONNECT. Eine SOCKS-Begrüßung beginnt mit binären Protokollfeldern. Software, die für diese Eingaben ausgelegt ist, kann die Verbindung an den passenden Handler weiterreichen.
Dies ist ein ausdrückliches Implementierungsmerkmal. Ein normaler Squid-HTTP-Listener wird nicht gemischt, weil sein Port auf 1080 geändert wird, und ein reiner SOCKS-Listener lernt HTTP nicht aus einer Browsereinstellung.
TLS zieht eine weitere Grenze: Eine verschlüsselte Proxy-Verbindung beginnt mit TLS, nicht mit einer sichtbaren HTTP-Methode. Sie am selben Endpunkt zu unterstützen, erfordert eine zusätzliche bewusste Behandlung; das Erkennen von Klartext-HTTP und SOCKS belegt diese Fähigkeit nicht.
Verwenden Sie das für den Endpunkt dokumentierte Client-Protokoll. Wenn beide funktionieren, ist das ein Beleg für den gemischten Listener dieses Servers, kein Grund, das Protokoll in jedem Client unbestimmt zu lassen.
Der gemischte Listener von Glider liefert ein konkretes Beispiel: Er schaut auf ein Byte, ohne es zu verbrauchen, leitet 0x05 an seinen SOCKS5-Handler weiter und ruft andernfalls seinen HTTP-Parser auf. Dieser Parser validiert die eingehende Anfrage weiterhin; die Auswahl der Weiterleitung macht aus beliebiger Eingabe kein gültiges HTTP.
Das Teilen des TCP-Listeners liefert nicht von sich aus eine SOCKS5-UDP-Assoziation. Glider startet seinen UDP-Listener getrennt. Die TCP-Protokollauswahl und die spätere Datagramm-Weiterleitung sind getrennte Fähigkeiten.