Condividi tramite

Diagnosticare la perdita di pacchetti

La perdita di pacchetti si verifica ogni volta che un pacchetto di rete non raggiunge la destinazione prevista. Alcune perdite di pacchetti sono normali e non sempre causano problemi di rete di livello superiore. In altri casi, la perdita di pacchetti può ridurre le prestazioni e causare errori nelle API o nelle applicazioni.

Acquisire e diagnosticare la perdita di pacchetti

Il primo passaggio durante l'esecuzione di un'indagine sulla perdita di pacchetti consiste nell'acquisire tracce Pktmon (Packet Monitor), in genere usando il flusso di lavoro della riga di comando pktmon. Pktmon può acquisire tracce di pacchetti, attribuire la perdita di pacchetti locali a motivi specifici e posizioni del codice e raccogliere statistiche sulla perdita di pacchetti. In combinazione con l'analisi wireshark del comportamento a livello di protocollo, le tracce pktmon sono sufficienti per identificare le cause radice di molti casi di perdita di pacchetti.

Se la diagnostica pktmon è inconcludente, è possibile acquisire tracce a livello di componente più complete usando rispettivamente il netsh.exe trace start scenario=InternetClient comando o netsh.exe trace start scenario=InternetServer per gli scenari client e server. Arrestare la traccia usando il comando netsh.exe trace stop dopo aver acquisito gli eventi. Queste tracce a livello di componente sono rumorose e non chiare, ma spesso contengono contesto aggiuntivo prima o dopo l'eliminazione di un pacchetto locale. Per la perdita remota, potrebbero indicare che il sistema locale deduce l'occorrenza della perdita di pacchetti. Le tracce possono essere convertite in testo usando netsh.exe trace convert nettrace.etl, aperte in Windows Performance Analyzer o usate con qualsiasi altro strumento ETW (Event Tracing for Windows).

Se si sospetta che la scheda di interfaccia di rete (NIC) sia la causa della perdita di pacchetti, è possibile monitorare i contatori di scarto tramite qualunque interfaccia dei contatori delle prestazioni o il cmdlet Get-NetAdapterStatistics.

Cause comuni della perdita di pacchetti locali

La perdita di pacchetti locali è completamente osservabile e può essere causata da vari fattori interni ed esterni.

  • Politica locale

    Il software di ispezione potrebbe causare l'eliminazione di pacchetti da computer remoti per impostazione predefinita, ad esempio quando Windows Firewall rifiuta i tentativi di connessione in ingresso. Anche la cybersecurity o il software antimalware nel sistema possono causare questi problemi.

  • Risorse basse

    Se il sistema o il socket esaurisce le risorse per gestire il pacchetto, il pacchetto viene eliminato. Esempi di limiti delle risorse includono la memoria fisica nel sistema e i buffer di invio o ricezione del socket. A seconda del limite di risorse, questi eventi potrebbero durare solo microsecondi, ad esempio quando la CPU del sistema non può reagire abbastanza rapidamente a un buffer di ricezione completo.

  • Errore ARP o ND

    Se l'hop successivo per un pacchetto in uscita non risponde alle richieste ARP (Address Resolution Protocol) o ND (Neighbor Discovery), i pacchetti inviati a tale hop successivo vengono eliminati nel sistema locale. I pacchetti possono anche essere eliminati durante i processi ARP o ND se viene superato il limite di coda pacchetti ARP o ND. I pacchetti ARP o ND stessi non vengono in genere eliminati localmente e appartengono alla categoria di perdita di pacchetti remoti.

  • Nessun itinerario

    Se il livello di rete non riesce a trovare una route valida verso la destinazione, è possibile che i pacchetti vengano eliminati.

  • Pacchetto non valido

    Se le intestazioni del pacchetto non sono valide, il pacchetto potrebbe essere eliminato. Ad esempio, le intestazioni di pacchetto contengono un checksum o un valore di campo non valido.

Cause comuni della perdita di pacchetti remoti

La perdita di pacchetti remoti non è osservabile direttamente nel computer locale quando il pacchetto viene eliminato. Protocollo Internet (IP) e la maggior parte dei livelli inferiori operano in modalità "best effort" e non sono affidabili. Il principio end-to-end richiede che gli endpoint implementino l'affidabilità all'interno dei protocolli se è necessaria la resilienza alla perdita di pacchetti. In alcuni scenari, la rete o l'endpoint remoto invia un messaggio di errore specifico del protocollo che indica il motivo della perdita. Tuttavia, in molti casi, l'unica indicazione di perdita di pacchetti è una mancanza di risposta.

  • Congestione

    Gli algoritmi di controllo della congestione basati sulla perdita inviano sempre più velocemente fino a quando un pacchetto non viene perso. Se l'algoritmo deduce che la perdita è causata dalla congestione, riduce temporaneamente la frequenza di invio in risposta. Questi algoritmi richiedono una piccola perdita per fornire un segnale di feedback.

  • Politica remota

    La rete o il computer remoto potrebbe eliminare pacchetti in base ai propri criteri.

  • Destinazione non raggiungibile

    Ciò può verificarsi se il computer remoto non ha un socket associato alla porta remota, il computer remoto è offline o la rete non riesce a trovare un percorso al computer remoto.

  • Perdita di sessione

    Se la rete ,inclusi NAT (Network Address Translation), i firewall e i servizi di bilanciamento del carico, o il computer remoto viene reimpostato o non riceve un pacchetto di recente, il contesto della sessione potrebbe scadere e i pacchetti successivi vengono eliminati.

  • Calo massimo dell'unità di trasmissione (MTU)

    Se le dimensioni di un pacchetto superano le dimensioni massime di trasmissione di un collegamento di rete verso la macchina remota, i drop di MTU potrebbero generare un errore: frammentazione ICMP (Internet Control Message Protocol) richiesta o pacchetto troppo grande.

Esempio di tracce di Monitoraggio pacchetti

Eseguire i comandi seguenti:

pktmon.exe start -c
pktmon.exe stop
pktmon.exe etl2txt PktMon.etl

Il file diPktMon.txt risultante contiene righe simili alle seguenti:

[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

Queste informazioni indicano che il pacchetto UDP in ingresso destinato alla porta 50005 viene eliminato perché non è associato alcun socket locale alla porta.

Esempio di tracce di Network Shell

Eseguire i comandi seguenti:

netsh.exe trace start scenario=InternetClient
netsh.exe trace stop
netsh.exe trace convert NetTrace.etl

Il file diNetTrace.txt risultante contiene righe simili alle seguenti:

[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.

Queste informazioni indicano che il pacchetto ICMP in uscita viene eliminato a causa dell'ispezione di Windows Filtering Platform (WFP). Il passaggio successivo per WFP consiste nel seguire la procedura di risoluzione dei problemi di WFP Live.

In un altro scenario, un segmento TCP inviato in precedenza non viene riconosciuto dall'endpoint remoto e alla fine viene attivato un timer di ritrasmissione locale, causando il nuovo invio di alcuni dei dati potenzialmente persi:

[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

Maggiori informazioni