Kästen

Netzwerk-Staus mit dem Datagramm Congestion Control Protocol vermeiden

Praxis & Tipps | Praxis

Seite 5: Kästen

DCCP-Kommunikationsabfolge

Das nebenstehende DCCP-Sequenzdiagramm zeigt den Verbindungsaufbau, den eigentlichen Datenversand und den Verbindungsabbau. Der Client sendet zunächst einen DCCP-Request und leitet damit den Verbindungsaufbau ein. In der Regel teilt er dem Server mit, welcher Staukontrollalgorithmus (CCID) zum Einsatz kommen soll. Als Erweiterung zu TCP, das eine Verbindung zur Anwendungssoftware über Ports impliziert, erweitert DCCP den generischen Paketkopf um ein Service-Code-Feld. Es liefert Informationen über das konkrete Anwendungsprotokoll ­ ein Vorteil für Firewalls und flexibler als das Konzept der "Wellknown Ports". Als Antwort sendet der Server ein DCCP-Response-Paket ­ die zweite Phase des DreiwegeVerbindungsaufbaus. Er bestätigt vom Client vorgeschlagene Optionen oder passt sie an und versendet selbst Optionen. Der Service-Code muss mit denen im DCCP-Request übereinstimmen. Sollte der Server den Verbindungswunsch ablehnen, würde er mit einem DCCP Reset antworten (siehe Grafik). Den Grund für die Ablehnung, zum Beispiel "Too Busy", kann er im Reset-Code kodieren. DCCP-Ack markiert das Ende des Verbindungsaufbaus. Der Client bewilligt Server-Optionen oder nimmt Anpassungen vor. Während des gesamten Verbindungsaufbaus lassen sich Anwendungsdaten übermitteln. Nun beginnt der Datenaustausch mit Paketen namens DCCP-Data/DCCP-DataAck, je nach dem gewählten Staukontrollalgorithmus bestätigt mit DCCP-Ack. Mit einem DCCP-CloseReq leitet der Server den Verbindungsabbau ein. Sollte der Client diesem Wunsch zuvorkommen, entfällt dieser Schritt, und der Client sendet unaufgefordert ein DCCP-Close, anderenfalls als Bestätigung der Close-Aufforderung. Zu guter Letzt kann ein DCCP-Reset, anders als dessen TCP-Pendant, einen Grund für den Verbindungsabbau angeben. Bei einem normalen Abbau gilt der Reset-Code 1. Für die "twice maximum segment lifetime" (2MSL, in diesem Fall vier Minuten) verbleibt der Client im TimewaitStatus. Auf diese Weise können Pakete, die sich längere Zeit im Netz befinden, eine neu aufgebaute Verbindung nicht beeinträchtigen.

DCCP-Paketformate

Die Abbildung zeigt exemplarisch das Format des DCCPResponse-Paketes. Der Server sendet es als zweites Paket des Dreiwege-Verbindungsaufbaus an den Client.

CCVAL kodiert Informationen über den verwendeten Staukontroll-Mechanismus (CCID).

CsCOV spezifiziert jene Teile des Paketes, die eine Prüfsumme schützen soll. Paketkopf und dessen Optionen sind Pflicht, optional lassen sich darüber hinaus alle oder ein Teil der Anwendungsdaten schützen.

Das Feld Type spiegelt die Art des Paketes wider. TCP kennt die Flags SYN, ACK, RST, PSH, URG und FIN. DCCP erweitert dieses Modell, indem das Setzen eines Typs einen Sub-Header nach sich zieht, der zusätzliche Informationen kodiert. Beispielsweise kann der Sub-Header DCCP-Reset den Grund für einen Verbindungsabbau angeben, etwa eine Server-Überlastung.

Derzeit sind folgende Typen spezifiziert:

0 DCCP-Request

1 DCCP-Response

2 DCCP-Data

3 DCCP-Ack

4 DCCP-DataAck

5 DCCP-CloseReq

6 DCCP-Close

7 DCCP-Reset

8 DCCP-Sync

9 DCCP-SyncAck

Die Abbildung zeigt ein DCCP-Response-Paket, dessen Type-Feld mit der Kennung 1 belegt ist.

X: Dieses Bit verdeutlicht die Verwendung erweiterter Sequence-und Acknowledge- Nummern (48 Bit). Sonst finden 24 Bit Verwendung. DCCP-Data, DCCP-Ack und DCCP-DataAck können diese Auswahl treffen, alle anderen Typen müssen 48 Bit verwenden. Damit lässt sich bei schnellen Verbindungen im Falle längerer Verzögerungen ein Überlaufen vermeiden (TCP-Stichwort: Protection Against Wrapped Sequence Numbers, PAWS).

Sequence- und Acknowledgement-Nummern dienen der Identifizierung und Bestätigung. Anders als TCP inkrementiert DCCP die Sequenznummer pro Paket, nicht pro Byte, denn es ist kein Bytestromprotokoll. Auch Bestätigungspakete folgen einem alternativen Ansatz: Sie bestätigen immer die größte Sequenznummer. Für genauere Informationen über Empfang oder Verlust dient die Option ACK-Vektor. DCCP ist wie erwähnt kein Protokoll mit der Intention einer hundertprozentigen Nutzdatenzuverlässigkeit.

Service Code bestimmt das zu transportierende Anwendungsprotokoll. Es muss mit dem im DCCP-Request gesetzten Wert übereinstimmen.

Options and Padding: Ähnlich TCP kennt auch DCCP Optionen, darunter Change und Confirm für die Aushandlung der CCID. Die Timestamp-Option ist ein alter Bekannter aus TCP-Zeiten.Daneben existieren viele weitere Optionen.

Application Data: DCCP kann bereits beim Verbindungsaufbau Daten versenden. Dieses Feld ist optional für eine DCCP-Response.

Stauvermeidung unter Linux

Ab Kernelversion 2.6.13 unterstützt Linux den modularen Austausch des Staukontrollalgorithmus für TCP mit dem Interface sysctl/proc. Die Konfiguration des Kernels erfordert die Auswahl der dafür benötigten Unterstützung: Networking/Networking options/TCP: advanced congestion control. sysctl -w net.ipv4.tcp_congestion_ control=hybla reicht danach zum Beispiel aus, um die Kommunikation mit dem Weltraumteleskop Hubble zu beschleunigen (geeignete Hardware und die korrekte Kombination aus Benutzernamen und Passwort vorausgesetzt).

Der ursprüngliche Artikel erschien in iX 05/2006.

Anzeige