HTTP-Paket Umbau
Wenn ich ein großes HTTP-Paket, das wurde aufgeteilt in eine Anzahl von TCP-Paketen, wie kann ich rekonstruieren, Sie wieder in einem einzigen HTTP-Paket? Im Grunde, wo in das Paket schaue ich sagen, wenn ein HTTP-Paket ist starten/beenden? Ich kann nicht scheinen, um zu sehen, irgendwelche Flaggen/Felder im TCP-header, bezeichnen den Beginn oder das Ende des HTTP-Pakets.
EDIT: Im follow-up für die Antworten. Wenn TCP steuert den Strom, wie funktioniert es wissen, wenn der stream beginnt und endet? Ist bestimmt durch den sockel öffnen und schließen? Einige Protokoll, auf einer bestimmten Ebene, muss in der Lage sein zu wissen, wenn der HTTP-stream/Paket begonnen hat und endete. Das ist das, was ich gerne wissen würde.
Die situation, die ich bin in ich bin mit einem packet-sniffer in C#, die liest in TCP-Pakete, und ich möchte in der Lage sein, zu rekonstruieren, die HTTP-Anfragen/Antworten/etc.. gehen Sie durch die Schnittstelle wie, wie wireshark und verschiedene andere Sniffer zu verwalten. Alternativ gibt es C# - Bibliotheken, die es Ihnen ermöglichen, die HTTP-streams auf der höheren Ebene, spart mir mit zu rekonstruieren, den HTTP-stream/Pakete selbst?
Dank.
Du musst angemeldet sein, um einen Kommentar abzugeben.
OK ich herausgefunden, wie dies zu tun (heftig, aber es bekommt den job getan).
Es ist einfach zu Streifen entfernt die Ethernet -, IP -, und TCP-Header verlassen Sie mit der " raw " - Daten-Nachricht. Wenn man in der Nachricht, es ist leicht zu erkennen, ob es der start in ein HTTP-Paket bei der Suche nach dem "HTTP/1.1 ..." am Anfang des Pakets. Dies zeigt an, das Paket ist der Beginn einer HTTP-stream/größere Päckchen/was auch immer. Sie können auch einige einfache Analyse zu Lesen, die "Content-Length" Feld, das die Gesamtlänge des gesamten HTTP-Paket.
Können Sie auch die Quelle/Ziel-IP & Port-Nummern in form einer eindeutigen ID für den link. So nach Erhalt der header-Paket, beachten Sie diese 4 Dinge (SRCIP, SRCPORT, DESTIP, DESTPORT). Nächsten Zeit erhalten Sie ein Paket mit diesem port/ip-combo, Sie können überprüfen, ob es den nächsten Teil des HTTP-Pakets. Sie können die Sequenznummern, um einige der Validierung und wahrscheinlich auch andere Sachen, aber im Allgemeinen sind die Pakete in Ordnung sind, so ist es OK. Ich glaube, ein neuer port geöffnet wird für jede HTTP-stream, so sollten Sie nicht erhalten zufällige Pakete, die nicht Teil des Baches, jedoch könnte dies ein Bereich anfällig für Fehler.
Sowieso, sobald Sie erhalten dieses Paket, noch einmal Streifen entfernt die Kopf-und die roh-Nachricht. Hinzufügen, dass es auf den bereits bekannten Teil der Nachricht. Wenn die Länge der gesamten Nachricht empfangen, so weit ist gleich der Länge Lesen von "Content-Length" - Feld, das Paket ist komplett!
Diese Methode ist offensichtlich anfällig für eine riesige Menge von Fehlern, aber ich bin nicht nach einem extrem robusten Weg, es zu tun. Ich dachte, ich würde die Antwort auf meine eigene Frage in den Fall kommt jemand über das gleiche Problem in der Zukunft! Viel Glück mit Ihrem schnüffeln 😀
Content-Lengthheader NICHT geben Sie die gesamte Länge des Pakets. Es gibt lediglich an der Größe des Inhalts, damit der Körper, die kommt nach dem Header. Der Kopf-und der Körper sind getrennt von\r\n\r\n.Sollten Sie nicht verwenden alle Informationen von der TCP-Ebene, um zu bestimmen, HTTP-request-Grenzen hinweg. TCP bietet einen verlässlichen byte-stream service; Sie können nicht sehen, keine Felder oder flags im TCP -, die helfen, mit dieser, weil Sie nicht da sind.
Zu bestimmen, wo die Grenzen sind, die in einer HTTP Anfrage, die Sie befolgen sollten, RFC 2616. Die Grenzen sind klar definiert, und Sie können bestimmen, Sie durch Analyse der Daten, die Sie erhalten.
In jedem TCP-Paket, die Anfang der payload-Daten werden unmittelbar nach dem TCP-header und das Ende der payload-Daten ist das Ende des IP-Pakets.
Ende der TCP-header ist leicht gefunden - die
Data Offsetist ein 4-bit-Feld im header, der enthält die Länge des headers in 32-bit-Worte (also multiplizieren Sie mit 4, um die Länge in 8-bit-bytes).Verwendung des TCP-Sequenz-Nummern aus der
SequenceFeld Zeichenfolge der Nutzdaten in der richtigen Reihenfolge zusammenzubringen. Beachten Sie, dass es möglicherweise Duplikate, im Falle der Weiterverbreitung.TCP ist ein stream Protokoll, nicht ein Paket-Protokoll. Der application layer (also Sie) erhält einen Strom von Daten, nicht ein Haufen von Paketen. Sie Lesen Sie einfach weiter Byte aus dem stream und Sie erhalten Ihre gesamte http-payload, während TCP führt die Fehlerprüfung, sendet, etc darunter.
Können Sie code verwenden, der open-source-Projekt mit dem Namen Xplico:
http://www.xplico.org
Mussten wir arbeiten an der Lösung des gleichen Problems. Wir waren in der Lage zu extrahieren, einige der zentralen Funktionen in einer open-source-Projekt.
http://code.google.com/p/pcap-reconst/
Bitte check it out und lassen Sie mich wissen, wenn es Ihnen zu helfen.
Content-Encodingheader, b) Umwandlung in eine gemeinsame text-Codierung auf der Grundlage dercharsetimContent-Typeheader und c) der Umgang mit chunked-encoding, wenn dieTransfer-Encoding- header gesetzt ist, umchunked?