IP-Paket-Fragmentierung bei http-Paketen?
-
HTTP schrieb:
Soweit ich es noch in Erinnerung habe, werden die TCP-Pakete (inkl. IP) fragmentiert. TCP als Transportprotokoll für HTTP-Anfragen und Antworten gibt - glaube ich - nur eigene Pakete fragmentiert. Nicht aber die zu transportierenden Pakete. Korrigiert mich bitte wenn ich falsch liege.
HTTP basiert gar nicht auf Paketen, zumindest nennt man normalerweise nicht so. Man kann HTTP auch über andere Protokolle als TCP nutzen, HTTP kümmert sich darum nicht.
Solange du irgendein System hast, das Byte-Streams verlustfrei von A nach B und umgekehrt übertragen kann, kannst du darüber HTTP fahren. Ob der Bytestream intern in Pakete aufgesplittet wird wie bei TCP, das ist für HTTP völlig egal.
-
Hallo,
aber die gesamte HTTP-Anfrage bzw. Antwort kann man doch durchaus als Paket bezeichnen, oder?
Natürlich ist HTTP nicht an TCP gebunden, aber es ist die übliche Verfahrensweise im WWW.
LG
-
HändyÄndy schrieb:
IP Pakete stellen die kleinste logische Datenmenge dar.
wenn sich in letzter Zeit nichts geändert hat, sind das wohl immernoch Bits.
-
HTTP schrieb:
aber die gesamte HTTP-Anfrage bzw. Antwort kann man doch durchaus als Paket bezeichnen, oder?
Ja, können tut man viel. Ich kann zB aus dem Fenster springen. Das alleine macht es noch lange nicht zu einer guten Idee.
Eine HTTP Anfrage ist eine HTTP Anfrage (Request). Wir können es auch HTTP Anfrage Teilchen oder HTTP Anfrage Wellen nennen - Fakt ist aber, dass HTTP nur Request und Response kennt - keine Fragmentierung, keine Pakete und keinen Kaffee.
Worauf willst du eigentlich hinaus?
-
Hallo,
wenn ich das richtig in Erinnerung habe war folgendes meine Aussage:
HTTP-Request und HTTPResponse bestehen jeweils aus lediglich zwei Bestandteilen. Den Content (auch Body genannt) und den Header. Letzterer beinhaltet den Aufbau des Body (Kodierung, Typ).
Also stell ich mal frech eine Gegenfrage: Was willst du von mir?
LG
-
Eine HTTP-Anfrage und Antwort bestehen aus einer Statuszeile bei einer Antwort und einer Anfragezeile/Methode (POST, GET...) bei der Anfrage. Enthalten ist immer die HTTP-Version, um dadurch einschätzen zu können welche Funktionen unterstützt werden (sollten).
Die folgenden Key->Value Paare enthalten weitergehende Informationen. Dazu zählt der Typ des Contents und seine länge, falls vorhanden. Eine GET-Anfrage enzählt i.d.R. keinen Content, während eine POST-Anfrage einen Content enthält.
An dieser Stelle kann man sich ja schon die Frage stellen: Wozu dieser Aufwand? Warum gibt man die Länge des Contents an?
Die Antwort darauf ist die, dass es bei TCP/IP keine Pakete gibt. Es ist nicht garantiert, dass die 200 Bytes die ich versendet habe auch als 200 Bytes ankommen. Es könnten auch erst 100 Bytes und danach 2x 50 Bytes ankommen.
Das ist auch der Grund warum das HTTP-Protokoll alle Zeilen mit einem \r\n abschließt und das Ende des Headers mit einem \r\n\r\n signalisiert.
Nur so ist es möglich, dass man unabhängig von den tatsächlich empfangenden Bytes das Ende der Anfrage/Antwort erkennen kann. Im Zweifel (kein Content-Length angegeben) ließt man einfach solange weiter bis x Millisekunden nichts mehr ankommt und beendet die Verbindung.
Alles in allem gehört die Socketprogrammierung zu den Themen mit den meisten Missverständnissen. Das Thema ist auch nicht so einfach, wie es scheint, wenn man es tatsächlich "richtig" machen will.
-
------ schrieb:
Die Antwort darauf ist die, dass es bei TCP/IP keine Pakete gibt. Es ist nicht garantiert, dass die 200 Bytes die ich versendet habe auch als 200 Bytes ankommen. Es könnten auch erst 100 Bytes und danach 2x 50 Bytes ankommen.
TCP ist die Content-Length egal und HTTP bekommt nicht mit, in welchen Teilen der Datenstrom versendet wurde. Die Angaben und die Formatierung sind rein für die Desktop-Anwendung interessant, damit diese den Datenstrom leichter verarbeiten kann.
HTTP unterstützt zwar eine Art Fragmentierung (byte serving), die hat aber mit der Fragmentierung auf unteren Netzwerkebenen nichts zu tun
und doch, bei IP gibt es Pakete. Sogenannte IP-Pakete...
-
zwutz schrieb:
TCP ist die Content-Length egal und HTTP bekommt nicht mit, in welchen Teilen der Datenstrom versendet wurde. Die Angaben und die Formatierung sind rein für die Desktop-Anwendung interessant, damit diese den Datenstrom leichter verarbeiten kann.
Ich habe nichts anderes behauptet.
zwutz schrieb:
und doch, bei IP gibt es Pakete. Sogenannte IP-Pakete...
Ich sprach von TCP/IP und wenn ich mit send 100 Bytes versende, dann müssen auch nicht sofort 100 Bytes lesbar sein. Es könnten auch weniger sein.
-
------ schrieb:
Das ist auch der Grund warum das HTTP-Protokoll alle Zeilen mit einem \r\n abschließt und das Ende des Headers mit einem \r\n\r\n signalisiert.
Das macht hier alles absolut keinen Sinn...
Du solltest uns sagen worauf du hinaus willst. Das klingt hier alles komplett verwirrt und zusammenhangslos.
-
Guten morgen,
das macht sehr wohl Sinn. Wenn du nicht in der Lage dazu bist es zu verstehen, halt dich doch einfach raus. Oder du versuchst es zu verstehen und fängst damit an, die Nutzer auseinander zu halten. Hast du das geschafft wirst du erkennen, dass es weder verwirrt noch zusammenhangslos ist.
Schönen Sonntag