通信プロトコル

通信プロトコルとは、通信システムにおける2つ以上のエンティティが情報を伝送できるようにする規則の体系です。プロトコルは、通信の規則、構文、意味、同期、および可能なエラー回復方法を定義します。プロトコルは、ハードウェア、ソフトウェア、またはその両方の組み合わせによって実装される場合があります。 [ 1 ]

通信システムは、様々なメッセージを交換するために明確に定義されたフォーマットを使用します。各メッセージは、特定の状況に対して事前に決定された一連の可能な応答から応答を引き出すことを意図した正確な意味を持ちます。指定された動作は、通常、それがどのように実装されるかとは無関係です。通信プロトコルは、関係者間で合意される必要があります。[ 2 ]合意に達するために、プロトコルは技術標準として開発される場合があります。プログラミング言語は計算について同様のことを記述するため、プロトコルとプログラミング言語の間には密接な類似性があります。つまり、プロトコルと通信の関係は、プログラミング言語と計算の関係と同じです。[ 3 ]別の表現では、プロトコルと通信の関係は、アルゴリズムと計算の関係と同じです。[ 4 ]

複数のプロトコルは、多くの場合、単一の通信の異なる側面を記述します。連携して動作するように設計されたプロトコルのグループは、プロトコルスイートと呼ばれます。ソフトウェアで実装された場合は、プロトコルスタックと呼ばれます。

インターネット通信プロトコルは、インターネット技術タスクフォース（IETF）によって公開されています。IEEE （電気電子技術者協会）は有線および無線ネットワークを、国際標準化機構（ISO）はその他の種類のネットワークを扱っています。ITU - Tは公衆交換電話網（PSTN）の通信プロトコルとフォーマットを扱っています。PSTNとインターネットの融合に伴い、標準規格も融合へと進んでいます。

通信システム

歴史

現代のデータ通信の文脈における「プロトコル」という用語の最初の使用は、 1967年4月の「NPLデータ通信ネットワークで使用するためのプロトコル」と題された覚書においてである。英国国立物理学研究所でパケット交換の先駆者であったドナルド・デイヴィスの指導の下、ロジャー・スキャントルベリーとキース・バートレットによってNPLネットワーク向けにこのプロトコルが作成された。彼らは翌年、その成果を公表した。[ 5 ] [ 6 ] [ 7 ] [ 8 ]

ARPANETでは、1969年のホスト間通信の出発点は、ボブ・カーンが書いた1822プロトコルであり、IMPへのメッセージの送信を定義しました。[ 9 ]スティーブ・クロッカーとジョン・ポステルを含む他の大学院生によって開発されたARPANETのネットワーク制御プログラム（NCP）は、1970年に初めて実装されました。[ 10 ] NCPインターフェースにより、アプリケーションソフトウェアは、より高レベルの通信プロトコルを実装することでARPANETを介して接続できるようになりました。これは、プロトコル階層化の概念の初期の例です。[ 11 ]

1970年代初頭にルイ・プーザンが設計したCYCLADESネットワークは、エンドツーエンドの原則を初めて実装し、パケット交換ネットワーク上でのデータの信頼性の高い配信をネットワーク自体のサービスではなくホストに責任を持たせた。 [ 12 ]彼のチームは、ベストエフォート型サービスを使用しながらユーザーアプリケーションに信頼性の高い仮想回線サービスを提供するという非常に複雑な問題に取り組んだ最初のチームであり、これは後の伝送制御プロトコル（TCP）への初期の貢献となった。[ 13 ] [ 14 ] [ 15 ]

ゼロックスPARCのボブ・メトカーフらは、インターネットワーキングのためのイーサネットとPARCユニバーサルパケット（PUP）のアイデアを概説した。[ 16 ]

1970年代初頭のボブ・カーンとヴィント・サーフによる研究は、伝送制御プログラム（TCP）の策定につながりました。[ 17 ] TCPのRFC  675仕様は、サーフ、ヨゲン・ダラル、カール・サンシャインによって1974年12月に作成されましたが、この時点ではまだモノリシックな設計でした。

国際ネットワークワーキンググループは、 1975年にCCITTに提出されたコネクションレス型データグラム標準に同意したが、CCITTにもARPANETにも採用されなかった。[ 18 ]別の国際的な研究、特にレミ・デプレの研究は、仮想回線に基づくX.25標準の開発に貢献し、これは1976年にCCITTに採用された。[ 19 ] [ 20 ]コンピュータメーカーは、 IBMのシステムネットワークアーキテクチャ（SNA）、デジタルイクイップメントコーポレーションのDECnet、ゼロックスネットワークシステムなどの独自のプロトコルを開発した。[ 21 ]

TCPソフトウェアは、 TCP/IPと呼ばれるモジュール型プロトコルスタックとして再設計されました。これは1982年にSATNETに、1983年1月にARPANETに導入されました。RFC 1122およびRFC 1123で概説されているように、1989年までに完全なインターネットプロトコルスイートが開発され、TCP/IPが新興インターネットの中核コンポーネントとして包括的なプロトコルスイートとして成長するための基盤が築かれました。[ 22 ]  

通信規格の参照モデルに関する国際的な取り組みの結果、1984年にOSIモデルが公開されました。1980年代後半から1990年代前半にかけて、技術者、組織、国家の間では、OSIモデルとインターネットプロトコルスイートのどちらの標準が最も優れた堅牢なコンピュータネットワークを実現するかという問題で意見が二極化しました。 [ 23 ] [ 24 ] [ 25 ]

コンセプト

ネットワークやその他のメディアを介してデバイス間で交換される情報は、通信プロトコル仕様で規定される規則と規約によって規定されます。通信の性質、実際に交換されるデータ、そして状態に依存する動作は、これらの仕様によって定義されます。デジタルコンピューティングシステムでは、これらの規則はアルゴリズムとデータ構造によって表現されます。プロトコルと通信の関係は、アルゴリズムやプログラミング言語と計算の関係に似ています。[ 3 ] [ 4 ]

オペレーティングシステムは通常、共有データを操作して相互に通信する協調プロセス群で構成されています。この通信は、プロセスコード自体に埋め込むことができる、広く理解されているプロトコルによって制御されます。[ 26 ] [ 27 ]一方、共有メモリがないため、通信システムは共有伝送媒体を使用して相互に通信する必要があります。伝送は必ずしも信頼できるものではなく、個々のシステムは異なるハードウェアやオペレーティングシステムを使用している可能性があります。

ネットワークプロトコルを実装するために、プロトコルソフトウェアモジュールは、マシンのオペレーティングシステム上に実装されたフレームワークとインターフェースされます。このフレームワークは、オペレーティングシステムのネットワーク機能を実装します。[ 28 ]プロトコルアルゴリズムが移植可能なプログラミング言語で表現されている場合、プロトコルソフトウェアはオペレーティングシステムに依存しません。最もよく知られているフレームワークは、TCP/IPモデルとOSI参照モデルです。

