イーサネットフレームチェックシーケンスは、データリンク層のフレームの最後に常に追加されます。フレームの最後に追加され、他の場所には追加されないのはなぜですか？
私はそれについて考え、CRCチェックサムの計算方法や、フレームの構造がヘッダー+crc+ペイロードではなくヘッダー+ペイロード+crcの方がハードウェアで実行しやすいことと関係があるのではないかと考えました。
CRCは（データ+パディング）/除数の形式のXOR除算を実行し、最後のフレームではパディングが余りに置き換えられます。次に、受信機は（データ+剰余）/除数を計算し、結果が0の場合にフレームを受け入れます。
正解です。フレームの最後にCRCを配置すると、パケットの遅延が減り、ハードウェアのバッファリング要件が減ります。送信側では、ハードウェアはフレームのバイトをすぐに読み取って送信できます。送信機は、データが通過するときにその場でCRCを計算し、フレームのテールにCRCを追加するだけです。
CRCがイーサネットヘッダーのどこかにある代替案を検討してください。ハードウェアは、CRCを計算するために、フレーム全体を読み取って保存する必要があります。これは大規模な先読み操作に相当し、送信遅延とハードウェアコストを大幅に増加させます。受信機にとっても状況はさらに複雑になります。
実際、配置はCRCとは非常に関係があります。多項式の除算です。CRCの残りをペイロードビットストリームの前に移動すると、バーストエラー検出などのCRCプロパティの一部が無効になります。
これを理解するための鍵は、CRCが常にバイトやペイロードのブロックではなくビットのストリームで動作しているという事実です。ビットがリトルエンディアンで送信される障害CRC実装を見つけることがありますが、実際にはCRCはビッグエンディアンで計算されます（個々のバイト内のビット順序に関して）。