「パケット」の仕組み

結論

ネットはデータをそのままドーンと送らず、小分け（パケット化）して運びます。
パケットには「宛先」「順番」「エラー検出」などのヘッダが付いていて、途中で別ルートを通ったり順番が前後しても、受信側で並べ直して復元できます。
そして最終的には、これら全部が**0と1（ビット列）**として線（電気/光/電波）に流れます。

1. そもそも「パケット」って何？

ざっくり言うと、パケットは “ネットの郵便小包” です。

• 中身（ペイロード）：送りたいデータ（文章、画像、動画の一部など）
• 表紙（ヘッダ）：宛先・管理情報（どこへ、何番目、壊れてないか等）

大きいデータは小包を大量に作って送る。途中で何個か落ちても（=パケットロス）再送したり、多少欠けても待たずに続行したり（用途次第）します。

2. レイヤで見る：封筒を重ねるイメージ

「パケット」は文脈で指す層がズレやすいので、まず“封筒の重ね方”で掴むのが早いです。

• Ethernet（L2）：同じネット内で次に渡す相手（MACアドレス）
• IP（L3）：最終目的地（IPアドレス）
• TCP/UDP（L4）：端末のどのアプリ宛？（ポート番号）
• アプリのデータ：HTTP、動画データの一部、文字列…など

イメージ：

[Ethernet封筒
  [IP封筒
    [TCP/UDP封筒
      [データ本体]
    ]
  ]
]

3. 実際の送信手順（「送る」ボタンの裏で起きてること）

ここでは「文字列をTCPで送る」典型パターンを、できるだけ現実寄りに並べます。

3.1 事前に起きがちなこと（環境で発生/省略）

• DNS：ドメイン名→IPアドレスに変換（例：example.com → 93.184…）
• ARP（IPv4）/NDP（IPv6）：次ホップ（だいたいルータ）のMACアドレスを調べる
  ※インターネット相手でも、Ethernetの宛先MACは通常「相手サーバ」ではなく「自分のルータ」

3.2 送信の本体（アプリが send() した瞬間から）

1. アプリ：文字列を送信要求
2. 文字コード化：文字列 → バイト列（多くはUTF-8）
3. TCP：バイト列にTCPヘッダを付ける（順番、確認、再送のための情報）
4. IP：IPヘッダを付ける（最終宛先IP、TTL等）
5. Ethernet：MACヘッダを付ける（次ホップMAC、EtherType）
6. NIC：最後にFCS（CRC）を付け、物理層でビット列として送出
   • ただし物理層はさらに符号化されるので、「0/1がそのまま電圧」ではなく規格に従って表現されます

4. 「1パケットは何バイト？」の実用答え

固定ではありません。が、現場での“だいたい”はこうです。

• 家庭/社内LAN（Ethernet）だと MTU 1500バイトがよくある（IPが1回で運べる上限の目安）
• TCPの場合、IPとTCPのヘッダを引いた「データ本体」は
  • IPv4/TCP：1500 − 20（IP） − 20（TCP） = 1460バイト（よく出てくる数字）
• PPPoE等ではMTUが1492になって、1460より少し減る…など例外も多い

要点：“パケット化＝超ムダ”ではなく、普通はMTU近くの大きめ単位で運ぶので効率は悪くなりにくい。

5. 具体例：「こんにちは」を“バイト”と“0/1”にバラす

「こんにちは」をネットで運ぶ前に、まずバイト列にします（ここではUTF-8）。

5.1 UTF-8の16進（hex）

「こんにちは」（5文字）は、UTF-8だと多くの場合 1文字=3バイトなので 合計15バイトになります。

• こ: E3 81 93
• ん: E3 82 93
• に: E3 81 AB
• ち: E3 81 A1
• は: E3 81 AF

まとめ：
E3 81 93 E3 82 93 E3 81 AB E3 81 A1 E3 81 AF（15バイト）

5.2 これを“0と1（ビット）”で表示

1バイト=8ビットなので、そのまま2進数にします。

11100011 10000001 10010011 11100011 10000010 10010011 11100011 10000001
10101011 11100011 10000001 10100001 11100011 10000001 10101111

