プロトコルフィールドがIPヘッダーの一部であるのはなぜですか？

これは、IPレイヤーがネットワークスタックの上位レイヤーを認識している理由の複製ではないことに注意してください。

パケットベースの通信でのプロトコル識別子（IPヘッダーのプロトコルフィールドなど）の必要性は明らかです。これは、このアルゴリズムか、ある種の計算集約型の推論アルゴリズムです。問題は、カプセル化されたプロトコルのヘッダーではなく、なぜIPヘッダーの一部として存在する必要があるのか​​ということです。

それは私には思われる理論的な透明性が実用的な考慮事項（AKA「HaskellはGoは満たしている」...）を満たすものを例この1：一方ではIPヘッダの区切りに概念「プロトコル」フィールドを配置する利害の分離ことなどを。目的のOSIモデル。一方、スタックの上位のプロトコルに一貫した方法でタイプを強制することははるかに困難であり、最終的にはいずれにしても同様の状況につながります（たとえば、スタックの上位のすべてのプロトコルが最初のヘッダーバイトを使用してそのタイプを指定した場合、IP が同じように最後のヘッダーバイトを使用しているかのように見えます。

だから私の質問は-「プロトコル」フィールドをIPのパケットヘッダー内に配置する理由は何ですか？

編集：この質問を書くとき、私は「推論」の前に「元の」という単語を追加するかどうか、つまりIPを考案したチームの推論を検討しましたが、質問が過去形（「何でしたか推論...」）。それでも実際にはその質問に答える返信はないため、これは必要なようです。注目すべきいくつかの洞察：

• @immibisは、他の形式では他のプロトコルのモデルを壊すことを示唆しています（たとえば、暗号化された通信プロトコルには平文の識別フィールドが必要です）
• @Eddieは本質的にその理由が慣習であることを述べています（プロトコルチェーンの設計の受け入れ、それがなぜ慣習なのかは謎のままです）
• @Rickyは、包括的な検討事項として実用性を強調します
• @Claudioは、プロトコルフィールドがカプセル化されたヘッダーの一部であることを示唆しています。IPヘッダーの解析中に行われる現在のモデルでは、追加のヘッダー識別ステップが必要になるでしょう。

言い換えれば、次のヘッダーのタイプを識別するすべてのヘッダーの代わりに、すべてのヘッダーが所定の場所（たとえば、最初のヘッダーバイト）で独自のタイプを識別するモデルの何が問題になっていますか？なぜそのようなモデルは現在のものよりも望ましくないのですか？

編集＃2：答えは与えられたいくつかの答え（主に上記のものと@Eddieの2番目の補遺）の組み合わせのようです：

1. 単純：の主破壊層不可知論をにこの特定の場合は全体としてスタック（またはモデル）は単純であることを意味します。

   • 「プロトコル識別」フェーズはなく、暗黙的でも明示的でもありません
   • レイヤーの独立性が向上しました（たとえば、暗号化された通信ハンドラーは、ヘルパープロトコルとレイヤーを共有する必要がありません）

   規制も大幅に簡素化され、クライアントプロトコルに要件を適用する必要がありません。

2. パフォーマンス：カプセル化されたパケットのプロトコルをパケット自体の前に示すことで、いくつかのタイプの高速ルーティングプロトコル（パケットフィルタリング、QOS、カットスルースイッチング）をネットワーク（インターネット）レイヤー自体に統合できます。これにより、ハッシュテーブルにアクセスできるのと同じくらい迅速に決定を下すことができます。これは、このプロトコルを実行するために設計されたハードウェアが限られていることを考えると、さらに重要です。

このモデルには欠点がありますが、一般的な使用例では、代替モデルよりも適しているようです。

ビットは一連の1と0としてNICに到着します。次の一連の1と0をどのように解釈するかを指示するために何かが存在しなければなりません。

イーサネット2はL2のデファクトスタンダードであり、最初の56ビットをプリアンブル、次の8ビットをプリアンブル、次の48ビットを宛先MAC、次の48ビットをソースとして解釈すると想定されています。 MAC など。

唯一のバリエーションは、時代遅れの802.3 L2ヘッダーであり、現在のEthernet2標準よりも古いものですが、同じ目的で機能するSNAPヘッダーも含まれていました。しかし、私は余談です。

標準のEthernet2 L2ヘッダーにはTypeフィールドがあり、次の1と0を解釈する方法を受信ノードに伝えます。

