パケットフォーマットとはなんなのか

パケットフォーマットとは、ネットワーク上でデータを送受信するときに使われる、データの構造や並び方を定めたルールのことです。

インターネットや社内LANなどの通信では、データがそのまま大きな塊として流れているわけではありません。

Webページ、画像、動画、メール、APIリクエストなどのデータは、通信しやすい単位に分割され、宛先や送信元などの制御情報を付けた形で送られます。

この通信単位を広い意味でパケットと呼びます。

そして、そのパケットの中に、

どこから送られたのか
どこへ送るのか
どのプロトコルを使っているのか
データの長さはいくつか
順番はどうなっているか
エラー確認用の情報はどこにあるか
実際のデータ本体はどこから始まるか

といった情報を、どの順番で、何ビット・何バイトずつ配置するかを決めたものが、パケットフォーマットです。

簡単に言えば、パケットフォーマットはネットワーク上を流れるデータの設計図です。

パケットとは何か

パケットは通信データの小さな単位

パケットとは、ネットワークで送受信されるデータの単位です。

例えば、ブラウザでWebサイトを開くと、あなたのPCやスマートフォンはWebサーバーに対してリクエストを送ります。

サーバーはそのリクエストに応じて、HTML、CSS、JavaScript、画像などを返します。

このとき、Webページのデータがそのまま1つの巨大な塊として送られるわけではありません。

実際には、通信プロトコルやネットワーク機器が扱いやすいサイズに分けられ、それぞれに制御情報が付けられて送信されます。

この小さな通信単位がパケットです。

パケットは宅配便に似ている

パケットは、宅配便の荷物に例えると分かりやすいです。

荷物を送るとき、箱の中には実際に届けたい商品が入っています。

しかし、それだけでは配送できません。

箱には、宛先、送り主、配送番号、配送方法などの情報が必要です。

ネットワーク通信でも同じです。

実際に送りたいデータ本体だけではなく、送信元、宛先、通信方式、データ長、エラー確認情報などが必要になります。

つまり、パケットは次のような構造を持っています。

配送ラベルに相当する情報 = ヘッダー
実際に送りたい中身     = ペイロード
必要に応じた確認情報   = トレーラー

この「どこに何を書くか」を決めたものがパケットフォーマットです。

パケットフォーマットの基本構造

基本は「ヘッダー」と「ペイロード」

多くのパケットは、基本的に次のような構造を持ちます。

+----------------+----------------+
| ヘッダー        | ペイロード      |
+----------------+----------------+

ヘッダーには通信に必要な制御情報が入り、ペイロードには実際に運びたいデータが入ります。

プロトコルによっては、末尾にトレーラーが付く場合もあります。

+----------------+----------------+----------------+
| ヘッダー        | ペイロード      | トレーラー      |
+----------------+----------------+----------------+

ただし、すべてのプロトコルが必ずトレーラーを持つわけではありません。

例えば、EthernetフレームにはFCSというトレーラーがありますが、IPパケットやTCPセグメントには通常トレーラーはありません。

ヘッダーとは

ヘッダーとは、パケットの先頭に付く制御情報です。

主に次のような情報が含まれます。

送信元アドレス
宛先アドレス
プロトコルの種類
パケット全体の長さ
順序番号
フラグ
エラー確認用の情報

ヘッダーは、手紙でいう宛名や差出人、宅配便でいう送り状のような役割を持ちます。

受信側の機器は、ヘッダーを見て「このパケットをどう処理すればよいか」を判断します。

ペイロードとは

ペイロードとは、パケットが実際に運ぶデータ本体のことです。

例えば、次のようなものがペイロードになります。

WebページのHTML
APIリクエストのJSON
メール本文
画像データの一部
動画データの一部
DNS問い合わせ内容

ただし、ネットワークでは階層ごとにデータが包まれるため、ある層にとってのペイロードが、別の層ではさらにヘッダーを持つ通信データになっていることがあります。

例えば、Ethernetから見たペイロードはIPパケットです。

一方、IPから見たペイロードはTCPセグメントやUDPデータグラムです。

