遅延・パケットロスとは何か

遅延

遅延とは、パケットが送信元から宛先まで届くために時間がかかる状態です。

pingでは、Echo Requestを送信してEcho Replyが戻るまでの 往復時間（RTT：Round Trip Time）を確認できます。

パケットロス

パケットロスとは、送信されたパケットの一部が宛先まで届かず、 通信経路の途中などで失われる状態です。

TCP通信では再送によって補える場合がありますが、 再送が発生すると通信完了までの時間が長くなります。 音声や映像などリアルタイム性の高い通信では、 パケットロスが音切れや映像の乱れとして現れる場合があります。

ジッター

ジッターとは、パケットごとの遅延時間が一定ではなく、 到着間隔がばらつく状態です。

たとえばRTTが常に20ms程度であれば比較的安定しています。 一方で10ms、100ms、15ms、300msのように大きく変動する場合は、 平均値だけでは分からない品質劣化が発生しています。

症状から原因候補を考える

遅延やパケットロスは原因ではなく、 ネットワーク上で発生している問題の結果です。

まず利用者が感じている症状を具体化します。

調査前に整理する情報

コマンドを実行する前に、影響範囲を整理します。

遅延・パケットロスの基本調査フロー

いきなりWiresharkを起動するのではなく、 問題が発生している区間を大きく分けてから詳細調査へ進みます。

1. 影響範囲を確定する 1台だけか複数台か、特定VLAN・拠点・サーバーだけかを確認します。
2. 近い機器からpingする デフォルトゲートウェイ、同一LAN上の機器、遠隔サーバーの順に確認し、 問題区間を広げていきます。
3. 連続して測定する 4回程度のpingだけで判断せず、一定時間継続し、 RTTの変動とパケットロスの有無を確認します。
4. tracerouteで経路を確認する 想定経路を通っているか、経路変更が発生していないかを確認します。
5. 各インターフェースを確認する CRC、input error、output drop、discardなどが増加していないか確認します。
6. 帯域・CPU・キューを確認する トラフィック集中や装置負荷、QoSによるdropがないか確認します。
7. 必要に応じてパケットを取得する TCP再送、Duplicate ACK、応答時間などを確認します。
8. 時刻と根拠をまとめる 「どこが怪しいか」ではなく、取得した数値と時刻を根拠として報告します。

pingでRTTとパケットロスを確認する

最初に使用する代表的なコマンドがpingです。

pingでは主に、 到達性、RTT、パケットロスを確認できます。

Windowsで連続pingを実行する

ping 192.168.20.10 -n 20

例として、次の結果が得られたとします。

C:\>ping 192.168.20.10 -n 20


192.168.20.10 に ping を送信しています 32 バイトのデータ:
192.168.20.10 からの応答: バイト数 =32 時間 =5ms TTL=61
192.168.20.10 からの応答: バイト数 =32 時間 =6ms TTL=61
要求がタイムアウトしました。
192.168.20.10 からの応答: バイト数 =32 時間 =52ms TTL=61
192.168.20.10 からの応答: バイト数 =32 時間 =7ms TTL=61

192.168.20.10 の ping 統計:
パケット数: 送信 = 20、受信 = 19、損失 = 1
(5% の損失)

ラウンド トリップの概算時間:
最小 = 5ms、最大 = 52ms、平均 = 9ms

見るべきポイント

段階的にpingする

遠隔サーバーだけにpingしても、 問題がLANなのかWANなのか判断できません。

たとえば次の結果なら、LAN側よりWAN以降を優先して調べられます。

pingが失敗してもパケットロスとは限らない

tracerouteで経路を確認する

pingで遠隔地への遅延やロスを確認したら、 次に通信経路を確認します。

tracert 192.168.20.10

例：

C:\>tracert 192.168.20.10


192.168.20.10 へのルートをトレースしています

1     1 ms     1 ms     1 ms  192.168.10.1
2     3 ms     3 ms     4 ms  10.0.0.1
3    45 ms    48 ms    46 ms  10.0.1.1
4    47 ms    46 ms    48 ms  192.168.20.10

トレースを完了しました。

この例では、2ホップ目までは数msですが、 3ホップ目から約45msへ増加しています。

ただし、これだけで「3ホップ目のルーターが原因」と断定することはできません。

tracerouteで確認するポイント

• 想定している経路を通っているか
• 障害前と経路が変わっていないか
• 特定区間以降でRTTが継続して増えているか
• 冗長回線へ切り替わっていないか
• VPNやインターネット経路が変化していないか

Windowsではpathpingも利用できる

pathping 192.168.20.10

pathpingは経路を確認したあと一定時間測定し、 各区間のロスを調査する際の参考にできます。

ただし、途中機器がICMPへ応答しない場合や応答を制限している場合があるため、 pathpingの数値だけで原因機器を決定しないでください。

インターフェース統計を確認する

pingやtracerouteで怪しい区間を絞ったら、 実際にその区間を構成するスイッチやルーターの インターフェースを確認します。

Cisco IOS形式の例

show interfaces GigabitEthernet1/0/1

確認例：

GigabitEthernet1/0/1 is up, line protocol is up


MTU 1500 bytes, BW 1000000 Kbit/sec
5 minute input rate 120000000 bits/sec
5 minute output rate 930000000 bits/sec
245 input errors, 245 CRC
0 frame, 0 overrun, 0 ignored
0 output errors, 18452 interface resets
38742 output drops

この例では、特に CRCエラーとoutput drops に注目します。

重要なのは「増えているか」

エラーカウンターが100件あることだけでは、 現在の障害と関係しているか判断できません。

たとえば障害調査開始時にCRCが100、 5分後に500へ増えているのであれば、 現在もエラーが継続して発生している可能性が高まります。

output dropが増える場合

送信方向のトラフィックがインターフェースやキューの処理能力を上回ると、 パケットが破棄される場合があります。

CPUや装置負荷も確認する

ルーターやファイアウォールなどでは、 高CPUやセッション数増加などによって処理遅延が発生する場合があります。

ただし確認コマンドや正常値は製品によって異なるため、 対象機種の監視項目や公式ドキュメントと合わせて確認します。

Wiresharkで再送を確認する

ネットワーク上でTCPパケットが失われると、 送信側が同じデータを再送する場合があります。

Wiresharkでは、TCP再送を調べることで、 利用者が感じている「遅さ」とパケットロスの関係を確認できます。

代表的な表示フィルター

tcp.analysis.retransmission

再送関連を広めに確認する場合：

tcp.analysis.flags

Wireshark上で次のような表示が多く確認される場合は、 TCPが正常な順序で受信できていない可能性があります。

• TCP Retransmission
• TCP Fast Retransmission
• TCP Dup ACK
• TCP Out-Of-Order

両端でキャプチャーすると強力

送信側では存在するパケットが、 受信側のキャプチャーでは存在しない場合、 その2地点の間で失われた可能性を考えられます。

さらにネットワーク内部でキャプチャーポイントを追加すると、 発生区間をより細かく絞り込めます。

遅延・パケットロスのよくある原因

ネットワークかサーバーかを分ける

「Web画面が遅い」からといって、 ネットワーク障害とは限りません。

調査時の注意点とよくある勘違い

1．pingを4回実行して問題なしと判断する

断続的な障害では、短時間のpingだけでは再現しないことがあります。

発生頻度に応じて一定時間継続して確認し、 問題発生時刻と照合します。

2．平均RTTだけを見る

平均値が正常でも、一時的に数百msへ跳ねる状態が ユーザー体感へ影響する場合があります。

最小値・最大値・ばらつきも確認します。

3．tracerouteの「*」を障害と決めつける

中継ルーターがtracerouteへ応答しない場合があります。 最終宛先まで正常に到達しているなら、 「*」だけを根拠に障害とは判断できません。

4．途中ホップのRTTが高いだけで原因機器を決める

中継機器が自分宛ての制御通信への応答を低い優先度で処理していても、 転送パケット自体は正常な場合があります。

その後のホップでも遅延が継続しているか確認します。

5．累積カウンターだけを見る

CRCやdropの値が大きくても、 過去の障害で増えた値かもしれません。

調査中に値が増加しているか確認してください。

6．ネットワークだけを疑い続ける

ネットワーク経路のRTTやロスが正常なら、 サーバーCPU、アプリケーション、ストレージ、 データベースなど別レイヤーへ調査範囲を広げます。

調査結果の報告方法

障害対応では、 「ネットワークが怪しいと思います」では十分ではありません。

どの試験を行い、どの数値から、どの区間を疑っているのか を整理します。

英語ログ・検索キーワード

海外ベンダーの資料やサポート情報では、 次の表現がよく使用されます。

自分の言葉で説明する課題