Loading article…
通信プロトコルとは、通信システムの2つ以上のエンティティが情報を伝送できるようにする規則体系です。プロトコルは、通信の規則、構文、意味、同期、および可能なエラー回復方法を定義します。プロトコルは、ハードウェア、ソフトウェア、またはその両方の組み合わせによって実装できます。 [ 1 ]
通信システムは、さまざまなメッセージを交換するために明確に定義されたフォーマットを使用します。各メッセージには、特定の状況に対してあらかじめ決められた応答の範囲から応答を引き出すことを目的とした正確な意味があります。指定された動作は通常、その実装方法とは無関係です。通信プロトコルは、関係者間で合意する必要があります。[ 2 ]合意に達するために、プロトコルは技術標準として開発される場合があります。プログラミング言語は計算について同じことを記述するため、プロトコルとプログラミング言語の間には密接な類似性があります。プロトコルは通信にとって、プログラミング言語が計算にとってのそれと同じです。[ 3 ]別の表現では、プロトコルは通信にとって、アルゴリズムが計算にとってのそれと同じであると述べています。[ 4 ]
複数のプロトコルは、単一の通信の異なる側面を記述することがよくあります。連携して動作するように設計されたプロトコルのグループはプロトコルスイートと呼ばれ、ソフトウェアで実装された場合はプロトコルスタックと呼ばれます。
最もよく知られている通信プロトコルのいくつかは、インターネット、ウェブ、電子メールに関連するもので、これらはインターネット技術タスクフォース（IETF）とワールドワイドウェブコンソーシアムによって開発および公開されています。イーサネット、Bluetooth、そしてもちろん携帯電話規格など、多くの有線および無線プロトコルもよく知られています。これらは主にIEEE（電気電子学会、例：イーサネット）によって管理されています。また、公衆交換電話網（PSTN）の電気通信プロトコルとフォーマットを扱うITU-Tもあります。PSTNとインターネットが融合するにつれて、多くのプロトコルが融合に向かっています。国際標準化機構（ISO）は、その他多くの種類のプロトコルを管理しています。
現代のデータ通信の文脈でプロトコルという用語が初めて使用されたのは、 1967 年 4 月に作成された「NPL データ通信ネットワークで使用するためのプロトコル」というタイトルの覚書です。英国国立物理研究所でパケット交換を先駆的に行ったドナルド・デイビスの指示の下、ロジャー・スカントルベリーとキース・バートレットがNPL ネットワーク用に作成しました。彼らは翌年にその成果を発表しました。[ 5 ] [ 6 ] [ 7 ] [ 8 ]
ARPANETでは、1969 年にホスト間通信の出発点となったのは、IMP へのメッセージ送信を定義したBob Kahnによって書かれた1822 プロトコルでした。 [ 9 ] Steve CrockerやJon Postelを含む他の大学院生によって開発された ARPANET 用のネットワーク制御プログラム (NCP) は、1970年に初めて実装されました。[ 10 ] NCP インターフェースにより、アプリケーション ソフトウェアは上位レベルの通信プロトコルを実装することで ARPANET を介して接続できるようになり、プロトコル階層化の概念の初期の例となりました。[ 11 ]
1970年代初頭にルイ・プーザンによって設計されたCYCLADESネットワークは、エンドツーエンドの原則を初めて実装し、パケット交換ネットワーク上でデータの信頼性の高い配信をネットワーク自体のサービスではなくホストの責任とした。 [ 12 ]彼のチームは、ベストエフォートサービスを使用しながら、ユーザーアプリケーションに信頼性の高い仮想回線サービスを提供するという非常に複雑な問題に初めて取り組み、伝送制御プロトコル（TCP）への初期の貢献となった。[ 13 ] [ 14 ] [ 15 ]
ボブ・メトカーフとゼロックスPARCの他の人々は、イーサネットとインターネットワーキングのためのPARCユニバーサルパケット（PUP）のアイデアを概説した。[ 16 ]
1970年代初頭のボブ・カーンとヴィント・サーフの研究により、伝送制御プログラム（TCP）が策定された。[ 17 ]その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 ]
通信プロトコルは、通信システム間で交換されるメッセージの表現方法を定義する。メッセージの符号化には、テキスト表現またはバイナリ表現が一般的に用いられる。
テキストベースのプロトコル、またはプレーンテキストプロトコルは、メッセージを人間が読める形式で表現します。多くの場合、 ASCIIやUTF-8などの機械可読エンコーディングでエンコードされたプレーンテキスト、またはIntel hex形式、XML、JSONなどの構造化されたテキストベースの形式で表現されます。
人間がすぐに読み取れるという点は、コンピュータ環境で使用する際に固有の利点（機械的な解析の容易さや帯域幅利用率の向上など）を持つバイナリメッセージ表現とは対照的である。
ネットワークアプリケーションには、データをカプセル化するためのさまざまな方法があります。インターネットプロトコルで非常に一般的な方法の1つは、テキスト指向のメッセージ表現で、要求と応答をASCIIテキストの行として送信し、改行文字（通常はキャリッジリターン文字）で終了します。コマンドに平易な人間が読めるテキストを使用するプロトコルの例としては、FTP（ファイル転送プロトコル）、SMTP（シンプルメール転送プロトコル）、HTTP（ハイパーテキスト転送プロトコル）の初期バージョン、およびfingerプロトコルなどがあります。[ 34 ]
テキストベースのメッセージ表現は、一般的に人間が検査・解釈しやすいため、デバッグ時やプロトコル開発の初期設計段階など、プロトコルの内容を人間が検査する必要がある場合に適しています。
バイナリプロトコルは、バイトのすべての値を利用できるメッセージ表現を使用します。これは、 ASCIIやUTF-8などの文字エンコーディングの文字に対応する値に限定されるテキスト ベースの表現とは対照的です。バイナリ メッセージ表現は、人間が直接読むのではなく、機械によって処理されることを目的としています。バイナリ プロトコルには簡潔さという利点があり、これは伝送と解釈の速度につながります。[ 35 ]
バイナリメッセージ表現は、 EbXML、HTTP/2、HTTP/3、EDOCなどの現代の標準で使用されています。[ 36 ] UMLのインターフェース[ 37 ]もバイナリプロトコルとみなすことができます。
データをネットワーク経由で送信することは、プロトコルにとって問題の一部にすぎません。受信したデータは、会話の進行状況という文脈の中で評価される必要があるため、プロトコルには文脈を記述するルールが含まれていなければなりません。このようなルールは、通信の構文を表すと言われます。また、データがやり取りが行われる文脈において意味を持つかどうかを判断するルールもあります。このようなルールは、通信の意味論を表すと言われます。
通信システム上でメッセージを送受信することで通信を確立します。したがって、プロトコルは送信を規定するルールを定める必要があります。一般的に、以下の点の多くに対処する必要があります。[ 38 ]
システムエンジニアリングの原則を適用して、共通のネットワークプロトコル設計原則のセットを作成しました。複雑なプロトコルの設計には、より単純な協調プロトコルへの分解が含まれることがよくあります。このような協調プロトコルのセットは、概念的なフレームワーク内でプロトコルファミリーまたはプロトコルスイートと呼ばれることがあります[ 31 ]。
通信システムは並行して動作します。並行プログラミングの重要な側面は、通信メッセージを適切な順序で受信および送信するためのソフトウェアの同期です。並行プログラミングは、従来、オペレーティングシステム理論のテキストで取り上げられてきました。[ 48 ]並行プログラムは隠れた複雑なバグが含まれていることで悪名高いため、形式検証は不可欠であると思われます。 [ 49 ]並行性と通信の研究に対する数学的アプローチは、通信逐次プロセス(CSP)と呼ばれます。[ 50 ]並行性は、ミーリーマシンやムーアマシンなどの有限状態マシンを使用してモデル化することもできます。ミーリーマシンとムーアマシンは、電気通信で使用されるハードウェアや一般的な電子機器の形で遭遇するデジタル電子システムの設計ツールとして使用されています。[ 51 ]
文献には、コンピュータ通信とプログラミングの間に数多くの類似点が示されています。例えば、プロトコルの転送メカニズムは中央処理装置（CPU）に相当します。このフレームワークでは、プログラマが互いに独立して連携するプロトコルを設計できるようにするルールが導入されています。
現代のプロトコル設計では、プロトコルは階層化されてプロトコルスタックを形成します。階層化とは、プロトコル設計タスクをより小さなステップに分割する設計原則であり、各ステップは特定の部分を実行し、プロトコルの他の部分とは少数の明確に定義された方法でのみ相互作用します。階層化により、プロトコルの各部分を組み合わせ爆発を起こすことなく設計およびテストすることができ、各設計を比較的シンプルに保つことができます。
インターネットで使用されている通信プロトコルは、多様で複雑な環境で機能するように設計されています。インターネットプロトコルは、シンプルさとモジュール性を考慮して設計されており、インターネットプロトコルスイートで定義されている機能レイヤーの大まかな階層に適合します。[ 52 ]最初の2つの連携プロトコルである伝送制御プロトコル（TCP）とインターネットプロトコル（IP）は、モノリシックな通信プロトコルである元の伝送制御プログラムをこの階層化された通信スイートに分解することによって生まれました。
OSIモデルは、インターネット以前のネットワークでの経験に基づいて国際的に開発されたもので、プロトコル間の相互作用に関するより厳格な規則と厳密な階層構造を備えた、一般的な通信のための参照モデルである。
一般的に、アプリケーションソフトウェアは堅牢なデータ転送層の上に構築されています。この転送層の基盤となるのは、インターネットでは通常コネクションレスなデータグラム配信およびルーティングメカニズムです。ネットワーク間でのパケット中継は、ネットワークリンク技術のみを含む別の層で行われます。このネットワークリンク技術は、イーサネットなどの特定の物理層技術に特有のものであることがよくあります。レイヤリングにより、必要に応じて技術を交換する機会が生まれます。たとえば、異なるネットワークの接続に対応するために、プロトコルはトンネル構成で積み重ねられることがよくあります。たとえば、IPは非同期転送モード（ATM）ネットワークを介してトンネル化される場合があります。
プロトコル階層化はプロトコル設計の基礎を形成します。[ 30 ]これにより、単一の複雑なプロトコルをより単純な協調プロトコルに分解することができます。[ 52 ]プロトコルの各層は、それぞれ異なる種類の通信問題を解決します。これらの層が組み合わさって、階層化スキームまたはモデルを構成します。
計算はアルゴリズムとデータを扱い、通信はプロトコルとメッセージを扱う。したがって、データフロー図のアナロジーは何らかのメッセージフロー図である。[ 4 ]プロトコル階層とプロトコルスイートを視覚化するために、2 つのシステム A と B 内およびシステム間のメッセージフローの図を図 3 に示す。システム A と B はどちらも同じプロトコルスイートを使用する。垂直フロー (およびプロトコル) はシステム内であり、水平メッセージフロー (およびプロトコル) はシステム間である。メッセージフローは、プロトコルによって指定されたルールとデータ形式によって制御される。青い線は (水平) プロトコル層の境界を示す。
プロトコルをサポートするソフトウェアは階層構造になっており、プロトコル階層との関係を図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）は、ウェブ技術のプロトコルと標準を作成しています。
国際標準化団体は、国や商業上の利害を考慮する国内団体よりも公平であるべきだとされている。標準化団体は将来の標準の研究開発も行っている。実際には、前述の標準化団体は互いに緊密に協力している。[ 68 ]
プロトコルの開発には複数の標準化団体が関与する可能性がある。それらが連携していない場合、結果としてプロトコルの複数の互換性のない定義、またはメッセージの複数の互換性のない解釈が生じる可能性がある。ある定義における重要な不変条件（例えば、安定したルーティングループを防ぐために生存時間が単調減少すること）が、別の定義では尊重されない可能性がある。[ 69 ]
ISOでは、標準化プロセスは小委員会作業部会の設置から始まります。作業部会は、議論やコメントを促すために、関係者（他の標準化団体を含む）に作業草案や討議文書を発行します。これにより、多くの質問、多くの議論、そして通常は意見の相違が生じます。これらのコメントが考慮され、作業部会によって草案が作成されます。フィードバック、修正、妥協を経て、提案は国際規格草案の地位に達し、最終的には国際規格となります。国際規格は、欠陥に対処し、主題に関する見解の変化を反映するために、定期的に再発行されます。[ 70 ]
インターネットの前身であるARPANETから得られた教訓は、プロトコルが動作するにはフレームワークが必要であるということである。したがって、構造化プロトコル（階層型プロトコルなど）とその標準化に適した汎用的で将来性のあるフレームワークを開発することが重要である。これにより、機能が重複するプロトコル標準を防ぎ、異なるレベル（レイヤー）におけるプロトコルの責任を明確に定義することができる。[ 72 ]これにより、さまざまなレイヤー仕様に準拠した標準プロトコルとサービスの設計フレームワークとして使用されるオープンシステム相互接続モデル（OSIモデル）が生まれた。[ 73 ]
OSI モデルでは、通信システムは、基本的な伝送メカニズムを提供する基盤となる物理媒体によって接続されていると想定されています。その上の層には番号が付けられています。各層は、直下の層のサービスを使用して、その上の層にサービスを提供します。最上位層は、アプリケーション プロセスにサービスを提供します。各層は、サービス アクセス ポイントと呼ばれるインターフェースを介して相互に通信します。各システムの対応する層は、ピア エンティティと呼ばれます。通信するために、特定の層の 2 つのピア エンティティは、その層に固有のプロトコルを使用します。このプロトコルは、下の層のサービスを使用して実装されます。[ 74 ]各層には、2 種類の標準があります。特定の層のピア エンティティがどのように通信するかを定義するプロトコル標準と、特定の層が上位の層とどのように通信するかを定義するサービス標準です。
OSIモデルにおける各層とその機能は、（最上位層から最下位層まで）以下のとおりです。
コネクションレス型ネットワークを前提とする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 ]暗号化されていないプロトコルメタデータはワイヤイメージを構成する情報源の一つであり、パケットタイミングなどのサイドチャネルも寄与します。[ 88 ]異なる視点を持つ異なる観察者は、異なるワイヤイメージを見る可能性があります。[ 89 ] ワイヤイメージは、エンドユーザーのプライバシーとプロトコルの拡張性に関係します。 [ 90 ]
If some portion of the wire image is not cryptographically authenticated, it is subject to modification by intermediate parties (i.e., middleboxes), which can influence protocol operation.[88] Even if authenticated, if a portion is not encrypted, it will form part of the wire image, and intermediate parties may intervene depending on its content (e.g., dropping packets with particular flags). Signals deliberately intended for intermediary consumption may be left authenticated but unencrypted.[91]
The wire image can be deliberately engineered, encrypting parts that intermediaries should not be able to observe and providing signals for what they should be able to.[92] If provided signals are decoupled from the protocol's operation, they may become untrustworthy.[93] Benign network management and research are affected by metadata encryption; protocol designers must balance observability for operability and research against ossification resistance and end-user privacy.[90] The IETF announced in 2014 that it had determined that large-scale surveillance of protocol operations is an attack due to the ability to infer information from the wire image about users and their behaviour,[94] and that the IETF would "work to mitigate pervasive monitoring" in its protocol designs;[95] this had not been done systematically previously.[95] The Internet Architecture Board recommended in 2023 that disclosure of information by a protocol to the network should be intentional,[96] performed with the agreement of both recipient and sender,[97] authenticated to the degree possible and necessary,[98] only acted upon to the degree of its trustworthiness,[99] and minimised and provided to a minimum number of entities.[100][101] Engineering the wire image and controlling what signals are provided to network elements was a "developing field" in 2023, according to the IAB.[102]
プロトコルの硬直化とは、ネットワークプロトコルの柔軟性、拡張性、進化可能性の喪失を指します。これは主に、プロトコルのワイヤイメージに敏感なミドルボックスが原因であり、ミドルボックスが正しく認識しない有効なメッセージを中断または妨害する可能性があります。[ 103 ]これはエンドツーエンド原則の違反です。[ 104 ]二次的な原因としては、プロトコルのエンドポイント実装の柔軟性の欠如が挙げられます。[ 105 ]
インターネットプロトコルの設計と展開において、硬直化は大きな問題です。硬直化は、新しいプロトコルや拡張機能がインターネットに展開されるのを妨げたり、新しいプロトコルの設計に制約を課したりする可能性があるためです。新しいプロトコルは、既に展開されているプロトコルにカプセル化されるか、別のプロトコルのワイヤ イメージを模倣する必要があるかもしれません。 [ 106 ]硬直化のため、伝送制御プロトコル(TCP) とユーザー データグラム プロトコル(UDP) は、インターネット上のトランスポート プロトコルとして実用的な唯一の選択肢となっています。 [ 107 ]また、TCP 自体もかなり硬直化しており、プロトコルの拡張や変更が困難になっています。[ 108 ]
硬直化を防ぐための推奨方法には、プロトコル メタデータの暗号化[ 109 ]、拡張ポイントが確実に使用され、ワイヤ イメージの多様性が可能な限り完全に示されること[ 110 ] などがある。既存の硬直化を是正するには、プロトコル参加者間の調整が必要である[ 111 ]。QUIC は、意図的に硬直化防止特性を備えて設計された最初のIETFトランスポート プロトコルである[ 87 ] 。
プロトコルの分類体系は、通常、使用領域と機能に焦点を当てています。使用領域の例としては、コネクション指向プロトコルとコネクションレスプロトコルが挙げられます。コネクション指向プロトコルはコネクション指向ネットワークで、コネクションレスプロトコルはコネクションレスネットワークで使用されます。機能の例としては、トンネリングプロトコルがあります。これは、パケットを上位プロトコルでカプセル化し、上位プロトコルを使用してトランスポートシステムを介してパケットを転送できるようにするものです。
階層化スキームは、機能と使用領域の両方を組み合わせたものです。主流の階層化スキームは、IETF と ISO によって開発されたものです。階層化スキームの基本的な前提は、両者を区別するに値するほど十分に異なっているにもかかわらず、一般的なプロトコルを 2 つのスキームのレイヤーに関連付けて比較するのが一般的です。[ 112 ] IETF の階層化スキームは、インターネット階層化またはTCP/IP 階層化と呼ばれます。ISO の階層化スキームは、OSI モデルまたはISO 階層化と呼ばれます。
ネットワーク機器の構成においては、専門用語として次のような区別がよく用いられます。プロトコルという用語は厳密にはトランスポート層を指し、サービスという用語はトランスポートにプロトコルを利用するプロトコルを指します。TCPとUDPの一般的な場合、サービスはポート番号によって区別されます。これらのポート番号への準拠は任意であるため、コンテンツ検査システムにおいては、サービスという用語は厳密にはポート番号を指し、アプリケーションという用語は検査シグネチャによって識別されるプロトコルを指すためによく用いられます。
カーンは次のように回想している。「...ポール・バランの貢献...ポールはほぼ完全に音声に関する考慮事項によって動機づけられていたと思います。彼が書いたものを見ると、彼は低コストの電子機器であるスイッチについて話していました。これらの場所に強力なコンピュータを置くという考えは、費用対効果が高いとはまだ思い浮かんでいませんでした。そのため、コンピュータスイッチの概念が欠けていました。プロトコルの概念全体が当時存在していませんでした。そして、コンピュータ間の通信という考えは、実際には二次的な関心事でした。」
Paul Baran ... はルーティング手順と敵対的な環境における分散通信システムの生存性に焦点を当てましたが、現在私たちが理解しているような形でのリソース共有の必要性には重点を置きませんでした。実際、ソフトウェアスイッチの概念は彼の研究には存在しませんでした。
サイクラデスはARPANETとは異なり、インターネットワーキングを容易にするために明確に設計されていました。例えば、さまざまなフォーマットやさまざまなサービスレベルに対応できました。
NPLネットワークとARPANETに加え、学術研究実験ネットワークであるCYCLADESも、コンピュータネットワーク技術の発展において重要な役割を果たした。
初頭、プーザン氏はフランス、イタリア、イギリスの拠点を結ぶ革新的なデータネットワークを構築した。そのシンプルさと効率性は、数十台だけでなく数百万台のマシンを接続できるネットワークへの道筋を示した。それはサーフ博士とカーン博士の想像力を掻き立て、彼らはその設計の一部を、現在インターネットを支えるプロトコルに取り入れた。
著者らは、国際ネットワーク プロトコルの初期段階の議論において有益なコメントをくれた同僚、特に R. Metcalfe、R. Scantlebury、D. Walden、H. Zimmerman、断片化とアカウンティングの問題について建設的なコメントをくれた D. Davies と L. Pouzin に感謝したい。そして、S・クロッカーは、結社の形成と崩壊について論評した。
このオープンシステム相互接続の基本参照モデルは、データの転送には接続が必要であるという前提に基づいています。