Datagramm-Überlastungskontrollprotokoll - Datagram Congestion Control Protocol

In Computer - Netzwerk , das Datagram Congestion Control Protocol ( DCCP ist) ein nachrichtenorientierte Transportschicht - Protokoll . DCCP implementiert zuverlässigen Verbindungsaufbau, -abbau, Explicit Congestion Notification (ECN), Congestion Control und Feature Negotiation . Die IETF hat DCCP im März 2006 als RFC  4340 als vorgeschlagenen Standard veröffentlicht. RFC  4336 bietet eine Einführung.

Betrieb

DCCP bietet eine Möglichkeit, auf Überlastungskontrollmechanismen zuzugreifen, ohne diese auf der Anwendungsebene implementieren zu müssen . Es ermöglicht eine flussbasierte Semantik wie im Transmission Control Protocol (TCP), bietet jedoch keine zuverlässige Lieferung in der Reihenfolge. Die sequenzielle Zustellung innerhalb mehrerer Streams wie im Stream Control Transmission Protocol (SCTP) ist in DCCP nicht verfügbar. Eine DCCP-Verbindung enthält sowohl Quittungsverkehr als auch Datenverkehr. Bestätigungen informieren einen Sender, ob seine Pakete angekommen sind und ob sie durch Explicit Congestion Notification (ECN) gekennzeichnet wurden. Quittungen werden so zuverlässig übertragen, wie es der im Einsatz befindliche Staukontrollmechanismus erfordert, möglicherweise absolut zuverlässig.

DCCP hat die Option für sehr lange (48-Bit) Sequenznummern, die einer Paket-ID entsprechen, anstatt einer Byte-ID wie bei TCP. Die lange Länge der Sequenznummern soll vor "einigen blinden Angriffen, wie dem Einschleusen von DCCP-Resets in die Verbindung" schützen.

Anwendungen

DCCP ist nützlich für Anwendungen mit zeitlichen Einschränkungen bei der Bereitstellung von Daten. Zu diesen Anwendungen gehören Streaming-Medien , Multiplayer-Online-Spiele und Internet-Telefonie . In solchen Anwendungen werden alte Nachrichten schnell nutzlos, so dass das Abrufen neuer Nachrichten dem erneuten Senden verlorener Nachrichten vorgezogen wird. Seit 2017 haben sich solche Anwendungen oft entweder für TCP entschieden oder das User Datagram Protocol (UDP) verwendet und ihre eigenen Überlastungskontrollmechanismen implementiert oder haben überhaupt keine Überlastungssteuerung. Obwohl DCCP für diese Anwendungen nützlich ist, kann es auch als allgemeiner Überlastungskontrollmechanismus für UDP-basierte Anwendungen dienen, indem nach Bedarf Mechanismen für eine zuverlässige oder geordnete Lieferung zusätzlich zu UDP/DCCP hinzugefügt werden. DCCP erlaubt in diesem Zusammenhang die Verwendung unterschiedlicher, aber in der Regel TCP-freundlicher Überlastungskontrollmechanismen.

Implementierungen

Die folgenden Betriebssysteme implementieren DCCP:

Userspace-Bibliothek:

  • Die DCCP-TP- Implementierung ist für die Portabilität optimiert, hat sich jedoch seit Juni 2008 nicht geändert.
  • Der Zweck dieser Implementierung von GoDCCP besteht darin, ein standardisiertes, tragbares NAT-freundliches Framework für die Peer-to-Peer-Kommunikation mit flexibler Überlastungskontrolle je nach Anwendung bereitzustellen.

Paketstruktur

Der generische DCCP-Header nimmt abhängig vom Wert von X, dem Extended Sequence Numbers-Bit, unterschiedliche Formen an. Wenn X eins ist, ist das Sequenznummernfeld 48 Bit lang, und der generische Header benötigt wie folgt 16 Byte.