これがなければ、L3ヘッダーがIPであるかIPv6であるかを受信エンティティはどのようにして知るのでしょうか？（またはAppleTalk、またはIPX、またはIPv8など...）

（上記と同じフレームへの）L3ヘッダーにはプロトコルフィールドがあり、IPヘッダーに続く次の1と0のセットを解釈する方法を受信ノードに伝えます。

繰り返しになりますが、これがなければ、受信エンティティはこれらのビットをICMPパケットとして解釈することをどのようにして知るのでしょうか。それは可能性もTCP、またはUDP、またはGRE、または別のIPヘッダ、または他人の茄多とします。

これにより、次のビットセットの解釈方法を受信エンティティに示す一種のプロトコルチェーンが作成されます。これがなければ、受信側はヒューリスティック（または他の同様の戦略）を使用して、最初にヘッダーのタイプを識別し、次にビットを解釈して処理する必要があります。これにより、各レイヤーで大きなオーバーヘッドが発生し、パケット処理に顕著な遅延が発生します。

この時点で、TCPヘッダーまたはUDPヘッダーを調べて、それらのヘッダーにタイプまたはプロトコルフィールドがないことを指摘したくなりますが、TCP / UDPがビットを解釈すると、ペイロードをアプリケーション。おそらく、少なくともL5 +プロトコルのバージョンを識別するための何らかのマーカーがあるでしょう。たとえば、HTTPにはHTTPリクエストに組み込まれたバージョン番号があります（1.0対1.1）。

編集して元のポスターの編集内容を話します。

すべてのヘッダーが次のヘッダーのタイプを識別する代わりに、すべてのヘッダーが所定の場所（たとえば、最初のヘッダーバイト）で独自のタイプを識別するモデルの何が問題になっていますか？なぜそのようなモデルは現在のモデルよりも望ましくないのですか？

回答を試みる前に、なぜどちらの方法が優れているか、または他の方法が優れているかについては、決定的な100万ドルの回答はおそらくないことに注意してください。どちらの場合も、それ自体を識別するプロトコルと、それがカプセル化するものを識別するプロトコルの場合、受信エンティティはビットを正しく解釈できます。

とはいえ、次のヘッダーを識別するプロトコルがより意味を持つ理由はいくつかあると思います。

＃1

標準がすべてのヘッダーの最初のバイトがそれ自体を識別するためのものである場合、これはすべてのレイヤーのすべてのプロトコルにわたって標準を設定することになります。つまり、1バイトだけが専用の場合、256のプロトコルしか使用できません。2バイトを割り当てたとしても、上限は65536です。どちらにしても、開発可能なプロトコルの数に任意の上限が設定されます。

一方、1つのプロトコルが次のプロトコルの解釈のみを担当していて、各プロトコル識別フィールドに1バイトしか割り当てられていない場合でも、最低でも、各レイヤーに最大256まで「スケーリング」します。

＃2

次のプロトコルフィールドが前のヘッダーに存在する場合にのみ、受信エンティティに最低限の検査のみを行って決定を行うことができるようにフィールドを順序付けるプロトコルが存在します。

イーサネット2と「カットスルー」スイッチングが思い浮かびます。これは、最初の（数バイト）がプロトコル識別ブロックになるように強制されている場合は不可能です。

＃3

最後に、クレジットを取得したくありませんが、元の質問のコメントのコメントにある@reirabの回答は非常に実行可能だと思います。

それは、名前を除いて、実質的にはIPv4（または下位レベルのプロトコル）ヘッダーの最後のバイトに過ぎないからです。これは「鶏肉または卵」の問題です。ヘッダーがどのプロトコルかわからない場合は、ヘッダーを解析できません。

_{Reirabの許可を得て引用}

イーサネットヘッダーにEther Typeフィールドがある理由を尋ねるのもよいでしょう。ネットワークスタックは、次の上位層のどのプロトコルが現在の層のペイロードを取得するかを知る必要があります。

編集1：

各データグラムに次の上位層のプロトコルがあるのは、層の独立性を作成するためです。各レイヤーはペイロードの内容を気にしません。また、ペイロードを調べてペイロードの配信先を決定する必要はありません。ヘッダーのプロトコル番号は、ペイロードが配信されるアドレスと考えてください。TCPポート番号がTCPアドレスであるように、それらはTCPにペイロードを配信する場所を通知します。