トレーラーとは

トレーラーとは、パケットやフレームの末尾に付く制御情報です。

代表的な例が、Ethernetフレームの末尾に付くFCSです。

FCSはFrame Check Sequenceの略で、受信したフレームが途中で壊れていないかを確認するために使われます。

ただし、トレーラーはすべてのプロトコルに存在するわけではありません。

多くのプロトコルでは、ヘッダーとペイロードだけで構成されます。

パケットフォーマットが必要な理由

受信側がデータを正しく解釈するため

ネットワーク上を流れるデータは、最終的には0と1のビット列です。

例えば、次のようなデータが届いたとします。

010001010110001001011010...

これだけを見ても、どこからどこまでが宛先で、どこからが本文なのか分かりません。

そこで、あらかじめフォーマットを決めておきます。

例えば、架空のプロトコルで次のように定義されているとします。

最初の1バイト   = 送信元ID
次の1バイト     = 宛先ID
次の2バイト     = データ長
それ以降         = データ本体

このルールがあるからこそ、受信側はビット列を意味のある情報として読み取れます。

パケットフォーマットがなければ、通信機器は受け取ったデータを正しく解釈できません。

異なる機器同士が通信するため

インターネットでは、メーカーもOSも性能も異なる機器が互いに通信しています。

Windows PC、Mac、iPhone、Android、Linuxサーバー、ルーター、スイッチ、クラウドサーバーなど、さまざまな機器が同じネットワーク上でデータをやり取りします。

それが可能なのは、TCP/IPやEthernetなどのプロトコルで、パケットフォーマットが標準化されているからです。

送信側と受信側が同じフォーマットを前提にしていれば、異なる機器同士でも正しく通信できます。

通信を制御するため

パケットには、単にデータ本体だけが入っているわけではありません。

通信を制御するために、次のような情報も必要です。

どの順番のデータか
届いたかどうか
分割されたデータかどうか
どのアプリケーション宛てか
通信を開始するのか終了するのか
途中で壊れていないか

こうした制御情報を正しく扱うためにも、パケットフォーマットが必要です。

パケットフォーマットでよく使われる用語

フィールド

フィールドとは、パケットフォーマットの中にある1つ1つの項目です。

例えば、IPヘッダーには次のようなフィールドがあります。

Version
Header Length
Total Length
TTL
Protocol
Source Address
Destination Address

それぞれのフィールドには、意味とサイズが決められています。

例えば、IPv4のVersionフィールドは4ビットです。

IPv4であれば、この値は通常「4」になります。

ビットとバイト

ビットは、0または1を表す最小単位です。

バイトは通常8ビットです。

パケットフォーマットでは、フィールドのサイズがビット単位またはバイト単位で定義されます。

例えば、IPv4アドレスは32ビット、つまり4バイトです。

192.168.0.1

このようなIPアドレスも、内部的には4バイトの値として扱われます。

固定長フィールド

固定長フィールドとは、サイズが決まっているフィールドです。

例えば、IPv4の送信元IPアドレスと宛先IPアドレスは、それぞれ32ビットです。

送信元IPアドレス = 32ビット
宛先IPアドレス   = 32ビット

固定長フィールドは、受信側が解析しやすく、処理も比較的高速です。

可変長フィールド

可変長フィールドとは、長さが状況によって変わるフィールドです。

例えば、次のようなものがあります。

TCPオプション
IPオプション
HTTPヘッダー
DNSの名前部分
TLSの拡張情報

可変長フィールドを使う場合は、受信側がどこまで読めばよいか判断できるようにする必要があります。

そのため、一般的には「長さ」を示すフィールドや、「ここで終わり」と分かる区切りが使われます。

エンディアン

エンディアンとは、複数バイトの数値をどの順番で並べるかというルールです。

ネットワーク通信では、一般的にネットワークバイトオーダーと呼ばれる並び方が使われます。

これは通常、ビッグエンディアンです。

例えば、16ビットの値 0x1234 は、ネットワーク上では通常次の順番で表現されます。

12 34

送信側と受信側でバイト順の解釈が違うと、数値を正しく読み取れません。

