TCP

Vorlesung: Netzwerke (TK) WS 2009/10
Kapitel 5 Ende-zu-Ende-Protokolle
Session 15
Prof. Dr. Michael Massoth
[Stand: 07.01.2009]
Copyright: © Michael Massoth
15 - 1
Netzwerke, WS 2009/10
15 - 2
ACHTUNG:
Testat_3
am Mittwoch, den 13.01.2010







Referenzmodelle (OSI, Hybrid, TCP/IP)
Hardware-Bausteine bzw. Kopplungselemente
Strukturierte Verkabelung
Ethernet (inkl. CSMA/CD) und WLAN
Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN)
Internetworking (inkl. IPv4-Adressierung und Subnetting, IPv6)
Ende-zu-Ende-Protokolle (UDP + TCP)
Copyright: © Michael Massoth
15 - 2
Netzwerke, WS 2009/10
15 - 3
ACHTUNG:
Testat_4
am Mittwoch, den 20.01.2009







Referenzmodelle (OSI, Hybrid, TCP/IP)
Hardware-Bausteine bzw. Kopplungselemente
Strukturierte Verkabelung
Ethernet (inkl. CSMA/CD) und WLAN
Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN)
Internetworking (inkl. IPv4-Adressierung und Subnetting, IPv6)
Ende-zu-Ende-Protokolle (UDP + TCP)
Copyright: © Michael Massoth
15 - 3
Netzwerke, WS 2009/10
15 - 4
ACHTUNG:
Testat_5
am Donnerstag, den 21.01.2009







Referenzmodelle (OSI, Hybrid, TCP/IP)
Hardware-Bausteine bzw. Kopplungselemente
Strukturierte Verkabelung
Ethernet (inkl. CSMA/CD) und WLAN
Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN)
Internetworking (inkl. IPv4-Adressierung und Subnetting, IPv6)
Ende-zu-Ende-Protokolle (UDP + TCP)
Copyright: © Michael Massoth
15 - 4
Netzwerke, WS 2009/10
15 - 9
Lernziele heute:
Transmission Control Protocol (TCP)  Teil 2
 Lernziele im Detail:
 TCP als zuverlässiges Byte-Strom-Protokoll verstehen, erklären und
anwenden können
 TCP Verbindungsaufbau und -abbau verstehen und erklären können
 TCP Zustandsübergangsdiagramm (wenn vorgegeben !!!) verstehen,
interpretieren und erklären können
Copyright: © Michael Massoth
15 - 9
Netzwerke, WS 2009/10
15 - 10
TCP
[Transmission Control Protocol ]




TCP-Segmentstruktur
Verbindungsorientierter Transport (1): Verbindungsaufbau
Verbindungsorientierter Transport (2): Verbindungsabbau
TCP-Verbindungsmanagement
Copyright: © Michael Massoth
15 - 10
Netzwerke, WS 2009/10
TCP-Multiplexmechanismus
15 - 11
 Bedeutung:
 Macht Koexistenz vieler höherer Protokolle und Anwendungsprozesse
in einem Rechner möglich  Prozessmultiplexing
 Zudem kann TCP von vielen Anwendungsprozessen eines höheren
Protokolls genutzt werden
 Ansatz:
 Zur Identifikation der verschiedenen Datenströme vergibt TCP in
jedem Rechner Port-Nummern.
 Über diese Port-Nummern erfolgt der gesamte Datenaustausch
zwischen den Anwendungsprozessen und dem TCP
 Vergabe der Port-Nummern in einem Rechner erfolgt dynamisch und
wahlfrei
 Für häufig genutzte Anwendungsprozesse sind feste Port-Nummern
vergeben  z.B. FTP=20, Telnet=23, SMTP=25, HTTP=80,
Rlogin=513
Copyright: © Michael Massoth
15 - 11
Netzwerke, WS 2009/10
TCP-Verbindungsmanagement (1)
15 - 12
Fette Linie =
normaler Pfad des Clients
Fette gestrichelte Linie =
normaler Pfad des Servers
Feine Linie =
ungewöhnliche Ereignisse
Jeder Übergang wird
durch das Ereignis
bezeichnet, das ihn
verursacht, sowie durch die
daraus resultierenden
Aktionen (getrennt durch
einen Schrägstrich „/“ )
 Ereignis/Aktionen
