プロトコルフィールドがIPヘッダーの一部であるのはなぜですか？
これは、IPレイヤーがネットワークスタックの上位レイヤーを認識している理由の複製ではないことに注意してください。 パケットベースの通信でのプロトコル識別子（IPヘッダーのプロトコルフィールドなど）の必要性は明らかです。これは、このアルゴリズムか、ある種の計算集約型の推論アルゴリズムです。問題は、カプセル化されたプロトコルのヘッダーではなく、なぜIPヘッダーの一部として存在する必要があるのかということです。 それは私には思われる理論的な透明性が実用的な考慮事項（AKA「HaskellはGoは満たしている」...）を満たすものを例この1：一方ではIPヘッダの区切りに概念「プロトコル」フィールドを配置する利害の分離ことなどを。目的のOSIモデル。一方、スタックの上位のプロトコルに一貫した方法でタイプを強制することははるかに困難であり、最終的にはいずれにしても同様の状況につながります（たとえば、スタックの上位のすべてのプロトコルが最初のヘッダーバイトを使用してそのタイプを指定した場合、IP が同じように最後のヘッダーバイトを使用しているかのように見えます。 だから私の質問は-「プロトコル」フィールドをIPのパケットヘッダー内に配置する理由は何ですか？ 編集：この質問を書くとき、私は「推論」の前に「元の」という単語を追加するかどうか、つまりIPを考案したチームの推論を検討しましたが、質問が過去形（「何でしたか推論...」）。それでも実際にはその質問に答える返信はないため、これは必要なようです。注目すべきいくつかの洞察： @immibisは、他の形式では他のプロトコルのモデルを壊すことを示唆しています（たとえば、暗号化された通信プロトコルには平文の識別フィールドが必要です） @Eddieは本質的にその理由が慣習であることを述べています（プロトコルチェーンの設計の受け入れ、それがなぜ慣習なのかは謎のままです） @Rickyは、包括的な検討事項として実用性を強調します @Claudioは、プロトコルフィールドがカプセル化されたヘッダーの一部であることを示唆しています。IPヘッダーの解析中に行われる現在のモデルでは、追加のヘッダー識別ステップが必要になるでしょう。 言い換えれば、次のヘッダーのタイプを識別するすべてのヘッダーの代わりに、すべてのヘッダーが所定の場所（たとえば、最初のヘッダーバイト）で独自のタイプを識別するモデルの何が問題になっていますか？なぜそのようなモデルは現在のものよりも望ましくないのですか？ 編集＃2：答えは与えられたいくつかの答え（主に上記のものと@Eddieの2番目の補遺）の組み合わせのようです： 単純：の主破壊層不可知論をにこの特定の場合は全体としてスタック（またはモデル）は単純であることを意味します。 「プロトコル識別」フェーズはなく、暗黙的でも明示的でもありません レイヤーの独立性が向上しました（たとえば、暗号化された通信ハンドラーは、ヘルパープロトコルとレイヤーを共有する必要がありません） 規制も大幅に簡素化され、クライアントプロトコルに要件を適用する必要がありません。 パフォーマンス：カプセル化されたパケットのプロトコルをパケット自体の前に示すことで、いくつかのタイプの高速ルーティングプロトコル（パケットフィルタリング、QOS、カットスルースイッチング）をネットワーク（インターネット）レイヤー自体に統合できます。これにより、ハッシュテーブルにアクセスできるのと同じくらい迅速に決定を下すことができます。これは、このプロトコルを実行するために設計されたハードウェアが限られていることを考えると、さらに重要です。 このモデルには欠点がありますが、一般的な使用例では、代替モデルよりも適しているようです。