そのため、パケットフォーマットではバイト順も重要です。

代表的なパケットフォーマットの例

Ethernetフレームのフォーマット

Ethernetは、LAN内で広く使われているデータリンク層の技術です。

Ethernetで扱われる通信単位は、厳密にはパケットではなくフレームと呼ばれます。

基本的なEthernet IIフレームは、概念的には次のような構造です。

+----------------------+----------------------+----------------+
| 宛先MACアドレス       | 送信元MACアドレス      | EtherType       |
+----------------------+----------------------+----------------+
| ペイロード                                             |
+--------------------------------------------------------+
| FCS                                                    |
+--------------------------------------------------------+

主なフィールドは次のとおりです。

項目	役割
宛先MACアドレス	LAN内での送り先機器を示す
送信元MACアドレス	LAN内での送り主機器を示す
EtherType	ペイロードの種類を示す
ペイロード	IPv4、IPv6、ARPなどのデータ
FCS	フレームのエラー確認に使う

Ethernetフレームのペイロードには、必ずIPパケットが入るわけではありません。

EtherTypeによって中身が決まります。

0x0800 = IPv4
0x86DD = IPv6
0x0806 = ARP

また、実際のEthernetでは、プリアンブル、SFD、VLANタグなどが関係する場合もあります。前述の構造は、理解しやすくするための基本形です。

IPv4パケットのフォーマット

IPは、異なるネットワークを越えてデータを届けるためのプロトコルです。

IPv4パケットのヘッダーには、次のようなフィールドがあります。

Version
IHL
DSCP / ECN
Total Length
Identification
Flags
Fragment Offset
TTL
Protocol
Header Checksum
Source Address
Destination Address
Options

主な項目を整理すると、次のようになります。

項目	役割
Version	IPのバージョンを示す。IPv4なら4
IHL	IPv4ヘッダーの長さを示す
Total Length	IPパケット全体の長さを示す
Identification	分割されたパケットの識別に使う
Flags	分割可否などを示す
Fragment Offset	分割されたデータの位置を示す
TTL	通過できるルーター数の上限を示す
Protocol	中身がTCP、UDP、ICMPなどのどれかを示す
Header Checksum	IPv4ヘッダーのエラー確認に使う
Source Address	送信元IPアドレス
Destination Address	宛先IPアドレス

IPv4パケットは、宛先IPアドレスをもとにルーターを経由しながら目的地へ運ばれます。

IPv6パケットのフォーマット

IPv6もIPの一種ですが、IPv4とはヘッダー構造が大きく異なります。

IPv6では、アドレスが128ビットになり、IPv4よりもはるかに広いアドレス空間を持ちます。

また、IPv6にはIPv4のようなヘッダーチェックサムがありません。

TTLに相当するフィールドは、IPv6ではHop Limitと呼ばれます。

IPv6では、オプション情報は基本ヘッダーではなく、拡張ヘッダーとして扱われます。

そのため、「IPパケット」と一言で言っても、IPv4とIPv6ではパケットフォーマットが異なる点に注意が必要です。

TCPセグメントのフォーマット

TCPは、信頼性のある通信を行うためのトランスポート層プロトコルです。

TCPで扱う通信単位は、厳密にはセグメントと呼ばれます。

TCPヘッダーには、次のようなフィールドがあります。

送信元ポート番号
宛先ポート番号
シーケンス番号
確認応答番号
データオフセット
フラグ
ウィンドウサイズ
チェックサム
緊急ポインタ
オプション

主な項目は次のとおりです。

項目	役割
送信元ポート番号	送信元アプリケーションを識別する
宛先ポート番号	宛先アプリケーションを識別する
シーケンス番号	データの順序を管理する
確認応答番号	どこまで受信したかを知らせる
データオフセット	TCPヘッダーの長さを示す
フラグ	SYN、ACK、FINなど通信状態を示す
ウィンドウサイズ	受信可能なデータ量を示す
チェックサム	TCPセグメントのエラー確認に使う
オプション	MSS、ウィンドウスケールなどの追加情報