インターネットが開発された当時、抽象化階層化はコンパイラとオペレーティングシステムの設計の両方において成功した設計手法であることが証明されており、プログラミング言語と通信プロトコルの類似性を考慮して、もともとモノリシックであったネットワークプログラムは協調するプロトコルに分解されました。[ 29 ]これにより、今日のプロトコル設計の基礎を形成する階層化プロトコルの概念が生まれました。[ 30 ]

システムは通常、単一のプロトコルだけで伝送を処理するのではなく、複数のプロトコルを組み合わせて協調的に動作させる仕組み（プロトコルスイートと呼ばれることもあります）を使用します。[ 31 ]最もよく知られているプロトコルスイートには、TCP/IP、IPX/SPX、X.25、AX.25 、 AppleTalkなどがあります。

プロトコルは機能に基づいてグループ分けすることができ、例えばトランスポートプロトコルのグループがあります。機能は各層にマッピングされ、各層は、例えばアプリケーション機能、トランスポート機能、インターネット機能、ネットワークインターフェース機能などに関連する異なるクラスの問題を解決します。[ 32 ]メッセージを送信するには、各層からプロトコルを選択する必要があります。次のプロトコルの選択は、各層のプロトコルセレクタを用いてメッセージを拡張することによって行われます。[ 33 ]

種類

通信プロトコルには、伝送されるコンテンツの表現方法に基づいて、テキストベースとバイナリの2種類があります。[ 1 ]

テキストベース

テキストベースプロトコルまたはプレーンテキストプロトコルは、その内容を人間が読める形式で表現します。多くの場合、ASCIIやUTF-8などの機械可読エンコードでエンコードされたプレーンテキスト、またはIntel 16進形式、XML、JSONなどの構造化テキストベースの形式で表現されます

人間がすぐに読めるという点は、コンピューター環境での使用に固有の利点 (機械的な解析の容易さや帯域幅の利用率の向上など) があるネイティブ バイナリ プロトコルとは対照的です。

ネットワークアプリケーションには、データをカプセル化する様々な方法があります。インターネットプロトコルで非常に一般的な方法の一つは、テキスト指向の表現です。これは、要求と応答をASCIIテキストの行として送信し、改行文字（通常はキャリッジリターン文字）で終了します。コマンドに人間が読めるプレーンテキストを使用するプロトコルの例としては、FTP（ファイル転送プロトコル）、SMTP（シンプルメール転送プロトコル）、初期のHTTP（ハイパーテキスト転送プロトコル）、およびフィンガープロトコルなどがあります。[ 34 ]

テキストベースのプロトコルは通常、人間による解析と解釈に最適化されているため、デバッグ中やプロトコル開発の初期設計段階など、プロトコルの内容を人間が検査する必要がある場合に適しています。

バイナリ

バイナリプロトコルは、 ASCIIエンコードされた人間が読める文字に対応する値のみを使用するテキストベースのプロトコルとは対照的に、バイトのすべての値を利用します。バイナリプロトコルは、人間ではなく機械によって読み取られることを目的としています。バイナリプロトコルには簡潔さという利点があり、これは伝送と解釈の速度につながります。[ 35 ]

バイナリは、 EbXML、HTTP/2、HTTP/3、EDOCなどの現代の標準を記述する規範文書で使用されています。[ 36 ] UMLのインターフェース[ 37 ]もバイナリプロトコルと見なすことができます。

基本要件

ネットワークを介してデータを取得することは、プロトコルにとって問題の一部にすぎません。受信したデータは、会話の進行状況という文脈の中で評価される必要があるため、プロトコルには文脈を記述する規則が含まれている必要があります。これらの規則は、通信の構文を表現すると言われています。他の規則は、データが交換が行われる文脈において意味があるかどうかを判断します。これらの規則は、通信の 意味を表現すると言われています

通信システムでは、通信を確立するためにメッセージが送受信されます。したがって、プロトコルは伝送を管理する規則を規定する必要があります。一般的に、以下の項目の多くが規定されるべきです。[ 38 ]

データ交換のためのデータ形式
デジタルメッセージのビット列が交換されます。ビット列はフィールドに分割され、各フィールドはプロトコルに関連する情報を伝達します。概念的には、ビット列はヘッダーとペイロードと呼ばれる2つの部分に分割されます。実際のメッセージはペイロードで伝達されます。ヘッダー領域には、プロトコルの動作に関連するフィールドが含まれています。最大転送単位（MTU）よりも長いビット列は、適切なサイズに分割されます。[ 39 ]
データ交換のためのアドレス形式
アドレスは送信者と受信者の両方を識別するために使用されます。アドレスはビット列のヘッダー領域で運ばれ、受信者はビット列が処理対象であるか無視すべきかを判断できます。送信者と受信者間の接続は、アドレスペア（送信者アドレス、受信者アドレス）を使用して識別できます。通常、アドレス値には特別な意味があります。すべて1のアドレスは、ネットワーク上のすべてのステーションへのアドレス指定を意味するため、このアドレスに送信すると、ローカルネットワーク上でブロードキャストが行われます。アドレス値の意味を記述する規則は、総称してアドレス指定スキームと呼ばれます。[ 40 ]
アドレスマッピング
プロトコルによっては、ある方式のアドレスを別の方式のアドレスにマッピングする必要がある場合があります。例えば、アプリケーションによって指定された論理IPアドレスをイーサネットMACアドレスに変換する場合などです。これはアドレスマッピングと呼ばれます。[ 41 ]
ルーティング
システム同士が直接接続されていない場合、宛先の受信者までの経路上にある中間システムが送信者に代わってメッセージを転送する必要があります。インターネットでは、ネットワークはルーターを介して接続されます。ルーターを介したネットワークの相互接続は、インターネットワーキングと呼ばれます。
伝送エラーの検出
データ破損の可能性があるネットワークでは、エラー検出が不可欠です。一般的なアプローチでは、データ領域のCRCをパケットの末尾に追加することで、受信側が破損による差異を検出できるようにします。受信側はCRCの差異に基づいてパケットを拒否し、何らかの方法で再送を手配します。[ 42 ]
確認応答
コネクション指向通信では、パケットが正しく受信されたことの確認応答が必要です。確認応答は受信者からそれぞれの送信者に返送されます。[ 43 ]
情報の損失 - タイムアウトと再試行
パケットはネットワーク上で失われたり、転送中に遅延したりすることがあります。これに対処するため、一部のプロトコルでは、送信者は一定時間内に受信者から正しく受信されたことの確認応答を期待することがあります。そのため、タイムアウトが発生した場合、送信者は情報を再送信する必要がある場合があります。[ a ]リンクが恒久的に切断されている場合、再送信は効果がありません。そのため、再送信回数には制限があります。再試行回数の制限を超えるとエラーとみなされます。[ 44 ]
情報の流れの方向
半二重リンクのように一度に一方向のみの送信しかできない場合、あるいは共有メディアのように一度に一つの送信者からしか送信できない場合は、方向について考慮する必要があります。これはメディアアクセス制御と呼ばれます。2つの当事者が同時に送信する場合、あるいは送信を希望する場合に衝突や競合が発生する場合に備えて、対策を講じる必要があります。[ 45 ]
シーケンス制御
長いビット列を断片に分割し、ネットワーク上で個別に送信する場合、断片は失われたり遅延したり、あるいはネットワークの種類によっては宛先への経路が異なる場合があります。その結果、断片は順序どおりに到着しない可能性があります。再送信により断片が重複する可能性があります。送信側で断片にシーケンス情報をマークすることで、受信側は何が失われたか、または重複したかを判断し、必要な再送信を要求し、元のメッセージを再構成することができます。[ 46 ]
フロー制御
フロー制御は、送信者が受信側または中間ネットワーク機器が処理できる速度よりも速く送信する場合に必要です。フロー制御は、受信側から送信側へのメッセージングによって実装できます。[ 47 ]
キューイング
通信プロセスまたはステート マシンは、キュー (または「バッファ」) (通常は FIFO キュー) を使用して、送信順にメッセージを処理しますが、優先順位が異なる複数のキューを持つ場合もあります。

