4. TRANSPORTPROTOKOLLE (TRANSPORT PROTOCOLS)

4.1 BENUTZER-DATAGRAMM-PROTOKOLL -- UDP (USER DATAGRAM PROTOCOL)

4.1.1 EINFÜHRUNG (INTRODUCTION)

Das Benutzer-Datagramm-Protokoll (User Datagram Protocol, UDP) [UDP:1] bietet nur einen minimalen Transportdienst -- ungesicherte Datagramm-Zustellung -- und gibt Anwendungen direkten Zugriff auf den Datagramm-Dienst der IP-Schicht. UDP wird von Anwendungen verwendet, die nicht das Dienstniveau von TCP benötigen oder die Kommunikationsdienste nutzen möchten (z.B. Multicast- oder Broadcast-Zustellung), die mit TCP nicht verfügbar sind.

UDP ist fast ein Null-Protokoll; die einzigen Dienste, die es über IP hinaus bietet, sind die Prüfsumme der Daten und das Multiplexing nach Portnummer. Daher muss ein auf UDP laufendes Anwendungsprogramm direkt mit den End-to-End-Kommunikationsproblemen umgehen, die ein verbindungsorientiertes Protokoll behandelt hätte -- zum Beispiel Neuübertragung für zuverlässige Zustellung, Paketierung und Reassemblierung, Flusskontrolle, Staukontrolle usw., wenn diese benötigt werden. Die ziemlich komplexe Kopplung zwischen IP und TCP wird sich in der Kopplung zwischen UDP und vielen Anwendungen widerspiegeln, die UDP verwenden.

4.1.2 PROTOKOLLDURCHLAUF (PROTOCOL WALK-THROUGH)

Es gibt keine bekannten Fehler in der UDP-Spezifikation.

4.1.3 SPEZIFISCHE PROBLEME (SPECIFIC ISSUES)

4.1.3.1 Ports

UDP-Well-Known-Ports folgen denselben Regeln wie TCP-Well-Known-Ports; siehe Abschnitt 4.2.2.1 unten.

Wenn ein Datagramm an einen UDP-Port adressiert ankommt, für den kein ausstehender LISTEN-Aufruf vorhanden ist, SOLLTE UDP eine ICMP-Meldung "Port Unreachable" senden.

4.1.3.2 IP-Optionen (IP Options)

UDP MUSS alle von der IP-Schicht empfangenen IP-Optionen transparent an die Anwendungsschicht weiterleiten.

Eine Anwendung MUSS in der Lage sein, IP-Optionen anzugeben, die in ihren UDP-Datagrammen gesendet werden sollen, und UDP MUSS diese Optionen an die IP-Schicht weiterleiten.

DISKUSSION (DISCUSSION):

Derzeit sind die einzigen Optionen, die durch UDP weitergeleitet werden müssen, Source Route, Record Route und Time Stamp. Es können jedoch in Zukunft neue Optionen definiert werden, und UDP muss und sollte keine Annahmen über das Format oder den Inhalt von Optionen treffen, die es an die oder von der Anwendung weiterleitet; eine Ausnahme könnte eine IP-Schicht-Sicherheitsoption sein.

Eine UDP-basierte Anwendung muss eine Source Route aus einem Anforderungsdatagramm erhalten und eine umgekehrte Route bereitstellen, um die entsprechende Antwort zu senden.

4.1.3.3 ICMP-Nachrichten (ICMP Messages)

UDP MUSS alle von der IP-Schicht empfangenen ICMP-Fehlermeldungen an die Anwendungsschicht weiterleiten. Konzeptionell kann dies zumindest durch einen Aufwärts-Aufruf an die ERROR_REPORT-Routine erreicht werden (siehe Abschnitt 4.2.4.1).

DISKUSSION:

Beachten Sie, dass ICMP-Fehlermeldungen, die durch das Senden eines UDP-Datagramms entstehen, asynchron empfangen werden. Eine UDP-basierte Anwendung, die ICMP-Fehlermeldungen empfangen möchte, ist verantwortlich für die Aufrechterhaltung des notwendigen Zustands, um diese Nachrichten bei ihrem Eintreffen zu demultiplexen; zum Beispiel kann die Anwendung einen ausstehenden Empfangsvorgang für diesen Zweck aufrechterhalten. Die Anwendung ist auch verantwortlich für die Vermeidung von Verwirrung durch verzögerte ICMP-Fehlermeldungen, die aus einer früheren Verwendung desselben Ports oder derselben Ports resultieren.

4.1.3.4 UDP-Prüfsummen (UDP Checksums)

Ein Host MUSS die Fähigkeit implementieren, UDP-Prüfsummen zu generieren und zu validieren. Eine Anwendung KANN optional in der Lage sein zu kontrollieren, ob eine UDP-Prüfsumme generiert wird, aber sie MUSS standardmäßig eingeschaltet sein.

Wenn ein UDP-Datagramm mit einer ungleich Null aber ungültigen Prüfsumme empfangen wird, MUSS UDP das Datagramm stillschweigend verwerfen. Eine Anwendung KANN optional in der Lage sein zu kontrollieren, ob UDP-Datagramme ohne Prüfsummen verworfen oder an die Anwendung weitergeleitet werden sollen.

DISKUSSION:

Einige Anwendungen, die normalerweise nur auf lokalen Netzwerken laufen, wählen aus Effizienzgründen das Deaktivieren von UDP-Prüfsummen. Infolgedessen wurden viele Fälle von nicht erkannten Fehlern gemeldet. Die Empfehlungen, ob UDP-Prüfsummen deaktiviert werden sollten, sind sehr umstritten.

IMPLEMENTIERUNG (IMPLEMENTATION):

Es gibt einen häufigen Implementierungsfehler bei der UDP-Prüfsumme. Im Gegensatz zur TCP-Prüfsumme ist die UDP-Prüfsumme optional; eine Null, die im Prüfsummenfeld des UDP-Headers übertragen wird, zeigt das Fehlen einer Prüfsumme an. Wenn die vom Sender tatsächlich berechnete UDP-Prüfsumme Null ist, muss sie als Alle Einsen (65535) übertragen werden. Der Empfänger muss keine besonderen Maßnahmen ergreifen, da in Einerkomplement-Arithmetik Null und 65535 äquivalent sind.

4.1.3.5 UDP-Multihoming

Wenn ein UDP-Datagramm empfangen wird, MUSS seine spezifische Zieladresse an die Anwendungsschicht weitergeleitet werden.

Eine Anwendung MUSS in der Lage sein, die zu verwendende IP-Quelladresse zum Senden eines UDP-Datagramms anzugeben oder sie unspezifiziert zu lassen (in diesem Fall wählt die Netzwerksoftware eine geeignete Quelladresse aus). Es SOLLTE eine Möglichkeit geben, die ausgewählte Quelladresse an die Anwendungsschicht zu übermitteln (z.B. damit die Anwendung später nur Antwort-Datagramme von der entsprechenden Schnittstelle empfangen kann).

DISKUSSION:

Anforderungs-/Antwort-Anwendungen, die UDP verwenden, sollten dieselbe Quelladresse für die Antwort verwenden wie die spezifische Zieladresse der Anforderung. Siehe den Abschnitt "General Issues" von [INTRO:1].

4.1.3.6 Ungültige Adressen (Invalid Addresses)

UDP-Datagramme, die mit einer ungültigen IP-Quelladresse empfangen werden (z.B. eine Broadcast- oder Multicast-Adresse), MÜSSEN von UDP oder der IP-Schicht verworfen werden (siehe Abschnitt 3.2.1.3).

Wenn ein Host ein UDP-Datagramm sendet, MUSS die Quelladresse eine (oder mehrere) der IP-Adressen des Hosts sein.

4.1.4 UDP/ANWENDUNGSSCHICHT-SCHNITTSTELLE (UDP/APPLICATION LAYER INTERFACE)

Die Anwendungsschnittstelle von UDP MUSS den vollständigen Satz von Diensten der IP/Transport-Schnittstelle bereitstellen, die in Abschnitt 3.4 dieses Dokuments beschrieben sind. Daher benötigen Anwendungen, die UDP verwenden, die in Abschnitt 3.4 beschriebenen Funktionen GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB() und RECV_ICMP(). Zum Beispiel kann GET_MAXSIZES() verwendet werden, um die effektive maximale UDP-Datagrammgröße für ein bestimmtes {Schnittstelle, entfernter Host, TOS}-Tripel zu erfahren.

Anwendungsschichtprogramme MÜSSEN in der Lage sein, TTL- und TOS-Werte zum Senden eines UDP-Datagramms und IP-Optionen festzulegen, und diese Werte müssen transparent an die IP-Schicht weitergeleitet werden. UDP KANN das empfangene TOS an die Anwendungsschicht weiterleiten.

4.1.5 ZUSAMMENFASSUNG DER UDP-ANFORDERUNGEN (UDP REQUIREMENTS SUMMARY)

Feature	Abschnitt	MUSS	SOLLTE	KANN	MUSS NICHT
UDP
UDP sendet Port Unreachable	4.1.3.1		x
IP-Optionen in UDP
- Empfangene IP-Optionen an Anwendung weiterleiten	4.1.3.2	x
- Anwendung kann IP-Optionen beim Senden angeben	4.1.3.2	x
- UDP leitet IP-Optionen an IP-Schicht weiter	4.1.3.2	x
ICMP-Nachrichten an Anwendung weiterleiten	4.1.3.3	x
UDP-Prüfsumme:
- Fähigkeit zum Generieren/Überprüfen der Prüfsumme	4.1.3.4	x
- Ungültige Prüfsumme stillschweigend verwerfen	4.1.3.4	x
- Option zum Senden ohne Prüfsumme	4.1.3.4			x
- Prüfsumme standardmäßig aktiviert	4.1.3.4	x
- Option zum Empfang mit erforderlicher Prüfsumme	4.1.3.4			x
UDP-Multihoming
- Spezifische Zieladresse an Anwendung weiterleiten	4.1.3.5	x
- Anwendung kann lokale IP-Adresse angeben	4.1.3.5	x
- Anwendung kann Wildcard-lokale IP-Adresse angeben	4.1.3.5	x
- Anwendung wird über verwendete lokale IP-Adresse informiert	4.1.3.5		x
Ungültige IP-Quelladresse von UDP/IP verworfen	4.1.3.6	x
Nur gültige IP-Quelladresse senden	4.1.3.6	x
UDP-Anwendungsschnittstelle
Vollständige IP-Schnittstelle von 3.4 für Anwendung bereitstellen	4.1.4	x
- TTL, TOS, IP-Optionen beim Senden angeben	4.1.4	x
- Empfangenes TOS an Anwendung weiterleiten	4.1.4			x