TCPは、データが届いたかを確認し、必要に応じて再送します。

また、順番が入れ替わったデータを正しく並べ直す役割も持ちます。

Web閲覧、メール送信、ファイル転送など、多くの通信でTCPは使われてきました。

ただし、現在のWeb通信ではHTTP/3のようにUDP上のQUICを使う方式もあります。

そのため、すべてのWeb通信がTCPだけで行われるわけではありません。

UDPデータグラムのフォーマット

UDPは、TCPよりもシンプルなトランスポート層プロトコルです。

UDPで扱う通信単位は、データグラムと呼ばれます。

UDPヘッダーは非常に短く、基本的には次の4つのフィールドで構成されます。

送信元ポート番号
宛先ポート番号
長さ
チェックサム

主な項目は次のとおりです。

項目	役割
送信元ポート番号	送信元アプリケーションを識別する
宛先ポート番号	宛先アプリケーションを識別する
長さ	UDPヘッダーとデータ全体の長さを示す
チェックサム	データの破損確認に使う

UDPには、TCPのような確認応答、再送制御、順序制御、コネクション確立の仕組みがありません。

そのため、UDPは軽量で低遅延な通信に向いています。

代表的には、次のような用途で使われます。

DNS
NTP
音声通話
ビデオ会議
オンラインゲーム
QUIC / HTTP/3

ただし、UDP自体が信頼性を保証しないため、必要に応じてアプリケーション側や上位プロトコル側で再送や順序制御を実装します。

通信は階層ごとにカプセル化される

カプセル化とは

ネットワーク通信では、複数のプロトコルが階層的に組み合わされます。

例えば、HTTPのデータを送る場合、HTTPデータにTCPヘッダーが付き、その外側にIPヘッダーが付き、さらにEthernetヘッダーが付きます。

このように、上位層のデータを下位層のプロトコルで包んでいくことをカプセル化と呼びます。

HTTP/1.1・HTTP/2 over HTTPSの例

HTTPS通信のうち、HTTP/1.1やHTTP/2をTCP上で使う場合、概念的には次のような構造になります。

Ethernet / Wi-Fi
└── IP
    └── TCP
        └── TLS
            └── HTTP

この場合、HTTPの内容はTLSによって暗号化されます。

そのため、ネットワーク上で観測できるのは、主にIPアドレス、ポート番号、通信サイズ、タイミング、TLSハンドシェイクの一部情報などです。

HTTPのパス、Cookie、POST本文などは通常見えません。

HTTP/3の例

HTTP/3では、TCPではなくQUICが使われます。

QUICはUDPの上で動作します。

HTTP/3の通信は、概念的には次のようになります。

Ethernet / Wi-Fi
└── IP
    └── UDP
        └── QUIC
            └── HTTP/3

そのため、現代のWeb通信を理解する場合は、従来のTCPベースのHTTPSだけでなく、UDP/QUICベースのHTTP/3も考慮する必要があります。

層によってペイロードの意味は変わる

ペイロードは、どの層から見るかによって意味が変わります。

例えば、TCPベースのHTTPS通信では次のようになります。

Ethernetから見たペイロード = IPパケット
IPから見たペイロード       = TCPセグメント
TCPから見たペイロード      = TLSレコード
TLSから見た中身            = HTTPデータ

平文HTTPであれば、TCPから見たペイロードはHTTPデータになります。

しかし、HTTPSの場合は、TCPの上にTLSがあり、その中に暗号化されたHTTPデータが入ります。

このように、パケットフォーマットを理解するときは、どの階層の視点で見ているのかが重要です。

パケットフォーマットの具体例

架空のシンプルなプロトコル

パケットフォーマットの考え方を理解するために、架空のシンプルなプロトコルを考えてみます。

このプロトコルでは、次のようなフォーマットを使うとします。

+------------+------------+------------+----------------+
| 送信元ID    | 宛先ID      | データ長     | データ本体       |
+------------+------------+------------+----------------+
| 1バイト     | 1バイト     | 2バイト      | 可変長           |
+------------+------------+------------+----------------+

この場合、ルールは次のとおりです。