Copyright: © Michael Massoth
15 - 12
Netzwerke, WS 2009/10
TCP-Verbindungsmanagement (2)
15 - 13
Zustand
Beschreibung
CLOSED
Keine Verbindung aktiv oder anstehend
LISTEN
Der Server wartet auf eine ankommende Verbindungsanfrage
SYN RCVD
Eine Verbindungsanfrage ist angekommen. Warten auf
Bestätigung.
SYN SENT
Die Anwendung hat begonnen, eine Verbindung zu öffnen.
ESTABLISHED
Zustand der normalen Datenübertragung
FIN WAIT 1
Die Anwendung möchte die Übertragung beenden.
FIN WAIT 2
Die andere Seite ist einverstanden, die Verbindung abzubauen.
TIMED WAIT
Warten bis keine TCP-Segmente mehr kommen.
CLOSING
Beide Seiten haben gleichzeitig versucht, zu beenden.
CLOSE WAIT
Die Gegenseite hat die Verbindungsfreigabe eingeleitet.
LAST ACK
Warten, bis keine TCP-Segmente mehr kommen.
Copyright: © Michael Massoth
15 - 13
Netzwerke, WS 2009/10
TCP Client Lifecycle
15 - 14
TCP Client
Copyright: © Michael Massoth
15 - 14
Netzwerke, WS 2009/10
TCP Client Lebenszyklus
15 - 15
Typische Abfolge von
TCP-Zuständen eines
TCP Clients
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.39]
Copyright: © Michael Massoth
15 - 15
Netzwerke, WS 2009/10
TCP Server Lifecycle
15 - 16
TCP Server
Copyright: © Michael Massoth
15 - 16
Netzwerke, WS 2009/10
TCP Server Lebenszyklus
15 - 17
Typische Abfolge von
TCP-Zuständen, die
ein serverseitiges
TCP durchläuft
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.40]
Copyright: © Michael Massoth
15 - 17
Netzwerke, WS 2009/10
TCP State Diagram: Connection Setup
15 - 18
Client
CLOSED
active OPEN
create TCB
Snd SYN
Server
passive OPEN
CLOSE
delete TCB
create TCB
CLOSE
delete TCB
LISTEN
SYN
RCVD
SEND
snd SYN
rcv SYN
snd SYN ACK
rcv SYN
snd ACK
SYN
SENT
Rcv SYN, ACK
rcv ACK of SYN
Snd ACK
CLOSE
Send FIN
Copyright: © Michael Massoth
ESTAB
15 - 18
Netzwerke, WS 2009/10
TCP State Diagram: Connection Teardown
CLOSE
send FIN
FIN
WAIT-1
ACK
FIN WAIT-2
Active Close ESTAB
CLOSE
send FIN
rcv FIN
Passive Close
send ACK
CLOSE
WAIT
rcv FIN
snd ACK
CLOSE
snd FIN
rcv FIN+ACK
snd ACK CLOSING
LAST-ACK
rcv ACK of FIN
rcv FIN
snd ACK
Copyright: © Michael Massoth
15 - 19
rcv ACK of FIN
TIME WAIT
CLOSED
Timeout=2msl
delete TCB
15 - 19
Netzwerke, WS 2009/10
TCP Connection Teardown
15 - 20
 Auf beiden Seiten gibt es drei mögliche Kombinationen von
Übergängen, um eine Verbindung vom ESTABLISHED- in den
CLOSED-Zustand zu versetzen:
 Die eine Seite schließt zuerst:
ESTABLISHED  FIN_WAIT_1  FIN_WAIT_2  TIME_WAIT
 CLOSED
 Die andere Seite schließt zuerst:
ESTABLISHED  CLOSE_WAIT  LAST_ACK  CLOSED
 Beide Seiten schließen gleichzeitig:
ESTABLISHED  FIN_WAIT_1  CLOSING TIME_WAIT 
CLOSED
Copyright: © Michael Massoth
15 - 20
Netzwerke, WS 2009/10
TCP Zustandsübergangsdiagramm
Erklärung:
CLOSED
Active open
Passive open
/SYN
Close

Close
LISTEN
SYN_RCVD
SYN/SYN + ACK
Send /SYN
SYN/SYN + ACK
ACK

FIN/ACK
FIN_WAIT_1
CLOSE_WAIT
AC
K

SYN + ACK/ACK
Close/FIN
ACK
SYN_SENT
ESTABLISHED
Close/FIN
15 - 21
Jede Box bezeichnet
einen Zustand, in dem
sich ein Ende einer
TCP-Verbindung
befinden kann
Alle Verbindungen
beginnen mit dem
Zustand CLOSED
Jeder Pfeil ist mit einer
Bezeichnung in der
Form Ereignis/Aktion
beschriftet
FIN/ACK
+
Close/FIN
FI
FIN_WAIT_2
N
/A
C
K
FIN/ACK
Copyright: © Michael Massoth
CLOSING
LAST_ACK
ACK Timeout after two
segment lifetimes
TIME_WAIT
ACK
CLOSED
15 - 21
Netzwerke, WS 2009/10
TCP for Client-Server Communication
15 - 22
 TCP is a connection-oriented protocol for client-server
communication:
Main
Thread of
Server
Process
Server
socket
Three-way
handshake
Client
Process
Client
socket
Copyright: © Michael Massoth
New
Thread of
Server
Process
Internet
Data
15 - 22
New
socket
Netzwerke, WS 2009/10
Adressierung
Portnummer
Application
15 - 23
80 für HTTP, 25 für SMTP
Sockets
ID Transportprotokoll
IP-Adresse
Transport
6 für TCP, 17 für UDP
Network
172.17.5.xx Labor-PC
Treiber
MAC-Adresse
Data Link
00:03:6C:1C:56:96
Physical
Copyright: © Michael Massoth
15 - 23
Netzwerke, WS 2009/10
Sockets
15 - 24
Ein Socket ist die Kombination von
einer IP-Adresse und einem Port
Computer B
Computer A
Requests to Destination Port 23
Source Port = 2500
Destination Port = 2500
Source Port = 23
Austausch der Quell- und Ziel-Sockets
Copyright: © Michael Massoth
15 - 24
Netzwerke, WS 2009/10
Port, Socket und eindeutige TCP-Verbindung
15 - 25
 Port:
 Eindeutige Zuordnung der TCP-Pakete zur nächsthöheren
Schicht bzw. zum Anwendungsprozess)
 Socket:
 Eindeutige Adresse einer TCP-Verbindung, zusammengesetzt aus
IP-Adresse und Port-Nummer
 Eindeutige TCP-Verbindung:
 4-Tupel aus [Sender IP-Adresse, Sender Port-Nummer,
Empfänger IP-Adresse, Empfänger Port-Nummer]  oder mit
anderen Worten {Sender-Socket, Empfänger-Socket}
Copyright: © Michael Massoth
15 - 25
Netzwerke, WS 2009/10
15 - 26
TCP
[Transmission Control Protocol ]





TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
Copyright: © Michael Massoth
15 - 26
Netzwerke, WS 2009/10
TCP ist ein Byte-orientiertes Protokoll
Application process
Application process
Write
Read
bytes
bytes
TCP
TCP
Send buffer
Receive buffer
Segment
Segment
■■■
Segment
Transmit segments
15 - 27
 Der Sender schreibt Bytes in
eine TCP-Verbindung, der
Empfänger liest sie aus
 TCP puffert am Quell-Host
ausreichend Bytes vom
sendenden Prozess, bis ein
Paket (=Segment) einer
angemessenen Größe
zusammenkommt
 Dann sendet TCP dieses
Segment an seinen Partner
auf dem Ziel-Host
 Merke: TCP ist ein zuverlässiges Byte-orientiertes Protokoll.
 Kein nachrichtenorientiertes Protokoll  Anfrage/AntwortAnwendungen (Client/Server, Request/Response) tauschen immer
Nachrichten aus!
Copyright: © Michael Massoth
15 - 27
Netzwerke, WS 2009/10
Sequenznummer eines TCP-Segments (1)
15 - 28
Merke: Die Sequenznummer eines TCP-Segments ist die
Bytestromnummer des ersten Bytes im Segment.
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.29]
Copyright: © Michael Massoth
15 - 28
Netzwerke, WS 2009/10
Sequenznummer eines TCP-Segments (2)
15 - 29
Beispiel für die Aufteilung der Daten einer Datei in TCP-Segemente:
 Annahme: Datei mit 500.000 Byte, MSS = 1.000 Byte, Start-Seqnum = 0
 Aufteilung der TCP-Segmente: Dem ersten TCP-Segment wird die
