Die Transportschicht: UDP und TCP

Eine Anwendung sendet über einen Socket, die Schnittstelle zwischen ihrem Prozess und der Transportschicht. Die Transportschicht lässt es so erscheinen, als kommunizierten Prozesse auf verschiedenen Hosts direkt miteinander. Das ist logische Kommunikation: Die Daten durchqueren weiterhin Verbindungen und Router, aber die Anwendung arbeitet über ihren lokalen Socket.

Verfolge die Daten durch die Schichten

Beim Sender übernimmt das Transportprotokoll Anwendungsdaten, teilt sie bei Bedarf in Abschnitte und ergänzt einen Transportheader. Das entstehende Segment geht an IP. IP ergänzt seinen eigenen Header und erzeugt so ein IP-Datagramm, das durch das Netz übertragen wird. Am Ziel übergibt IP das Segment an das Transportprotokoll, das den Transportheader interpretiert und die Daten an einen Socket liefert.

Die Protokolllogik läuft auf den Endhosts. Gewöhnliche Router leiten IP-Datagramme weiter; sie übernehmen keine TCP-Quittungen und Übertragungswiederholungen für die Anwendungen. Stell dir die IP-Adresse als Anschrift eines Gebäudes und den empfangenden Socket als den vorgesehenen Empfänger darin vor. Einen Brief zum Gebäude und ihn zur richtigen Person zu bringen, sind getrennte Aufgaben.

IP bietet eine Best-Effort-Übertragung zwischen Hosts. Datagramme können verloren gehen, dupliziert, in anderer Reihenfolge zugestellt oder beschädigt werden. Die Transportschicht erweitert die Übertragung auf Prozesse und kann Mechanismen ergänzen, die diese Fehler beheben.

Vergleiche die Dienste

UDP ergänzt die IP-Übertragung um Ports und eine Fehlerprüfung. Ein Segment kann ohne vorherigen Austausch zum Verbindungsaufbau ankommen. UDP stellt ein verlorenes Segment nicht wieder her und hält ein späteres Segment nicht zurück, bis ein früheres eintrifft.

TCP richtet vor der normalen Datenübertragung einen Verbindungszustand ein. Es nummeriert Bytes, prüft auf Fehler, erhält Quittungen und überträgt fehlende Daten erneut. Die empfangende Anwendung erhält einen zuverlässigen Bytestrom in der richtigen Reihenfolge. Flusskontrolle schützt ihren Puffer; Überlastkontrolle reagiert auf die Netzlast.

Zuverlässigkeit macht das darunterliegende Netz nicht zuverlässig. Verschwindet ein IP-Datagramm, sendet TCP eine weitere Kopie der fehlenden Daten. Treffen spätere Bytes zuerst ein, kann der Empfänger sie zurückhalten, bis die Lücke gefüllt ist. Die Anwendung sieht eine korrigierte Übertragung, muss aber möglicherweise länger warten. Weder TCP noch UDP kann allein durch die Nutzung von Best-Effort-IP eine Zustellfrist versprechen oder Netzkapazität reservieren.

Wähle den Dienst am Socket

Ein Stream-Socket wählt normalerweise TCP; ein Datagramm-Socket wählt UDP. HTTP/1.1 und HTTP/2, die E-Mail-Übertragung mit SMTP und die entfernte Anmeldung mit SSH nutzen TCP. Gewöhnliche DNS-Anfragen nutzen häufig UDP. HTTP/3 nutzt QUIC über UDP: QUIC bietet zuverlässige Datenströme und Sicherheit auf Basis des minimalen UDP-Dienstes.

Eine TCP-Verbindung allein hält ein Passwort nicht geheim. TLS ergänzt Verschlüsselung und Authentifizierung oberhalb von TCP; QUIC integriert TLS in seinen Aufbau. Zuverlässigkeit beantwortet die Frage, ob Bytes korrekt und in der richtigen Reihenfolge bei der Anwendung ankommen. Vertraulichkeit beantwortet die Frage, ob ein Beobachter sie lesen kann.

Ein Host hat häufig viele Sockets geöffnet. Das Multiplexen sammelt ausgehende Daten von diesen Sockets und ergänzt Transportheader. Das Demultiplexen wählt für jedes eintreffende Segment den empfangenden Socket aus.

Lies die Adressinformationen

Sowohl TCP als auch UDP enthalten einen 16-Bit-Quellport und einen 16-Bit-Zielport. Die Werte reichen von 0 bis 65.535. Der Zielport identifiziert den empfangenden Dienst; der Quellport hilft dem Kommunikationspartner, seine Antwort zu adressieren. Die IANA teilt Ports in Systemports 0–1023, Benutzerports 1024–49151 und dynamische Ports 49152–65535 ein.

Server lauschen an vereinbarten Ports: SSH nutzt 22, SMTP 25, DNS 53, HTTP 80 und HTTPS üblicherweise 443. Clients erhalten vom Betriebssystem normalerweise einen vorübergehenden, ephemeren Port. Dessen konfigurierter Bereich muss nicht dem dynamischen Bereich der IANA entsprechen: Ein häufig verwendeter Linux-Standard ist 32768–60999, während Windows häufig 49152–65535 nutzt.

Bei einem eintreffenden IP-Datagramm bestimmt der Host zunächst das Transportprotokoll. Der IPv4-Protokollwert 6 bedeutet TCP und 17 bedeutet UDP; IPv6 identifiziert das Protokoll der höheren Schicht durch seine Kette von Next-Header-Feldern. TCP-Port 53 und UDP-Port 53 gehören zu unterschiedlichen Namensräumen der Transportprotokolle. Der Empfänger wählt dann anhand von Adressen und Ports einen Socket aus und stellt die Daten für die Anwendung in eine Warteschlange.

UDP: viele Clients, ein empfangender Socket

Im grundlegenden Modell eines nicht verbundenen UDP-Servers wird der empfangende Socket anhand von Ziel-IP-Adresse und Zielport ausgewählt. Verschiedene Clients können alle an denselben Socket senden.

Ein Server unter 203.0.113.53 lauscht an UDP-Port 53. Anfragen von 198.51.100.7:51000 und 192.0.2.44:62011 erreichen diesen einen Serversocket. Die erste Antwort geht von 203.0.113.53:53 an 198.51.100.7:51000. Die Anwendung erhält Quelladresse und Quellport jeder Anfrage, damit sie dem richtigen Client antworten kann. Ein verbundener UDP-Socket kann auch einschränken, von welchem Kommunikationspartner er empfängt; ein UDP-Handshake kommt nicht hinzu.

TCP: Verbindungen anhand von vier Werten unterscheiden

Ein TCP-Server hat einen lauschenden Socket und separate Verbindungssockets. Eine Verbindung wird durch das Vierertupel aus Quell-IP-Adresse, Quellport, Ziel-IP-Adresse und Zielport identifiziert.

Für einen Server unter 203.0.113.10:80 sind dies unterschiedliche Verbindungen:

• 198.51.100.7:50312 → 203.0.113.10:80
• 198.51.100.7:50313 → 203.0.113.10:80
• 192.0.2.44:50312 → 203.0.113.10:80

Die ersten beiden unterscheiden sich im Quellport. Der erste und der dritte haben denselben Quellport, unterscheiden sich aber in der Quelladresse. Alle drei nutzen den Serverport 80. Ein separater Serverport pro Client ist unnötig, weil das vollständige Vierertupel ihre Verbindungssockets unterscheidet. Ein Prozess kann viele solche Sockets bearbeiten.

Wenn kein Socket passt