プロトコル設計

システム工学の原則は、共通のネットワークプロトコル設計原則のセットを作成するために適用されてきました。複雑なプロトコルの設計には、より単純で連携するプロトコルへの分解が含まれることがよくあります。このような連携するプロトコルのセットは、概念的な枠組みの中で、 プロトコルファミリまたはプロトコルスイート[ 31 ]と呼ばれることがあります

通信システムは並行して動作します。並行プログラミングの重要な側面は、適切な順序で通信メッセージを受信および送信するためのソフトウェアの同期です。並行プログラミングは伝統的にオペレーティングシステム理論の教科書で話題になっています。[ 48 ]並行プログラムは隠れた巧妙なバグを含むことで悪名高いため、形式検証は不可欠と思われます。[ 49 ]並行性と通信を研究するための数学的アプローチは、通信順次プロセス（CSP）と呼ばれます。[ 50 ]並行性は、ミーリーマシンやムーアマシンなどの有限状態マシンを使用してモデル化することもできます。ミーリーマシンとムーアマシンは、通信や一般的な電子機器に使用されるハードウェアの形で遭遇するデジタル電子システムの設計ツールとして使用されています。[ 51 ]

文献には、コンピュータ通信とプログラミングの間に多くの類似点が示されています。例えば、プロトコルの転送メカニズムは中央処理装置（CPU）に相当します。このフレームワークは、プログラマが互いに独立して連携するプロトコルを設計できるようにする規則を導入しています。

階層化

図2. インターネット階層化スキームに関連するプロトコル
TCP/IPモデルまたはインターネット階層化スキームと、いくつかの一般的なプロトコルとの関係

現代のプロトコル設計では、プロトコルは階層化され、プロトコルスタックを形成します。階層化とは、プロトコル設計タスクをより小さなステップに分割する設計原則です。各ステップは特定の部分を実行し、プロトコルの他の部分とは、明確に定義された少数の方法でのみ相互作用します。階層化により、プロトコルの各部分を設計およびテストする際に、ケースの組み合わせ爆発を回避でき、各設計を比較的シンプルな状態に保つことができます。

インターネットで使用されている通信プロトコルは、多様かつ複雑な環境で機能するように設計されています。インターネットプロトコルは、シンプルさとモジュール性を重視して設計されており、インターネットプロトコルスイートで定義された機能層の大まかな階層構造に適合しています。[ 52 ]最初の2つの連携プロトコルである伝送制御プロトコル（TCP）とインターネットプロトコル（IP）は、モノリシックな通信プロトコルであった元の伝送制御プログラムをこの階層化された通信スイートに分解することで生まれました。

OSIモデルは、インターネット以前のネットワークの経験に基づいて、プロトコル相互作用のより厳格なルールと厳密な階層化を備えた一般的な通信の参照モデルとして国際的に開発されました。

通常、アプリケーションソフトウェアは堅牢なデータトランスポート層上に構築されます。このトランスポート層の基盤となるのは、データグラムの配信およびルーティング機構であり、インターネットでは通常コネクションレス型です。ネットワーク間のパケット中継は、ネットワークリンク技術のみを扱う別の層で行われます。この技術は、多くの場合、イーサネットなどの特定の物理層技術に固有のものです。レイヤリングにより、必要に応じて技術を交換できるようになります。例えば、異なるネットワーク間の接続に対応するために、プロトコルはトンネリング方式でスタックされることがよくあります。例えば、IPは非同期転送モード（ATM）ネットワークを介してトンネリングされる場合があります。

プロトコルの階層化

図3. プロトコルスイートを使用したメッセージフロー
図3. プロトコルスイートを使用したメッセージフロー。黒いループは実際のメッセージングループを示し、赤いループは下位層によって可能になる層間の有効な通信を示します

プロトコル階層化はプロトコル設計の基礎を形成します。[ 30 ]これにより、単一の複雑なプロトコルをより単純で協調的なプロトコルに分解することができます。[ 52 ]各プロトコル層はそれぞれ異なる種類の通信問題を解決します。これらの層が組み合わさって、階層化スキームまたはモデルを構成します。

計算はアルゴリズムとデータを扱います。通信はプロトコルとメッセージを必要とします。したがって、データフロー図に相当するものは、ある種のメッセージフロー図です。[ 4 ]プロトコルの階層化とプロトコルスイートを視覚化するために、2 つのシステム A と B 内およびシステム間におけるメッセージフローの図を図 3 に示します。システム A と B はどちらも同じプロトコルスイートを使用します。垂直方向のフロー (およびプロトコル) はシステム内であり、水平方向のメッセージフロー (およびプロトコル) はシステム間です。メッセージフローはルールによって制御され、データ形式はプロトコルによって指定されます。青い線は (水平) プロトコル層の境界を示します。

ソフトウェアの階層化

図5：プロトコルとソフトウェアの階層化。プロトコルを実装するソフトウェアモジュールは立方体で表されます。モジュール間の情報の流れは矢印で表されます。赤い矢印（上部の2つの水平矢印）は仮想的なものです。青い線はレイヤーの境界を示しています

プロトコルをサポートするソフトウェアは階層構造になっており、プロトコル階層化との関係は図 5 に示されています。

システムAでメッセージを送信するには、最上位層のソフトウェアモジュールが直下のモジュールと連携し、カプセル化すべきメッセージを引き渡します。下位モジュールは、実装したプロトコルに従ってヘッダーデータを入力し、下位モジュールと連携します。下位モジュールは、通信チャネルを介してメッセージをシステムBの下位モジュールに送信します。受信側システムBでは逆の処理が行われ、最終的にメッセージは元の形式でシステムBの最上位モジュールに届けられます。[ 53 ]

プログラム翻訳はサブ問題に分割されます。その結果、翻訳ソフトウェアも階層化され、ソフトウェア層を独立して設計することが可能になります。同様のアプローチはTCP/IPの階層化にも見られます。[ 54 ]

