Transmission Control Protocol: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(215 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''TCP''' ('''Transmission Control Protocol''') ist ein Netzwerkprotokoll, das definiert, auf welche Art und Weise Daten zwischen Netzwerkkomponenten ausgetauscht werden sollen.
'''Transmission Control Protocol''' (TCP)


= Beschreibung =
== Beschreibung ==
''' Was ist TCP '''
; Transportprotokoll
* Ist ein zuverlässiges, verbindungsorientiertes, paketvermitteltes (nicht ''paketvermittelnd'') Transportprotokoll.
{| class="wikitable options"
* TCP ermöglicht die Übertragung eines Datenstroms.
|-
* Im Unterschied zum verbindungslosen [[Netzwerke:UDP | User Datagram Protokoll (UDP)]] stellt TCP eine Verbindung zwischen zwei Endpunkten (Sockets) einer Netzverbindung her.
! Funktionen !! Beschreibung
** Auf dieser Verbindung können in beide Richtungen Daten übertragen werden.
 
''' Vorteile '''
* Netzwerküberlastungskontrolle.
* Zuverlässige Datenübertragung:
** erkennt verlorene Segmente, doppelte Segmente und fehlerhafte Segmente.
 
''' Allgemeines '''
TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex.
* Kann auch als zwei Halbduplexverbindungen betrachtet werden (Informationsfluss in beide Richtungen (allerdings nicht gleichzeitig)).
* Die Daten in Gegenrichtung können zusätzliche Steuerungsinformationen enthalten.
* Anwendungen, die TCP häufig nutzen, sind zum Beispiel Webbrowser und Webserver.
 
''' TCP-Software '''
* Übernimmt Verbindungsverwaltung sowie die Datenübertragung.
* Netz-Protokollstack des Betriebssystems.
* Anwendungsprogramme nutzen Sockets. 
 
''' Entwicklung '''
* Entwickelt von Robert E. Kahn und Vinton G. Cerf als Forschungsarbeit.
* Beginn 1973, erste Standardisierung 1981 als [https://tools.ietf.org/html/rfc793 ''RFC 793''].
* Danach gab es viele Erweiterungen, diese werden bis heute in RFCs spezifiziert.
 
= Header =
* Das TCP-Segment besteht immer aus zwei Teilen: dem  Header  und der Nutzlast.
* Die Nutzlast enthält die zu übertragenden Daten.
** Die wiederum Protokollinformationen der Anwendungsschicht, wie HTTP oder FTP, entsprechen können.
* Der Header enthält für die Steuerung der Kommunikation erforderliche Daten.
* Da das Options-Feld in der Regel nicht genutzt wird, hat ein typischer Header eine Größe von 20 Byte.
 
=== Felder des TCP-Header ===
[[Datei:TCP Header.svg|mini|550px| Aufbau des TCP-Headers]]
 
{| class="wikitable"
! Feld !! Funktion !! Größe
|-----
| Source Port (Quellport)
| Gibt die Portnummer auf der Senderseite an
| 2 Byte
|-----
| Destinations Port (Zielport)
| Gibt die Portnummer auf der Empfängerseite an.
| 2 Byte
|-----
| Sequence Number
| Sequenznummer des ersten Daten-Oktett dieses TCP-Segments, dient zur Sortierung  Oder die Initialisierungs-Sequenznummer falls das SYN-Flag gesetzt ist
| 4 Byte
|-----
| Acknowledgement Number
| Gibt die '' Sequenznummer '' an, die der Absender dieses TCP-Segments als Nächstes erwartet  Sie ist nur gültig, falls das ACK-Flag  gesetzt ist.
| 4 Byte
|-----
| Data Offset
| Gibt die ''Länge des TCP-Headers'' in 32-Bit-Blöcken an (ohne Nutzdaten). 
* Hiermit wird die Startadresse der Nutzdaten angezeigt.
| 4 Bit
|-----
| Reserved
| Ist für zukünftige Verwendungen reserviert.
* Alle Bits müssen null sein.
| 4 Bit
|-----
| Control-Flags
| Zweiwertige Variablen mit den Zuständen ''gesetzt'' und ''nicht gesetzt''.
* Kennzeichnung für die wichtigen Zustände der Kommunikation und Weiterverarbeitung der Daten.
| 8 Bit
|-----
| (Receive) Window
| Ist die Anzahl der Bytes die der Sender dieses TCP-Segments bereit ist zu empfangen.
* Beginnend bei dem durch das ''Acknowledgementfeld'' indizierten Daten-Oktett.
| 2 Byte
|-----
| Checksum
| Dient zur Erkennung von Übertragungsfehlern.
* Wird über den TCP-Header, die Daten und einen Pseudo-Header berechnet.
* Der Header besteht aus Ziel-IP, Quell-IP, TCP-Protokollkennung (0x0006) und der Länge des TCP-Headers inkl. Nutzdaten (in Bytes).
| 2 Byte
|-----
| Urgent Pointer
| Nur gültig, wenn das URG-Flag gesetzt ist.
* Die Urgent-Daten beginnen sofort nach dem Header
* Zusammen mit der Sequenz-Nummer gibt dieser Wert die Position des ersten Bytes ''nach'' den Urgent-Daten an.
| 2 Byte
|-----
| Options
| Unterschiedlich groß und enthält Zusatzinformationen.
* Müssen ein Vielfaches von 32 Bit lang sein, ansonsten muss mit Nullbits aufefüllt werden (''Padding'').
* Ermöglicht Verbindungsdaten auszuhandeln, die nicht im TCP-Header enthalten sind, wie z.B. die Maximalgröße des Nutzdatenfeldes.
| 0–40 Byte
|}
 
=== TCP-Flags ===
{| class="wikitable"
! Feld !! Funktion !! Größe
|-----
| ECE-Flag (ECN-Echo)
|  Teilt dem Sender mit, dass das Netzwerk überlastet ist und die Senderate reduziert werden muss.
*  Wird für Explicit Congestion Notification (ECN) benötigt
| 1 Bit
|-----
| CRW-Flag (''Congestion Window Reduced'')
|  Teilt dem Empfänger mit das die Senderate reduziert wurde.
*  Wird für Explicit Congestion Notification (ECN) benötigt
| 1 Bit
|-----
| URG-Flag (''Urgent'')
|
* Die Daten nach dem Header werden sofort von der Anwendung bearbeitet.
* Anwendung unterbricht die Datenverarbeitung des aktuellen TCP-Segments und liest alle Bytes nach dem Header bis zu dem Byte, auf das das ''Urgent-Pointer ''-Feld zeigt, aus.
* Kann verwendet werden, um eine Anwendung auf dem Empfänger abzubrechen.
* In der Regel wird dieses Flag nicht ausgewertet.
| 1 Bit
|-----
| ACK-Flag (''Acknowledgment'')
|  Hat in Verbindung mit der ''Acknowledgment''-Nummer die Aufgabe, den Empfang von TCP-Segmenten bestätigen.
*  Die ''Acknowledgment''-Nummer ist nur gültig, wenn das Flag gesetzt ist.
| 1 Bit
|-----
| PSH-Flag (''Push'')
|  Sowohl der ausgehende, als auch der eingehende Puffer wird übergangen.
*  Hilft den Datenstrom von TCP effizienter zu verarbeiten, indem die empfangende Applikation gezielter aufgeweckt werden kann.
*  RFC 1122 & RFC 793
| 1 Bit
|-----
| RST-Flag (''Reset'')
|  Wird verwendet, wenn eine Verbindung abgebrochen werden soll.
*  z.B. bei technischen Problemen oder zur Abweisung unerwünschter Verbindungen
*  Oder bei nicht geöffneten Ports, es wird kein ICMP-Paket mit „Port Unreachable“ verschickt.
| 1 Bit
|-----
| SYN-Flag (''Synchronize'')
|  Pakete mit diesem Flag initiieren eine Verbindung.
*  Dient der Synchronisation von ''Sequenznummern'' beim Verbindungsaufbau.
*  Server antwortet normalerweise mit SYN+ACK oder RST.
| 1 Bit
|-----
| FIN-Flag (''Finish'')
|  Schlussflag, dient zur Freigabe der Verbindung, zeigt an, dass keine Daten vom Sender kommen.
*  FIN- und SYN-Flags haben Sequenznummern, damit diese in der richtigen Reihenfolge abgearbeitet werden.
| 1 Bit
|-----
|}
 
= TCP-Verbindung =
Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert.
* Ein Endpunkt stellt ein geordnetes Paar dar (IP-Adresse und Port).
* Ein solches Paar bildet eine bidirektionale Software-Schnittstelle (Socket).
TCP-Verbindungen werden durch vier Werte (Quadrupel) eindeutig identifiziert:
* Quell-IP-Adresse
* Quell-Port
* Ziel-IP-Adresse
* Ziel-Port
 
=== Beispiel ===
# Ein Serverprozess erzeugt einen Socket auf Port 80 (''bind'').
#* Markiert diesen für eingehende Verbindungen (''listen'').
#* Fordert vom Betriebssystem die nächste anstehende Verbindung an (''accept'').
#* Diese Anforderung blockiert den Serverprozess zunächst, da noch keine Verbindung existiert.
# Die erste Verbindungsanfrage kommt und wird vom Betriebssystem angenommen, die Verbindung kommt zustande.
# Jetzt wird diese Verbindung durch das Quadrupel identifiziert.
## Der Serverprozess wird aufgeweckt und ihm ein Handle für diese Verbindung überreicht.
##* So kann ein Webserver mehrere Verbindungen von verschiedenen Rechnern annehmen
## Üblich startet der Serverprozess einen Kindprozess, dem er die Behandlung der Verbindung delegiert.
## Der Serverprozess fährt mit einer weiterer ''Accept''-Anforderung an das Betriebssystem fort.
 
=== Ports ===
* Portnummern sind Dualsystem 16-Bit-Zahlen und reichen von 0 bis 65535.
* Ports von 0 bis 1023 sind reserviert
** Vergeben von '''I'''nternet '''A'''ssigned '''N'''umbers '''A'''uthority (IANA)
** z.B. ist Port 80 für '''H'''yper'''t'''ext '''T'''ransfer '''P'''rotocol (HTTP) reserviert.
* Das Benutzen der vordefinierten Ports ist nicht bindend.
** Jeder Administrator kann bspw. einen FTP-Server (normalerweise Port 21) auch auf einem beliebigen Port laufen lassen.
* Mehrfaches ''listen'' auf demselben Port ist nicht möglich.
 
= Verbindungsverwaltung =
=== Allgemein ===
Ein Server, der seinen Dienst anbietet, erzeugt einen Endpunkt (Socket) mit der Portnummer und seiner IP-Adresse.
* Bezeichnet als "''passive open''" oder "''listen''".
 
Ein Client, der eine Verbindung aufbauen will, erzeugt einen Endpunkt (Socket) mit seiner IP-Adresse und einer eigenen, noch freien Portnummer.
* Mit der Adresse des Servers und dem Port kann dann eine Verbindung aufgebaut werden.
 
Während der Datenübertragungsphase sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch.
* Bezeichnet als "''active open''"
Jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten.
 
=== Verbindungsaufbau ===
[[Datei:Tcp-handshake.svg|mini|500px| TCP-Handshake]]
 
# Der Client sendet dem Server ein ''SYN''-Paket mit einer Sequenznummer ''x''.
#*Die Sequenznummern sind für die Sicherstellung einer vollständigen Übertragung in der richtigen Reihenfolge und ohne Duplikate wichtig.
#*Ein Paket, dessen ''SYN-Bit'' im Header gesetzt ist.
#*Die Start-Sequenznummer ist eine beliebige zufällige Zahl, abhängig von der TCP-Implementierung. 
# Der Server empfängt das Paket und antwortet.
#*Port geschlossen, antwortet er mit einem TCP-RST, ein Signal, dass keine Verbindung aufgebaut werden kann.
#*Port geöffnet, bestätigt er den Erhalt des ersten SYN-Pakets und stimmt dem Verbindungsaufbau zu, indem er ein SYN/ACK-Paket zurückschickt.
#**Ein Paket, mit ACK-Flag im TCP-Header, welche die Sequenznummer ''x+1'' des SYN-Pakets im Header enthält.
#**Der Server sendet im Gegenzug seine Start-Sequenznummer ''y'', diese ist unabhängig von der Start-Sequenznummer des Clients. 
# Der Client bestätigt den Erhalt des SYN/ACK-Pakets durch ein eigenes ACK-Pakets mit der Sequenznummer ''x+1''.
#*Wird auch als „Forward Acknowledgement“ bezeichnet.
#*Aus Sicherheitsgründen sendet der Client die Sequenznummer des Servers + 1 im ACK-Segment zurück. 
# Die Verbindung ist damit aufgebaut.
 
==== Verbindungsaufbau Beispiel ====
 
{| class="wikitable"
|-
|-
|width="60px"| 1. || SYN-SENT ||width="60px"| → || <SEQ=100><CTL=SYN> ||width="60px"| → || SYN-RECEIVED
| Zuverlässig ||
|-
|-
| 2. || SYN/ACK-RECEIVED || ← || <SEQ=300><ACK=101><CTL=SYN,ACK> || ← || SYN/ACK-SENT
| Verbindungsorientiert ||
|-
|-
| 3. || ACK-SENT || → || <SEQ=101><ACK=301><CTL=ACK> || → || ESTABLISHED
| Datenströme || Übertragung von Datenströmen
|}
|}


* Nach Aufbau ist die Verbindung für beide Kommunikationspartner gleichberechtigt
; TCP stell eine Verbindung zwischen zwei Endpunkten (Sockets) einer Netzverbindung her
* Man kann einer bestehenden Verbindung auf TCP-Ebene nicht ansehen, wer der Server und wer der Client ist.
* Auf dieser Verbindung können in beide Richtungen Daten übertragen werden
* Eine Unterscheidung dieser beiden Rollen in der weiteren Betrachtung keine Bedeutung mehr.
* Unterschied zu UDP (verbindungslos [[Netzwerke:UDP | User Datagram Protokoll (UDP)]])
 
=== Verbindungsabbau ===
[[Datei:TCP-Teardown.svg|mini|500px| TCP-Teardown]]
 
* Der Verbindungsabbau kann ''beidseitig'' oder ''schrittweise einseitig'' erfolgen.
* Der geregelte Verbindungsabbau erfolgt dem Verbindungsaufbau ähnlich.
*# Statt dem SYN-Bits kommt das FIN-Bit zum Einsatz, welches anzeigt, dass keine Daten mehr vom Sender kommen werden.
*# Der Erhalt des Pakets wird mit ACK bestätigt und der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket.
*# Dieses FIN-Paket wird ihm zuletzt bestätigt.
 
* Ein verkürztes ist Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden.
 
=== Halb geschlossene Verbindungen ===
* Der Verbindungsabbau erfolgt schrittweise einseitig.
* Erlaubt der Gegenseite nach der einseitigen Trennung noch Daten zu übertragen.
 
=== Halb offene Verbindungen ===
* wenn eine Seite abstürzt, ohne dass die verbleibende Seite dies erfährt.
* Effekt: Betriebssystemressourcen werden nicht freigegeben.
* Ursprung: TCP-Verbindungen von der Protokollseite bestehen, bis sie abgebaut werden.
 
==== 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.
 
=== 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 angewendet 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.
 
= Datenübertragung =
[[Datei:Tcp daten.svg|mini| 450px | Segmentierung der Nutzdaten]]
 
=== TCP-/IP-Segment-Größe ===
* Typischerweise eine Größe von maximal 1500Bytes .
* 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.
#  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 ===
[[Datei:Tcp transfer.png|mini|450px| 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 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 ===
[[Datei:Sliding window.svg|mini| Sliding Window]]
 
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.
 
=== Überlaststeuerung/Staukontrolle (Congestion Control) ===
 
* Wird eine Verbindung stark belastet, werden immer mehr Pakete verworfen.
* Durch die Wiederholung steigt wiederum die Belastung, dies sorgt (ohne Maßnahmen) für einen Datenstau.
* Die Verlustrate wird von einem IP-Netzwerk ständig beobachtet.
* Normalerweise wird eine TCP/IP-Verbindung langsam gestartet (Slow-Start) und die Senderate schrittweise erhöht, bis zum Datenverlust.
* Ein Datenverlust verringert die Senderate, ohne Verlust wird sie wiederum erhöht.
 
==== Algorithmus zur Überlaststeuerung ====
Gehen bei einer bestimmten Fenstergröße Pakete verloren, kann das festgestellt werden, wenn der Sender innerhalb einer bestimmten Zeit (Timeout) kein ACK erhält.
* Man muss davon ausgehen, dass das Paket aufgrund zu hoher Netzlast von einem Router im Netz verworfen wurde (Stau im Netz).
* Um den Stau aufzulösen, müssen alle beteiligten Sender ihre Netzlast reduzieren.
 
Dazu werden im RFC 2581 vier Algorithmen definiert:
# ''slow start''
# ''congestion avoidance''
# ''fast retransmit''
# ''fast recovery'',
* ''slow start'' und ''congestion avoidance'' werden zusammen verwendet.
* ''fast retransmit'' und ''fast recovery'' werden zusammen verwendet, sind eine Erweiterung von ''slow start'' und ''congestion avoidance''.
 
==== Slow Start Slow Start und Congestion Avoidance ====
[[Datei:TCPSlowStartundCongestionAvoidance.svg|mini|450px|Grafische Darstellung des Slow-Start-Algorithmus]]
 
* Der Slow-Start-Algorithmus dient zur Bestimmung des ''congestion window''.
* Da die momentane Auslastung des Netzes nicht bekannt ist, wird mit kleinen Datenmengen begonnen.
 
# Der Algorithmus startet mit einem kleinen Fenster, von einer Maximum Segment Size (MSS), in dem Datenpakete vom Sender zum Empfänger übertragen werden.
# Der Empfänger sendet ACK an den Sender zurück.
# Für jedes empfangene ACK wird die Größe des ''congestion window'' um eine MSS erhöht.
#*Dies führt innerhalb einer Roundtrip-Zeit zu einer Verdopplung des Congestion Windows.
# Dieses exponentielle Wachstum wird so lange fortgesetzt, bis der ''Slow-Start Threshold'' erreicht wird.
#*Die Phase des exponentiellen Wachstums wird auch ''Slow Start Phase'' genannt.
# Danach wird das Congestion Window nur noch um eine MSS erhöht, wenn alle Pakete aus dem Fenster erfolgreich übertragen wurden.
#*Es wächst pro Roundtrip-Zeit nur noch um eine MSS, also nur noch linear.
#**Diese Phase wird als ''Congestion Avoidance Phase'' bezeichnet.
#*Das Wachstum wird beendet, wenn das vom Empfänger festgelegte Empfangsfenster erreicht worden ist.
 
 
Kommt es zu einem Timeout, wird das ''congestion window'' auf 1 zurückgesetzt, der ''slow-start threshold'' wird auf die Hälfte der gesendeten, unquittierten Pakete herabgesetzt (Flight Size).
* Die Phase des exponentiellen Wachstums wird also verkürzt.
* Das Fenster wächst bei häufigen Paketverlusten nur langsam.


==== Fast-Retransmit und Fast-Recovery ====
; Vorteile
* Werden eingesetzt, um nach Paketverlust schneller auf die Stau-Situation zu reagieren.
* [[Transmission Control Protocol/Überlastungskontrolle|Überlastungskontrolle]]
* Empfänger informiert den Sender, wenn Pakete außer der Reihe ankommen und somit dazwischen ein Paketverlust vorliegt.
* Zuverlässige Datenübertragung
* Der Empfänger bestätigt das letzte korrekte Paket erneut für jedes weitere ankommende Paket außer der Reihe.
** erkennt verlorene, doppelte und fehlerhafte Segmente
* Man spricht dabei von ''Dup-Acks'' (''duplicate acknowledgments''),
** Mehrere aufeinanderfolgende Nachrichten, welche dasselbe Datensegment ACKen.
* Der Sender bemerkt die duplizierten ACKS, und nach dem dritten Duplikat sendet er sofort, vor Ablauf des Timers, das verlorene Paket erneut.
** Da nicht auf den Timerablauf gewartet werden muss, heißt das Prinzip ''Fast Retransmit''.
* Dup-Acks: auch Hinweise darauf, dass ein Paketverlust stattfand, dennoch die folgenden Pakete angekommen sind.
* Das Sendefenster wird nach dem Fehler nur halbiert (kein Slow-Start). 


; Allgemeines
* TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex
* Kann auch als zwei Halbduplexverbindungen betrachtet werden (Informationsfluss in beide Richtungen (allerdings nicht gleichzeitig))
* Die Daten in Gegenrichtung können zusätzliche Steuerungsinformationen enthalten
* Anwendungen, die TCP häufig nutzen, sind zum Beispiel Webbrowser und Webserver


Zusätzlich kann das Sendefenster noch um die Anzahl der Dup-Acks erhöht werden,
; TCP-Software
* Jedes Dup-Ack steht für ein weiteres Paket, welches den Empfänger erreicht hat.
* Übernimmt Verbindungsverwaltung sowie die Datenübertragung
* Dadurch kann nach dem Fehler schneller wieder die volle Sendeleistung erreicht werden.
* Netz-Protokollstack des Betriebssystems
* Das Prinzip nennt man ''Fast-Recovery''.
* Anwendungsprogramme nutzen Sockets


[[Datei:Tcp verbindung.png|none|750px|Verwaltung der TCP-Verbindungen als endlicher Automat]]
==== Entwicklung ====
* Entwickelt von Robert E. Kahn und Vinton G. Cerf als Forschungsarbeit
* Beginn 1973, erste Standardisierung 1981 als [https://tools.ietf.org/html/rfc793 ''RFC 793'']
* Danach gab es viele Erweiterungen, diese werden bis heute in RFCs spezifiziert


= Installation =
== Das Transmission Control Protocol arbeitet auf dem OSI-04 ==
 
= Konfiguration =
== Dateien ==
 
= Dokumentation =
== RFC ==
# RFC 793 (1981)
# RFC 7323 (2014)
== Man-Pages ==
== Info-Pages ==
 
= Links =
== Intern ==
== Weblinks ==
 
= Testfragen =
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>
 
= TMP =
== Die Transportschicht ==
* Transmission Control Protocol
* User Datagram Protocol
 
=== Aufgaben der Transportschicht ===
* Verbindungsaufbau (falls verbindungsorientiert)
* Datentransfer
* normale Daten / Daten mit Priorität, Unterbrechungssignale
* strom- oder paketorientiert
* Fehlerbehandlung, Flusssteuerung
* Verbindungsabbruch
* durch den Benutzer
* durch den Diensterbringer, d.h. die Transportschicht
* Adressierung des "Benutzers" der Transportschicht, d.h. des Anwendungsprozesses
* Managementfunktionen
* Programmierschnittstelle (API)
 
== Transmisson Control Protocol (TCP) ==
* Verbindungsorientiertes Protokoll
* Beinhaltet verschiedene Algorithmen zur Fehler-erkennung und -behandlung
* Sequenznummern
* Quittungsnummern
* Anzeigen (Flags)
* Die richtige Reihenfolge der Daten ist garantiert
* Bietet der Anwendungsschicht einen zuverlässigen Transportdienst
 
=== Was ist TCP? ===
* Das Transmission Control Protocol arbeitet auf dem OSI-Layer 4
* TCP verwendet 16-Bit Portnummern zur Adressierung
* TCP verwendet 16-Bit Portnummern zur Adressierung
* Zusätzlich zur Adressierung übernimmt es weitere Aufgaben
* Zusätzlich zur Adressierung übernimmt es weitere Aufgaben
Zeile 482: Zeile 45:
* Verbindungsaufbau/-abbau
* Verbindungsaufbau/-abbau
* Fehlerkontrolle (-korrektur)
* Fehlerkontrolle (-korrektur)
* Flußkontrolle (engl. Flow Control)
* Flußkontrolle (Flow Control)
* verhindert, dass der Empfänger von einem Sender schneller Daten erhält, als er entgegennehmen kann
* verhindert, dass der Empfänger von einem Sender schneller Daten erhält, als er entgegennehmen kann
* Netzwerk-Überlastkontrolle (engl. Congestion Control)
* Netzwerk-Überlastkontrolle (Congestion Control)
* verhindert, dass es zu einer Überlastsituation im Netz kommt, die zum vollständigen Zusammenbruch des Netzes führen könnte (congestion collapse)
* verhindert, dass es zu einer Überlastsituation im Netz kommt, die zum vollständigen Zusammenbruch des Netzes führen könnte (congestion collapse)
* bei Erkennen einer Überlastsituation (Paketverlust!) wird vom Sender die Datenrate gedrosselt
* bei Erkennen einer Überlastsituation (Paketverlust!) wird vom Sender die Datenrate gedrosselt
* transparente Übertragung von byte streams
* transparente Übertragung von byte streams
* Anwendungen, die TCP benutzen, sollen nicht merken, dass die Daten in Form von Paketen übertragen werden.
* Anwendungen, die TCP benutzen, sollen nicht merken, dass die Daten in Form von Paketen übertragen werden
* Mutliplexing
* Mutliplexing
* Mehrfachnutzung einer Verbindung
* Mehrfachnutzung einer Verbindung
 
* Verbindungsorientiertes Protokoll
=== TCP ===
* Beinhaltet verschiedene Algorithmen zur Fehlererkennung und -behandlung
* RFC 793. J. Postel. Transmission Control Protocol. 1981.
* Sequenznummern
* Quittungsnummern
* Anzeigen (Flags)
* Die richtige Reihenfolge der Daten ist garantiert
* Bietet der Anwendungsschicht einen zuverlässigen Transportdienst
* RFC 793. J. Postel. Transmission Control Protocol. 1981
* setzt direkt auf dem Internet Protokoll (IP) auf
* setzt direkt auf dem Internet Protokoll (IP) auf
* IP Protokoll Nr.: 06
* IP Protokoll Nr.: 06
Zeile 500: Zeile 68:
* garantiert eine fehlergesicherte, zuverlässige Transportverbindung zwischen zwei Rechnersystemen (Ende zu Ende Kontrolle)
* garantiert eine fehlergesicherte, zuverlässige Transportverbindung zwischen zwei Rechnersystemen (Ende zu Ende Kontrolle)


== TCP im DoD-Modell ==
=== TCP im DoD-Modell ===
* Rolle von TCP im OSI-Referenzmodell
* Rolle von TCP im OSI-Referenzmodell


== Eigenschaften von TCP ==
=== Eigenschaften von TCP ===
* Vollduplex-Verbindung
* Vollduplex-Verbindung
* stellt eine “byte pipe” zur Verfügung - unstrukturierter Datenstrom
* stellt eine “byte pipe” zur Verfügung - unstrukturierter Datenstrom
Zeile 510: Zeile 78:
* Variable Grösse des Sendefensters bestimmt durch das Maximum von:
* Variable Grösse des Sendefensters bestimmt durch das Maximum von:
* Angabe des Empfängers (receiver window size)
* Angabe des Empfängers (receiver window size)
* Congestion window size, abhängig von einer lokalen Schätzung der Netzbelastung -> “Slow Start” Algorithmus
* Congestion window size, abhängig von einer lokalen Schätzung der Netzbelastung -> “Slow Start” Algorithmus
 
== Basismechanismen ==
== Basismechanismen ==
* Unterteilt den byte stream in Einheiten
* Unterteilt den byte stream in Einheiten
Zeile 516: Zeile 85:
* Segmente haben eine variable Länge
* Segmente haben eine variable Länge
* Die maximale Segmentgrösse wird bei der Verbindungserstellung festgelegt
* Die maximale Segmentgrösse wird bei der Verbindungserstellung festgelegt
* Jedes Segment hat eine Folgenummer, die seine Position im Datenstrom in Bytes spezifiziert.
* Jedes Segment hat eine Folgenummer, die seine Position im Datenstrom in Bytes spezifiziert
* Abgesendete Segmente müssen innerhalb einer bestimmten Zeit bestätigt werden (adaptiv geschätzte Round Trip Time).
* Abgesendete Segmente müssen innerhalb einer bestimmten Zeit bestätigt werden (adaptiv geschätzte Round Trip Time)
* Bestätigungen werden verzögert gesendet (ca. 200 ms)
* Bestätigungen werden verzögert gesendet (ca. 200 ms)
* Wenn keine Bestätigung über den erfolgreichen Empfang dieses Paketes innerhalb der Timer-Laufzeit eintrifft, wird die Übertragung wiederholt.
* Wenn keine Bestätigung über den erfolgreichen Empfang dieses Paketes innerhalb der Timer-Laufzeit eintrifft, wird die Übertragung wiederholt
* Jedes Segment hat eine Ende-zu-Ende-Prüfsumme
* Jedes Segment hat eine Ende-zu-Ende-Prüfsumme
* Fehlerhaft empfangene Segmente werden ignoriert.
* Fehlerhaft empfangene Segmente werden ignoriert
* Empfänger ordnet empfangene Segmente entsprechend ihrer Folgenummer
* Empfänger ordnet empfangene Segmente entsprechend ihrer Folgenummer
* Duplikate werden ignoriert.
* Duplikate werden ignoriert
 
== Der TCP-Header ==
=== Der TCP-Header im Detail 1 ===
* Sender-Port
16-Bit-Adresse des Quell-Sockets
* Empfänger-Port
16-Bit-Adresse des Ziels (Service)
 Endpunkte der TCP-Verbindung 
* Sequenznummer
32-Bit-Zahl zur Indentifizierung gesendeter Datensegmente
* Quittungsnummer (Achnowledgment Number)
* Gibt an bis zu welchem Byte Daten korrekt empfangen wurden, indem der Empfänger übermittelt, welche Byte als nächstes erwartet wird
* Länge (Data Offset/Header Length)
* Länge des TCP-Kopfes in 32Bit-Worten
* Wegen der variablen Länge des Optionsfeldes notwendig
 
* Fenstergröße
* Fenstergröße in Byte ab dem bereits bestätigtem Byte
* Flusssteuerung
* wird vom Host je nach Belastung dynamisch festgelegt
* Prüfsumme über
* TCP-Paketkopf
* Daten
* Teile des IP-Paketkopfes (Pseudo-Header)
* IP-Quell- und Ziel-Adresse
* Protokollnummer (06)
* TCP-Segmentlänge
* Die Einbeziehung des Pseudo-Headers in die Prüfsumme hilft durch IP falsch zugeteilte Pakete zu erkennen
* Der TCP-Header im Detail 4
* Urgent-Zeiger
* Ergibt zusammen mit der Sequenznummer einen Zeiger auf das Ende von dringenden Daten, die vor den eigentlichen Nutzdaten stehen
* Wird nur bei gesetztem URG-Flag gelesen
* Optionen
* No-Option
* Maximum Segment Size (MSS)
* Maximale Anzahl von Nutzdaten die ein Host annehmen will oder kann
* Wird bei beim Verbindungsaufbau ausgetauscht
* Der kleinere Wert wird verwandt
* Default ist 536 Byte
* End of Option List
* Füllzeichen
* auf die nächste 32-Bit-Grenze wird mit Nullen aufgefüllt
* Nutzdaten
* Daten höherer Protokolle (z.B. http)
 
=== Flags ===
* Sechs 1-Bit-Felder zur Steuerung der Verbindung
* URG
* Urgent: Der Urgent-Pointer wird verwand
* ACK
* Achnowledgement: Die Bestätigung ist gültig
* PSH
* Push: Daten werden beim Empfänger nicht gepuffert
* RST
* Reset: Verbindung wird zurückgesetzt (Ungültiges Segment, Hostabsturz oder Verbindungsablehnung)
* SYN
* Synchronise Sequenze Number: Verbindungsaufbau
* FIN
* Finish: Verbindungsabbau
 
== Identifizieren  von  Anwendungen ==
== Ports ==
* Ports von 0 bis 65535 gibt es unabhängig voneinander bei TCP  und UDP
* Sie stellen die Endpunkte einer Kommunikations-beziehung  zwischen zwei Rechnern dar
* Die sog. „well-known-ports“ von 0..1023 sind standardisiert  z.B.:
* TCP-Port 80 für http
* UDP+TCP-Port 53 für DNS
* UDP-Port 123 für NTP
 
* Die well-known-ports  sind für Systemdienste/Daemons  reserviert und dürfen nur mit besonderen Rechten (root)  genutzt werden
 
=== TCP-Multiplexmechanismus ===
* Da die Kombination aus IP-Adresse, Quell- und Zielport  eindeutig ist, können auch Datenströme gleichen Typs  eindeutig den zuständigen Prozessen zugeordnet werden


=== Zuweisung von Portnummern ===
== Socket-Schnittstelle ==
* Passive Seite
* Server bindet sich an einen bestimmten Port (bind())
* Aktive Seite
* Client sendet Anfrage oder erstellt eine Verbindung zum Port des Servers (connect()).
* Portnummern können Anwendungsdiensten statisch zugeordnet sein: Eintrag in einer Datenbank, die den durch Server erbrachten Diensten bestimmte Ports zuordnet
/etc/services (UNIX)
%SYSTEMROOT%\system32\drivers\etc\services  (Windows)
* Dynamische Zuordnung via Verzeichnisdienst, Nameserver (lokal oder verteilt) möglich.
 
=== Verwaltung der well-known-ports ===
* Internet Assigned Numbers Authority (IANA)
* Zuständig für Vergabe von Konstanten in TCP/ IP- Protokollen (port numbers, protocol numbers, ...)
* Bereich 0.. 1023: Für globale "well known" ports, kontrolliert von der IANA
* Bereich 1024 .. 65535: Frei für dynamische Allozierung durch Prozesse oder für statische Allozierung mit lokaler Bedeutung
* Registrierung durch IANA ist optional
* Aktuelle globale/statische Zuordnungen: ftp:// ftp.isi.edu / in-notes / iana / assignments
 
=== Well-known port numbers ===
'''%SYSTENROOT%\system32\drivers\etc\services'''
# Copyright (c) 1993-1999 Microsoft Corp.
# Diese Datei enthält die Portnummern für bekannte Dienste gemäß IANA.
# Format:
# <Dienstname>  <Portnummer>/<Protokoll>  [Alias...]  [#<Kommentar>]
ftp-data          20/tcp                          #FTP, data
ftp                21/tcp                          #FTP. control
telnet            23/tcp
smtp              25/tcp    mail                  #Simple Mail Transfer Protocol
time              37/tcp    timserver
time              37/udp    timserver
domain            53/tcp                          #Domain Name Server
domain            53/udp                          #Domain Name Server
tftp              69/udp                          #Trivial File Transfer
http              80/tcp    www www-http          #World Wide Web
pop3              110/tcp                          #Post Office Protocol - Version 3
nntp              119/tcp    usenet                #Network News Transfer Protocol
ntp              123/udp                          #Network Time Protocol
netbios-ns        137/tcp    nbname                #NETBIOS Name Service
netbios-ns        137/udp    nbname                #NETBIOS Name Service
netbios-dgm      138/udp    nbdatagram            #NETBIOS Datagram Service
netbios-ssn      139/tcp    nbsession              #NETBIOS Session Service
imap              143/tcp    imap4                  #Internet Message Access Protocol
snmp              161/udp                          #SNMP
irc              194/tcp                          #Internet Relay Chat Protocol       
ipx              213/udp                          #IPX over IP
https            443/tcp    MCom
https            443/udp    MCom
[...]
 
== Die Socket-Schnittstelle ==
* De-facto-Standard für TCP/IP Programmierschnittstelle
* De-facto-Standard für TCP/IP Programmierschnittstelle
* Zugang zu TCP, UDP und (eingeschränkt) IP
* Zugang zu TCP, UDP und (eingeschränkt) IP
Zeile 660: Zeile 106:
* Benennung/Adressierung von Kommunikations-endpunkten
* Benennung/Adressierung von Kommunikations-endpunkten
* name binding
* name binding
* Können benutzt werden wie Dateideskriptoren  
* Können benutzt werden wie Dateideskriptoren
 
== Verbindungen und Verbindungsendpunkte ==
== Verbindungen und Verbindungsendpunkte ==
* Eine TCP-Verbindung wird durch ein Paar von Adressen und Port-Nummern identifiziert (Verbindungsendpunkte):
* Eine TCP-Verbindung wird durch ein Paar von Adressen und Port-Nummern identifiziert (Verbindungsendpunkte):
Zeile 666: Zeile 113:
* IP-Adresse und Port-Nummer Host B
* IP-Adresse und Port-Nummer Host B
* Jede Verbindung wird durch ein Paar von Verbindungsendpunkten eindeutig identifiziert
* Jede Verbindung wird durch ein Paar von Verbindungsendpunkten eindeutig identifiziert
* mehrere Verbindung zwischen den gleichen Hosts sind dadurch gleichzeitig möglich.
* mehrere Verbindung zwischen den gleichen Hosts sind dadurch gleichzeitig möglich
== TCP-Verbindungsmanagement ==
* Das TCP-Verbindungsmanagement ist notwendig, weil die tieferen Netzwerkschichten keinen zuverlässigen Transport der Daten gewährleisten
* Daten können beim Transport
* verloren gehen
* verfälscht werden (defekte Pakete)
* durcheinander gebracht werden (falsche Reihenfolge)
* verzögert werden
* dupliziert werden
=== TCP Verbindungsablauf ===
* Drei Phasen
* Verbindungsaufbau
* Datenaustausch
* Verbindungsabbau
 
== 1. Verbindungsaufbau ==
* Verbindungswunsch
== Bestätigung durch beide Seiten ==
* TCP-VerbindungsaufbauBeispiel
== 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)
== TCP Verbindungsaufbau3-Way-Handshake ==
=== 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


== Segmente, Datenströme und Sequenznummern ==
== Segmente, Datenströme und Sequenznummern ==
Zeile 701: Zeile 120:
* Zufallszahl auf beiden Seiten (32 Bit)
* Zufallszahl auf beiden Seiten (32 Bit)
* Seq.nr. := Initiale Seq.nr. + Byte-Position im Datenstrom
* Seq.nr. := Initiale Seq.nr. + Byte-Position im Datenstrom
* TCP betrachtet einen Datenstrom als Sequenz von Bytes, die für die Übertragung in TCP-Segmente eingeteilt werden.
* TCP betrachtet einen Datenstrom als Sequenz von Bytes, die für die Übertragung in TCP-Segmente eingeteilt werden
* Jedes Segment wird dann in der Regel auf ein IP-Paket abgebildet.
* Jedes Segment wird dann in der Regel auf ein IP-Paket abgebildet
* Größe eines Segmentes bei lokaler Übertragung gemäß physikalischem Netz (MTU)
* Größe eines Segmentes bei lokaler Übertragung gemäß physikalischem Netz (MTU)
* Ist diese nicht angegeben oder kann sie nicht ermittelt werden, dann wird ein Standartwert von 536 Bytes verwandt
* Ist diese nicht angegeben oder kann sie nicht ermittelt werden, dann wird ein Standartwert von 536 Bytes verwandt
== 2. 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 Windowwanderndes 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
== 3. Abbau einer TCP-Verbindung ==
* Senden eines Segments mit FIN=1
* Bestätigung
* muss für beide Richtungen separat erfolgen
== TCP-Verbindungsabbau ==
* durch zweimal half-close
* da die TCP-Verbindung bidirektional ist, können beide Richtungen getrennt voneinander beendet werden
* wer seine Senderolle beenden möchte, setzt das FIN Flag
* FIN „kostet“ ein Byte und wird daher durch ein ack(nowledgement) bestätigt
* der andere Teilnehmer kann weiter senden - jedoch sieht man fast immer das Verhalten, dass der andere Teilnehmer als Reaktion auch seine Senderolle beendet
* derjenige Teilnehmer, der zuerst seine Verbindung beendet, führt ein „active close“ (i.d.R. der Client) durch, der Kommunikationspartner ein „passive close“ (i.d.R. der Server)
== 2MSL Wait State ==
* derjenige Teilnehmer, der einen active close durchführt, muss nach  Senden des ACKS die Verbindung für eine gewisse Zeit für das FIN des  Kommunikationspartners offen halten
* Grund: das ack könnte verloren gehen und müsste dann erneut übertragen werden
* die „gewisse Zeit“ beträgt 2 maximal segment lifetimes (daher 2MSL wait state)
* implementiert wird eine MSL als 30 - 120 Sekunden
* während 2MSL Wait State kann daher die Port-Nummer noch nicht wieder für andere  TCP-Verbindungen verwendet werden
== TCP Reset ==
* ein Segment, bei dem das RST (reset) bit im TCP header gesetzt ist, terminiert die Verbindung in Form eines „abortive release“ (im Gegensatz zum „orderly release“ mit FIN):
* alle Daten, die beim Sender gepuffert waren, werden verworfen und das reset Segment wird sofort gesendet, die Verbindung ist damit aus Sicht des RST Senders sofort terminiert
* es können beim Reset Daten verloren gehen (das passiert beim Verbindungsabbau mit FIN nicht)
* der Emfänger eines RST Segmentes meldet dies der Anwendung und terminiert sofort
* es gibt prinzipiell zwei unterschiedliche Situationen, wann ein RST gesendet wird:
* wenn ein Port nicht belegt ist (connection refused)
* wenn eine bestehende Verbindung abgebrochen wird (connection reset by peer)
== TCP-VerbindungsabbauBeispiel ==
== 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
== Ablehnung einer Verbindung ==
* Versuch eines Verbindungsaufbaus zu einem geschlossenen Port
* Beispiel TCP
* Beispiel UDP
== Ablehnung einer VerbindungTCP ==
== Ablehnung einer VerbindungUDP ==
== Überlastungskontrolle ==
* Bei Paketvermittelten Netzen kann es zu Überlastung kommen
* Beim Zielhost
* Innerhalb des Netzwerkes
* Lösungen
Änderung der Fenstergröße
* Congestion Windows Size (Größe des Überlastungsfensters)
* Die tatsächliche Segmentgröße ist ein Limit aus beiden Werten
== Slow Start with Congestion Avoidance ==
* Beim Verbindungsaufbau wird das Überlastungfenster auf die Größe eines Segmentes gesetzt
* Kommen die Quittungen des versandten Segmentes ohne Timeout an, wird die Größe des Überlastungsfensters verdoppelt
* Dies geschieht bis zum Schwellenwert von 64 KByte
* Danach pro erfolgreichem Sende- und Empfangszyklus um jeweils eine Segmentgröße
* Dieser Algorithmus ist für zuverlässige Verbindungen konzipiert und sollte z.B. bei WLANs deaktiviert werden
* Dort verringert er stark die effektive Bandbreit
== Slow Start Algorithmus ==


== Allgemeines ==
TCP ist im Prinzip eine [[Ende-zu-Ende-Verbindung]] in [[Vollduplex]], welche die Übertragung der Informationen in beide Richtungen zulässt, analog zu einem Telefongespräch
* Diese Verbindung kann auch als zwei [[Duplex (Nachrichtentechnik)|Halbduplexverbindungen]], bei denen Informationen in beide Richtungen (allerdings nicht gleichzeitig) fließen können, betrachtet werden
* Die Daten in Gegenrichtung können dabei zusätzliche Steuerungsinformationen enthalten
* Die Verwaltung dieser Verbindung sowie die Datenübertragung werden von der TCP-Software übernommen
* Die TCP-Software ist üblicherweise im Netz-Protokollstack des Betriebssystems angesiedelt
* Anwendungsprogramme benutzen eine Schnittstelle dazu, meist [[Socket (Software)|Sockets]], die sich (je nach Betriebssystem unterschiedlich) beispielsweise bei [[Microsoft Windows]] in extra einzubindenden [[Programmbibliothek]]en („[[Winsock]].dll“ bzw. „wsock32.dll“) befinden. [[Linux]] und viele andere [[Unixoides System|unixoide Betriebssysteme]] enthalten einen Socketlayer im Betriebssystemkern
* Auf den Socketlayer wird über Systemaufrufe zugegriffen
* Anwendungen, die TCP häufig nutzen, sind zum Beispiel [[Webbrowser]] und [[Webserver]]
Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert
* Ein Endpunkt stellt ein [[geordnetes Paar]] dar, bestehend aus [[IP-Adresse]] und [[Port (Protokoll)|Port]]
* Ein solches Paar bildet eine bidirektionale [[Software]]-Schnittstelle und wird auch als [[Socket (Software)|Socket]] bezeichnet
* Somit wird eine TCP-Verbindung durch vier Werte (einem Quadrupel) identifiziert:
(Lokaler Rechner, Lokaler Port, Entfernter Rechner, Entfernter Port)
Dabei kommt es auf das gesamte Quadrupel an
* Beispielsweise können zwei verschiedene Prozesse auf demselben Rechner denselben lokalen Port benutzen und dabei sogar mit demselben Rechner auf der gegenüberliegenden Seite kommunizieren, sofern die beteiligten Prozesse auf der anderen Seite unterschiedliche Ports benutzen
* In einem solchen Fall würde es sich um zwei verschiedene Verbindungen handeln, deren Quadrupel sich nur in einem von vier Werten unterscheidet: dem Port auf der gegenüberliegenden Seite
Verbindung 1: (Lokaler Rechner, Port x, Entfernter Rechner, Port y)
Verbindung 2: (Lokaler Rechner, Port x, Entfernter Rechner, Port z)
Ein Serverprozess erzeugt beispielsweise einen Socket (''socket bind'') auf Port 80, markiert diesen für eingehende Verbindungen (''listen'') und fordert vom Betriebssystem die nächste anstehende Verbindung an (''accept'')
* Diese Anforderung blockiert den Serverprozess zunächst, da noch keine Verbindung existiert
* Kommt dann die erste Verbindungsanfrage durch einen Client an, wird sie vom Betriebssystem angenommen, so dass die Verbindung zustande kommt
* Ab jetzt wird diese Verbindung durch das oben beschriebene Quadrupel identifiziert
Schließlich wird der Serverprozess aufgeweckt und ihm ein Handle für diese Verbindung überreicht. Üblicherweise startet der Serverprozess anschließend einen Kindprozess, zu dem er die Behandlung der Verbindung delegiert
* Er selbst setzt dann seine Arbeit mit einer weiteren ''Accept''-Anforderung an das Betriebssystem fort
Dadurch ist es möglich, dass ein Webserver mehrere Verbindungen von verschiedenen Rechnern annehmen kann
* Mehrfaches ''listen'' auf demselben Port ist nicht möglich. Üblicherweise bestimmt das Programm auf der [[Client]]seite den Port nicht selbst, sondern lässt ihn sich vom Betriebssystem zuweisen
Ports sind [[Dualsystem|16-Bit-Zahlen]] (Portnummern) und reichen von 0 bis 65535
* Ports von 0 bis 1023 sind reserviert ([[Well Known Ports]] und werden von der [[Internet Assigned Numbers Authority|IANA]] vergeben, z.&nbsp;B.&nbsp;ist Port 80 für das im [[World Wide Web|WWW]] verwendete [[Hypertext Transfer Protocol|HTTP]] reserviert
* Das Benutzen der vordefinierten Ports ist nicht bindend
* So kann jeder Administrator beispielsweise einen FTP-Server (normalerweise Port 21) auch auf einem beliebigen anderen Port laufen lassen
== Datenintegrität und Zuverlässigkeit ==
Im Gegensatz zum verbindungslosen [[User Datagram Protocol|UDP]] [[Implementation|implementiert]] TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten
* Das darunterliegende Protokoll ([[Internet Protocol|IP]]) ist paketorientiert, wobei [[Datenpaket]]e verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können
* TCP wurde entwickelt, um mit der Unsicherheit der darunterliegenden Schichten umzugehen
* Es prüft daher die Integrität der Daten mittels der [[Prüfsumme]] im Paketkopf und stellt die Reihenfolge durch [[Sequenznummer]]n sicher
* Der Sender [[Sendewiederholung|wiederholt]] das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne ([[Timeout (Netzwerktechnik)|Timeout]]) eintrifft
* Die Daten der Pakete werden beim Empfänger in einem [[Puffer (Informatik)|Puffer]] in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen
Der [[Datentransfer]] kann selbstverständlich jederzeit nach dem „Aufbau einer Verbindung“ gestört, verzögert oder ganz unterbrochen werden
* Das Übertragungssystem läuft dann in einen Timeout
* Der vorab getätigte „Verbindungsaufbau“ stellt also keinerlei Gewähr für eine nachfolgende, dauerhaft gesicherte Übertragung dar
=== Bestätigungen ===
Die jeweilige Länge des Puffers, bis zu der keine Lücke im Datenstrom existiert, wird bestätigt (''windowing'')
* Dadurch ist das Ausnutzen der Netz-Bandbreite auch bei großen Strecken möglich
* Bei einer Übersee- oder Satellitenverbindung dauert das Eintreffen des ersten ACK-Signals aus technischen Gründen bisweilen mehrere 100&nbsp;Millisekunden, in dieser Zeit können unter Umständen mehrere hundert Pakete gesendet werden
* Der Sender kann den Empfängerpuffer füllen, bevor die erste Bestätigung eintrifft
* Alle Pakete im Puffer können gemeinsam bestätigt werden
* Bestätigungen können zusätzlich zu den Daten in den [[#Aufbau des TCP-Headers|TCP-Header]] des entgegengesetzten Datenstroms eingefügt werden (''piggybacking''), falls der Empfänger ebenfalls Daten für den Sender bereithält
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/Transmission Control Protocol}}
----
* [[Liste der standardisierten Ports]]
* [[Stream Control Transmission Protocol]] (SCTP)
=== Dokumentation ===
==== RFC ====
{| class="wikitable sortable options"
|-
! RFC !! Titel
|-
| [https://www.rfc-editor.org/info/rfc793 793] || Transmission Control Protocol
|-
| [https://www.rfc-editor.org/info/rfc1071 107] || Berechnen der Prüfsumme für IP, UDP und TCP
|-
| [https://www.rfc-editor.org/info/rfc1122 1122] || Fehlerbehebungen bei TCP
|-
| [https://www.rfc-editor.org/info/rfc1323 1323] || Erweiterungen bei TCP
|-
| [https://www.rfc-editor.org/info/rfc2018 2018] || TCP SACK – Selective Acknowledgment Options
|-
| [https://www.rfc-editor.org/info/rfc3168 3168] || Explicit Congestion Notification
|-
| [https://www.rfc-editor.org/info/rfc5482 54829] || TCP User Timeout Option
|-
| [https://www.rfc-editor.org/info/rfc5681 5681] || TCP Congestion Control – TCP-Überlastkontrolle
|-
| [https://www.rfc-editor.org/info/rfc7414 7414] || Übersicht zu TCP RFCs
|-
| [https://www.rfc-editor.org/info/rfc7323 7323] || 2014
|}
=== Links ===
==== Weblinks ====
# [http://www.cs.berkeley.edu/~brewer/cs262/cong-avoid.pdf Congestion Avoidance and Control]
# [http://www.warriorsofthe.net/ Warriors of the net] (Film zu TCP)


[[Kategorie:Netzwerke]]
[[Kategorie:TCP]]
</noinclude>

Aktuelle Version vom 28. Januar 2024, 14:54 Uhr

Transmission Control Protocol (TCP)

Beschreibung

Transportprotokoll
Funktionen Beschreibung
Zuverlässig
Verbindungsorientiert
Datenströme Übertragung von Datenströmen
TCP stell eine Verbindung zwischen zwei Endpunkten (Sockets) einer Netzverbindung her
Vorteile
Allgemeines
  • TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex
  • Kann auch als zwei Halbduplexverbindungen betrachtet werden (Informationsfluss in beide Richtungen (allerdings nicht gleichzeitig))
  • Die Daten in Gegenrichtung können zusätzliche Steuerungsinformationen enthalten
  • Anwendungen, die TCP häufig nutzen, sind zum Beispiel Webbrowser und Webserver
TCP-Software
  • Übernimmt Verbindungsverwaltung sowie die Datenübertragung
  • Netz-Protokollstack des Betriebssystems
  • Anwendungsprogramme nutzen Sockets

Entwicklung

  • Entwickelt von Robert E. Kahn und Vinton G. Cerf als Forschungsarbeit
  • Beginn 1973, erste Standardisierung 1981 als RFC 793
  • Danach gab es viele Erweiterungen, diese werden bis heute in RFCs spezifiziert

Das Transmission Control Protocol arbeitet auf dem OSI-04

  • TCP verwendet 16-Bit Portnummern zur Adressierung
  • Zusätzlich zur Adressierung übernimmt es weitere Aufgaben
  • Verbindungsmanagement (Three-Way-Handshake)
  • Verbindungsaufbau/-abbau
  • Fehlerkontrolle (-korrektur)
  • Flußkontrolle (Flow Control)
  • verhindert, dass der Empfänger von einem Sender schneller Daten erhält, als er entgegennehmen kann
  • Netzwerk-Überlastkontrolle (Congestion Control)
  • verhindert, dass es zu einer Überlastsituation im Netz kommt, die zum vollständigen Zusammenbruch des Netzes führen könnte (congestion collapse)
  • bei Erkennen einer Überlastsituation (Paketverlust!) wird vom Sender die Datenrate gedrosselt
  • transparente Übertragung von byte streams
  • Anwendungen, die TCP benutzen, sollen nicht merken, dass die Daten in Form von Paketen übertragen werden
  • Mutliplexing
  • Mehrfachnutzung einer Verbindung
  • Verbindungsorientiertes Protokoll
  • Beinhaltet verschiedene Algorithmen zur Fehlererkennung und -behandlung
  • Sequenznummern
  • Quittungsnummern
  • Anzeigen (Flags)
  • Die richtige Reihenfolge der Daten ist garantiert
  • Bietet der Anwendungsschicht einen zuverlässigen Transportdienst
  • RFC 793. J. Postel. Transmission Control Protocol. 1981
  • setzt direkt auf dem Internet Protokoll (IP) auf
  • IP Protokoll Nr.: 06
  • Theoretisch ist es möglich TCP mit einem beliebigen Protokoll der Schicht 3 zu kombinieren
  • Praktisch wird TCP allerdings immer in IP gekapselt
  • garantiert eine fehlergesicherte, zuverlässige Transportverbindung zwischen zwei Rechnersystemen (Ende zu Ende Kontrolle)

TCP im DoD-Modell

  • Rolle von TCP im OSI-Referenzmodell

Eigenschaften von TCP

  • Vollduplex-Verbindung
  • stellt eine “byte pipe” zur Verfügung - unstrukturierter Datenstrom
  • Folgenummern sind Bytenummern
  • Sliding Window-Protokoll
  • Variable Grösse des Sendefensters bestimmt durch das Maximum von:
  • Angabe des Empfängers (receiver window size)
  • Congestion window size, abhängig von einer lokalen Schätzung der Netzbelastung -> “Slow Start” Algorithmus

Basismechanismen

  • Unterteilt den byte stream in Einheiten
  • die jeweils in einem IP Paket übertragen werden, diese Einheiten heißen Segmente
  • Segmente haben eine variable Länge
  • Die maximale Segmentgrösse wird bei der Verbindungserstellung festgelegt
  • Jedes Segment hat eine Folgenummer, die seine Position im Datenstrom in Bytes spezifiziert
  • Abgesendete Segmente müssen innerhalb einer bestimmten Zeit bestätigt werden (adaptiv geschätzte Round Trip Time)
  • Bestätigungen werden verzögert gesendet (ca. 200 ms)
  • Wenn keine Bestätigung über den erfolgreichen Empfang dieses Paketes innerhalb der Timer-Laufzeit eintrifft, wird die Übertragung wiederholt
  • Jedes Segment hat eine Ende-zu-Ende-Prüfsumme
  • Fehlerhaft empfangene Segmente werden ignoriert
  • Empfänger ordnet empfangene Segmente entsprechend ihrer Folgenummer
  • Duplikate werden ignoriert

Socket-Schnittstelle

  • De-facto-Standard für TCP/IP Programmierschnittstelle
  • Zugang zu TCP, UDP und (eingeschränkt) IP
  • Unterstützung verschiedener Protokolle
  • Protocol familiy
  • Address familiy
  • Abstraktion für Kommunikationsendpunkte
  • sockets

… mit verschiedenen Kommunikationseigenschaften

  • socket types (stream socket, datagram socket)
  • Benennung/Adressierung von Kommunikations-endpunkten
  • name binding
  • Können benutzt werden wie Dateideskriptoren

Verbindungen und Verbindungsendpunkte

  • Eine TCP-Verbindung wird durch ein Paar von Adressen und Port-Nummern identifiziert (Verbindungsendpunkte):
  • IP-Adresse und Port-Nummer Host A
  • IP-Adresse und Port-Nummer Host B
  • Jede Verbindung wird durch ein Paar von Verbindungsendpunkten eindeutig identifiziert
  • mehrere Verbindung zwischen den gleichen Hosts sind dadurch gleichzeitig möglich

Segmente, Datenströme und Sequenznummern

  • Erhaltung der Reihenfolge
  • Nummerierung:
  • Zufallszahl auf beiden Seiten (32 Bit)
  • Seq.nr. := Initiale Seq.nr. + Byte-Position im Datenstrom
  • TCP betrachtet einen Datenstrom als Sequenz von Bytes, die für die Übertragung in TCP-Segmente eingeteilt werden
  • Jedes Segment wird dann in der Regel auf ein IP-Paket abgebildet
  • Größe eines Segmentes bei lokaler Übertragung gemäß physikalischem Netz (MTU)
  • Ist diese nicht angegeben oder kann sie nicht ermittelt werden, dann wird ein Standartwert von 536 Bytes verwandt

Allgemeines

TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex, welche die Übertragung der Informationen in beide Richtungen zulässt, analog zu einem Telefongespräch

  • Diese Verbindung kann auch als zwei Halbduplexverbindungen, bei denen Informationen in beide Richtungen (allerdings nicht gleichzeitig) fließen können, betrachtet werden
  • Die Daten in Gegenrichtung können dabei zusätzliche Steuerungsinformationen enthalten
  • Die Verwaltung dieser Verbindung sowie die Datenübertragung werden von der TCP-Software übernommen
  • Die TCP-Software ist üblicherweise im Netz-Protokollstack des Betriebssystems angesiedelt
  • Anwendungsprogramme benutzen eine Schnittstelle dazu, meist Sockets, die sich (je nach Betriebssystem unterschiedlich) beispielsweise bei Microsoft Windows in extra einzubindenden Programmbibliotheken („Winsock.dll“ bzw. „wsock32.dll“) befinden. Linux und viele andere unixoide Betriebssysteme enthalten einen Socketlayer im Betriebssystemkern
  • Auf den Socketlayer wird über Systemaufrufe zugegriffen
  • Anwendungen, die TCP häufig nutzen, sind zum Beispiel Webbrowser und Webserver

Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert

  • Ein Endpunkt stellt ein geordnetes Paar dar, bestehend aus IP-Adresse und Port
  • Ein solches Paar bildet eine bidirektionale Software-Schnittstelle und wird auch als Socket bezeichnet
  • Somit wird eine TCP-Verbindung durch vier Werte (einem Quadrupel) identifiziert:
(Lokaler Rechner, Lokaler Port, Entfernter Rechner, Entfernter Port)

Dabei kommt es auf das gesamte Quadrupel an

  • Beispielsweise können zwei verschiedene Prozesse auf demselben Rechner denselben lokalen Port benutzen und dabei sogar mit demselben Rechner auf der gegenüberliegenden Seite kommunizieren, sofern die beteiligten Prozesse auf der anderen Seite unterschiedliche Ports benutzen
  • In einem solchen Fall würde es sich um zwei verschiedene Verbindungen handeln, deren Quadrupel sich nur in einem von vier Werten unterscheidet: dem Port auf der gegenüberliegenden Seite
Verbindung 1: (Lokaler Rechner, Port x, Entfernter Rechner, Port y)
Verbindung 2: (Lokaler Rechner, Port x, Entfernter Rechner, Port z)

Ein Serverprozess erzeugt beispielsweise einen Socket (socket bind) auf Port 80, markiert diesen für eingehende Verbindungen (listen) und fordert vom Betriebssystem die nächste anstehende Verbindung an (accept)

  • Diese Anforderung blockiert den Serverprozess zunächst, da noch keine Verbindung existiert
  • Kommt dann die erste Verbindungsanfrage durch einen Client an, wird sie vom Betriebssystem angenommen, so dass die Verbindung zustande kommt
  • Ab jetzt wird diese Verbindung durch das oben beschriebene Quadrupel identifiziert

Schließlich wird der Serverprozess aufgeweckt und ihm ein Handle für diese Verbindung überreicht. Üblicherweise startet der Serverprozess anschließend einen Kindprozess, zu dem er die Behandlung der Verbindung delegiert

  • Er selbst setzt dann seine Arbeit mit einer weiteren Accept-Anforderung an das Betriebssystem fort

Dadurch ist es möglich, dass ein Webserver mehrere Verbindungen von verschiedenen Rechnern annehmen kann

  • Mehrfaches listen auf demselben Port ist nicht möglich. Üblicherweise bestimmt das Programm auf der Clientseite den Port nicht selbst, sondern lässt ihn sich vom Betriebssystem zuweisen

Ports sind 16-Bit-Zahlen (Portnummern) und reichen von 0 bis 65535

  • Ports von 0 bis 1023 sind reserviert (Well Known Ports und werden von der IANA vergeben, z. B. ist Port 80 für das im WWW verwendete HTTP reserviert
  • Das Benutzen der vordefinierten Ports ist nicht bindend
  • So kann jeder Administrator beispielsweise einen FTP-Server (normalerweise Port 21) auch auf einem beliebigen anderen Port laufen lassen

Datenintegrität und Zuverlässigkeit

Im Gegensatz zum verbindungslosen UDP implementiert TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten

  • Das darunterliegende Protokoll (IP) ist paketorientiert, wobei Datenpakete verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können
  • TCP wurde entwickelt, um mit der Unsicherheit der darunterliegenden Schichten umzugehen
  • Es prüft daher die Integrität der Daten mittels der Prüfsumme im Paketkopf und stellt die Reihenfolge durch Sequenznummern sicher
  • Der Sender wiederholt das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne (Timeout) eintrifft
  • Die Daten der Pakete werden beim Empfänger in einem Puffer in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen

Der Datentransfer kann selbstverständlich jederzeit nach dem „Aufbau einer Verbindung“ gestört, verzögert oder ganz unterbrochen werden

  • Das Übertragungssystem läuft dann in einen Timeout
  • Der vorab getätigte „Verbindungsaufbau“ stellt also keinerlei Gewähr für eine nachfolgende, dauerhaft gesicherte Übertragung dar

Bestätigungen

Die jeweilige Länge des Puffers, bis zu der keine Lücke im Datenstrom existiert, wird bestätigt (windowing)

  • Dadurch ist das Ausnutzen der Netz-Bandbreite auch bei großen Strecken möglich
  • Bei einer Übersee- oder Satellitenverbindung dauert das Eintreffen des ersten ACK-Signals aus technischen Gründen bisweilen mehrere 100 Millisekunden, in dieser Zeit können unter Umständen mehrere hundert Pakete gesendet werden
  • Der Sender kann den Empfängerpuffer füllen, bevor die erste Bestätigung eintrifft
  • Alle Pakete im Puffer können gemeinsam bestätigt werden
  • Bestätigungen können zusätzlich zu den Daten in den TCP-Header des entgegengesetzten Datenstroms eingefügt werden (piggybacking), falls der Empfänger ebenfalls Daten für den Sender bereithält


Anhang

Siehe auch

Dokumentation

RFC

RFC Titel
793 Transmission Control Protocol
107 Berechnen der Prüfsumme für IP, UDP und TCP
1122 Fehlerbehebungen bei TCP
1323 Erweiterungen bei TCP
2018 TCP SACK – Selective Acknowledgment Options
3168 Explicit Congestion Notification
54829 TCP User Timeout Option
5681 TCP Congestion Control – TCP-Überlastkontrolle
7414 Übersicht zu TCP RFCs
7323 2014

Links

Weblinks

  1. Congestion Avoidance and Control
  2. Warriors of the net (Film zu TCP)
Abgerufen von „https://wiki.foxtom.de/index.php?title=Transmission_Control_Protocol&oldid=92318“