最初の1バイト = 送信元ID
次の1バイト   = 宛先ID
次の2バイト   = データ長
それ以降       = データ本体

バイト列を読み解く例

次のようなバイト列があったとします。

01 05 00 04 54 45 53 54

このフォーマットに従って読むと、次のように解釈できます。

01             = 送信元ID
05             = 宛先ID
00 04          = データ長 4バイト
54 45 53 54    = データ本体

54 45 53 54 はASCII文字として読むと TEST です。

つまり、このパケットは次のような意味になります。

送信元ID 1 から 宛先ID 5 へ、
4バイトのデータ "TEST" を送っている

ここで 00 04 を4と読むのは、ビッグエンディアンとして解釈しているためです。

このように、パケットフォーマットが決まっていれば、単なるバイト列を意味のあるデータとして読み取れます。

パケット・フレーム・セグメント・データグラムの違い

階層によって呼び方が変わる

ネットワークでは、似たような言葉がいくつも出てきます。

代表的な用語を整理すると、次のようになります。

用語	主に使われる層	例
フレーム	データリンク層	Ethernetフレーム、Wi-Fiフレーム
パケット	ネットワーク層	IPパケット
セグメント	トランスポート層	TCPセグメント
データグラム	UDPやIPで使われることがある	UDPデータグラム、IPデータグラム
メッセージ	アプリケーション層	HTTPメッセージ、DNSメッセージ
レコード	TLSなどで使われる	TLSレコード
フレーム	HTTP/2やQUICでも使われる	HTTP/2フレーム、QUICフレーム

厳密には、層やプロトコルごとに呼び方が異なります。

ただし、日常的な会話や広い意味では、これらをまとめて「パケット」と呼ぶこともあります。

厳密な文書では用語を分ける

初心者向けの説明では「パケット」とまとめて説明しても問題ありません。

しかし、技術文書や障害調査では、どの層の話をしているのかを明確にする必要があります。

例えば、次のように表現を分けると誤解が少なくなります。

Ethernetの話なら「フレーム」
IPの話なら「パケット」
TCPの話なら「セグメント」
UDPの話なら「データグラム」
HTTPの話なら「メッセージ」
TLSの話なら「レコード」

この区別を理解しておくと、ネットワークの資料やWiresharkの解析結果を読みやすくなります。

MTUとパケットサイズ

MTUとは

MTUとは、Maximum Transmission Unitの略で、1回に送れる最大サイズのことです。

標準的なEthernetでは、IPパケットを載せるペイロード部分のMTUが1500バイトであることが多いです。

ただし、これは絶対ではありません。

例えば、次のような場合にはMTUが変わることがあります。

PPPoE
VPN
トンネル通信
Jumbo Frame
クラウド環境
モバイルネットワーク

PPPoEではMTUが1492バイトになることが多く、VPNでは暗号化やトンネル用ヘッダーの分だけ実効的なMTUが小さくなる場合があります。

MTUを超えるとどうなるか

IPパケットが経路上のMTUを超える場合、分割が必要になることがあります。

IPv4では、条件によってルーターがパケットを分割することがあります。

ただし、DF、つまりDon't Fragmentフラグが立っている場合は分割されず、破棄されることがあります。

IPv6では、途中のルーターはパケットを分割しません。送信元が適切なサイズに調整する必要があります。

現在の通信では、Path MTU Discoveryなどを使って、できるだけ途中での分割を避ける設計が一般的です。

Web表示速度にも関係する

MTUやパケットサイズは、Web表示速度にも関係します。

パケットが大きすぎると経路上で問題が起きる可能性があり、小さすぎるとヘッダーの割合が増えて効率が悪くなります。

通常のWebマーケティングやWeb制作ではMTUを直接設定する機会は少ないですが、VPN環境、社内ネットワーク、CDN、クラウド、サーバー設定などでは、通信品質に影響することがあります。

テキスト形式とバイナリ形式

テキストベースのフォーマット

プロトコルの中には、人間が比較的読みやすいテキスト形式で定義されているものがあります。

代表例はHTTP/1.1です。

