| orm@doc-tcpip.org | Erstellt: Januar 2000 - Letzte Modifikation: Februar 2005 |
Betrifft den Sender.
Mit dieser Neuerung soll das Netz vor plötzlichen Lastspitzen geschützt werden. Der Sender muß sich paketweise an die optimale Senderate herantasten.
Praktisch sendet der Sender nach dem vollendeten TCP Handshake zuerst ein Paket. Er wartet dann, bis das entsprechende ACK eingetroffen ist, worauf er zwei Pakete schickt. Erhält er wieder ein zeitlich akzeptables ACK, so werden 4 Pakete gesendet.
Das Eintreffen der ACK des Empfängers taktet also die Rate, mit der der Sender Pakete auf das Netz legt. Der Sender tut dies solang, bis Pakete verloren gehen (also ein ACK ausbleibt und Retransmission-Timer ablaufen). Die Senderate pendelt sich so dynamisch auf einen, der Last auf dem Netz angepassten Wert ein.
Betrifft den Empfänger.
Hierbei geht es darum, die Zahl der Pakete auf dem Netz insgesamt zu drücken und den TCP-Stack von Sender und Empfänger zu entlasten.
Jedes empfangene Paket löst einen ACK aus. Dieser muß nun nicht sofort gesendet werden, sondern darf verzögert werden. Es wird darauf gehofft, das in dieser Zeit sowieso ein Paket gesendet werden muß, das den ACK dann Huckepack mitnimmt.
Die laut Standard maximale Verzögerung ist 0.5 Sekunden (darüber kommt man in den Bereich der Retransmission Timeouts). Um Methoden wie Slow Start nicht zu gefährden, wird nicht nur die Zeit begrenzt, sondern auch die Zahl der Pakete, die auf diesem Socket von diesem Sender erhalten worden sind. Sind mehr als 2 Pakete eingetroffen, so muß der ACK unverzüglich ausgelöst werden.
Da die meisten Verbindungen Datenfluß von beiden Seiten erfahren, ist dieser Ansatz sehr praktikabel.
Ein Problem entsteht, wenn der Sender eine Anweisung an den Empfänger schickt, die auf mehrere Pakete verteilt werden muß. Dann wird erst ein Paket gesendet. Der Empfänger bearbeitet das Paket und wartet nun auf den lokalen Stack, bis ein Paket gesendet wird, um den ACK huckepack mitzugeben. Da der Applikation im lokalen Stack aber die Information im zweiten Paket fehlt, wird kein Paket gebildet. Der Timer (also der ACK-Delay) muß erst auslaufen. Hier ist die Applikation anzupassen oder der Delay auszuschalten - eine moderne Applikation sollte ein solches Verhalten aber nicht zeigen.
Mit SACK wird das ACK Verhalten von TCP fundamental geändert. Normalerweise wird die höchste Sequenznummer der in Reihenfolge empfangenen Oktetts/Segmente bestätigt. Das bedeutet, das die Daten in der richtigen Reihenfolge und komplett vorliegen müßen. Retransmissions umfassen sämtliche Oktetts ab dem fehlenden Segment, auch wenn spätere Segmente fehlerfrei empfangen worden sind.
SACK modifiziert die Art, wie das Acknowledgement Field beschrieben und interpretiert wird. Der Empfänger kann einzelne, unzusammenhängende Blocks als empfangen quittieren, worauf der Sender nur noch die fehlenden Oktetts (Segmente) erneut sendet.
Diese Optionen sollten beim Aufbau einer TCP Verbindung ausgehandelt werden. Nur so ist sichergestellt, daß
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL