【テクニカル・上級編】 802.1QフレームのPCP（Priority Code Point）フィールドの振る舞い – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

802.1QのPCPが支配するL2の秩序：TLSハンドシェイクと遅延削減の極限最適化

ネットワークエンジニアの端くれであれば、L2スイッチの背後で繰り広げられるパケットの泥臭い生存競争に一度は魅入られたことがあるはずだ。数千円の安価なスイッチから、ラックの底で唸るハイエンドなデータセンター向けシャーシ型スイッチに至まで、すべての機器が毎秒数千万のフレームを処理している。

その膨大なトラフィックの濁流の中で、どのパケットが優遇され、どのパケットがベストエフォートの海に沈められるかを決定づけている隠れた主役がいる。それがIEEE 802.1QヘッダーのTCI（Tag Control Information）に潜む、わずか3ビットのフィールド、PCP（Priority Code Point）だ。

今回は、このPCPがレイヤー2の世界でどのようにパケットの運命を左右し、さらに上位層のトランスポート最適化やTLSハンドシェイクのレイテンシー削減にどう寄与するのか、その深淵を覗いていこう。

—

1. 802.1Qフレーム構造とPCPの物理的振る舞い

通常のイーサネットフレームに、VLAN IDと共に追加される4バイトの802.1Qタグ。その内訳を思い出してほしい。TPID（Tag Protocol Identifier: 0x8100）に続く16ビットのTCIは、次のような構造をしている。

PCP（Priority Code Point）: 上位3ビット（値: 0〜7）
DEI（Drop Eligible Indicator）: 1ビット（旧CFI）
VLAN ID: 下位12ビット（値: 0〜4095）

この先頭3ビットであるPCPが、IEEE 802.1p（現在はIEEE 802.1Q規格内に統合）で定義されたCoS（Class of Service）のマッピングを司る。

L2スイッチは、受信したフレームのPCP値をハードウェア（ASICのTCAMやパケットバッファマネージャー）で即座に読み取る。そして、スイッチ内部の複数用意された出力キュー（通常は4つから8つのハードウェア・キュー）のどこにパケットをエンキューすべきかを決定する。

ここで重要なのは、PCPはレイヤー2の概念であり、L3のDSCP（Differentiated Services Code Point）とは独立して存在しているという点だ。ルータを越えない純粋なL2ドメインや、エッジでのL2/L3境界において、このPCPとDSCPの相互マッピング（QoSポリシー）が適切に設計されていないと、どれだけ上位層でパケットをチューニングしても、スイッチの出力ポートで公平にドロップ（Tail Drop）の洗礼を受けることになる。

—

2. TLSハンドシェイクとTCPバッファチューニングのパラドックス

現代のWebインフラストラクチャは、その大半がHTTPS、すなわちTLSで暗号化されている。セキュアな通信を確立するためのTLSハンドシェイク（Client Hello, Server Hello, Certificate, Key Exchangeなど）は、データ転送の「前段階」で行われるため、ここで発生するラウンドトリップ（RTT）の遅延がそのままアプリケーションの体感速度（TTFB: Time to First Byte）に直結する。

ここで、インフラエンジニアが陥りがちなパラドックスがある。
「TCPのウィンドウサイズを大きくし、BDP（Bandwidth-Delay Product）を最大化すればスループットは上がる」という鉄則があるが、バッファを無闇に巨大化させると、いわゆるBufferbloat（バッファブロート）を引き起こす。スイッチやルータのキューが肥大化し、結果としてTCPのACKパケットやTLSのハンドシェイクパケットが巨大なキューの最後尾に並ばされ、RTTが跳ね上がってしまうのだ。

このジレンマを打破するのが、PCPを活用した帯域と優先度の分離である。

Linuxカーネルにおけるソケット優先度の付与とVLANタグ挿入

Linuxホストから送出されるパケットに対して、特定のアプリケーションやポートのトラフィック（例えばHTTPSの443ポートや管理用のSSH）に適切なソケットマークを付与し、それをトランスポート層からL2のPCPへとブリッジさせる設定を見てみよう。

以下のPythonスクリプトやiproute2の仕組みを用いることで、Linuxのネットワークスタックから送出されるパケットのIPヘッダー（DSCP）と、vlanデバイスを経由した際のL2ヘッダー（PCP）を連動させることが可能だ。

# 1. 802.1QのVLANインターフェースを作成する (例: eth0上にVLAN 100を作成)
sudo ip link add link eth0 name eth0.100 type vlan id 100

# 2. vlanデバイスに対して、特定のスレッドやDSCP値を持つパケットを特定のPCPにマップする
# Linuxの vlan_qos 映射機能を利用 (DSCP -> PCP のマッピング)
sudo ip link set dev eth0.100 type vlan egress-qos-map 0:0 3:3 4:4 46:5
# ※ 上記は例: DSCP 46 (EF: Expedited Forwarding) を PCP 5 (VOIP/重要制御) にマッピング

# 3. tc (Traffic Control) を用いて、パケットの送出キューイング規 disciplina (qdisc) を設定
sudo tc qdisc add dev eth0 root handle 1: prio

このように、OSのネットワークスタックレベルで重要パケット（TLSの暗号化ハンドシェイクや制御信号）を識別し、それをL2フレームのPCP 5 や 6 にマッピングして送出することで、下流のL2スイッチは即座に高優先度キュー（Strict Priority Queue）へとパケットを割り当てることができる。

—

3. ヘッダー圧縮とPCPの維持：制約されたネットワーク環境の現実

IoTデバイスが密集する環境や、帯域が極限まで限られた無線バックホール、あるいは産業用イーサネット（PROFINETやEtherCATなど）の領域では、わずか数バイトのオーバーヘッドすら致命傷になる。

802.1Qタグの4バイト（TPID + TCI）は、通常のギガビット回線では無視できるが、小粒なパケット（VoIPの音声パケットやリアルタイム制御の小ペイロード）が大量に流れる環境では、帯域効率を数パーセント悪化させる。

ここでROHC（RObust Header Compression: RFC 3095 / RFC 5795）などのヘッダー圧縮アルゴリズムが登場する。ROHCは、IP、UDP、TCP、そしてRTPなどのヘッダーを極限まで圧縮し、数バイトに縮める技術だが、L2の802.1Qタグおよびその内部のPCPフィールドをどう扱うかという問題が生じる。

多くのキャリアグレードのルータやトランスポート装置では、L2トンネリングやMPLS、あるいは特定のL2レイヤーでカプセル化を行う際、PCPの値をMPLSのEXP（Experimental）ビットや、IPのDSCPへと「コピー（Remarking）」する処理を挟む。

+-------------------------------------------------------+
|  Ethernet Header (DA, SA, 802.1Q [PCP=5], EtherType)   |
+-------------------------------------------------------+
                          │
                          ▼ (L2/L3境界でのリマーキング)
+-------------------------------------------------------+
|  IP Header (DSCP = EF / 46)                           |
+-------------------------------------------------------+

このリマーキングが適切に行われないと、ヘッダー圧縮やトンネリングを通過した瞬間にPCPの優先度情報が消失し、宛先までの途上のスイッチでベストエフォートの扱いを受けてしまう。インフラ設計においては、「どのポイントでPCPがDSCPに変換され、どこで再度L2のPCPに戻されるか」のライフサイクルを完全に把握しておく必要がある。

—

4. セキュリティの視点：PCPの悪用とネットワーク脆弱性の回避

ネットワークスペシャリストとして見落とせないのが、このQoS（PCP）機能がセキュリティ上の攻撃ベクトルになり得るという事実だ。

悪意ある攻撃者が、レイヤー2スイッチに対して不正なPCP値（例えば 6 や 7 のネットワーク制御クラス）を付与したトラフィックを意図的に大量流し込んだ場合、何が起きるだろうか。

多くの安価なL2スイッチ、あるいは設定を誤ったエンタープライズ向けスイッチでは、PCP 7（Network Control: STPやLACPなどのクリティカルな制御フレームが使用するべき領域）のトラフィックに対して無条件で最優先のStrict Priorityを割り当てている。

攻撃者がこのPCP 7 を偽装してDDoS攻撃や帯域占有フラッドを仕掛けた場合、本物のスパニングツリー（STP）のBPDUや、LACPのリンク制御パケットがスイッチの内部キューで後回しにされるか、最悪の場合バッファ溢れによってドロップさせられる。
結果として、ネットワークの生命線である制御プロトコルがダウンし、スイッチ間リンクがループに陥ったり、ルーティングが崩壊するという致命的なインシデント（L2 Control Plane Exhaustion）を引き起こす。

実務における防御策（硬化設定）

このような脆弱性を回避するため、エッジスイッチ（アクセスポートやトランクポート）では厳格なQoSポリシー（Trust Boundary）を構築しなければならない。

Cisco CatalystやNexusスイッチを例に、信頼境界（Trust Boundary）を明示し、ユーザーポートからの不正なPCP値を信頼しない（あるいは書き換える）設定の核心部分を見てみよう。

# 1. アクセスポートまたは不正なトラフィックが流入するポートでQoSの信頼境界を設定
interface GigabitEthernet0/1
 description User-Facing-Access-Port
 switchport mode access
 switchport access vlan 100
 
 # デフォルトではポートに入ってくるQoSマーク（PCPやDSCP）を信用しない（Un-trusted）
 # スイッチ側で強制的にPCPを 0 (Best Effort) にリセットする
 mls qos trust dscp
 # または、レイヤー2入力時にPCPを強制上書きする設定
 srr-queue input bandwidth 80 20 0 0
 priority-queue out

インフラのセキュリティ監査においては、「誰がPCPの値を決める権限を持っているか」を常に意識する必要がある。エンドホスト（ユーザーのPCや不正なIoTデバイス）が勝手にPCPを 7 に設定して送信できるような野放しのトランク構成は、セキュリティ・アーキテクチャの観点から即座に排除されるべきである。

—

5. まとめ：パケットの運命をデザインする

802.1Qのたった3ビット、PCP。
その小さな領域の振る舞いを理解し、L2スイッチのキューイング戦略、OSのソケットバッファ、そしてTLSハンドシェイクの遅延削減とを結びつけてデザインできるかどうかが、凡百のインフラエンジニアと、真のネットワークプロトコルスペシャリストを分ける境界線となる。

パケットが光の速度で物理ファイバーを駆け抜け、スイッチのASICを通過するその一瞬一瞬で、PCPは静かに、しかし確実にその運命を指し示している。この目に見えない秩序を自在に操り、極限のパフォーマンスと堅牢なセキュリティを両立させたネットワークを構築することこそ、我々のロマンであり、技術者としての醍醐味なのだ。