Ein SYN an einen geschlossenen TCP-Port erhält normalerweise einen TCP-Reset mit gesetztem RST-Flag. Ein UDP-Segment an einen Port ohne Empfänger löst normalerweise eine ICMP-Meldung „Port nicht erreichbar“ aus. Firewalls, Filter und Antwortbegrenzungen können beeinflussen, was zurückkommt. Bei einer Portprüfung ist SYN-ACK ein Beleg für einen lauschenden TCP-Dienst; RST zeigt eine Ablehnung an. Ausbleibende Antworten allein lassen nicht unterscheiden, ob gefiltert wird, ein Verlust vorliegt oder ein Host nicht verfügbar ist.

UDP sendet jede Nachricht unabhängig, ohne Handshake oder gemeinsamen Verbindungszustand für Sequenznummern. Sein fester 8-Byte-Header enthält vier Felder mit je 16 Bit: Quellport, Zielport, Länge und Prüfsumme.

Zähle die richtigen Bytes

Die Länge umfasst den UDP-Header und seine Daten. Sie beträgt mindestens 8 Byte. Eine Nachricht mit 40 Byte Daten hat die UDP-Länge 48. Bei einem IPv4-Header von 20 Byte und ohne IP-Optionen ist das vollständige IP-Datagramm 68 Byte lang. Der IP-Header liegt außerhalb der UDP-Länge.

Die Prüfsumme erkennt manche Bitfehler im UDP-Header und in den Daten. Sie umfasst auch einen Pseudoheader, der aus IP-Adressinformationen, der Protokollnummer und der UDP-Länge gebildet wird. Diese Werte helfen, ein Segment zu erkennen, das mit falschen Adressinformationen zugestellt wurde. Der Pseudoheader dient als Eingabe für die Berechnung; er ist kein zusätzlich übertragener Teil des UDP-Headers.

Addiere mit zyklischem Übertrag

Behandle die Eingabe für die Berechnung als 16-Bit-Wörter. Setze das Prüfsummenfeld während der Berechnung auf null. Addiere die Wörter und führe jeden Übertrag über Bit 16 hinaus an das niederwertige Ende zurück. Das ist die Einerkomplementaddition. Kehre schließlich alle 16 Bit der so gebildeten Summe um, um die Prüfsumme zu erhalten. Ist die Byteanzahl ungerade, hänge nur für die Berechnung ein Nullbyte an.

Verwende für drei Beispielwörter die Hexadezimalschreibweise, um den Übertrag sichtbar zu machen:

1. Addiere A35C und 69C3 zu 10D1F. Die führende 1 ist ein Übertrag außerhalb der 16 Bit.
2. Führe ihn zurück: 0D1F + 1 = 0D20.
3. Addiere 1234: 0D20 + 1234 = 1F54.
4. Bilde das Komplement jedes Bits: FFFF − 1F54 = E0AB.

Die Prüfsumme ist E0AB. Den führenden Übertrag einfach wegzulassen, würde eine falsche Summe ergeben. Binär lautet die endgültige Summe 0001 1111 0101 0100 und ihr Komplement 1110 0000 1010 1011.

Prüfe beim Empfänger

Der Empfänger wiederholt die Addition mit zyklischem Übertrag über Pseudoheader und empfangenes Segment, diesmal einschließlich des Prüfsummenfeldes. Ein unverändertes Segment ergibt nur Einsen, FFFF. Hier gilt 1F54 + E0AB = FFFF. Ein Ergebnis mit einem Nullbit zeigt einen erkannten Fehler an. UDP verwirft ein Segment stillschweigend, wenn dessen mitgelieferte Prüfsumme ungleich null die Prüfung nicht besteht; es sendet keinen Ersatz und korrigiert die Daten nicht.

Nur Einsen bedeuten, dass die Prüfung bestanden wurde, nicht dass jeder mögliche Fehler ausgeschlossen ist. Einander ausgleichende Änderungen in verschiedenen Wörtern können die Summe unverändert lassen. Die Prüfsumme erkennt Fehler; sie lokalisiert die fehlerhaften Bits weder noch korrigiert sie sie.

Warum die Endhosts erneut prüfen

Eine Verbindungsprüfung schützt eine bestimmte Verbindung. Manche Verbindungen haben möglicherweise keine solche Prüfung, und auch innerhalb von Geräten zwischen Verbindungen können Daten beschädigt werden. Eine Ende-zu-Ende-Prüfung testet, was den Zielhost erreicht hat. Das veranschaulicht das Ende-zu-Ende-Prinzip: Eine Eigenschaft, die über den ganzen Pfad benötigt wird, muss an dessen Endpunkten geprüft werden.

Bei IPv4 zeigt ein UDP-Prüfsummenfeld mit dem Wert null an, dass der Sender die Prüfsumme weggelassen hat. Eine berechnete Prüfsumme mit dem Wert null wird als Folge von Einsen übertragen, um diese Unterscheidung zu erhalten. IPv6 verlangt normalerweise eine UDP-Prüfsumme, mit eng festgelegten Ausnahmen für Tunnel. TCP verwendet ebenfalls eine Internet-Prüfsumme mit Pseudoheader und schreibt seine Prüfsumme vor.

Der kleine Dienstumfang von UDP gibt einer Anwendung Kontrolle über ihre Nachrichten. Es gibt keinen Transport-Handshake vor der ersten Nachricht, keine UDP-Warteschlange für Übertragungswiederholungen und keinen UDP-Mechanismus, der spätere Daten hinter einer fehlenden früheren Nachricht zurückhält. Die Anwendung entscheidet, was sie sendet und welche Verluste relevant sind.

Stimme die Wiederherstellung auf den nutzbaren Ankunftszeitpunkt ab

Betrachte Sprachdaten, die in Abschnitten von 20 ms gesendet werden: 50 Nachrichten pro Sekunde. Ein fehlender Abschnitt soll in 60 ms abgespielt werden, doch die Erkennung des Verlusts und der Empfang einer weiteren Kopie dauern etwa 150 ms. Dieser wiederhergestellte Abschnitt käme zu spät an. Eine Sprachanwendung kann spätere Abschnitte rechtzeitig abspielen und den fehlenden Ton kaschieren, etwa indem sie die Lücke glättet.

Entscheidend ist die verbleibende Zeit bis zur Wiedergabe, nicht die Dauer von 20 ms eines Abschnitts. Kann die Wiederherstellung vor der Frist abgeschlossen werden, kann eine Übertragungswiederholung helfen. TCP muss Bytes in der richtigen Reihenfolge ausliefern, sodass ein fehlendes früheres Byte auch die Auslieferung bereits empfangener späterer Bytes verzögern kann. Dieses Warten wird innerhalb des Datenstroms häufig Head-of-Line-Blocking genannt.

Eine Dateiübertragung hat eine andere Priorität: Jedes Byte muss korrekt ankommen, und das Warten auf eine Wiederherstellung ist akzeptabel. TCP bietet diesen Dienst bereits. Bei UDP müsste die Anwendung oder ein anderes Protokoll Verluste erkennen, Ersatzdaten anfordern und die Reihenfolge wiederherstellen.

Was der kleine Header bringt

Der UDP-Header umfasst 8 Byte, der TCP-Header mindestens 20. Ein UDP-Server kann Nachrichten vieler Clients empfangen, ohne Transportverbindungen pro Client aufzubauen. Socketpuffer und Anwendungsressourcen gibt es dennoch, „verbindungslos“ bedeutet also nicht, dass der Host nichts speichert.