アプリケーション層以下のモジュールは、一般的にオペレーティングシステムの一部とみなされます。これらのモジュール間のデータ受け渡しは、アプリケーションプログラムとトランスポート層間のデータ受け渡しよりもはるかに低コストです。アプリケーション層とトランスポート層の境界は、オペレーティングシステム境界と呼ばれます。[ 55 ]

厳密な階層化

階層化モデルに厳密に準拠すること、いわゆる厳密な階層化は、必ずしもネットワーク構築に最適なアプローチとは限りません。[ 56 ]厳密な階層化は、実装のパフォーマンスに悪影響を与える可能性があります。[ 57 ]

プロトコル階層化は今日ではコンピュータネットワークの分野で広く採用されているが、プロトコルスタックを抽象化すると上位層が下位層の機能を重複させてしまう可能性があるとして歴史的に多くの研究者から批判されてきた[ 58 ]。その代表的な例としては、リンクごととエンドツーエンドの両方でのエラー回復が挙げられる[ 59 ] 。

デザインパターン

通信プロトコルの設計と実装において一般的に繰り返し発生する問題は、ソフトウェアデザインパターンによって解決できます。[ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ]

形式仕様

通信構文を記述する一般的な形式手法は、抽象構文記法1（ISO標準）と拡張バッカス・ナウア記法（IETF標準） です

有限状態機械モデルは、プロトコルの可能な相互作用を形式的に記述するために使用されます。[ 65 ] [ 66 ]および通信有限状態機械[ 67 ]

プロトコル開発

通信を行うには、プロトコルを選択する必要があります。ルールはアルゴリズムとデータ構造によって表現できます。アルゴリズムを移植可能なプログラミング言語で表現することで、ハードウェアとオペレーティングシステムの独立性が向上します。仕様のソースコード独立性により、より広範な相互運用性が実現します

プロトコル標準は通常、標準化団体の承認または支援を得て作成され、標準化プロセスが開始されます。標準化団体のメンバーは、自主的に作業結果を遵守することに同意します。メンバーは、プロトコルに関連する大きな市場シェアを握っている場合が多く、多くの場合、標準は重要な公共の利益に資すると考えられるため、法律または政府によって施行されるため、承認を得ることはプロトコルにとって非常に重要となります。

プロトコル標準の必要性

プロトコル標準の必要性は、 IBMが発明したバイナリ同期通信（BSC）プロトコルの変遷を見れば明らかです。BSCは、2つの独立したノードを接続するために使用された初期のリンクレベルプロトコルです。当初はマルチノードネットワークでの使用を想定していませんでした。しかし、実際に使用してみると、プロトコルのいくつかの欠陥が明らかになりました。標準化が欠如していたため、メーカーや組織はプロトコルを自由に拡張し、自社ネットワーク上で互換性のないバージョンを作成しました。場合によっては、ユーザーが他社の機器を使用することを意図的に阻止することもありました。オリジナルのバイナリ同期プロトコルには50以上のバリエーションが存在します。標準化が行われていれば、少なくともこれらの事態の一部は防げたはずです。[ 28 ]

場合によっては、プロトコルが標準化プロセスを経ずに市場を独占することがあります。このようなプロトコルは、デファクトスタンダードと呼ばれます。 デファクトスタンダードは、新興市場、ニッチ市場、または独占（または寡占）された市場でよく見られます。特に競争相手を追い払うために使用される場合、市場を非常にネガティブに支配する可能性があります。歴史的な観点から見ると、標準化はデファクトスタンダードの悪影響を打ち消す手段と見なす必要があります。肯定的な例外も存在します。Linux のようなデファクトスタンダードオペレーティングシステムは、ソースコードが公開され、オープンな方法で維持されているため、競争を促し、市場にこのようなネガティブな影響を与えません。

標準化団体

通信プロトコルに関連する標準化団体には、国際標準化機構（ISO）、国際電気通信連合（ITU）、電気電子学会（IEEE）、インターネット技術タスクフォース（IETF）などがあります。IETFは、インターネットで使用されているプロトコルを管理しています。IEEEは、電子機器業界における商用および民生用デバイスの多くのソフトウェアおよびハードウェアプロトコルを管理しています。ITUは、公衆交換電話網（PSTN）や多くの無線通信システムを設計する電気通信技術者の統括組織です。海洋電子機器では、 NMEA規格が使用されています。ワールド・ワイド・ウェブ・コンソーシアム（W3C）は、Web技術のプロトコルと標準を策定しています

国際標準化団体は、国家や商業上の利害を考慮する必要がある地域組織よりも公平であると考えられています。標準化団体は、将来の標準規格の研究開発も行っています。実際には、前述の標準化団体は互いに緊密に協力しています。[ 68 ]

プロトコルの開発には複数の標準化団体が関与することがあります。これらの団体が連携していない場合、プロトコルの定義やメッセージの解釈が互いに矛盾する複数の定義が生じる可能性があります。ある定義における重要な不変条件（例えば、安定したルーティングループを防ぐためにTTL値が単調減少するなど）が、別の定義では尊重されない可能性があります。[ 69 ]

標準化プロセス

ISOでは、標準化プロセスは小委員会の作業部会の設置から始まります。作業部会は、議論とコメントを促すために、利害関係者（他の標準化団体を含む）に作業草案と議論文書を発行します。これにより、多くの質問、多くの議論、そして通常は何らかの意見の相違が生じます。これらのコメントが考慮され、作業部会によって提案案が作成されます。フィードバック、修正、妥協を経て、提案は国際規格案となり、最終的には国際規格となります。国際規格は、欠陥に対処し、主題に関する変化する見解を反映するために定期的に再発行されます。[ 70 ]

OSI標準化

インターネットの前身であるARPANETから得られた教訓は、プロトコルが動作するには枠組みが必要であるということである。したがって、構造化プロトコル（階層化プロトコルなど）に適した、汎用的で将来性のある枠組みを開発し、その標準化を行うことが重要となる。これにより、機能が重複するプロトコル標準が生まれるのを防ぎ、異なるレベル（層）におけるプロトコルの役割を明確に定義できるようになる。[ 72 ]そこから開放型システム間相互接続モデル（OSIモデル）が生まれ、これは様々な層の仕様に準拠した標準プロトコルおよびサービスの設計枠組みとして利用されている。[ 73 ]

OSIモデルでは、通信システムは、基本的な伝送メカニズムを提供する基礎となる物理媒体によって接続されているものと想定されています。その上の層には番号が付けられています。各層は、すぐ下の層のサービスを使用して、その上の層にサービスを提供します。最上位層は、アプリケーションプロセスにサービスを提供します。層は、サービスアクセスポイントと呼ばれるインタフェースによって相互に通信します。各システムの対応する層は、ピアエンティティと呼ばれます。通信するために、特定の層の2つのピアエンティティは、下の層のサービスを使用して実装されたその層に固有のプロトコルを使用します。[ 74 ]各層には、特定の層のピアエンティティが通信する方法を定義するプロトコル標準と、特定の層がその上の層と通信する方法を定義するサービス標準の2種類の標準があります。

OSI モデルでは、層とその機能は（最上位層から最下位層の順に）次のとおりです。

  • アプリケーション層は、アプリケーションプロセスに対して、通信相手の識別、通信に必要な権限の確立、相手の可用性と認証の決定、通信のプライバシーメカニズムに関する合意、エラー回復の責任とデータ整合性を確保するための手順に関する合意、連携するアプリケーションプロセス間の同期、構文上の制約（文字セットやデータ構造など）の識別、コストと許容可能なサービス品質の決定、必要なログオンおよびログオフ手順を含む対話規律の選択などのサービスを提供する。[ 75 ]
  • プレゼンテーション層は、アプリケーション層に対して、セッション確立の要求、データ転送、アプリケーション層間で使用される構文のネゴシエーション、必要な構文変換、フォーマット、および特殊目的の変換（例：データ圧縮およびデータ暗号化）などのサービスを提供する場合がある。[ 76 ]
  • セッション層は、プレゼンテーション層に以下のサービスを提供する：セッション接続の確立と解放、通常および迅速なデータ交換、送信プレゼンテーションエンティティが受信セッションエンティティに許可なくプレゼンテーションエンティティにデータを解放しないように指示できる検疫サービス、プレゼンテーションエンティティが特定の制御機能を実行する順番を制御できるようにする相互作用管理、セッション接続の再同期、プレゼンテーションエンティティへの回復不可能な例外の報告。[ 77 ]
  • トランスポート層は、選択されたサービス品質に応じて、費用対効果の高い方法で信頼性と透過性に優れたデータ転送を提供します。複数のトランスポート接続を1つのネットワーク接続に多重化したり、1つのトランスポート接続を複数のネットワーク接続に分割したりすることができます。[ 78 ]
  • ネットワーク層は、トランスポートピアエンティティ間のネットワークパスの設定、維持、解放を行う。中継が必要な場合は、この層によってルーティングと中継機能が提供される。サービス品質は、接続確立時にネットワークエンティティとトランスポートエンティティ間でネゴシエートされる。この層は、ネットワーク輻輳制御も担う。[ 79 ]
  • データリンク層は、データリンク接続の確立、維持、解放を行う。物理層で発生したエラーは検出され、修正される場合もある。エラーはネットワーク層に報告される。データリンクユニットの交換（フロー制御を含む）は、この層で定義される。[ 80 ]
  • 物理層は、物理的な接続の電気的特性、使用される伝送技術、物理的な接続の設定、保守、クリアなどの詳細を記述します。[ 81 ]

TCP/IPの階層化スキームがコネクションレス型ネットワークを前提としているのに対し、RM/OSIはコネクション指向型ネットワークを前提としている。[ 82 ]コネクション指向型ネットワークは広域ネットワークに適しており、コネクションレス型ネットワークはローカルエリアネットワークに適している。コネクション指向型通信には何らかのセッションと（仮想）回線が必要であるため、（TCP/IPモデルには存在しない）セッション層が存在する。ISOの構成メンバーは主に広域ネットワークに関心を持っていたため、RM/OSIの開発はコネクション指向型ネットワークに集中し、コネクションレス型ネットワークはRM/OSIの補遺[ 83 ] [ 84 ]で初めて言及され、後にRM/OSIの更新版に組み込まれた。[ 85 ]

当時、IETFはこの問題と、インターネットには存在しないプロトコルが必要であるという事実に対処する必要がありました。その結果、IETFは「大まかな合意と実行コード」に基づく独自の標準化プロセスを開発しました。[ 86 ]この標準化プロセスはRFC 2026で規定されています。  

現在、IETFはインターネットで使用されるプロトコルの標準化団体となっています。RM/OSIはモデルを拡張し、コネクションレス型サービスも含めるようにしたため、TCPとIPはどちらも国際標準として開発されるようになりました。

ワイヤーイメージ

プロトコルのワイヤーイメージとは、プロトコルに参加していない観察者がプロトコルメッセージを観察することで収集できる情報であり、プロトコルによって明示的に意味が与えられた情報だけでなく、観察者によって行われた推論も含まれます。[ 87 ]暗号化されていないプロトコルメタデータはワイヤーイメージを構成する1つの情報源であり、パケットタイミングを含むサイドチャネルも寄与します。 [ 88 ]異なる立場にある異なる観察者は、異なるワイヤーイメージを見る可能性があります。[ 89 ] ワイヤーイメージは、エンドユーザーのプライバシーとプロトコルの拡張性に関連しています。 [ 90 ]

ワイヤイメージの一部が暗号的に認証されていない場合、中間者（ミドルボックスなど）による変更の対象となり、プロトコルの動作に影響を与える可能性があります。[ 88 ]認証されていても、一部が暗号化されていない場合はワイヤイメージの一部となり、中間者がその内容に応じて介入する可能性があります（例えば、特定のフラグを持つパケットをドロップするなど）。意図的に中間者による使用を意図した信号は、認証されていても暗号化されていないままになる場合があります。[ 91 ]

ワイヤイメージは意図的に設計することができ、仲介者が観察できないはずの部分を暗号化し、観察できるはずの部分に信号を提供する。[ 92 ]提供された信号がプロトコルの動作から切り離されている場合、信頼できなくなる可能性があります。[ 93 ]メタデータの暗号化は、ネットワークの管理と研究に悪影響を及ぼします。プロトコル設計者は、操作性と研究のための観察可能性と、骨化耐性およびエンドユーザーのプライバシーとのバランスを取る必要があります。[ 90 ] IETFは2014年に、プロトコル動作の大規模な監視は、ワイヤイメージからユーザーとその行動に関する情報を推測できるため、攻撃であると判断したと発表し、[ 94 ] IETFはプロトコル設計において「広範な監視を軽減するために取り組む」と述べましたが、[ 95 ]これは以前は体系的に行われていませんでした。[ 95 ]インターネットアーキテクチャ委員会は2023年に、プロトコルによるネットワークへの情報開示は意図的であること、[ 96 ]受信者と送信者の双方の同意を得て行われること、[ 97 ]可能かつ必要な範囲で認証されること、[ 98 ]信頼性の程度に応じてのみ行動すること、[ 99 ]最小限に抑えられ、最小限の数のエンティティに提供されることを勧告した。[ 100 ] [ 101 ] IABによると、2023年にはワイヤイメージのエンジニアリングとネットワーク要素に提供される信号の制御は「発展途上の分野」であった。[ 102 ]

骨化

プロトコルの骨化とは、ネットワークプロトコルの柔軟性、拡張性、進化性が失われることです。これは主に、プロトコルのワイヤイメージに敏感なミドルボックスが原因で、ミドルボックスは有効なメッセージであっても正しく認識できず、メッセージを中断したり干渉したりする可能性があります。 [ 103 ]これはエンドツーエンド原則に違反しています。[ 104 ]二次的な原因としては、プロトコルのエンドポイント実装の柔軟性の欠如が挙げられます。[ 105 ]

