0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@saluton

【完全保存版】L2〜L7重要ヘッダー完全攻略！フィールド構造から実効スループット計算まで網羅辞典

0
Last updated at Posted at 2026-05-15

🌐 ネットワークのヘッダーサイズには設計思想が詰まっている。応用情報で差がつくL2〜L7プロトコル徹底解説

応用情報技術者試験（AP）の午前・午後試験において、ネットワーク分野の大きな得点源となる各階層（L2〜L7）の重要ヘッダーを網羅的に解説します。

各フィールドの役割、階層間の違い、カプセル化の流れ、そして具体的な使用状況や頻出の計算問題テクニックまで、試験に必要な知識を凝縮しました。

📌 本記事の学習ポイント

  • 各階層のプロトコルが持つヘッダーの「役割」と「サイズ（バイト数）」を正確に一致させる。
  • カプセル化・非カプセル化のプロセスにおけるデータの変化をイメージできるようにする。
  • 午後試験の記述対策として、暗号化範囲やプロトコルの具体的な使用状況（挙動）を押さえる。

🎯 午後試験（記述式）の出題傾向と攻略のロードマップ

応用情報技術者試験（AP）の午後試験において、「ネットワーク」や「情報セキュリティ」は毎年多くの受験生が選択する超重要分野です。しかし、単に午前向けの選択肢知識を暗記しているだけでは、記述式の壁を突破することは困難です。

午後試験では、仮想の事例を基にした長文問題が出題されます。ここでは各ヘッダーの構造が机上の空論ではなく、**「実際の通信トラフィックやセキュリティ障害の現場でどのように機能しているか」**が鋭く問われます。特に近年の午後試験では、以下の3つの切り口が合否を分けるトレンドとなっています。

  • 📊 ネットワークの性能評価（計算問題）：
    単純な回線速度だけでなく、各階層のヘッダー（L2〜L4）がもたらすオーバーヘッドを正確に計算し、システムの実効スループットやバッファ容量の見積もりを算出させる問題が頻出します。
  • 🔒 セキュリティプロトコルの挙動解析：
    「IPsec（ESP）の導入によってパケット構造がどう変化し、どこまでが暗号化されるのか」「TLS 1.3のハンドシェイクがどう高速化に寄与しているか」など、パケットの内部構成をトレースする力が求められます。
  • 🌐 アプリケーション層（HTTP/DNS）の脆弱性対策：
    クッキー（Cookie）のSecure属性やHttpOnly属性を用いたセッションハイジャック対策、DNSヘッダーの識別子（Transaction ID）のランダム化によるキャッシュポイズニング防御策など、ヘッダー内の特定フィールドを操作した具体的なセキュリティ実装が記述問題の主役となります。

💡 本文を読む前のアドバイス：
これより解説する各プロトコルのヘッダー構造を学ぶ際は、「何バイトなのか（サイズ）」「何のためにそのフィールドが存在するのか（目的）」を常に午後試験の事例と結びつけながら読み進めてください。

1. イーサネットヘッダー（L2：データリンク層）

MACアドレスを用いて、同一ネットワーク（同一セグメント）内の隣接機器間でフレームを運ぶためのヘッダーです。

📂 重要フィールド

  • 宛先MACアドレス（6バイト）： 次にフレームを受け取る機器の物理アドレス。
  • 送信元MACアドレス（6バイト）： フレームを送り出した機器の物理アドレス。
  • タイプ / 長さ（2バイト）： 上位層のプロトコルを指定。IPv4（0x0800）、IPv6（0x86DD）、ARP（0x0806）などの識別番号が入ります。

⚠️ 特徴・注意点＆具体的な使用状況

  • アドレスの書き換え： ルーターを越える（ルーティングされる）たびに、ヘッダー内の送信元・宛先MACアドレスは、次のホップの機器のものへと順次書き換えられます。
  • エラーチェック： フレームの末尾には、誤り検出用の**FCS（Frame Check Sequence：4バイト）**が必ず付加されます。
  • 使用状況： 自端末から同一LAN内にあるデフォルトゲートウェイ（ルーター）のインターフェースへデータを届ける際、L2フレームとしてカプセル化する局面で使用されます。

2. IPヘッダー（L3：ネットワーク層）

IPアドレスを用いて、異なるネットワーク間をまたぐ**エンドツーエンド（最終目的地まで）の通信（ルーティング）**を実現するヘッダーです。

