データがイーサネットフレームのどこから始まるかを検索すると、TCPヘッダー（20バイト）+ IPヘッダー（20バイト）+イーサネットヘッダー（SA + DA +タイプ）、つまり14バイトという一般的な回答が得られます。つまり、簡単に言えば、その質問に対する答えは52〜54バイトになり、データはイーサネットフレームで始まりますが、8バイトのプリアンブルも追加する必要はありませんか。
また、イーサネットフレームの1514であるイーサネットフレームサイズについて検索しました。ここでプリアンブルとCRCを無視するのはなぜですか？
回答:
ジョナサンジョの答えに追加：
イーサネットのコンポーネントは、1（異なるメディアで実行できるため）と2（異なるメディアでフレームが同じであるため）の両方にあります。
Preamble、SoF Delimiter、Inter-packet Gapは実際にはレイヤー1（レシーバーの起動など）にあり、フレーム（ヘッダー、ペイロード、FCSを含む）はレイヤー2にあります。
イーサネットフレーム内のデータは、イーサネットフレームのペイロードです。質問1では、すべてのレイヤー3プロトコルがIPv4であり、すべてのレイヤー4プロトコルがTCPであると想定しています。これらは悪い想定です。イーサネットは、どのレイヤー3プロトコル（IPv4、IPX、IPv6、AppleTalkなど）を使用するかを認識していないため、フレームのデータがペイロードになります。たとえば、IPv4パケットヘッダーは20〜60オクテットですが、IPv6パケットヘッダーは常に40オクテットです。イーサネットはこれを認識していません。ペイロードフィールドがあることだけを認識しており、そのフィールドにあるものは認識していません。
イーサネットフレームヘッダーは通常14オクテットですが、タグ付きフレームがない限り、18オクテットです。MTUは最大ペイロードサイズです。イーサネットの最小フレームサイズは、FCSを含めて64オクテットであるため、ペイロードの範囲は42（タグあり）または46（タグなし）オクテットから最大ペイロードサイズの1500オクテットまでです。つまり、イーサネットフレーム（ヘッダーとペイロード）は60オクテットから1514（タグなし）または1518（タグ付き）オクテットです。
データがどこから始まるかというと、アプリケーションデータを意味します。これは実際にはすべてのプロトコルに依存します。UDPヘッダーはわずか8オクテットであり、UDPペイロードはアプリケーションデータの場合もあれば、アプリケーションデータとしてカウントされない独自のヘッダーを持つアプリケーション層プロトコルのデータグラムの場合もあります。TCPの例では、WebブラウザでWebサーバーを実行している場合があります。HTTP（アプリケーション層プロトコル）またはHTMLをデータとしてカウントしますか（HTMLはHTTPのデータです）。データを参照する場合、それは参照しているプロトコルに関連しています。
プリアンブルは実際には7オクテットで、その後にフレーミングオクテット、開始フレーム区切り文字（SFD）が続きます。フレームが来ることを示し、同期の目的で機能するだけで、フレームの一部ではありません。フレーム間ギャップと同じように、フレームの一部としてカウントされません。プリアンブルとSFDがメモリに入ることがないため、それを含むメモリオフセットはありません8。
イーサネットフレームは、ハードウェアが通常FCSを計算/チェックし、CPUがそれを認識したりメモリに配置したりしないため、1514オクテットと記述されることがあります。src、dest、type、ペイロードのみです。ただし、標準に従って、フレームはFCSを含むように明確に定義されています。基本フレームは、少なくとも1500オクテット、プラス14のプラス4 FCS = 1520の最大クライアント・データ・フィールドの長さを有するものとして定義されます。
PS。トランク上のパケット用の別の4オクテットであるオプションの802.1qタグを忘れないでください。他にもいくつか特別なタイプがあります。
編集標準は、主にFCSを含むように定義されているフレームについて説明しています（Richardのコメントに感謝）。また 、プリアンブルの先頭から拡張ビットの末尾までのパケットについても説明します（FCSの後で、衝突検出を確実にするために必要になる場合があります）。このパケットは、ハードウェアが回線上で送信するすべてのビットです。（通常、イーサネットフレーム内のIP パケットについて話すので、この「パケット」の使用法は混乱する可能性があります。）
結局のところ、それは定義の問題であり、ありがたいことにそれらを調べることができます。ご存じない場合は、標準を無料で利用できます。コアは4,000ページの長さ（！）ですが、定義などのほとんどのものは非常に読みやすく、完全に明確です。少なくともセクション3.1.1パケット形式を確認することを強くお勧めします。http://www.ieee802.org/3/
すでに存在することに加えて、良い答え：
プリアンブルは物理層の重要な機能です。データを単一ビットまたはシンボルストリームにシリアル化する場合、何らかの形式の同期を提供する必要があることに注意してください-最初にビット/シンボルに、次にワードに。
プリアンブルがワイヤ上で生成するシンボルパターン（実際には01010 ...は10BASE-xマンチェスターコードのみ）により、レシーバーはシンボルクロックをトランスミッターの正確な速度に調整できます。ワイヤーに変更がない場合でも、受信したシンボルの数がわかります。（すべての物理層は中間同期の手段も提供するため、継続的なプロセスです。）
プリアンブルの後ろのSOFパターンは、最初のワード（またはオクテット/バイト）の始まりを示します。レシーバーは、そのバッファーをアクティブにし、デコードされたビットをクロックし、デコーダーから出力されるビットを非シリアル化して、ワード単位でバッファーに送信します。一度に1バイトであるか32ビットワードであるかは関係ありませんが、バイト境界が正しいことが重要です。
したがって、プリアンブルとSOFは必ず物理トランスポートメカニズムの一部であり、物理層に属します。レイヤー2の観点からすると、フレームには開始マーカーは必要ありません。最初のオクテットが入ってくるところから始まります。
レイヤリングに関する他の優れた回答に加えて、一部のプロトコルはL2イーサネットフレームのすぐ上にあります。最もよく知られているのは、リンクに直接関連するARP、RARP、CDPなどです（また、 Zac、LLDPやSTPのBPDUなどの他のプロトコル）
それは非常にまれですが、データをイーサネットフレームで送信するアプリケーションが見つかることがありますが、これについて私が見た唯一の理由は、a）あいまいになるように設計された独自のプロトコル、またはライセンス管理のように純粋にローカルなプロトコル、b ）実験、特にリアルタイム転送またはプロトコルスタックタイミングの評価。これの長所と短所は、この回答の範囲外です。
これは、「データ」が0x0eで始まるタイミングテストパケットの出力です。
14:54:29.698140 34:02:86:9f:f2:fc > 00:04:75:c8:28:e5, 802.3, length 64: length 50
0x0000: 0004 75c8 28e5 3402 869f f2fc 0000 4041 ..u.(.4.......@A
0x0010: 4243 4445 4647 4849 4a4b 4c4d 4e4f 5051 BCDEFGHIJKLMNOPQ
0x0020: 5253 5455 5657 5859 5a5b 5c5d 5e5f 6061 RSTUVWXYZ[\]^_`a
0x0030: 6263 6465 6667 6869 6a6b 6c6d 6e6f 7071 bcdefghijklmnopq