Zu den häufigen UDP-Einsatzgebieten gehören gewöhnliche DNS-Anfragen an Port 53, NTP-Zeitsynchronisation an 123, SNMP-Management an 161 und DHCP-Adressvergabe an 67 und 68. Für Anrufe und Spiele wird häufig UDP gewählt, damit Nachrichten rechtzeitig ankommen. Video-on-Demand nutzt häufig HTTP über TCP oder QUIC; die Regel „Video nutzt UDP“ ist daher zu allgemein.

QUIC zeigt, wie viel ein Protokoll auf Basis von UDP ergänzen kann: zuverlässige Datenströme, Überlastkontrolle und Sicherheit durch TLS 1.3. Es wurde 2021 standardisiert und nutzt häufig UDP-Port 443; HTTP/3 läuft über QUIC. UDP selbst hat diese Dienste nicht hinzugewonnen.

Halte Nachrichten klein genug

UDP erhält Nachrichtengrenzen. Ein Empfangsvorgang liest eine Nachricht, keinen aus mehreren Sendevorgängen zusammengesetzten Bytestrom. Die Anwendung muss einen ausreichend großen Lesepuffer bereitstellen; ein kleinerer Puffer kann die Nachricht abschneiden.

Bei IPv4 mit einem 20-Byte-IP-Header beträgt die theoretische maximale Nutzlast 65.535 − 20 − 8 = 65.507 Byte. Beim Senden nahe dieser Grenze kann IP-Fragmentierung nötig sein. Auf einem Pfad, der IPv4-Datagramme mit 1.500 Byte unterstützt, passen ohne IP-Optionen 1.500 − 20 − 8 = 1.472 Byte Daten ohne Fragmentierung hinein. Andere Pfade und Header können diesen Wert verringern.

Berücksichtige die fehlenden Kontrollmechanismen

UDP hat keine eingebaute Flusskontrolle, um einen langsamen Empfänger zu schützen. Füllt sich dessen Socketpuffer, können eintreffende Nachrichten verworfen werden. Außerdem fehlt eine eingebaute Überlastkontrolle. Verantwortungsvoll arbeitende UDP-Anwendungen sorgen für eine geeignete Ratensteuerung, damit sie einen gemeinsam genutzten Pfad nicht überlasten. Manche Netze filtern UDP, sodass Anwendungen möglicherweise eine Ausweichmöglichkeit brauchen.

Das Weglassen von Verbindungsaufbau und Wiederherstellung kann Verzögerungen verringern, aber UDP erhöht weder die Kapazität einer Verbindung noch verhindert es IP-Verluste. Beurteile das gesamte Anwendungsprotokoll: Die zusätzliche Arbeit oberhalb von UDP kann stärker ins Gewicht fallen als die Headergröße.

Ein Protokoll zur zuverlässigen Datenübertragung liefert der empfangenden Anwendung korrekte Daten in der richtigen Reihenfolge und ohne Duplikate, selbst wenn der darunterliegende Kanal Pakete beschädigt. Entwickle den Entwurf, indem du fragst, was auf jeder Stufe schiefgehen kann. Bei diesen Protokollen fließen Anwendungsdaten in eine Richtung und Steuerrückmeldungen zurück.

Beschreibe das Verhalten mit Zuständen

Ein endlicher Automat hält den aktuellen Zustand des Senders oder Empfängers fest. Jeder Übergang hat ein auslösendes Ereignis und auszuführende Aktionen. Ein Zustand wie „Warten auf ACK 0“ erfasst, welchen Beleg der Sender braucht, bevor er fortfahren kann. In der Darstellung endlicher Automaten steht Λ für kein Ereignis oder keine Aktion; ein eingehender gestrichelter Pfeil markiert den Anfangszustand.

Bei einem vollkommen zuverlässigen Kanal braucht Version 1.0 nur das Senden und Ausliefern. Der Sender verpackt die Daten, der Empfänger entnimmt sie, und keiner von beiden braucht eine Rückmeldung. Mit Bitfehlern ändert sich der Entwurf.

Erkenne einen Fehler und fordere eine weitere Kopie an

Version 2.0 verwendet drei Mechanismen:

• Eine Prüfsumme ermöglicht dem Empfänger, ein Paket auf Beschädigung zu prüfen.
• Ein ACK meldet erfolgreichen Empfang; ein NAK meldet beschädigte Daten.
• Eine Übertragungswiederholung sendet bei Bedarf eine weitere Kopie.

Zusammen bilden sie die automatische Wiederholungsanforderung (ARQ). Der Sender sendet ein Paket und wartet auf eine Rückmeldung, bevor er das nächste sendet: Stop-and-Wait. Er behält eine Kopie des aktuellen Pakets, weil er es möglicherweise erneut senden muss.

Rückmeldepakete durchqueren jedoch denselben unzuverlässigen Kanal. Ein beschädigtes ACK lässt den Sender im Unklaren: Hat der Empfänger die Daten angenommen oder wird eine weitere Kopie benötigt? Erneutes Senden ist nur sicher, wenn der Empfänger eine Ersatzkopie von neuen Anwendungsdaten unterscheiden kann. Eine Prüfsumme allein erkennt keine Duplikate; zwei gültige Kopien haben denselben gültigen Inhalt.

Gib jedem ausstehenden Paket eine Identität

Version 2.1 ergänzt eine Sequenznummer. Wenn nur ein Paket aussteht, genügt in diesem Stop-and-Wait-Kanalmodell eine Ein-Bit-Nummer, die zwischen 0, 1, 0, 1 wechselt. Der Empfänger merkt sich, welche Nummer er erwartet. Er liefert ein gültiges Paket mit dieser Nummer einmal aus und ändert dann die erwartete Nummer. Ein Paket mit der vorherigen Nummer ist ein Duplikat: Quittiere es erneut, liefere seine Daten aber nicht noch einmal aus.

Der Sender behält die aktuelle Nummer bei Übertragungswiederholungen bei. Er wechselt erst nach dem passenden, lesbaren ACK zur anderen Nummer. Beschädigte Rückmeldungen oder ein NAK lösen in diesem Entwurf für reine Bitfehler eine Übertragungswiederholung aus.

Ersetze NAKs durch wiederholte ACKs

Version 2.2 verzichtet auf NAKs. Der Empfänger antwortet auf ein beschädigtes oder dupliziertes Paket mit einem ACK für das letzte angenommene Paket. Das ACK braucht daher eine Nummer.

Angenommen, Paket 0 enthält „A“ und kommt korrekt an. Der Empfänger liefert „A“ aus und sendet ACK 0. Paket 1 mit „B“ wird beschädigt, daher wiederholt der Empfänger ACK 0. Der Sender wartet auf ACK 1; diese Duplikatquittung signalisiert ihm, Paket 1 erneut zu senden. Die gültige Ersatzkopie wird als „B“ ausgeliefert und mit ACK 1 quittiert.

Duplizierte Daten zu verwerfen und das duplizierte Paket zu quittieren sind unterschiedliche Aktionen. Würde der Empfänger eine Ersatzkopie stillschweigend ignorieren, deren früheres ACK unlesbar war, könnte der Sender nie erfahren, dass die Zustellung erfolgreich war. Auch TCP verzichtet auf NAKs, obwohl sich seine Bytenummerierung und seine Regeln für Fast Retransmit von diesem einfachen Protokoll unterscheiden.

Eine Rückmeldung hilft nicht, wenn sie nie ankommt. Kann der Kanal ein Datenpaket oder ein ACK verlieren, braucht der Sender eine Möglichkeit, ohne empfangene Nachricht fortzufahren. Version 3.0 ergänzt das Alternating-Bit-Protokoll um einen Countdown-Zeitgeber.