これが「こんにちは」の“データ本体”部分の ビット列です。
実際のパケットでは、この前にIP/TCP等のヘッダが付き、さらにEthernetヘッダが付きます。

6. 「ヘッダが付く」とどれくらい増える？

「こんにちは」15バイトに対して、最小構成の目安はこうなります（暗号化なし、オプションなしの理想化）。

• TCPヘッダ：20バイト
• IPv4ヘッダ：20バイト
• Ethernetヘッダ + FCS：14 + 4 = 18バイト

合計の“増え” = 20 + 20 + 18 = 58バイト
中身15バイトなので、かなり小さいデータだと相対的にヘッダ比が大きい。

ただし、動画みたいにデータが大きく連続する場合は、通常 1パケットのデータ本体が1460バイト付近になるため、ヘッダ比は小さくなります（次章）。

7. 「動画だと、とんでもないことになる？」への答え

7.1 普通の“圧縮された動画”は、パケット数は多いが普通に捌ける

例：1080p配信が 5 Mbps だと仮定します。

• 5,000,000 bit/s ÷ 8 = 625,000 byte/s
• 1パケットで運ぶ“データ本体”が約1460 byteなら
  625,000 ÷ 1,460 ≈ 428パケット/秒

4K配信で 25 Mbps なら

• 25,000,000 bit/s ÷ 8 = 3,125,000 byte/s
• 3,125,000 ÷ 1,460 ≈ 2,140パケット/秒

1秒あたり数百〜数千パケットは、現代のネットでは珍しくありません。

7.2 “パケット化のムダ”は、動画だと数％程度に収まる

MTU1500の典型で、TCP/IPv4/Ethernetの最低限を足すと

• データ本体：1460 byte
• ヘッダ類：58 byte（上で計算したやつ）
• 1518 byte中のヘッダ比：58 / 1518 ≈ 3.8%

さらにEthernetには線上で

• Preamble+SFD（8 byte相当）
• IFG（12 byte相当の“間”）

があるので、線上の効率で見てもだいたい

• 1回あたり線上：1518 + 8 + 12 = 1538 byte相当
• ヘッダ等（データ以外）：1538 − 1460 = 78 byte相当
• 比率：78 / 1538 ≈ 5.1%

つまり、動画が「パケットになったせいで10倍になる」みたいなことは通常起きません。

7.3 本当に“とんでもない”のは未圧縮（生動画）

未圧縮1080p/60fps/RGB（24bit）を雑に見積もると：

• 1920×1080×3 ≈ 6.2MB/フレーム
• ×60fps ≈ 約373MB/s
• bit換算で 約3Gbps

これは一般回線だと厳しい。だから現実の配信は H.264/HEVC/AV1 等で圧縮して、数Mbps〜数十Mbpsに落として送っています。

8. 「動画が止まる」主因は“パケット数”より別にある

動画が止まるのは多くの場合：

• 帯域不足（必要ビットレートに届かない）
• ロス/ジッタ（再送待ち、バッファ枯渇）
• 混雑制御（TCP/QUICが回線混雑と判断して速度を落とす）
• Wi-Fi区間の再送増（電波悪いと無線側でやり直しが増える）

要するに、パケット数そのものより **品質（ロス/遅延のブレ）**と 足りる帯域が効きます。

留意点（ここだけ押さえると誤解が減る）

• 「パケット」という言葉は人によって IPパケットを指したり Ethernetフレームまで含めたりします（サイズの答えがズレる原因）
• HTTPS/TLSやHTTP/2/HTTP/3（QUIC）を使うと、ヘッダや暗号化で実際の構造はもっと複雑になります
  （特にTLSだと“中身”は暗号文になり、「こんにちは」は見えなくなる）
• 実機で“実際のバイト列”を見たいなら Wireshark が定番。ただしFCSはNICで付加されることが多く、キャプチャには出ない場合があります

もし次に深掘りするなら、ブログの続編として一番効くのはこの2つです：

1. Wiresharkで「こんにちは」がどう見えるか（実キャプチャの読み方）
2. 動画配信（HLS/DASH）で“止まらない”ためのバッファと適応ビットレートの仕組み