🔹 IPv4ヘッダーの重要フィールド（最小20バイト）

  • バージョン（4ビット）： IPv4を示す数値「4」が格納されます。
  • ヘッダー長（4ビット）： ヘッダー全体の長さを表します（オプションがない通常時は20バイト）。
  • プロトコル（1バイト）： 上位層のプロトコルを指定します。ICMP（1）、TCP（6）、UDP（17）、ESP（50）、AH（51）など、試験で直接狙われる数値です。
  • 送信元 / 宛先IPアドレス（各4バイト / 計8バイト）： 最終的な通信相手の32ビットIPアドレス。NAT/NAPT環境を通過する場合を除き、ルーターを越えても原則として書き換えられません。
  • TTL（Time To Live / 1バイト）： パケットの生存時間。ルーターを通過（ホップ）するたびに1ずつ減算され、0になるとパケットは破棄されます。これにより、経路のループによるパケットの永久徘徊を防止します。
  • 識別子・フラグ・フラグメントオフセット： 送信経路のMTU（最大転送単位）を超えたパケットを分割（断片化：フラグメンテーション）し、受信側で正しく再組み立てを行うために使用される連動フィールドです。

🔹 IPv6ヘッダーの特徴（IPv4との違い：固定40バイト）

  • アドレス長の拡大： 32ビットから128ビット（16バイト）×2（送信元/宛先）へと大幅に拡張されました。
  • ヘッダーの固定長化： 基本ヘッダーが40バイト固定となり、ルーターでのハードウェア処理が高速化されました。
  • フィールドの整理・名称変更： IPv4の「プロトコル」は**「ネクストヘッダー」に、「TTL」は「ホップリミット」**に名称変更されました。また、ルーターの処理負荷を軽減するため、不要なチェックサムや、断片化に関するフィールドが基本ヘッダーから削除（必要な場合は拡張ヘッダーへ移行）されました。

🛠️ 具体的な使用状況

PCからインターネット上のWebサーバーへリクエストを送る際、宛先IPアドレスにサーバーのパブリックIPを設定し、世界中のルーターに経路制御（ルーティング）してもらう局面で使用されます。

3. TCPヘッダー ＆ UDPヘッダー（L4：トランスポート層）

通信を行うアプリケーション（プロセス）を識別する**「ポート番号」**を持ちます。信頼性を最優先するか、転送速度・リアルタイム性を最優先するかで構造が完全に異なります。

🔒 TCPヘッダー（信頼性重視・コネクション型・最小20バイト）

確実なデータ転送（順序制御や再送制御）を行うため、制御用フィールドが多くヘッダー長は重くなります。

  • 送信元 / 宛先ポート番号（各2バイト）： 通信プロセスを識別（HTTP: 80、HTTPS: 443、DNS: 53など）。
  • シーケンス番号（4バイト）： 送信するデータのストリーム上の位置（順序）を表す番号。データの並び替えや欠落検知の基準となります。
  • 確認応答番号（ACK番号 / 4バイト）： 受信側が「次に受信したいデータのシーケンス番号」を送信側に通知し、データの到達を証明します。
  • コントロールフラグ（6ビット）： 通信の状態を制御する重要なビット群です（AP午前・午後ともに超頻出）。
    • SYN： 接続要求（コネクション確立の開始）
    • ACK： 確認応答（データの受信や接続・切断の承認）
    • FIN： 切断要求（コネクションの正常終了）
    • RST： 強制切断（異常リセット）
  • ウィンドウサイズ（2バイト）： 受信側が現在一度に受け入れられるデータバッファの残量を相手に伝え、溢れを防ぐ「フロー制御」を行います。

⚡ UDPヘッダー（速度・リアルタイム性重視・コネクションレス型・固定8バイト）

オーバーヘッドを徹底的に減らすため、機能は最小限に絞り込まれています。

  • 送信元ポート番号（2バイト） / 宛先ポート番号（2バイト）
  • データ長（2バイト）： ヘッダーとデータを合わせた、UDPセグメント全体の長さを表します。
  • チェックサム（2バイト）： データの破損がないかを確認するエラー検知用（IPv4では任意、IPv6では必須）。
  • 特徴： シーケンス番号や確認応答の仕組みを持たないため、パケットが途中で紛失しても再送制御は行いません（上位のアプリケーション層で必要に応じて制御します）。

🛠️ 具体的な使用状況

  • TCPの使用状況： Webサイトの閲覧（HTTP/HTTPS）やファイルの転送（FTP）、メールの送受信（SMTP/POP3）など、1ビットの欠損も許されない正確な通信を行う場合。
  • UDPの使用状況： IP電話（VoIP）や動画のライブ配信、DNSの名前解決、音声・映像のリアルタイム双方向通信など、多少のデータ欠落よりも遅延の少なさが求められる場合。