4.2 ÜBERTRAGUNGSSTEUERUNGSPROTOKOLL -- TCP (TRANSMISSION CONTROL PROTOCOL)

4.2.1 EINFÜHRUNG (INTRODUCTION)

Das Übertragungssteuerungsprotokoll (Transmission Control Protocol, TCP) [TCP:1] ist das wichtigste zuverlässige verbindungsorientierte virtuelle Stromkreis-Transportprotokoll der Internet-Suite. TCP bietet zuverlässige, geordnete Zustellung eines bidirektionalen Byte-Stroms. TCP wird von Anwendungen verwendet, die einen zuverlässigen verbindungsorientierten Transportdienst benötigen, wie z.B. Mail (SMTP), Dateiübertragung (FTP) und virtueller Terminaldienst (Telnet); die Anforderungen dieser Anwendungsschichtprotokolle werden in [INTRO:1] beschrieben.

4.2.2 PROTOKOLLDURCHLAUF (PROTOCOL WALK-THROUGH)

4.2.2.1 Well-Known Ports: RFC-793 Abschnitt 2.7

DISKUSSION:

TCP reserviert Portnummern im Bereich 0-255 für "Well-Known"-Ports, um auf standardisierte Dienste im Internet zuzugreifen. Der Rest des Port-Raums kann frei an Anwendungsprozesse vergeben werden. Die aktuellen Definitionen von Well-Known-Ports sind im RFC mit dem Titel "Assigned Numbers" [INTRO:6] aufgeführt. Die Voraussetzung für die Definition eines neuen Well-Known-Ports ist ein RFC, das den vorgeschlagenen Dienst mit ausreichenden Details dokumentiert, um neue Implementierungen zu ermöglichen.

Einige Systeme erweitern dieses Konzept, indem sie eine dritte Unterteilung des TCP-Port-Raums hinzufügen: reservierte Ports (reserved ports), die typischerweise für betriebssystemspezifische Dienste verwendet werden. Zum Beispiel können reservierte Ports zwischen 256 und einer systemabhängigen oberen Grenze liegen. Einige Systeme entscheiden sich weiterhin, Well-Known-Ports und reservierte Ports zu schützen, indem sie nur privilegierten Benutzern erlauben, TCP-Verbindungen mit diesen Port-Werten zu öffnen. Dies ist völlig vernünftig, solange der Host nicht annimmt, dass alle Hosts ihre niedrig nummerierten Ports auf diese Weise schützen.

4.2.2.2 Verwendung von Push: RFC-793 Abschnitt 2.8

Wenn die Anwendung eine Reihe von SEND-Aufrufen ausgibt, ohne das PUSH-Flag zu setzen, KANN TCP die Daten intern puffern, ohne sie zu senden. Ähnlich kann TCP beim Empfang einer Reihe von Segmenten ohne das PSH-Bit die Daten intern in die Warteschlange stellen, ohne sie an die empfangende Anwendung zu liefern.

Das PSH-Bit ist keine Datensatzmarkierung und ist unabhängig von Segmentgrenzen. Der Sender SOLLTE aufeinanderfolgende PSH-Bits beim Paketieren von Daten zusammenfassen, um das größtmögliche Segment zu senden.

TCP KANN das PUSH-Flag beim SEND-Aufruf implementieren. Wenn das PUSH-Flag nicht implementiert ist, dann darf das sendende TCP: (1) keine Daten auf unbestimmte Zeit puffern, und (2) MUSS das PSH-Bit im letzten gepufferten Segment setzen (d.h. wenn keine weiteren Daten in der Warteschlange zum Senden sind).

Die Diskussion in RFC-793 auf den Seiten 48, 50 und 74 legt fälschlicherweise nahe, dass das empfangene PSH-Flag an die Anwendungsschicht weitergegeben werden sollte. Die Weitergabe des empfangenen PSH-Flags an die Anwendungsschicht ist jetzt OPTIONAL.

Die Anwendung muss logischerweise das PUSH-Flag in einem SEND-Aufruf setzen, wann immer sie die Zustellung von Daten erzwingen muss, um eine Kommunikationsblockierung zu vermeiden. TCP SOLLTE jedoch Segmente mit maximaler Größe senden, wann immer möglich, um die Leistung zu verbessern (siehe Abschnitt 4.2.3.4).

DISKUSSION:

Wenn das PUSH-Flag bei SEND-Aufrufen nicht implementiert ist, d.h. wenn die Anwendungs-/TCP-Schnittstelle ein reines Strommodell verwendet, liegt die Verantwortung für die Aggregation kleiner Datenfragmente zu angemessen großen Segmenten teilweise bei der Anwendungsschicht.

Normalerweise sollten interaktive Anwendungsprotokolle das PUSH-Flag mindestens beim letzten SEND-Aufruf jeder Befehls- oder Antwortsequenz setzen. Massen-Datenübertragungsprotokolle wie FTP sollten das PUSH-Flag beim letzten Segment einer Datei setzen oder wenn es notwendig ist, um eine Pufferblockierung zu verhindern.

Auf der Empfängerseite erzwingt das PSH-Bit die Zustellung gepufferter Daten an die Anwendung (auch wenn weniger als ein vollständiger Puffer an Daten empfangen wurde). Umgekehrt kann das Fehlen des PSH-Bits verwendet werden, um unnötige Weckrufe des Anwendungsprozesses zu vermeiden; dies kann eine wichtige Leistungsoptimierung für große Timesharing-Hosts sein. Die Weitergabe des PSH-Bits an die empfangende Anwendung ermöglicht ähnliche Optimierungen innerhalb der Anwendung.

4.2.2.3 Fenstergröße: RFC-793 Abschnitt 3.1

Die Fenstergröße MUSS als vorzeichenlose Zahl behandelt werden, da große Fenstergrößen sonst als negative Fenster erscheinen und TCP nicht funktioniert. Es wird EMPFOHLEN, dass Implementierungen 32-Bit-Felder für Sende- und Empfangsfenstergrößen im Verbindungsdatensatz reservieren und 32 Bits für alle Fensterberechnungen verwenden.

DISKUSSION:

Das Fensterfeld im TCP-Header ist bekanntermaßen zu klein für Hochgeschwindigkeits- und Langstrecken-Pfade. Experimentelle TCP-Optionen wurden definiert, um die Fenstergröße zu erweitern; siehe z.B. [TCP:11]. Um die Übernahme solcher Erweiterungen zu antizipieren, sollten TCP-Implementierer das Fenster als 32-Bit behandeln.

4.2.2.4 Dringlichkeitszeiger: RFC-793 Abschnitt 3.1

Es gibt einen Fehler im zweiten Satz: Der Dringlichkeitszeiger zeigt auf die Sequenznummer des letzten Bytes (nicht LAST+1) der dringlichen Datensequenz. Die Beschreibung auf Seite 56 (letzter Satz) ist korrekt.

TCP MUSS dringliche Datensequenzen beliebiger Länge unterstützen.

TCP MUSS die Anwendungsschicht asynchron benachrichtigen, wenn ein Dringlichkeitszeiger empfangen wird und keine früheren dringlichen Daten noch ausstehen, oder wann immer der Dringlichkeitszeiger im Datenstrom vorrückt. Es MUSS eine Möglichkeit geben, dass die Anwendung erfährt, wie viele dringliche Daten noch von der Verbindung zu lesen sind, oder zumindest festzustellen, ob noch mehr dringliche Daten zu lesen sind.

DISKUSSION:

Obwohl der Dringlichkeitsmechanismus von jeder Anwendung verwendet werden kann, wird er normalerweise verwendet, um "Interrupt"-Typ-Befehle an Telnet-Programme zu senden (siehe Abschnitt "Use of Telnet Synch Sequence" in [INTRO:1]).

Die asynchrone oder "Out-of-Band"-Benachrichtigung ermöglicht es der Anwendung, in den "Dringlichkeitsmodus" zu wechseln und Daten von der TCP-Verbindung zu lesen. Dies ermöglicht das Senden von Steuerbefehlen an eine Anwendung, deren normaler Eingabepuffer mit nicht verarbeiteten Daten gefüllt ist.

IMPLEMENTIERUNG:

Der in Abschnitt 4.2.4.1 beschriebene generische Aufwärts-Aufruf ERROR-REPORT() ist ein möglicher Mechanismus, um die Anwendung über das Eintreffen dringlicher Daten zu benachrichtigen.

4.2.2.5 TCP-Optionen: RFC-793 Abschnitt 3.1

TCP MUSS in der Lage sein, TCP-Optionen in jedem Segment zu empfangen. TCP MUSS jede TCP-Option, die es nicht implementiert, ohne Fehler ignorieren, vorausgesetzt, die Option hat ein Längenfeld (alle zukünftig definierten TCP-Optionen werden ein Längenfeld haben). TCP MUSS bereit sein, eine illegale Optionslänge (z.B. Null) ohne Absturz zu behandeln; die vorgeschlagene Prozedur ist, die Verbindung zurückzusetzen und den Grund zu protokollieren.

4.2.2.6 Maximum Segment Size Option: RFC-793 Abschnitt 3.1

TCP MUSS das Senden und Empfangen der Maximum Segment Size (MSS) Option implementieren [TCP:4].

TCP SOLLTE eine MSS-Option (Maximum Segment Size) in jedem SYN-Segment senden, wenn sein Empfangs-MSS vom Standardwert 536 abweicht, und KANN sie immer senden.

Wenn beim Verbindungsaufbau keine MSS-Option empfangen wird, MUSS TCP einen Standard-Sende-MSS von 536 (576-40) annehmen [TCP:4].

Die maximale Größe der Segmente, die TCP tatsächlich sendet, der "effektive Sende-MSS", MUSS das Minimum zwischen dem Sende-MSS (der die verfügbare Reassemblierungs-Puffergröße des entfernten Hosts widerspiegelt) und der von der IP-Schicht zulässigen maximalen Größe sein:

Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

wobei:

• SendMSS ist der vom entfernten Host empfangene MSS-Wert oder der Standardwert 536, wenn keine MSS-Option empfangen wurde.
• MMS_S ist die maximale Größe einer Transportschicht-Nachricht, die TCP senden kann.
• TCPhdrsize ist die Größe des TCP-Headers; dies ist normalerweise 20, kann aber größer sein, wenn TCP-Optionen gesendet werden müssen.
• IPoptionsize ist die Größe aller IP-Optionen, die TCP mit der aktuellen Nachricht an die IP-Schicht weiterleitet.

Der in einer MSS-Option zu sendende MSS-Wert muss kleiner oder gleich sein:

MMS_R - 20

wobei MMS_R die maximale Größe einer Transportschicht-Nachricht ist, die empfangen (und reassembliert) werden kann. TCP erhält MMS_R und MMS_S von der IP-Schicht; siehe den generischen Aufruf GET_MAXSIZES in Abschnitt 3.4.