Reagiere auf ausbleibende Antworten, ohne Daten doppelt auszuliefern

Der Sender startet den Zeitgeber immer, wenn er das aktuelle Paket sendet, auch bei einer Ersatzkopie. Ein passendes, unversehrtes ACK stoppt den Zeitgeber und erlaubt das nächste Paket. Ein beschädigtes ACK oder ein ACK mit der falschen Nummer wird ignoriert. Läuft der Zeitgeber zuerst ab, sendet der Sender dasselbe Paket erneut und startet den Zeitgeber neu.

Bei einem verlorenen Datenpaket hat der Empfänger nichts zu quittieren; die Zeitüberschreitung sorgt für die Ersatzkopie. Bei einem verlorenen ACK hat der Empfänger die Daten bereits ausgeliefert. Wenn die Ersatzkopie ankommt, weist die Sequenznummer sie als Duplikat aus. Der Empfänger verwirft ihre Daten und sendet das ACK erneut.

Eine vorzeitige Zeitüberschreitung tritt ein, wenn das ursprüngliche Paket oder ACK lediglich langsam war. Die Ersatzkopie verschwendet Übertragungskapazität, aber die Duplikaterkennung erhält die korrekte Zustellung. Ein sinnvolles Zeitlimit muss die erwartete Umlaufzeit und die Verarbeitung beim Empfänger berücksichtigen. Ein zu kurzes verursacht unnötige Übertragungswiederholungen; ein zu langes verzögert die Wiederherstellung nach tatsächlichem Verlust.

Unterscheide Übertragungszeit und Wartezeit

Die Paketlänge sei $L$ Bit und die Übertragungsrate $R$ bit/s. Der Sender braucht $L\mathrm{/}R$ Sekunden, um ein Paket auf die Verbindung zu übertragen. Ohne die Zeit für Übertragung und Verarbeitung des ACK dauert ein Stop-and-Wait-Zyklus $RTT+L\mathrm{/}R$. Der Zeitanteil für das Senden beträgt

Bei Paketen mit 1.500 Byte auf einer Verbindung mit 1 Gbit/s rechne zunächst Byte in Bit um:

Dann gilt $L\mathrm{/}R=12\mu \text{s}=\mathrm{0,012}\text{ ms}$. Bei einer RTT von 40 ms gilt:

Der Sender ist etwa 0,03 % der Zeit aktiv. Der Durchsatz beträgt etwa 12.000 Bit alle 0,040012 s oder 300 kbit/s. Selbst eine sehr schnelle Verbindung überträgt wenig Nutzverkehr, weil der Sender fast den gesamten Zyklus wartet.

Übertrage die Pakete im Pipelining-Verfahren

Pipelining erlaubt mehrere unquittierte Pakete unterwegs. Passen bis zu $N$ Pakete in das Sendefenster, beträgt die ideale Auslastung

Auf derselben Verbindung ergeben 1.000 Pakete eine Auslastung von etwa 0,30. Um sie vollständig auszulasten, braucht man mindestens $\mathrm{40,012}\mathrm{/}\mathrm{0,012}\approx \mathrm{3.334,33}$ Paketübertragungszeiten; runde daher auf 3.335 Pakete auf. Beim Abrunden bleibt vor dem ersten ACK ein kleines Leerlaufintervall.

Eine größere Pipeline braucht genügend Sequenznummern, um ihre Pakete zu unterscheiden, und genügend Pufferplatz, um unquittierte Daten vorzuhalten. Je nach Protokoll muss möglicherweise auch der Empfänger Daten puffern. Go-Back-N und Selective Repeat lösen diese Entwurfsfragen unterschiedlich.

Eine höhere Übertragungsrate allein verkürzt die ohnehin kurze Übertragungszeit. Bei fester Paketgröße und RTT verringert sie die Stop-and-Wait-Auslastung. Erst mehr Daten unterwegs ermöglichen dem Sender, die verfügbare Kapazität zu nutzen.

Go-Back-N (GBN) erlaubt bis zu $N$ gesendete, aber unquittierte Pakete. Das Schiebefenster des Senders rückt vor, wenn Quittungen die Zustellung bestätigen. Der Empfänger bleibt einfach: Er nimmt nur das nächste Paket in der richtigen Reihenfolge an.

Unterscheide die Bereiche des Senders

Die Variable base bezeichnet das älteste unquittierte Paket. nextseqnum bezeichnet das nächste neu zu sendende Paket. Vor dem Sequenznummernüberlauf gelten folgende Bereiche:

• Unterhalb von base: bereits quittiert.
• Von base bis einschließlich nextseqnum − 1: gesendet, wartet auf Quittung.
• Von nextseqnum bis einschließlich base + N − 1: für neue Daten verfügbar.
• Bei oder oberhalb von base + N: gesperrt, bis das Fenster vorrückt.

Bei base = 10, nextseqnum = 13 und $N=5$ stehen die Pakete 10–12 aus. Die Pakete 13 und 14 können gesendet werden. Paket 15 nicht. Ein Fenster begrenzt die ausstehenden Daten, nicht die Gesamtzahl der Pakete einer Übertragung.

Kumulative Quittungen verschieben die Basis

GBN-ACK $n$ bestätigt alle Pakete bis einschließlich $n$. Es setzt base auf $n+1$. Eine spätere kumulative Quittung kann daher frühere verlorene ACKs abdecken. Diese Nummerierung bezeichnet das zuletzt angenommene Paket; die ACK-Konvention von TCP bezeichnet das nächste erwartete Byte.

GBN unterhält einen Zeitgeber für das älteste ausstehende Paket. Das Senden des ersten ausstehenden Pakets startet ihn. Ein ACK, das die Basis verschiebt, startet ihn neu, wenn noch Daten ausstehen; die Quittung aller Daten stoppt ihn. Läuft der Zeitgeber ab, überträgt der Sender jedes gesendete, aber noch unquittierte Paket erneut. Diese Anzahl kann kleiner sein als die maximale Fenstergröße $N$.

Verfolge ein fehlendes Paket

Verwende ein Fenster der Größe vier und sende die Pakete 0, 1, 2 und 3. Paket 2 geht verloren. Der Empfänger liefert 0 und 1 aus und sendet ACK 0 und ACK 1. Paket 3 kommt hinter der Lücke an: Der Empfänger verwirft es und wiederholt ACK 1.

Die ersten beiden ACKs schaffen Platz für die Pakete 4 und 5. Auch sie kommen hinter dem fehlenden Paket 2 an, werden daher beide verworfen und mit ACK 1 beantwortet. Die Basis des Senders bleibt bei 2. Bei der Zeitüberschreitung überträgt er 2, 3, 4 und 5 erneut. Sie kommen nun in der richtigen Reihenfolge an und können alle ausgeliefert werden.

Die Kopien von 3, 4 und 5 waren beim ersten Mal unversehrt. GBN sendet sie erneut, weil sein Empfänger Pakete außerhalb der Reihenfolge nicht puffert. Das spart Zustandsinformationen beim Empfänger, verursacht aber nach einem Verlust zusätzlichen Verkehr.

Lass eine Sequenznummer außerhalb des Fensters

Ein $k$-Bit-Feld bietet $2^k$ Paketnummern, die zyklisch wiederverwendet werden. GBN verlangt

