帯域幅は速度ではない：遅延、ジッター、パケットロス、スループット、TTFB入門
未経験者向けにRTT遅延、ジッター、パケットロス、帯域幅、スループット、TTFBの違いを解説し、再現性のあるVPSネットワーク測定方法を提示します。
VPSプランを見る際、最も目立つのは1 Gbpsや10 Gbpsといった数値です。初心者は「このマシンは非常に高速だ」と受け取りがちですが、帯域幅は高速道路の車線幅（最大通行容量）のようなものです。道路が広くても、信号待ち、迂回、渋滞、事故があれば目的地に早く着くとは限りません。
ネットワークの品質は、遅延、ジッター、パケットロス、スループット、アプリケーション応答速度に分けて評価する必要があります。
一、遅延（レイテンシ）：往復にかかる時間
一般的なpingで測定されるのはRTT（Round-Trip Time、往復時間）です。手元の端末から宛先へパケットが届き、戻ってくるまでの所要時間をミリ秒（ms）で表します。
20 ms：操作の追従性が非常に高く快適
200 ms：1回ごとの送受信で明確な待ち時間を感じるこれは絶対基準ではなく目安です。Webページの表示には複数回の往復通信が必要であり、SSH操作もリアルタイムの双方向対話を伴います。そのため、下り帯域が広くても遅延が大きいと操作に「もたつき」を感じます。
二、ジッター：遅延の安定性
10回のRTT測定結果が40、41、39、42 msであれば安定しています。一方、40、180、55、300 msのように激しく変動する場合、平均値は悪く見えなくても体感レスポンスは著しく不安定になります。
この遅延のばらつきを「ジッター（揺らぎ）」と呼びます。音声通話、オンラインゲーム、リモートシェル、ビデオ会議などは、大容量ファイルのダウンロード以上にジッターの影響を受けやすくなります。
RFC 3393はIPパケット遅延変動の測定基準を定義しています。詳細な計算式を覚える必要はありませんが、平均遅延だけでなく測定サンプル間の安定性も極めて重要であることを理解しておきましょう。
三、パケットロス：送出したデータが届かない現象
パケットロスとは、送信されたパケットが制限時間内に宛先へ到達しない現象です。TCP等のプロトコルはデータを再送しますが、再送処理自体が時間と帯域を消費します。わずか数パーセントの継続的なロスであっても、SSHのフリーズ、ダウンロード速度の急減、音声の途切れを引き起こします。
RFC 2680が指摘するように、顕著なパケットロスはTCPが高いスループットを維持することを困難にします。さらに、往路と復路の経路が異なる場合、往復テストでは双方の損失が合算されてしまいます。
なお、一部のルーターはICMP応答の優先度を制限しています。pingでパケットロスが表示されても、実際のHTTPSやSSHサービスで同様のロスが発生しているとは限りません。実際のワークロードに近いプロトコルで測定することが重要です。
四、帯域幅とスループット：理論上限と実測値
| 項目 | 意味 |
|---|---|
| 帯域幅（Bandwidth） | インターフェースや回線が持つ理論上の最大容量 |
| スループット（Throughput） | 今回の測定で実際に転送成功したデータ量 |
| グッドプット（Goodput） | プロトコルオーバーヘッドや再送を除き、アプリが受信した正味データ量 |
VPSのスペック表に1 Gbpsとあっても、それはポートの規格上限です。実際のスループットは、共有回線の混雑、経由ルート、パケットロス、遅延、TCPウィンドウサイズ、ディスクI/O、CPU性能によって制約されます。
したがって、速度測定結果が低くても「回線が悪い」とは限りません。低速なストレージからの読み出しや、相手先サーバー側の速度制限によってボトルネックが生じる場合もあります。
五、TTFB：サーバーが応答を開始するまでの時間
TTFBはTime to First Byteの略で、HTTPリクエストを送信してから最初の1バイトを受信するまでの時間です。DNS解決、TCP接続、TLSハンドシェイク、ネットワーク往復、サーバー側処理時間が合算されます。
TTFBが大きい場合、回線遅延だけでなく、Webアプリケーションの重い処理、データベースクエリ、コールドスタートが原因の可能性があります。単なるpingよりもWeb体験の実態を反映しますが、ページ全体の完全描画時間とは異なります。
ping はネットワークの往復時間を測る；
TTFB はアプリが応答を返すまでの時間を測る；
完全読み込みには HTML、画像、CSS、JS、フォントの受信時間が加わる。六、1回のスピードテストで結論を出してはいけない理由
1回の測定は、その瞬間の特定の接続元、宛先、プロトコル、負荷状況を切り取ったスナップショットに過ぎません。有意義な比較を行うには、以下の条件を記録します：
- テスト実施日時；
- ローカル環境の回線事業者と接続方式；
- VPSの地域とテスト対象エンドポイント；
- 使用プロトコル（TCP、UDP、ICMP）；
- 測定時間、同時接続スレッド数、転送データ量；
- サーバーのCPU・ディスク負荷；
- 夜間の混雑ピーク時かどうか。
条件が揃っていなければ、測定数値の差異はVPS自体の性能差ではなくテスト手法の違いによって生じます。
七、初心者向けの4段階テスト手法
簡単な確認から実運用環境のテストへと段階的に進めます：
1. 到達性（Reachability）： ドメインが正しく解決され、TCP接続が確立できるか； 2. 回線品質（Quality）： 複数回のRTT測定で遅延、ジッター、パケットロスを確認する； 3. 伝送性能（Throughput）： 信頼できるツール（iperf3等）で実効スループットを計測する； 4. 実ワークロード（Application）： Webページの読み込み、SSH操作、API実行、実ファイル転送を試す。
出所不明な「ワンクリックベンチマークスクリプト」を安易にroot権限で実行しないでください。内容を確認せず未暗号化のHTTPからスクリプトをパイプ実行すると、サーバーの完全な制御権を第三者に明け渡すリスクがあります。
八、まとめ
ネットワークが「速い」かどうかは、単一の数値では測れません。
対話操作のスムーズさは「遅延とジッター」；
接続の安定性は「パケットロス」；
大容量ファイル転送は「実効スループット」；
Web表示は「TTFBとアセット描画完了時間」；
最終判断は「実際の業務アプリケーションの動作」。帯域幅は重要ですが、速度と同義ではありません。VPSにおいては、一時的なピーク速度よりも、安定して再現性のある実効性能こそが重要です。
よくある質問
pingが低いのにSSHが重いのはなぜですか？
瞬間的なジッター、TCPパケットロス、サーバー高負荷、端末の描画処理、復路ルーティングの遅延が考えられます。SSHのデバッグログやサーバー負荷を確認してください。
途中のホップで80%のパケットロスが出ていますが回線故障ですか？
後続のホップや最終目的地で損失がなければ、中継ルーターが診断パケットへの応答を制限しているだけです。
スピードテストで月間転送量を消費しますか？
はい。スループットテストは実際にデータを送受信するため、転送量を消費します。テスト前におよその通信量を見積もりましょう。
参考リンク
Share