Enthält HTTP als Protokoll einen Mechanismus zur Gewährleistung von Informationen?

513
Zach Smith

Ich habe diese Frage zu networkengineering.stackexchange gestellt, ohne zu wissen, dass Protokolle über TCP nicht in Frage kamen (dh, dass nur die OSI-Schichten 4 und darunter dort zum Thema gehören).

Die Frage ist diese:

Da HTTP über TCP implementiert wird und TCP verlustfrei ist, enthält HTTP jegliche Art von Informationen für die Paketerstellung?

Ich kann mir vorstellen, dass, sobald eine HTTP-Anforderung abgeschlossen ist, Sie einfach davon ausgehen können, dass die HTTP-Informationen vollständig sind (da die gesamte Sequenz von TCP-Paketen, die zum Transport von HTTP verwendet werden, garantiert in Ordnung ist und abgeschlossen ist).

Ist diese Annahme richtig?

Eine schnelle Google-Suche zeigt mir, dass sich OSI-Schicht 4 speziell mit End-to-End-Verbindungen und Zuverlässigkeit beschäftigt. Dies lässt mich verstehen, dass HTTP-Pakete KEINE Mittel zur Überprüfung der Integrität benötigen, wenn sie neu zusammengestellt werden. dh am Ende einer Netzwerkübertragung wird ein HTTP-Paket vollständig und korrekt zusammengestellt, wenn die TCP-Sitzung fehlerfrei abgeschlossen wird.

Ist das richtig?

0

1 Antwort auf die Frage

3
grawity

Ja, HTTP / 1.x enthält keinen Mechanismus zum erneuten Zusammenstellen von Paketen. Es erwartet, dass die Transportschicht (normalerweise TCP oder QUIC) diese bereitstellt, wie in RFC 7230, Abschnitt 6, zu sehen ist :

6. Verbindungsverwaltung

HTTP-Messaging ist unabhängig von den zugrunde liegenden Verbindungsprotokollen auf Transport- oder Sitzungsschicht. HTTP setzt nur einen zuverlässigen Transport voraus, bei dem Anfragen in der Reihenfolge geliefert werden und Antworten entsprechend in der Reihenfolge geliefert werden.

Das heißt, HTTP / 1.x enthält optionale Mechanismen zum Identifizieren, wann eine Antwort abgeschlossen ist . Dies ist erforderlich, da HTTP / 1.x die Wiederverwendung von Verbindungen unterstützt und dieselbe zugrunde liegende TCP-Verbindung möglicherweise für mehrere Anforderungs- / Antwortpaare verwendet wird. (Und natürlich hat TCP keine Ahnung von separaten Nachrichten.)

Patienten, die "Connection: close" verwenden (Standard in HTTP / 1.0), können einfach davon ausgehen, dass eine sauber geschlossene TCP-Verbindung ein Antwortende anzeigt. Clients, die "Connection: keep-alive" verwenden (Standardeinstellung in HTTP / 1.1), erwarten jedoch, dass die Antwort eine dieser Antworten hat

  1. einen "Content-Length:" -Header, wenn die Antwortlänge eindeutig und bekannt ist, oder
  2. ein Chunk von null Länge, wenn die Antwort eine unbestimmte Länge hat und "Transfer-Encoding: chunked" verwendet.

Dasselbe gilt immer noch für HTTP / 2 über TCP und sogar HTTP über QUIC.

Verwandte Probleme