Bei drei Bit lauten die Nummern 0–7 und das größte Sendefenster ist sieben groß. Wären alle acht erlaubt, könnte der Empfänger 0–7 annehmen und danach wieder 0 erwarten. Gingen alle ACKs verloren, sähe ein erneut gesendetes altes Paket 0 dann wie ein neues aus. Werden nur 0–6 gesendet, erwartet der Empfänger stattdessen 7 und kann das erneut gesendete Paket 0 als alt erkennen. Fensterberechnungen nahe dem Überlauf folgen der zyklischen Reihenfolge, nicht der gewöhnlichen Zahlengröße.

Selective Repeat (SR) speichert korrekt empfangene Pakete, auch wenn frühere fehlen. Jedes gültige Paket erhält ein eigenes ACK. Der Sender kann dann nur das Paket ersetzen, dessen Zeitgeber abläuft.

Verfolge jedes Paket einzeln

Das Fenster des Senders beginnt bei send_base, dem ältesten unquittierten Paket, und enthält $N$ zulässige Sequenznummern. Jedes ausstehende Paket hat einen logischen Zeitgeber. Ein ACK markiert genau dieses Paket als empfangen. Ein ACK jenseits der Basis verschiebt das Fenster allein nicht: Die Basis bleibt bei der ersten Lücke. Sobald diese Lücke quittiert ist, springt die Basis über bereits quittierte nachfolgende Pakete hinweg.

Das Fenster des Empfängers beginnt bei rcv_base, dem nächsten für die Auslieferung benötigten Paket. Ein gültiges Paket innerhalb des Fensters wird quittiert. Daten außerhalb der Reihenfolge werden gepuffert. Trifft das Paket an der Basis ein, liefert der Empfänger es und jedes darauf folgende lückenlos gepufferte Paket aus und hält an der nächsten Lücke an.

Ein Paket im unmittelbar vorhergehenden Fenster ist ein altes Duplikat. Der Empfänger quittiert es erneut, ohne es auszuliefern. Diese Regel ist entscheidend, wenn das ursprüngliche ACK verloren ging: Der Sender wartet möglicherweise noch, obwohl der Empfänger bereits weitergegangen ist.

Behebe einen Verlust

Setze $N=4$ und lass Paket 2 verloren gehen, nachdem der Sender 0–3 gesendet hat. Der Empfänger liefert 0 und 1 aus und quittiert sie, dann puffert und quittiert er 3. Die ersten beiden ACKs erlauben dem Sender, 4 und 5 zu übertragen. Beide werden gepuffert und einzeln quittiert, aber send_base bleibt bei 2.

Wenn der Zeitgeber von Paket 2 abläuft, wird nur 2 erneut gesendet. Sobald es ankommt, kann der Empfänger 2, 3, 4 und 5 zusammen ausliefern und rcv_base auf 6 setzen. Sobald ACK 2 den Sender erreicht, rückt auch dessen Basis auf 6 vor und überspringt die Pakete 3–5, deren ACKs er bereits besitzt.

Warum das Fenster höchstens halb so groß wie der Nummernraum ist

Der Empfänger kann dem Sender voraus sein, weil ACKs verzögert werden oder verloren gehen. Neu zulässige Nummern dürfen sich nicht mit Nummern überschneiden, die möglicherweise noch als alte Pakete erneut gesendet werden.

Angenommen, bei Zwei-Bit-Nummern 0–3 und einem Fenster der Größe drei nimmt der Empfänger 0, 1 und 2 an. Sein neues Fenster ist {3, 0, 1}. Verschwinden alle ACKs, passt ein erneut gesendetes altes Paket 0 in dieses Fenster und sieht neu aus. Der Empfänger kann es nicht von einem tatsächlich neuen Paket 0 unterscheiden, das nach einem verlorenen Paket 3 gesendet wurde.

Für gleich große Sender- und Empfängerfenster lautet die sichere Schranke

Eine Nummerierung mit drei Bit erlaubt daher SR-Fenster bis zur Größe vier, während GBN sieben erlaubt.

Unterscheide eine alte Kopie nach dem Überlauf

Fensterbeschränkungen berücksichtigen die aktuellen Fenster, aber ein reales Netz kann auch eine alte Kopie unterwegs halten, bis Nummern wiederverwendet werden. Eine maximale Paketlebensdauer begrenzt, wie lange solche Kopien überleben können. TCP nennt dies die maximale Segmentlebensdauer (MSL). Bei hohen Raten kann TCP seinen 32-Bit-Sequenznummernraum schnell wiederverwenden; daher hilft das zeitstempelbasierte PAWS, veraltete Daten zurückzuweisen.

Eine TCP-Verbindung besteht aus Zustandsinformationen auf zwei Endhosts: Puffern, Bytezählern und anderen Variablen, die beim Aufbau angelegt werden. Sie ist eine Punkt-zu-Punkt-Verbindung zwischen zwei Endpunkten und eine Vollduplexverbindung, sodass beide gleichzeitig senden können. Gewöhnliche Router leiten ihre IP-Datagramme weiter, ohne den TCP-Zustand der Endpunkte zu verwalten.

Bytes haben keine Nachrichtengrenzen

TCP erhält die Reihenfolge der Bytes, aber nicht die Grenzen der Schreibvorgänge einer Anwendung. Drei Schreibvorgänge mit je 100 Byte können die Anwendung in einem einzigen Lesevorgang mit 300 Byte oder in Lesevorgängen mit 50 und 250 Byte erreichen. Eine Anwendung, die Nachrichten austauscht, muss selbst für deren Abgrenzung sorgen, etwa durch ein Längenfeld oder ein Trennzeichen. Ein kurzer Lesevorgang belegt nicht, dass eine vollständige Nachricht angekommen ist.

Schreibvorgänge der Anwendung gelangen in einen Sendepuffer. TCP wählt Abschnitte zur Übertragung aus und behält unquittierte Daten für mögliche Übertragungswiederholungen. Eingehende Daten gelangen in einen Empfangspuffer, bis die empfangende Anwendung sie liest.

Bestimme die Größe der Daten getrennt von den Headern

Die maximale Segmentgröße (MSS) begrenzt die Anwendungsdaten in einem Segment. Sie schließt TCP- und IP-Header aus. Für einen Pfad, der IP-Datagramme mit 1.500 Byte sowie IPv4-Header mit 20 Byte und TCP-Header mit 20 Byte unterstützt, gilt:

Optionen brauchen mehr Platz, daher muss ein Sender die tatsächlichen Headerlängen berücksichtigen. Jeder Endpunkt gibt während des Handshakes die MSS bekannt, die er empfangen kann; Beschränkungen des Pfades können die sendbare Größe weiter einschränken. Ohne MSS-Option wird standardmäßig von 536 Byte Daten bei IPv4 und 1.220 bei IPv6 ausgegangen.

Lies die Headerfelder

Der minimale Header umfasst fünf 32-Bit-Wörter oder 20 Byte. Ein Datenoffset von 8 bedeutet 32 Byte, einschließlich 12 Byte über den festen Header hinaus. Der maximale Offset ist 15: insgesamt 60 Byte, mit Platz für bis zu 40 Byte Optionen.

Interpretiere Flags und Optionen

SYN synchronisiert beim Öffnen die Sequenznummern. FIN schließt eine Senderichtung. RST bricht eine Verbindung ab oder lehnt sie ab. ACK zeigt an, dass das Quittungsfeld gültig ist. PSH fordert eine umgehende Weitergabe an die Anwendung an; es erzeugt keine Nachrichtengrenze. URG zeigt an, dass der Zeiger auf dringende Daten relevant ist, obwohl für neue Anwendungen empfohlen wird, diesen Mechanismus zu vermeiden. ECE und CWR tragen Signale der expliziten Überlastbenachrichtigung.