GET /index.html HTTP/1.1
Host: example.com
User-Agent: ...

テキストベースのフォーマットには、次のようなメリットがあります。

人間が読みやすい
デバッグしやすい
ログとして扱いやすい
手動で確認しやすい

一方で、バイナリ形式に比べるとサイズが大きくなりやすく、解析コストも高くなる場合があります。

バイナリベースのフォーマット

IP、TCP、UDP、TLS、DNS、HTTP/2、QUICなどは、バイナリ形式のフォーマットとして扱われます。

バイナリ形式には、次のようなメリットがあります。

サイズを小さくしやすい
機械的に解析しやすい
処理を高速化しやすい
曖昧さを減らしやすい

一方で、人間が直接読むのは難しく、Wiresharkなどの解析ツールが必要になります。

例えば、IPパケットやTCPセグメントをそのまま16進数で見ても、初心者には意味が分かりにくいです。

しかし、フォーマットを知っていれば、どのバイトがどのフィールドに対応するかを読み解けます。

パケットフォーマットとプロトコルの関係

プロトコルは通信ルール全体

プロトコルとは、通信を成立させるためのルール全体です。

例えばTCPというプロトコルには、次のようなルールが含まれます。

どのようなヘッダーを使うか
通信をどう開始するか
通信をどう終了するか
データの順番をどう管理するか
受信確認をどう返すか
再送をどう行うか
タイムアウトをどう扱うか
エラーをどう処理するか

このように、プロトコルは単なるデータ形式だけではなく、通信手順や状態管理も含みます。

パケットフォーマットはデータ構造のルール

パケットフォーマットは、プロトコルの中でも特に「データをどのような構造にするか」に関する部分です。

整理すると、次のようになります。

プロトコル = 通信ルール全体
パケットフォーマット = データ構造のルール

例えばTCPであれば、TCPヘッダーの各フィールドの並び方やサイズがパケットフォーマットに相当します。

一方、3ウェイハンドシェイク、再送制御、輻輳制御などは、TCPプロトコル全体の動作ルールです。

Wiresharkで見るパケットフォーマット

Wiresharkとは

Wiresharkは、ネットワーク上を流れるパケットをキャプチャして解析できるツールです。

Wiresharkを使うと、実際に流れている通信を次のような階層で確認できます。

Ethernet II
Internet Protocol Version 4
Transmission Control Protocol
Transport Layer Security
Hypertext Transfer Protocol

これは、Wiresharkが各プロトコルのパケットフォーマットを知っているためです。

受信したバイト列をフォーマットに従って分解し、フィールドごとに意味を表示してくれます。

HTTPSでは中身が見えないことが多い

WiresharkでHTTP通信を見ると、メソッド、パス、ヘッダー、レスポンス内容などが確認できる場合があります。

しかし、HTTPS通信ではHTTPの中身がTLSで暗号化されています。

そのため、通常は次のような情報は見えません。

URLのパス
クエリパラメータ
Cookie
POST本文
HTML本文
APIレスポンス本文

一方で、次のような情報は見える可能性があります。

送信元IPアドレス
宛先IPアドレス
送信元ポート
宛先ポート
通信サイズ
通信タイミング
TLSハンドシェイクの一部情報

パケットフォーマットを理解すると、「どの情報が見えるのか」「どの情報が暗号化されて見えないのか」を切り分けやすくなります。

WebマーケティングやWeb制作との関係

ページ表示速度の理解に役立つ

WebマーケティングやWeb制作では、パケットフォーマットを直接読む機会は多くありません。

しかし、通信の仕組みを理解していると、ページ表示速度の改善をより深く考えられます。

例えば、Webページを表示するまでには、次のような処理が関係します。

DNS名前解決
TCP接続
TLSハンドシェイク
HTTPリクエスト
HTTPレスポンス
コンテンツのダウンロード
ブラウザのレンダリング

Core Web VitalsやLCP、TTFBを改善するときにも、ネットワーク通信の理解は重要です。

パケットフォーマットそのものを毎回読む必要はありませんが、通信にはヘッダーや制御情報があり、複数のプロトコルが階層的に関わっていると理解しておくと、原因調査の精度が上がります。