DISKUSSION:

Die Wahl der TCP-Segmentgröße hat einen starken Einfluss auf die Leistung. Größere Segmente verbessern den Durchsatz, indem sie die Header-Größe und den Verarbeitungsaufwand pro Datagramm über mehr Datenbytes amortisieren; wenn das Paket jedoch so groß ist, dass es eine IP-Fragmentierung verursacht, sinkt die Effizienz stark, wenn ein Fragment verloren geht [IP:9].

Einige TCP-Implementierungen senden die MSS-Option nur, wenn sich der Ziel-Host in einem nicht verbundenen Netzwerk befindet. Im Allgemeinen hat die TCP-Schicht jedoch möglicherweise nicht die geeigneten Informationen, um diese Entscheidung zu treffen, daher ist es am besten, die Aufgabe der Bestimmung der geeigneten MTU für den Internet-Pfad der IP-Schicht zu überlassen. Daher empfehlen wir, dass TCP immer die Option sendet (wenn sie nicht 536 ist) und dass die IP-Schicht MMS_R wie in den Abschnitten 3.3.3 und 3.4 angegeben bestimmt. Der vorgeschlagene IP-Schicht-Mechanismus zur Messung der MTU würde dann die IP-Schicht ändern, ohne TCP zu ändern.

4.2.2.7 TCP-Prüfsumme: RFC-793 Abschnitt 3.1

Im Gegensatz zur UDP-Prüfsumme (siehe Abschnitt 4.1.3.4) ist die TCP-Prüfsumme niemals optional. Der Sender MUSS sie generieren und der Empfänger MUSS sie überprüfen.

4.2.2.8 TCP-Verbindungszustandsdiagramm: RFC-793 Abschnitt 3.2, Seite 23

Es gibt mehrere Probleme mit diesem Diagramm:

(a) Der Pfeil von SYN-SENT nach SYN-RCVD sollte mit "snd SYN,ACK" beschriftet sein, um mit dem Text auf Seite 68 und Abbildung 8 übereinzustimmen.

(b) Es könnte einen Pfeil vom Zustand SYN-RCVD zum Zustand LISTEN geben, bedingt durch den Empfang eines RST nach einem passiven Open (siehe Text auf Seite 70).

(c) Es ist möglich, direkt vom Zustand FIN-WAIT-1 in den Zustand TIME-WAIT zu gehen (siehe Seite 75 der Spezifikation).

4.2.2.9 Auswahl der initialen Sequenznummer: RFC-793 Abschnitt 3.3, Seite 27

TCP MUSS die angegebene uhrengesteuerte Auswahl der initialen Sequenznummer verwenden.

4.2.2.10 Gleichzeitige Öffnungsversuche: RFC-793 Abschnitt 3.4

Es gibt einen Fehler in Abbildung 8: Das Paket in Zeile 7 sollte identisch mit dem Paket in Zeile 5 sein.

TCP MUSS gleichzeitige Öffnungsversuche unterstützen.

DISKUSSION:

Es überrascht Implementierer manchmal, dass wenn zwei Anwendungen versuchen, sich gleichzeitig miteinander zu verbinden, nur eine Verbindung generiert wird anstatt zwei. Dies war eine absichtliche Design-Entscheidung; versuchen Sie nicht, sie zu "korrigieren".

4.2.2.11 Wiederherstellung von altem doppeltem SYN: RFC-793 Abschnitt 3.4, Seite 33

Beachten Sie, dass eine TCP-Implementierung MUSS nachverfolgen, ob die Verbindung den Zustand SYN_RCVD als Ergebnis eines passiven OPEN oder eines aktiven OPEN erreicht hat.

4.2.2.12 RST-Segment: RFC-793 Abschnitt 3.4

TCP SOLLTE zulassen, dass ein empfangenes RST-Segment Daten enthält.

DISKUSSION:

Es wurde vorgeschlagen, dass ein RST-Segment ASCII-Text enthalten könnte, der die Ursache des RST kodiert und erklärt. Für solche Daten wurde noch kein Standard festgelegt.

4.2.2.13 Schließen einer Verbindung: RFC-793 Abschnitt 3.5

Eine TCP-Verbindung kann auf zwei Arten enden: (1) die normale TCP-Schließsequenz unter Verwendung eines FIN-Handshakes, und (2) ein "Abort", bei dem ein oder mehrere RST-Segmente gesendet werden und der Verbindungszustand sofort gelöscht wird. Wenn eine TCP-Verbindung von der entfernten Seite geschlossen wird, MUSS die lokale Anwendung informiert werden, ob sie normal geschlossen oder abgebrochen wurde.

Die normale TCP-Schließsequenz liefert gepufferte Daten zuverlässig in beiden Richtungen. Da die beiden Richtungen einer TCP-Verbindung unabhängig geschlossen werden, ist es möglich, dass eine Verbindung "halb geschlossen" ist, d.h. in einer Richtung geschlossen, und ein Host darf weiterhin Daten in der offenen Richtung auf einer halb geschlossenen Verbindung senden.

Ein Host KANN eine "Halbduplex"-TCP-Schließsequenz implementieren, so dass eine Anwendung, die CLOSE aufgerufen hat, nicht weiterhin Daten von der Verbindung lesen kann. Wenn ein solcher Host einen CLOSE-Aufruf ausgibt, während empfangene Daten noch in TCP ausstehen, oder wenn neue Daten nach dem CLOSE-Aufruf empfangen werden, SOLLTE sein TCP ein RST senden, um zu zeigen, dass Daten verloren gegangen sind.

Wenn eine Verbindung aktiv geschlossen wird, MUSS sie für eine Zeit von 2×MSL (Maximum Segment Lifetime) im TIME-WAIT-Zustand bleiben. Sie KANN jedoch einen neuen SYN vom entfernten TCP akzeptieren, um die Verbindung direkt vom TIME-WAIT-Zustand aus wiederzueröffnen, wenn sie:

(1) ihre initiale Sequenznummer für die neue Verbindung größer als die größte Sequenznummer zuweist, die sie bei der vorherigen Verbindungsinkarnation verwendet hat, und

(2) zum TIME-WAIT-Zustand zurückkehrt, wenn sich das SYN als altes Duplikat erweist.

DISKUSSION:

Der vollständige Vollduplex-Abschluss mit Datenerhaltung von TCP ist eine Funktion, die nicht im analogen ISO-Transportprotokoll TP4 enthalten ist.

Einige Systeme haben keine halb geschlossenen Verbindungen implementiert, wahrscheinlich weil sie nicht in das E/A-Modell ihres bestimmten Betriebssystems passen. Bei diesen Systemen kann eine Anwendung, sobald sie CLOSE aufgerufen hat, keine Eingabedaten mehr von der Verbindung lesen; dies wird als "Halbduplex"-TCP-Schließsequenz bezeichnet.

Der TCP-Graceful-Close-Algorithmus erfordert, dass der Verbindungszustand auf (mindestens) einem Ende der Verbindung für einen Timeout-Zeitraum von 2×MSL, d.h. 4 Minuten, definiert bleibt. Während dieses Zeitraums ist das (entfernte Socket, lokales Socket)-Paar, das die Verbindung definiert, belegt und kann nicht wiederverwendet werden. Um die Zeit zu verkürzen, in der ein bestimmtes Socketpaar belegt ist, erlauben einige TCPs, dass ein neuer SYN im TIME-WAIT-Zustand akzeptiert wird.

4.2.2.14 Datenkommunikation: RFC-793 Abschnitt 3.7, Seite 40

Seit dem Schreiben von RFC-793 gab es umfangreiche Arbeiten an TCP-Algorithmen zur Erreichung effizienter Datenkommunikation. Spätere Abschnitte dieses Dokuments beschreiben die erforderlichen und empfohlenen TCP-Algorithmen zur Bestimmung, wann Daten gesendet werden (Abschnitt 4.2.3.4), wann eine Bestätigung gesendet wird (Abschnitt 4.2.3.2) und wann das Fenster aktualisiert wird (Abschnitt 4.2.3.3).

DISKUSSION:

Ein wichtiges Leistungsproblem ist das "Silly Window Syndrome" oder "SWS" [TCP:5], ein stabiles Muster kleiner inkrementeller Fensterbewegungen, das zu extrem schlechter TCP-Leistung führt. Algorithmen zur Vermeidung von SWS werden unten für die Sendeseite (Abschnitt 4.2.3.4) und die Empfangsseite (Abschnitt 4.2.3.3) beschrieben.

Kurz gesagt, SWS wird durch den Empfänger verursacht, der den rechten Rand des Fensters jedes Mal vorrückt, wenn er neuen Pufferspeicherplatz zum Empfangen von Daten verfügbar hat, und durch den Sender, der jedes inkrementelle Fenster, egal wie klein, zum Senden von mehr Daten verwendet [TCP:5]. Das Ergebnis kann ein stabiles Muster des Sendens winziger Datensegmente sein, selbst wenn sowohl Sender als auch Empfänger beide über großen gesamten Pufferspeicherplatz für die Verbindung verfügen. SWS kann nur während der Übertragung einer großen Datenmenge auftreten; wenn die Verbindung inaktiv wird, verschwindet das Problem. Es wird durch eine typische einfache Implementierung der Fensterverwaltung verursacht, aber die unten angegebenen Sender- und Empfängeralgorithmen werden es vermeiden.

Ein weiteres wichtiges TCP-Leistungsproblem ist, dass einige Anwendungen, insbesondere Zeichen-für-Zeichen-Remote-Anmeldung zu Hosts, dazu neigen, Ströme von Ein-Byte-Datensegmenten zu senden. Um Deadlocks zu vermeiden, muss jeder TCP-SEND-Aufruf solcher Anwendungen "gepusht" werden, entweder explizit durch die Anwendung oder implizit durch TCP. Das Ergebnis kann ein Strom von TCP-Segmenten sein, die jeweils ein Byte Daten enthalten, was das Internet sehr ineffizient macht und zur Internet-Überlastung beiträgt. Der in Abschnitt 4.2.3.4 beschriebene Nagle-Algorithmus bietet eine einfache und effektive Lösung für dieses Problem. Er hat den Effekt, Zeichen auf Telnet-Verbindungen zu gruppieren; dies kann Benutzer, die an Einzelzeichen-Echo gewöhnt sind, zunächst überraschen, aber diese Gruppierung ist sowohl für das Netzwerk als auch für die Antwortzeit des Benutzers vorteilhaft.

Die Benutzerakzeptanz war kein Problem.

