TCP Bestätigungsnummern - fbi.h
Werbung
Vorlesung: Netzwerke (TK) WS 2011/12
Kapitel 5 Ende-zu-Ende-Protokolle
Session 16
Prof. Dr. Michael Massoth
[Stand: 11.01.2012]
Copyright: © Michael Massoth
16 - 1
Netzwerke, WS 2011/12
16 - 2
ACHTUNG:
Testat_4
am Dienstag, den 17.01.2012
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)
Ende-zu-Ende-Protokolle (UDP + TCP)
Copyright: © Michael Massoth
16 - 2
Netzwerke, WS 2011/12
16 - 3
ACHTUNG:
Testat_5
am Dienstag, den 24.01.2012
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)
Ende-zu-Ende-Protokolle (UDP + TCP)
Copyright: © Michael Massoth
16 - 3
Netzwerke, WS 2011/12
16 - 4
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
16 - 4
Netzwerke, WS 2011/12
16 - 5
TCP
[Transmission Control Protocol ]
TCP-Segmentstruktur
Verbindungsorientierter Transport (1): Verbindungsaufbau
Verbindungsorientierter Transport (2): Verbindungsabbau
TCP-Verbindungsmanagement
Copyright: © Michael Massoth
16 - 5
Netzwerke, WS 2011/12
TCP-Multiplexmechanismus
16 - 6
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
16 - 6
Netzwerke, WS 2011/12
TCP-Verbindungsmanagement (1)
16 - 7
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
16 - 7
Netzwerke, WS 2011/12
TCP-Verbindungsmanagement (2)
16 - 8
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
16 - 8
Netzwerke, WS 2011/12
TCP Client Lifecycle
16 - 9
TCP Client
Copyright: © Michael Massoth
16 - 9
Netzwerke, WS 2011/12
TCP Client Lebenszyklus
16 - 10
Typische Abfolge von
TCP-Zuständen eines
TCP Clients
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.39]
Copyright: © Michael Massoth
16 - 10
Netzwerke, WS 2011/12
TCP Server Lifecycle
16 - 11
TCP Server
Copyright: © Michael Massoth
16 - 11
Netzwerke, WS 2011/12
TCP Server Lebenszyklus
16 - 12
Typische Abfolge von
TCP-Zuständen, die
ein serverseitiges
TCP durchläuft
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.40]
Copyright: © Michael Massoth
16 - 12
Netzwerke, WS 2011/12
TCP State Diagram: Connection Setup
16 - 13
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
16 - 13
Netzwerke, WS 2011/12
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
16 - 14
rcv ACK of FIN
TIME WAIT
CLOSED
Timeout=2msl
delete TCB
16 - 14
Netzwerke, WS 2011/12
TCP Connection Teardown
16 - 15
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
16 - 15
Netzwerke, WS 2011/12
TCP Zustandsübergangsdiagramm
Erklärung:
CLOSED
Active open /SYN
Passive open
Close
Close
LISTEN
SYN_RCVD
SYN/SYN + ACK
Send /SYN
SYN/SYN + ACK
ACK
SYN_SENT
Close/FIN
FIN/ACK
FIN_WAIT_1
ACK
FIN_WAIT_2
CLOSE_WAIT
AC FIN/ACK
K
+
FI
N/
AC
K
FIN/ACK
Copyright: © Michael Massoth
SYN + ACK/ACK
ESTABLISHED
Close/FIN
16 - 16
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
Close/FIN
CLOSING
LAST_ACK
ACK Timeout after two
segment lifetimes
TIME_WAIT
ACK
CLOSED
16 - 16
Netzwerke, WS 2011/12
TCP for Client-Server Communication
16 - 17
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
16 - 17
New
socket
Netzwerke, WS 2011/12
Adressierung
Portnummer
Application
16 - 18
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
16 - 18
Netzwerke, WS 2011/12
Sockets
16 - 19
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
16 - 19
Netzwerke, WS 2011/12
Port, Socket und eindeutige TCP-Verbindung
16 - 20
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
16 - 20
Netzwerke, WS 2011/12
16 - 21
TCP
[Transmission Control Protocol ]
TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
Copyright: © Michael Massoth
16 - 21
Netzwerke, WS 2011/12
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
16 - 22
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
16 - 22
Netzwerke, WS 2011/12
Sequenznummer eines TCP-Segments (1)
16 - 23
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
16 - 23
Netzwerke, WS 2011/12
Sequenznummer eines TCP-Segments (2)
16 - 24
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
16 - 24
Netzwerke, WS 2011/12
TCP Sequenznummern (1)
16 - 25
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
16 - 25
Netzwerke, WS 2011/12
TCP Sequenznummern (2)
16 - 26
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
16 - 26
Netzwerke, WS 2011/12
Telnet: Eine Fallstudie
16 - 27
Telnet: Eine Fallstudie für Sequenzund Bestätigungsnummern
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.30]
Copyright: © Michael Massoth
16 - 27
Netzwerke, WS 2011/12
TCP Bestätigungsnummern (1)
16 - 28
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
16 - 28
Netzwerke, WS 2011/12
TCP Bestätigungsnummern (2)
16 - 29
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
16 - 29
Netzwerke, WS 2011/12
Erzeugung von Quittungen
16 - 30
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
16 - 30
Netzwerke, WS 2011/12
Einige interessante Szenarien (1)
16 - 31
Neuübertragung aufgrund einer
verlorenen Bestätigung (ACK)
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.32]
Copyright: © Michael Massoth
16 - 31
Netzwerke, WS 2011/12
Einige interessante Szenarien (2)
16 - 32
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
16 - 32
Netzwerke, WS 2011/12
Einige interessante Szenarien (3)
16 - 33
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
16 - 33
Netzwerke, WS 2011/12
16 - 34
TCP
[Transmission Control Protocol ]
TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
Copyright: © Michael Massoth
16 - 34
Netzwerke, WS 2011/12
16 - 35
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
16 - 35
Netzwerke, WS 2011/12
Zwei Probleme aus der Praxis
16 - 36
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
16 - 36
Netzwerke, WS 2011/12
Zuverlässige Zustellung
16 - 37
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
16 - 37
Netzwerke, WS 2011/12
Implizite Übertragungswiederholung
16 - 38
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
P1,0
Zeitüberwachung
P1,0
P1,0
ACK
ACK
DL-Data.Req(p2)
DL-Data.Ind(p1)
P2,1
P2,1
ACK
ACK
DL-Data.Ind(p2)
Zeitüberwachung
Legende:
Daten,Folgenummer
P2,1
P2,1
ACK
ACK
Als Duplikat erkannt!
Zeit
Copyright: © Michael Massoth
16 - 38
Netzwerke, WS 2011/12
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
1) p6
(
K
AC (3)
K )
AC K(45)
ACCK( (6)
A CK
A
p2
p3
p4
p5
p6
(2)
K
ACK(3)
ACK(4)
ACK(5)
ACK(6)
AC
Copyright: © Michael Massoth
16 - 39
16 - 39
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 2011/12
1
TCP Flusskontrolle und Fenstergröße
16 - 40
Merke:
TCP setzt einen zuverlässigen bytestromorientierten
Datentransferdienst auf den unzuverlässigen Best-EffortDienst von IP auf.
Copyright: © Michael Massoth
16 - 40
Netzwerke, WS 2011/12
16 - 41
TCP
[Transmission Control Protocol ]
TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
Copyright: © Michael Massoth
16 - 41
Netzwerke, WS 2011/12
TCP Receiver Window und Buffer
16 - 42
Zusammenhang zwischen TCP Receiver Window und Receiver Buffer
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.35]
Copyright: © Michael Massoth
16 - 42
Netzwerke, WS 2011/12
TCP Window Flow Control: Send Side
16 - 43
TCP Sendepuffer
window
Sent and acked
Sent but not acked
Not yet sent
Next to be sent
Copyright: © Michael Massoth
16 - 43
Netzwerke, WS 2011/12
TCP Window Flow Control: Receive Side
TCP-Empfangspuffer
16 - 44
What should receiver do?
New
Receive buffer
Acked but not
delivered to user
Not yet
acked
window
Copyright: © Michael Massoth
16 - 44
Netzwerke, WS 2011/12
TCP Window Flow Control: Send Side
16 - 45
Packet Received
Packet Sent
Source
Dest.
Dest.Port
Port
SourcePort
Port
Sequence
SequenceNumber
Number
Source
Dest.
SourcePort
Port
Dest.Port
Port
Sequence
SequenceNumber
Number
Acknowledgment
Acknowledgment
HL/Flags
Window
Window
HL/Flags
Acknowledgment
Acknowledgment
HL/Flags
Window
Window
HL/Flags
D.
D.Checksum
Checksum Urgent
UrgentPointer
Pointer
Options…
Options…
D.
D.Checksum
Checksum Urgent
UrgentPointer
Pointer
Options...
Options...
App write
acknowledged
Copyright: © Michael Massoth
sent
to be sent outside window
16 - 45
Netzwerke, WS 2011/12
TCP Flusskontrolle und Fenstergröße (1)
16 - 46
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
16 - 46
Netzwerke, WS 2011/12
TCP Flusskontrolle und Fenstergröße (2)
16 - 47
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
16 - 47
Netzwerke, WS 2011/12
Fensterverwaltung und Flusskontrolle in TCP
16 - 48
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
16 - 48
Netzwerke, WS 2011/12
16 - 49
Vielen Dank für Ihre
Aufmerksamkeit!
Noch Fragen?
Fragen und Diskussion
Copyright: © Michael Massoth
16 - 49
Netzwerke, WS 2011/12
