• Transmission Control Protocol (TCP)

(1)

Grundlagen der Rechnernetze

Transportschicht

(2)

Übersicht

• Einfacher Demultiplexer (UDP)

• Transmission Control Protocol (TCP)

– Verbindungsauf‐ und abbau

– Flusskontrolle mittels Sliding‐Window‐Verfahren – Regulärer Duplexbetrieb inklusive Flusskontrolle – Adaptive Reübertragungen

– Erweiterungen – Überlastkontrolle

– Überlastvermeidung

– Implementationsvarianten

(3)

Einfacher Demultiplexer (UDP)

(4)

Demultiplexing aber sonst keine weitere Funktionalität über IP

UDP

Prozess 1 Prozess 2 Prozess 3

Ankommende Pakete Queues

Demultiplexing mittels

Portnummern Prozess

IP‐Paket

Quelle: 192.100.120.40 Ziel: 192.200.133.100 Daten: UDP‐Paket

Data

SrcPort DstPort Length Checksum

Sender‐Host Empfänger‐Host

Port‐Nummern sind 16 Bits lang.

Damit gibt es 2¹⁶ = 65536 unterschiedliche Ports.

Global eindeutige

Adresse eines Prozesses:

<Port,Host>

Prozess arbeitet blockierend die Queue per FiFo ab.

Nachrichten werden bei voller Queue verworfen.

Nachrichtengröße ist durch maximale

(5)

und ggf. noch eine Checksumme

Fehlererkennung mittels Checksumme

[vgl. RFC 768 zu UDP und RFC 2460 zu IPv6]

• optional in IPv4 und verpflichtend in IPv6

• Gleicher Checksummenalgorithmus wie bei IP (Addition von 16‐Bit‐Worten mittels

Einerkomplementarithmetik)

• Eingabe ist der UDP‐Header und ein Pseudo‐Header Pseudo‐Header

• Source‐IP‐Adresse und Destination‐IP‐Adresse

• Protokollnummer (IPv4: protocol, IPv6: next header)

• plus UDP‐Längen‐Feld (UDP‐header und Daten) [damit wird UDP‐Längen‐Feld zwei mal addiert]

Pseudoheader ermöglicht einen einfachen Test, dass die Nachricht zwischen den richtigen End‐Punkten

ausgeliefert wurde.

[bei Änderung der IP‐Adresse währen der Auslieferung ist damit falsches Ziel ist erkennbar (sofern die

Checksumme nicht angepasst wurde)]

Data

source address destination address

zero protocol UDP length

source address

zero

destination address

Data

next h.

Pseudo Header unter IPv6 für Upper Layer Checksums Pseudo Header für UDP unter IPv4

upper layer packet length

(6)

Festlegung von Port‐Nummern

Gemäß RFC 6335 gibt es drei Kategorien von Portnummern

• 0 bis 1023 (System Ports) und 1024 bis 49151 (User Ports) – Zuweisung durch die Internet Assigned Numbers Authority (IANA, www.iana.org);

System und User Ports unterscheiden sich in der strenge der Registrierungsprozeduren

• 49152 bis 65 535 (Dynamic Ports) – können einfach von jedem Dienst ad hoc

verwendet werden. Ports werden zugewiesen, wenn eine Sitzung eingerichtet wird, und freigegeben, wenn die Sitzung endet.

Ports 0 bis 1023 (System Ports) umfassen die gängigen Protokolle und Diensten.

Zum Beispiel Port 21 für FTP File‐Server, Port 22 für SSH Remote Login, Port 25 für SMTP Mail‐Server, Port 53 für DNS Domain Name Server, Port 80 für HTTP Web‐Server, usw.

Ein bekannter Port aus der Kategorie 1024 bis 49151 (User Ports): Port 8080 WWW Caching Service.

Wo findet man vorab festgelegte Ports?

z.B. im Web unter

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml Unter vielen Unix‐Systemen unter /etc/servicesz.B.

less /etc/services

(7)

Festlegung von Port‐Nummern

Manchmal ist ein bekannter Port nur der Ausgangspunkt für die Kommunikation:

• Kontaktanfrage des Clients über bekannten Port

• nach dem ersten Kontakt wird ein privater Port für deren Session ausgemacht

• Der bekannte Port steht dann neuen Client‐Anfragen wieder zur Verfügung

Eine Frage bleibt noch: wo findest man im Falle von Dynamic Port den Port eines Dienstes?

Lösung: Port‐Mapper:

• ein festgelegter Port über den man den Port‐Mapper anspricht

• Client fragt erst den Port‐Mapper nach dem richtigen Port für einen bestimmten Dienst

• Der rückgegebene Port wird dann für die Kontaktierung des eigentlichen Services verwendet

Client Port‐Mapper

Server

Host 1 Host 2

(8)

Ergänzung : NAPT als Lösung für IPv4

Erinnerung: Network‐Address‐Translation (NAT): Lokalen Hosts werden temporär globale Adressen zugeordnet.

Problem: NAT‐Box braucht aber immer so viele IP‐Adressen, wie viele interne Hosts simultan auf das Internet zugreifen wollen.

Bessere Lösung: Network Address Port Translation (NAPT)

Lokales Netz

NAT‐Box

Verfügbare eindeutige globale Adressen:

171.69.210.246, ..., 171.69.210.252 Lokal eindeutige

Adresse:

10.0.1.5 H

IP‐Paket:

Quelle: 10.0.1.5

IP‐Paket:

Quelle: 171.69.210.246 Ins Internet

IP‐Paket:

Ziel: 10.0.1.5

IP‐Paket:

Ziel: 171.69.210.246

(9)

Ergänzung : NAPT als Lösung für IPv4

Damit: verwende nur eine globale IP‐Adresse (hier z.B. 203.0.113.1) und unterscheide die simultanen Zugriffe interner Hosts auf das Internet durch übergangsweisen Austausch der der Source‐Port‐Nummern.

Src IP: 192.168.1.2

Beispiel aus Fall/Stevens, TCP/IP Illustrated, Volume 1, Second Edition, The Protocols, S.305 Src Port: 23479

Src IP: 192.168.1.35 Src Port: 23479

Src IP: 192.168.17.4 Src Port: 34011

Src IP: 203.0.113.1 Src Port: 23479

Src IP: 203.0.113.2 Src Port: 23479

Src IP: 203.0.113.3 Src Port: 34011

NAT

Src IP: 203.0.113.1 Src Port: 23479

Src IP: 203.0.113.1 Src Port: 3000

Src IP: 203.0.113.1 Src Port: 34011

NAPT

Src IP: 192.168.1.2 Src Port: 23479

Src IP: 192.168.1.35 Src Port: 23479

Src IP: 192.168.17.4 Src Port: 34011

(10)

Transmission Control Protocol (TCP)

(11)

Übersicht

Anwendungsprozess A

TCP Sende‐

puffer

Anwendungsprozess B

TCP Empfangs‐

puffer

…

schreibe Bytes

lese

Bytes …

Segment Segment

… lese

Bytes

Empfangs‐

puffer

Sende‐

puffer

IP IP

Segment Segment Segment Segment

(12)

Übersicht

Anwendungsprozess A

TCP Sende‐

puffer

Anwendungsprozess B

TCP Empfangs‐

puffer

…

lese

Bytes …

Segment Segment

… lese

Bytes

Empfangs‐

puffer

Sende‐

puffer

IP IP

Segment Segment Segment Segment

Grundfunktion

•

Zuverlässige Auslieferung

•

eines Full‐Duplex

•

Byte‐Streams in

•

korrekter Reihenfolge Darüber hinaus:

•

Flusskontrolle (vermeidet, dass Sender den Empfänger überlastet)

•

Lastkontrolle (vermeidet, dass

Sender zu viel Last im Netz erzeugt) Wie auch bei UDP:

•

Port‐Mechanismus

(gleiche Diskussion wie bei UDP)

(13)

Segmentnummerierung und ACKs

Initiale Sequenznummer im Beispiel: 1999 Byte‐Stream

…

Segment 1 Bytes:

0…1023 Sequenz‐

nummer:

2000

Segment 2 Bytes:

1024…2047 Sequenz‐

nummer:

3024

Segment 3 Bytes:

2048…5000 Sequenz‐

nummer:

4028

Sender Empfänger Daten (SequenceNum)

Acknowledgment (SequenceNum+1) Bestätigt wird immer das

nächste erwartete Byte

• Sequenznummern zeigen (modulo maximale Sequenznummer 2³²) auf Byte‐Positionen im Byte‐Stream

• In der Regel ist das Acknowledgement Teil eines TCP‐Segmentes in die Rückrichtung

(14)

Segmentstruktur

Octet 0 1 2 3

Bit 0 1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031

0 0 Source Port Destination Port

4 32 Sequence Number

8 64 Acknowledgement Number (if ACK set)

12 96 HdrLen Rsrved 0 0 0

N S

C W

R E C E

U R G

A C K

P S H

R S T

S Y N

F I N

Advertised Window

16 128 Checksum Urgent Pointer (if URG set) 20

…

160

…

Options (if HdrLen > 5)

(Padded at end with 0‐Bytes if necessary)

Data

(15)

Transmission Control Protocol (TCP)

Verbindungsaufbau und ‐abbau

(16)

Übersicht

Herstellen eine TCP‐Verbindung

• Client (Anrufer) führ ein Active‐Open für einen Server durch

• Der Server muss zuvor ein passives Öffnen durchgeführt haben

• Die Verbindung wird dann über einen Dreiwege‐Handshake hergestellt

• (Bemerkung: das ist der Regelfall. TCP ermöglicht aber auch gleichzeitiges aktives Öffnen von beiden Seiten)

Erst nach erfolgreichem Ablauf des Verbindungsaufbau beginnen beide Seiten mit dem Senden von Daten.

Abbau einer TCP‐Verbindung

• Sobald ein Teilnehmer mit dem Senden von Daten fertig ist, schließt er eine Richtung der Verbindung

• TCP initiier damit eine Sequenz von Control‐Nachrichten

Der Verbindungsaufbau ist zwar (in der Regel) asymmetrisch, der Verbindungsabbau ist jedoch symmetrisch (jede Seite muss die Verbindung unabhängig schließen).

Es ist möglich, dass eine Seite die Verbindung schon beendet , was bedeutet, dass sie keine Daten mehr senden kann, während die andere Seite die andere Hälfte der

bidirektionalen Verbindung offen hält und weiterhin Daten sendet.

(17)

Dreiwege‐Handshake

Client (active open)

Server (passive open)

Data Checksum

HdrLen 0 Flags

Options (variabel)

UrgPtr

AdvertisedWindow Acknowledgement

SequenceNum

SrcPort DstPort

U R G

A C K

P S H

R S T

S Y N

F I N 0 4 10 16 31

Dreiwege‐Handshake generell: zwei Parteien wollen sich auf eine Reihe von Parametern einigen. Speziell bei TCP:

• Festlegen einer initialen zufälligen Sequenznummer für beide Kommunikationsrichtungen

• Diese wird jeweils bestätigt (Server‐>Client: SYN+ACK, Client‐>Server: ACK)

• Bestätigt wird das erste erwartete Byte an der Stelle Sequenznummer+1

• Bei Ausbleiben einer Bestätigung findet eine Reübertragung statt

(18)

Dreiwege‐Handshake

Client (active open)

Server (passive open)

Data Checksum

HdrLen 0 Flags

Options (variabel)

UrgPtr

AdvertisedWindow Acknowledgement

SequenceNum

SrcPort DstPort

U R G

A C K

P S H

R S T

S Y N

F I N 0 4 10 16 31

Warum nicht einfach am Anfang auf 0 setzen?

Der Grund dafür ist der Schutz vor verzögert eintreffenden Nachrichten einer alten Inkarnationen derselben Verbindung (SrcPort, SrcIPAddr, DstPort, DstIPAddr)

(19)

TCP‐Zustandsübergangsdiagramm

Verbindungsaufbau

Datenübertragungsphase

Verbindungsabbau

Bildquelle: en.wikipedia.org/wiki/Transmission_Control_Protocol

