【テクニカル・上級編】バックプレッシャー（Backpressure）とフローコントロール（IEEE 802.3x Pauseフレーム） – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

ネットワークの深淵：IEEE 802.3xが招く「沈黙」とバッファ溢れの物理的真実

インフラエンジニアの端くれとして、これまで数多のパケットロスと対峙してきたが、最も「解明しづらい」現象の一つが、輻輳によるバッファ溢れだ。我々はしばしば、パケットロス＝TCPの再送制御や輻輳回避（Congestion Control）の問題と短絡的に考えがちだが、その足元、L2のレイヤーで何が起きているかまで意識を巡らせているだろうか？

今日は、スイッチのバックプレッシャーと IEEE 802.3x Pauseフレームという、物理的かつ泥臭い「強制停止」のメカニズムについて、現場の視点から紐解いていこう。

—

1. 物理的な「待った！」：IEEE 802.3x Pauseフレームの挙動

現代の全二重（Full-Duplex）ネットワークにおいて、受信側のバッファが限界に達したとき、スイッチは対向ノードに対して「少し黙れ」と信号を送る。これが IEEE 802.3x によるフローコントロールだ。

内部挙動の深層

パケットは、スイッチのIngressポートから入った瞬間、ASIC内の共有バッファにキューイングされる。このバッファが High Watermark を超えると、ハードウェアレベルで Pause フレーム（宛先MAC 01:80:C2:00:00:01）が生成される。このフレームには Pause Time が含まれており、送信側はその期間、データパケットの送出を停止しなければならない。

この挙動は、上位層から見れば「突如としてRTTが増大したかのようなレイテンシ」として観測される。TCPスタックが輻輳ウィンドウ（cwnd）を絞る前に、L2で通信そのものが「一時凍結」されるわけだ。これが高負荷なストレージネットワークや、マイクロバーストが頻発する環境で発生すると、アプリケーション層のレスポンスに凄まじいジッタを生むことになる。

—

2. 半二重の残滓：バックプレッシャー（Backpressure）

全二重が主流となった現在でも、低速なレガシー環境や特定の産業用スイッチでは「バックプレッシャー」という概念が生きている。これは、受信側がわざと「キャリアセンス」を偽装して衝突を誘発させたり、プリアンブルを乱したりすることで、送信側に「コリジョンが起きている」と誤認させ、送信をバックオフさせる手法だ。

現代の設計においてこれを明示的に有効にすることは稀だが、古いハブや安価なアンマネージドスイッチと混在させる環境では、予期せぬスループット低下の主犯となる。トラブルシューティングの際、show interface で Late Collisions や Excessive Deferral が右肩上がりであれば、この物理的なバックプレッシャーが疑わしい。

—

3. 極限のチューニング：パケットロスとTCP、そしてTLSの最適化

インフラアーキテクトが目指すべきは、「Pauseフレームが発生しない設計」だ。バッファが枯渇する前に、TCPスタック側で制御を完了させる必要がある。

Linuxカーネルにおけるチューニングの要諦

もし、サーバ側のNICでフローコントロールが有効で、かつバッファ溢れによるPauseフレームが観測されるなら、まずはNICのRXバッファを拡張すべきだ。

# 現在のRXバッファ設定を確認
ethtool -g eth0

# RXバッファの最大化（ハードウェア限界まで引き上げる）
# これにより、一過性のバーストを吸収し、Pauseフレームの発生を遅延させる
sudo ethtool -G eth0 rx 4096

さらに、TCPの輻輳制御アルゴリズムを BBR に変更することは、現代のネットワークにおいて必須の選択肢だ。CUBIC が「ロスを検知して速度を落とす」のに対し、BBR は「帯域幅とRTTをモデル化し、バッファが埋まる前に流速を調整する」ため、Pauseフレームの誘発を物理的に抑え込める。

# BBRの有効化（sysctl.confへの追記推奨）
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

—

4. セキュリティとパフォーマンスのトレードオフ

最後に、TLSハンドシェイクとネットワーク最適化の観点について。
TLS 1.3の導入により、0-RTTハンドシェイクが現実のものとなったが、これはパケットの最初のバーストを劇的に増やす。もしネットワーク機器側でフローコントロールが有効で、かつバッファが十分に確保されていない場合、この最初の「Client Hello」に伴うデータ群がPauseフレームを誘発する引き金になり得る。

MTUの最適化: 1500 byteを維持しつつ、ジャンボフレームを無闇に有効化しない。フラグメントによる再構築オーバーヘッドはバッファを食い潰す。
ヘッダー圧縮: HPACK や QPACK はアプリケーション層の話だが、L2/L3の物理負荷を減らすには、無駄なトラフィック（不要なマルチキャスト等）を IGMP Snooping 等で物理的に排除し、バッファの占有率を下げるのが先決だ。

結びに：エンジニアとしての矜持

「スイッチの設定でフローコントロールをオフにする」という選択肢を提示すると、驚く現場がある。だが、バッファでパケットを止めてレイテンシを悪化させるよりも、「溢れたら捨てる（Drop）」というTCP本来の動作に委ねる方が、現代の高性能なTCPスタックにおいては遥かに健全なパフォーマンスを示すことが多いのだ。

ネットワークの深淵を覗くとき、教科書的な「フローコントロールはパケットロスを防ぐ」という記述を鵜呑みにせず、それが「アプリケーションのリアルタイム性にどう影響するか」という視点を忘れないでほしい。パケットが物理的な導線の上でどう振る舞っているか、その「息遣い」を感じ取ることが、真のインフラアーキテクトへの第一歩だ。