Zu den gebräuchlichen Optionen gehören MSS, Fensterskalierung, Zeitstempel und selektive Quittung (SACK). Die Skalierung erweitert den Bereich des Empfangsfensters. Zeitstempel helfen, die RTT zu messen und veraltete Segmente zurückzuweisen. SACK beschreibt empfangene Blöcke hinter einer Lücke.

Ohne Optionen fügen TCP und IPv4 zusammen 40 Byte hinzu. Ein volles Segment mit 1.460 Byte Daten belegt ein IP-Datagramm von 1.500 Byte, davon sind etwa 97,3 % Anwendungsdaten. Ein reines ACK enthält keine Daten, belegt aber trotzdem diese 40 Byte Header.

TCP-Sequenznummern zählen Bytes, nicht Segmente. Die Sequenznummer eines Segments bezeichnet sein erstes Datenbyte. Seine Quittungsnummer beschreibt die Gegenrichtung: das nächste Byte, das dieser Sender zu empfangen erwartet.

Teile einen Datenstrom in Segmente

Eine Anfangssequenznummer (ISN) von 3.000 wird vom SYN verwendet. Das erste Datenbyte trägt daher die Nummer 3.001. Eine Datei mit 10.000 Byte braucht bei einer MSS von 1.460 sechs volle Datensegmente und ein kürzeres Segment:

Jede nächste Sequenznummer ergibt sich durch Addition der Datenlänge des vorherigen Segments. Das letzte Byte trägt die Nummer 13.000, sodass der erfolgreiche Empfang der gesamten Datei das kumulative ACK 13.001 erzeugt.

Quittiere einen lückenlosen Anfangsbereich

ACK $n$ bestätigt alle Bytes bis einschließlich $n-1$. Es bestätigt nicht Byte $n$. Hat der Empfänger die Bytes bis 4.460, erwartet er 4.461. Ein Segment, das bei 5.921 beginnt, lässt eine Lücke. Ein Empfänger, der dieses Segment puffert, sendet weiterhin ACK 4.461, weil sein lückenloser Anfangsbereich nicht gewachsen ist.

Deshalb kann die Quittung nicht einfach die größte beobachtete Sequenznummer sein. Spätere Bytes zeigen, dass hinter der Lücke etwas angekommen ist; sie füllen die Lücke nicht. Wenn der fehlende Bereich eintrifft, kann ein kumulatives ACK über bereits gepufferte Daten hinwegspringen.

Verfolge beide Richtungen unabhängig

Angenommen, das nächste Byte eines Clients ist 1.000 und das nächste Byte eines Servers ist 5.000. Der Client sendet 200 Byte Daten mit Sequenznummer 1.000 und Quittungsnummer 5.000. Die Antwort des Servers enthält 1.200 Byte mit Sequenznummer 5.000 und Quittungsnummer 1.200. Das nächste reine ACK des Clients hat Sequenznummer 1.200 und Quittungsnummer 6.200.

Der Server hat seine eigene Sequenznummer nicht aus der Länge der Anfrage abgeleitet. Jede Richtung hat eine eigene Nummerierung. Das Mitführen eines ACK mit ausgehenden Daten heißt Huckepackverfahren. Ein reines ACK verbraucht keinen Sequenznummernraum; SYN und FIN verbrauchen jeweils eine Nummer, auch ohne Daten.

Verwalte Anfangswerte und Überlauf

Endpunkte wählen beim Öffnen einer Verbindung eine ISN. Eine Uhr und eine mit einem Schlüssel berechnete Pseudozufallsfunktion der Verbindungsadressen und Ports helfen, eine neue Verbindung von alten verzögerten Segmenten zu unterscheiden und Außenstehenden das Erraten gültiger Nummern zu erschweren. Würde jede Verbindung bei null beginnen, wären beide Schutzmaßnahmen schwächer.

Die Felder sind 32 Bit lang, daher läuft die Nummerierung modulo $2^{32}$ über, nach etwa 4,3 Milliarden Byte. Bei 1 Gbit/s dauert ein Durchlauf dieses Raums etwa 34 s, bei 10 Gbit/s etwa 3,4 s. Das zeitstempelbasierte PAWS bietet auf schnellen Pfaden eine zusätzliche Prüfung auf veraltete Segmente.

Bei gewöhnlicher Rechnung fern vom Überlauf ist das nächste Byte nach einem Datensegment dessen Sequenznummer plus dessen Datenlänge. Ist ein SYN oder FIN vorhanden, berücksichtige die zusätzliche Nummer, die dieses Steuerflag verbraucht. Wende die Rechnung getrennt auf jede Richtung an.

Beim TCP-Verbindungsaufbau können beide Endpunkte eine Anfangssequenznummer bekannt geben und erfahren, dass der Kommunikationspartner sie erhalten hat. Der spätere Abbau gibt jede Richtung getrennt frei. Dieser Austausch von Steuernachrichten nutzt denselben Sequenznummernraum wie die Daten.

Verfolge den Drei-Wege-Handshake

1. Der Client erstellt einen Verbindungszustand, sendet SYN mit ISN 7.000 und wechselt in SYN_SENT.
2. Der Server antwortet mit SYN-ACK, Sequenznummer 21.000 und Quittungsnummer 7.001. Während er auf die Bestätigung wartet, befindet er sich in SYN_RCVD.
3. Der Client speichert die Nummer des Servers und sendet ACK mit Sequenznummer 7.001 und Quittungsnummer 21.001. Der Client wechselt in ESTABLISHED; der Server tut dies, wenn dieses ACK eintrifft.

Jedes SYN verbraucht eine Nummer. Das dritte Segment kann bereits Anwendungsdaten enthalten. Der gewöhnliche Handshake kostet eine Umlaufzeit, bevor der Client diese ersten Daten senden kann. Ein Austausch aus zwei Nachrichten würde dem Server nicht mitteilen, dass der Client seine ISN erhalten hat, und könnte dazu führen, dass er ein verzögertes altes SYN als neue Anfrage annimmt.

An der Socket-Schnittstelle startet connect einen aktiven Verbindungsaufbau. Ein Server lauscht auf Anfragen, und accept liefert nach dem Aufbau einen neuen Verbindungssocket zurück. Der lauschende Socket bleibt für weitere Clients verfügbar.

Schließe jede Richtung

Ein Endpunkt sendet FIN, wenn er keine weiteren Bytes mehr zu senden hat. Der Kommunikationspartner quittiert dieses FIN, indem er sein ACK um eins darüber hinaus erhöht. Der Kommunikationspartner kann seine eigenen verbleibenden Bytes noch senden: Das ist ein halbseitiger Verbindungsabbau. Sein späteres FIN schließt die andere Richtung und benötigt ebenfalls ein ACK. Der Abbau umfasst häufig vier Segmente, ein FIN und ein ACK können jedoch kombiniert werden.

Für einen Client, der zuerst schließt, ist die übliche Zustandsfolge ESTABLISHED → FIN_WAIT_1 nach dem Senden von FIN → FIN_WAIT_2, sobald dieses FIN quittiert ist → TIME_WAIT nach Empfang und Quittierung des FIN des Kommunikationspartners → CLOSED. Der Kommunikationspartner durchläuft CLOSE_WAIT, während seine Anwendung ihre Arbeit beendet, dann LAST_ACK nach dem Senden seines eigenen FIN und schließlich CLOSED beim Empfang des ACK.

Halte das letzte ACK wiederholbar

