Acht Bytes lesen und dann den SOCKS4-Tunnel übergeben
Vermeiden Sie es, die Begrüßung des Ziels zu verschlucken oder auf nicht vorhandene Bytes zu warten, indem Sie die feste SOCKS4-Antwortgrenze parsen.
Die SOCKS4-Verbindungsanforderung ist erfolgreich, doch die Anwendung sieht nie die Begrüßung des Servers. Eine Stelle zum Nachsehen ist der erste Lesevorgang des Connectors. Ein Lesevorgang über sechzehn Bytes ist für eine acht Byte große SOCKS4-Antwort zu groß.
| Antwortfeld | Bytes |
|---|---|
| Feld für Antwortversion | 1 |
| Ergebniscode | 1 |
| Portfeld | 2 |
| Adressfeld | 4 |
Der Ergebniscode 0x5a zeigt an, dass die Anforderung genehmigt wurde. SOCKS4a ändert, wie die Anforderung einen Hostnamen trägt; es macht aus der Antwort keine sechzehn Bytes.
Nach der Antwort trägt derselbe TCP-Stream das Zielprotokoll. Ein Mailserver kann seine Begrüßung sofort senden. Ein Lesevorgang, der sechzehn verfügbare Bytes verbraucht, kann daher die vollständige Proxy-Antwort plus die ersten acht Bytes dieser Begrüßung mitnehmen. Folgt noch nichts, kann ein überdimensionierter blockierender Lesevorgang stattdessen eine unnötige Wartezeit hinzufügen.
Die exakte Länge ist Aufgabe des Parsers
Einmal acht Bytes anzufordern ist kein ausreichender Beleg dafür, dass acht Bytes angekommen sind. Stream-Lesevorgänge können weniger zurückgeben. Sammeln Sie genau die Länge der Antwort innerhalb einer Frist, brechen Sie bei einem geschlossenen oder fehlgeschlagenen Stream ab, prüfen Sie die Antwort und überlassen Sie die folgenden Bytes der Anwendung.
Nutzt der Connector einen größeren gepufferten Lesevorgang, bewahren Sie alles nach der Grenze auf und reichen es an den nächsten Verbraucher weiter. Den Überschuss zu verwerfen ist derselbe Datenverlust mit einer anderen Lesegröße.
SOCKS5 braucht seinen eigenen Parser. Die Länge seiner Antwortadresse kann je nach Adresstyp unterschiedlich sein. Jeden Proxy-Lesevorgang durch einen festen Lesevorgang von acht Bytes zu ersetzen, würde ein Protokoll reparieren und ein anderes brechen.