Loading article…
通信プロトコルは、通信システムの2つ以上のエンティティが物理量の任意の変化を介して情報を伝送できるようにする規則のシステムです。プロトコルは、通信の規則、構文、セマンティクス、同期、および可能なエラー回復方法を定義します。プロトコルは、ハードウェア、ソフトウェア、またはその両方の組み合わせによって実装される場合があります。 [1]
通信システムは、さまざまなメッセージを交換するために明確に定義された形式を使用します。各メッセージには、特定の状況に対して事前に決定された可能な応答の範囲から応答を引き出すことを意図した正確な意味があります。指定された動作は、通常、実装方法とは無関係です。通信プロトコルは、関係者間で合意される必要があります。[2]合意に達するために、プロトコルが技術標準に開発される場合があります。プログラミング言語は計算について同じことを記述するため、プロトコルとプログラミング言語の間には密接な類似性があります。プロトコルは通信に対して、プログラミング言語は計算に対してです。 [3]別の定式化では、プロトコルは通信に対して、アルゴリズムは計算に対してであると述べています。[4]
複数のプロトコルは、多くの場合、単一の通信のさまざまな側面を説明します。連携して動作するように設計されたプロトコルのグループは、プロトコル スイートと呼ばれ、ソフトウェアに実装されると、プロトコル スタックになります。
インターネット通信プロトコルは、インターネット技術特別調査委員会(IETF)によって公開されています。IEEE (電気電子技術者協会) は有線および無線ネットワークを扱い、国際標準化機構(ISO) はその他のタイプを扱います。ITU -T は公衆交換電話網(PSTN) の通信プロトコルと形式を扱います。PSTN とインターネットが融合するにつれて、標準も融合に向かっています。
通信システム
歴史
現代のデータ通信の文脈で「プロトコル」という用語が初めて使用されたのは、1967年4月の「NPLデータ通信ネットワークで使用するプロトコル」と題された覚書である。英国国立物理学研究所でパケット交換の先駆者であるドナルド・デイヴィスの指導の下、ロジャー・スキャントルベリーとキース・バートレットがNPLネットワーク向けに作成した。[5] [6] [7] [8] [9]
ARPANETでは、1969 年のホスト間通信の出発点は、ボブ・カーンが書いた1822 プロトコルであり、IMP へのメッセージの送信を定義しました。[10]スティーブ・クロッカーとジョン・ポステル、ヴィント・サーフなどの大学院生によって開発された ARPANET のネットワーク制御プログラム(NCP) は、1970 年に初めて実装されました。 [11] NCP インターフェイスにより、アプリケーション ソフトウェアは、より高レベルの通信プロトコルを実装することで ARPANET を介して接続できるようになりました。これは、プロトコル階層化の概念の初期の例です。[12]
1970年代初頭にルイ・プザンが設計したCYCLADESネットワークは、エンドツーエンドの原則を初めて実装し、パケット交換ネットワーク上でのデータの信頼性の高い配信をネットワーク自体のサービスではなくホストに責任を持たせた。 [13]彼のチームは、ベストエフォート型サービスを使用しながらユーザーアプリケーションに信頼性の高い仮想回線サービスを提供するという非常に複雑な問題に初めて取り組み、伝送制御プロトコル（TCP）の初期の貢献となった。[14] [15] [16]
ゼロックスPARCのボブ・メトカーフらは、インターネットワーキングのためのイーサネットとPARCユニバーサルパケット（PUP）のアイデアを概説した。[17]
1970年代初頭のボブ・カーンとヴィント・サーフによる研究により、伝送制御プログラム（TCP）が策定されました。[18] TCPのRFC 675仕様は、1974年12月にサーフ、ヨゲン・ダラル、カール・サンシャイン によって書かれましたが、この時点ではまだモノリシックな設計でした。
国際ネットワークワーキンググループは、コネクションレス型データグラム標準に合意したが、これは1975年にCCITTに提出されたが、CCITTにもARPANETにも採用されなかった。 [19]別の国際的な研究、特にレミ・デプレの研究は、仮想回線に基づくX.25標準の開発に貢献し、これは1976年にCCITTに採用された。[20] [21]コンピュータメーカーは、 IBMのシステムネットワークアーキテクチャ（SNA）、デジタルイクイップメントコーポレーションのDECnet、ゼロックスネットワークシステムなどの独自のプロトコルを開発した。[22]
TCPソフトウェアは、TCP/IPと呼ばれるモジュラープロトコルスタックとして再設計されました。これは1982年にSATNETに、1983年1月にARPANETにインストールされました。RFC 1122とRFC 1123で概説されているように、1989年までに完全なインターネットプロトコルスイートが開発されたことで、新興インターネットのコアコンポーネントとしての包括的なプロトコルスイートとしてのTCP /IPの成長の基礎が築かれました。[23]
通信規格の参照モデルに関する国際的な取り組みの結果、1984年にOSIモデルが発表された。1980年代後半から1990年代前半にかけて、技術者、組織、国家の間では、OSIモデルとインターネットプロトコルスイートのどちらの標準が最良かつ最も堅牢なコンピュータネットワークを実現するのかという問題で意見が分かれた。 [24] [25] [26]
コンセプト
ネットワークやその他のメディアを介してデバイス間で交換される情報は、通信プロトコル仕様で定義できる規則と規約によって管理されます。通信の性質、交換される実際のデータ、および状態に依存する動作は、これらの仕様によって定義されます。デジタルコンピューティングシステムでは、ルールはアルゴリズムとデータ構造によって表現できます。プロトコルは通信に対して、アルゴリズムやプログラミング言語は計算に対してであるのと同じです。[3] [4]
オペレーティングシステムには通常、共有データを操作して相互に通信する一連の連携プロセスが含まれています。この通信は、プロセスコード自体に埋め込むことができる、よく理解されているプロトコルによって制御されます。[27] [28]対照的に、共有メモリがないため、通信システムは共有伝送媒体を使用して相互に通信する必要があります。伝送は必ずしも信頼できるわけではなく、個々のシステムが異なるハードウェアまたはオペレーティングシステムを使用する場合があります。
ネットワークプロトコルを実装するには、プロトコルソフトウェアモジュールをマシンのオペレーティングシステムに実装されたフレームワークとインターフェースします。このフレームワークはオペレーティングシステムのネットワーク機能を実装します。[29]プロトコルアルゴリズムが移植可能なプログラミング言語で表現されている場合、プロトコルソフトウェアはオペレーティングシステムに依存しないようになります。最もよく知られているフレームワークは、TCP/IPモデルとOSIモデルです。
インターネットが開発された当時、抽象化レイヤリングはコンパイラとオペレーティングシステムの設計の両方において成功した設計アプローチであることが証明されており、プログラミング言語と通信プロトコルの類似性を考慮して、もともとモノリシックだったネットワークプログラムは協調するプロトコルに分解されました。[30]これにより、現在ではプロトコル設計の基礎となっている階層化プロトコルの概念が生まれました。[31]
システムは通常、伝送を処理するために単一のプロトコルを使用するのではなく、プロトコルスイートと呼ばれる連携するプロトコルのセットを使用します。[32]最もよく知られているプロトコルスイートには、TCP/IP、IPX/SPX、X.25、AX.25、AppleTalkなどがあります。
プロトコルは機能に基づいてグループ分けすることができます。たとえば、トランスポートプロトコルのグループがあります。機能はレイヤーにマッピングされ、各レイヤーは、たとえば、アプリケーション、トランスポート、インターネット、ネットワークインターフェース機能に関連するさまざまな問題を解決します。[33]メッセージを送信するには、各レイヤーからプロトコルを選択する必要があります。次のプロトコルの選択は、各レイヤーのプロトコルセレクタを使用してメッセージを拡張することによって行われます。[34]
種類
通信プロトコルには、伝送されるコンテンツの表現方法に基づいて、テキストベースとバイナリの2種類があります。[35]
テキストベース
テキストベース プロトコルまたはプレーン テキスト プロトコルは、その内容を人間が判読できる形式で表現します。多くの場合、プレーン テキストはASCIIやUTF-8などの機械可読エンコーディングでエンコードされた形式、またはIntel 16 進形式、XML、JSONなどの構造化テキスト ベース形式で表現されます。
人間がすぐに読めるという点は、コンピュータ環境での使用に固有の利点（機械的な解析の容易さや帯域幅の利用率の向上など） を持つネイティブ バイナリ プロトコルとは対照的です。
ネットワークアプリケーションには、データをカプセル化するさまざまな方法があります。インターネットプロトコルで非常に一般的な方法の1つは、テキスト指向の表現で、要求と応答をASCIIテキストの行として送信し、改行文字（通常はキャリッジリターン文字）で終了します。コマンドに人間が読めるプレーンテキストを使用するプロトコルの例としては、FTP（ファイル転送プロトコル）、SMTP（シンプルメール転送プロトコル）、HTTP（ハイパーテキスト転送プロトコル）の初期バージョン、およびフィンガープロトコルがあります。[36]
テキストベースのプロトコルは通常、人間による解析と解釈に最適化されているため、デバッグ中やプロトコル開発の初期設計段階など、プロトコルの内容を人間が検査する必要がある場合に適しています。
バイナリ
バイナリプロトコルは、ASCIIエンコードされた人間が読める文字に対応する値のみを使用するテキストベースのプロトコルとは対照的に、バイトのすべての値を使用します。バイナリプロトコルは、人間ではなく機械によって読み取られるように設計されています。バイナリプロトコルには簡潔さという利点があり、これは伝送と解釈の速度につながります。[37]
バイナリは、 EbXML、HTTP/2、HTTP/3、EDOCなどの最新の標準を記述する規範文書で使用されています。[38] UMLのインターフェース[39]もバイナリプロトコルと見なすことができます。
基本要件
ネットワーク経由でデータを取得することは、プロトコルの問題の一部にすぎません。受信したデータは、会話の進行状況のコンテキストで評価する必要があるため、プロトコルにはコンテキストを記述するルールが含まれている必要があります。これらの種類のルールは、通信の構文を表すと言われています。その他のルールは、交換が行われるコンテキストでデータが意味を持つかどうかを決定します。これらの種類のルールは、通信の セマンティクスを表すと言われています。
通信システムでは、通信を確立するためにメッセージが送受信されます。したがって、プロトコルは送信を管理するルールを規定する必要があります。一般的に、以下の多くに対処する必要があります。[40]
- データ交換のためのデータ形式
- デジタルメッセージのビット列が交換される。ビット列はフィールドに分割され、各フィールドにはプロトコルに関連する情報が含まれる。概念的には、ビット列はヘッダーとペイロードと呼ばれる2つの部分に分割される。実際のメッセージはペイロードで運ばれる。ヘッダー領域には、プロトコルの動作に関連するフィールドが含まれる。最大転送単位（MTU）よりも長いビット列は、適切なサイズの部分に分割される。[41]
- データ交換のためのアドレス形式
- アドレスは送信者と意図された受信者の両方を識別するために使用されます。アドレスはビット列のヘッダー領域で運ばれ、受信者はビット列が関心の対象であり、処理する必要があるか無視する必要があるかを判断できます。送信者と受信者間の接続は、アドレスペア（送信者アドレス、受信者アドレス）を使用して識別できます。通常、一部のアドレス値には特別な意味があります。すべて1のアドレスは、ネットワーク上のすべてのステーションのアドレス指定を意味すると解釈できるため、このアドレスに送信すると、ローカルネットワークでブロードキャストが発生します。アドレス値の意味を説明する規則は、まとめてアドレス指定スキームと呼ばれます。[42]
- アドレスマッピング
- プロトコルによっては、ある方式のアドレスを別の方式のアドレスにマッピングする必要があることがあります。たとえば、アプリケーションによって指定された論理IPアドレスをイーサネットMACアドレスに変換する場合などです。これをアドレスマッピングと呼びます。[43]
- ルーティング
- システムが直接接続されていない場合、意図した受信者までの経路上にある中間システムが送信者に代わってメッセージを転送する必要があります。インターネットでは、ネットワークはルーターを使用して接続されます。ルーターを介したネットワークの相互接続は、インターネットワーキングと呼ばれます。
- 伝送エラーの検出
- データの破損が起こりうるネットワークでは、エラー検出が必要です。一般的なアプローチでは、データ領域のCRCがパケットの末尾に追加され、受信側が破損による差異を検出できるようになります。受信側はCRCの差異に基づいてパケットを拒否し、何らかの方法で再送信を手配します。[44]
- 謝辞
- コネクション指向通信では、パケットが正しく受信されたことの確認応答が必要である。確認応答は受信者からそれぞれの送信者に返される。[45]
- 情報の損失 - タイムアウトと再試行
- パケットはネットワーク上で失われたり、転送中に遅延したりすることがあります。これに対処するために、一部のプロトコルでは、送信者は一定時間内に受信者から正しく受信されたことの確認応答を期待することがあります。したがって、タイムアウトが発生すると、送信者は情報を再送信する必要があります。 [a]リンクが永久に切断された場合、再送信は効果がありません。そのため、再送信回数は制限されています。再試行制限を超えるとエラーと見なされます。[46]
- 情報の流れの方向
- 半二重リンクのように一度に一方向にしか送信できない場合や、共有メディアのように一度に1人の送信者からしか送信できない場合は、方向に対処する必要があります。これはメディアアクセス制御として知られています。2つの当事者が同時に送信したり送信したりする場合の衝突や競合に対応できるように準備する必要があります。 [47]
- シーケンス制御
- 長いビット列を断片に分割してネットワーク上で個別に送信した場合、断片が失われたり遅延したり、ネットワークの種類によっては宛先までの経路が異なる場合があります。その結果、断片は順序どおりに到着しないことがあります。再送信により断片が重複する可能性があります。送信側で断片に順序情報をマークすることで、受信者は何が失われたか、または重複したかを判断し、必要な再送信を要求して元のメッセージを再構成できます。[48]
- フロー制御
- フロー制御は、送信者が受信側または中間ネットワーク機器が処理できる速度よりも速く送信する場合に必要になります。フロー制御は、受信側から送信側へのメッセージングによって実装できます。[49]
- キューイング
- 通信プロセスまたはステート マシンは、キュー (または「バッファ」) (通常は FIFO キュー) を使用して、送信された順序でメッセージを処理します。また、優先順位が異なる複数のキューが存在する場合もあります。
プロトコル設計
システムエンジニアリングの原理は、共通のネットワークプロトコル設計原理のセットを作成するために適用されてきました。複雑なプロトコルの設計では、多くの場合、より単純で連携するプロトコルに分解されます。このような連携するプロトコルのセットは、概念フレームワーク内でプロトコルファミリまたはプロトコルスイートと呼ばれることがあります[32]。
通信システムは並行して動作します。並行プログラミングの重要な側面は、適切な順序で通信メッセージを受信および送信するためのソフトウェアの同期です。並行プログラミングは、伝統的にオペレーティングシステム理論のテキストのトピックでした。[50]並行プログラムは隠れた高度なバグが含まれていることで悪名高いため、形式検証は不可欠であると思われます。[51]並行性と通信の研究に対する数学的なアプローチは、通信シーケンシャルプロセス(CSP) と呼ばれます。[52]並行性は、ミーリーマシンやムーアマシンなどの有限状態マシンを使用してモデル化することもできます。ミーリーマシンとムーアマシンは、通信や一般的な電子機器で使用されるハードウェアの形で遭遇するデジタル電子システムの設計ツールとして使用されています。[53] [より良い情報源が必要]
文献には、コンピュータ通信とプログラミングの間に数多くの類似点が示されています。類似点として、プロトコルの転送メカニズムは中央処理装置 (CPU) に相当します。フレームワークでは、プログラマが互いに独立して連携するプロトコルを設計できるようにするルールが導入されています。
レイヤー
現代のプロトコル設計では、プロトコルは階層化されてプロトコル スタックを形成します。階層化とは、プロトコル設計タスクをより小さなステップに分割する設計原則です。各ステップは特定の部分を実行し、プロトコルの他の部分とは少数の明確に定義された方法でのみ相互作用します。階層化により、ケースの組み合わせ爆発なしでプロトコルの各部分を設計およびテストでき、各設計を比較的シンプルに保つことができます。
インターネットで使用されている通信プロトコルは、多様で複雑な設定で機能するように設計されています。インターネットプロトコルは、単純さとモジュール性を考慮して設計されており、インターネットプロトコルスイートで定義された機能層の大まかな階層に適合しています。[54]最初の2つの連携プロトコルである伝送制御プロトコル（TCP）とインターネットプロトコル（IP）は、モノリシック通信プロトコルである元の伝送制御プログラムをこの階層化された通信スイートに分解した結果生まれました。
OSI モデルは、インターネット以前のネットワークの経験に基づいて、プロトコル相互作用のより厳格なルールと厳密な階層化を備えた一般的な通信の参照モデルとして国際的に開発されました。
通常、アプリケーション ソフトウェアは堅牢なデータ トランスポート層の上に構築されます。このトランスポート層の基盤となるのは、インターネットでは通常コネクションレスであるデータグラム配信およびルーティング メカニズムです。ネットワーク間のパケット リレーは、ネットワーク リンク テクノロジのみを含む別の層で行われます。このテクノロジは、多くの場合、イーサネットなどの特定の物理層テクノロジに固有のものです。レイヤリングにより、必要に応じてテクノロジを交換できるようになります。たとえば、異なるネットワークの接続に対応するために、プロトコルは多くの場合、トンネリング構成でスタックされます。たとえば、IP は非同期転送モード(ATM) ネットワークを介してトンネリングされる場合があります。
プロトコル階層化
プロトコル階層化はプロトコル設計の基礎を形成します。[31]これにより、単一の複雑なプロトコルをより単純で連携するプロトコルに分解できます。[54]プロトコル層はそれぞれ異なるクラスの通信問題を解決します。これらの層が一緒になって階層化スキームまたはモデルを構成します。
計算はアルゴリズムとデータを扱います。通信はプロトコルとメッセージに関係します。したがって、データフロー図の類似物は、ある種のメッセージフロー図です。[4]プロトコルの階層化とプロトコルスイートを視覚化するために、2つのシステムAとBの内外のメッセージフローの図を図3に示します。システムAとBは両方とも同じプロトコルスイートを使用します。垂直フロー（およびプロトコル）はシステム内であり、水平メッセージフロー（およびプロトコル）はシステム間です。メッセージフローはルールによって制御され、データ形式はプロトコルによって指定されます。青い線は（水平）プロトコル層の境界を示します。
ソフトウェアの階層化
プロトコルをサポートするソフトウェアは階層構造になっており、プロトコル階層構造との関係は図 5 に示されています。
システム A でメッセージを送信するには、最上位層のソフトウェア モジュールが直下のモジュールとやり取りし、カプセル化されるメッセージを渡します。下位モジュールは、実装されているプロトコルに従ってヘッダー データを入力し、下位モジュールとやり取りして、通信チャネルを介してシステム B の下位モジュールにメッセージを送信します。受信側システム B では逆のことが起き、最終的にメッセージは元の形式でシステム B の最上位モジュールに配信されます。[55]
プログラム翻訳はサブ問題に分割される。その結果、翻訳ソフトウェアも階層化され、ソフトウェア層を独立して設計することが可能になる。TCP/IPの階層化でも同じアプローチが見られる。[56]
アプリケーション層以下のモジュールは、一般的にオペレーティングシステムの一部と見なされます。これらのモジュール間でデータを渡すことは、アプリケーションプログラムとトランスポート層間でデータを渡すよりもはるかに安価です。アプリケーション層とトランスポート層の境界は、オペレーティングシステム境界と呼ばれます。[57]
厳密な階層化
厳密な階層化モデルに厳密に従うことは、厳密な階層化として知られる手法ですが、必ずしもネットワーク構築に最適なアプローチとは限りません。[58]厳密な階層化は、実装のパフォーマンスに悪影響を及ぼす可能性があります。[59]
プロトコル階層化は今日ではコンピュータネットワークの分野で広く使用されていますが、プロトコルスタックを抽象化すると上位層が下位層の機能を複製する可能性があるため、歴史的に多くの研究者から批判されてきました[60]。その主な例としては、リンクごととエンドツーエンドの両方でのエラー回復が挙げられます。[61]
デザインパターン
通信プロトコルの設計と実装において一般的に繰り返し発生する問題は、ソフトウェア設計パターンによって解決できます。[62] [63] [64] [65] [66]
正式な仕様
通信構文を記述する一般的な形式手法としては、抽象構文記法 1 ( ISO標準) と拡張バッカス・ナウア記法( IETF標準) があります。
有限状態機械モデルは、プロトコルの可能な相互作用を形式的に記述するために使用される。[67] [68]および通信有限状態機械[69]
プロトコル開発
通信を行うには、プロトコルを選択する必要があります。ルールは、アルゴリズムとデータ構造で表現できます。アルゴリズムを移植可能なプログラミング言語で表現することで、ハードウェアとオペレーティング システムの独立性が強化されます。仕様のソースの独立性により、より広範な相互運用性が実現します。
プロトコル標準は、標準化プロセスを開始する標準化団体の承認またはサポートを取得することで作成されるのが一般的です。標準化団体のメンバーは、自主的に作業結果を遵守することに同意します。メンバーは、プロトコルに関連する大きな市場シェアを管理していることが多く、多くの場合、標準は重要な公共の利益に役立つと考えられるため、法律または政府によって施行されるため、承認を得ることはプロトコルにとって非常に重要になります。
プロトコル標準の必要性
プロトコル標準の必要性は、IBMが発明したバイナリ同期通信(BSC) プロトコルに何が起こったかを見ればわかります。BSC は、2 つの別々のノードを接続するために使用された初期のリンク レベル プロトコルです。もともとマルチノード ネットワークで使用することを意図していませんでしたが、実際に使用してみると、プロトコルのいくつかの欠陥が明らかになりました。標準化がなかったため、メーカーや組織は自由にプロトコルを拡張し、ネットワーク上に互換性のないバージョンを作成しました。場合によっては、ユーザーが他のメーカーの機器を使用しないように意図的に行われたこともあります。元のバイナリ同期プロトコルには 50 を超えるバリエーションがあります。標準があれば、少なくともこのような事態の一部は防げたはずです。[29]
場合によっては、プロトコルが標準化プロセスを経ずに市場を独占することがあります。このようなプロトコルは、事実上の標準と呼ばれます。事実上の標準は、新興市場、ニッチ市場、または独占(または寡占) された市場でよく見られます。特に競争相手を追い払うために使用される場合、市場を非常にネガティブに支配する可能性があります。歴史的な観点から見ると、標準化は事実上の標準の悪影響を打ち消す手段と見なされるべきです。肯定的な例外も存在します。Linux のような事実上の標準オペレーティング システムは、ソースが公開され、オープンな方法で維持されているため、競争を招き、市場をこのようにネガティブに支配することはありません。
標準化団体
通信プロトコルに関連する標準化団体には、国際標準化機構(ISO)、国際電気通信連合(ITU)、電気電子学会(IEEE)、インターネット技術特別調査委員会(IETF)などがあります。IETF は、インターネットで使用されるプロトコルを管理しています。IEEE は、電子機器業界の商用および消費者向けデバイス用の多くのソフトウェアおよびハードウェア プロトコルを管理しています。ITU は、公衆交換電話網(PSTN) や多くの無線通信システムを設計する電気通信技術者の統括組織です。海洋電子機器には、 NMEA標準が使用されています。World Wide Web Consortium (W3C) は、Web テクノロジのプロトコルと標準を作成しています。
国際標準化団体は、国内または商業上の利害を考慮する必要がある地方組織よりも公平であると考えられています。標準化団体は将来の標準の研究開発も行っています。実際には、前述の標準化団体は互いに緊密に協力しています。[70]
プロトコルの開発には複数の標準化団体が関与することがある。それらの団体が調整されていない場合、結果としてプロトコルの定義が複数存在したり、メッセージの解釈が複数存在したり、互換性がなくなったりする可能性がある。ある定義における重要な不変条件（例えば、安定したルーティングループを防ぐために存続時間値が単調減少するなど）が、別の定義では尊重されない可能性がある。[71]
標準化プロセス
ISOでは、標準化プロセスは小委員会の作業グループを委託することから始まります。作業グループは、議論やコメントを促すために、関係者（他の標準化団体を含む）に作業草案と議論文書を発行します。これにより、多くの質問、多くの議論、そして通常は何らかの意見の相違が生じます。これらのコメントが考慮され、作業グループによって草案が作成されます。フィードバック、修正、妥協を経て、提案は国際規格草案の状態になり、最終的には国際規格になります。国際規格は、欠陥に対処し、主題に関する変化する見解を反映するために定期的に再発行されます。[72]
OSI標準化
インターネットの前身であるARPANETから学んだ教訓は、プロトコルが機能するにはフレームワークが必要であるということである。したがって、構造化プロトコル（階層化プロトコルなど）とその標準化に適した、汎用的で将来性のあるフレームワークを開発することが重要になる。これにより、機能が重複するプロトコル標準がなくなり、異なるレベル（レイヤー）でのプロトコルの責任を明確に定義できるようになる。[74]これにより、開放型システム間相互接続モデル（OSIモデル）が生まれ、さまざまなレイヤー仕様に準拠した標準プロトコルとサービスの設計のフレームワークとして使用されている。[75]
OSIモデルでは、通信システムは、基本的な伝送メカニズムを提供する基礎となる物理媒体によって接続されているものと想定されています。その上の層には番号が付けられています。各層は、すぐ下の層のサービスを使用して、その上の層にサービスを提供します。最上位層は、アプリケーションプロセスにサービスを提供します。層は、サービスアクセスポイントと呼ばれるインターフェースによって相互に通信します。各システムの対応する層は、ピアエンティティと呼ばれます。通信するために、特定の層の2つのピアエンティティは、下の層のサービスを使用して実装されたその層に固有のプロトコルを使用します。[76]各層には、特定の層のピアエンティティが通信する方法を定義するプロトコル標準と、特定の層が上の層と通信する方法を定義するサービス標準の2種類の標準があります。
OSI モデルでは、層とその機能は次のとおりです (最上位層から最下位層へ):
- アプリケーション層は、アプリケーションプロセスに以下のサービスを提供することができる：意図された通信相手の識別、通信に必要な権限の確立、相手の可用性と認証の決定、通信のプライバシーメカニズムに関する合意、エラー回復の責任とデータ整合性を確保するための手順に関する合意、協力するアプリケーションプロセス間の同期、構文上の制約（文字セットやデータ構造など）の識別、コストと許容可能なサービス品質の決定、必要なログオンおよびログオフ手順を含む対話規律の選択。[77]
- プレゼンテーション層は、アプリケーション層に対して、セッション確立の要求、データ転送、アプリケーション層間で使用される構文のネゴシエーション、必要な構文変換、フォーマット、特殊目的の変換（データ圧縮やデータ暗号化など）などのサービスを提供することができる。[78]
- セッション層は、プレゼンテーション層に以下のサービスを提供することができる：セッション接続の確立と解放、通常および迅速なデータ交換、送信プレゼンテーションエンティティが受信セッションエンティティに許可なくプレゼンテーションエンティティにデータを解放しないように指示できる検疫サービス、プレゼンテーションエンティティが特定の制御機能を実行する順番を制御できるようにする対話管理、セッション接続の再同期、プレゼンテーションエンティティへの回復不可能な例外の報告。[79]
- トランスポート層は、選択されたサービス品質に応じて、コスト効率の高い方法で信頼性が高く透過的なデータ転送を提供します。トランスポート層は、複数のトランスポート接続を1つのネットワーク接続に多重化したり、1つのトランスポート接続を複数のネットワーク接続に分割したりすることができます。[80]
- ネットワーク層は、トランスポートピアエンティティ間のネットワークパスの設定、保守、解放を行います。リレーが必要な場合、ルーティングとリレー機能はこの層によって提供されます。サービス品質は、接続が確立されたときにネットワークエンティティとトランスポートエンティティ間でネゴシエートされます。この層は、ネットワーク輻輳制御も担当します。[81]
- データリンク層は、データリンク接続のセットアップ、メンテナンス、解放を行います。物理層で発生したエラーは検出され、修正されることがあります。エラーはネットワーク層に報告されます。データリンクユニットの交換（フロー制御を含む）はこの層によって定義されます。[82]
- 物理層は、物理的な接続の電気的特性、使用される伝送技術、物理的な接続の設定、保守、クリアなどの詳細を記述します。[83]
TCP/IP の階層化スキームがコネクションレス型ネットワークを想定しているのに対し、RM/OSI はコネクション指向型ネットワークを想定している。[84]コネクション指向型ネットワークは広域ネットワークに適しており、コネクションレス型ネットワークはローカルエリアネットワークに適している。コネクション指向型通信には何らかの形のセッションと (仮想) 回線が必要であるため、(TCP/IP モデルにはない) セッション層が必要となる。ISO の構成メンバーは主に広域ネットワークに関心があったため、RM/OSI の開発はコネクション指向型ネットワークに集中し、コネクションレス型ネットワークは RM/OSI の補遺[85] [86]で初めて言及され、後に RM/OSI の更新版に組み込まれた。[87]
当時、[いつ? ] IETF はこの問題と、インターネットには存在しないプロトコルが必要であるという事実に対処する必要がありました。[要出典]その結果、IETF は「大まかな合意と実行中のコード」に基づく独自の標準化プロセスを開発しました。[88]標準化プロセスはRFC 2026で説明されています 。
現在、IETF はインターネットで使用されるプロトコルの標準化団体となっています。RM/OSI はモデルを拡張してコネクションレス サービスも含めるようにしており、このため TCP と IP の両方が国際標準として開発される可能性があります。[引用が必要]
ワイヤー画像
プロトコルのワイヤイメージとは、プロトコルメッセージを観察し、プロトコルによって明示的に意味が与えられた情報だけでなく、観察者によって行われた推論も含む、非参加の観察者が収集できる情報です。[89]暗号化されていないプロトコルメタデータはワイヤイメージを構成する1つのソースであり、パケットタイミングを含むサイドチャネルも寄与します。 [90]異なる立場にある異なる観察者は、異なるワイヤイメージを見る可能性があります。[91]ワイヤイメージは、エンドユーザーのプライバシーとプロトコルの拡張性 に関連しています。 [92]
ワイヤイメージの一部が暗号的に認証されていない場合、中間者（ミドルボックスなど）による変更の対象となり、プロトコルの動作に影響を与える可能性があります。[90]認証されていても、一部が暗号化されていない場合はワイヤイメージの一部となり、中間者がその内容に応じて介入する場合があります（特定のフラグを持つパケットをドロップするなど）。意図的に中間者による消費を意図した信号は、認証されていても暗号化されていないままになることがあります。[93]
ワイヤイメージは意図的に設計することができ、仲介者が観察できないはずの部分を暗号化し、仲介者が観察できるはずの部分に信号を提供する。[94]提供された信号がプロトコルの動作から切り離されている場合、信頼できなくなる可能性がある。[95]メタデータ暗号化は、ネットワーク管理と研究に悪影響を及ぼす。プロトコル設計者は、操作性と研究のための観察可能性と、骨化耐性およびエンドユーザーのプライバシーとのバランスを取る必要がある。[92] IETFは2014年に、プロトコル動作の大規模な監視は、ワイヤイメージからユーザーとその行動に関する情報を推測できるため、攻撃であると判断したと発表し、[96] IETFはプロトコル設計において「広範な監視を軽減するために取り組む」と述べた。[97]これは、以前は体系的に行われていなかった。[97]インターネットアーキテクチャ委員会は2023年に、プロトコルによるネットワークへの情報開示は意図的であること、[98]受信者と送信者の両方の同意を得て実行すること、[99]可能かつ必要な範囲で認証すること、[100]信頼性の程度に応じてのみ行動すること、[101]最小限に抑えて最小限の数のエンティティに提供することを推奨しました。[102] [103] IABによると、ワイヤイメージをエンジニアリングし、ネットワーク要素に提供される信号を制御することは、2023年には「発展途上の分野」でした。[104]
骨化
プロトコルの骨化とは、ネットワークプロトコルの柔軟性、拡張性、進化性が失われることである。これは主に、プロトコルのワイヤイメージに敏感なミドルボックスが原因であり、ミドルボックスは有効なメッセージを正しく認識できず、メッセージを中断したり干渉したりする可能性がある。[105]これはエンドツーエンドの原則に違反している。[106]二次的な原因としては、プロトコルのエンドポイント実装の柔軟性の欠如が挙げられる。[107]
骨化はインターネットプロトコルの設計と導入における大きな問題であり、新しいプロトコルや拡張機能がインターネット上に導入されないようにしたり、新しいプロトコルの設計に制約を設けたりする可能性がある。新しいプロトコルは、すでに導入されているプロトコルにカプセル化するか、別のプロトコルのワイヤイメージを模倣しなければならない可能性がある。 [108]骨化のため、伝送制御プロトコル(TCP) とユーザーデータグラムプロトコル(UDP) がインターネット上のトランスポートプロトコルの唯一の実用的な選択肢であり、 [109] TCP 自体が大幅に骨化しているため、プロトコルの拡張や変更が困難になっている。[110]
骨化を防ぐための推奨される方法には、プロトコルメタデータの暗号化[111]、拡張ポイントの実行とワイヤイメージの可変性が可能な限り完全に発揮されることの保証[112]などがある。既存の骨化を改善するには、プロトコル参加者間の調整が必要である。[113] QUICは、意図的に骨化防止特性を備えて設計された最初のIETFトランスポートプロトコルである。 [89]
分類
プロトコルの分類方式は、通常、使用ドメインと機能に重点を置きます。使用ドメインの例として、コネクション指向プロトコルとコネクションレス プロトコルは、それぞれコネクション指向ネットワークとコネクションレス ネットワークで使用されます。機能の例としては、トンネリング プロトコルがあります。これは、パケットを高レベル プロトコルでカプセル化し、高レベル プロトコルを使用してトランスポート システムを介してパケットを渡すために使用されます。
階層化スキームは、機能と使用ドメインの両方を組み合わせたものです。支配的な階層化スキームは、IETFとISOによって開発されたものです。階層化スキームの基本的な前提は、両者を区別する必要があるほど異なっているにもかかわらず、共通のプロトコルを2つのスキームのレイヤーに関連付けることで、両者を比較するのが一般的な方法です。[114] IETFの階層化スキームは、インターネット階層化またはTCP/IP階層化と呼ばれます。ISOの階層化スキームは、 OSIモデルまたはISO階層化と呼ばれます。
ネットワーク機器の構成では、専門用語による区別がよく用いられます。プロトコルという用語は厳密にはトランスポート層を指し、サービスという用語はトランスポート用のプロトコルを使用するプロトコルを指します。TCP と UDP の一般的なケースでは、サービスはポート番号によって区別されます。これらのポート番号への準拠は任意であるため、コンテンツ検査システムでは、サービスという用語は厳密にはポート番号を指し、アプリケーションという用語は検査シグネチャによって識別されるプロトコルを指すのによく使用されます。
参照
- ネットワークプロトコルのリスト
- プロトコルビルダー – ネットワーク接続コンポーネントを構築するためのプログラミングツール
注記
- ^ 確認応答を受信できなかった場合、元の送信または確認応答のいずれかが失われたことを示します。送信者にはこれらのケースを区別する手段がないため、すべてのデータが受信されたことを確認するには、元の送信が失われたという控えめな仮定を立てる必要があります。
参考文献
- ^ US 7529565、ヒルピッシュ、ロバート E.、ダッヒシャー、ロブ、マーク シール他、「ワイヤレス通信プロトコル」、2009 年 5 月 5 日発行、Starkey Laboratories Inc.およびOticon ASに譲渡
- ^ プロトコル、ブリタニカ百科事典、2012年9月12日時点のオリジナルよりアーカイブ、 2012年9月24日閲覧
- ^ ab Comer 2000、セクション 11.2 - 複数のプロトコルの必要性、p. 177、「それら (プロトコル) は通信にとって、プログラミング言語が計算にとってであるようなものです」
- ^ abc Comer 2000、セクション 1.3 - インターネット サービス、p. 3、「プロトコルは通信にとって、アルゴリズムは計算にとってである」
- ^ ノートン、ジョン（2015年9月24日）。未来の簡潔な歴史。オリオン。ISBN 978-1-4746-0277-8。
- ^ Cambell-Kelly, Martin (1987). 「国立物理学研究所におけるデータ通信 (1965-1975)」. Annals of the History of Computing . 9 (3/4): 221–247. doi :10.1109/MAHC.1987.10023. S2CID 8172150.
- ^ Pelkey, James L. 「6.1 通信サブネット: BBN 1969」。起業家資本主義とイノベーション: 1968-1988 年のコンピュータ通信の歴史。Kahn
の回想によると: ... Paul Baran の貢献 ... また、Paul は音声に関する考慮によってほぼ完全に動機付けられていたと思います。彼の書いたものを見ると、彼は低コストの電子機器であるスイッチについて語っていました。強力なコンピュータをこれらの場所に配置するというアイデアは、コスト効率が良いとは彼には思い浮かばなかったのです。そのため、コンピュータ スイッチのアイデアは存在していませんでした。プロトコルという概念自体が当時は存在していませんでした。そして、コンピュータ間の通信というアイデアは、実際には二次的な関心事でした。
- ^ウォルドロップ 、 M.ミッチェル（2018年）。『ドリームマシン』。ストライププレス。p.286。ISBN 978-1-953953-36-0バラン氏は、
コンピューター通信よりもデジタル音声通信に重点を置いていました。
- ^ Kleinrock, L. (1978). 「パケット通信の原理と教訓」. Proceedings of the IEEE . 66 (11): 1320–1329. doi :10.1109/PROC.1978.11143. ISSN 0018-9219.
Paul Baran ... は、ルーティング手順と、過酷な環境における分散通信システムの存続可能性に焦点を当てていましたが、現在私たちが理解しているような形でのリソース共有の必要性については焦点を当てていませんでした。実際、彼の研究にはソフトウェア スイッチの概念はありませんでした。
- ^ インターフェース メッセージ プロセッサ: ホストと IMP の相互接続の仕様(PDF) (レポート)。Bolt Beranek と Newman (BBN)。レポート番号 1822。
- ^ 書籍、高解像度。UGC-NET/JRF/SET PTP およびガイド教育および研究適性: UGC-NET、HD 製。高解像度書籍。
- ^ 「NCP – ネットワーク制御プログラム」。Living Internet。2022年8月7日時点のオリジナルよりアーカイブ。2022年10月8日閲覧。
- ^ ベネット、リチャード（2009年9月）。「変化のための設計：エンドツーエンドの議論、インターネットの革新、そしてネット中立性の議論」（PDF）。情報技術とイノベーション財団。pp. 7、11 。 2017年9月11日閲覧。
- ^ アバテ、ジャネット（2000年）。インターネットの発明。MITプレス。pp.124-127。ISBN 978-0-262-51115-5
実際、CYCLADESはARPANETとは異なり、インターネットワーキングを容易にするために明確に設計されており、例えば、さまざまなフォーマットやさまざまなレベルのサービスを扱うことができました
。 - ^ キム・ビョン・クン (2005)。インターネットの国際化：影響力とテクノロジーの共進化。エドワード・エルガー。pp. 51–55。ISBN 1845426754
NPLネットワークとARPANETに加えて、学術研究実験ネットワークであるCYCLADESもコンピュータネットワーク技術の発展に重要な役割を果たした
。 - ^ 「インターネットの第5の男」。エコノミスト。2013年11月30日。ISSN 0013-0613 。2020年4月22日閲覧。
1970年代初頭、プーザン氏はフランス、イタリア、イギリスを結ぶ革新的なデータネットワークを作成した。そのシンプルさと効率性は、数十台ではなく数百万台のマシンを接続できるネットワークへの道を示した。それはサーフ博士とカーン博士の想像力をかき立て、彼らはその設計の側面を、現在インターネットを動かしているプロトコルに取り入れた。
- ^ モスコヴィティス 1999、p.78-9
- ^ Cerf, V.; Kahn, R. (1974). 「パケットネットワーク相互通信プロトコル」(PDF) . IEEE Transactions on Communications . 22 (5): 637–648. doi :10.1109/TCOM.1974.1092259. ISSN 1558-0857. 2017年1月6日時点のオリジナルより アーカイブ(PDF) . 2020年2月23日閲覧。
著者は、国際ネットワークプロトコルの初期の議論で有益なコメントをくれた多くの同僚、特にR. Metcalfe、R. Scantlebury、D. Walden、およびH. Zimmerman、断片化とアカウンティングの問題について建設的なコメントをくれたD. DaviesとL. Pouzin、およびアソシエーションの作成と破壊についてコメントしてくれたS. Crockerに感謝します。
- ^ McKenzie, Alexander (2011). 「INWG とインターネットの構想: 目撃証言」. IEEE Annals of the History of Computing . 33 (1): 66–71. doi :10.1109/MAHC.2011.9. ISSN 1934-1547. S2CID 206443072.
- ^ Schwartz, Mischa (2010). 「X.25 仮想回線 - TRANSPAC IN France - インターネット以前のデータネットワーキング [通信の歴史]」. IEEE Communications Magazine . 48 (11): 40–46. doi :10.1109/MCOM.2010.5621965. ISSN 1558-1896. S2CID 23639680.
- ^ Rybczynski, Tony (2009). 「パケット交換の商業化 (1975-1985): カナダの視点 [通信の歴史]」. IEEE Communications Magazine . 47 (12): 26–31. doi :10.1109/MCOM.2009.5350364. ISSN 1558-1896. S2CID 23243636.
- ^ ヨーロッパ研究ネットワークの「隠された」前史。Trafford Publishing。p. 354。ISBN 978-1-4669-3935-6。
- ^ 「TCP/IPインターネットプロトコル」。Living Internet。2022年9月1日時点のオリジナルよりアーカイブ。2022年10月8日閲覧。
- ^ Andrew L. Russell (2013 年 7 月 30 日)。「OSI: 存在しなかったインターネット」IEEE Spectrum第 50 巻、第 8 号。
- ^ Russell, Andrew L. 「Rough Consensus and Running Code' and the Internet-OSI Standards War」（PDF）。IEEE Annals of the History of Computing。2019年11月17日時点のオリジナルよりアーカイブ（PDF） 。 2020年2月23日閲覧。
- ^ 「Standards Wars」（PDF） 2006年。2021年2月24日時点のオリジナルよりアーカイブ（PDF） 。 2020年2月23日閲覧。
- ^ Ben-Ari 1982、第 2 章「並行プログラミングの抽象化」、18-19 ページにも同様のことが述べられています。
- ^ Ben-Ari 1982、セクション 2.7 - 要約、p. 27 では、並行プログラミングの抽象化について要約しています。
- ^ ab Marsden 1986、セクション 6.1 - なぜ標準が必要なのか?、p. 64-65 では、BSC を例として、標準プロトコルと標準フレームワークの両方の必要性を示しています。
- ^ Comer 2000、Sect. 11.2 - The Need For Multiple Protocols、p. 177 では、コンピュータ通信とプログラミング言語の類似点を描いてこれを説明しています。
- ^ ab セクション 11.10 - レイヤリングの欠点、p. 192 には、レイヤリングがプロトコル設計の基礎を形成すると記載されています。
- ^ ab Comer 2000、Sect. 11.2 - The Need For Multiple Protocols、p. 177 でも同様のことが述べられています。
- ^ Comer 2000、セクション 11.3 - プロトコル ソフトウェアの概念レイヤー、p. 178、「各レイヤーは、問題の一部を処理する責任を負います。」
- ^ Comer 2000、Sect. 11.11 - The Basic Idea Behind Multiplexing And Demultiplexing、p. 192 でも同様のことが述べられています。
- ^ 「データ通信 - 概要 | ScienceDirect Topics」www.sciencedirect.com。 2022年5月31日時点のオリジナルよりアーカイブ。2022年5月31日閲覧。
- ^ Kirch, Olaf (2002年1月16日). 「テキストベースのプロトコル」。2010年5月30日時点のオリジナルよりアーカイブ。2014年10月21日閲覧。
- ^ Kirch, Olaf (2002年1月16日). 「Binary Representation Protocols」. 2010年5月30日時点のオリジナルよりアーカイブ。2006年5月4日閲覧。
- ^ Kirch, Olaf (2002 年 1 月 16 日). 「Binary Representation Protocols」. 2006 年 3 月 5 日時点のオリジナルよりアーカイブ。2006年5 月 4 日閲覧。
- ^ 「UML Web サイトへようこそ！」Uml.org。 2019 年 9 月 30 日時点のオリジナルよりアーカイブ。 2017 年1 月 15 日閲覧。
- ^ Marsden 1986、第 3 章「プロトコルの基本概念と問題領域」、p. 26-42 では、次の内容の多くについて説明しています。
- ^ Comer 2000、セクション 7.7.4 - データグラム サイズ、ネットワーク MTU、およびフラグメンテーション、p. 104、フラグメンテーションとフラグメントのヘッダーへの影響について説明しています。
- ^ Comer 2000、第4章「クラスフルインターネットアドレス」、p. 64-67;71。
- ^ Marsden 1986、セクション 14.3 - 階層化の概念と一般的な定義、p. 187 で、アドレス マッピングについて説明しています。
- ^ Marsden 1986、セクション 3.2 - 検出および伝送エラー、p. 27 では、後方エラー訂正の利点について説明しています。
- ^ Marsden 1986、セクション 3.3 - 確認応答、p. 28-33 では、肯定応答のみの利点について説明し、データグラム プロトコルを例外として挙げています。
- ^ Marsden 1986、セクション 3.4 - 情報の損失 - タイムアウトと再試行、p. 33-34。
- ^ Marsden 1986、セクション 3.5 - 情報フローの方向、p. 34-35 では、マスター/スレーブと制御を獲得するための交渉について説明しています。
- ^ Marsden 1986、セクション 3.6 - シーケンス制御、p. 35-36 では、パケットが失われる仕組みと、シーケンスによってこれがどのように解決されるかについて説明しています。
- ^ Marsden 1986、セクション3.7 - フロー制御、p. 36-38。
- ^ Ben-Ari 1982、序文、p. xiii。
- ^ Ben-Ari 1982、序文、p. xiv。
- ^ Hoare 1985、第4章「コミュニケーション」、133ページ、コミュニケーションについて扱っています。
- ^ S. Srinivasan、デジタル回路とシステム、NPTELコース、2009年12月27日時点のオリジナルよりアーカイブ
- ^ ab Comer 2000、Sect. 11.2 - The Need For Multiple Protocols、p. 177 では、レイヤーの分解について紹介しています。
- ^ Comer 2000、Sect. 11.3 - The Conceptual Layers Of Protocol Software、p. 179、最初の 2 つの段落では、連続するレイヤーを介したメッセージの送信について説明しています。
- ^ Comer 2000、セクション 11.2 - 複数のプロトコルの必要性、p. 178 では、プロトコル ソフトウェアとコンパイラ、アセンブラ、リンカー、ローダーの類似点について説明しています。
- ^ Comer 2000、Sect. 11.9.1 - Operating System Boundary、p. 192 では、オペレーティング システムの境界について説明しています。
- ^ IETF 1989、セクション 1.3.1 - 組織、p. 15、2 番目の段落: 多くの設計上の選択には、厳密な階層化の創造的な「破壊」が含まれます。
- ^ Comer 2000、Sect. 11.10 - The Disadvantage Of Layering、p. 192 では、最適化の例を挙げながら、「厳密なレイヤリングは極めて非効率的になる可能性がある」理由を説明しています。
- ^ Wakeman, I (1992 年 1 月)。「レイヤリングは有害であると考えられる」IEEE ネットワーク: 20–24。
- ^ 黒瀬, James; ロス, Keith (2005).コンピュータネットワーキング: トップダウンアプローチ. ピアソン.
- ^ Lascano, Jorge Edison; Clyde, Stephen; Raza, Ali. 「Communication-protocol Design Patterns (CommDP) - COMMDP」。2017年3月18日時点のオリジナルよりアーカイブ。2017年3月17日閲覧。
- ^ Lascano, JE; Clyde, S. (2016).アプリケーションレベル通信プロトコルのパターン言語。ICSEA 2016、第11回国際ソフトウェアエンジニアリングの進歩会議。pp. 22–30。
- ^ Daigneau, R. (2011).サービス デザイン パターン: SOAP/WSDL および RESTful Web サービスの基本設計ソリューション(第 1 版). Upper Saddle River、NJ: Addison-Wesley Professional.
- ^ Fowler, M. (2002).エンタープライズ アプリケーション アーキテクチャのパターン(第 1 版). ボストン: Addison-Wesley Professional. ISBN 0-321-12742-0。
- ^ [1]F. Buschmann、K. Henney、DC Schmidt、「パターン指向ソフトウェアアーキテクチャ第4巻：分散コンピューティングのためのパターン言語、第4巻版」、イングランド、チチェスター、ニューヨーク：Wiley、2007年。
- ^ Bochmann, G. (1978). 「通信プロトコルの有限状態記述」.コンピュータネットワーク. 2 (4–5): 361–372. doi :10.1016/0376-5075(78)90015-6.
- ^ Comer 2000、「インターネットワーキング用語と略語集」、p. 704、用語「プロトコル」。
- ^ ブランド、ダニエル; ザフィロプーロ、ピトロ (1983)。「有限状態マシンの通信について」。ACM ジャーナル。30 ( 2 ): 323。doi : 10.1145/322374.322380。S2CID 11607967。
- ^ Marsden 1986、セクション 6.3 - 標準化の利点、p. 66-67 でも同様のことが述べられています。
- ^ ブライアント＆モロー 2009年、4ページ。
- ^ Marsden 1986、セクション 6.4 - 標準化に関するいくつかの問題、p. 67 では、HDLC を例にプロセスが説明されています。
- ^ 「X.225: 情報技術 - 開放型システム間相互接続 - コネクション指向セッションプロトコル: プロトコル仕様」。2021年2月1日時点のオリジナルよりアーカイブ。2023年3月10日閲覧。
- ^ Marsden 1986、セクション 6.1 - なぜ標準が必要なのか?、p. 65 では、ARPANET から学んだ教訓について説明しています。
- ^ Marsden 1986、セクション 14.1 - はじめに、p. 181 で OSI について紹介しています。
- ^ Marsden 1986、セクション 14.3 - 階層化の概念と一般的な定義、p. 183-185 で用語について説明しています。
- ^ Marsden 1986、セクション 14.4 - アプリケーション層、p. 188 でこれが説明されています。
- ^ Marsden 1986、セクション 14.5 - プレゼンテーション層、p. 189 でこれが説明されています。
- ^ Marsden 1986、セクション 14.6 - セッション層、p. 190 でこれが説明されています。
- ^ Marsden 1986、セクション 14.7 - トランスポート層、p. 191 でこれが説明されています。
- ^ Marsden 1986、セクション 14.8 - ネットワーク層、p. 192 でこれが説明されています。
- ^ Marsden 1986、セクション 14.9 - データリンク層、p. 194 でこれが説明されています。
- ^ Marsden 1986、セクション 14.10 - 物理層、p. 195 でこれが説明されています。
- ^ ISO 7498:1984 – 情報処理システム - 開放型システム間相互接続 - 基本参照モデル。p. 5。
この開放型システム間相互接続の基本参照モデルは、データの転送には接続が必要であるという前提に基づいています。
- ^ ISO 7498:1984/ADD 1:1987 – 情報処理システム — 開放型システム間相互接続 — 基本参照モデル — 補遺 1。
- ^ Marsden 1986、セクション 14.11 - コネクションレス モードと RM/OSI、p. 195 でこれについて言及されています。
- ^ ISO 7498:1994 – 情報処理システム - 開放型システム間相互接続 - 基本参照モデル。
- ^ Comer 2000、セクション 1.9 - インターネット プロトコルと標準化、p. 12 では、IETF が既存のプロトコルを使用しなかった理由が説明されています。
- ^ Trammell & Kuehlewind 2019、p. 2より。
- ^ Trammell & Kuehlewind 2019、p. 3より。
- ^ Trammell & Kuehlewind 2019、4ページ。
- ^ ab Fairhurst & Perkins 2021、7.結論。
- ^ Trammell & Kuehlewind 2019、5ページ。
- ^ Trammell & Kuehlewind 2019、6ページ。
- ^ Trammell & Kuehlewind 2019、p.7-8。
- ^ Farrell & Tschofenig 2014、2ページ。
- ^ Farrell & Tschofenig 2014、3ページより。
- ^ Arkko et al. 2023、2.1。意図的な配布。
- ^ Arkko et al. 2023、2.2. 情報配信の制御。
- ^ Arkko et al. 2023、2.3. 情報の保護と認証。
- ^ Arkko et al. 2023、2.5. 情報の影響の制限。
- ^ Arkko et al. 2023、2.4。情報の最小化。
- ^ Arkko et al. 2023、2.6. エンティティの最小セット。
- ^ Arkko et al. 2023, 3. 今後の研究。
- ^ Papastergiou et al. 2017、p. 619.
- ^ パパステルジオウら。 2017、p. 620。
- ^ パパステルジオウら。 2017、p. 620-621。
- ^ パパステルジオウら。 2017、p. 623-4。
- ^ McQuistin、Perkins、Fayed 2016、p.1。
- ^ トムソン＆パウリー 2021、A.5。TCP。
- ^ ハーディ2019、7-8頁。
- ^ Thomson & Pauly 2021、3.アクティブユース。
- ^ Thomson & Pauly 2021、3.5。積極的な使用の回復。
- ^ Comer 2000、Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model、p. 183 にも同じことが述べられています。
文献
- ラディア・パールマン(1999)。 『相互接続: ブリッジ、ルーター、スイッチ、およびインターネットワーキング プロトコル(第 2 版)』。Addison- Wesley。ISBN 0-201-63448-1。特に第18章の「ネットワーク設計の伝説」はオンラインでも閲覧可能です。
- ジェラルド・J・ホルツマン（1991年）。コンピュータプロトコルの設計と検証。プレンティス・ホール。ISBN 0-13-539925-4。
- Douglas E. Comer (2000)。TCP /IP によるインターネットワーキング - 原理、プロトコル、アーキテクチャ(第 4 版)。Prentice Hall。ISBN 0-13-018380-6。特に、第 11 章のプロトコル階層化。RFC ガイドとインターネットワーキング用語および略語の用語集もあります。
- R. Braden編 (1989)。インターネットホストの要件 - 通信層。インターネット技術タスクフォース (IETF) 略称。doi : 10.17487/ RFC1122。RFC 1122 。プロトコル ソフトウェアの実装者向けに TCP/IP について説明します。特に、導入部ではスイートの設計目標の概要を示します。
- M. Ben-ari (1982)。並行プログラミングの原則(第 10 版)。Prentice Hall International。ISBN 0-13-701078-8。
- CAR Hoare (1985)。「連続プロセスの伝達」（第 10 版）。Prentice Hall International。ISBN 0-13-153271-5。
- RD Tennent (1981)。プログラミング言語の原則(第 10 刷)。Prentice Hall International。ISBN 0-13-709873-1。
- ブライアン・W・マースデン（1986年）。通信ネットワークプロトコル（第2版）。チャートウェル・ブラット。ISBN 0-86238-106-1。
- アンドリュー・S・タネンバウム（1984年）。構造化コンピュータ組織（第10刷）。プレンティス・ホール・インターナショナル。ISBN 0-13-854605-3。
- Bryant, Stewart、Morrow, Monique 編 (2009 年 11 月)。協調性のないプロトコル開発は有害と考えられる。doi : 10.17487 / RFC5704。RFC 5704 。
- Farrell , Stephen; Tschofenig, Hannes (2014 年 5 月) 。広範囲にわたる監視は攻撃である。doi : 10.17487/RFC7258。RFC 7258 。
- Trammell , Brian; Kuehlewind, Mirja (2019 年 4 月)。ネットワーク プロトコルのワイヤ イメージ。doi : 10.17487/ RFC8546。RFC 8546 。
- Hardie, Ted 編 (2019 年 4 月)。トランスポート プロトコル パス信号。doi : 10.17487 / RFC8558。RFC 8558 。
- Fairhurst, Gorry; Perkins, Colin (2021 年 7 月)。トランスポート ヘッダーの機密性、ネットワーク操作、およびインターネット トランスポート プロトコルの進化に関する考慮事項。doi : 10.17487 / RFC9065。RFC 9065 。
- Thomson , Martin; Pauly, Tommy (2021 年 12 月)。プロトコル拡張メカニズムの長期的な実行可能性。doi : 10.17487/ RFC9170。RFC 9170 。
- Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja ( 2023 年 7 月)。アプリケーションに関する考慮事項 - パス信号を使用したネットワーク コラボレーション。doi : 10.17487/ RFC9419。RFC 9419 。
- McQuistin, Stephen; Perkins, Colin; Fayed, Marwan (2016 年 7 月)。骨化したネットワーク上でのリアルタイム トランスポート サービスの実装。2016 年応用ネットワーク研究ワークショップ。doi :10.1145 / 2959424.2959443。hdl : 1893/26111。
- Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). 「インターネット トランスポート層の骨化の解消: 調査と今後の展望」. IEEE Communications Surveys & Tutorials . 19 : 619–639. doi :10.1109/COMST.2016.2626780. hdl : 2164/8317 . S2CID 1846371.
- モスコヴィティス、クリストス JP (1999)。インターネットの歴史: 1843 年から現在までの年表。ABC- CLIO。ISBN 978-1-57607-118-2。
外部リンク
- Javvin のプロトコル辞書
- OSI参照モデルによる遠隔制御分野のプロトコルの概要