Beim üblichen aktiven Verbindungsabbau dauert TIME_WAIT die doppelte maximale Segmentlebensdauer. Verschwindet das letzte ACK, kann der andere Endpunkt sein FIN erneut senden und ein weiteres ACK erhalten. Das Warten gibt alten Segmenten außerdem Zeit zu verfallen, bevor das Vierertupel der Verbindung wiederverwendet wird. Der MSL-Wert des Standards von zwei Minuten ergibt vier Minuten; Implementierungen können andere Zeiten verwenden, ein vertrauter Linux-Wert sind 60 Sekunden.

Ein RST unterscheidet sich von FIN: Es bricht die Verbindung ab oder lehnt eine Anfrage ab. Ein SYN an einen geschlossenen Port erhält normalerweise RST. SYN-ACK zeigt einen lauschenden Dienst an; ausbleibende Antworten können durch Filterung, Verlust oder ein nicht verfügbares Ziel entstehen.

Schütze unvollständige Handshakes

Bei einem SYN-Flooding werden viele Verbindungsanfragen gesendet, ohne sie abzuschließen. Ein Server, der für jede halboffene Verbindung Ressourcen reserviert, kann seinen verfügbaren Zustandsspeicher aufbrauchen. SYN-Cookies verzögern die Reservierung dieses Zustands pro Verbindung. Der Server kodiert überprüfbare Verbindungsinformationen mithilfe eines Geheimnisses und einer zeitabhängigen Eingabe in seine gewählte ISN. Ein gültiges abschließendes ACK gibt das Cookie über seine Quittungsnummer zurück, sodass der Server es prüfen und Zustandsinformationen anlegen kann. Der Server hat weiterhin einen lauschenden Socket und gemeinsam genutzte Ressourcen; er vermeidet es, für jedes SYN eine einzelne unvollständige Verbindung zu speichern.

TCP braucht ein Wiederholungszeitlimit, das lang genug für normale Umlaufzeiten ist, aber kurz genug, um sich nach einem Verlust rasch zu erholen. Die RTT schwankt mit Änderungen von Warteschlangen und Pfaden. Daher richtet sich das Zeitlimit sowohl nach einer geglätteten Schätzung als auch nach der Größe der jüngsten Abweichungen.

Nimm einen eindeutigen Messwert

SampleRTT misst die Zeitspanne vom Senden der Daten bis zum Empfang eines ACK, das sie abdeckt. In einer einfachen Implementierung misst TCP jeweils ein geeignetes Segment. Der Karn-Algorithmus schließt erneut übertragene Daten von der gewöhnlichen RTT-Messung aus: Ein ACK könnte sich auf die ursprüngliche Kopie oder die Ersatzkopie beziehen. Ausgehandelte Zeitstempel können diese Mehrdeutigkeit beseitigen.

Der erste gültige Messwert $R$ setzt EstimatedRTT zunächst auf $R$ und DevRTT auf $R\mathrm{/}2$. Bevor ein Messwert vorliegt, beträgt das empfohlene anfängliche Zeitlimit 1 s.

Aktualisiere die Schwankung vor dem Mittelwert

Verwende für einen neuen Messwert die vorherige EstimatedRTT, um die Abweichung zu messen:

Aktualisiere dann den exponentiell gewichteten gleitenden Mittelwert:

Die empfohlenen Gewichte sind $\beta =1\mathrm{/}4$ und $\alpha =1\mathrm{/}8$. Ältere Messwerte behalten nach jeder Aktualisierung weniger Einfluss. Würde zuerst der Mittelwert aktualisiert, änderte sich die in der ersten Gleichung verwendete Abweichung.

Rechne eine Aktualisierung durch

Beginne mit EstimatedRTT = 100 ms und DevRTT = 10 ms; nimm einen Messwert von 120 ms.

1. Absolute Abweichung: $\mathrm{\mid }120-100\mathrm{\mid }=20\text{ ms}$.
2. Neue DevRTT: $\mathrm{0,75}(10)+\mathrm{0,25}(20)=\mathrm{12,5}\text{ ms}$.
3. Neue EstimatedRTT: $\mathrm{0,875}(100)+\mathrm{0,125}(120)=\mathrm{102,5}\text{ ms}$.
4. Grundlegendes Zeitlimit: $\mathrm{102,5}+4(\mathrm{12,5})=\mathrm{152,5}\text{ ms}$.

Die Grundregel lautet:

Der vollständige Standard verwendet EstimatedRTT + max(G, 4 DevRTT), wobei $G$ die Auflösung der Uhr ist. Wenn der Sicherheitsabstand aus vier Abweichungen das Uhrintervall übersteigt, liefert die Grundregel dasselbe Ergebnis.

Der Standard empfiehlt, einen berechneten Wert unter 1 s auf 1 s anzuheben. Tatsächliche Implementierungen können eine kleinere Untergrenze verwenden; ein häufiges Linux-Minimum ist 200 ms. Die berechneten 152,5 ms sind daher ein Rohwert und nicht unbedingt der Zeitgeberwert, den ein Host einstellt. Eine optionale Obergrenze muss mindestens 60 s betragen.

Erhöhe das Zeitlimit nach einer Zeitüberschreitung

Läuft der Zeitgeber ab, sendet TCP die ältesten unquittierten Daten erneut und verdoppelt das Zeitlimit. Aus einem aktuellen Wert von 0,75 s werden 1,5 s, nach einem weiteren Ablauf 3 s. Wiederholte sofortige Versuche würden zusätzlichen Verkehr auf einem Pfad erzeugen, der bereits keine Rückmeldungen zustellt.

Ein neu eintreffendes ACK verkürzt das erhöhte Zeitlimit nicht unbedingt. TCP braucht eine gültige neue RTT-Messung, um die Schätzung neu zu berechnen. Ohne Zeitstempel verhindert die Mehrdeutigkeit bei Übertragungswiederholungen, dass ein ACK für erneut gesendete Daten als neuer Messwert verwendet wird. Sobald geeignete neue Daten gesendet und quittiert werden, kann ein frischer Messwert das berechnete Zeitlimit senken.

TCP kombiniert eine Prüfsumme, Bytesequenznummern, kumulative ACKs und Übertragungswiederholungen, um einen zuverlässigen Datenstrom zu liefern. Der Sender muss ein ACK, das den bestätigten Bereich erweitert, von einem unterscheiden, das die aktuelle Grenze wiederholt.

Verfolge die Ereignisse des Senders

SendBase ist das erste unquittierte Byte; NextSeqNum ist die nächste ungenutzte Bytenummer. Neue Anwendungsdaten werden mit der Sequenznummer NextSeqNum gesendet, die anschließend um die Datenlänge erhöht wird. Läuft kein Zeitgeber für Übertragungswiederholungen, startet das Senden ausstehender Daten ihn.

Der empfohlene grundlegende Zeitgeberalgorithmus verwendet einen Zeitgeber für Übertragungswiederholungen für das älteste unquittierte Segment. Eine Zeitüberschreitung überträgt dieses älteste ausstehende Segment erneut, verdoppelt das Intervall und startet den Zeitgeber neu. Ein ACK größer als SendBase verschiebt die Basis und startet den Zeitgeber neu, falls Daten ausstehen. Ist alles quittiert, stoppt der Zeitgeber. Eine Duplikatquittung verschiebt die Basis nicht.

Verlorene ACKs können sich erledigen

A sendet 500 Byte beginnend bei 501. B empfängt sie und sendet ACK 1.001, das verloren geht. Bestätigt nichts anderes diese Bytes, läuft bei A das Zeitlimit ab und A sendet sie erneut. B erkennt das Duplikat, liefert keine zusätzlichen Daten aus und sendet ACK 1.001 erneut.

