Was ist der Unterschied zwischen einem TCP-Segment und einem TCP-Paket?


16

Ist ein TCP-Segment nicht Teil eines TCP-Pakets?

Folgendes habe ich gelesen:

Ein Segment ist ein Teil der Anwendungsdaten, die von TCP in eine transportierbare Größe zerlegt und mit einem TCP-Header umhüllt werden

Besteht der TCP-Header nicht selbst aus Segmenten?

Antworten:


21

Wir sagen, es TCP segmenthandelt sich um die Protokolldateneinheit, die aus einem TCP-Header und einem Anwendungsdatenstück (Paket) besteht, das aus der (oberen) Anwendungsschicht stammt. Transportschichtdaten werden im Allgemeinen als segmentund Netzwerkschichtdateneinheit als bezeichnet, datagramaber wenn wir UDP als Transportschichtprotokoll UDP segmentverwenden, sagen wir nicht , stattdessen sagen wir UDP datagram. Ich denke, das liegt daran, dass wir die UDP-Dateneinheit nicht segmentieren (die Segmentierung erfolgt in der Transportschicht, wenn wir TCP verwenden).

Datenkapselung und der TCP / IP-Protokollstapel


Diese Erklärung gilt für das von der IETF verwaltete TCP / IP-Modell .
Abmeldung am

8

Der ursprüngliche TCP-RFC ist ein bisschen unscharf, wie er den Begriff "Segment" verwendet.

In einigen Fällen bezieht sich der Begriff "Segment" nur auf den aktuellen Teil des Anwendungsdatenstroms, der übertragen wird und die TCP-Header ausschließt. Beispielsweise ist die TCP-Größe "Maximum Segment Size" (MSS) die maximale Größe des Anwendungsdatenblocks in dieser Nachricht, wobei die TCP-Header nicht berücksichtigt werden.

In anderen Fällen umfasst der Begriff "Segment" jedoch die gesamte TCP-Nachricht, einschließlich der TCP-Header. In der Tat werden in mindestens einem Fall TCP-Segmente ohne Anwendungsdaten (wie z. B. einfache Bestätigungen) erwähnt.

Eine einzelne ganze IP-Nachricht ist ein "Datagramm".

Der ursprüngliche IP-RFC bezieht sich auf Verbindungsschichtnachrichten als "Pakete". IP-Datagramme können in "Fragmente" zerlegt werden, um in die Paketgrößenbeschränkungen in Netzwerken mit kleinen Paketen zu passen.

Die IEEE 802.3 / Ethernet-Verbindungsschicht bezeichnet eine einzelne zusammenhängende physikalische Schichtübertragung als "Paket". Der MAC-Datenverbindungsteil des Pakets wird "Frame" genannt. Der Frame beginnt mit der Ziel-MAC-Adresse und endet mit der Frame-Check-Sequenz. Der Teil des Frames, der ein IP-Datagramm (oder ein Fragment davon) enthalten kann, wird als "MAC-Client-Datenfeld" bezeichnet.

Technisch gesehen gibt es also kein "TCP-Paket" oder "IP-Paket". Pakete sind Begriffe aus den Schichten unterhalb von IP. TCP hat "Segmente" und IP hat "Datagramme".


2

Der TCP-Header, der auch als "Segment-Header" bezeichnet wird, und die Nutzdaten oder Daten oder "Segmentdaten" bilden das TCP-Segment unterschiedlicher Größe.


2

Ein TCP-Segment wird als Datagramm bezeichnet. In der Regel ist ein Segment oder ein Datagramm ein Paket. Wenn das Datagramm oder Paket von der Netzwerkschicht verarbeitet wird, fügt es den IP-Header zu den Daten hinzu und wird zu einem IP-Paket.

Die Transportschicht segmentiert die Daten in kleinere Einheiten, die als Segmente, Datagramme oder sogenannte Pakete bezeichnet werden. Wir bezeichnen sie jedoch normalerweise als Segmente.


2

TCP-Segment ist nur ein Konzept, es ist anders mit IP-Defragmentierung

Wenn Sie Daten senden, die größer als IP MTU sind, werden sie in ein IP-Paket geschrieben, aber die IP-Schicht hat festgestellt, dass das IP-Paket zu lang ist, um gesendet zu werden Bezeichner aber mit unterschiedlichem Offset und unterschiedlicher Datenlänge. Die Empfangsseite ist für das Sammeln aller Teile verantwortlich. Nachdem sie alle Teile erhalten hat, setzt sie alle Teile zu einem vollständigen IP-Paket zusammen und schiebt es auf die obere Protokollschicht.

aber die tcp-schicht hat ein anderes verhalten. Wenn Sie Daten senden, die groß genug sind, werden die Daten von der TCP-Ebene nicht in ein TCP-Paket aufgeteilt. Sie werden dann in Teile aufgeteilt (IP hingegen). Sie rufen einen Teil der Rohdaten in ein TCP-Paket ab und drücken dann die Taste tcp-paket zu ip-schicht, die länge des tcp-pakets wird von mss bestimmt, später ruft es einen anderen teil der restdaten in ein anderes tcp-paket ab und wiederholt den prozess, bis alle daten übertragen sind.

wenn tcp nicht mss verwendet, ist es schrecklich. Angenommen, Sie senden Daten, die größer als mss sind. Sie werden nur in ein TCP-Paket aufgeteilt. Daten werden aufgrund von nicht verwendetem CSS nicht in kleine Teile aufgeteilt. TCP-Paket ist größer als IP-MTU. Die IP-Adresse teilt das TCP paket in stücke. Das TCP-Paket wird erneut übertragen, wenn eines der Teile verloren geht, und es wird Zeit und Bandbreite verschwendet

ps: tcp_mss = ip_mtu - tcp_header


1

Ein Header besteht nicht aus Segmenten. Ein Header hat immer die gleiche Größe und muss vollständig sein. Andernfalls könnte das Paket nicht decodiert werden.

Was Sie als "Segment" bezeichnen, ist das gesamte "Paket", das später mit anderen zum TCP-Stream kombiniert wird. Sehen:

Das Transmission Control Protocol akzeptiert Daten aus einem Datenstrom, "segmentiert" sie in Blöcke und fügt einen TCP-Header hinzu, der ein TCP-Segment erstellt.


1

TCP empfängt Daten von der Anwendungsschicht und "zerlegt" diese Daten in mehrere Datensegmente. Teile der ursprünglichen Daten mit einem hinzugefügten TCP-Header. Teil dieses Headers ist eine Sequenznummer, die vom TCP-Protokoll auf der Empfängerseite verwendet wird, um alle empfangenen Segmente (abzüglich der Header) in die richtige Reihenfolge zu bringen und die ursprünglichen Daten wieder zusammenzusetzen, die dann an die Anwendungsschicht übertragen werden .

Also, um deine Frage zu beantworten; Der Begriff "TCP-Paket" existiert nicht wirklich. Es wird ein "Segment" genannt, das aus einem Header und einem Datenabschnitt besteht. Der Header selbst besteht aus mehreren 'Feldern', die unter anderem eine Sequenznummer, eine Prüfsumme sowie Quell- und Zielportnummern enthalten.


1

Wenn Sie Daten über eine TCP-Verbindung senden, überschreitet die von Ihnen gesendete Datenmenge möglicherweise die maximale Größe der Bytes, die von der Verbindung in einem einzelnen Paket zugelassen werden. Dieser Betrag "Maximum Segment Size" (auch als MSS bezeichnet) wird zur Verbindungszeit zwischen den beiden TCP-Endpunkten (Client und Server) "ausgehandelt" (1). Das OSI Level 4-Protokoll TCP ist für das Scatter / Gather verantwortlich. Dies bedeutet, dass Ihr Datenstrom in kleinere Teile (Segmente genannt) aufgeteilt und separat über das Netzwerk gesendet wird. Auf der anderen Seite ist die TCP-Schicht dafür verantwortlich, das Paket in der richtigen Reihenfolge neu zu sammeln, um den Stream so zu reformieren, wie er gesendet wurde. Nichts kann Ihnen sagen, dass die Segmente in der gleichen Reihenfolge am Ziel ankommen wie am Abreisetag. Das ist auch der Grund, warum Pakete nummeriert werden. Mehr, Pakete werden einzeln (2) vom Empfänger bestätigt, aber manchmal können Pakete verloren gehen. Dann wird keine ACK vom Ziel des Pakets an den Sender zurückgesendet. Dann sollte der Sender es erneut senden (das ist auch die Rolle von TCP). Manchmal wird das Paket korrekt empfangen, aber die Bestätigung wird vom Sender nicht empfangen (verlorenes Paket erneut). In einem solchen Fall sendet der Sender es erneut, aber der Empfänger sieht, dass es es bereits empfangen hat (das ist ein Dup-Paket) und beseitigt es, sendet aber die Bestätigung erneut an den Absender.

