【実務・中級編】モバイル網におけるパケットロス・Jitter・遅延(RTT)の測定手法と影響 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

モバイル回線の「目に見えない挙動」を暴く：パケットロス・Jitter・遅延と戦うエンジニアの心得

「Wi-Fiでは完璧なのに、なぜかモバイル回線だとAPIのレスポンスが跳ねる」。

現場でインフラやアプリの運用に携わっていると、一度は頭を抱えた経験があるはずです。5Gの普及でスループット（理論上の最高速度）は劇的に向上しましたが、物理層の安定性、つまり「揺らぎ」は4G時代と変わらず、あるいはミリ波の導入によってよりシビアになっています。

今日は、教科書的な理論を現場の泥臭い現実に引き戻し、モバイル網における「遅延（RTT）・ジッター・パケットロス」がアプリケーションに与える実態と、それをどう計測し、どう対処すべきかについて掘り下げていきましょう。

—

1. 無線区間の「見えない壁」：なぜモバイルは揺れるのか

モバイル通信、特にSub6やミリ波といった高周波数帯を使う5G環境では、電波は極めて気まぐれです。移動中のハンドオーバー（基地局の切り替わり）、遮蔽物による急激な減衰、そして電波干渉。これらはすべて、物理層での再送やバッファリングを引き起こします。

ここでエンジニアが意識すべきは、「パケットが届かない」のではなく「パケットが遅れて届く」ことの罪深さです。

RTT（往復遅延）: APIリクエストの「握手」にかかる時間。モバイルでは100msを超えることも珍しくありません。
Jitter（ジッター）: 連続するパケット間の遅延のばらつき。これが大きいと、音声・動画ストリーミングは即死します。
パケットロス: TCPの再送タイマーを強烈に刺激します。TCP Window Sizeが縮小され、スループットが急降下する「パケットロスの悪循環」は、モバイルアプリの体感速度を決定づけるボトルネックです。

—

2. 現場で使える「泥臭い」測定手法

「通信が悪い」という報告を鵜呑みにしてはいけません。まずは mtr（My Traceroute）でパケットの損失ポイントを可視化しましょう。

MTRによる定点観測

pingを打ち続けるだけでは不十分です。mtr を使い、経路上のどこでパケットが落ちているのか、あるいは遅延が増大しているのかを特定します。

# ターゲットに対してTCPポート80/443を指定して診断
# モバイル回線特有のICMP制限を回避するため、TCPでのプローブが有効です
mtr -T -P 443 -c 100 example.com

PythonでAPIレスポンスの「ゆらぎ」を記録する

インフラ運用では、単純な生存確認ではなく「APIのTTFB（Time To First Byte）」を計測し続けるスクリプトを仕込むのが定石です。

import requests
import time
import statistics

def measure_api_latency(url, count=50):
    latencies = []
    for _ in range(count):
        start = time.perf_counter()
        try:
            # 接続タイムアウトを厳しめに設定してモバイルの「詰まり」を検知
            r = requests.get(url, timeout=2.0)
            end = time.perf_counter()
            latencies.append((end - start) * 1000)
        except requests.exceptions.RequestException:
            latencies.append(None) # タイムアウトはNoneとして記録
        time.sleep(0.5) # 連続負荷を避けつつ計測
    
    return latencies

# 結果の統計を出力
latencies = [l for l in measure_api_latency("https://api.example.com") if l is not None]
print(f"平均RTT: {statistics.mean(latencies):.2f}ms")
print(f"ジッター（標準偏差）: {statistics.stdev(latencies):.2f}ms")

—

3. アプリケーション設計へのフィードバック

計測で「モバイル特有の不安定さ」が見えたら、次は設計でカバーします。

TCP/TLSハンドシェイクのコストを減らす

モバイル回線において、毎回TCPコネクションを張るのは自殺行為です。コネクションプールを適切に設定し、Keep-Alive を活用してハンドシェイク回数を最小化してください。

HTTP/3 (QUIC) の検討

モバイル通信の救世主がQUICです。UDPベースであるため、パケットロス発生時にTCPのような「ヘッド・オブ・ライン・ブロッキング（一つのパケットロスが後続の全データの滞留を招く現象）」が発生しません。

NginxでHTTP/3を有効にする設定例:

server {
    # UDP 443ポートでQUICを待ち受け
    listen 443 quic reuseport;
    listen 443 ssl;
    
    # HTTP/3をクライアントに通知するヘッダー
    add_header Alt-Svc 'h3=":443"; ma=86400';
    
    # 略
}

—

結論：ネットワークを「信頼しない」勇気

モバイルネットワークにおいて、「安定」は幻想です。

Web APIを設計する際は、常に「パケットロスがあり、ジッターが激しく、突然切断される可能性がある」という前提に立ち返ってください。タイムアウト設定を適切に短くし、リトライ戦略を指数バックオフで行い、クライアント側でのローカルキャッシュを極限まで活用する。

泥臭い計測と、それに基づいた「ネットワークに依存しない」アプリケーション設計こそが、モバイル時代を生き抜くエンジニアの武器になります。

計測を恐れず、パケットの挙動を愛してください。その先にこそ、ユーザーが驚くような「快適なモバイル体験」が待っているはずです。