Angenommen, A hätte auch die nächsten 500 Byte ab 1.001 gesendet. Trifft ACK 1.501 vor der Zeitüberschreitung ein, bestätigt es beide Segmente. Der Verlust von ACK 1.001 erfordert keine Übertragungswiederholung. Ein ACK ist kumulativ, daher braucht der Sender nicht für jedes Segment ein eigenes, nicht verlorenes ACK.

Bei einer vorzeitigen Zeitüberschreitung sendet A nur das älteste Segment erneut. Bestätigen verzögerte ACKs anschließend beide ursprünglichen Segmente, muss A das zweite nicht erneut senden. Eine Zeitüberschreitung ist ein Beleg dafür, dass die Rückmeldung nicht rechtzeitig ankam, kein Beweis, dass jedes ausstehende Segment verschwunden ist.

Nutze den Zeitpunkt von ACKs, um Lücken zu melden

Bei Daten in der richtigen Reihenfolge ohne ausstehendes ACK darf der Empfänger ein ACK kurz, um weniger als 0,5 s, verzögern, um Quittungen zusammenzufassen. Er sollte mindestens jedes zweite Segment voller Größe quittieren. Ein zweites in der richtigen Reihenfolge eintreffendes Segment löst bei ausstehendem ACK ein kumulatives ACK aus. Eine Ankunft außerhalb der Reihenfolge hinter einer Lücke löst sofort eine Duplikatquittung aus; auch das vollständige oder teilweise Füllen einer Lücke löst sofort ein ACK aus.

Fülle eine Lücke vor der Zeitüberschreitung

Angenommen, A sendet fünf Segmente mit je 1.000 Byte, beginnend bei 1.001, 2.001, 3.001, 4.001 und 5.001. Das zweite geht verloren. Das ACK von B nach dem ersten lautet 2.001. Die drei späteren Ankünfte erzeugen jeweils ein weiteres ACK 2.001.

Nach drei Duplikatquittungen sendet A das bei 2.001 beginnende Segment mittels Fast Retransmit erneut, ohne die Zeitüberschreitung abzuwarten. Da die späteren Daten gepuffert sind, kann B nach dem Füllen dieser Lücke mit 6.001 quittieren. Das erste ACK 2.001 ist das ursprüngliche ACK; die nächsten drei sind Duplikate. Ein oder zwei Duplikate können durch eine gewöhnliche Änderung der Reihenfolge entstehen, weshalb auf weitere Belege gewartet wird.

TCP kombiniert Ideen beider Fensterprotokolle. Seine kumulativen ACKs und der grundlegende einzelne Zeitgeber ähneln GBN, seine Pufferung und gezielten Übertragungswiederholungen jedoch SR. Ausgehandeltes SACK meldet Byteblöcke hinter der kumulativen Grenze, die bereits vorliegen, sodass der Sender mehrere Lücken genauer identifizieren kann. TCP sendet bei fehlgeschlagener Prüfsumme kein NAK; die entstehende Lücke wird durch spätere ACKs oder eine Zeitüberschreitung sichtbar.

Flusskontrolle verhindert, dass ein TCP-Sender den Puffer des Empfängers überfüllt. Sie reagiert darauf, wie schnell die empfangende Anwendung liest. Überlastkontrolle reagiert auf die Last im Netz; die beiden Steuerungen schützen unterschiedliche Ressourcen.

Berechne den verfügbaren Platz

RcvBuffer sei die Pufferkapazität, LastByteRcvd das letzte in der richtigen Reihenfolge gespeicherte Byte und LastByteRead das letzte von der Anwendung gelesene Byte. In diesem Modell lückenloser Daten beträgt der belegte Platz LastByteRcvd − LastByteRead. Das Empfangsfenster ist

Der Empfänger kündigt den verfügbaren Platz im Fensterfeld seiner zurückgesendeten Segmente an. Der Sender hält die Anzahl seiner unquittierten Bytes innerhalb dieses Spielraums:

Bei RcvBuffer = 40.000 Byte, LastByteRcvd = 30.000 und LastByteRead = 18.000 beträgt die Belegung 12.000 und rwnd 28.000 Byte. ACK 30.001 mit diesem Fenster erlaubt unquittierte Bytes bis einschließlich 58.000. Hat der Sender bereits bis einschließlich 34.000 gesendet, hat er 4.000 ausstehende Bytes und darf noch 24.000 senden. Das Fenster ist ein Spielraum für alle ausstehenden Bytes, kein zusätzlicher Spielraum darüber hinaus.

Setze nach einem Nullfenster fort

Ist kein Platz mehr vorhanden, kündigt der Empfänger rwnd = 0 an und der Sender stoppt die normale Übertragung neuer Daten. Wenn die Anwendung liest, kündigt der Empfänger den neu verfügbaren Platz in einer Fensteraktualisierung an.

Diese Aktualisierung kann ein reines ACK sein, das für sich genommen nicht zuverlässig zugestellt wird. Geht es verloren, könnte der Sender weiter warten, obwohl Platz vorhanden ist. Nullfenstersonden, die häufig ein Byte enthalten, veranlassen den Empfänger, sein aktuelles Fenster zurückzumelden. Die Abstände zwischen den Testanfragen wachsen; sie sind keine normale Übertragung großer Datenmengen durch ein geschlossenes Fenster.

Setze das Fenster zum Durchsatz in Beziehung

Bei festem Fenster und fester RTT gilt für den idealen fensterbegrenzten Durchsatz:

Verwende Byte und Sekunden, um Byte/s zu erhalten. Ein Fenster von 65.535 Byte erlaubt bei einer RTT von 0,1 s etwa 655.350 Byte/s oder 5,2 Mbit/s. Eine höhere Übertragungsrate kann diese Fenstergrenze nicht beseitigen.

Um einen Pfad auszulasten, muss das Fenster sein Bandbreiten-Verzögerungs-Produkt abdecken. Bei 1 Gbit/s und 0,1 s betragen die benötigten Daten unterwegs 100 Millionen Bit oder 12,5 MB. Das ist eine notwendige Fenstergröße für diese ideale Rate, keine Garantie, sie zu erreichen.

Skaliere das Feld und vermeide winzige Aktualisierungen

Das 16-Bit-Feld allein kann ein so großes Fenster nicht darstellen. Eine in SYNs ausgehandelte Option zur Fensterskalierung multipliziert spätere Fensterwerte mit $2^s$, wobei $s\le 14$ gilt. Die größte Skalierung ergibt etwas weniger als 1 GiB. Eine Verschiebung um 7 erlaubt höchstens 8.388.480 Byte; eine Verschiebung um 8 erlaubt 16.776.960 und reicht für das Beispiel mit 12,5 MB. Der Skalierungsfaktor bleibt für seine Richtung fest, während sich der angekündigte Platz ändert. Die Fensterfelder der SYNs selbst werden nicht skaliert.

Die Ankündigung nach jeweils wenigen neu freigegebenen Bytes kann das Silly-Window-Syndrom verursachen: viele winzige Segmente mit großem Header-Overhead. Um dies zu vermeiden, wartet der Empfänger auf eine brauchbare Menge freien Platzes, häufig eine MSS oder die Hälfte des Puffers, je nachdem, welcher Wert kleiner ist. Der Nagle-Algorithmus behandelt kleine Schreibvorgänge des Senders, indem er sie zurückhält, solange frühere Daten unquittiert sind, oder bis genügend Daten für ein volles Segment vorliegen.