User Datagram Protocolは、Hans Christian Andersenの「Ugly Duckling」に似ています。何十年も見過ごされ、decade笑された後、このシンプルなプロトコルは、ブロードバンド速度によって可能になった新しい魅力的なマルチメディアアプリケーションのトランスポートプロトコルとして、突然ファンを魅了しました。今日、データを配信する必要があるアプリケーションは、以前は支配的なTCP（Transmission Control Protocol）よりもUDPを迅速に選択していました。.
UDP履歴
UDPはインターネットとほぼ同じ期間存在していました。インターネットは1974年5月に電気電子技術者協会が「パケットネットワーク相互通信のためのプログラム” 沿って ヴィントサーフ そして ボブ・カーン. コンセプトを開発する必要があり、カーンとサーフはともに、米国政府の 国防高等研究計画局, DARPAとも呼ばれます. ジョン・ポステル サーフとカーンの元のアイデアで提案された単一の構造を分割することを提案しました。これにより、階層化された概念が作成されました。 1974年の概要に含まれていたオリジナルの伝送制御プログラムは、上位層の伝送制御プロトコルと下位層のインターネットプロトコルに分割されました（したがってTCP / IP）.
チームが理論の実装について考え始めたとき、ポステルのモジュラーアプローチは意味がありました。として知られるようになったものの間に明確な分業がありました トランスポート層, これは、伝送制御プロトコルの場所です。 インターネット層, インターネットプロトコルが存在する場所。ただし、サーフとカーンは、高速トラックオプションの必要性を想定していました。彼らは、ある層から別の層に渡されることによって、データが送信のためにどのように準備されるかについての図を作成しました。処理タスクはまっすぐな垂直線として表され、新しいスタックダイアグラムを下って下がっていきます。 TCPおよびIPへのアプリケーション.
ファーストトラックでの描画に関しては、TCPの通過を回避する曲線の迂回線を描画する必要はありませんでした。代わりに、トランスポート層を表すブロックよりも少し広いインターネット層を表す長方形を描きました。この視覚的な調整により、通常のルートとファーストトラックのルートの両方が、平行線としてスタックを下降する可能性があります。しかし、このトリックは、ポステルが埋める必要があると感じたギャップを残しました。これが、ユーザーデータグラムプロトコルが発明された理由です. プロトコルスタック図のバランスをとるためにちょうどそこにありました.
TCPの利点
Transmission Control Protocolは、転送中のデータに不可欠なサービスを提供します。ストリーム内のすべてのパケットが実際に到着することを保証し、順番に到着することを確認します。秩序ある転送を保証するこれらの制御手順は、両側間の調整手段なしでは不可能です。そのため、TCPは最初に、データを交換する2つのデバイス間で合意を確立します。この契約は呼ばれています セッション. また、「接続.」UDPにはセッション確立手順がないため、「コネクションレス.」
セッションは、接続の両側に、管理交換にタグ付けできる参照番号を提供します。セッションでは、ポートの概念を導入することもできます. セッションIDは、実際にはTCPヘッダーに含まれる識別子の組み合わせです. このIDを使用して、TCPプロシージャの設計者は、「ソケット.ポート番号もUDPに割り当てられますが、そのプロトコルは宛先IPとポート番号のみを一意の識別子として使用できます。その組み合わせから派生した識別子は、別のコンピューターで実行されていても、同じポートにアクセスしようとする他のすべてのプロセスをブロックします。 UDPは、双方向ダイアログを有効にする手順を持たない配信専用システムになりました.
TCP接続の概念はすべて、コンピューター間でやり取りされるデータが混同したり、文字化けしたりしないようにするために、非常に洗練された普遍的な方法に発展しました。. ソケットにより、同じ2台のコンピューター間で同時に複数の接続を開くことができました. このアイデアにより、データを渡すために複数のチャネルが動作する可能性が生まれました。これは頻繁に使用される手順であり、初期のネットワークアプリケーションの多くがこれを利用していました。の ファイル転送プロトコル, たとえば、2つのチャネルを使用します。1つはデータを渡すためのもので、もう1つは管理通信用のチャネルです。データチャネルと制御チャネルの異なるポート番号により、2つの異なるソケットが作成されます.
各セッションの一意のIDは、TCPが2台のコンピューター間の通信に価値を追加したことを意味しました。 1970年代後半から80年代前半には、大規模な組織と学術機関のみがコンピューターとネットワークを持っていました。そのため、2つの組織が、異なる目的のために相互に同時に接続するために、大きなメインフレームを必要とする可能性が非常に高くなりました。教授が別の大学の同僚にファイルを送信している間に、研究者が同じリモート大学のコンピューターへのTelnetセッションを開くこともできます。. TCPのおかげで、2台のコンピューターが複数の接続を同時に維持でき、それらのセッションのそれぞれが同時に複数のチャネルを操作できました。. コンピュータごとに1つのIPアドレスが割り当てられたインターネットプロトコルのみで通信が管理されている場合、これらの同時接続は不可能です。. セッションメカニズムのないUDPは、接続されたコンピューターが応答を送信する必要があるアプリケーションを管理できませんでした.
データセキュリティ
TCPの優れた構造により、ネットワーク間の接続が可能になり、インターネットはアカデミアを超えてビジネス界に拡大し始めました。の作成 ワールドワイドウェブ, 1991年に公開されたのは、Hypertext Transfer Protocol（HTTP）を運ぶWebページがTCPの上に簡単に配置できるためでした。.
インターネットをまとめて、一般にアクセス可能なWorld Wide Webを開発した学者と技術者は、 青い空の思想家. 彼らは、世界中の人々の間の研究を加速し、相互作用を改善する技術とその可能性に興奮していました。. 彼らは彼らの素晴らしい発明が泥棒、詐欺師、都市テロリストへの贈り物だったという事実を説明できませんでした. インターネットもWorld Wide Webもセキュリティがまったくありませんでした.
消費者主導の Netscape Corporation この問題を見つけるために。 Netscapeは、世界をリードするWebブラウザーを作成し、無料で提供して、一般大衆にインターネットを普及させました。計画は機能し、情報交換と連絡チャネルが広がり、より多くの人々がインターネットサービスにサインアップすることを奨励しました。しかし セキュリティの欠如は、Webの商業化に対する障壁を提示しました. 人々にオンラインサービスへの支払いを促す能力がなければ、企業が新しいアプリケーション、ウェブサイト、またはオンラインサービスの開発に投資するインセンティブはありませんでした。.
Web上で支払いを収集する際の主な障壁は、セキュリティの欠如でした。インターネット送信でのデータ盗難に関するいくつかの見出しは、インターネットを商業的に実行可能にする可能性を封じています。しかしながら, NetscapeはHTTPSを思いついた – 伝送を保護した安全なバージョンのHTTP. これらのセキュリティ手順のTCP / IPスタックの理想的な場所は、TCPのセッション確立プロセス中です。そう, TCPはインターネットの運用にさらに不可欠になりました UDPが使用される可能性はさらに低いように思われました.
UDPが離陸
1980年以来存在しているにもかかわらず, UDPは完全に見落とされていました 今世紀の初めにブロードバンドインターネットサービスが利用可能になるまで。 Webおよびその他のインターネットアプリケーションがTCPの機能を拡張している間、ユーザーデータグラムプロトコルはほとんど無視されました。.
しかしながら, インターネット経由で音声会話やビデオ会議を行う機能は、常に企業にアピールしています. これらのアプリケーションはブロードバンドの前に存在していましたが、より高速なプライベートネットワークでのみ使用できます。サウンドとビデオをネットワーク経由で渡す技術が確立された, ブロードバンドの高速化により、これらのアプリケーションを一般の人々が利用できるようになりました 実現可能なアイデアになりました。しかし、インターネット経由で利用可能な速度は十分に十分ではありませんでした.
インターネットからちょうど十分な速度を引き出すための即時の解決策は、TCPと ほとんど忘れられているUDPに目を向ける.
TCPの問題
インタラクティブなアプリケーションは、送信中に発生する問題の一部を処理する必要があります。これらのアプリケーションが本当に望んでいないTCPの主な機能の1つは バッファリング.
TCPは、パケットが順番に到着するようにします。パケットがストリームから欠落している場合, 受信TCP実装は、その特定のパケットを再送信するために、送信TCPプログラムに要求を送信します. それまでの間、そのパケットは遅れて到着する可能性があります。 TCPはスライディングフレームシステムを使用して到着パケットを処理し、セグメントが遅れたり失われたりすると、そのスライドが詰まる. メモリ内のいくつかのフレームの一時的な保存は、バッファリングと呼ばれるものです. TCPは、欠落しているシーケンス番号を持つパケットで空のスロットを満たすことができるまで待機します。インターネットテレフォニーの場合、このようなアクションにより回線がサイレントになります。ビデオストリーミングでは、パケットの欠落を待つとビデオプレーヤーがフリーズします。.
対話型アプリケーションには、TCPバッファリングを回避する手順がありません. スタック層の背後にある原則は、上位層がサービスを要求し、それを提供するために下位層に任せることです。アプリケーションがトランスポートレイヤーに送信できる「そのまま」のシグナルはありません。.
デジタル電話の会話でパケットが失われた場合、発信者は短い沈黙を経験しますが、両側のアプリケーションは移動し、次のパケットの送受信を続けます。. 紛失したパケットが回復するまでに、対話型の会話は既に進行しているため、ストリームに再び挿入しようとしても意味がありません。;損失を帳消しにして続けるほうがいいです。同様に、パケットの損失はライブビデオストリームの短いスキップを意味し、視聴者は1ミリ秒のフレームのプロットを保持するよりもビデオが前進し続けるよりもはるかに多くなります.
ビデオプレーヤーが一時停止し、メッセージ「バッファリング」をご覧ください。通常、完了したバッファリングの割合を示すカウンターもあります。このバッファリングは、接続の転送速度がビデオ再生のフレームレートよりも遅い場合に発生します。ただし、このメッセージに関する重要なポイントは、バッファリングがトランスポートプロトコルではなくプレーヤーによって管理されていることを示していることです。.
提携プロトコル
対話型アプリケーションはTCPによる遅延を望んでいませんでしたが、そのプロトコルの機能の一部を望んでいました。彼らはUDPが提供できる以上のものを望んでいました。そのため、TCPの機能の一部を埋めるために他のプロトコルが考案されました.
セッション開始プロトコル
セッション開始プロトコル（SIP）は、Voice over IP（VoIP）アプリケーション用に開発されました。インターネットテレフォニーはTCPのバッファリングを必要としませんでしたが、電話の従来のコール確立手順をエミュレートする必要がありました – ダイヤル、呼び出し音、通話中、ピックアップ、通話終了。ただし、SIPはセッション全体を管理するのではなく、TCPの接続作成およびティアダウン機能を処理するだけです。インターネット上で実行されるすべてのコールはSIPを使用します。そのため、「SIP」は「VoIP.」
高速デジタル接続で音声トラフィックを一括して実行することを「SIPトランキング.」インターネットから通常の固定電話に通話を切り替えることを「SIPターミネーション.」デジタルテレフォニー業界では、SIPを使用してテクノロジを識別していますが、そのすべての活動の基盤はUDPです.
リアルタイム転送プロトコル
TCPは対話型トラフィックのオーバーヘッドが大きすぎるため、捨てる必要があるという決定にもかかわらず, 通信エンジニアは、TCPが提供する施設に戻り続けました そして、彼らは彼らがUDPでそれらを持つことができることを望みました。 Real-Time Transport Protocol（RTP）は、UDPを使用するときに経験する機能の多くの不足を補います.
UDPをメディアストリーミングに関連させるこれらのアドオンプロトコルの主要な機能は、TCPで従来管理されていたプロセスの一部をアプリケーションにプッシュできることです。. RTPは、TCPのトラフィック管理機能の一部を処理しますが、すべてではありません.
RTPは、シーケンス外のパケットを並べ替えて、失われたパケットを記録できます。ただし、シーケンス機能を実装する必要はなく、トランスポート層でバッファリングせずに実装することは不可能です.
RTP制御プロトコル
RTPは常にRTCPと提携しています, これはRTP制御プロトコルです。 RTPCは、TCPのセッション管理機能の一部をエミュレートしますが、プロトコルの基本原則はストリームに侵入せず、メディア伝送を遅くしないことです。そのため、その活動はまれです. プロトコルは、パケット損失を含むパフォーマンスデータを収集します, および転送レート情報. 受信プレーヤーはこの情報を使用して、ビデオの解像度を下げるか、別のビデオコーディング標準に切り替えるかを決定できます。.
ビデオおよびオーディオアプリケーションを使用する場合、RTPとRTCPの両方が関係していることはほぼ確実です。 「インターリーブ」RTSPの定義にあるオプション（下記参照）は、RTP送信をTCPに移動します。ただし、これは異常な提案であり、ラボを超えて実装されたことはありません。その仕様がなければ、すべてのRTPおよびRTCPアクティビティはUDPによって運ばれます.
リアルタイムストリーミングプロトコル
リアルタイムストリーミングプロトコル（RTSP）は、ほとんどの場合、ビデオおよびオーディオの再生または録音アプリケーションに関与します。. このプロトコルは、プレーヤーとレコーダーにコントロールボタンを提供します. これらは、一時停止、記録/再生、早送り、巻き戻しです。不思議なことに、RTSPはUDPで実行できますが、UDPがサポートするビデオまたはオーディオストリームと提携している場合でも、通常はTCPで転送されます.
UDP専用アプリケーション
アプリケーションをサポートする多くの軽量ネットワークは、TCP機能のシミュレーションを構成する他のプロトコルなしでUDPを使用します. これらの機能は、プライベートネットワークでの使用のみを目的としています。 認証手順や伝送暗号化が含まれていないため.
ネットワークを管理する場合は、 ネットワークタイムプロトコル（NTP）, その ドメインネームシステム（DNS）, その 動的ホスト構成プロトコル（DHCP）, そしてその 簡易ファイル転送プロトコル（TFTP）. これらの管理サービスはすべてUDP上で実行されます。これらのプライベートネットワークアプリケーションを超えて、UDP上でのみ実行されるアプリケーションを見つけることは非常に困難です。.
UDP vs TCP
UDPヘッダー構造とTCPヘッダー構造の比較は、UDPの制限を示しています.
UDPヘッダーには4つのフィールドしかありません。これらの4つのうち、 送信元ポート フィールドはオプションであり、空白のままにすることができます。 IPv4では、 チェックサム フィールドもオプションですが、IPv6の実装には必須です。これは、IPv4伝送の場合、UDPヘッダーに必要な情報は2つだけであるということです。.
TCPヘッダーは、さらに多くの情報を運ぶことができます.
図からわかるように、TCPパケットヘッダーには、ヘッダーの意味を調整する一連の9つのフラグがあります。イベントには「緊急」フィールドがあります。これにより、TCPシステムはUDPよりもはるかに柔軟になり、UDPの開発に費やされた時間よりも、TCPの手順とそのパケットヘッダーの構造により多くの時間が費やされたことを示しています。.
TCPヘッダーに送信元ポートを含める必要があるという事実により、送信元と宛先のIPアドレスと送信元と宛先のポート番号からセッションIDを作成して、より一意のソケットを作成できます。 UDPでは、セッションを作成する手順がないため, 各メッセージは完了したタスクとして扱われます, プロトコルはパケットをつなぎ合わせようとしません。したがって、USPを使用するアプリケーションは、その継続性を自分で管理する必要があります.
UDPのセキュリティ
TCPの接続指向の方法により、UDPのプロトコルでのセキュリティの実装がはるかに簡単になります。ただし、UDPで利用可能な暗号化標準があります。セキュリティUDPを直接目的とする主なオプションは、Datagram Transport Layer SecurityプロトコルまたはDTLSです.
幸運なことに, DTLSは、多くの無料のオープンソースライブラリで利用できます。, そのため、プロトコル定義をくまなく調べて、それを実装するためにオープンプログラムを作成する必要はありません。. OpenSSL, これは、オープンソースコードのライブラリであり、Transport Layer Securityの実装の最も一般的なソースです。これは、TCPで最も広く実装されているセキュリティシステムです。このライブラリも DTLS実装を含む, したがって、安全なTCP接続を提供する同じアプリケーションで安全なUDPオプションに遭遇できるはずです。.
UDPユーザーの別のオプションは、インターネット層で動作するように設計されたセキュリティシステムに依存することです。これは IPSec, またはインターネットプロトコルセキュリティ。 IPSecはトランスポート層の下で動作するため、ポートを操作できません。したがって、UDPがセッションを維持できないという事実は、IPSecが使用されている場合は重要ではありません。 – IP層プロトコルもセッションを作成できません. 下位システムとして, IPSecは、UDPを含むトランスポート層プロトコルをサポートできます。.
IPSecには認証方法が含まれ、パケットを暗号化して盗聴スヌーパーから保護します。 ITは、一般的なTLSと同等のセキュリティを提供しますが、あまり広く実装されていません。 IPSecはインターネットキーエクスチェンジ（IKEv2）システムを使用して認証をセットアップするため、IPSecはIKEv2として請求されることがよくあります。 IKEv2方法論では、 Diffie-Hellman鍵交換手順, これは、TLSがHTTPSセキュアWebページセッション方法論に使用するシステムとまったく同じです.
KerberosとKerberosのキーのインターネットネゴシエーション（KINK）は、通常Kerberosと呼ばれるセキュリティシステムの2つの要素です。 Kerberosセッション確立手順は、「証明書」を使用するTLS方式に類似した「チケット」のシステムを使用します。スタックの最下部では、KerberosはIPSecによって支えられています。同名のKerberosレイヤーはUDPの上にあり、UDPソケットを使用して通信を容易にします。これはUDPに優しいセキュリティシステムです. Kerberosのエキサイティングな機能は、UDP転送を保護するためにAES暗号化を使用するオプションを許可することです。. AESはおそらく今日の一般的な使用で最も安全な暗号であり、世界最高のVPNプライバシー保護システムに推奨されるセキュリティ方式です。.
接続管理を提供しない環境で暗号化キーをネゴシエートするのは明らかに困難ですが、UDPはセキュリティオプションを提供します。したがって、UDPベースのアプリケーションを実装するときは、送信を保護するタスクを放棄しないでください.
UDPの未来
TCPを模倣するためにサイドプロトコルを使用しない純粋なUDPベースのアプリケーションはまれであり、さらに希少になる可能性があります。 UDPを使用する軽量ネットワークユーティリティは、セキュリティで保護されたローカルネットワークで繁栄します。ただし、新しいゼロデイ攻撃によるセキュリティの脅威が毎週増加しているため、構成管理とアドレス指定の重要なサービスを管理する安全でないプロトコルを持つという概念は愚かに満足しているようです。.
ネットワークがサービスをクラウドに移行すると、UDPベースのTFTPおよびDHCPのサービスがより安全な代替手段に置き換えられ始めます. HTTPS経由でアプリケーションをサーフィンする簡単なソリューションは、プログラミングの労力をかけずにセキュリティを提供し、HTTPSを搭載し、UDPの能力リストから機会を奪うTCPに未来を向けます。.
メディア送信をサポートするUDPのニッチは耐える可能性があります。インタラクティブアプリケーションをサポートするために、すでに多くのライバルトランスポートシステムが提案されていますが、VoIPおよびビデオストリーミングの最初の選択肢としての位置からUDPをノックしたものはありません。このライバルのリストには以下が含まれます。
Reliable User Datagram Protocol（RUDP）, シスコとマイクロソフトの実装があります.
ストリーム制御伝送プロトコル（SCTP）, UDP / RTP / RTCPコンボの代替として提案されたが失敗しましたが、完全に落ち着くことはありませんでした.
UDPと呼ばれるこのいアヒルの子は、ブロードバンドおよびインタラクティブアプリケーションの魔法のような変革力のおかげで、白鳥であることが発見されました。この活性化された星は、インターネットの海を楽に滑空し続けます.
どのような伝送方法を使用していますか？ UDPのugいアヒルの子を白鳥と見ていますか？以下のコメントセクションにあなたの経験について書いてください.
関連：
TCP / IPの究極のガイド
TCPdumpとは?
SolarWinds TFTPサーバーのレビュー
TFTPD32 TFTPサーバーのレビュー
画像：
CC BY-SA 2.5の下でライセンスされている英語版ウィキブックスのDevarshiによるUDPのヘッダー
Wikimedia Commonsを介したQuliyevfermanによるビットスケールのTCPパケットレイアウト。 CC BY-SA 4.0でライセンスされています