Beachten Sie, dass der Nagle-Algorithmus und der SWS-Vermeidungsalgorithmus auf der Sendeseite komplementäre Rollen bei der Verbesserung der Leistung spielen. Der Nagle-Algorithmus verhindert das Senden winziger Segmente, wenn die zu sendenden Daten in kleinen Schritten zunehmen, während der SWS-Vermeidungsalgorithmus kleine Segmente verhindert, die durch das Vorrücken des rechten Rands des Fensters in kleinen Schritten entstehen.

Eine nachlässige Implementierung kann zwei oder mehr Bestätigungssegmente pro empfangenem Datensegment senden. Nehmen wir zum Beispiel an, dass der Empfänger jedes Datensegment sofort bestätigt. Wenn das Anwendungsprogramm dann die Daten verbraucht und den verfügbaren Empfangspufferspeicherplatz erneut erhöht, kann der Empfänger ein zweites Bestätigungssegment senden, um das Fenster des Senders zu aktualisieren. Der Extremfall tritt bei Ein-Zeichen-Segmenten auf TCP-Verbindungen auf, die das Telnet-Protokoll für den Remote-Anmeldedienst verwenden. Einige Implementierungen wurden beobachtet, bei denen jedes eingehende Ein-Zeichen-Segment drei Rücksegmente generiert: (1) die Bestätigung, (2) eine Ein-Byte-Fenstervergrößerung und (3) das Echo-Zeichen.

4.2.2.15 Neuübertragungstimeout: RFC-793 Abschnitt 3.7, Seite 41

Der in RFC-793 vorgeschlagene Algorithmus zur Berechnung des Neuübertragungstimeouts ist jetzt bekanntermaßen unzureichend; siehe Abschnitt 4.2.3.1 unten.

Aktuelle Arbeiten von Jacobson [TCP:7] über Internet-Überlastung und TCP-Neuübertragungsstabilität haben einen kombinierten Übertragungsalgorithmus hervorgebracht, der "Slow Start" mit "Congestion Avoidance" kombiniert. Ein TCP MUSS diesen Algorithmus implementieren.

Wenn ein neuübertragenes Paket identisch mit dem ursprünglichen Paket ist (was impliziert, dass sich nicht nur die Datengrenzen nicht geändert haben, sondern auch die Fenster- und Bestätigungsfelder des Headers nicht geändert haben), dann KANN dasselbe IP-Identifikationsfeld verwendet werden (siehe Abschnitt 3.2.1.5).

IMPLEMENTIERUNG:

Einige TCP-Implementierer haben sich entschieden, den Datenstrom zu "paketieren", d.h. Segmentgrenzen zu wählen, wenn Segmente ursprünglich gesendet werden, und diese Segmente in eine "Neuübertragungswarteschlange" einzureihen, bis sie bestätigt werden. Ein anderes Design (das möglicherweise einfacher ist) besteht darin, die Paketierung jedes Mal zu verschieben, wenn Daten übertragen oder neuübertragen werden, so dass es keine Segment-Neuübertragungswarteschlange gibt.

In einer Implementierung mit einer Segment-Neuübertragungswarteschlange kann die TCP-Leistung verbessert werden, indem Segmente, die auf Bestätigung warten, neu paketiert werden, wenn das erste Neuübertragungstimeout auftritt. Das heißt, ausstehende Segmente, die passen würden, würden zu einem Segment maximaler Größe kombiniert, mit einem neuen Identifikationswert. Das TCP würde dann dieses kombinierte Segment in der Neuübertragungswarteschlange behalten, bis es bestätigt wird. Wenn jedoch die ersten beiden Segmente in der Neuübertragungswarteschlange insgesamt mehr als ein Segment maximaler Größe ergeben würden, würde das TCP nur das erste Segment unter Verwendung des ursprünglichen Identifikationsfelds neuübertragen.

4.2.2.16 Fensterverwaltung: RFC-793 Abschnitt 3.7, Seite 41

Ein empfangendes TCP SOLLTE NICHT das Fenster schrumpfen, d.h. den rechten Rand des Fensters nach links bewegen. Ein sendendes TCP MUSS jedoch robust gegen Fensterschrumpfung sein, die dazu führen kann, dass das "nutzbare Fenster" (siehe Abschnitt 4.2.3.4) negativ wird.

Wenn dies geschieht, SOLLTE der Sender keine neuen Daten senden, SOLLTE aber alte nicht bestätigte Daten zwischen SND.UNA und SND.UNA+SND.WND normal neuübertragen. Der Sender KANN auch alte Daten jenseits von SND.UNA+SND.WND neuübertragen, SOLLTE aber die Verbindung nicht wegen Timeout beenden, wenn Daten jenseits des rechten Rands des Fensters nicht bestätigt werden. Wenn das Fenster auf Null schrumpft, MUSS das TCP es auf die Standardweise testen (siehe nächster Abschnitt).

DISKUSSION:

Viele TCP-Implementierungen werden verwirrt, wenn das Fenster von rechts schrumpft, nachdem Daten in ein größeres Fenster gesendet wurden. Beachten Sie, dass TCP eine Heuristik hat, um die neueste Fensteraktualisierung trotz möglicher Neuordnung von Datagrammen auszuwählen; infolgedessen kann es eine Fensteraktualisierung mit einem kleineren Fenster als zuvor angeboten ignorieren, wenn weder die Sequenznummer noch die Bestätigungsnummer erhöht wird.

4.2.2.17 Testen von Null-Fenstern: RFC-793 Abschnitt 3.7, Seite 42

Das Testen von Null-(angebotenen)-Fenstern MUSS unterstützt werden.

Ein TCP KANN sein angebotenes Empfangsfenster auf unbestimmte Zeit geschlossen halten. Solange das empfangende TCP weiterhin Bestätigungen als Antwort auf die Testsegmente sendet, MUSS das sendende TCP zulassen, dass die Verbindung offen bleibt.

DISKUSSION:

Es ist äußerst wichtig zu bedenken, dass ACK-Segmente (Bestätigungen), die keine Daten enthalten, nicht zuverlässig von TCP übertragen werden. Wenn das Testen von Null-Fenstern nicht unterstützt wird, kann eine Verbindung auf unbestimmte Zeit hängen bleiben, wenn ein ACK-Segment, das das Fenster wieder öffnet, verloren geht.

Die Verzögerung beim Öffnen eines Null-Fensters tritt normalerweise auf, wenn die empfangende Anwendung aufhört, Daten von ihrem TCP zu nehmen. Betrachten Sie zum Beispiel eine Drucker-Daemon-Anwendung, die gestoppt wird, weil dem Drucker das Papier ausgeht.

Der übertragende Host SOLLTE das erste Null-Fenster-Test senden, wenn ein Null-Fenster für die Neuübertragungstimeout-Periode (siehe Abschnitt 4.2.2.15) existiert hat, und SOLLTE das Intervall zwischen aufeinanderfolgenden Tests exponentiell zurücksetzen.

DISKUSSION:

Diese Prozedur minimiert die Verzögerung, wenn die Null-Fenster-Bedingung auf ein verlorenes ACK-Segment zurückzuführen ist, das eine Fensteröffnungsaktualisierung enthält. Das exponentielle Backoff wird empfohlen, möglicherweise mit einem hier nicht spezifizierten maximalen Intervall. Diese Prozedur ist ähnlich der des Neuübertragungsalgorithmus, und es kann möglich sein, die beiden Prozeduren in der Implementierung zu kombinieren.

4.2.2.18 Passive OPEN-Aufrufe: RFC-793 Abschnitt 3.8

Jeder passive OPEN-Aufruf erstellt entweder einen neuen Verbindungsdatensatz im LISTEN-Zustand oder gibt einen Fehler zurück; er DARF NICHT einen zuvor erstellten Verbindungsdatensatz beeinflussen.

Ein TCP, das mehrere gleichzeitige Benutzer unterstützt, MUSS einen OPEN-Aufruf bereitstellen, der funktional einer Anwendung ermöglicht, auf einem Port zu LISTEN, während ein Verbindungsblock mit demselben lokalen Port im Zustand SYN-SENT oder SYN-RECEIVED ist.

DISKUSSION:

Einige Anwendungen (z.B. SMTP-Server) müssen möglicherweise mehrere Verbindungsversuche etwa gleichzeitig verarbeiten. Die Wahrscheinlichkeit, dass ein Verbindungsversuch fehlschlägt, wird reduziert, indem der Anwendung eine Möglichkeit gegeben wird, auf eine neue Verbindung zu hören, während ein früherer Verbindungsversuch den Drei-Wege-Handshake durchläuft.

IMPLEMENTIERUNG:

Akzeptable Implementierungen gleichzeitiger Opens können mehrere passive OPEN-Aufrufe zulassen, oder sie können das "Klonen" von Verbindungen im LISTEN-Zustand aus einem einzigen passiven OPEN-Aufruf ermöglichen.

4.2.2.19 Time to Live: RFC-793 Abschnitt 3.9, Seite 52

RFC-793 spezifizierte, dass TCP die IP-Schicht auffordern sollte, TCP-Segmente mit TTL = 60 zu senden. Dies ist veraltet; der zum Senden von TCP-Segmenten verwendete TTL-Wert MUSS konfigurierbar sein. Siehe Abschnitt 3.2.1.7 für die Diskussion.

4.2.2.20 Ereignisverarbeitung: RFC-793 Abschnitt 3.9

Obwohl es nicht streng erforderlich ist, SOLLTE ein TCP in der Lage sein, Segmente außerhalb der Reihenfolge in eine Warteschlange zu stellen. Ändern Sie das "may" im letzten Satz des ersten Absatzes auf Seite 70 in "should".

DISKUSSION:

Einige kleine Host-Implementierungen haben die Warteschlange von Segmenten aufgrund begrenzten Pufferspeicherplatzes weggelassen. Diese Auslassung wird voraussichtlich den TCP-Durchsatz negativ beeinflussen, da der Verlust eines einzelnen Segments alle nachfolgenden Segmente als "außerhalb der Reihenfolge" erscheinen lässt.

Im Allgemeinen MUSS die Verarbeitung empfangener Segmente so implementiert werden, dass ACK-Segmente wann immer möglich aggregiert werden. Zum Beispiel, wenn das TCP eine Reihe von Segmenten in der Warteschlange verarbeitet, MUSS es alle verarbeiten, bevor es ACK-Segmente sendet.

Hier sind einige detaillierte Fehlerkorrekturen und Notizen zum Abschnitt "Ereignisverarbeitung" von RFC-793.

(a) CLOSE-Aufruf, Zustand CLOSE-WAIT, S. 61: Zustand LAST-ACK eingeben, nicht CLOSING.

(b) LISTEN-Zustand, SYN prüfen (S. 65, 66): Mit einem SYN-Bit, wenn die Sicherheit/das Compartment oder die Priorität für das Segment falsch ist, wird ein Reset gesendet. Die falsche Form des Reset wird im Text gezeigt; es sollte sein:

<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

(c) SYN-SENT-Zustand, SYN prüfen, S. 68: Wenn die Verbindung in den ESTABLISHED-Zustand eintritt, sollten die folgenden Variablen gesetzt werden:

SND.WND <- SEG.WND
SND.WL1 <- SEG.SEQ
SND.WL2 <- SEG.ACK

(d) Sicherheit und Priorität prüfen, S. 71: Der erste "ESTABLISHED STATE"-Header sollte wirklich eine Liste aller Zustände außer SYN-RECEIVED sein: ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK und TIME-WAIT.

(e) SYN-Bit prüfen, S. 71: "Im SYN-RECEIVED-Zustand und wenn die Verbindung mit einem passiven OPEN initiiert wurde, dann diese Verbindung zum LISTEN-Zustand zurückführen und zurückkehren. Sonst...".

(f) ACK-Feld prüfen, SYN-RECEIVED-Zustand, S. 72: Wenn die Verbindung in den ESTABLISHED-Zustand eintritt, sollten die unter (c) aufgeführten Variablen gesetzt werden.

(g) ACK-Feld prüfen, ESTABLISHED-Zustand, S. 72: Das ACK ist ein Duplikat wenn SEG.ACK =< SND.UNA (das = wurde weggelassen). Ebenso sollte das Fenster aktualisiert werden wenn: SND.UNA =< SEG.ACK =< SND.NXT.

(h) USER TIMEOUT, S. 77:

Es wäre besser, die Anwendung über den Timeout zu benachrichtigen, anstatt TCP zu erlauben, die Verbindung zu zwingen. Siehe jedoch auch Abschnitt 4.2.3.5.

4.2.2.21 Bestätigung von Segmenten in der Warteschlange: RFC-793 Abschnitt 3.9

Ein TCP KANN ein ACK-Segment senden, das RCV.NXT bestätigt, wenn ein gültiges Segment ankommt, das im Fenster ist, aber nicht am linken Rand des Fensters.

DISKUSSION:

RFC-793 (siehe Seite 74) war mehrdeutig darüber, ob ein ACK-Segment gesendet werden sollte oder nicht, wenn ein Segment außerhalb der Reihenfolge empfangen wurde, d.h. wenn SEG.SEQ nicht gleich RCV.NXT war.

Ein Grund für die Bestätigung von Segmenten außerhalb der Reihenfolge könnte sein, einen experimentellen Algorithmus zu unterstützen, der als "Fast Retransmit" bekannt ist. Mit diesem Algorithmus verwendet der Sender "redundante" ACKs, um abzuleiten, dass ein Segment verloren gegangen ist, bevor der Neuübertragungstimer abläuft. Er zählt die Anzahl der Male, dass ein ACK mit demselben SEG.ACK-Wert und demselben rechten Fensterrand empfangen wurde. Wenn mehr als eine Schwellenanzahl solcher ACKs empfangen wird, wird angenommen, dass das Segment, das die Bytes beginnend bei SEG.ACK enthält, verloren gegangen ist und ohne Warten auf einen Timeout neuübertragen. Die Schwelle wird gewählt, um die maximal wahrscheinliche Neuordnung von Segmenten im Internet auszugleichen. Es gibt noch nicht genug Erfahrung mit dem Fast-Retransmit-Algorithmus, um seine Nützlichkeit zu bestimmen.

4.2.3 SPEZIFISCHE PROBLEME (SPECIFIC ISSUES)

4.2.3.1 Berechnung des Neuübertragungstimeouts (Retransmission Timeout Calculation)

Ein Host-TCP MUSS den Algorithmus von Karn und den Algorithmus von Jacobson zur Berechnung des Neuübertragungstimeouts ("RTO") implementieren.

• Der Algorithmus von Jacobson zur Berechnung der geglätteten Rundlaufzeit ("RTT") enthält eine einfache Maßnahme der Varianz [TCP:7].

• Der Algorithmus von Karn zur Auswahl von RTT-Messungen stellt sicher, dass mehrdeutige Rundlaufzeiten die Berechnung der geglätteten Rundlaufzeit nicht verfälschen [TCP:6].

Diese Implementierung MUSS auch ein "exponentielles Backoff" für aufeinanderfolgende RTO-Werte für dasselbe Segment enthalten. Die Neuübertragung von SYN-Segmenten SOLLTE denselben Algorithmus wie Datensegmente verwenden.

DISKUSSION:

Es gab zwei bekannte Probleme mit den in RFC-793 spezifizierten RTO-Berechnungen. Erstens ist die genaue Messung von RTTs schwierig, wenn es Neuübertragungen gibt. Zweitens ist der Algorithmus zur Berechnung der geglätteten Rundlaufzeit unzureichend [TCP:7], da er fälschlicherweise annahm, dass die Varianz der RTT-Werte klein und konstant sein würde. Diese Probleme wurden durch die Algorithmen von Karn bzw. Jacobson gelöst.

Die Leistungsverbesserung durch die Verwendung dieser Verbesserungen variiert von bemerkenswert bis dramatisch. Der Algorithmus von Jacobson zur Einbeziehung der gemessenen RTT-Varianz ist besonders wichtig bei einer Niedriggeschwindigkeitsverbindung, wo die natürliche Variation der Paketgrößen eine große Variation der RTT verursacht. Ein Anbieter stellte fest, dass die Link-Auslastung auf einer 9,6-kb-Leitung von 10% auf 90% stieg, nachdem der Varianz-Algorithmus von Jacobson in TCP implementiert wurde.

Die folgenden Werte SOLLTEN verwendet werden, um die Schätzparameter für eine neue Verbindung zu initialisieren:

(a) RTT = 0 Sekunden.

(b) RTO = 3 Sekunden. (Die geglättete Varianz sollte auf den Wert initialisiert werden, der zu diesem RTO führt).

Die empfohlenen Ober- und Untergrenzen für das RTO sind bekanntermaßen für große Internets unzureichend. Die Untergrenze SOLLTE in Bruchteilen einer Sekunde gemessen werden (um Hochgeschwindigkeits-LANs zu berücksichtigen) und die Obergrenze sollte 2×MSL sein, d.h. 240 Sekunden.

DISKUSSION:

Die Erfahrung hat gezeigt, dass diese Initialisierungswerte vernünftig sind und dass in jedem Fall die Algorithmen von Karn und Jacobson das TCP-Verhalten vernünftigerweise unempfindlich gegenüber den anfänglichen Parameterauswahlen machen.

4.2.3.2 Wann ein ACK-Segment gesendet werden soll (When to Send an ACK Segment)

Ein Host, der einen Strom von TCP-Datensegmenten empfängt, kann die Effizienz sowohl im Internet als auch bei den Hosts erhöhen, indem er weniger als ein ACK-Segment (Bestätigung) pro empfangenem Datensegment sendet; dies wird als "verzögerte ACK" bezeichnet [TCP:5].

Ein TCP SOLLTE eine verzögerte ACK implementieren, aber eine ACK sollte nicht übermäßig verzögert werden; insbesondere MUSS die Verzögerung weniger als 0,5 Sekunden betragen, und in einem Strom von Segmenten voller Größe SOLLTE es eine ACK für mindestens jedes zweite Segment geben.

DISKUSSION:

Eine verzögerte ACK gibt der Anwendung die Möglichkeit, das Fenster zu aktualisieren und möglicherweise eine sofortige Antwort zu senden. Insbesondere im Fall der Zeichen-für-Zeichen-Remote-Anmeldung kann eine verzögerte ACK die Anzahl der vom Server gesendeten Segmente um den Faktor 3 reduzieren (ACK, Fensteraktualisierung und Echo-Zeichen alle in einem Segment kombiniert).

Darüber hinaus kann eine verzögerte ACK bei einigen großen Multibenutzer-Hosts den Protokollverarbeitungsaufwand erheblich reduzieren, indem die Gesamtzahl der zu verarbeitenden Pakete reduziert wird [TCP:5]. Übermäßige Verzögerungen bei ACKs können jedoch die Rundlaufzeitmessung und die "Clocking"-Algorithmen für Pakete stören [TCP:7].

4.2.3.3 Wann eine Fensteraktualisierung gesendet werden soll (When to Send a Window Update)

Ein TCP MUSS einen SWS-Vermeidungsalgorithmus im Empfänger enthalten [TCP:5].

IMPLEMENTIERUNG:

Der SWS-Vermeidungsalgorithmus des Empfängers bestimmt, wann der rechte Rand des Fensters vorrücken darf; dies ist üblicherweise als "Fensteraktualisierung" bekannt. Dieser Algorithmus kombiniert sich mit dem verzögerten ACK-Algorithmus (siehe Abschnitt 4.2.3.2), um zu bestimmen, wann tatsächlich ein ACK-Segment mit dem aktuellen Fenster an den Empfänger gesendet wird. Wir verwenden die Notation von RFC-793; siehe Abbildungen 4 und 5 in diesem Dokument.

Die Lösung für das SWS des Empfängers besteht darin, zu vermeiden, den rechten Rand des Fensters RCV.NXT+RCV.WND in kleinen Schritten vorzurücken, selbst wenn Daten in kleinen Segmenten aus dem Netzwerk empfangen werden.

Angenommen, der gesamte Empfangspufferspeicherplatz ist RCV.BUFF. Zu einem bestimmten Zeitpunkt können RCV.USER Bytes dieses Gesamtwerts an Daten gebunden sein, die empfangen und bestätigt wurden, aber vom Benutzerprozess noch nicht verbraucht wurden. Wenn die Verbindung inaktiv ist, ist RCV.WND = RCV.BUFF und RCV.USER = 0.

Den rechten Rand des Fensters fest zu halten, während Daten ankommen und bestätigt werden, erfordert, dass der Empfänger weniger als seinen vollen Pufferspeicherplatz anbietet, d.h. der Empfänger muss ein RCV.WND angeben, das RCV.NXT+RCV.WND konstant hält, während RCV.NXT zunimmt. Somit ist der gesamte Pufferspeicherplatz RCV.BUFF im Allgemeinen in drei Teile aufgeteilt:

|<------- RCV.BUFF ---------------->|
     1             2            3
----|---------|------------------|------|----
           RCV.NXT               ^
                              (Fixed)

1 - RCV.USER =  empfangene, aber noch nicht verbrauchte Daten;
2 - RCV.WND =   dem Sender angekündigter Platz;
3 - Reduction = verfügbarer, aber noch nicht angekündigter Platz.

Der vorgeschlagene SWS-Vermeidungsalgorithmus für den Empfänger ist, RCV.NXT+RCV.WND festzuhalten, bis die Reduktion erfüllt:

RCV.BUFF - RCV.USER - RCV.WND  >=  min(Fr * RCV.BUFF, Eff.snd.MSS)

wobei Fr ein Bruchteil ist, dessen empfohlener Wert 1/2 ist, und Eff.snd.MSS der effektive Sende-MSS für die Verbindung ist (siehe Abschnitt 4.2.2.6). Wenn die Ungleichung erfüllt ist, wird RCV.WND auf RCV.BUFF-RCV.USER gesetzt.

Beachten Sie, dass der Gesamteffekt dieses Algorithmus darin besteht, RCV.WND in Schritten von Eff.snd.MSS vorzurücken (für realistische Empfangspuffer: Eff.snd.MSS < RCV.BUFF/2). Beachten Sie auch, dass der Empfänger seinen eigenen Eff.snd.MSS verwenden muss, wobei angenommen wird, dass er derselbe ist wie der des Senders.

4.2.3.4 Wann Daten gesendet werden sollen (When to Send Data)

Ein TCP MUSS einen SWS-Vermeidungsalgorithmus im Sender enthalten.

Ein TCP SOLLTE den Nagle-Algorithmus [TCP:9] implementieren, um kurze Segmente zusammenzufassen. Es MUSS jedoch eine Möglichkeit geben, den Nagle-Algorithmus für eine einzelne Verbindung zu deaktivieren. In jedem Fall unterliegt das Senden von Daten auch der Einschränkung durch den Slow-Start-Algorithmus (Abschnitt 4.2.2.15).

DISKUSSION:

Der Nagle-Algorithmus ist im Allgemeinen wie folgt:

Wenn es nicht bestätigte Daten gibt (d.h., SND.NXT > SND.UNA), dann puffert das sendende TCP alle Benutzerdaten (unabhängig vom PSH-Bit), bis die ausstehenden Daten bestätigt wurden oder bis das TCP ein Segment voller Größe (Eff.snd.MSS Bytes; siehe Abschnitt 4.2.2.6) senden kann.

Einige Anwendungen (z.B. Echtzeit-Display-Fensteraktualisierungen) erfordern, dass der Nagle-Algorithmus deaktiviert wird, damit kleine Datensegmente mit maximaler Rate gestreamt werden können.

IMPLEMENTIERUNG:

Der SWS-Vermeidungsalgorithmus des Senders ist schwieriger als der des Empfängers, da der Sender den gesamten Pufferspeicherplatz des Empfängers RCV.BUFF nicht (direkt) kennt. Ein Ansatz, der sich als gut funktionierend erwiesen hat, ist, dass der Sender Max(SND.WND) berechnet, das maximale Sendefenster, das er bisher auf der Verbindung gesehen hat, und diesen Wert als Schätzung für RCV.BUFF verwendet. Leider kann dies nur eine Schätzung sein; der Empfänger kann jederzeit die Größe von RCV.BUFF reduzieren. Um einen daraus resultierenden Deadlock zu vermeiden, ist es notwendig, einen Timeout zu haben, um die Datenübertragung zu erzwingen und den SWS-Vermeidungsalgorithmus zu überschreiben. In der Praxis sollte dieser Timeout selten auftreten.

Das "nutzbare Fenster" [TCP:5] ist:

U = SND.UNA + SND.WND - SND.NXT

d.h., das angebotene Fenster minus die Menge der gesendeten, aber nicht bestätigten Daten. Wenn D die Menge der im sendenden TCP in der Warteschlange befindlichen, aber noch nicht gesendeten Daten ist, dann wird der folgende Regelsatz empfohlen.

Daten senden:

(1) wenn ein Segment maximaler Größe gesendet werden kann, d.h. wenn:

min(D,U) >= Eff.snd.MSS;

(2) oder wenn die Daten gepusht sind und alle in der Warteschlange befindlichen Daten jetzt gesendet werden können, d.h. wenn:

[SND.NXT = SND.UNA and] PUSHED and D <= U

(die Bedingung in Klammern wird durch den Nagle-Algorithmus auferlegt);

(3) oder wenn mindestens ein Bruchteil Fs des maximalen Fensters gesendet werden kann, d.h. wenn:

[SND.NXT = SND.UNA and]
min(D,U) >= Fs * Max(SND.WND);

(4) oder wenn die Daten PUSHed sind und der Override-Timeout auftritt.

Hier ist Fs ein Bruchteil, dessen empfohlener Wert 1/2 ist. Der Override-Timeout sollte im Bereich von 0,1 - 1,0 Sekunden liegen. Es kann praktisch sein, diesen Timer mit dem Timer zu kombinieren, der zum Testen von Null-Fenstern verwendet wird (Abschnitt 4.2.2.17).

Beachten Sie schließlich, dass der gerade spezifizierte SWS-Vermeidungsalgorithmus anstelle des in [TCP:5] enthaltenen Algorithmus auf der Senderseite verwendet werden sollte.

4.2.3.5 TCP-Verbindungsfehler (TCP Connection Failures)

Übermäßige Neuübertragung desselben Segments durch TCP deutet auf einen Ausfall des entfernten Hosts oder des Internet-Pfads hin. Dieser Ausfall kann kurz- oder langfristig sein. Die folgende Prozedur MUSS verwendet werden, um übermäßige Neuübertragungen von Datensegmenten zu behandeln [IP:11]:

(a) Es gibt zwei Schwellenwerte R1 und R2, die die Menge der aufgetretenen Neuübertragung für dasselbe Segment messen. R1 und R2 können in Zeiteinheiten oder als Zählung von Neuübertragungen gemessen werden.

(b) Wenn die Anzahl der Übertragungen desselben Segments den Schwellenwert R1 erreicht oder überschreitet, wird eine negative Mitteilung (siehe Abschnitt 3.3.1.4) an die IP-Schicht übermittelt, um die Dead-Gateway-Diagnose auszulösen.

(c) Wenn die Anzahl der Übertragungen desselben Segments einen Schwellenwert R2 erreicht, der größer als R1 ist, wird die Verbindung geschlossen.

(d) Eine Anwendung MUSS in der Lage sein, den Wert von R2 für eine bestimmte Verbindung zu setzen. Zum Beispiel könnte eine interaktive Anwendung R2 auf "unendlich" setzen, was dem Benutzer die Kontrolle gibt, wann er sich trennt.

(e) TCP SOLLTE die Anwendung über das Zustellproblem informieren (sofern solche Informationen von der Anwendung nicht deaktiviert wurden; siehe Abschnitt 4.2.4.1), wenn R1 erreicht wird und bevor R2 erreicht wird. Dies ermöglicht es einer Remote-Anmeldeanwendung (User Telnet), den Benutzer zu informieren, zum Beispiel.

Der Wert von R1 SOLLTE mindestens 3 Neuübertragungen entsprechen, beim aktuellen RTO. Der Wert von R2 SOLLTE mindestens 100 Sekunden entsprechen.

Ein Versuch, eine TCP-Verbindung zu öffnen, könnte mit übermäßigen Neuübertragungen des SYN-Segments oder durch Empfang eines RST-Segments oder eines ICMP-Port-Unreachable fehlschlagen. Die Neuübertragungen von SYN MÜSSEN auf die allgemeine Art und Weise behandelt werden, die gerade für Datenneuübertragungen beschrieben wurde, einschließlich der Benachrichtigung der Anwendungsschicht.

Die Werte von R1 und R2 können jedoch für SYN- und Datensegmente unterschiedlich sein. Insbesondere MUSS R2 für ein SYN-Segment groß genug gesetzt werden, um die Neuübertragung des Segments für mindestens 3 Minuten bereitzustellen. Die Anwendung kann die Verbindung natürlich früher schließen (d.h. den Öffnungsversuch aufgeben).

DISKUSSION:

Einige Internet-Pfade haben erhebliche Setup-Zeiten, und die Anzahl solcher Pfade wird in Zukunft wahrscheinlich zunehmen.

4.2.3.6 TCP Keep-Alives

Implementierer KÖNNEN "Keep-Alives" in ihre TCP-Implementierungen einbeziehen, obwohl diese Praxis nicht allgemein akzeptiert wird. Wenn Keep-Alives einbezogen werden, MUSS die Anwendung in der Lage sein, sie für jede TCP-Verbindung zu aktivieren oder zu deaktivieren, und sie MÜSSEN standardmäßig deaktiviert sein.

Keep-Alive-Pakete DÜRFEN NUR gesendet werden, wenn für die Verbindung in einem Intervall kein Daten- oder Bestätigungspaket empfangen wurde. Dieses Intervall MUSS konfigurierbar sein und MUSS standardmäßig mindestens zwei Stunden betragen.

Es ist äußerst wichtig zu bedenken, dass ACK-Segmente, die keine Daten enthalten, nicht zuverlässig von TCP übertragen werden. Daher DARF ein Keep-Alive-Mechanismus, wenn er implementiert ist, NICHT das Fehlen einer Antwort auf eine bestimmte Sonde als tote Verbindung interpretieren.

Eine Implementierung SOLLTE ein Keep-Alive-Segment ohne Daten senden; sie KANN jedoch konfigurierbar sein, um ein Keep-Alive-Segment mit einem Müll-Byte zu senden, für Kompatibilität mit fehlerhaften TCP-Implementierungen.

DISKUSSION:

Ein "Keep-Alive"-Mechanismus testet das andere Ende einer Verbindung periodisch, wenn die Verbindung ansonsten inaktiv ist, selbst wenn keine zu sendenden Daten vorhanden sind. Die TCP-Spezifikation enthält keinen Keep-Alive-Mechanismus, da er: (1) perfekt gute Verbindungen während transienter Internet-Ausfälle unterbrechen könnte; (2) unnötige Bandbreite verbraucht ("wenn niemand die Verbindung nutzt, wen kümmert es, ob sie noch gut ist?"); und (3) für einen Internet-Pfad, der pro Paket abgerechnet wird, Geld kostet.

Einige TCP-Implementierungen haben jedoch einen Keep-Alive-Mechanismus einbezogen. Um zu bestätigen, dass eine inaktive Verbindung noch aktiv ist, senden diese Implementierungen ein Testsegment, das eine Antwort vom Peer-TCP auslösen soll. Ein solches Segment enthält normalerweise SEG.SEQ = SND.NXT-1 und kann ein Müll-Datenbyte enthalten oder nicht. Beachten Sie, dass bei einer stillen Verbindung SND.NXT = RCV.NXT ist, sodass diese SEG.SEQ außerhalb des Fensters liegt. Daher veranlasst die Sonde den Empfänger, ein Bestätigungssegment zurückzugeben, das bestätigt, dass die Verbindung noch aktiv ist. Wenn der Peer die Verbindung aufgrund einer Netzwerkpartition oder eines Absturzes aufgegeben hat, antwortet er mit einem RST anstelle eines Bestätigungssegments.

