Transmission Control Protocol/Verbindungsverwaltung: Unterschied zwischen den Versionen
K Textersetzung - „Man-Pages“ durch „Man-Page“ |
|||
(38 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''topic''' - Kurzbeschreibung | |||
=== Beschreibung === | |||
=== Drei-Wege-Handschlag === | === Drei-Wege-Handschlag === | ||
* Typisch werden Antworten auf das erste SYN- bzw | * Typisch werden Antworten auf das erste SYN- bzw | ||
** Theoretisch wäre auch das Versenden zweier separater Pakete denkbar | * FIN-Paket zu einem einzelnen Paket zusammengefasst (SYN/ACK bzw | ||
* In diesem Fall müssen nur noch drei Pakete versendet werden, man spricht vom Drei-Wege-Handschlag | * FIN/ACK) | ||
* Das Zusammenfassen des FIN-Pakets und ACK-Pakets ist problematisch | ** Theoretisch wäre auch das Versenden zweier separater Pakete denkbar | ||
** Das Fin-Paket signalisiert „keine weiteren Daten“ | * In diesem Fall müssen nur noch drei Pakete versendet werden, man spricht vom Drei-Wege-Handschlag | ||
* Allerdings kann der Sender des FIN-Pakets weiterhin Daten empfangen wollen (halb geschlossenen Verbindung) | * Das Zusammenfassen des FIN-Pakets und ACK-Pakets ist problematisch | ||
** Das Fin-Paket signalisiert „keine weiteren Daten“ | |||
* Allerdings kann der Sender des FIN-Pakets weiterhin Daten empfangen wollen (halb geschlossenen Verbindung) | |||
; Überlegung | ; Überlegung | ||
# Den Beginn einer HTTP-Anfrage im SYN-Paket mitschicken, weitere Daten nach Verbindungsaufbau | # Den Beginn einer HTTP-Anfrage im SYN-Paket mitschicken, weitere Daten nach Verbindungsaufbau | ||
# Im letzten HTTP-Request-Paket die Verbindung mittels FIN schließen | # Im letzten HTTP-Request-Paket die Verbindung mittels FIN schließen | ||
* In der Praxis nicht | * In der Praxis nicht angewandt da: | ||
** Wenn der Browser die Verbindung auf diese Art schließt, würde möglicherweise der Server die Verbindung schließen, anstatt die Anfrage vollständig zu beantworten | ** Wenn der Browser die Verbindung auf diese Art schließt, würde möglicherweise der Server die Verbindung schließen, anstatt die Anfrage vollständig zu beantworten | ||
; Drei-Wege-Handschlag | ; Drei-Wege-Handschlag | ||
Sowohl beim Verbindungsaufbau als auch beim Verbindungsabbau werden die Antworten auf das erste SYN- bzw | Sowohl beim Verbindungsaufbau als auch beim Verbindungsabbau werden die Antworten auf das erste SYN- bzw | ||
Das Zusammenfassen des FIN-Pakets und des ACK-Pakets ist allerdings problematisch, da das Senden eines FIN-Pakets die Bedeutung hat „es folgen keine weiteren Daten mehr“ | * FIN-Paket typischerweise zu einem einzelnen Paket (SYN/ACK bzw | ||
* FIN/ACK) zusammengefasst – theoretisch wäre auch das Versenden zweier separater Pakete denkbar | |||
* Da in diesem Fall nur noch drei Pakete versendet werden müssen, spricht man auch häufig vom sogenannten [[Drei-Wege-Handschlag]] | |||
Das Zusammenfassen des FIN-Pakets und des ACK-Pakets ist allerdings problematisch, da das Senden eines FIN-Pakets die Bedeutung hat „es folgen keine weiteren Daten mehr“ | |||
* Allerdings kann der Sender des FIN-Pakets weiterhin Daten empfangen (wollen); man spricht von einer halb geschlossenen Verbindung (die Empfangsrichtung ist weiterhin offen, während die Senderichtung geschlossen wurde) | |||
* Es wäre z. B. denkbar, den Beginn einer HTTP-Anfrage (''HTTP-Request'') direkt im SYN-Paket mitzuschicken, weitere Daten, sobald die Verbindung aufgebaut wurde, und im letzten HTTP-Request-Paket die (Senderichtung der) Verbindung gleich mittels FIN zu schließen | |||
* In der Praxis wird dieses Verfahren allerdings nicht angewandt | |||
* Würde der Browser die Verbindung auf diese Art sofort schließen, würde möglicherweise auch der Server die Verbindung schließen anstatt die Anfrage vollständig zu beantworten | |||
==== Timeout bei Verbindungsaufbau ==== | ==== Timeout bei Verbindungsaufbau ==== | ||
Zeile 121: | Zeile 37: | ||
* Aktives Öffnen einer Verbindung (SYN) | * Aktives Öffnen einer Verbindung (SYN) | ||
* Passive Seite nimmt eine Verbindung auf einer bestimmten Port-Nummer entgegen | * Passive Seite nimmt eine Verbindung auf einer bestimmten Port-Nummer entgegen | ||
* Die initialen Sequenznummern werden auf jeder Seite zufällig gewählt und bestätigt | * Die initialen Sequenznummern werden auf jeder Seite zufällig gewählt und bestätigt | ||
* 3-fach-Handshake (nötig wegen des unzuverlässigen Dienstes von IP) | * 3-fach-Handshake (nötig wegen des unzuverlässigen Dienstes von IP) | ||
=== Verbindungsaufbau und -abbau === | |||
Ein Server, der seinen [[Netzwerkdienst|Dienst]] anbietet, erzeugt einen Endpunkt (Socket) mit der Portnummer und seiner IP-Adresse | |||
* Dies wird als ''passive open'' oder auch als ''listen'' bezeichnet | |||
Will ein Client eine Verbindung aufbauen, erzeugt er einen eigenen Socket aus seiner Rechneradresse und einer eigenen, noch freien Portnummer | |||
* Mit Hilfe eines ihm bekannten Ports und der Adresse des Servers kann dann eine Verbindung aufgebaut werden | |||
* Eine TCP-Verbindung ist durch folgende 4 Werte eindeutig identifiziert: | |||
* Quell-IP-Adresse | |||
* Quell-Port | |||
* Ziel-IP-Adresse | |||
* Ziel-Port | |||
Während der Datenübertragungsphase (''active open'') sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch | |||
* Insbesondere kann jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten | |||
=== Maximum segment lifetime (MSL) === | |||
* Die maximale Zeit, die ein Segment im Netzwerk verbringen kann, bevor es verworfen wird | |||
* Nach dem Senden des letzten ACKs wechselt der Client in einen zwei MSL andauernden Wartezustand (''wait state''), in dem alle verspäteten Segmente verworfen werden | |||
** Dadurch wird sichergestellt, dass keine verspäteten Segmente als Teil einer neuen Verbindung fehlinterpretiert werden können | |||
** Außerdem wird eine korrekte Verbindungsterminierung sichergestellt | |||
* Geht ACK ''y+1'' verloren, läuft beim Server der Timer ab, und das LAST_ACK-Segment wird erneut übertragen | |||
=== Puffer === | |||
* Beim Datenversand über TCP werden zwei Puffer verwendet | |||
# Senderseitig übermittelt die Applikation die Sendedaten an TCP und dieses puffert die Daten | |||
# Effizient werden mehrere kleine Übertragungen in Form einer einzigen großen gesendet | |||
# Empfängerseitig landen die empfangenen Daten im Puffer, dieser verfolgt ähnliche Ziele | |||
* Wenn von TCP mehrere einzelne Pakete empfangen wurden, ist es besser, diese zusammengefügt an die Applikation weiterzugeben | |||
Beim Versenden von Daten über das TCP werden zwei [[Puffer (Informatik)|Puffer]] verwendet | |||
* Senderseitig übermittelt die Applikation die zu sendenden Daten an das TCP und dieses puffert die Daten, um mehrere kleine Übertragungen effizienter in Form einer einzigen großen zu senden | |||
* Nachdem die Daten dann an den Empfänger übermittelt wurden, landen sie im empfängerseitigen Puffer | |||
* Dieser verfolgt ähnliche Ziele | |||
* Wenn vom TCP mehrere einzelne Pakete empfangen wurden, ist es besser, diese zusammengefügt an die Applikation weiterzugeben | |||
=== Datenübertragung === | === Datenübertragung === | ||
Zeile 129: | Zeile 80: | ||
==== TCP-/IP-Segment-Größe ==== | ==== TCP-/IP-Segment-Größe ==== | ||
* Typischerweise eine Größe von maximal 1500 Byte | * Typischerweise eine Größe von maximal 1500 Byte | ||
* Muss in die darunter liegende Übertragungsschicht passen, das Internetprotokoll | * Muss in die darunter liegende Übertragungsschicht passen, das Internetprotokoll (IP) | ||
* IP-Pakete sind zwar bis 65.535Bytes (64KiB) spezifiziert, werden aber meist über Ethernet übertragen | * IP-Pakete sind zwar bis 65.535Bytes (64KiB) spezifiziert, werden aber meist über Ethernet übertragen | ||
** Bei Ethernet ist die Größe der (Layer-3-)Nutzdaten auf 64 bis 1500Bytes festgelegt (bei Jumbo Frames höher) | ** Bei Ethernet ist die Größe der (Layer-3-)Nutzdaten auf 64 bis 1500Bytes festgelegt (bei Jumbo Frames höher) | ||
* TCP- und IP-Protokoll definieren jeweils einen Header von 20Bytes Größe | * TCP- und IP-Protokoll definieren jeweils einen Header von 20Bytes Größe | ||
* Für die (Applikations-)Nutzdaten bleiben in einem TCP/IP-Paket also 1460Bytes übrig | * Für die (Applikations-)Nutzdaten bleiben in einem TCP/IP-Paket also 1460Bytes übrig | ||
* Da die meisten Internet-Anschlüsse DSL verwenden, kommt zusätzlich das Point-to-Point Protocol (PPP) zwischen IP und Ethernet zur Anwendung (8Bytes) | * Da die meisten Internet-Anschlüsse DSL verwenden, kommt zusätzlich das Point-to-Point Protocol (PPP) zwischen IP und Ethernet zur Anwendung (8Bytes) | ||
Die Nutzdaten reduzieren sich also auf insgesamt 1500− 20− 20− 8 =1452Bytes | Die Nutzdaten reduzieren sich also auf insgesamt 1500− 20− 20− 8 =1452Bytes Maximum Segment Size (MSS) | ||
* Dies entspricht einer maximalen Nutzdatenrate von 96,8 % | * Dies entspricht einer maximalen Nutzdatenrate von 96,8 % | ||
==== Aufteilen der Anwendungsdaten auf TCP-/IP-Segmente ==== | ==== Aufteilen der Anwendungsdaten auf TCP-/IP-Segmente ==== | ||
# | # Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der Maximum Segment Size (MSS) | ||
# | # Als Beispiel legt ein Webserver einen 7Kilobyte großen Datenblock im Puffer ab | ||
#* Um mit einem 1460Byte großen Nutzdatenfeld 7Kilobyte Daten zu versenden: | #* Um mit einem 1460Byte großen Nutzdatenfeld 7Kilobyte Daten zu versenden: | ||
#*# Teilt die TCP-Software die Daten auf mehrere Pakete auf | #*# Teilt die TCP-Software die Daten auf mehrere Pakete auf | ||
#*# Fügt einen TCP-Header hinzu und versendet die TCP-Segmente | #*# Fügt einen TCP-Header hinzu und versendet die TCP-Segmente | ||
#* Dieser Vorgang wird Segmentierung genannt | #* Dieser Vorgang wird Segmentierung genannt | ||
# | # Der Datenblock im Puffer wird in fünf Segmente aufgeteilt, diese werden nacheinander abgeschickt | ||
## | ## Jedes Segment erhält durch die TCP-Software einen TCP-Header | ||
# | # Segmente kommen nicht zwingend in richtiger Reihenfolge an | ||
# | # Um die Segmente wieder zu sortieren, ist jedes Segment nummeriert | ||
#* Bei der Zuordnung der Segmente im Empfänger wird die Sequenznummer herangezogen | #* Bei der Zuordnung der Segmente im Empfänger wird die Sequenznummer herangezogen | ||
# Die TCP-Software des Empfängers bestätigt die einwandfrei angekommenen TCP-Segmente | # Die TCP-Software des Empfängers bestätigt die einwandfrei angekommenen TCP-Segmente | ||
#*Andernfalls werden die Pakete neu angefordert | #*Andernfalls werden die Pakete neu angefordert | ||
==== TCP-/IP-Datenübertragung ==== | ==== TCP-/IP-Datenübertragung ==== | ||
[[Datei:Tcp transfer.png|800px| Beispiel eines Datentransfers]] | [[Datei:Tcp transfer.png|800px| Beispiel eines Datentransfers]] | ||
# Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 und einer Nutzdatenlänge von 1460Bytes an den Empfänger | # Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 und einer Nutzdatenlänge von 1460Bytes an den Empfänger | ||
# Der Empfänger bestätigt es mit einem TCP-Header, ohne Daten, mit ACK=1461 und fordert das zweite TCP-Segment ab dem Byte Nummer 1461 an | # Der Empfänger bestätigt es mit einem TCP-Header, ohne Daten, mit ACK=1461 und fordert das zweite TCP-Segment ab dem Byte Nummer 1461 an | ||
# Sender schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger | # Sender schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger | ||
# Empfäner bestätigt es wieder mit einem ACK=2921 | # Empfäner bestätigt es wieder mit einem ACK=2921 | ||
* Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind | * Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind | ||
* Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen | * Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen | ||
* Fehlt zum Beispiel das 3 | * Fehlt zum Beispiel das 3 | ||
** Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal | * Segment, kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht | ||
** Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente, wenn beide die TCP-Option Selective ACK (SACK) unterstützen | ** Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal | ||
* Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer | ** Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente, wenn beide die TCP-Option Selective ACK (SACK) unterstützen | ||
* Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer | |||
==== Retransmission Timer ==== | ==== Retransmission Timer ==== | ||
* Zur Feststellung, wann ein Paket im Netzwerk verloren gegangen ist, wird vom Sender ein Timeout verwendet, bis zu dem das ACK der Gegenseite eingetroffen sein muss | * Zur Feststellung, wann ein Paket im Netzwerk verloren gegangen ist, wird vom Sender ein Timeout verwendet, bis zu dem das ACK der Gegenseite eingetroffen sein muss | ||
** Timeout zu niedrig, Pakete werden doppelt geschickt | ** Timeout zu niedrig, Pakete werden doppelt geschickt | ||
** Timeout zu hoch, velorene Pakete werden zu spät neu geschickt | ** Timeout zu hoch, velorene Pakete werden zu spät neu geschickt | ||
* Aufgrund unterschiedlicher Laufzeiten der IP-Pakete ist nur ein dynamischer Timer sinnvoll | * Aufgrund unterschiedlicher Laufzeiten der IP-Pakete ist nur ein dynamischer Timer sinnvoll | ||
==== Flusssteuerung und Staukontrolle ==== | ==== Flusssteuerung und Staukontrolle ==== | ||
In den folgenden zwei Abschnitten werden die TCP-Konzepte zur Flusssteuerung und Staukontrolle (oder Überlaststeuerung) erläutert | In den folgenden zwei Abschnitten werden die TCP-Konzepte zur Flusssteuerung und Staukontrolle (oder Überlaststeuerung) erläutert | ||
* Dabei werden das '' Sliding Window '' und das '' Congestion Window '' eingeführt | * Dabei werden das '' Sliding Window '' und das '' Congestion Window '' eingeführt | ||
* Der Sender wählt als tatsächliche Sendefenstergröße das Minimum aus beiden Fenstern | * Der Sender wählt als tatsächliche Sendefenstergröße das Minimum aus beiden Fenstern | ||
* Es werden ARQ-Protokolle (Automatic Repeat reQuest) für eine zuverlässige Datenübertragung eingesetzt | * Es werden ARQ-Protokolle (Automatic Repeat reQuest) für eine zuverlässige Datenübertragung eingesetzt | ||
==== Flusssteuerung ==== | ==== Flusssteuerung ==== | ||
[[Datei:Sliding window.svg| Sliding Window]] | [[Datei:Sliding window.svg| Sliding Window]] | ||
Da Daten aus dem Puffer gelesen werden, ändert sich der Füllstand des Puffers ständig | Da Daten aus dem Puffer gelesen werden, ändert sich der Füllstand des Puffers ständig | ||
* | * Deshalb ist es notwendig, den Datenfluss dem Füllstand entsprechend zu steuern | ||
** | ** Dies geschieht mit dem '' Sliding Window '' und dessen Größe | ||
* | * Der Puffer des Senders wird auf auf 10 Segmente erweitert | ||
;Im Sliding Window (a) werden gerade die Segmente 1–5 übertragen | ;Im Sliding Window (a) werden gerade die Segmente 1–5 übertragen | ||
# | # Obwohl der Puffer voll ist, werden die nächsten Daten (ab Byte 7301) mit ACK=7301 angefordert | ||
#* Das nächste Segment kann nicht mehr verarbeitet werden | #* Das nächste Segment kann nicht mehr verarbeitet werden | ||
#* Mit dem Window-Feld (=0) teilt er dem Sender mit, dass keine Daten mehr verschickt werden sollen | #* Mit dem Window-Feld (=0) teilt er dem Sender mit, dass keine Daten mehr verschickt werden sollen | ||
# | # Die Anwendung liest die Segmente 1–5 aus dem Puffer, es werden 7300Byte frei | ||
# | # Er kann die restlichen Segmente 6–10 mit einem TCP-Header (SEQ=1, ACK=7301, Window=7300), beim Sender anfordern | ||
# | # Der Sender weiß nun, dass er maximal fünf Segmente schicken kann, und verschiebt das Window um fünf Segmente nach rechts (Sliding Window (b)) | ||
# | # Die Segmente 6–10 werden nun alle zusammen als ''Burst'' verschickt | ||
# | # Beim Ankommen aller TCP-Segmente beim Empfänger, quittiert er sie (SEQ=1 und ACK=14601) und fordert die nächsten Daten an | ||
==== Fehlerbehandlung ==== | ==== Fehlerbehandlung ==== | ||
Zeile 216: | Zeile 168: | ||
==== Effiziente Datenübertragung ==== | ==== Effiziente Datenübertragung ==== | ||
* TCP verwendet das Sliding-Window-Protocol | * TCP verwendet das Sliding-Window-Protocol | ||
* um möglichst effizient Daten zu übertragen und Flusskontrolle zu ermöglichen | * um möglichst effizient Daten zu übertragen und Flusskontrolle zu ermöglichen | ||
* Bei einer Vollduplex-Verbindung müssen insgesamt 4 Fenster verwaltet werden | * Bei einer Vollduplex-Verbindung müssen insgesamt 4 Fenster verwaltet werden | ||
==== TCP PUSH Flag (PSH) ==== | ==== TCP PUSH Flag (PSH) ==== | ||
Zeile 236: | Zeile 188: | ||
* Jedes Bestätigungspaket enthält einen "window advertisement" Wert, in dem der Empfänger angibt, für wieviele weitere Pakete er noch freie Kapazität hat | * Jedes Bestätigungspaket enthält einen "window advertisement" Wert, in dem der Empfänger angibt, für wieviele weitere Pakete er noch freie Kapazität hat | ||
* das Fenster kann also größer oder kleiner werden | * das Fenster kann also größer oder kleiner werden | ||
=== Überlastungskontrolle === | === Überlastungskontrolle === | ||
[[Transmission Control Protocol/Überlastungskontrolle]] | |||
<noinclude> | |||
== Anhang == | |||
=== Siehe auch === | |||
== | {{Special:PrefixIndex/{{BASEPAGENAME}}}} | ||
==== Sicherheit ==== | |||
==== Dokumentation ==== | |||
===== RFC ===== | |||
=== | ===== Man-Page ===== | ||
===== Info-Pages ===== | |||
==== Links ==== | |||
===== Projekt ===== | |||
===== Weblinks ===== | |||
=== | |||
=== | |||
[[Kategorie: | [[Kategorie:TCP]] | ||
</noinclude> |
Aktuelle Version vom 6. November 2024, 12:47 Uhr
topic - Kurzbeschreibung
Beschreibung
Drei-Wege-Handschlag
- Typisch werden Antworten auf das erste SYN- bzw
- FIN-Paket zu einem einzelnen Paket zusammengefasst (SYN/ACK bzw
- FIN/ACK)
- Theoretisch wäre auch das Versenden zweier separater Pakete denkbar
- In diesem Fall müssen nur noch drei Pakete versendet werden, man spricht vom Drei-Wege-Handschlag
- Das Zusammenfassen des FIN-Pakets und ACK-Pakets ist problematisch
- Das Fin-Paket signalisiert „keine weiteren Daten“
- Allerdings kann der Sender des FIN-Pakets weiterhin Daten empfangen wollen (halb geschlossenen Verbindung)
- Überlegung
- Den Beginn einer HTTP-Anfrage im SYN-Paket mitschicken, weitere Daten nach Verbindungsaufbau
- Im letzten HTTP-Request-Paket die Verbindung mittels FIN schließen
- In der Praxis nicht angewandt da:
- Wenn der Browser die Verbindung auf diese Art schließt, würde möglicherweise der Server die Verbindung schließen, anstatt die Anfrage vollständig zu beantworten
- Drei-Wege-Handschlag
Sowohl beim Verbindungsaufbau als auch beim Verbindungsabbau werden die Antworten auf das erste SYN- bzw
- FIN-Paket typischerweise zu einem einzelnen Paket (SYN/ACK bzw
- FIN/ACK) zusammengefasst – theoretisch wäre auch das Versenden zweier separater Pakete denkbar
- Da in diesem Fall nur noch drei Pakete versendet werden müssen, spricht man auch häufig vom sogenannten Drei-Wege-Handschlag
Das Zusammenfassen des FIN-Pakets und des ACK-Pakets ist allerdings problematisch, da das Senden eines FIN-Pakets die Bedeutung hat „es folgen keine weiteren Daten mehr“
- Allerdings kann der Sender des FIN-Pakets weiterhin Daten empfangen (wollen); man spricht von einer halb geschlossenen Verbindung (die Empfangsrichtung ist weiterhin offen, während die Senderichtung geschlossen wurde)
- Es wäre z. B. denkbar, den Beginn einer HTTP-Anfrage (HTTP-Request) direkt im SYN-Paket mitzuschicken, weitere Daten, sobald die Verbindung aufgebaut wurde, und im letzten HTTP-Request-Paket die (Senderichtung der) Verbindung gleich mittels FIN zu schließen
- In der Praxis wird dieses Verfahren allerdings nicht angewandt
- Würde der Browser die Verbindung auf diese Art sofort schließen, würde möglicherweise auch der Server die Verbindung schließen anstatt die Anfrage vollständig zu beantworten
Timeout bei Verbindungsaufbau
- Was passiert, wenn der Kommunikationspartner nicht antwortet?
- die Übertragung des Paketes wird wiederholt, TCP betrachtet dies als gewöhnlichen Paketverlust
- nach einer festen Zeit (timeout) wird der Verbindungsversuch abgebrochen und die Anwendung informiert
Verbindungsaufbau
- Aktives Öffnen einer Verbindung (SYN)
- Passive Seite nimmt eine Verbindung auf einer bestimmten Port-Nummer entgegen
- Die initialen Sequenznummern werden auf jeder Seite zufällig gewählt und bestätigt
- 3-fach-Handshake (nötig wegen des unzuverlässigen Dienstes von IP)
Verbindungsaufbau und -abbau
Ein Server, der seinen Dienst anbietet, erzeugt einen Endpunkt (Socket) mit der Portnummer und seiner IP-Adresse
- Dies wird als passive open oder auch als listen bezeichnet
Will ein Client eine Verbindung aufbauen, erzeugt er einen eigenen Socket aus seiner Rechneradresse und einer eigenen, noch freien Portnummer
- Mit Hilfe eines ihm bekannten Ports und der Adresse des Servers kann dann eine Verbindung aufgebaut werden
- Eine TCP-Verbindung ist durch folgende 4 Werte eindeutig identifiziert:
- Quell-IP-Adresse
- Quell-Port
- Ziel-IP-Adresse
- Ziel-Port
Während der Datenübertragungsphase (active open) sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch
- Insbesondere kann jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten
Maximum segment lifetime (MSL)
- Die maximale Zeit, die ein Segment im Netzwerk verbringen kann, bevor es verworfen wird
- Nach dem Senden des letzten ACKs wechselt der Client in einen zwei MSL andauernden Wartezustand (wait state), in dem alle verspäteten Segmente verworfen werden
- Dadurch wird sichergestellt, dass keine verspäteten Segmente als Teil einer neuen Verbindung fehlinterpretiert werden können
- Außerdem wird eine korrekte Verbindungsterminierung sichergestellt
- Geht ACK y+1 verloren, läuft beim Server der Timer ab, und das LAST_ACK-Segment wird erneut übertragen
Puffer
- Beim Datenversand über TCP werden zwei Puffer verwendet
- Senderseitig übermittelt die Applikation die Sendedaten an TCP und dieses puffert die Daten
- Effizient werden mehrere kleine Übertragungen in Form einer einzigen großen gesendet
- Empfängerseitig landen die empfangenen Daten im Puffer, dieser verfolgt ähnliche Ziele
- Wenn von TCP mehrere einzelne Pakete empfangen wurden, ist es besser, diese zusammengefügt an die Applikation weiterzugeben
Beim Versenden von Daten über das TCP werden zwei Puffer verwendet
- Senderseitig übermittelt die Applikation die zu sendenden Daten an das TCP und dieses puffert die Daten, um mehrere kleine Übertragungen effizienter in Form einer einzigen großen zu senden
- Nachdem die Daten dann an den Empfänger übermittelt wurden, landen sie im empfängerseitigen Puffer
- Dieser verfolgt ähnliche Ziele
- Wenn vom TCP mehrere einzelne Pakete empfangen wurden, ist es besser, diese zusammengefügt an die Applikation weiterzugeben
Datenübertragung
TCP-/IP-Segment-Größe
- Typischerweise eine Größe von maximal 1500 Byte
- Muss in die darunter liegende Übertragungsschicht passen, das Internetprotokoll (IP)
- IP-Pakete sind zwar bis 65.535Bytes (64KiB) spezifiziert, werden aber meist über Ethernet übertragen
- Bei Ethernet ist die Größe der (Layer-3-)Nutzdaten auf 64 bis 1500Bytes festgelegt (bei Jumbo Frames höher)
- TCP- und IP-Protokoll definieren jeweils einen Header von 20Bytes Größe
- Für die (Applikations-)Nutzdaten bleiben in einem TCP/IP-Paket also 1460Bytes übrig
- Da die meisten Internet-Anschlüsse DSL verwenden, kommt zusätzlich das Point-to-Point Protocol (PPP) zwischen IP und Ethernet zur Anwendung (8Bytes)
Die Nutzdaten reduzieren sich also auf insgesamt 1500− 20− 20− 8 =1452Bytes Maximum Segment Size (MSS)
- Dies entspricht einer maximalen Nutzdatenrate von 96,8 %
Aufteilen der Anwendungsdaten auf TCP-/IP-Segmente
- Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der Maximum Segment Size (MSS)
- Als Beispiel legt ein Webserver einen 7Kilobyte großen Datenblock im Puffer ab
- Um mit einem 1460Byte großen Nutzdatenfeld 7Kilobyte Daten zu versenden:
- Teilt die TCP-Software die Daten auf mehrere Pakete auf
- Fügt einen TCP-Header hinzu und versendet die TCP-Segmente
- Dieser Vorgang wird Segmentierung genannt
- Um mit einem 1460Byte großen Nutzdatenfeld 7Kilobyte Daten zu versenden:
- Der Datenblock im Puffer wird in fünf Segmente aufgeteilt, diese werden nacheinander abgeschickt
- Jedes Segment erhält durch die TCP-Software einen TCP-Header
- Segmente kommen nicht zwingend in richtiger Reihenfolge an
- Um die Segmente wieder zu sortieren, ist jedes Segment nummeriert
- Bei der Zuordnung der Segmente im Empfänger wird die Sequenznummer herangezogen
- Die TCP-Software des Empfängers bestätigt die einwandfrei angekommenen TCP-Segmente
- Andernfalls werden die Pakete neu angefordert
TCP-/IP-Datenübertragung
- Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 und einer Nutzdatenlänge von 1460Bytes an den Empfänger
- Der Empfänger bestätigt es mit einem TCP-Header, ohne Daten, mit ACK=1461 und fordert das zweite TCP-Segment ab dem Byte Nummer 1461 an
- Sender schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger
- Empfäner bestätigt es wieder mit einem ACK=2921
- Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind
- Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen
- Fehlt zum Beispiel das 3
- Segment, kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht
- Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal
- Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente, wenn beide die TCP-Option Selective ACK (SACK) unterstützen
- Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer
Retransmission Timer
- Zur Feststellung, wann ein Paket im Netzwerk verloren gegangen ist, wird vom Sender ein Timeout verwendet, bis zu dem das ACK der Gegenseite eingetroffen sein muss
- Timeout zu niedrig, Pakete werden doppelt geschickt
- Timeout zu hoch, velorene Pakete werden zu spät neu geschickt
- Aufgrund unterschiedlicher Laufzeiten der IP-Pakete ist nur ein dynamischer Timer sinnvoll
Flusssteuerung und Staukontrolle
In den folgenden zwei Abschnitten werden die TCP-Konzepte zur Flusssteuerung und Staukontrolle (oder Überlaststeuerung) erläutert
- Dabei werden das Sliding Window und das Congestion Window eingeführt
- Der Sender wählt als tatsächliche Sendefenstergröße das Minimum aus beiden Fenstern
- Es werden ARQ-Protokolle (Automatic Repeat reQuest) für eine zuverlässige Datenübertragung eingesetzt
Flusssteuerung
Da Daten aus dem Puffer gelesen werden, ändert sich der Füllstand des Puffers ständig
- Deshalb ist es notwendig, den Datenfluss dem Füllstand entsprechend zu steuern
- Dies geschieht mit dem Sliding Window und dessen Größe
- Der Puffer des Senders wird auf auf 10 Segmente erweitert
- Im Sliding Window (a) werden gerade die Segmente 1–5 übertragen
- Obwohl der Puffer voll ist, werden die nächsten Daten (ab Byte 7301) mit ACK=7301 angefordert
- Das nächste Segment kann nicht mehr verarbeitet werden
- Mit dem Window-Feld (=0) teilt er dem Sender mit, dass keine Daten mehr verschickt werden sollen
- Die Anwendung liest die Segmente 1–5 aus dem Puffer, es werden 7300Byte frei
- Er kann die restlichen Segmente 6–10 mit einem TCP-Header (SEQ=1, ACK=7301, Window=7300), beim Sender anfordern
- Der Sender weiß nun, dass er maximal fünf Segmente schicken kann, und verschiebt das Window um fünf Segmente nach rechts (Sliding Window (b))
- Die Segmente 6–10 werden nun alle zusammen als Burst verschickt
- Beim Ankommen aller TCP-Segmente beim Empfänger, quittiert er sie (SEQ=1 und ACK=14601) und fordert die nächsten Daten an
Fehlerbehandlung
- Checksummen-Fehler
- Erkennen von Übertragungsfehlern
- Defekte Pakete werden weggeworfen
- Nach Timeout wird das entsprechende Paket neu gesendet
- Abgebrochene Verbindung
- plötzlicher Abbruch (Absturz, Kabel entfernt, ...)
- Schließen der Verbindung nach Timeout
Datenaustausch
- Senden eines Segments und Start eines Timer
- Bestätigung mit nächster erwarteter Sequenznummer
- Wird Timer überschritten, erneutes Senden
Effiziente Datenübertragung
- TCP verwendet das Sliding-Window-Protocol
- um möglichst effizient Daten zu übertragen und Flusskontrolle zu ermöglichen
- Bei einer Vollduplex-Verbindung müssen insgesamt 4 Fenster verwaltet werden
TCP PUSH Flag (PSH)
- die ursprüngliche Aufgabe des PSH Flags war es, dass der Sender eines Segmentes den Empfänger auffordert, dieses (und alle vorangegangenen) sofort bei der jeweiligen Anwendung auszuliefern, ohne dass es lange gepuffert wird
- dies sollte z. B. für interaktive Anwendungen verwendet werden
- wird inzwischen jedoch standardmäßig (fast) immer gesetzt, da keine Rechenzeit beim Auslesen der Puffer gespart werden muss
Sliding Window (wanderndes Fenster)
Variable Fenstergröße
- Größe des Fensters kann variieren
- Reagieren auf Netzwerk-Engpässe
- Flusskontrolle (z. B. zwischen verschieden starken Partnern)
- Verkehrssteuerung
- Jacobsen's "slow start" Algorithmus variiert die Grösse des Sendefensters, um die Senderate an die Netzbelastung anzupassen
- Siehe Überlastungskontrolle
- Flusssteuerung
- Jedes Bestätigungspaket enthält einen "window advertisement" Wert, in dem der Empfänger angibt, für wieviele weitere Pakete er noch freie Kapazität hat
- das Fenster kann also größer oder kleiner werden
Überlastungskontrolle
Transmission Control Protocol/Überlastungskontrolle