4. IPsecヘッダー：ESP ＆ AH（L3.5：セキュリティ層）

IPパケットの暗号化や改ざん検知（認証）を行うプロトコルです。AP試験では**「暗号化の有無」と「パケット構造の違い」**が鋭く問われます。

🛡️ AH（Authentication Header：認証ヘッダー）

  • 機能・特徴： データの「改ざん検知（認証）」と「送信元の本人の確認」のみを提供します。
  • 暗号化： 一切行いません。 データ（ペイロード）は平文のままで、丸見えの状態です。
  • 構造と課題： 元のIPヘッダーとTCP/UDPヘッダーの間に挿入されます。元のIPヘッダー自体も認証の範囲に含めて計算するため、途中のルーターでIPアドレスが書き換えられるNAT/NAPT環境を通過することができません。

🔐 ESP（Encapsulating Security Payload：暗号ペイロード）

  • 機能・特徴： 「暗号化（機密性保持）」に加えて、「改ざん検知（認証）」「リプレイ攻撃防止」のすべてをフルパッケージで提供します。
  • 構造： 対象となるデータ部分の前に「ESPヘッダー」を置き、後ろに「ESPトレーラ」と「ESP認証データ」を配置して、データをサンドイッチのように挟み込みます。
  • 暗号化： TCP/UDPなどの上位データ（トランスポートモード時）、または元のIPヘッダーを含むパケット全体（トンネルモード時）を完全に暗号化し、盗聴から保護します。

🛠️ 具体的な使用状況

企業の拠点間をインターネット経由で安全に接続する「インターネットVPN（IPsec-VPN）」を構築し、社内の機密データを暗号化して通信させる局面でESPが広く使用されます。

5. DNS・ICMP・TLS・ARPヘッダー（午前・午後単独出題領域）

試験において、単独のテーマとして深く掘り下げられやすい重要なプロトコル群です。

🔎 DNSヘッダー（L7：アプリケーション層・固定12バイト）

DNSは通常、高速性を重視してUDPポート53（※サイズ超越時やゾーン転送時はTCPポート53）を利用します。固定12バイトの後に可変長のメッセージが続きます。

  • 識別子（Transaction ID / 2バイト）： 問い合わせ（リクエスト）と応答（レスポンス）を正しく紐付けるためのランダムな値。DNSキャッシュポイズニング対策のキーパーツです。
  • フラグ（2バイト）： 通信の性質を示すビット群。
    • QR（1ビット）： 0なら問い合わせ、1なら応答。
    • AA（1ビット）： 応答したサーバーが、そのドメインの管理権限を持つ「権威DNSサーバー」であることを示す。
    • RD（1ビット）： 再帰的問い合わせ（自身のキャッシュになくても、他のサーバーに繰り返し聞いて答えを探すこと）を要求するフラグ。
  • 質問数 / 回答数 / 権威リソースレコード数 / 追加リソースレコード数（各2バイト）： 後続するデータセクションに、レコードがそれぞれいくつ含まれているかを示します。

🛠️ ICMPヘッダー（L3：ネットワーク層・最低4バイト）

IP通信において発生したエラーの通知や、ネットワークの状態診断を行うためのプロトコルです。IPヘッダーの直後に配置されます。

  • タイプ（Type / 1バイト）： メッセージの「大分類」を示します。
    • 0： エコー応答（Echo Reply） $\rightarrow$ pingの返答
    • 8： エコー要求（Echo Request） $\rightarrow$ pingの送信
    • 3： 宛先到達不能（Destination Unreachable） $\rightarrow$ ルート未存在や遮断時
    • 11： 時間超過（Time Exceeded） $\rightarrow$ IPヘッダーのTTLが0になった際（tracerouteコマンドで経路上のルーターを特定する仕組みに利用）
  • コード（Code / 1バイト）： タイプをさらに細分化した「詳細理由」を示します（例：タイプ3かつコード1＝ホスト到達不能、コード3＝ポート到達不能）。
  • チェックサム（2バイト）： エラー検知用。

🔑 TLSヘッダー（L4.5：セッション〜プレゼンテーション層・5バイト）

