スウェーデンのカールスタード大学は9月10日、インターネット上の遅延を、利用者に近いアクセス区間からWebサーバー内部、衛星回線に至るまで調査したSimon Sundberg氏の博士論文を紹介した。通常の通信を観測する軽量なツールと、高頻度で試験用パケットを送信する手法を使い分け、一般的な速度テストだけでは捉えにくい遅延を測定している。米国の無線ISPで観測された、まれにほぼ1秒に達する往復時間は、その具体例の一つだ。この研究が示しているのは、回線の帯域を増やすだけでは解消できない「遅さ」を、どこで、どの程度の時間スケールで発生しているのかに応じて調べる必要があるということだ。

帯域は単位時間あたりに運べるデータ量を、遅延は通信や処理の過程で生じる待ち時間を指す。大きなファイルのダウンロードでは帯域が重要になる一方、相手からの応答を待つビデオ通話やオンラインゲームでは、一時的な遅延の増加も利用体験を損なう。この違い自体は以前から知られている。Sundberg氏の研究の意義は、実際に運用されているネットワーク上で、こうした遅延を継続的に捉えるための手法を整えた点にある。

AD

米無線ISPで見えた、まれに長引く遅延

利用者に近い区間を調査したのは、米テキサス州エルパソのJackRabbit Wirelessである。2024年のACM Internet Measurement Conference（IMC）で公刊された研究によると、当時の加入者は約400で、その約95%を一般家庭が占めていた。測定期間は2023年10月30日から12月1日までで、途中に約5時間の欠測がある。したがって、2026年9月時点の通信状況を測定したものではない。

研究チームはISPの中核ネットワークに観測点を設置し、通常の通信から90億件を超えるRTT（往復遅延時間）のサンプルを収集した。観測点から利用者端末へ向かう「内部区間」と、インターネット上の通信相手へ向かう「外部区間」を分けて分析している。ここでいう内部区間にはISPのアクセス網だけでなく、家庭内の接続も含まれており、宅内Wi-Fiだけを測定したものではない。

内部区間では短いRTTが大半を占める一方、まれに大きな遅延が発生した。観測値の99%がその値以下に収まる99パーセンタイルは、内部区間が326ミリ秒、外部区間が134ミリ秒だった。外部区間は通常時の待ち時間が長い一方、大きく遅れるケースのばらつきは内部区間より小さかった。

さらに、内部区間で観測されたRTTの約0.16%は996ミリ秒を超えていた。ほぼ1秒に達する遅延だが、これは平均値でも加入者の割合でもなく、観測された内部RTTのサンプル全体に占める割合である。集計は4ミリ秒刻みで行われ、996ミリ秒を超える値は最後の区分にまとめられている。そのため、この区分に含まれるすべての値を厳密な「1秒超」とみなすこともできない。

同ISPでは、送信待ちのパケットがキューに滞留しすぎるのを防ぐAQMや、通信帯域を公平に配分するための制御をすでに導入していた。それでも夕方の混雑時には内部区間で大きな遅延が増えたことから、研究者は家庭内のWi-Fiルーターが主な原因である可能性を指摘している。ただし、各家庭の機器を個別に測定して原因を特定したわけではない。単一のISPで得られた結果から、日本を含む家庭回線全体での発生率を推定することもできない。

遅延を測る場所によって、見える問題は変わる

研究チームが開発した「epping」は、試験用の通信を新たに発生させることなく、実際に流れているパケットからRTTを推定する受動監視ツールだ。Linuxカーネル内でプログラムを実行できるeBPFを利用し、測定値の計算や集計をカーネル内で処理する。パケットを複製して別のプログラムへ渡したり、個々の測定結果を逐一外部へ送ったりする際の負荷を抑える設計となっている。

測定そのものの負荷が大きければ、観測対象の通信に影響を与えてしまう。そこでeppingや、サーバー内部の遅延を調べる「netstacklat」は、できるだけ軽い処理で継続的に監視できることを重視している。ただし、追加の通信を発生させないことと、処理負荷がまったくないことは同じではない。

3つの研究で対象としている遅延は、それぞれ測定方法も、そこから分かる範囲も異なる。ラストマイルのRTT、ホスト内部の受信処理時間、Starlink回線の片道遅延は、同じ種類の速度指標ではない。

観測対象 主な方法 分かること・限界
ISPの観測点と利用者端末の間 eppingで既存通信のRTTを推定 利用者側の区間で遅延が増える時間帯や分布を把握できる。ただし、家庭内のどの機器が原因なのかを直接特定することはできない
Webサーバー内部の受信処理 netstacklatでカーネル内の通過時刻を追跡 パケットがアプリケーションに読み込まれるまでの待ち時間を調べられる。アプリケーション全体の応答時間とは異なる
Starlinkを通る通信 nanoprobeで試験用パケットを高頻度に送信し、機器側で時刻を記録 片道遅延が短い時間スケールでどのように変動するかを調べられる。ISPで通常の通信を観測した実験とは測定条件が異なる

この比較は、Sundberg氏の博士論文における研究手法と成果の整理と、各研究の観測対象に基づいている。同じ「遅延」という言葉を使っていても、測定に含まれる区間が異なれば、数値を単純に比較することはできない。利用者側で大きな遅延が観測されたからといって、サーバー内部や衛星回線の調査が不要になるわけでもない。

AD

サーバー内部で生じる遅延、測り方で変わる衛星回線の見え方

netstacklatの研究では、nginxとApacheを対象に、サーバー設定やファイルサイズ、同時接続数を変えた144通りの条件で実験を行った。そのうえでCloudflareの実運用サーバーにも導入し、通信がサーバーに到着してからアプリケーションに読み込まれるまでの遅延を調べている。この成果はIMC 2026の採択稿として公開されている。

博士論文で紹介されているCloudflareでの観測では、受信処理の遅延は通常64〜256マイクロ秒だった。一方、あるサーバーでは通信量が大きく増えていないにもかかわらず、遅延の中央値が128〜256マイクロ秒程度から、約3時間かけて2ミリ秒を超えるまで増加する異常を捉えた。ネットワーク上をパケットが移動する時間だけを見ていては、サーバーに到着した後、コンピューター内部で待たされる時間を見落としてしまう。

ただし、この結果をすべてのWebサーバーに共通する深刻な遅延と受け取るのは早計だ。別の半制御実験では、想定容量を超える負荷をかけた場合でも、受信処理時間の95パーセンタイルは1ミリ秒未満だった。単純に負荷が増えた場合と、通常運用中に特定の異常が発生した場合を切り分けて観測できる点に、こうした監視の価値がある。

Starlinkでは、さらに細かい時間スケールでの観測が必要だった。研究チームは「nanoprobe」を使って高頻度で試験用パケットを送り、ネットワークカードが記録する時刻を利用した。OS内部の処理を経てから時刻を記録すると、測定したい回線そのものの遅延に、測定用コンピューター内部で生じた待ち時間が混ざりやすいためだ。

その結果、数ミリ秒の間に到着した複数のパケットが、無線通信の処理単位ごとにまとめて届く様子が確認された。先に到着したパケットほど長く待ち、後から到着したパケットほど待ち時間が短くなる。この動きが繰り返されるため、細かい時間分解能で見ると、遅延は逆のこぎり波のように周期的に変動する。

従来のように粗い間隔で測定すると、遅延がいくつかの帯状の値に分かれているように見えていた。研究では、これを測定間隔が粗いために本来とは異なるパターンとして見える「エイリアシング」だと説明している。衛星までの距離に由来する伝搬時間だけでなく、パケットの送信タイミングや無線資源の割り当ても待ち時間を生む。平均値だけでなく、どの程度細かい時間間隔で測定したのかによっても、ネットワークの仕組みの見え方は変わる。

増速の前に、どこで待っているのかを知る

eppingの公開コードは、ISP向けの通信品質管理基盤LibreQoSにも取り込まれている。netstacklatやnanoprobeも公開されており、これらの研究成果は、実験環境で遅延を測る段階から、実運用中のネットワークを継続的に調べるための手段へと発展している。

もっとも、監視できる範囲には制約がある。博士論文で扱われたeppingの実装では、RTTを推定できる対象はTCPとICMP Echoに限られており、あらゆるゲーム通信やQUICをそのまま観測できるわけではない。netstacklatも、TCPとUDPの受信処理を対象としている。また、測定結果を集計することで処理負荷を抑える代わりに、個々の通信の細かな情報は失われる。ツール単体で遅延の原因を自動的に特定する仕組みでもない。

これらの結果から得られる運用上の示唆は、単純に回線を増速する前に、遅延がどの区間で、どの時間帯に生じているのかを切り分ける必要があるということだ。利用者側の区間に問題があるのか、サーバー内部の受信処理に時間がかかっているのかによって、対処すべき場所も変わる。

通常時の短い遅延だけでなく、まれに発生する大きな遅延も継続的に捉えられれば、通信事業者やサービス提供者は、設備を増強すべき場所と、処理方法を見直すべき場所をより正確に絞り込める。