Seqnum = 0, dem zweiten TCP-Segment die Seqnum = 1.000, dem dritten
TCP-Segment die Seqnum = 2.000, usw. zugewiesen.
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.29]
Copyright: © Michael Massoth
15 - 29
Netzwerke, WS 2009/10
TCP Sequenznummern (1)
15 - 30
 TCP Sequenznummern:
 Jedes gesendete TCP-Byte hat eine Sequenzfolgenummer (kurz:
Sequenznummer).
 Merke: Sequenz- und Quittungsnummern beziehen sich auf Bytes!
 Die Start-Sequenznummer (ISN) wird beim Verbindungsaufbau
durch das Betriebssystem bestimmt (Three Way Handshake)
Copyright: © Michael Massoth
15 - 30
Netzwerke, WS 2009/10
TCP Sequenznummern (2)
15 - 31
 TCP Sequenznummern:
 Merke: Die Sequenznummer eines TCP-Segments ist die
Bytestromnummer des ersten Bytes im Segment.
 Mit anderen Worten: Als Sequenznummer im TCP-Header wird
das erste Daten-Byte in diesem Segment gesetzt. Falls SYN = 1
gesetzt ist, dann handelt es sich um die ISN (engl. Initial Sequenz
Number), das erste Datenbyte hat dann die Nummer ISN + 1
 Das erste Daten-Byte, gleich hinter dem TCP-Header, hat die
niedrigste Sequenznummer innerhalb des TCP-Segments. Alle
nachfolgenden Daten-Bytes werden konsekutiv durchnummeriert.
Copyright: © Michael Massoth
15 - 31
Netzwerke, WS 2009/10
Telnet: Eine Fallstudie
15 - 32
Telnet: Eine Fallstudie für Sequenzund Bestätigungsnummern
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.30]
Copyright: © Michael Massoth
15 - 32
Netzwerke, WS 2009/10
TCP Bestätigungsnummern (1)
15 - 33
 TCP Bestätigungsnummern:
 Merke: Die Bestätigungsnummer, die Host B in sein Segment
einfügt, ist die Sequenznummer des nächsten Bytes, das Host B
von Host A erwartet.
 Als Quittungsnummer im TCP-Header wird gesetzt:
ACK-Nummer (von Host B) = fehlerfrei empfangene Seq-Nummer
(von Host A) + Größe der Nutzdaten in Byte
 TCP arbeitet mit positiven Quittungen, die Summenquittungen
darstellen (für die Menge erfolgreich übertragener Bytes)
Copyright: © Michael Massoth
15 - 33
Netzwerke, WS 2009/10
TCP Bestätigungsnummern (2)
15 - 34
 TCP Bestätigungsnummern:
 TCP arbeitet (i.d.R.) mit positiven Quittungen, die
Summenquittungen darstellen (für die Menge erfolgreich
übertragener Bytes)
 Da TCP Bytes nur bis zum ersten fehlenden bzw. erwarteten Byte
im Datenstrom bestätigt, sagt man, dass TCP kumulative
Bestätigungen verwendet.
 Bestätigungen für fehlerfrei empfangene Daten im Datentransfer
