Wenn ich ein großes HTTP-Paket habe, das in eine Anzahl von TCP-Paketen aufgeteilt wurde, wie kann ich sie in ein einzelnes HTTP-Paket zurückverwandeln? Grundsätzlich, wo im Paket sehe ich aus, wenn ein HTTP-Paket beginnt / endet? Ich sehe anscheinend keine Flags / Felder im TCP-Header, die den Anfang oder das Ende des HTTP-Pakets anzeigen.
BEARBEITEN: Im Anschluss an die Antworten. Wenn TCP den Stream verwaltet, wie weiß er, wann der Stream beginnt und endet? Wird das durch das Öffnen und Schließen der Steckdose bestimmt? Einige Protokolle müssen auf einer bestimmten Ebene wissen können, wann der HTTP-Datenstrom / das HTTP-Paket gestartet und beendet wurde. Das würde ich gerne wissen.
Die Situation, in der ich mich befinde, ist, dass ich einen Paket-Sniffer in C # verwende, der TCP-Pakete einliest, und ich würde gerne in der Lage sein, die HTTP-Anfragen / Antworten / etc. Durch die Schnittstelle gehen, wie wireshark und verschiedene andere Sniffer es schaffen. Gibt es alternativ C # -Bibliotheken, mit denen Sie die HTTP-Streams auf der höheren Ebene anzapfen können, wodurch ich den HTTP-Stream / die Pakete selbst rekonstruieren muss?
Danke.
OK Ich habe herausgefunden, wie das geht (zweifelhaft, aber es macht den Job fertig).
Es ist einfach, die Ethernet-, IP- und TCP-Header zu entfernen, so dass Sie die Nachricht "rohe" Daten erhalten. Wenn Sie innerhalb der Nachricht nachsehen, ist es leicht zu erkennen, ob es der Start eines HTTP-Pakets ist, indem Sie nach dem "HTTP / 1.1 ..." am Anfang des Pakets suchen. Dies zeigt an, dass das Paket der Start eines HTTP-Streams / größeren Pakets / was auch immer ist. Sie können auch ein einfaches Parsing durchführen, um das Feld "Content-Length" zu lesen, das die Gesamtlänge des gesamten HTTP-Pakets ist.
Sie können auch die Quelle / Ziel-IP & amp; Port-Nummern, um eine eindeutige ID für den Link zu bilden. Nachdem Sie das Header-Paket empfangen haben, notieren Sie diese 4 Dinge (SRCIP, SRCPORT, DESTP, DESTPORT). Wenn Sie das nächste Mal ein Paket erhalten, das dieser Port / IP-Kombination entspricht, können Sie prüfen, ob es sich um den nächsten Teil des HTTP-Pakets handelt. Sie können die Sequenznummern verwenden, um etwas zu validieren und wahrscheinlich andere Dinge, aber im Allgemeinen sind die Pakete in Ordnung, also ist es in Ordnung. Ich denke, dass ein neuer Port für jeden HTTP-Stream geöffnet wird, so dass Sie keine zufälligen Pakete erhalten sollten, die nicht Teil des Streams sind, aber dies könnte ein fehleranfälliger Bereich sein.
Sobald Sie dieses Paket erhalten haben, entfernen Sie die Header erneut und erhalten Sie die rohe Nachricht. Fügen Sie es dem bereits bekannten Teil der Nachricht hinzu. Wenn die Länge der gesamten empfangenen Nachricht gleich der Länge ist, die aus dem Feld "Content-Length" gelesen wurde, ist das Paket vollständig!
Diese Methode ist offensichtlich anfällig für eine große Anzahl von Fehlern, aber ich bin nicht auf eine extrem robuste Art und Weise, dies zu tun. Ich dachte, ich würde meine eigene Frage beantworten, falls jemand anderes in Zukunft auf dasselbe Problem stoßen sollte! Viel Glück beim Schnüffeln: D
Sie sollten keine Informationen von der TCP-Ebene verwenden, um HTTP-Anforderungsgrenzen zu bestimmen. TCP bietet einen zuverlässigen Byte-Stream-Dienst; Sie können keine Felder oder Markierungen in TCP sehen, die dabei helfen, weil sie nicht da sind.
Um festzustellen, wo sich die Grenzen in einer HTTP-Anfrage befinden, sollten Sie RFC 2616 folgen. Die Grenzen sind gut definiert, und Sie können sie bestimmen, indem Sie die empfangenen Daten analysieren.
In jedem TCP-Paket befindet sich der Start der Nutzdaten unmittelbar hinter dem TCP-Header, und das Ende der Nutzdaten ist das Ende des IP-Pakets.
Das Ende des TCP-Headers ist leicht zu finden - das Data Offset ist ein 4-Bit-Feld im Header, das die Länge des Headers in 32-Bit-Wörtern enthält (multiplizieren Sie es mit 4, um die Länge in 8 zu erhalten) -Bit Bytes).
Verwenden Sie die TCP-Sequenznummern aus dem Feld Sequence , um die Nutzdaten in der richtigen Reihenfolge zusammenzufassen. Beachten Sie, dass es im Fall von Wiederholungen zu Duplikaten kommen kann.
TCP ist ein stream Protokoll, kein Paketprotokoll. Die Anwendungsschicht (d. H. Sie) erhält einen Datenstrom, nicht einen Bündel von Paketen. Sie lesen gerade Bytes aus dem Stream ein und Sie erhalten Ihre gesamte HTTP-Payload, während TCP die Fehlerprüfung, die erneute Versendung usw. darunter durchführt.