IPパケット内のソースIPと宛先IPの位置

イーサネットの人たちは早い段階で「カットスルー」を想定していたと思います。IPでは、「ヘッダーチェックサム」はIPアドレスの前にあるため、「カットスルー」は実際には不可能ですが、IPアドレスが含まれているため、ヘッダーの値を決定する前にIPヘッダー全体を読み取る必要があります。このコンテキストでのヘッダーの順序は関係ありません。しかし、それでも疑問が残ります。なぜIPヘッダーは「カットスルー」に対応するように設計されていないのですか。そして答えはおそらく、それはその時点ではそれほど興味深い/重要ではなかったし、それが今日であるかどうかは議論の余地がある。

@ytti：IPが「カットスルー」をサポートするとしたら、どのような改善がありますか？IPはめったに層2なしで使用されていません

イーサネットの場合、宛先を最初に設定したのは、当時ハブが大流行していたためであり、ホストがフレームが自分向けのものであるかどうかをホストが判断するのがより効率的になったためです。以前のバージョンのIPおよびTCPでは、最初に宛先アドレスがありました。それがv4で切り替えられた理由は本当の説明はありません。効率や速度がこれまでIPに重点を置いてきたとは思えません。

@BatchyXはIPがL2で使用されている場合、L3ルーティングの決定を行う必要がある場合、フレーム設計のためにそれを「カットスルー」することはできません。私もそれについてあまり強く感じていません。たぶん、一部の人々はIPカットスルーの素晴らしいユースケースを持っています。

何か回答がありましたか？もしそうなら、質問が永遠にポップアップし続けないように答えを受け入れ、答えを探します。または、独自の回答を提供して受け入れることもできます。

TokenRingはMACを左から右に送信するため、マルチキャストビットは8番目のビットではなく1番目のビットと見なされます。