Leider können einige schlecht konzipierte TCP-Implementierungen nicht auf ein Segment mit SEG.SEQ = SND.NXT-1 antworten, es sei denn, das Segment enthält Daten. Alternativ könnte eine Implementierung feststellen, ob ein Peer korrekt auf Keep-Alive-Pakete ohne Müll-Datenbyte reagiert hat.

Ein TCP-Keep-Alive-Mechanismus sollte nur in Serveranwendungen aufgerufen werden, die sonst auf unbestimmte Zeit hängen bleiben und unnötig Ressourcen verbrauchen könnten, wenn ein Client abstürzt oder eine Verbindung während eines Netzwerkausfalls aufgibt.

4.2.3.7 TCP-Multihoming

Wenn eine Anwendung auf einem Multi-Homed-Host die lokale IP-Adresse beim aktiven Öffnen einer TCP-Verbindung nicht angibt, MUSS TCP die IP-Schicht auffordern, eine lokale IP-Adresse auszuwählen, bevor der (erste) SYN gesendet wird. Siehe die Funktion GET_SRCADDR() in Abschnitt 3.4.

Zu allen anderen Zeiten wurde ein früheres Segment entweder auf dieser Verbindung gesendet oder empfangen, und TCP MUSS dieselbe lokale Adresse verwenden, die in diesen früheren Segmenten verwendet wurde.

4.2.3.8 IP-Optionen

Wenn empfangene Optionen von der IP-Schicht an TCP weitergegeben werden, MUSS TCP Optionen ignorieren, die es nicht versteht.

Ein TCP KANN die Zeitstempel- und Datensatzrouten-Optionen unterstützen.

Eine Anwendung MUSS in der Lage sein, eine Quellroute anzugeben, wenn sie eine TCP-Verbindung aktiv öffnet, und dies MUSS Vorrang vor einer in einem Datagramm empfangenen Quellroute haben.

Wenn eine TCP-Verbindung passiv GEÖFFNet wird und ein Paket mit einer vollständigen IP-Quellrouten-Option ankommt (die eine Rückgaberoute enthält), MUSS TCP die Rückgaberoute speichern und für alle auf dieser Verbindung gesendeten Segmente verwenden. Wenn eine andere Quellroute in einem nachfolgenden Segment ankommt, SOLLTE die spätere Festlegung die frühere ersetzen.

4.2.3.9 ICMP-Nachrichten

TCP MUSS auf eine von der IP-Schicht übermittelte ICMP-Fehlernachricht reagieren, indem es sie an die Verbindung weiterleitet, die den Fehler verursacht hat. Die benötigten Demultiplexing-Informationen können im IP-Header gefunden werden, der in der ICMP-Nachricht enthalten ist.

• Source Quench

  TCP MUSS auf ein Source Quench reagieren, indem es die Übertragung auf der Verbindung verlangsamt. Die EMPFOHLENE Prozedur ist, dass ein Source Quench ein "Slow Start" auslöst, als ob ein Neuübertragungstimeout aufgetreten wäre.

• Destination Unreachable -- Codes 0, 1, 5

  Da diese Unreachable-Nachrichten weiche Fehlerbedingungen anzeigen, DARF TCP die Verbindung NICHT aufgeben, und es SOLLTE die Informationen der Anwendung verfügbar machen.

  DISKUSSION:

  TCP könnte die weiche Fehlerbedingung direkt an die Anwendungsschicht mit einem Aufwärts-Aufruf an die ERROR_REPORT-Routine melden, oder es könnte die Nachricht einfach notieren und sie der Anwendung nur dann melden, wenn und wann die TCP-Verbindung einen Timeout erlebt.

• Destination Unreachable -- Codes 2-4

  Dies sind harte Fehlerbedingungen, daher SOLLTE TCP die Verbindung aufgeben.

• Time Exceeded -- Codes 0, 1

  Dies sollte auf dieselbe Weise behandelt werden wie die Destination Unreachable-Codes 0, 1, 5 (siehe oben).

• Parameter Problem

  Dies sollte auf dieselbe Weise behandelt werden wie die Destination Unreachable-Codes 0, 1, 5 (siehe oben).

4.2.3.10 Validierung der entfernten Adresse (Remote Address Validation)

Eine TCP-Implementierung MUSS einen lokalen OPEN-Aufruf für eine ungültige entfernte IP-Adresse (z.B. eine Broadcast- oder Multicast-Adresse) als Fehler zurückweisen.

Ein eingehendes SYN mit einer ungültigen Quelladresse sollte entweder von TCP oder von der IP-Schicht ignoriert werden (siehe Abschnitt 3.2.1.3).

Eine TCP-Implementierung MUSS ein eingehendes SYN-Segment, das an eine Broadcast- oder Multicast-Adresse adressiert ist, stillschweigend zurückweisen.

4.2.3.11 TCP-Verkehrsmuster (TCP Traffic Patterns)

IMPLEMENTIERUNG:

Die TCP-Protokollspezifikation [TCP:1] gibt dem Implementierer viel Freiheit beim Entwurf der Algorithmen, die den Nachrichtenfluss über die Verbindung steuern -- Paketierung, Fensterverwaltung, Senden von Bestätigungen usw. Diese Designentscheidungen sind schwierig, da ein TCP sich an eine breite Palette von Verkehrsmustern anpassen muss. Die Erfahrung hat gezeigt, dass ein TCP-Implementierer das Design auf zwei extremen Verkehrsmustern testen muss:

• Einzelzeichen-Segmente (Single-character Segments)

  Selbst wenn der Sender den Nagle-Algorithmus verwendet, erhält der Empfänger normalerweise einen Strom von Einzelzeichen-Segmenten, wenn eine TCP-Verbindung Remote-Anmeldeverkehr über ein LAN mit niedriger Verzögerung transportiert. Wenn der Remote-Terminal-Echo-Modus wirksam ist, wird das System des Empfängers normalerweise jedes Zeichen wiederholen, sobald es empfangen wird.

• Massenübertragung (Bulk Transfer)

  Wenn TCP für eine Massenübertragung verwendet wird, sollte der Datenstrom (fast) vollständig aus Segmenten der Größe des effektiven MSS bestehen. Obwohl TCP einen Sequenznummernraum mit Byte-Granularität verwendet, sollte sein Betrieb im Massenübertragungsmodus so sein, als ob TCP einen Sequenzraum verwenden würde, der nur Segmente zählt.

Die Erfahrung hat ferner gezeigt, dass ein einzelnes TCP diese beiden Extreme effizient und effektiv handhaben kann.

Das wichtigste Werkzeug zum Überprüfen einer neuen TCP-Implementierung ist ein Paket-Trace-Programm. Es gibt eine große Erfahrung, die die Bedeutung des Tracings einer Vielzahl von Verkehrsmustern mit anderen TCP-Implementierungen und des sorgfältigen Studiums der Ergebnisse zeigt.

4.2.3.12 Effizienz (Efficiency)

IMPLEMENTIERUNG:

Umfangreiche Erfahrung hat zu folgenden Vorschlägen für eine effiziente TCP-Implementierung geführt:

(a) Keine Daten kopieren (Don't Copy Data)

Bei der Massen-Datenübertragung sind die wichtigsten CPU-intensiven Aufgaben das Kopieren von Daten von einem Ort zum anderen und die Prüfsumme der Daten. Es ist wichtig, die Anzahl der Kopiervorgänge von TCP-Daten zu minimieren. Da die ultimative Geschwindigkeitsbeschränkung das Abrufen von Daten über den Speicherbus sein kann, kann es nützlich sein, das Kopieren mit der Prüfsumme zu kombinieren und beides mit einem einzigen Speicherabruf durchzuführen.

(b) Handcrafting der Prüfsummenroutine (Hand-Craft the Checksum Routine)

Eine gute TCP-Prüfsummenroutine ist typischerweise zwei- bis fünfmal schneller als eine einfache und direkte Implementierung der Definition. Große Sorgfalt und clevere Codierung sind oft erforderlich und ratsam, um den Prüfsummencode "ultraschnell" zu machen. Siehe [TCP:10].

(c) Für den häufigen Fall codieren (Code for the Common Case)

Die TCP-Protokollverarbeitung kann kompliziert sein, aber für die meisten Segmente gibt es nur wenige einfache Entscheidungen zu treffen. Die Segment-Verarbeitung wird erheblich beschleunigt, indem die Hauptlinie so codiert wird, dass die Anzahl der Entscheidungen im häufigsten Fall minimiert wird.

4.2.4 TCP/ANWENDUNGSSCHICHT-SCHNITTSTELLE (TCP/APPLICATION LAYER INTERFACE)

4.2.4.1 Asynchrone Berichte (Asynchronous Reports)

Es MUSS einen Mechanismus geben, um weiche TCP-Fehlerbedingungen an die Anwendung zu melden. Generisch nehmen wir an, dass dies die Form einer von der Anwendung bereitgestellten ERROR_REPORT-Routine annimmt, die asynchron [INTRO:7] von der Transportschicht aufwärts aufgerufen werden kann:

ERROR_REPORT(local connection name, reason, subreason)

Die genaue Kodierung der Parameter reason und subreason wird hier nicht spezifiziert. Die Bedingungen, die asynchron an die Anwendung gemeldet werden MÜSSEN, umfassen jedoch:

• Eingehende ICMP-Fehlernachricht (siehe 4.2.3.9)
• Übermäßige Neuübertragungen (siehe 4.2.3.5)
• Vorrücken des Dringlichkeitszeigers (siehe 4.2.2.4).

Ein Anwendungsprogramm, das solche ERROR_REPORT-Aufrufe nicht empfangen möchte, SOLLTE jedoch in der Lage sein, diese Aufrufe effektiv zu deaktivieren.

DISKUSSION:

Diese Fehlerberichte spiegeln im Allgemeinen weiche Fehler wider, die von vielen Anwendungen ohne Schaden ignoriert werden können. Es wurde vorgeschlagen, dass diese Fehlerbericht-Aufrufe standardmäßig "ausgeschaltet" sein sollten, aber dies ist nicht erforderlich.

4.2.4.2 Type-of-Service

Die Anwendungsschicht MUSS in der Lage sein, den Type-of-Service (TOS) für auf einer Verbindung gesendete Segmente anzugeben. Es ist nicht erforderlich, aber die Anwendung SOLLTE in der Lage sein, das TOS während der Lebensdauer der Verbindung zu ändern. TCP SOLLTE den aktuellen TOS-Wert unverändert an die IP-Schicht weiterleiten, wenn es Segmente auf der Verbindung sendet.

Das TOS wird unabhängig in jeder Richtung auf der Verbindung spezifiziert, sodass die empfangende Anwendung das TOS angibt, das für ACK-Segmente verwendet wird.

TCP KANN das zuletzt empfangene TOS an die Anwendung weiterleiten.

DISKUSSION:

Einige Anwendungen (z.B. SMTP) ändern die Art ihrer Kommunikation während der Lebensdauer einer Verbindung und möchten daher die TOS-Spezifikation ändern.

Beachten Sie auch, dass der in RFC-793 spezifizierte OPEN-Aufruf einen Parameter ("options") enthält, in dem der Aufrufer IP-Optionen wie Quellroute, Datensatzroute oder Zeitstempel angeben kann.

4.2.4.3 Flush-Aufruf (Flush Call)

Einige TCP-Implementierungen haben einen FLUSH-Aufruf einbezogen, der die Sendewarteschlange des TCP von allen Daten leert, für die der Benutzer SEND-Aufrufe ausgegeben hat, die aber noch rechts vom Sendefenster sind. Das heißt, es leert so viele in der Warteschlange befindliche Sendedaten wie möglich, ohne die Sequenznummernsynchronisation zu verlieren. Dies ist nützlich für die Implementierung der "Abort Output"-Funktion von Telnet.

4.2.4.4 Multihoming

Die in den Abschnitten 2.7 und 3.8 von RFC-793 beschriebene Benutzerschnittstelle muss für Multihoming erweitert werden. Der OPEN-Aufruf MUSS einen optionalen Parameter haben:

OPEN( ... [local IP address,] ... )

um die Angabe der lokalen IP-Adresse zu ermöglichen.

DISKUSSION:

Einige TCP-basierte Anwendungen müssen die zu verwendende lokale IP-Adresse zum Öffnen einer bestimmten Verbindung angeben; FTP ist ein Beispiel.

IMPLEMENTIERUNG:

Ein passiver OPEN-Aufruf mit einem angegebenen "lokale IP-Adresse"-Parameter wartet auf eine eingehende Verbindungsanforderung an diese Adresse. Wenn der Parameter nicht angegeben ist, wartet ein passiver OPEN auf eine eingehende Verbindungsanforderung an eine beliebige lokale IP-Adresse und bindet dann die lokale IP-Adresse der Verbindung an die bestimmte verwendete Adresse.

Für einen aktiven OPEN-Aufruf wird ein angegebener "lokale IP-Adresse"-Parameter zum Öffnen der Verbindung verwendet. Wenn der Parameter nicht angegeben ist, wählt die Netzwerksoftware eine geeignete lokale IP-Adresse (siehe Abschnitt 3.3.4.2) für die Verbindung.

4.2.5 ZUSAMMENFASSUNG DER TCP-ANFORDERUNGEN (TCP REQUIREMENTS SUMMARY)

Feature	Abschnitt	MUSS	SOLLTE	KANN	MUSS NICHT
Push-Flag
Aggregiere oder in Warteschlange: ungepushte Daten	4.2.2.2			x
Sender aggregiert aufeinanderfolgende PSH-Flags	4.2.2.2		x
SEND-Aufruf kann PUSH angeben	4.2.2.2			x
Falls nicht: Sender puffert auf unbestimmte Zeit	4.2.2.2				x
Falls nicht: PSH letztes Segment	4.2.2.2	x
Empfangs-ALP über PSH benachrichtigen	4.2.2.2			x
Segment maximaler Größe senden wenn möglich	4.2.2.2		x
Fenster
Als vorzeichenlose Zahl behandeln	4.2.2.3	x
Als 32-Bit-Zahl behandeln	4.2.2.3		x
Fenster von rechts schrumpfen	4.2.2.16				x
Robust gegen Fensterschrumpfung	4.2.2.16	x
Empfangsfenster auf unbestimmte Zeit geschlossen	4.2.2.17			x
Sender testet Null-Fenster	4.2.2.17	x
Erster Test nach RTO	4.2.2.17		x
Exponentielles Backoff	4.2.2.17		x
Fenster auf unbestimmte Zeit bei Null bleiben lassen	4.2.2.17	x
Sender-Timeout bei Null-Fenster-Verbindung	4.2.2.17				x
Dringliche Daten
Zeiger zeigt auf letztes Byte	4.2.2.4	x
Sequenz dringlicher Daten beliebiger Länge	4.2.2.4	x
ALP asynchron über dringliche Daten informieren	4.2.2.4	x
ALP kann wissen, wie viel dringliche Daten in Warteschlange	4.2.2.4	x
TCP-Optionen
TCP-Optionen in jedem Segment empfangen	4.2.2.5	x
Nicht unterstützte Optionen ignorieren	4.2.2.5	x
Illegale Optionslänge behandeln	4.2.2.5	x
Senden und Empfangen von MSS-Option implementieren	4.2.2.6	x
MSS-Option senden außer wenn 536	4.2.2.6		x
MSS-Option immer senden	4.2.2.6			x
Standard-Sende-MSS ist 536	4.2.2.6	x
Effektiven Sende-MSS berechnen	4.2.2.6	x
TCP-Prüfsumme
Sender generiert Prüfsumme	4.2.2.7	x
Empfänger prüft Prüfsumme	4.2.2.7	x
Uhrengesteuerte ISN-Auswahl verwenden	4.2.2.9	x
Verbindungen öffnen
Gleichzeitige Öffnungsversuche unterstützen	4.2.2.10	x
SYN-RCVD merkt sich vorherigen Zustand	4.2.2.11	x
Passiver Open-Aufruf beeinträchtigt andere	4.2.2.18				x
Funktion: Gleichzeitige LISTENs auf gleichem Port	4.2.2.18	x
IP-Quelladresse für SYN bei Bedarf anfordern	4.2.3.7	x
Andernfalls lokale Adresse der Verbindung verwenden	4.2.3.7	x
OPEN an Broadcast/Multicast-IP-Adresse	4.2.3.10				x
Segment an Broadcast/Multicast stillschweigend ablehnen	4.2.3.10	x
Verbindungen schließen
RST kann Daten enthalten	4.2.2.12		x
Anwendung über abgebrochene Verbindung informieren	4.2.2.13	x
Halbduplex-Verbindungsschließung	4.2.2.13			x
RST senden um Datenverlust anzuzeigen	4.2.2.13		x
Im TIME-WAIT-Zustand für 2×MSL Sekunden	4.2.2.13	x
SYN vom TIME-WAIT-Zustand akzeptieren	4.2.2.13			x
Neuübertragungen
Jacobsons Slow-Start-Algorithmus	4.2.2.15	x
Jacobsons Congestion-Avoidance-Algorithmus	4.2.2.15	x
Mit gleicher Identifikation neuübertragen	4.2.2.15			x
Karns Algorithmus	4.2.3.1	x
Jacobsons RTO-Schätzalgorithmus	4.2.3.1	x
Exponentielles Backoff	4.2.3.1	x
RTO-Berechnung für SYN wie für Daten	4.2.3.1		x
Empfohlene Anfangswerte und Grenzen	4.2.3.1		x
ACK-Generierung
Segmente außer der Reihe in Warteschlange	4.2.2.20		x
Gesamte Warteschlange vor ACK-Senden verarbeiten	4.2.2.20	x
ACK für Segment außer der Reihe senden	4.2.2.21			x
Verzögerte ACKs	4.2.3.2		x
Verzögerung < 0,5 Sekunden	4.2.3.2	x
ACK jedes 2. Segment voller Größe	4.2.3.2	x
SWS-Vermeidungsalgorithmus des Empfängers	4.2.3.3	x
Daten senden
TTL konfigurierbar	4.2.2.19	x
SWS-Vermeidungsalgorithmus des Senders	4.2.3.4	x
Nagle-Algorithmus	4.2.3.4		x
Anwendung kann Nagle-Algorithmus deaktivieren	4.2.3.4	x
Verbindungsfehler
Negative IP-Benachrichtigung bei R1-Retrans	4.2.3.5	x
Verbindung bei R2-Retrans schließen	4.2.3.5	x
ALP kann R2 setzen	4.2.3.5	x
ALP über R1≤retrans<R2 informieren	4.2.3.5		x
Empfohlene Werte R1, R2	4.2.3.5		x
Gleicher Mechanismus für SYN	4.2.3.5	x
R2 mindestens 3 Minuten für SYN	4.2.3.5	x
Keep-Alive-Pakete senden	4.2.3.6			x
Anwendung kann anfordern	4.2.3.6	x
Standardmäßig "aus"	4.2.3.6	x
Nur senden wenn inaktiv für Intervall	4.2.3.6	x
Intervall konfigurierbar	4.2.3.6	x
Standardmäßig mindestens 2 Stunden	4.2.3.6	x
Tolerant gegenüber verlorenen ACKs	4.2.3.6	x
IP-Optionen
Optionen ignorieren, die TCP nicht versteht	4.2.3.8	x
Zeitstempel unterstützen	4.2.3.8			x
Datensatzroute unterstützen	4.2.3.8			x
Quellroute
ALP kann angeben	4.2.3.8	x
Quellroute im Datagramm überschreiben	4.2.3.8	x
Rückgaberoute aus Quellroute konstruieren	4.2.3.8	x
Spätere Quellroute ersetzt	4.2.3.8		x
ICMP-Nachrichten von IP empfangen	4.2.3.9	x
Dest Unreachable(0,1,5)→ALP informieren	4.2.3.9		x
Dest Unreachable(0,1,5)→Verbindung nicht aufgeben	4.2.3.9				x
Dest Unreachable(2-4)→Verbindung aufgeben	4.2.3.9		x
Source Quench→Slow Start	4.2.3.9		x
Time Exceeded→ALP sagen, nicht aufgeben	4.2.3.9		x
Param Problem→ALP sagen, nicht aufgeben	4.2.3.9		x
Adressvalidierung
OPEN-Aufruf an ungültige IP-Adresse ablehnen	4.2.3.10	x
SYN mit ungültiger IP-Adresse ablehnen	4.2.3.10	x
SYN an Broadcast/Multicast stillschweigend ablehnen	4.2.3.10	x
TCP/ALP-Schnittstellendienste
Mechanismus zur Fehlerberichterstattung	4.2.4.1	x
ALP kann Fehlerberichtsroutine deaktivieren	4.2.4.1		x
ALP kann Sende-TOS angeben	4.2.4.2	x
Unverändert an IP weitergeleitet	4.2.4.2		x
ALP kann TOS während Verbindung ändern	4.2.4.2		x
Empfangenes TOS an ALP weiterleiten	4.2.4.2			x
FLUSH-Aufruf	4.2.4.3			x
Optionaler lokaler IP-Adresse-Parameter in OPEN	4.2.4.4	x

HINWEISE:

(1) "ALP" bedeutet Anwendungsschichtprogramm (Application-Layer Program).