データグラム輻輳制御プロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

コンピュータネットワークデータグラム輻輳制御プロトコルDCCPは)メッセージ指向であるトランスポート層 プロトコルDCCPは、信頼性の高い接続セットアップ、ティアダウン、明示的輻輳通知(ECN)、輻輳制御、および機能ネゴシエーションを実装しますIETFは、としてDCCPを発表RFC  4340提案された標準2006年3月に、RFC 4336で紹介しています。  

操作

DCCPは、アプリケーション層に実装することなく、輻輳制御メカニズムにアクセスする方法を提供しますこれは、伝送制御プロトコル(TCP)のようなフローベースのセマンティクスを可能にしますが、信頼性の高い順序どおりの配信を提供しません。DCCPでは、Stream Control Transmission Protocol(SCTP)のように、複数のストリーム内でシーケンス配信を行うことはできません。DCCP接続には、確認応答トラフィックとデータトラフィックが含まれます。確認応答は、パケットが到着したかどうか、および明示的輻輳通知によってマークされたかどうかを送信者に通知します(ECN)。確認応答は、使用中の輻輳制御メカニズムが必要とするのと同じくらい確実に、おそらく完全に確実に送信されます。

DCCPには、TCPのようなバイトIDではなく、パケットIDに対応する非常に長い(48ビット)シーケンス番号のオプションがあります。シーケンス番号の長さが長いのは、「接続へのDCCPリセットの注入などの一部のブラインド攻撃」を防ぐことを目的としています。[1]

アプリケーション

DCCPは、データの配信にタイミングの制約があるアプリケーションに役立ちます。このようなアプリケーションには、ストリーミングメディアマルチプレイヤーオンラインゲームインターネットテレフォニーなどがあります。このようなアプリケーションでは、古いメッセージはすぐに役に立たなくなるため、失われたメッセージを再送信するよりも、新しいメッセージを取得する方が優先されます。 2017年の時点で、このようなアプリケーションはTCPに対応するか、ユーザーデータグラムプロトコルを使用することがよくあります。(UDP)独自の輻輳制御メカニズムを実装しているか、輻輳制御がまったくありません。DCCPは、これらのアプリケーションに役立ちますが、UDP / DCCPに加えて、信頼性の高い、または順序どおりの配信のためのメカニズムを必要に応じて追加することにより、UDPベースのアプリケーションの一般的な輻輳制御メカニズムとしても機能します。このコンテキストでは、DCCPは、異なるが一般的にTCPに適した輻輳制御メカニズムの使用を許可します

実装

次のオペレーティングシステムはDCCPを実装しています。

ユーザースペースライブラリ:

  • DCCP-TPの実装は移植性のために最適化されていますが、2008年6月以降変更はありません。[4]
  • この実装のGoDCCPの目的は、アプリケーションに応じて、柔軟な輻輳制御を備えたピアツーピア通信用の標準化されたポータブルなNAT対応フレームワークを提供することです。

パケット構造

DCCP汎用ヘッダーは、拡張シーケンス番号ビットであるXの値に応じてさまざまな形式を取ります。Xが1の場合、シーケンス番号フィールドは48ビット長で、次のように汎用ヘッダーは16バイトを使用します。

DCCP汎用ヘッダー
オフセット オクテット 0 1
オクテット 少し  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
0 0 ソースポート
2 16 宛先ポート
4 32 データオフセット CCVal CsCov
6 48 チェックサム
8 64 解像度 タイプ X = 1 予約済み
10 80 シーケンス番号(上位ビット)
12 96 シーケンス番号
14 112 シーケンス番号(下位ビット)

Xがゼロの場合、シーケンス番号の下位24ビットのみが送信され、汎用ヘッダーの長さは12バイトです。

オフセット オクテット 0 1
オクテット 少し  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
0 0 ソースポート
2 16 宛先ポート
4 32 データオフセット CCVal CsCov
6 48 チェックサム
8 64 解像度 タイプ X = 0 シーケンス番号(高)
10 80 シーケンス番号(下位ビット)
ソースポート(16ビット)
送信ポートを識別します
宛先ポート(16ビット)
受信ポートを識別します
データオフセット
(8ビット):パケットのDCCPヘッダーの開始からアプリケーションデータ領域の開始までのオフセット(32ビットワード)。
CCVal(4ビット)
HC-SenderCCIDによって使用されます
チェックサムカバレッジ(CsCov)(4ビット)
チェックサムカバレッジは、チェックサムフィールドでカバーされるパケットの部分を決定します。
チェックサム(16ビット)
パケットのDCCPヘッダー(オプションを含む)、ネットワーク層疑似ヘッダー、およびチェックサムカバレッジに応じて、アプリケーションデータのすべて、一部、またはまったくのインターネットチェックサム
予約済み(解像度)(3ビット)
送信者は、生成されたパケットでこのフィールドをすべてゼロに設定する必要があり、受信者はその値を無視する必要があります
タイプ(4ビット)
Typeフィールドは、パケットのタイプを指定します
拡張シーケンス番号(X)(1ビット)
1に設定すると、48ビットのシーケンス番号と確認応答番号を持つ拡張汎用ヘッダーの使用を示します。
シーケンス番号(48または24ビット)
ソースがこの接続で送信したすべてのパケットのシーケンスでパケットを一意に識別します

現在の開発

マルチパス機能(MPTCP)によるTCPプロトコルの拡張と同様に、DCCPについても、マルチパス機能は、対応してMP-DCCPとして示される IETF [5]で議論されてい ます。最初の実装はすでに開発され、テストされ、オペレーターと学界の間の共同アプローチで提示されており[6]、オープンソースソリューションとして利用できます。

も参照してください

参考文献

  1. ^ RFC4340セクション7.6
  2. ^ 「[dccp] FreeBSDの実装」www.ietf.org 2018年4月18日取得
  3. ^ 「LinuxはDCCP [LWN.net]を取得します」lwn.net 2018年4月18日取得
  4. ^ 2011年6月13日に取得されたdccp-tpwikiの変更ログ
  5. ^ 修正、マーカス; ブランストロム、アンナ; カッセラー、アネアス; Rakocevic、Veselin; ジョンソン、スティーブン(2021年11月9日)。「複数のアドレスを使用したマルチパス操作のためのDCCP拡張機能」 引用ジャーナルには|journal=ヘルプが必要です
  6. ^ https://multipath-dccp.org/

外部リンク

プロトコル仕様

  • RFC  4340 —データグラム輻輳制御プロトコル
  • RFC  5595 —データグラム輻輳制御プロトコル(DCCP)サービスコード
  • RFC  5596 — NAT /ミドルボックストラバーサルを容易にするDCCP同時オープンテクニック
  • RFC  5762 —RTPおよびDCCP
  • RFC  5238 — DCCPを介したデータグラムトランスポート層セキュリティ(DTLS)
  • RFC  5634 —DCCPのクイックスタート
  • RFC  6773 —NATトラバーサル用のデータグラム輻輳制御プロトコルUDPカプセル化

輻輳制御ID

  • RFC  4341 —DCCP輻輳制御ID2のプロファイル:TCPのような輻輳制御
  • RFC  4342 —DCCP輻輳制御ID3のプロファイル:TCPフレンドリーレート制御(TFRC)
  • RFC  5622 —DCCP輻輳制御ID4のプロファイル:小さなパケットのTCP対応レート制御(TFRC-SP)

その他の情報