骨化はインターネットプロトコルの設計と導入における大きな問題であり、新しいプロトコルや拡張機能がインターネット上に導入されなくなったり、新しいプロトコルの設計に制約が生じたりする可能性がある。新しいプロトコルは、既に導入されているプロトコルにカプセル化するか、別のプロトコルのワイヤイメージを模倣する必要があるかもしれない。 [ 106 ]骨化のため、伝送制御プロトコル（TCP）とユーザーデータグラムプロトコル（UDP）は、インターネット上のトランスポートプロトコルとして実用的な選択肢であり、 [ 107 ] TCP自体も大幅に骨化しており、プロトコルの拡張や変更が困難になっている。[ 108 ]

骨化を防ぐための推奨される方法には、プロトコルメタデータの暗号化[ 109 ]、拡張ポイントの実行とワイヤイメージの可変性が可能な限り完全に発揮されることの保証[ 110 ]などがある。既存の骨化を改善するには、プロトコル参加者間の調整が必要である。[ 111 ] QUICは、意図的に骨化防止特性を備えて設計された最初のIETFトランスポートプロトコルである。 [ 87 ]

分類

プロトコルの分類体系は通常、使用ドメインと機能に焦点を当てています。使用ドメインの例として、コネクション指向プロトコルとコネクションレスプロトコルは、それぞれコネクション指向ネットワークとコネクションレスネットワークで使用されます。機能の例としては、トンネリングプロトコルがあります。これは、パケットを高レベルプロトコルでカプセル化し、高レベルプロトコルを使用してトランスポートシステムを介してパケットを通過させるために使用されます

階層化スキームは、機能と使用領域の両方を兼ね備えています。主流となっている階層化スキームは、IETFとISOによって開発されたものです。階層化スキームの根底にある前提は両者を区別する必要があるほど大きく異なりますが、共通のプロトコルを両スキームの層に関連付けることで、両者を比較することが一般的です。[ 112 ] IETFの階層化スキームは、インターネット階層化またはTCP/IP階層化と呼ばれます。ISOの階層化スキームは、OSIモデルまたはISO階層化と呼ばれます。

ネットワーク機器の設定においては、専門用語による区別がしばしば用いられます。「プロトコル」という用語は厳密にはトランスポート層を指し、「サービス」という用語はトランスポート層プロトコルを利用するプロトコルを指します。TCPやUDPといった一般的なケースでは、サービスはポート番号で区別されます。これらのポート番号への準拠は任意であるため、コンテンツ検査システムでは、「サービス」という用語は厳密にはポート番号を指し、「アプリケーション」という用語は検査シグネチャによって識別されるプロトコルを指すために使用されることが多いです。

参照

注記

  1. ^確認応答を受信できない場合は、元の送信または確認応答のいずれかが失われたことを示します。送信者にはこれらのケースを区別する手段がないため、すべてのデータが受信されたことを確認するには、元の送信が失われたという保守的な仮定を立てる必要があります