DCCP-generischer Header
Versätze Oktett 0 1
Oktett Bit  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 fünfzehn
0 0 Quellport
2 16 Zielhafen
4 32 Datenoffset CCVal CsCov
6 48 Prüfsumme
8 64 Auflösung Typ X=1 Reserviert
10 80 Sequenznummer (hohe Bits)
12 96 Sequenznummer
14 112 Sequenznummer (niedrige Bits)

Wenn X null ist, werden nur die unteren 24 Bit der Sequenznummer übertragen und der generische Header ist 12 Byte lang.

Versätze Oktett 0 1
Oktett Bit  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 fünfzehn
0 0 Quellport
2 16 Zielhafen
4 32 Datenoffset CCVal CsCov
6 48 Prüfsumme
8 64 Auflösung Typ X=0 Sequenznummer (hoch)
10 80 Sequenznummer (niedrige Bits)
Quellport (16 Bit)
Identifiziert den sendenden Port
Zielport (16 Bit)
Identifiziert den empfangenden Port
Datenoffset
(8 Bits): Der Offset vom Anfang des DCCP-Headers des Pakets zum Anfang seines Anwendungsdatenbereichs in 32-Bit-Wörtern.
CCVal (4 Bit)
Wird vom HC-Sender CCID verwendet
Prüfsummenabdeckung (CsCov) (4 Bit)
Prüfsummenabdeckung bestimmt die Teile des Pakets, die vom Feld Prüfsumme abgedeckt werden.
Prüfsumme (16 Bit)
Die Internet-Prüfsumme des DCCP-Headers des Pakets (einschließlich Optionen), ein Pseudoheader der Vermittlungsschicht und, je nach Prüfsummenabdeckung, alle, einige oder keine Anwendungsdaten
Reserviert (Res) (3 Bit)
Sender MÜSSEN dieses Feld bei generierten Paketen auf alle Nullen setzen, und Empfänger MÜSSEN seinen Wert ignorieren
Typ (4 Bit)
Das Feld Typ gibt den Typ des Pakets an
Erweiterte Sequenznummern (X) (1 Bit)
Auf eins setzen, um die Verwendung eines erweiterten generischen Headers mit 48-Bit-Sequenz- und Bestätigungsnummern anzuzeigen
Sequenznummer (48 oder 24 Bit)
Identifiziert das Paket eindeutig in der Reihenfolge aller Pakete, die die Quelle auf dieser Verbindung gesendet hat

Aktuelle Entwicklung

Ähnlich wie die Erweiterung des TCP- Protokolls um Multipath Capability ( MPTCP ) wird auch für DCCP das Multipath-Feature bei der IETF entsprechend als MP-DCCP bezeichnet . Erste Implementierungen wurden bereits in einem kollaborativen Ansatz zwischen Betreibern und Wissenschaft entwickelt, getestet und präsentiert und stehen als Open-Source-Lösung zur Verfügung.

Siehe auch

Verweise

Externe Links

Protokollspezifikationen

  • RFC  4340 – Datagramm-Überlastungskontrollprotokoll
  • RFC  5595 – Die Dienstcodes des Datagram Congestion Control Protocol (DCCP)
  • RFC  5596 – DCCP Simultaneous-Open-Technik zur Erleichterung von NAT/Middlebox-Traversal
  • RFC  5762 – RTP und DCCP
  • RFC  5238 – Datagram Transport Layer Security (DTLS) über DCCP
  • RFC  5634 – Schnellstart für DCCP
  • RFC  6773 – Ein Datagramm- Überlastungskontrollprotokoll UDP-Kapselung für NAT-Traversal

Staukontroll-IDs

  • RFC  4341 – Profil für DCCP Congestion Control ID 2: TCP-like Congestion Control
  • RFC  4342 – Profil für DCCP Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
  • RFC  5622 – Profil für DCCP Congestion Control ID 4: TCP-freundliche Ratensteuerung für kleine Pakete (TFRC-SP)

Andere Informationen