Um den Durchsatz zu verbessern, kann der Sender auch mehrere Pakete hintereinander senden und muss nicht auf die vorherige Bestätigung warten, um das nächste Paket zu senden. Es ist auch Teil des TCP-Protokolls und wird als Schiebefenster bezeichnet. Die Anzahl der für eine Bestätigung ausstehenden gesendeten Pakete ist begrenzt.

(1) In der Tat gibt es überhaupt keine Verhandlung, jeder Endpunkt gibt die maximale Größe an, mit der er umgehen kann. Dieser Wert enthält weder die 20 Byte des IP-Headers noch die 20 Byte des TCP-Headers. (2) Mehrere Pakete können auch von einem einzigen ACK bestätigt werden.

Beachten Sie, dass Datagramme gekapselte Daten sind, die über ein IP-Netzwerk oder ein verbindungsloses Protokoll wie UDP gesendet werden. Pakete sind gekapselte Daten für ein verbindungsorientiertes Protokoll wie TCP. Segmente sind Teile eines Datenstroms, der über TCP gesendet wird. Sehen Sie sich W.Richard Stevens "TCP / IP Illustrated" an, um eine weitaus bessere Erklärung für all diese Dinge zu erhalten.


0

Ein TCP-Segment ist ein Paket. Ein Segment ist nur ein Teil eines TCP-Verbindungsstroms zwischen zwei Computern. Ein Datagramm ist ein "Paket" im Sinne von UDP.


0

Ein IP-Paket besteht aus einem IP-Header mit angehängten Daten. Die Daten sind ein TCP-Header und ein Segment von Anwendungsdaten, das als TCP-Segment bezeichnet wird. TCP-Segment ist das, was Sie normalerweise als TCP-Paket bezeichnen.


0

Der "Oberbegriff" für solche Dinge ist Protocol Data Unit (PDU).

LAYER # - OSI NAME     - COMMON PROTOCOL OR USE - PDU NAME
-------   ------------   ----------------------   --------------------------
Layer 1 - Physical     - Transceiver            - bits, or a physical signal
Layer 2 - Datalink     - Ethernet               - frame
Layer 3 - Network      - IP                     - packet
Layer 4 - Transport    - TCP                    - segment
Layer 5 - Session      - SIP                    - data, request, or response
Layer 6 - Presentation - Encryption/compression - data, request, or response
Layer 7 - Application  - HTTP                   - data, request, or response

Bei bestimmten Protokollen ab Schicht 4 verschwimmen die Dinge (zum Beispiel kenne ich bis heute nichts, was wirklich nur ein Sitzungsprotokoll ist, und es gibt wirklich kein gemeinsames "Präsentations" -Protokoll aber es ist definitiv fast eine separate Schicht in vielen Software- / Kommunikations-Stacks.

Wie bereits erwähnt, hat jede dieser PDUs einen Header, der sich von der Nutzlast oder den Daten unterscheidet. Der Header enthält Informationen zu den Daten und möglicherweise eine Prüfsumme zur Überprüfung am anderen Ende.


Wird die Arbeit TPDU nicht stattdessen auf den oberen Schichten verwendet? siehe books.google.de/books?id=daqV_KzkoSIC&pg=PA147
Janus Troelsen
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.