宛先MACアドレスは、フレームを配信するスイッチインターフェイスをネットワークスイッチに通知します。Ether Typeフィールドはペイロードを配信する場所をレイヤー2に通知し、IPヘッダーのプロトコルフィールドはペイロードを配信する場所をレイヤー3に通知し、TCPおよびUDPのポート番号はペイロードを配信する場所をレイヤー4に通知します。

トレーラーに接続してどこかに配達する18輪トラックの運転手について考えてみてください。トレーラーの内容や、それが何のために使われるかを心配する必要はありません。彼はちょうど彼の書類を見て、それを書類のその場所に届けます。

どのプロトコルが使用されるかを知らずに、各プロトコルが独立して開発されたことを覚えておく必要があります。長い間、イーサネットで使用されているプラ​​イマリレイヤー3プロトコルはIPXでした。イーサネットはIPX用に特別に作成されたものでしたが、今日は至る所に普及していますか？イーサネットは、ネットワークスタックがイーサネットペイロードの宛先を決定するために使用できるイーサタイプフィールドを持つことにより、任意のレイヤ3プロトコルを伝送するために構築されました。IPは同じことを行い、TCPとUDPも同じです。これは簡単で論理的な方法です。そのため、ネットワークスタックで独自に開発した各レイヤーには同等の機能があります。このため、ネットワークスタックに簡単にプラグインできる、任意のレイヤー用の独自のプロトコルを自由に開発できます。

編集2：

異なるレイヤー3プロトコルをレイヤー2に登録できます。IPX（0x8137）、IPv4、（0x0800）、ARP（0x0806）、IPv6（0x86DD）などのプロトコルを同時に実行できます。レイヤー2は、どのプロトコルが登録されているかを認識し、適切なレイヤーにペイロードを渡します。ペイロードについて何も知らない3つのプロトコル（または、プロトコルが登録されていないパケットをドロップします）。使用しているレイヤー3プロトコルの組み合わせごとに異なるレイヤー2プロトコルをインストールする必要はありません。レイヤー2プロトコルがレイヤー3プロトコルの詳細を知る必要がある場合に必要です。 ）パケットヘッダーを読み取ることができるようにするため。IPv4とIPv6のパケットヘッダーでさえかなり異なります。

以下は、レイヤー2に登録される可能性のあるさまざまなレイヤー3プロトコルの値の不完全なリストです。

レイヤー4プロトコルはさまざまなレイヤー3プロトコルにも登録され、アプリケーションはレイヤー4プロトコルに登録されます。

元の質問では、レイヤーは互いに独立している必要があると仮定されていました。この種のことは、実際にレイヤーの独立性を促進するのではなく、提案したようにそれを壊すのではありません。レイヤー2は、ペイロードがIPv4であることを認識していません。イーサタイプが0x0800であることのみを認識しており、そのイーサタイプを登録したレイヤー3プロトコルにペイロードを渡す必要があります。

あなたの質問への直接の答えではありませんが：

一方では、IPヘッダーに「プロトコル」フィールドを配置すると、OSIが目的とした関心の概念的な分離が崩れます。

TCP / IPは、OSIモデルを参照せずに開発されました。それらはいくつかの共通点を共有していますが、それは別個の開発作業でした。

最も単純な理由は、パケットが受信されたときに解析を支援することです。

どのプロトコルに従うかがわかっている場合は、より厳密な制約を作成できます。IPパケットの唯一の動的な側面はサイズです（IPオプションの存在により、このサイズは4バイトの倍数で増加します）。

解析フェーズでは、IPヘッダーの長さ、プロトコルを確認できます。次に、低レベルのパケット検証では、データ構造体（通常はicmp、tcp、udpヘッダー）を介してパケットデータが読み取られ、簡単なパケットが検証されます。

タイトルを読んでください：

IPパケットにTCPデータが含まれている場合、プロトコル番号フィールドの値は6になるため、ペイロードはTCPスタックに送信され、TCPはポート番号を使用してデータを正しいアプリケーションに送信します。プロトコル番号17のUDPについても同様です。

IPプロトコル番号フィールドを確認するもう1つの方法は、IPパケットヘッダーにこのフィールドがない場合、IPは1種類のデータしか運ぶことができず、このフィールドを追加すると、IPが複数のタイプのデータを運ぶことができるようになります。プロトコル番号で区別されるデータは、TCP / UDPポートを使用するTCP / UDPの場合も同じで、Ethertypeを使用する複数のアプリケーションやイーサネットに対応します。