パケット損失は、ネットワーク パケットが目的の宛先に到達しない場合に発生します。 パケット損失の一部は正常であり、常に上位レベルのネットワークの問題が発生するとは限りません。 パケット損失によってパフォーマンスが低下し、アプリケーション プログラミング インターフェイス (API) またはアプリケーションが失敗することがあります。
パケット損失のキャプチャと診断
パケット損失の調査を行うときの最初の手順は、パケット モニター (Pktmon) トレースをキャプチャすることです。通常は、pktmon コマンド ライン ワークフローを使用します。 Pktmon は、パケット トレースをキャプチャし、ローカル パケット損失を特定の理由とコードの場所に属性付けし、パケット損失の統計情報を収集できます。 プロトコル レベルの動作の Wireshark 分析と組み合わせると、パケット損失の多くのケースの根本原因を特定するのに pktmon トレースで十分です。
pktmon 診断が決定的でない場合は、クライアントとサーバーのシナリオでそれぞれ netsh.exe trace start scenario=InternetClient または netsh.exe trace start scenario=InternetServer コマンドを使用して、より包括的なコンポーネント レベルのトレースをキャプチャできます。 イベントがキャプチャされたら、 netsh.exe trace stop コマンドを使用してトレースを停止します。 これらのコンポーネント レベルのトレースはノイズが多く、明確ではありませんが、多くの場合、ローカル パケットが破棄される前または後に追加のコンテキストが含まれます。 リモート損失の場合、ローカル システムがパケット損失の発生を推測することを示している可能性があります。 トレースは、 netsh.exe trace convert nettrace.etlを使用してテキストに変換したり、 Windows Performance Analyzer で開いたり、他の Event Tracing for Windows (ETW) ツールで使用したりできます。
ネットワーク インターフェイス カード (NIC) がパケット損失の原因として疑われる場合は、 パフォーマンス カウンター インターフェイスまたは Get-NetAdapterStatistics コマンドレットを使用してその破棄カウンターを監視できます。
ローカル パケット損失の一般的な原因
ローカル パケット損失は完全に監視可能であり、さまざまな内部要因と外部要因によって発生する可能性があります。
ローカル ポリシー
検査ソフトウェアでは、Windows ファイアウォールが受信接続の試行を拒否した場合など、リモート コンピューターからのパケットが既定で破棄される可能性があります。 システム上のサイバーセキュリティまたはマルウェア対策ソフトウェアも、これらの問題を引き起こす可能性があります。
リソースが少ない
システムまたはソケットがパケットを処理するためにリソースを使い切った場合、パケットは破棄されます。 リソース制限の例としては、システム上の物理メモリや、ソケットの送受信バッファーなどがあります。 リソースの制限によっては、システムの CPU が完全な受信バッファーに十分に迅速に反応できない場合など、これらのイベントはマイクロ秒単位で実行される場合があります。
ARP または ND エラー
送信パケットの次ホップがアドレス解決プロトコル (ARP) または近隣探索 (ND) 要求に応答しない場合、その次ホップに送信されたパケットはローカル システムで破棄されます。 ARP または ND パケット キューの制限を超えると、ARP または ND プロセス中にパケットがドロップされる可能性もあります。 通常、ARP または ND パケット自体はローカルにドロップされず、リモート パケット損失カテゴリに属します。
ルートなし
ネットワーク レイヤーが宛先への有効なルートを見つけられない場合は、パケットが破棄される可能性があります。
無効なパケット
パケット ヘッダーが無効な場合は、パケットが破棄される可能性があります。 たとえば、パケット ヘッダーに無効なチェックサムまたはフィールド値が含まれているとします。
リモート パケット損失の一般的な原因
リモート パケットの損失は、ローカル コンピューターではパケットが損失したときに直接観察されません。 インターネット プロトコル (IP) とその下のほとんどのレイヤーは "ベスト エフォート" であり、信頼性がありません。 エンドツーエンドの原則では、パケット損失に対する回復性が必要な場合は、エンドポイントがプロトコル内に信頼性を実装する必要があります。 一部のシナリオでは、ネットワークまたはリモート エンドポイントが、損失の理由を示すプロトコル固有のエラー メッセージを送信します。 ただし、多くの場合、パケット損失の唯一の兆候は応答の欠如です。
渋滞
損失ベースの輻輳制御アルゴリズムは、パケットが失われるまで、より高速かつ迅速に送信します。 アルゴリズムは、損失が 輻輳によって引き起こされたと推測した場合、応答する送信速度を一時的に低下させます。 これらのアルゴリズムでは、フィードバック信号を提供するために少量の損失が必要です。
リモート ポリシー
ネットワークまたはリモート コンピューターは、独自のポリシーに従ってパケットをドロップする可能性があります。
宛先に到達できない
これは、リモート コンピューターにリモート ポートにバインドされたソケットがない場合、リモート コンピューターがオフラインになっている場合、またはネットワークでリモート コンピューターへのパスが見つからない場合に発生する可能性があります。
セッション損失
ネットワーク (ステートフル ネットワーク アドレス変換 (NAT)、ファイアウォール、ロード バランサーを含む) またはリモート コンピューターがリセットされた場合、または最近パケットを受信しない場合、そのセッション コンテキストが期限切れになり、後続のパケットが破棄される可能性があります。
最大伝送ユニット (MTU) の低下
パケットのサイズがリモート マシンへのパスに沿ったネットワーク リンクの最大伝送サイズを超えると、MTU ドロップによってエラーが発生する可能性があります。インターネット制御メッセージ プロトコル (ICMP) の断片化が必要であるか、パケットが大きすぎます。
パケット モニター トレースの例
次のコマンドを実行してください:
pktmon.exe start -c
pktmon.exe stop
pktmon.exe etl2txt PktMon.etl
結果の PktMon.txt ファイルには、次のような行が含まれています。
[30]0000.0000::<DateTime> [Microsoft-Windows-PktMon] Drop: PktGroupId 8444249301423149, PktNumber 1, Appearance 0, Direction Rx , Type IP , Component 49, Filter 1, DropReason INET: transport endpoint was not found , DropLocation 0xE000460A, OriginalSize 402, LoggedSize 148
Drop: ip: 192.168.5.88.50005 > 192.168.5.68.50005: UDP, length 374
この情報は、ローカル ソケットがポートにバインドされていないため、ポート 50005 宛ての受信 UDP パケットが破棄されたことを示します。
ネットワーク シェル トレースの例
次のコマンドを実行してください:
netsh.exe trace start scenario=InternetClient
netsh.exe trace stop
netsh.exe trace convert NetTrace.etl
結果の NetTrace.txt ファイルには、次のような行が含まれています。
[30]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCPIP: Network layer (Protocol 1(ICMP), AddressFamily = 2(IPV4)) dropped 1 packet(s) on interface 13. SourceAddress = 192.168.5.68. DestAddress = 192.168.5.88. Reason = 9(Inspection drop). Direction = 0(Send). NBL = 0xFFFFE189BEAF3AC0.
この情報は、Windows フィルタリング プラットフォーム (WFP) 検査のために送信 ICMP パケットが破棄されたことを示します。 WFP の次の手順では、 WFP ライブ ドロップのトラブルシューティング手順に従います。
別のシナリオでは、以前に送信された TCP セグメントがリモート エンドポイントによって確認されず、最終的にローカル再送信タイマーが発生し、TCP によって失われる可能性のあるデータの一部が再送信されます。
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Connection 0xFFFFE189BD811AA0 0(RetransmitTimer) timer has expired.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Tail Loss Probe Event Connection = 0xFFFFE189BD811AA0, Event = 2(TimerFired).
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Tail Loss Probe Send Connection = 0xFFFFE189BD811AA0 SndUna = 2526318360, SndMax = 2526321759, SendAvailable = 3399, TailProbeSeq = 2526320299, TailProbeLast = 2526321759, ControlsToSend = 0, ThFlags = 16.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: connection 0xFFFFE189BD811AA0 (local=192.168.5.68:55330 remote=6.6.0.27:443): TCP send event, SeqNo = 2526320299, BytesSent = 1460, CWnd = 18538, SndWnd = 197632, SRtt = 17631, RttVar = 4947, RTO = 300, RcvWnd = 65535, PacingRate = 0, State = 4(EstablishedState), CongestionState = 0, SndUna = 2526318360, SndMax = 2526321759, RecoveryMax = 0, RcvBufSet = 0(FALSE), MaxRcvBuf = 65535.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: connection = 0xFFFFE189BD811AA0 send tracker marked a transmit as rexmit. Start = 2526320299, End = 2526321759, Timestamp = 467744252, InFlightCount = 2, SackedBytes = 0, BytesInFlight = 4859.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Connection 0xFFFFE189BD811AA0 0(RetransmitTimer) timer started. Scheduled to expire in 300 ms. Processor 31: LastInterruptTime 305324952689 100-ns ticks; LastMicrosecondCount 30532515324 msec