HTTPS通信（ポート443）の内部などでデータを暗号化する際、TCPの直上で「TLSレコードプロトコル」として機能します。

  • コンテンツタイプ（1バイト）： 流れているデータの種類を識別。
    • 22 (Handshake)： 鍵交換や暗号アルゴリズムの選定・決定を行う接続フェーズ。
    • 21 (Alert)： エラーや接続切断の通知。
    • 23 (Application Data)： 実際に暗号化されたHTTPなどのメインデータ。
  • バージョン（2バイト）： TLSのバージョン（TLS 1.2は0x0303、TLS 1.3は0x0304）。
  • 長さ（2バイト）： 後続するデータの純粋なバイト数。
  • 特徴（TLS 1.3）： 最新のTLS 1.3では、最初のHandshakeの段階から可能な限り早期に暗号化を開始し、通信を往復1回（1-RTT）で確立する高速化が図られています。

🏷️ ARPヘッダー（L2/L3境界：データリンク層・固定28バイト ※IPv4時）

IPアドレスの情報を元に、対応する通信相手の「MACアドレス」を動的に導出するためのプロトコルです。IPパケットにはカプセル化されず、イーサネットフレームにダイレクトに格納（タイプ値：0x0806）されます。

  • ハードウェアタイプ（2バイト）： ネットワークの規格。イーサネットは「1」。
  • プロトコルタイプ（2バイト）： 対象とする L3 プロトコル。IPv4は0x0800。
  • オペレーション（Opcode / 2バイト）： 1なら「ARP要求（Request）」、2なら「ARP応答（Reply）」。
  • 送信元MAC（6B）/ 送信元IP（4B）/ 宛先MAC（6B）/ 宛先IP（4B）：
    • 具体的な使用状況（ARP要求時）： 通信相手のMACアドレスが不明なため、このフィールド内の宛先MACは「00:00:00:00:00:00」の空欄にします。その代わり、外側のL2イーサネットヘッダーの宛先MACを**ブロードキャストアドレス（FF:FF:FF:FF:FF:FF）**に設定して、LAN内の全機器へ同時に問いかけます。

6. HTTPヘッダー（L7：アプリケーション層）

Webブラウザ（クライアント）とWebサーバー間で、リクエストおよびレスポンスに付随する制御用の付加情報を、テキスト形式（キー: 値）でやり取りするヘッダーです。

📋 AP試験で覚えるべき最重要HTTPヘッダー一覧

ヘッダー名 種類 概要・AP試験での決定的なポイント
Host リクエスト 接続先のホスト名（ドメイン）を指定。1つのIPアドレスで複数の異なるWebサイトを並行運用する**「バーチャルホスト」**の実現に絶対不可欠。
User-Agent リクエスト アクセスしてきたブラウザの種類、バージョン、OSの情報を通知。サーバー側でPC用・スマホ用の表示ページを動的に切り替えるトリガーに利用。
Location レスポンス ブラウザに対して、別の転送先URLへ移動するよう指示。ステータスコード 301（恒久的移動） / 302（一時的移動） によるリダイレクト処理時に必須。
Set-Cookie レスポンス サーバーからクライアントへ、状態管理用のセッションIDなどのクッキー情報をローカルに保存させる命令。セキュリティ属性（Secure, HttpOnly, SameSite）が午後試験の脆弱性対策で非常に狙われやすい。
Cookie リクエスト Set-Cookieによってブラウザに保存されたクッキー情報を、次回以降のアクセス時にサーバーへ自動送信。Webのステートレスな性質を補い、**セッション維持（ログイン状態のキープ）**に使用。
Authorization リクエスト ベーシック認証（基本認証）等において、IDとパスワードをコロンで繋ぎ、Base64でエンコードした文字列をサーバーに送信して認証を受ける際に使用。
Cache-Control 共通 キャッシュの有効期限や可否（no-store: キャッシュ禁止、no-cache: 再確認義務、max-age=秒: 有効期限）を厳密に制御。
Content-Type 共通 送受信するメッセージボディのデータ形式（text/html, application/json, image/png など）を指定し、ブラウザに正しくレンダリングさせる。

7. 試験の山場：スループット・オーバーヘッド計算問題の解法テクニック

午前試験の計算問題、および午後試験のネットワーク構築評価で確実に得点するための、ヘッダーサイズを用いた計算テクニックです。

📐 暗記必須の固定長サイズ一覧

  • イーサネットヘッダー： 14バイト（末尾のFCS 4バイトを合わせると計18バイト）
  • IPv4ヘッダー： 20バイト（オプションなしの場合）
  • IPv6ヘッダー： 40バイト（固定長）
  • TCPヘッダー： 20バイト（オプションなしの場合）
  • UDPヘッダー： 8バイト（固定長）
  • DNSヘッダー： 12バイト（固定部分）

:::⚠️ 計算問題での注意トラップ：物理層の要素
「回線占有時間」や「物理層レベルでの実効転送速度」を計算させる問題に限り、イーサネットフレーム自体のサイズに加え、物理層で付加される**プリアンブル（8バイト）およびフレーム間の無通信時間であるインターフレームギャップ（IFG：12バイト）**の計20バイトをパケットごとに加算する必要があります。問題文の指示を極めて慎重に読み取ってください。

💡 典型問題の思考プロセスと解法

【例題】
100 MbpsのLAN環境で、IPv4・TCP・HTTPを使い、1パケットあたり1,460バイトのアプリケーションデータを連続送信する。回線の最大実効スループット（アプリデータの純粋な転送速度）は何Mbpsになるか。ただし、イーサネットH=14B、FCS=4B、プリアンブル=8B、IFG=12Bとし、オプションHおよびACKによる遅延は考慮しない。

ステップ1：1パケットが消費するトータルの「物理サイズ」を算出

  アプリデータ長：1,460 バイト
＋ TCPヘッダー   ：   20 バイト
＋ IPヘッダー    ：   20 バイト
＋ イーサネット  ：   18 バイト（14B + FCS 4B）
＋ 物理層余白    ：   20 バイト（プリアンブル 8B + IFG 12B）
─────────────────────────────────────────────
合計物理サイズ   ：1,538 バイト

ステップ2：純粋なアプリデータの「データ効率（有効比率）」を算出

回線に流れるすべてのデータのうち、何割が目的のデータかを求めます。

$$ \text{データ効率} = \frac{1,460 \text{ バイト}}{1,538 \text{ バイト}} $$

ステップ3：回線速度にデータ効率を掛け算してフィニッシュ

$$ \text{実効スループット} = 100 \text{ Mbps} \times \left( \frac{1,460}{1,538} \right) \approx 94.92 \text{ Mbps} $$

解答：約 94.9 Mbps

💡 試験テクニック：MTUとMSSの自動リンク
問題文に「MTU（Maximum Transmission Unit）が1,500バイトのイーサネット環境において、TCPで最大のデータサイズを送信する」とだけ書かれており、アプリデータのサイズが明記されていないケースがあります。この場合、

$$ \text{MSS（最大セグメントサイズ）} = \text{MTU (1,500B)} - \text{IPヘッダー (20B)} - \text{TCPヘッダー (20B)} = 1,460 \text{ バイト} $$

という関係式を思い出し、アプリデータサイズを自動的に1,460バイトと見抜いて計算を開始してください。

📝 まとめ：応用情報技術者試験に向けた最終要点チェック

  • カプセル化の方向： 送信時は「L7（HTTP） $\rightarrow$ L4（TCP/UDP） $\rightarrow$ L3（IP） $\rightarrow$ L2（イーサネット）」の順に外側へヘッダーが包まれていく。受信時は逆順に剥がされる。
  • アドレスの挙動： ルーターを越える時、L3のIPアドレスは「変わらない」が、L2のMACアドレスは「ホップごとに次々と書き換えられる」。
  • TCP vs UDP： 確実な制御を行うTCPは最小20バイト、速度を追及するUDPはわずか8バイト。SYN/ACK/FINフラグはTCPだけの特権。
  • IPsecのESP： データをESPヘッダーとトレーラで挟み込み、データを完全に暗号化する。AHは暗号化を行わず認証のみ。
  • スループット計算： 各ヘッダーのバイト数（14, 20, 20）を確実に暗記し、問題文に「プリアンブル」「IFG」の指示がある場合は必ず物理サイズに足し算して比率を出す。

☕ あとがき：点と点に「背景」が結びついたとき、ネットワークは武器になる

お疲れ様でした！L2のイーサネットフレームからL7のHTTPメッセージまで、応用情報技術者試験（AP）で合格ラインを超えるために必要なヘッダー知識を網羅的に駆け抜けました。

一見すると、無機質なバイト数やビットフラグの羅列に思えるかもしれません。しかし、これらのヘッダー構造にはすべて**「インターネットを破綻させず、安全かつ高速にデータを届ける」**という、開発者たちの血の滲むような試行錯誤の歴史と背景（プロトコルの設計思想）が詰まっています。

応用情報試験の午後問題が素晴らしいのは、まさにその「設計思想」や「周辺知識」をシナリオ形式で突いてくる点にあります。

  • 「なぜIPv6ではチェックサムが廃止されたのか？」
    $\rightarrow$ 背景：L2やL4のエラー検知能力が向上したため、L3での二重チェックを省いてルーターの負荷を減らしたかったから。
  • 「なぜTCPの3ウェイハンドシェイクで初期シーケンス番号はランダムなのか？」
    $\rightarrow$ 背景：固定値や予測可能な値にすると、悪意ある第三者に通信を乗っ取り（セッションハイジャック）されるリスクがあるから。
  • 「なぜDNSは53番ポートなのか？」
    $\rightarrow$ 背景：かつては軽量なUDPでの名前解決が主流だったため。しかし、現代ではDNSSECや暗号化DNS（DoH/DoT）の普及といった「セキュリティ強化の背景」から、TCP併用や別ポートへの拡張という歴史の転換点を迎えている。

試験本番で初見の応用問題や複雑なネットワーク構成図に出会ったときは、ぜひ一歩引いて、このヘッダーたちの役割を思い出してください。**「このルーターはIPヘッダーのどこを見ているだろう？」「このファイアウォールはTCPのどのフラグを監視しているだろう？」**という視点を持つだけで、問題文に隠されたヒントが驚くほどクリアに見えてくるはずです。

📢 最後に一言：
午前試験の暗記を「点」とするならば、午後試験の長文読解はそれらを繋ぐ「線」であり、この記事で学んだ背景知識こそが全体を立体的に捉えるための「空間」となります。インフラからアプリケーションまでを論理的に見通せる本物のITエンジニアを目指して、この調子で合格を掴み取りましょう！応援しています！

📖 応用情報必須：登場した重要ネットワーク用語・フィールド完全網羅辞典

本記事（前文・本文・あとがき）に登場したすべての重要キーワードおよびヘッダー内の各フィールドについて、試験で問われる定義や役割を1つずつ徹底解説したアルファベット・階層順の網羅リストです。午後試験の記述対策として、正確な用語定義のチェックにご活用ください。

🔷 L2：データリンク層 / 物理層 関連用語

  • イーサネットヘッダー (Ethernet Header)
    L2（データリンク層）で付加される、同一セグメント内の機器間でフレームを配送するための制御情報。送信元/宛先MACアドレスや上位プロトコルを示すタイプフィールドで構成される。
  • MACアドレス (Media Access Control Address)
    ネットワーク機器のネットワークカード（NIC）に製造時に割り当てられる、全世界で一意の48ビット（6バイト）の物理アドレス。
  • タイプ / 長さ (Type / Length)
    イーサネットヘッダー内の2バイトのフィールド。フレームのデータ部分にカプセル化されている上位層（L3）のプロトコル（IPv4、IPv6、ARPなど）を識別するために使用される。
  • FCS (Frame Check Sequence)
    イーサネットフレームの末尾に付加される4バイトのエラー検出用フィールド。CRC（巡回冗長検査）というアルゴリズムを用いて、通信途中にフレームが破損（ビットエラー）していないかをチェックする。
  • プリアンブル (Preamble)
    物理層のレベルで、イーサネットフレームの送信直前に付加される8バイトの同期用信号。受信側に「これからフレームが始まります」と通知し、ビット同期を確立させる。スループット計算問題で考慮を求められることがある。
  • インターフレームギャップ (IFG：Inter-Frame Gap)
    連続するイーサネットフレームの間に設けなければならない、12バイト分に相当する最小限の無通信時間（静止時間）。ネットワーク機器が受信処理を終え、次のフレームに備えるために必要となる。
  • ARP (Address Resolution Protocol)
    IPアドレス（L3の論理アドレス）から、対応する機器のMACアドレス（L2の物理アドレス）を動的に割り出すためのプロトコル。
  • ARP要求 / ARP応答 (ARP Request / ARP Reply)
    MACアドレスを尋ねるための「要求」はLAN内全体へのブロードキャスト（一斉放送）で行われ、該当するIPアドレスを持つ端末が自らのMACアドレスを「応答」としてユニキャスト（単独通信）で返却する。
  • オペレーション (Opcode：Operation Code)
    ARPヘッダー内の2バイトのフィールド。その ARP パケットが「1：ARP要求（Request）」なのか「2：ARP応答（Reply）」なのかを識別する。
  • ブロードキャストアドレス (Broadcast Address)
    同一LAN内のすべての機器に対して、データを同時に一斉送信するために使用される特殊なアドレス。L2ではすべてのビットが「1」の FF:FF:FF:FF:FF:FF となる。

🔶 L3：ネットワーク層 関連用語

  • IPヘッダー (IP Header)
    L3（ネットワーク層）で付加される、異なるネットワーク間でのエンドツーエンド通信（ルーティング）を実現するための制御情報。
  • IPアドレス (Internet Protocol Address)
    ネットワーク上の機器を識別するために割り当てられる論理アドレス。IPv4は32ビット（4バイト）、IPv6は128ビット（16バイト）の長さを有する。
  • プロトコル (Protocol フィールド)
    IPv4ヘッダー内の1バイトのフィールド。IPパケットのデータ部分に格納されている上位層（L4）のプロトコル番号（TCP:6、UDP:17、ICMP:1など）を指定する。
  • ネクストヘッダー (Next Header)
    IPv6ヘッダーにおいて、IPv4の「プロトコル」フィールドに相当するもの。基本ヘッダーの次に続く拡張ヘッダーや、L4プロトコルの種類を指定する。
  • TTL (Time To Live) / ホップリミット (Hop Limit)
    パケットがネットワーク内で永久にループするのを防ぐための生存カウンタ。ルーターを1台通過（ホップ）するたびに1ずつ減算され、0になるとパケットは強制的に破棄される。IPv6では「ホップリミット」に名称変更。
  • 断片化 (フラグメンテーション：Fragmentation)
    送信経路のMTU（最大転送単位）よりも大きいIPパケットを、ルーターや送信元端末が細かく分割する処理。IPv4ヘッダー内の「識別子」「フラグ」「フラグメントオフセット」はこの再組み立てのために連動する。
  • MTU (Maximum Transmission Unit)
    ノードが1回の通信で送信できるL3パケット（IPパケット）の最大バイト数。通常のイーサネット環境では「1500バイト」が標準値となる。
  • ICMP (Internet Control Message Protocol)
    IP通信において発生したエラーの通知や、ネットワークの診断情報（疎通確認など）をやり取りするためのプロトコル。pingやtracerouteの基盤となる。
  • タイプ / コード (Type / Code)
    ICMPヘッダー内のフィールド。タイプ（1バイト）でメッセージの「大分類（0:応答、8:要求、3:到達不能、11:時間超過など）」を示し、コード（1バイト）でその「詳細な理由」を表す。

🔶 L4：トランスポート層 関連用語

  • ポート番号 (Port Number)
    L4（トランスポート層）で用いられる、通信を行うアプリケーション（プロセス）を識別するための16ビット（2バイト）の識別番号（例: HTTPは80、HTTPSは443）。
  • TCPヘッダー (TCP Header)
    信頼性を担保したコネクション型通信を行うための、最小 20 バイトのヘッダー。シーケンス番号や確認応答番号、各種制御用のビットフラグを持つ。
  • シーケンス番号 (Sequence Number)
    TCPヘッダー内の4バイトのフィールド。送信するデータストリームが、全体のどの位置（何バイト目）から始まっているかを示す。データの抜け漏れ検知や、到着順序の並び替えに使用される。
  • 確認応答番号 (ACK番号：Acknowledgment Number)
    TCPヘッダー内の4バイトのフィールド。データを受信した側が送信側に対して、「ここまでのデータは無事に届いたので、次は○バイト目のデータを送ってください」と要求・通知するための番号。
  • コントロールフラグ (Control Flags)
    TCPヘッダー内の6ビットの領域。通信の状態（コネクションの確立、維持、切断など）を制御するビット群（SYN, ACK, FIN, RSTなど）が配置されている。
  • SYN / ACK / FIN / RST
    TCPの接続・切断制御ビット。SYNは接続要求、ACKは確認応答、FINは正常な切断要求、RSTは通信エラー等による強制リセットを表す。
  • ウィンドウサイズ (Window Size)
    TCPヘッダー内の2バイトのフィールド。受信側が現在受け入れ可能なデータバッファの空き容量（残りバイト数）を送信側に通知し、送信量を調整させる「フロー制御」に用いられる。
  • MSS (Maximum Segment Size)
    TCPにおいて、IP/TCPヘッダー等を除いた「純粋なアプリケーションデータ（ペイロード）」の1パケットあたりの最大バイト数。通常は「MTU － 40バイト」で算出される。
  • UDPヘッダー (UDP Header)
    リアルタイム性や速度を最優先したコネクションレス型通信を行うための、わずか8バイト（固定長）の軽量ヘッダー。
  • 3ウェイハンドシェイク (3-way Handshake)
    TCP通信を開始する前に、端末間で確実に通信が可能かを確認し、初期のシーケンス番号を交換し合ってコネクションを確立する3往復のプロセス（SYN $\rightarrow$ SYN+ACK $\rightarrow$ ACK）。
  • 初期シーケンス番号 (ISN：Initial Sequence Number)
    3ウェイハンドシェイクの最初に、各端末が独自に生成するシーケンス番号の初期値。セッションハイジャック（通信乗っ取り）を防ぐため、現代のOSでは推測不可能なランダムな値が生成される。