参考文献

  1. ^ a b US 7529565、ヒルピッシュ、ロバート・E.、ダッヒシャー、ロブ、シール、マーク他、「無線通信プロトコル」、2009年5月5日発行、スターキー・ラボラトリーズ社およびオーティコンASに譲渡 
  2. ^ Protocol、ブリタニカ百科事典、2012年9月12日時点のオリジナルよりアーカイブ、 2012年9月24日閲覧。
  3. ^ a b Comer 2000, 11.2節 - 複数プロトコルの必要性、p. 177、「それら（プロトコル）は通信にとって、プログラミング言語が計算にとってであるようなものです。」
  4. ^ a b c Comer 2000, セクション 1.3 - インターネットサービス、p. 3、「プロトコルは通信にとって、アルゴリズムは計算にとってのようなものである」
  5. ^ノートン、ジョン（2015年9月24日）『未来の簡潔な歴史』オリオン社、ISBN 978-1-4746-0277-8。
  6. ^ Campbell-Kelly, Martin (1987年7月). 「国立物理学研究所におけるデータ通信 (1965-1975)」 . IEEE Annals of the History of Computing . 9 (3): 221– 247. Bibcode : 1987IAHC....9c.221C . doi : 10.1109/MAHC.1987.10023 .
  7. ^ Pelkey, James L. 「6.1 通信サブネット：BBN 1969」 . 『起業家資本主義とイノベーション：コンピュータ通信の歴史 1968–1988』 . Kahn の回想によれば：… Paul Baran の貢献… 私はまた、Paul の動機はほぼ完全に音声に関するものだったと考えています。彼の著作を見ると、彼は低コストの電子機器であるスイッチについて語っていました。強力なコンピュータをこれらの場所に設置するという費用対効果の高いアイデアは、彼には思い浮かばなかったのです。つまり、コンピュータスイッチというアイデアは存在しなかったのです。当時はプロトコルという概念自体が存在しませんでした。そして、コンピュータ間通信というアイデアは、実際には二次的な関心事でした。
  8. ^ Kleinrock, L. (1978). 「パケット通信の原理と教訓」. Proceedings of the IEEE . 66 (11): 1320– 1329. Bibcode : 1978IEEEP..66.1320K . doi : 10.1109/PROC.1978.11143 . ISSN 0018-9219 . Paul Baran … はルーティング手順と、過酷な環境下における分散通信システムの生存性に焦点を当てていましたが、現在私たちが理解しているような形でのリソース共有の必要性については焦点を当てていませんでした。実際、彼の研究にはソフトウェアスイッチの概念は存在しませんでした。 
  9. ^インターフェースメッセージプロセッサ：ホストとIMPの相互接続仕様（PDF）（レポート）。Bolt BeranekとNewman（BBN）。レポート番号1822。
  10. ^書籍、高解像度。UGC -NET/JRF/SET PTP & Guide Teaching and Research Aptitude: UGC-NET By HD。高解像度書籍。
  11. ^ 「NCP – ネットワーク制御プログラム」 . Living Internet . 2022年8月7日時点のオリジナルよりアーカイブ。 2022年10月8日閲覧。
  12. ^ベネット、リチャード（2009年9月）「変化のための設計：エンドツーエンドの議論、インターネットの革新、そしてネット中立性に関する議論」（PDF）情報技術イノベーション財団 7、11ページ。 2017年9月11日閲覧。
  13. ^アバテ、ジャネット（2000年）『インターネットの発明』MITプレス、pp.  124– 127. ISBN 978-0-262-51115-5 実際、CYCLADESはARPANETとは異なり、インターネットワーキングを容易にするために明確に設計されていました。例えば、さまざまなフォーマットやさまざまなレベルのサービスに対応できました
  14. ^キム・ビョングン（2005年）『インターネットの国際化：影響力と技術の共進化』エドワード・エルガー、pp.  51– 55. ISBN 1845426754 NPLネットワークとARPANETに加えて、学術研究実験ネットワークであるCYCLADESも、コンピュータネットワーク技術の発展において重要な役割を果たしました
  15. ^ 「インターネットの第5の男」。エコノミスト誌。2013年11月30日。ISSN 0013-0613 。2020年4月22日閲覧。1970年代初頭、プザン氏はフランス、イタリア、イギリスを結ぶ革新的なデータネットワークを構築しました。そのシンプルさと効率性は、数十台ではなく数百万台のマシンを接続できるネットワークへの道を示しました。このネットワークはサーフ博士とカーン博士の想像力を掻き立て、彼らはその設計の一部を、現在のインターネットを支えるプロトコルに取り入れました。 
  16. ^モスコヴィティス 1999 、 p.78-9 
  17. ^ Cerf, V.; Kahn, R. (1974年5月). "A Protocol for Packet Network Intercommunication" (PDF) . IEEE Transactions on Communications . 22 (5): 637– 648. Bibcode : 1974ITCom..22..637C . 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。 
  18. ^ McKenzie, Alexander (2011年1月). 「INWGとインターネットの構想：目撃証言」. IEEE Annals of the History of Computing . 33 (1): 66– 71. Bibcode : 2011IAHC...33a..66M . doi : 10.1109/MAHC.2011.9 . ISSN 1934-1547 . 
  19. ^ Schwartz, Mischa (2010年11月). 「X.25仮想回線 - TRANSPAC IN France - インターネット以前のデータネットワーキング [通信の歴史]」. IEEE Communications Magazine . 48 (11): 40– 46. doi : 10.1109/MCOM.2010.5621965 . ISSN 1558-1896 . 
  20. ^ Rybczynski, Tony (2009年12月). 「パケット交換の商業化（1975-1985）：カナダの視点 [通信の歴史]」. IEEE Communications Magazine . 47 (12): 26– 31. doi : 10.1109/MCOM.2009.5350364 . ISSN 1558-1896 . 
  21. ^ヨーロッパ研究ネットワークの「隠された」前史トラフォード出版 354ページISBN 978-1-4669-3935-6。
  22. ^ 「TCP/IPインターネットプロトコル」。Living Internet。2022年9月1日時点のオリジナルよりアーカイブ。2022年10月8日閲覧
  23. ^ Andrew L. Russell (2013年7月30日). 「OSI: インターネットは存在しなかった」 . IEEE Spectrum . 第50巻第8号.
  24. ^ 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日閲覧。
  25. ^ “Standards Wars” (PDF) . 2006年. 2021年2月24日時点のオリジナルよりアーカイブ(PDF) . 2020年2月23日閲覧。
  26. ^ Ben-Ari 1982、第 2 章「並行プログラミングの抽象化」、p. 18-19 でも同様のことが述べられています。
  27. ^ Ben-Ari 1982、セクション 2.7 - 要約、p. 27 では、並行プログラミングの抽象化について要約しています。
  28. ^ a b Marsden 1986、セクション 6.1「なぜ標準が必要なのか?」、p. 64-65 では、BSC を例に挙げて、標準プロトコルと標準フレームワークの両方の必要性を示しています。
  29. ^ Comer 2000、セクション 11.2 - 複数のプロトコルの必要性、p. 177 では、コンピューター通信とプログラミング言語の類似点を描いてこれを説明しています。
  30. ^ a bセクション 11.10 - 階層化の欠点、p. 192 には、階層化がプロトコル設計の基礎を形成すると記載されています。
  31. ^ a b Comer 2000、Sect. 11.2 - The Need For Multiple Protocols、p. 177でも同様のことが述べられています。
  32. ^ Comer 2000、セクション 11.3 - プロトコル ソフトウェアの概念レイヤー、p. 178、「各レイヤーは、問題の一部を処理する責任を負います。」
  33. ^ Comer 2000、Sect. 11.11 - The Basic Idea Behind Multiplexing And Demultiplexing、p. 192 でも同様のことが述べられています。
  34. ^ Kirch, Olaf (2002年1月16日). 「テキストベースプロトコル」 . 2010年5月30日時点のオリジナルよりアーカイブ。2014年10月21日閲覧。
  35. ^ Kirch, Olaf (2002年1月16日). 「Binary Representation Protocols」 . 2010年5月30日時点のオリジナルよりアーカイブ。2006年5月4日閲覧。
  36. ^ Kirch, Olaf (2002年1月16日). 「Binary Representation Protocols」 . 2006年3月5日時点のオリジナルよりアーカイブ。 2006年5月4日閲覧。
  37. ^ “Welcome To UML Web Site!” . Uml.org . 2019年9月30日時点のオリジナルよりアーカイブ。2017年1月15日閲覧。
  38. ^ Marsden 1986、第 3 章「プロトコルの基本概念と問題領域」、p. 26-42 では、次の内容の多くを説明しています。
  39. ^ Comer 2000、セクション 7.7.4 - データグラム サイズ、ネットワーク MTU、およびフラグメンテーション、p. 104、フラグメンテーションとフラグメントのヘッダーへの影響について説明しています。
  40. ^ Comer 2000、第4章 クラスフルインターネットアドレス、p.64-67;71。
  41. ^ Marsden 1986、セクション 14.3 - 階層化の概念と一般的な定義、p. 187 で、アドレス マッピングについて説明しています。
  42. ^ Marsden 1986、セクション3.2「検出および伝送エラー」、p.27では、後方誤り訂正の利点について説明しています。
  43. ^ Marsden 1986、セクション 3.3 - 確認応答、p. 28-33 では、肯定応答のみの利点について説明し、データグラム プロトコルを例外として挙げています。
  44. ^ Marsden 1986、セクション3.4「情報の損失 - タイムアウトと再試行」、p.33-34。
  45. ^ Marsden 1986、セクション 3.5 - 情報フローの方向、p. 34-35 では、マスター/スレーブと制御を獲得するためのネゴシエーションについて説明しています。
  46. ^ Marsden 1986、セクション 3.6 - シーケンス制御、p. 35〜36 では、パケットが失われる仕組みと、シーケンス制御によってこれがどのように解決されるかについて説明しています。
  47. ^ Marsden 1986、セクション3.7「フロー制御」、p.36〜38。
  48. ^ Ben-Ari 1982、序文、p. xiii。
  49. ^ Ben-Ari 1982、序文、p. xiv。
  50. ^ Hoare 1985、第4章「コミュニケーション」、p. 133では、コミュニケーションについて扱っています。
  51. ^ S. Srinivasan,デジタル回路とシステム、NPTELコース、2009年12月27日時点のオリジナルよりアーカイブ
  52. ^ a b Comer 2000、Sect. 11.2 - The Need For Multiple Protocols、p. 177 では、レイヤーの分解について紹介しています。
  53. ^ Comer 2000、Sect. 11.3 - The Conceptual Layers Of Protocol Software、p. 179、最初の 2 つの段落では、連続するレイヤーを介したメッセージの送信について説明しています。
  54. ^ Comer 2000、セクション 11.2 - 複数のプロトコルの必要性、p. 178 では、プロトコル ソフトウェアとコンパイラ、アセンブラ、リンカー、ローダーの類似点について説明しています。
  55. ^ Comer 2000、Sect. 11.9.1 - Operating System Boundary、p. 192 では、オペレーティング システムの境界について説明しています。
  56. ^ IETF 1989、セクション 1.3.1 - 組織、p. 15、2 番目の段落: 多くの設計上の選択には、厳密な階層化の創造的な「破壊」が含まれます。
  57. ^ Comer 2000、Sect. 11.10 - The Disadvantage Of Layering、p. 192 では、最適化の例を挙げながら、「厳密なレイヤリングは非常に非効率的になる可能性がある」理由を説明しています。
  58. ^ Wakeman, I (1992年1月). 「レイヤリングは有害と考えられる」. IEEE Network : 20–24 .
  59. ^黒瀬, ジェームズ; ロス, キース (2005). 『コンピュータネットワーキング：トップダウンアプローチ』 ピアソン.
  60. ^ Lascano, Jorge Edison; Clyde, Stephen; Raza, Ali. 「Communication-protocol Design Patterns (CommDP) - COMMDP」。2017年3月18日時点のオリジナルよりアーカイブ。2017年3月17日閲覧。
  61. ^ Lascano, JE; Clyde, S. (2016).アプリケーションレベル通信プロトコルのためのパターン言語. ICSEA 2016, 第11回国際ソフトウェア工学進歩会議. pp.  22– 30.
  62. ^ Daigneau, R. (2011).サービスデザインパターン: SOAP/WSDLおよびRESTful Webサービスのための基本的な設計ソリューション（第1版）. アッパーサドルリバー、ニュージャージー州: Addison-Wesley Professional.
  63. ^ Fowler, M. (2002). 『エンタープライズ・アプリケーション・アーキテクチャのパターン』（第1版）. ボストン: Addison-Wesley Professional. ISBN 0-321-12742-0。
  64. ^ [1]F. Buschmann、K. Henney、DC Schmidt著、『パターン指向ソフトウェアアーキテクチャ 第4巻：分散コンピューティングのためのパターン言語』第4巻版。イギリス・チチェスター、ニューヨーク：Wiley、2007年
  65. ^ Bochmann, G. (1978). 「通信プロトコルの有限状態記述」.コンピュータネットワーク. 2 ( 4–5 ): 361– 372. doi : 10.1016/0376-5075(78)90015-6 .
  66. ^ Comer 2000、「インターネットワーキング用語と略語集」、p. 704、「用語プロトコル」。
  67. ^ブランド、ダニエル; ザフィロプーロ、ピトロ (1983年4月). 「有限状態機械の通信について」 . ACMジャーナル. 30 (2): 323– 342. doi : 10.1145/322374.322380 .
  68. ^ Marsden 1986、セクション6.3「標準化の利点」、p. 66-67にも同様のことが述べられています。
  69. ^ブライアント＆モロー 2009、4ページ。
  70. ^ Marsden 1986、セクション 6.4 - 標準化に関するいくつかの問題、p. 67 では、HDLC を例にプロセスが説明されています。
  71. ^ 「X.225：情報技術 - 開放型システム間相互接続 - コネクション指向セッションプロトコル：プロトコル仕様」。2021年2月1日時点のオリジナルよりアーカイブ。2023年3月10日閲覧。
  72. ^ Marsden 1986、セクション 6.1「なぜ標準が必要なのか?」、p. 65 では、ARPANET から学んだ教訓について説明しています。
  73. ^ Marsden 1986、セクション 14.1 - はじめに、p. 181 で OSI について紹介しています。
  74. ^ Marsden 1986、セクション 14.3 - 階層化の概念と一般的な定義、p. 183-185 で用語について説明しています。
  75. ^ Marsden 1986、セクション 14.4 - アプリケーション層、p. 188 でこれが説明されています。
  76. ^ Marsden 1986、セクション 14.5 - プレゼンテーション層、p. 189 でこれが説明されています。
  77. ^ Marsden 1986、セクション 14.6 - セッション層、p. 190 でこれが説明されています。
  78. ^ Marsden 1986、セクション 14.7 - トランスポート層、p. 191 でこれが説明されています。
  79. ^ Marsden 1986、セクション 14.8 - ネットワーク層、p. 192 でこれが説明されています。
  80. ^ Marsden 1986、セクション 14.9 - データリンク層、p. 194 でこれが説明されています。
  81. ^ Marsden 1986、セクション 14.10 - 物理層、p. 195 でこれが説明されています。
  82. ^ ISO 7498:1984 – 情報処理システム - 開放型システム間相互接続 - 基本参照モデル。p. 5。この開放型システム間相互接続の基本参照モデルは、データの転送には接続が必要であるという前提に基づいています。
  83. ^ ISO 7498:1984/ADD 1:1987 – 情報処理システム — 開放型システム相互接続 — 基本参照モデル — 補遺1。
  84. ^ Marsden 1986、セクション 14.11 - コネクションレスモードと RM/OSI、p. 195 でこれについて言及されています。
  85. ^ ISO 7498:1994 – 情報処理システム - 開放型システム相互接続 - 基本参照モデル。
  86. ^ Comer 2000、セクション 1.9 - インターネット プロトコルと標準化、p. 12 では、IETF が既存のプロトコルを使用しなかった理由が説明されています。
  87. ^ a b Trammell & Kuehlewind 2019、p.2。
  88. ^ a b Trammell & Kuehlewind 2019、p.3。
  89. ^ Trammell & Kuehlewind 2019、4ページ。
  90. ^ a bフェアハースト＆パーキンス 2021、7 .結論。
  91. ^ Trammell & Kuehlewind 2019、5ページ。
  92. ^ Trammell & Kuehlewind 2019、6ページ。
  93. ^ Trammell & Kuehlewind 2019、p.7-8。
  94. ^ Farrell & Tschofenig 2014、2ページ。
  95. ^ a b Farrell & Tschofenig 2014、p.3。
  96. ^ Arkko et al. 2023、2.1 . 意図的な配布。
  97. ^ Arkko et al. 2023 , 2.2. 情報流通の制御。
  98. ^ Arkko et al. 2023、2.3 . 情報の保護と認証。
  99. ^ Arkko et al. 2023、2.5 . 情報の影響の制限。
  100. ^ Arkko et al. 2023 , 2.4. 情報の最小化。
  101. ^ Arkko et al. 2023 , 2.6. 実体の最小集合。
  102. ^ Arkko et al. 2023 , 3. 今後の研究。
  103. ^パパステルジオウら。 2017、p. 619.
  104. ^パパステルジオウら。 2017、p. 620。
  105. ^パパステルジオウら。 2017、p. 620-621。
  106. ^パパステルジオウら。 2017、p. 623-4。
  107. ^ McQuistin、Perkins、Fayed 2016、p.1。
  108. ^ Thomson & Pauly 2021、A.5. TCP。
  109. ^ハーディ 2019、7-8頁。
  110. ^ Thomson & Pauly 2021、3 . アクティブユース。
  111. ^ Thomson & Pauly 2021、3.5。積極的な使用の回復。
  112. ^ Comer 2000、Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model、p. 183 にも同様のことが述べられています。

参考文献

「 https://en.wikipedia.org/w/index.php?title=通信プロトコル&oldid =1333044172」より取得