このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
Webページの読み込み、動画ストリーミング、API呼び出しを含むインターネット上のすべてのやりとりは、接続から始まります。これらの基本的な接続は、デバイス間で行き来するパケットのストリームで構成されています。
こうしたネットワーク接続のさまざまな側面について、研究者や実務者はインターネットが存在する前から注目を集めてきました。接続への関心は、1991年の1991年の1991年の1991年の1991年の度必須システムの論文「通信内容の特性」に見られるように、接続に対する関心は以前からあることさえあります。いずれにせよ、インターネット測定コミュニティは何十年もにわたってインターネット通信の特性評価を行ってきており、「その期間は？」どれほど大きいものでしょうか？頻度は？ –そしてこれらは始まったばかりです。
意外なことに、インターネット全体の接続特性はほとんど利用できません。誰もがツール（例: Wireshark など）を使用して、ローカルにデータを取得できますが、アクセスと規模の理由から、グローバルな接続を測定することは事実上不可能です。さらに、ネットワーク事業者は一般的に、観察した特徴を共有しません。観察には自明な時間とエネルギーがかかる場合を想定します。
このブログ記事では、別の方向へ進んで、グローバルCDNを通じて確立された接続について集約したインサイトを共有します。CloudflareへのHTTPリクエストの約 70% を占める TCP 接続の特性を紹介し、クライアント側の測定だけでは得られない実証的なインサイトを提供します。
システムの動作を特徴とすることで、変化の影響を予測することができます。ネットワークのコンテキストにおいて、新しいルーティングアルゴリズムやトランスポートプロトコルを考えてみましょう。その効果を測定するにはどうすればよいでしょうか？1つの方法は、変更をライブネットワークに直接デプロイすることですが、これにはリスクが伴います。予期しない結果がユーザーやネットワークの他の部分に混乱をもたらす可能性があり、「まずはデプロイ」というアプローチは潜在的に安全でないか、倫理的に疑わしいものになります。
最初のステップとして、ライブデプロイメントより安全な方法は、シミュレーションです。シミュレーションを使用することで、デザイナーは完全なバージョンを構築することなく、スキームに関する重要なインサイトを得ることができます。しかし、インターネット全体をシミュレートするのは困難を伴います。「なぜ私たちはインターネットのシミュレートのしかたを知らないのか」という非常に初期の作品に説明されています。
有用なシミュレーションを実行するには、学習している実際のシステムのように動作する必要があります。つまり、実際の行動を模倣した合成データを生成するということです。多くの場合、私たちは統計的分布、つまり実際のデータの挙動を示す数学的記述を用いてこれを行います。しかし、これらの分布を作成する前に、まずデータを特徴付け、その主要な特性を測定し、理解する必要があります。この条件を満たしている場合にのみ、シミュレーションが現実的な結果を出すことができます。
データの価値は、その収集メカニズムに依存します。すべてのデータセットには死角、バイアス、制限があり、これらを無視すると誤解を招く結論につながる可能性があります。データがどのように収集されたのか、何を表しているのか、何を除外しているのかなど、より詳細な情報を調査することで、その信頼性をよりよく理解し、そのデータを使用する方法について情報に基づいた意思決定を行うことができます。収集したテレメトリについて詳しく見てみましょう。
データセットの概要.このデータは、上の図でVisitor to Cloudflareとラベル付けされたTCP接続を示しています。この接続は、HTTP 1.0、1.1、2.0経由でリクエストを提供し、当社のグローバルCDNサーバーで受信される毎秒平均8,400万件のHTTPリクエストの約70%を占めています。
サンプリング。受動的に収集されたデータのスナップショットは、2025年10月7日～10月15日の間にCloudflareへの全TCP接続の1%を一律にサンプリングしたものです。サンプリングは、個々のクライアント向けサーバーで行われ、データセンターレベルでのサンプリングによって生じるバイアスを軽減するために行われます。
多様性。大規模事業者によるトラフィックは主に自社のもので、検索、ソーシャルメディア、ストリーミングなどわずかなサービスで圧倒的保護、パフォーマンス向上、コスト削減に役立ちますこのような顧客の多様性を活かして、世界中から多種多様なWebアプリケーション、サービス、ユーザーをもたらします。その結果、当社が観察する接続は、常に進化する幅広いクライアントデバイスとアプリケーション固有の動作によって形成されたものです。
ログに記録するもの。ログの各エントリは、LinuxカーネルのTCP_INFO構造を経由して取得されたソケットレベルのメタデータと、SNIおよび接続中に行われたリクエストの数で構成されています。このログでは、個々のHTTPリクエスト、トランザクション、および詳細は除外されます。当社では、パケットの持続時間や送信数、処理されたHTTPリクエストの数など、メタデータ統計情報との接続にログを使用することを制限しています。
データキャプチャ。私たちは、FINパケットで正しくクローズする接続のみを特徴付けることで、完全に処理されたデータセット内の「有用な」接続を表すことを選択しました。これは、攻撃緩和策によって傍受された接続、タイムアウト、またはRSTパケットによって中断された接続を除外します。
安全なクローズ自体は「有用な」接続を示すものではないため、この分析からアイドル接続または非HTTP接続を除外するためには、接続中に少なくとも1つのHTTPリクエストが成功する必要があります。興味深いことに、これらはTCP全体の11%を占めています。 FINパケットで終了するCloudflareへの接続を確立する必要があります。
また、Cloudflareのロギングメカニズム全体と後処理パイプラインの詳細についても、以前のブログでご紹介しています。
ネットワークは本質的に動的で、トレンドは時間の経過とともに変化するものですが、当社のグローバルインフラストラクチャ全体で見られる大規模なパターンは、経時的に驚くほど一貫しています。当社のデータは接続特性のグローバルな視点を提供していますが、分布は地域のトラフィックパターンによって異なる可能性があります。
ビジュアライゼーションでは、累積分布関数（CDF）グラフ、具体的には経験的同等物で特性を表します。CDFは特に分布をマクロに把握するのに役立ちます。同じ画面で、一般的なケースと極端なケースの両方を明確に把握できます。大規模なパターンを理解するために、下のイラストで使用しています。また、分布をよりよく理解するために、ネットワーキングデータに共通する極端な値の存在を考慮するために、ログスケーリングされた軸を採用しています。
インターネット接続に関する長年の疑問は、「象とマウス」に関連しています。実務者や研究者は、ほとんどのフローが小規模で一部が巨大であることを十分に認識していますが、その境界を表すデータはほとんど存在しません。ここからがプレゼンテーションの始まりです。
まず、Cloudflareサーバーがクライアントに返す接続で送信される応答パケット数の分布を見てみましょう。
グラフでは、X軸は送信された応答パケット数をログスケールで表し、Y軸は各パケットカウント以下の接続の累積割合を示しています。平均応答は約240パケットですが、分布は大きく偏っています。中央値は12パケットで、インターネット接続の50％が非常に少ないパケットで構成されていることを示しています。さらに90パーセンタイルに達すると、接続はわずか107パケットを伝送します。
この対照的な結果は、インターネットトラフィックのヘビーテールの性質を浮き彫りにしています。実際は少数の接続が動画ストリームや大容量ファイル転送のように大量のデータを転送するのに対し、ほとんどのインタラクションは小さいもので、小さなWebオブジェクト、マイクロサービストラフィック、またはAPI応答を配信するものです。
上のプロットは、HTTPプロトコルバージョンごとのパケット数の分布を示したものです。HTTP/1.X（HTTP 1.0と1.1の両方を含む）接続では、応答の中央値はわずか10パケットで構成され、接続の90%は応答パケットが63個未満です。一方、HTTP/2接続は、中央値が16パケット、90パーセンタイルが170パケットと、より大きな応答を示します。この違いは、HTTP/2が1つの接続で複数のストリームを多重化する方法を反映していると考えられます。多くの場合、より多くのリクエストと応答をより少ない接続に統合するため、接続あたりのパケットの総数が増加します。また、HTTP/2接続には追加のコントロールプレーンフレームとフロー制御メッセージがあり、応答パケットカウントが増えます。
このような違いにもかかわらず、全部のビューで見ると、同じように価格が強いパターンが見られます。ごく一部の接続が膨大な量のデータを伝送し（象のフロー）、何百万ものパケットにまで拡張し、ほとんどの接続は軽量（マウスのフロー）にとどまっています。
これまでは、サーバーからクライアントに送信されるパケットの総数に焦点を当ててきましたが、接続動作の別の重要な側面は、以下に示される、送受信パケットのバランスです。
X軸は、サーバーが送信したパケットとクライアントから受信したパケットの比率を示したもので、CDFとして可視化されています。すべての接続において、中央値は0.91で、接続の半分で、クライアントが送信するパケットはサーバーが応答する量よりもわずかに多いことを意味します。このクライアント側のパケット過剰は、主にTLS ハンドシェイク開始（ClientHello）、HTTP制御リクエストヘッダー、データ確認（ACK）を反映しており、通常、低容量の場合はサーバーがコンテンツペイロードで返すよりもクライアントが多くのパケットを送信することになります。接続が可能になっています。
CDNワークロードによくある大規模なダウンロードなど、クライアントの多い接続のロングテールがあるため、平均比率は1.28とさらに高くなっています。ほとんどの接続は、比較的狭い範囲内に分類されます。接続の10%は比率が0.67以下、90%は1.85以下です。しかし、ロングテールの挙動はインターネットトラフィックの多様性を浮き彫りにしています。アップロードが多い接続とダウンロードが多い接続の両方から極端な値が生じるのです。3.71の差異は、これらの非対称なフローを反映しており、接続の大部分はほぼバランスのとれたアップロードとダウンロードの交換を維持しています。
データを見る別の次元は、サーバーがクライアントに送信したバイトを使用しており、各接続で配信されるデータの実際の量を取得しています。この指標はtcpi_bytes_sentから得られており、linux/tcp.h で定義されているように、TCPヘッダーを除外しながら、(再)送信されるセグメントペイロードもカバーしています。RFC 4898（TCP Extended Statistics MIB）に準拠しています。
上記のプロットは、HTTPプロトコルバージョンごとに送信されたバイトを示します。X軸は、各接続上でサーバーが送信したバイトの合計を表しています。このパターンは、パケット数の分布で見られたものと概ね一致しています。
HTTP/1.Xでは、中央値のレスポンスは4.8KBで、90%の接続が51KB未満で送信しています。対照的に、HTTP/2接続はわずかに大きな応答を示します。中央値は6KB、90パーセンタイルは146KBです。平均ははるかに高く、HTTP/1.xでは224KBとなります。390KBもあれば、少数の非常に大規模な転送が反映されています。このようなロングテールの極端なフローは、1接続あたり数十ギガバイトに達する可能性がありますが、非常に軽量な接続の場合は、最小ペイロードはHTTP/1.Xの場合は最小115バイト、HTTP/2の場合は202バイトとなります。
tcpi_bytes_received指標を使用することで、接続ごとの受信バイト数と送信バイト数の比率を見て、データ交換のバランスをよりよく理解できるようになりました。この比率は、各接続がどの程度非対称であるかを表しています。基本的には、サーバーがクライアントから受信するデータと比較して、どれだけのデータを送信しているかを表しています。全接続の中央値は3.78で、すべてのケースの半分で、サーバーは受信量よりほぼ4倍のデータを送信していることを意味します。平均は81.06とはるかに高く、ダウンロードが多いフローによって維持されている強いロングテールを示しています。ここでも、強いロングテールの分布が見られ、極端なケースのごく一部が数百万を超える、クライアントに向けたデータ転送の極端な値となっています。
パケット数とバイト数は、交換されるデータの量を把握しますが、接続時間はその交換がどのように展開されるかを示す洞察を提供します。
上のCDFは、接続時間（有効期限）の分布を秒単位で示しています。X軸はログスケールであることに注意してください。すべての接続の中央値はわずか4.7秒で、接続の半分は5秒未満で完了します。平均は96秒とはるかに高く、長期間有効な接続の数が少なく、平均を歪めていることを反映しています。ほとんどの接続は、0.1秒（10パーセンタイル）から300秒（90パーセンタイル）の範囲内に収まります。また、デフォルトのアイドルタイムアウト制限に関係なく、接続を再利用するためにキープアライブで維持された可能性があり、複数日にわたる非常に長時間の接続も発生していることがわかります。このような長期間の接続は、通常、持続的なセッションまたはマルチメディアトラフィックを表しますが、Webトラフィックの大部分は依然として短時間でバースト的、一時的なものです。
単一の接続が、Webトラフィックに対して複数のHTTPリクエストを伝送することができます。これにより、接続多重化のパターンが明らかになりました。
上記は、1つの接続で確認されるHTTPリクエストの数（ログ単位）をHTTPプロトコルのバージョン別に分類したものです。HTTP/1.X（平均3リクエスト）とHTTP/2（平均8リクエスト）接続の両方では、リクエストの中央値がわずか1であり、制限された接続の再利用の蔓延を強調していることがすぐにわかります。しかし、HTTP/2は単一の接続で複数のストリームの多重化をサポートしているため、90パーセンタイルは10リクエストに上昇し、極端な場合には数千のリクエストが送信されることもあり、接続の合体によって増幅される可能性があります。対照的に、HTTP/1.X接続はリクエストカウントがかなり低くなります。これは、プロトコル設計に一致しています。HTTP/1.0は「接続ごとに1つのリクエスト」という原則に従っていますが、HTTP/1.1は持続的な接続を導入しました。両方のバージョンを組み合わせても、HTTP/1.X接続が90回以上のリクエストを送受信することは稀です。パーセンタイルです。
短時間の接続の蔓延は、長いセッションを維持するのではなく、新しい接続を開く傾向がある自動化されたクライアントやスクリプトによって説明できます。この直感を探るために、データセンターから発信されるトラフィック（自動化の可能性が高い）と典型的なユーザートラフィック（ユーザー駆動型）の間でデータを分離し、クライアントASNをプロキシとして使用しました。
上のプロットは、非DC（ユーザー駆動型）トラフィックの1接続あたりのリクエスト数がわずかに多く、ブラウザまたはアプリが単一の永続的な接続で複数のリソースを取得していることと一致しており、90パーセンタイルは5リクエスト/あたり5リクエストであることを示しています。接続が確立されます。対照的に、DC発信のトラフィックは、平均約3リクエスト、90パーセンタイルが2件で、私たちの予想を検証しています。このような違いにもかかわらず、リクエストの中央値は両グループとも1であることに変わりはなく、接続のオリジンにかかわらず、ほとんどが実に短いものであることを示しています。
接続レベルの測定は、根本的なパスの特性に関する洞察も提供します。さらに詳しく見ていきましょう。
ネットワークパスに沿った最大転送単位（MTU）は、パスMTU（PMTU）と呼ばれることもあります。PMTUは、スループット、効率性、および遅延に影響を与える断片化やパケットドロップなしに接続を通過できる最大のパケットサイズを決定します。当社のサーバー上のLinux TCPスタックは、パス最大転送単位検出の一部として、接続のためのパスに沿って断片化することなく送信できる最大のセグメントサイズを追跡します。
このデータから、最大転送単位の中央値（90パーセンタイルも！）は1500バイトであり、これは典型的なイーサネット最大転送単位と一致しており、ほとんどのインターネットパスで標準と見なされていることがわかりました。興味深いことに、10パーセンタイルは1,420バイトで、パスにMTUがわずかに小さいネットワークリンクを含む場合を反映しています。これは、一部のVPN、IPv6tov4トンネル、または断片化を避けるために厳格な制限を課す古いネットワーク機器でよく見られることです。極端には、IPv4接続の最大転送単位は552バイトまで小さく、これはLinuxカーネルによって許可される最小PMTU値に関連しています。
トランスポートプロトコルの重要なパラメータは、輻輳ウィンドウ（CWND）であり、これは、受信者からの確認を待たずに送信できるパケット数です。私たちは、これらのパケットまたはバイトを「インフライト」と呼びます。接続中、輻輳ウィンドウは接続全体で動的に進化します。
しかし、データ転送の開始時にある初期の輻輳ウィンドウ（ICCWND）は、特に上記のようにインターネットトラフィックに影響を与える短期間の接続では、大きな影響を与える可能性があります。ICWNDが低すぎると、小および中程度の転送がボトルネック帯域幅に到達するまでに追加のラウンドトリップ時間がかかり、配信が遅くなります。逆に、高すぎると、送信者によってネットワークが圧倒され、ボトルネックリンクを共有するすべての接続で不要なパケット損失や再送信が発生するリスクがあります。
ICWNDの妥当な推定値は、TCP送信者がスロースタートから移行する瞬間の輻輳ウィンドウサイズと考えることができます。この推移は、送信者が指数関数的な増加から輻輳の回避へと移行する時点を表しており、さらなる成長が輻輳のリスクを負う可能性があると考えられます。下図は、BBRが算出した低速スタート時点の輻輳ウィンドウサイズの分布を示しています。中央値はおよそ464KBで、通常1,500バイトの最大転送単位で1接続あたり約310パケットに相当しますが、極端なフローでは数十メガバイトが実行されます。この変動は、TCP接続の多様性と、トラフィックを伝送するネットワークの動的に変化する性質を反映しています。
これらの値は、Cloudflareとエンドユーザー間のパスだけでなく、Cloudflareと隣接するデータセンター間のネットワークパス（通常は適切にプロビジョニングされ、より高い帯域幅を提供）を含むネットワークパスの組み合わせを反映していることを強調することが重要です。
上記の分布を最初に検査したところ、値が非常に高いように見えるため、疑わしい結果に直面しました。そして、その数値はBBR固有の動作を人為的なものであり、輻輳ウィンドウをパスの利用可能容量、帯域幅遅延製品（BDP）の推定よりも高く設定していることがわかりました。水増しは、設計によるものです。この仮説を証明するために、下の図は、BBRのBDPの推定値に沿って、上の分布を再度プロットしたものです。BBRの未確認パケットの輻輳ウィンドウとBDPの推定値の違いは明らかです。
上のプロットは、計算されたBDP値を接続テレメトリに与えて追加したものです。BDPの中央値は約77KB、つまり約50パケットになります。上記の輻輳ウィンドウ分布と比較すると、最近クローズされた接続からのBDP推定ははるかに安定していることがわかります。
これらのインサイトを基に、初期の輻輳ウィンドウサイズの妥当性とその状況の特定に役立てています。当社独自の社内実験では、ICWNDのサイズが小規模な接続では30～40%もパフォーマンスに影響することが明らかになりました。このような洞察は、10年以上にわたって10パケットがデフォルト値となってきた、より良い初期輻輳ウィンドウ値を見つける取り組みを再検討するのに役立つ可能性があります。
インターネット接続は非常に異機種な環境にあることが観測され、「象とマウス」という現象と一致する強い強いテールテールの特徴が数十年にわたる観察で確認されたことを確認しました。アップロードとダウンロードのバイト数の比率は、大規模なフローでは驚くことではありませんが、短いフローでは驚くほど小さく、インターネットトラフィックの非対称的な性質を浮き彫りにしています。こうした接続特性を理解することで、接続パフォーマンス、信頼性、ユーザーエクスペリエンスを改善する方法の情報が得られます。
当社はこの活動を基盤として構築し、他のユーザーが同様の恩恵を受けられるように、Cloudflare Radarで接続レベルの統計を公開する予定です。
ネットワークの改善に向けた当社の取り組みは継続中です。研究者、学術機関、インターン、この分野に関心をお持ちの皆様は、ask-research@cloudflare.comまでご連絡ください。知識を共有し、協力することで、インターネットを誰にとってもより速く、より安全で、より信頼性の高いものに変え続けることができます。