🔶 L3.5〜L4.5：セキュリティ / トンネリング 関連用語

  • IPsec (Security Architecture for Internet Protocol)
    L3（ネットワーク層）レベルでIPパケットの暗号化や改ざん検知、認証を行い、安全な仮想専用線（VPN）を構築するためのプロトコル群。
  • AH (Authentication Header)
    IPsecを構成するプロトコルの1つ。データの完全性（改ざん検知）と送信元認証を提供するが、データの暗号化は一切行わない。元のIPヘッダーまで認証範囲に含めるため、NAT/NAPTと競合し通過できない。
  • ESP (Encapsulating Security Payload)
    IPsecを構成するプロトコルの1つ。機密性（暗号化）、完全性（改ざん検知）、送信元認証をすべて提供する。データをESPヘッダーとESPトレーラでカプセル化（サンドイッチ）して暗号をかける。
  • トランスポートモード / トンネルモード
    IPsecの動作モード。トランスポートモードは元のIPヘッダーを残し、データ（ペイロード）のみを保護する（端末間通信用）。トンネルモードは元のIPパケットを丸ごと暗号化し、その前に新しいIPヘッダーを付与する（拠点間のVPNルーター通信用）。
  • TLSヘッダー (TLS Header / レコードプロトコル)
    L4のTCPの直上でデータを安全にカプセル化・暗号化する、5バイトのヘッダー。「コンテンツタイプ（データの種類）」「バージョン」「長さ」で構成される。
  • TLS 1.3
    TLSプロトコルの最新バージョン。従来のTLS 1.2に比べて、接続確立（ハンドシェイク）にかかる往復回数を1回（1-RTT）へと半減させ、暗号化アルゴリズムを強力なものに限定することで高速化と安全性を両立している。

🔶 L7：アプリケーション層 関連用語

  • HTTPヘッダー (HTTP Header)
    L7（アプリケーション層）において、WebブラウザとWebサーバー間で、リクエストやレスポンスに付随する制御メタ情報をテキスト形式（キー：値）で伝えるためのヘッダー。
  • Host へッダー
    HTTPリクエストヘッダーの1つ。クライアントがアクセスしようとしているWebサーバーのホスト名（ドメイン名）を指定する。1つのIPアドレスで複数のサイトを同居させる「バーチャルホスト」の実現に必須。
  • User-Agent ヘッダー
    HTTPリクエストヘッダーの1つ。アクセスしてきたブラウザの種類やバージョン、OSの情報をサーバーに伝える。デバイスに応じたWebページの出し分け等に利用される。
  • Location ヘッダー
    HTTPレスポンスヘッダーの1つ。ブラウザに対し、「このURLへ転送（リダイレクト）してください」と指示を出すために、ステータスコード301や302と共に返却される。
  • Set-Cookie / Cookie ヘッダー
    状態管理を持たないHTTP（ステートレス）においてセッションを維持するための仕組み。サーバーがクライアントへ保存を命じるのがSet-Cookie、保存された値を次回以降のアクセス時にクライアントからサーバーへ自動送信するのがCookie。
  • Secure / HttpOnly / SameSite 属性
    クッキーの安全性を高めるための属性。Secure属性はHTTPS通信（暗号化）時のみクッキー送信を許可し、HttpOnly属性はJavaScriptからのアクセスを禁止してXSSによるクッキー盗聴を防ぐ。SameSite属性はクロスサイト（別サイト経由）でのクッキー送信を制限しCSRF攻撃を防ぐ。
  • Authorization ヘッダー
    HTTPリクエストヘッダーの1つ。ベーシック認証（基本認証）等において、IDとパスワードをコロンで繋ぎ、Base64でエンコードした文字列をサーバーに送信して認証を受ける際に使用する。

🔗 参考サイト・関連リンク（Web References）

本記事の実効スループット計算の解説およびプロトコル構造の整理にあたり、以下の信頼性の高いWebリソースを参考にしています。さらに深く学習したい方は、ぜひこれらのリンク先も併せてご参照ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?