von Host A (Client)  Host B (Server), werden im Datenstrom von
Host B  Host A mitbefördert. Dies nennt man auch Huckepack
(engl. Piggyback)
Copyright: © Michael Massoth
15 - 34
Netzwerke, WS 2009/10
Erzeugung von Quittungen
15 - 35
TCP-Empfehlungen für die ACK-Erzeugung [RFC 1122, RFC 2581]
Ereignis
Aktion des TCP-Empfängers
Ankunft eines fehlerfreien TCP-Segments in der
richtigen Reihenfolge mit der erwarteten
Sequenznummer. Alle Daten bis zu dieser
erwarteten Sequenznummer sind bereits bestätigt.
Keine Lücke in den empfangenen Daten.
Verzögertes ACK; maximal 500 ms auf
Ankunft eines weiteren Segments in der
richtigen Reihenfolge warten. ACK senden,
falls das nächste erwartete Segment innerhalb
dieses Zeitintervalls nicht ankommt.
Ankunft eines fehlerfreien TCP-Segments in der
richtigen Reihenfolge mit der erwarteten
Sequenznummer. Ein weiteres vorher
empfangenes fehlerfreies Segment in der
richtigen Reihenfolge wurde noch nicht bestätigt.
Keine Lücke in den empfangenen Daten.
Sofort ein einzelnes kumulatives ACK
senden, um beide Segmente mit der richtigen
Reihenfolge zu bestätigen.
Ankunft eines fehlerfreien TCP-Segments außer
der Reihe mit einer höheren als der erwarteten
Sequenznummer. Lücke erkannt.
Sofort ein Duplikat-ACK mit Angabe der
Sequenznummer des nächsten erwarteten
Bytes senden.
Ankunft eines fehlerfreien TCP-Segments, das die
Lücke in den empfangenen Daten teilweise oder
vollständig füllt.
Sofort ein ACK senden, sofern dieses
Segment mit dem unteren Ende der Lücke
beginnt.
Copyright: © Michael Massoth
15 - 35
Netzwerke, WS 2009/10
Einige interessante Szenarien (1)
15 - 36
Neuübertragung aufgrund einer
verlorenen Bestätigung (ACK)
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.32]
Copyright: © Michael Massoth
15 - 36
Netzwerke, WS 2009/10
Einige interessante Szenarien (2)
15 - 37
TCP-Segment wird nicht
erneut übertragen, weil
seine Bestätigung vor
dem Timeout ankommt.
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.33]
Copyright: © Michael Massoth
15 - 37
Netzwerke, WS 2009/10
Einige interessante Szenarien (3)
15 - 38
Durch eine kumulative Bestätigung
wird die Neuübertragung des ersten
TCP-Segments vermieden.
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.34]
Copyright: © Michael Massoth
15 - 38
Netzwerke, WS 2009/10
15 - 39
TCP
[Transmission Control Protocol ]





TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
Copyright: © Michael Massoth
15 - 39
Netzwerke, WS 2009/10
15 - 40
Lernziele heute :
Zuverlässige Zustellung: Stop-and-Wait-Algorithmus und
Sliding Window (Grundlagen)
 Lernziele im Detail:
 Zuverlässige Zustellung verstehen und anwenden können
 Sliding-Window-Algorithmus für Sender und Empfänger mit
Variablenverwaltung verstehen und anwenden können
Copyright: © Michael Massoth
15 - 40
Netzwerke, WS 2009/10
Zwei Probleme aus der Praxis
15 - 41
 Problem 1: Fehlererkennung
 Weil TCP-Segmente während der Übertragung manchmal beschädigt
werden, müssen diese Fehler erkannt werden können.
 Problem 2: Zuverlässige Zustellung
 Da einige beim Zielknoten ankommende TCP-Segmente Fehler
enthalten können und daher verworfen werden, lautet die nächste
Aufgabe, wie solche Fehler behoben werden können.
 Das Ziel ist dabei, die Verbindungsleitung für höhere Schichten und
Anwendungen als zuverlässig erscheinen zu lassen.
Copyright: © Michael Massoth
15 - 41
Netzwerke, WS 2009/10
Zuverlässige Zustellung
15 - 43
 Frage: Wie können Pakete (oder genauer TCP-Segmente)
zuverlässig zugestellt werden? Welche prinzipiellen Methoden
können dabei eingesetzt werden?
[Frage ans Auditorium, Ideen an Tafel sammeln]
 Antworten:
 Quittungen  positive und/oder negative Bestätigungen,
Acknowledgements (ACKs)
 Zeitüberwachung  Timer, Timeout
 Sequenznummern
Copyright: © Michael Massoth
15 - 43
Netzwerke, WS 2009/10
Implizite Übertragungswiederholung
15 - 44
 Um verlorengegangene Pakete/Quittungen behandeln zu können, die
