Ein Forward-Proxy bewahrt keine TCP-Segmentgrenzen
Trennen Sie TCP-Segmentierung, Socket-Lesevorgänge und HTTP-Framing, wenn Sie den Verkehr auf beiden Seiten eines Forward-Proxys untersuchen.
Angenommen, eine HTTP-Antwort erscheint nach dem Passieren von Squid in mehreren aufgezeichneten TCP-Segmenten. Das kann normales TCP-Verhalten sein und ist kein Beweis dafür, dass die Antwort falsch aufgeteilt wurde.
Ein Forward-Proxy hat normalerweise zwei Verbindungen:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originJede Verbindung hat ihren eigenen TCP-Zustand, eigene Sequenznummern und eigene Paketierung. Der Proxy kann Daten von einer Verbindung lesen und in die andere schreiben, ohne die ursprünglichen Segmentgrößen zu bewahren. Pufferung, Sendezeitpunkt, Überlastung und Größenbeschränkungen des Pfades können eine andere Gruppierung erzeugen.
Drei Grenzen, die getrennt bleiben sollten
| Grenze | Was sie bestimmt |
|---|---|
| TCP-Segment | Der Transport- und Netzwerkpfad |
| Ergebnis eines Socket-Lesevorgangs | Verfügbare Stream-Bytes und der Puffer des Aufrufers |
| HTTP-Nachricht oder -Frame | Die Framing-Regeln des HTTP-Protokolls |
Ein Lesevorgang kann einen Teil eines Headers, einen vollständigen Header samt Body-Bytes oder Daten enthalten, die mehr als eine Grenze auf Anwendungsebene überschreiten. TCP verbindet „Ende der HTTP-Antwort“ nicht mit dem Ende eines erfolgreichen Lesevorgangs.
Ein HTTP/1.1-Parser sammelt daher Header an und wendet die geltenden Regeln für das Body-Framing an, darunter Länge, Transferkodierung oder erlaubtes Schließen der Verbindung. Ein HTTP/2-Frame ist eine Protokollstruktur, die selbst TCP-Segmente überschreiten kann; er ist kein anderer Name für ein Netzwerkpaket.
Ein erfolgreicher CONNECT-Tunnel bewahrt den getunnelten Bytestrom, nutzt aber weiterhin zwei TCP-Strecken. Seine Segmentgrenzen können abweichen, selbst wenn der Proxy die Bytes im Tunnel nicht verändert hat.
Vergleichen Sie bei der Untersuchung von Beschädigungen die wieder zusammengesetzten Anwendungsdaten. Paketzahlen zu vergleichen oder auf beiden Seiten identische Paketlängen zu erwarten, verlangt von TCP eine Grenzgarantie, die es nicht bietet.