Grundlagen der Rechnernetze
Transportschicht
Übersicht
• Einfacher Demultiplexer (UDP)
• Transmission Control Protocol (TCP)
• TCP‐Überlastkontrolle
• TCP‐Überlastvermeidung
• TCP‐Varianten
Einfacher Demultiplexer (UDP)
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 216 = 65536 unterschiedliche Ports.
Global eindeutige
Adresse eines Prozesses:
<Port,Host>
Woher erfährt der Sender die Port‐Nummer des Empfängers?
Möglichkeit 1: vorab festgelegte Port‐Nummern.
•
Zum Beispiel Port 53 für DNS, Port 25 für Mail‐Server oder Port 517 für Unix‐
Talk‐Programm
•
Festgelegte Portnummern werden in einem RFC periodisch aktualisiert
•
Unter vielen Unix‐Systemen findet man die festen Portnummern auch unter /etc/services
Möglichkeit 2: Port‐Mapper
•
Nur 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
Bemerkung: häufig werden nach dem ersten Kontakt zwischen Client und Server ein privater Port für deren Session ausgemacht.
Client Port‐Mapper
Server
Host 1 Host 2
Transmission Control Protocol (TCP)
Übersicht
Anwendungsprozess A
TCP Sende‐
puffer
Anwendungsprozess B
TCP Empfangs‐
puffer
…
schreibe Bytes
lese
Bytes …
Segment Segment
… lese
Bytes
schreibe Bytes
Empfangs‐
puffer
Sende‐
puffer
IP IP
Segment Segment Segment Segment
Übersicht
Anwendungsprozess A
TCP Sende‐
puffer
Anwendungsprozess B
TCP Empfangs‐
puffer
…
schreibe Bytes
lese
Bytes …
Segment Segment
… lese
Bytes
schreibe 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
Segmentnummerierung und ACKs
Initiale Sequenznummer: 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
Sliding‐Window
Sendende Anwendung
TCP
LastByteAcked
LastByteWritten
LastByteSent
… …
Sendepuffer
Empfangende Anwendung
TCP
NextByteExpected
LastByteRead
LastByteRcvd
… …
Empfangspuffer
MaxSendBuffer = Größe des Sendepuffers MaxRcvBuffer = Größe des Empfangspuffers TCP‐Acknowledgements sind kummulativ (Kummulative ACKs) – bestätigt wird die Nummer des ersten noch fehlenden Bytes. Alle vorigen Bytes wurden schon vollständig empfangen.
Flusskontrolle
Sender
TCP
v=LastByteAcked
l=LastByteWritten
w=LastByteSent
… …
Empfänger
TCP
NextByteExpected
x=LastByteRead
y=LastByteRcvd
… …
MSB = MaxSendBuffer MRB=MaxRcvBuffer
Zur Vermeidung eines Empfangs‐
pufferüberlaufes muss gelten:
Hierzu wird dem Sender das folgende
„AdvertisedWindow“ a mitgeteilt:
Auf Senderseite muss stets gelten:
Damit ist das Maximum an Daten, welches der Sender versenden darf (genannt „EffectiveWindow“ e):
Anwendung, die z Bytes schreibt wird blockiert, wenn:
Protokollablauf
Verbindungsaufbau
Datenübertragungsphase
Verbindungsabbau
Bildquelle: en.wikipedia.org/wiki/Transmission_Control_Protocol
Tafelanschrieb
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 Data Offset
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
Window Size
16 128 Checksum Urgent Pointer (if URG set) 20
…
160
…
Options (if data Offset > 5)
(Padded at end with 0‐Bytes if necessary)
Data
Regulärer Duplexbetrieb
AdvWnd=1024, AckedSeqNr=3463
Gerät 1 Gerät 2
AdvertisedWindow = 0 Deadlock?
AdvertisedWindow=0
Empfangspuffer wird geleert und Empfänger sendet nichts an den Sender zurück.
Empfänger Sender
Annahme: Sender sendet ab hier nicht weiter
Woher weis der Sender, dass wieder Platz im Empfängerpuffer ist?!?
AdvertisedWindow=0
Empfangspuffer wird geleert und Empfänger sendet nichts an den Sender zurück.
Empfänger Sender
Segment der Länge 1
AdvertisedWindow=0
Segment der Länge 1
AdvertisedWindow=1200
Probing mit Segment der Länge 1
Persist timer
Wann soll ein Segment versendet werden?
TCP verwaltet eine Variable Maximum‐Segment‐Size (MSS)
MSS = MTU des lokalen Netzes minus TCP‐ und IP‐Headergröße Versende Segment auf jeden Fall sobald
• mindestens MSS viele neue Bytes vorliegen oder
• der sendende Prozess explizit darum bittet (push)
Was sonst? Warum nicht aggressiv immer sofort senden?
Sofortiges Senden bedeutet unnötiger Overhead
Sender Empfänger
Sendepuffer leer
…
2 Bytes erzeugt 7 Bytes erzeugt 3 Bytes erzeugt
Segment mit ein paar wenigen Bytes bedeutet unnötiger Overhead. Versendet werden muss: Daten + IP‐Header + TCP‐Header.
Effekte wie diesen, in denen unnötig kleine Pakete versendet werden, nennt man auch Silly‐Window‐Syndrom.
Besser wäre es doch zu warten, bis der Puffer wieder gut gefüllt ist. Wie lange
sollte man warten?
Nagle‘s Algorithmus
Routine, die von TCP ausgeführt wird, wenn die sendende Applikation neue Daten produziert hat:
if verfügbare Daten und Window >= MSS then sende volles Segment
else
if nicht-Acked Data unterwegs then
puffere die Daten bis Ack ankommt else
sende alle neuen Daten jetzt endif
endif
(Die Vorgehensweise von Nagle‘s Lösung nennt man auch self‐
clocking.)
Reübertragung bei TCP der ersten Stunde
TCP‐Sender TCP‐Empfänger
Segment
*
Wie lange warten, bis das Segment
reübertragen wird?
Erste TCP‐
Implementierungen
verwenden das zweifache der RTT.
Woher kennt man die RTT?