計測タグやAPI通信の理解に役立つ

広告タグ、アクセス解析タグ、コンバージョンAPI、サーバーサイドGTMなどでは、ブラウザやサーバーが外部サービスと通信します。

このとき、表面的にはJavaScriptやAPIリクエストに見えても、実際には次のような層を通っています。

HTTP / HTTPS
TLS
TCP または QUIC
IP
Ethernet / Wi-Fi / モバイル通信

通信エラーが起きた場合、原因はHTTPレベルとは限りません。

例えば、次のような問題が考えられます。

DNSの失敗
TLS証明書の問題
TCP接続の失敗
HTTPステータスエラー
API側の認証エラー
ネットワーク遅延
パケットロス

パケットフォーマットや通信階層を理解していると、問題の切り分けがしやすくなります。

セキュリティ理解にも役立つ

パケットフォーマットを理解すると、セキュリティの基礎も分かりやすくなります。

例えば、次のようなテーマと関係します。

ファイアウォール
WAF
DDoS攻撃
SYN flood
IPスプーフィング
ポートスキャン
TLS暗号化
パケットフィルタリング
Bot対策

ファイアウォールは、IPアドレス、ポート番号、プロトコル種別などをもとに通信を制御します。

WAFは、HTTPリクエストの内容を見て攻撃らしい通信を検出します。

この違いを理解するうえでも、どの層にどのような情報があるのかを知ることは重要です。

パケットフォーマットを理解するポイント

まずはヘッダーとペイロードを押さえる

パケットフォーマットを理解するうえで、最初に押さえるべきなのは次の2つです。

ヘッダー   = 通信制御のための情報
ペイロード = 実際に運びたいデータ

プロトコルによってフィールド名やサイズは違いますが、基本的な考え方は共通しています。

どの層の話かを意識する

同じ「データ」でも、どの層から見るかによって呼び方や意味が変わります。

例えば、HTTPのデータは、TLSから見ると暗号化対象のデータであり、TCPから見るとTLSレコードの一部であり、IPから見るとTCPセグメントの一部です。

そのため、パケットフォーマットを読むときは、次のように考えると理解しやすくなります。

今見ているのはEthernetの話か
IPの話か
TCP/UDPの話か
TLSの話か
HTTPの話か

代表的なフォーマットから学ぶ

最初からすべてのプロトコルを理解する必要はありません。

まずは、次の代表的なフォーマットを押さえるとよいです。

Ethernetフレーム
IPv4パケット
IPv6パケット
TCPセグメント
UDPデータグラム
TLSレコード
HTTPメッセージ
DNSメッセージ

このあたりを理解すると、ネットワーク通信全体の見通しがかなり良くなります。

まとめ

パケットフォーマットとは、ネットワーク上で送受信されるデータの構造や並び方を定めたルールです。

パケットには、実際に送りたいデータだけでなく、送信元、宛先、プロトコル種別、データ長、順序、エラー確認などの制御情報が含まれます。

基本的な構造は、ヘッダーとペイロードです。プロトコルによっては、末尾にトレーラーが付く場合もあります。

代表的な例としては、Ethernetフレーム、IPv4パケット、IPv6パケット、TCPセグメント、UDPデータグラムなどがあります。

また、通信ではHTTP、TLS、TCPまたはUDP、IP、EthernetやWi-Fiといった複数の層が組み合わされます。

このように、上位層のデータを下位層のプロトコルで包む仕組みをカプセル化と呼びます。

パケットフォーマットを理解すると、ネットワーク障害の切り分け、Web表示速度の改善、セキュリティ対策、API通信、広告タグや計測タグの通信理解にも役立ちます。

最初に覚えるべきポイントは、次の3つです。

ヘッダー   = 通信に必要な制御情報
ペイロード = 実際に運びたいデータ
フォーマット = それらをどう並べるかのルール

つまり、パケットフォーマットとは、通信データを送信側と受信側が同じ意味で扱うための「共通の設計図」です。

以上、パケットフォーマットとはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。