【テクニカル・上級編】無線パケット損失と遅延揺らぎ（ジッタ）がTCP/UDPスループットに与える影響 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5G時代の「見えない壁」：無線区間のジッタとTCP輻輳制御の冷酷な現実

インフラエンジニアやテックリードの皆さん、こんにちは。

「5Gになったから低遅延で爆速」——そんな謳い文句を信じているのは、エンドユーザーだけで十分です。我々プロフェッショナルは、無線区間（Air Interface）に潜む「バーストエラー」と、それが引き起こす「ジッタ（遅延揺らぎ）」が、いかにしてトランスポート層のパフォーマンスをスポイルしているかを骨の髄まで理解しているはずです。

今日は、理論値と実効値の間に存在する「埋められない溝」を、パケットレベルの挙動から紐解いていきます。

無線区間の「気まぐれ」がTCPウィンドウを崩壊させる

TCPは、パケットロスを「輻輳（ネットワークの混雑）」と誤認する設計思想に基づいています。有線LANであればロス＝輻輳ですが、5GやLTEにおいて、瞬発的な電波干渉によるパケットロスは「ただのノイズ」です。

しかし、カーネルのTCPスタックは容赦しません。ロスを検知した瞬間、cwnd（輻輳ウィンドウ）を急激に絞り込み、スループットは崖から落ちるように低下します。特に、無線区間で発生するジッタは、RTTの分散を増大させ、RTO（再送タイムアウト）の計算式を狂わせます。

なぜジッタが致命的なのか

無線区間では、サブフレーム単位のスケジューリングや再送制御（HARQ）が動いています。これにより、RTTが数ミリ秒から数十ミリ秒まで激しく変動します。この揺らぎが続く環境下では、TCPのSRTT（平滑化されたRTT）算出が追いつかず、偽の再送（Spurious Retransmission）が誘発され、スループットはさらに悪化するという悪循環に陥ります。

現場で効くLinuxカーネルチューニング

現代のモバイルネットワークにおいては、標準的な Cubic よりも、遅延ベースで輻輳を制御する BBR (Bottleneck Bandwidth and Round-trip propagation time) の採用が正解です。

以下は、バースト性の高いモバイル回線でパフォーマンスを最大化するためのsysctl設定例です。

# BBRアルゴリズムを有効化し、キューイングの遅延を回避
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

# TCPウィンドウサイズを動的に拡大（高遅延・高帯域に対応）
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# タイムスタンプオプションを有効化し、RTT測定の精度を向上させる
sysctl -w net.ipv4.tcp_timestamps=1

# 再送のバックオフを微調整し、過敏な反応を抑える
sysctl -w net.ipv4.tcp_retries2=5

TLSハンドシェイクの「往復」を削ぎ落とす

モバイル環境において、RTTが10ms増えるだけで、TLSハンドシェイクは致命的な遅延を生みます。特に、TCP Fast Open（TFO）を活用し、ハンドシェイクの往復回数を削減することは、アプリの体感速度を劇的に改善します。

# NginxでのTFO有効化設定
listen 443 ssl fastopen=256;

# 0-RTT（TLS 1.3）の活用
ssl_early_data on;

ただし、0-RTT はリプレイ攻撃に対する脆弱性があるため、API設計時には「冪等性（Idempotency）」を担保したエンドポイントのみに適用するよう、設計レベルでの防衛が必要です。

ヘッダー圧縮とパケット断片化の最適化

モバイル通信における ROHC（Robust Header Compression）は基地局側の処理ですが、アプリ側で意識すべきは「MTUの最適化」です。モバイル回線のデフォルトMTUは1500バイトですが、VPNやトンネリングを挟むと、パケットの断片化（Fragmentation）が発生し、オーバーヘッドが増大します。

ping コマンドでフラグを立てて、実環境での最適MTUを測定しておくことは、テックリードの嗜みと言えるでしょう。

# パケットの分割を許可せず、サイズを徐々に下げて測定
ping -M do -s 1472 8.8.8.8
# もし 1472 でエラーが出るなら、ヘッダー分を引いて MTU を 1420 程度まで落とす判断が必要

結びに：エンジニアとしての「観測眼」

結局のところ、無線区間の挙動を完全に制御することは不可能です。だからこそ、我々は「ロスが起きる前提」でシステムを設計する必要があります。

UDPベースのプロトコル（QUIC/HTTP3）への移行: 再送制御をトランスポート層で独立させることで、無線特有のパケットロスによるHead-of-Line Blockingを回避する。
アプリケーション層でのフォールバック: ネットワークの品質を監視し、状況に応じてコンテンツの品質を動的に調整するアダプティブ・ストリーミングの実装。

ネットワークは生き物です。教科書的な設定を適用して満足するのではなく、tcpdump でパケットのシーケンス番号を追いかけ、tc（Traffic Control）でジッタを模した検証環境を作り、泥臭く追い込むこと。それこそが、この混沌とした無線環境でサービスを守り抜く唯一の道です。

さあ、皆さんのターミナルにも、パケットの鼓動が聞こえてきましたか？