sonst einen weiteren Datenaustausch unterbinden würden, muss vom
Sender eine Zeitüberwachung durchgeführt werden (Time-out), nach der
eine erneute Übertragung erfolgt.
Sender
DL-Data.Req(p1)
Empfänger
P1,0
Zeitüberwachung
P1,0
ACK
DL-Data.Req(p2)
DL-Data.Ind(p1)
P2,1
ACK
DL-Data.Ind(p2)
Zeitüberwachung
Legende:
Daten,Folgenummer
P2,1
ACK
Als Duplikat erkannt!
Zeit
Copyright: © Michael Massoth
15 - 44
Netzwerke, WS 2009/10
1
Fehlerbehandlung: Go-back-N
DL-Data.Req(p1)
DL-Data.Req(p2)
DL-Data.Req(p3)
DL-Data.Req(p4)
DL-Data.Req(p5)
DL-Data.Req(p6)
p1
p2
p3
p4
p5
p6
p2
p3
p4
p5
p6
Copyright: © Michael Massoth
15 - 45
15 - 45
DL-Data.Ind(p1)
DL-Data.Ind(p2)
DL-Data.Ind(p3)
DL-Data.Ind(p4)
DL-Data.Ind(p5)
DL-Data.Ind(p6)
Netzwerke, WS 2009/10
1
TCP Flusskontrolle und Fenstergröße
15 - 48
 Merke:
TCP setzt einen zuverlässigen bytestromorientierten
Datentransferdienst auf den unzuverlässigen Best-EffortDienst von IP auf.
Copyright: © Michael Massoth
15 - 48
Netzwerke, WS 2009/10
15 - 49
TCP
[Transmission Control Protocol ]





TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
Copyright: © Michael Massoth
15 - 49
Netzwerke, WS 2009/10
TCP Receiver Window und Buffer
15 - 50
Zusammenhang zwischen TCP Receiver Window und Receiver Buffer
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.35]
Copyright: © Michael Massoth
15 - 50
Netzwerke, WS 2009/10
TCP Window Flow Control: Send Side
15 - 51
TCP Sendepuffer
window
Sent and acked
Sent but not acked
Not yet sent
Next to be sent
Copyright: © Michael Massoth
15 - 51
Netzwerke, WS 2009/10
TCP Window Flow Control: Receive Side
TCP-Empfangspuffer
15 - 52
What should receiver do?
New
Receive buffer
Acked but not
delivered to user
Not yet
acked
window
Copyright: © Michael Massoth
15 - 52
Netzwerke, WS 2009/10
TCP Window Flow Control: Send Side
Packet Received
Packet Sent
Source Port
15 - 53
Dest. Port
Source Port
Dest. Port
Sequence Number
Sequence Number
Acknowledgment
Acknowledgment
HL/Flags
Window
HL/Flags
Window
D. Checksum
Urgent Pointer
D. Checksum
Urgent Pointer
Options…
Options...
App write
acknowledged
Copyright: © Michael Massoth
sent
to be sent outside window
15 - 53
Netzwerke, WS 2009/10
TCP Flusskontrolle und Fenstergröße (1)
15 - 54
 Merke: Das 16-Bit-Feld Empfänger-Fenster (Window) dient
der Flusskontrolle.
 Es wird dazu benutzt, um die Anzahl von Bytes anzugeben, die
ein Empfänger anzunehmen bereit ist.
 Die Empfänger-Fenstergröße bildet eine absolute obere
Schranke für den Sender und darf nicht überschritten werden.
Copyright: © Michael Massoth
15 - 54
Netzwerke, WS 2009/10
TCP Flusskontrolle und Fenstergröße (2)
15 - 55
 Mit anderen Worten: TCP stellt Flusskontrolle dadurch bereit,
dass es den Sender eine Variable verwalten lässt, die man als
Empfagsfenster (ReceiveWindow) bezeichnet.
 Das Empfangsfenster ist dynamisch, d. h. es ändert sich im
Verlauf einer Verbindung.
 In einer Vollduplex-Verbindung verwaltet der Sender auf
jeder Seite der Verbindung ein eigenes Empfangsfenster.
Copyright: © Michael Massoth
15 - 55
Netzwerke, WS 2009/10
Fensterverwaltung und Flusskontrolle in TCP
15 - 56
Beispiel:
Empfänger hat
eine Empfangsfenstergröße
(Puffer) von nur
4.096 Byte.
Merke:
Flusskontrolle
erfolgt über das
„WINDOW“-Feld
im TCP-Header.
Copyright: © Michael Massoth
15 - 56
Netzwerke, WS 2009/10
15 - 57
Vielen Dank für Ihre
Aufmerksamkeit!
Noch Fragen?
 Fragen und Diskussion
Copyright: © Michael Massoth
15 - 57
Netzwerke, WS 2009/10