(20)

Typischer Ablauf

• Server im Listen‐State

• Client führt Active‐Open aus Darstellung als MSC:

Verbindungsaufbau im Detail

(21)

Drei mögliche Fälle:

1. Diese Seite beendet zuerst

2. Die andere Seite beendet zuerst 3. Beide Seiten beenden gleichzeitig Darstellung von Fall 1 als MSC:

Verbindungsabbau im Detail

(22)

Transmission Control Protocol (TCP)

Flusskontrolle mittels Sliding‐Window‐Verfahren

(23)

Sliding‐Window

Das Herzstück von TCP ist ein Sliding‐Window‐Verfahren.

Entscheidender Unterschied zu Sliding‐Window‐Verfahren auf der

Verbindungsebene: bei TCP läuft dieses Ende‐zu‐Ende über das Internet und nicht über eine physische Punkt‐zu‐Punkt‐Verbindung. Hieraus ergeben sich die folgenden Konsequenzen:

•

Es braucht einen expliziten Mechanismus zum Verbindungsaufbau

•

Round‐Trip Zeiten sind sehr variabel (z.B. im Spektrum von wenigen ms bis mehrere 100 ms)

•

Pakete können in unterschiedlicher Reihenfolge am Empfänger ankommen;

d.h. wesentlich ältere Pakete können plötzlich auftauchen (konservative Schätzung maximale Lebenszeit (maximum segment lifetime MSL) eines IP‐

Paketes: 120 Sekunden)

•

das Verfahren muss ein breites Spektrum an Rechen‐ und Speicherkapazitäten erlauben

•

das Delay‐Bandbreitenprodukt ist sehr variabel

•

die verfügbaren Ressourcen im Netz sind nicht bekannt

(24)

Sende‐ und Empfangspuffer

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

Empfangende Anwendung

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Sendepuffer

noch nicht bestätigte gesendete Daten und neue zu sendende Daten der darüber

liegenden Schicht

Empfangspuffer

schon empfangene Daten (unter Umständen mit fehlenden Datenabschnitten), die noch nicht von der darüber liegenden Schicht gelesen wurden

(25)

Zusammenhang der einzelnen Pointer

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Sendepuffer

• LastByteAcked <= LastByteSent

• LastByteSent <= LastByteWritten

Empfangspuffer

• LastByteRead < NextByteExpected

• NextByteExpected <= LastByteRcvd+1 NextByteExpected zeigt auf das erste noch nicht empfange Byte. Alle vorigen Bytes wurden vollständig empfangen.

Achtung: wir ignorieren hier Wraparound der Pointer aufgrund von endlicher Bitanzahl zur Speicherung von Segmentnummern (32 Bit).

(26)

Größe des Sende‐ und Empfangspuffer

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Sendepuffer

verwendeter Pufferspeicher =

LastByteWritten ‐ LastByteAcked Diese Größe muss immer kleiner gleich MaxSendBuffer sein.

Empfangspuffer

verwendeter Pufferspeicher = LastByteRcvd ‐ LastByteRead

Diese Größe muss immer kleiner gleich MaxRcvBuffer sein.

(27)

Definition des AdvertisedWindow

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Empfänger teilt dem Sender seine festgelegte Größe des Empfangspuffers durch das AdvertisedWindow mit. Dies legt die maximale erlaubte Anzahl weiteren noch

versendbaren noch nicht bestätigten Bytes fest.

Auf Empfängerseite muss immer gelten: LastByteRcvd ‐ LastByteRead <= MaxRcvBuffer Das AdvertisedWindow wird demnach wie folgt festgelegt:

AdvertisedWindow = MaxRcvBuffer ‐ ((NextByteExpected ‐ 1) ‐ LastByteRead)

(28)

Definition des EffectiveWindow

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Auf der Senderseite muss immer sicher gestellt sein:

LastByteSent ‐ LastByteAcked <= AdvertisedWindow

Das EffectiveWindow, d.h. die Anzahl an noch versebaren Bytes, ist dann wir folgt:

EffectiveWindow = AdvertisedWindow ‐ (LastByteSent ‐ LastByteAcked)