Campo di battaglia: controlla la perdita di pacchetti e il tempo di ritorno dei pacchetti del gioco multiplayer

Sono consapevole che questa è una domanda insolita, ma sembra che le persone qui siano molto probabilmente quelle che possono aiutare. Sto cercando di eseguire il debug con il mio ISP perché sto avendo ritardi estremi durante il gioco.

Domanda: qual è un buon modo per analizzare il pacchetto-runtime e -loss che mi dà informazioni più dettagliate su dove si trova il collo di bottiglia nella connessione? Esiste un modo semplice per riprodurre artificialmente il traffico in una certa misura senza effettivamente giocare?

Ecco la mia situazione:

• Il mio ISP fornisce la mia connessione su una grande rete wireless con diversi punti di accesso su circa 10 km prima di raggiungere il cavo principale. È sempre stato così e in passato si è rivelato estremamente affidabile. A causa di cambiamenti nell'hardware o di altre modifiche all'installazione del mio ISP, la qualità del gioco è scesa diversi mesi fa. Il mio ISP è molto utile e cerca di trovare e risolvere l'origine dei problemi.
• In generale ho un ping molto buono e quando gioco, le informazioni di gioco mostrano sempre un buon ping di 20-30 ms.
• Una caratteristica di Battlefield è che mostra simboli di avvertimento quando il frame rate diminuisce, il tempo di consegna della connessione è cattivo o i pacchetti si perdono. La situazione che si ripete è che posso giocare circa 10-60 secondi senza alcun simbolo di avvertimento e quindi ho una grave perdita di pacchetti in cui ho ritardi e BF mi mostra tutti i tipi di avvisi di connessione. Dopodiché, posso giocare di nuovo per alcuni secondi prima di vedere di nuovo questo comportamento.

Sto lavorando esclusivamente su Linux e sono un po 'bene con ping, traceroute, nmapaltri strumenti di rete, e. Conosco le alte porte utilizzate da BF, posso scoprire le dimensioni dei pacchetti utilizzate e, naturalmente, posso estrarre gli IP dai server di gioco. Qual è un buon modo per iniziare a rintracciare questo problema in modo da poter sperare di provocare artificialmente la perdita di pacchetti mentre il mio ISP esegue il debug di ciò che accade nella sua rete?

Analisi

Ho installato WireShark come suggerito gentilmente da moonpoint e ho catturato alcuni minuti di gameplay ritardato. In una prima analisi, mi sono concentrato sui pacchetti che provengono dal server di gioco. Ho filtrato tutti i pacchetti UDP che provengono dal server al mio IP e ho regolato il tempo per vedere il tempo relativo tra quei pacchetti. Dopo l'ordinamento c'erano circa 20 pacchetti che impiegavano tra 650 e 1300 ms che sospetto siano quelli in cui sto saltando metà della mappa. Tra la maggior parte degli altri pacchetti hanno quasi esattamente il tempo di esecuzione che vedo come "Ping" all'interno del gioco di circa 30 ms.

Dopo aver contrassegnato tutti i pacchetti critici, ho cancellato il filtro e ho esaminato tutto il traffico per vedere se riesco a trovare un modello di ciò che è attivo con tutti i pacchetti attorno a quelli critici. Quello che ho scoperto è che ci sono due situazioni. Nota che 94.250.208.153 è il server di gioco e il punto culminante blu è il pacchetto di gioco UDP critico:

Innanzitutto, circa 10-15 pacchetti prima di quello critico esiste un mistico pacchetto M-Search SSDP proveniente da un indirizzo MAC:

La seconda situazione è che il pacchetto critico è preceduto (o talvolta circondato) da una ritrasmissione TCP principalmente a un server di Google:

Ci sono ulteriori passi che potrei prendere dalla mia parte? Qualcuno può dirmi come posso investigare nel pacchetto mistico SSDP?

L'MTR, che combina le funzionalità presenti nel ping e nel traceroute, può anche essere uno strumento utile per determinare il punto oi punti lungo un percorso di rete in cui si verifica la perdita di pacchetti o in cui il jitter è elevato ( esempio ).

È inoltre possibile utilizzare l' analizzatore di pacchetti Wireshark gratuito e open source per risolvere il problema, ma essere in grado di comprendere le informazioni fornite richiede familiarità con il funzionamento dei protocolli Internet sottostanti , come TCP / IP. Ci sono corsi e tutorial sul suo utilizzo online. Anche se imparare a usarlo in modo efficace può richiedere parecchio tempo, una volta appreso come utilizzare uno strumento come Wireshark, sarai in grado di risolvere più facilmente tutti i tipi di problemi che riguardano la connettività di rete.

Se non hai familiarità con Wireshark, su YouTube, c'è WireShark Tutorial per principianti e Wireshark 101: How to Wireshark, Haktip 115 ; molti altri possono essere trovati cercando i termini "Wireshark tutorial". I siti Web con esercitazioni includono l'esercitazione Wireshark rapida e sporca , Come utilizzare Wireshark per acquisire, filtrare e ispezionare i pacchetti e l' esercitazione Wireshark , che è un file PDF creato dal professor Angelos Stavrou nel dipartimento di informatica della George Mason University. Ci sono anche corsi online disponibili su come usare Wireshark.

Con Wireshark o tcpdump , uno strumento di acquisizione dei pacchetti della riga di comando disponibile per sistemi Linux, OS X e Microsoft Windows ( WinDump ), è possibile acquisire i pacchetti che fluiscono da e verso il sistema quando si verifica il problema in modo da poter analizzare i dati in un secondo momento o in tempo reale o, poiché entrambi gli strumenti possono salvare i dati acquisiti come file pcap , è possibile fornire i dati al personale di supporto della rete del proprio ISP, poiché il loro personale potrebbe avere familiarità con l'interpretazione di tali dati come file pcap sono un metodo comune per scambiare dati su un problema di rete tra i tecnici di rete durante il debug di un problema.

Wireshark acquisirà tutti i dati su un'interfaccia di rete, ma poiché conosci i numeri delle porte di rete e gli indirizzi IP associati ai server di gioco di Battlefield, puoi utilizzare un filtro Wireshark per filtrare i numeri di porta e / o l'indirizzo IP .

Aggiornare:

Le cifre esadecimali che hai visto associate al "pacchetto M-Search SSDP" non sono indirizzi MAC (Media Access Control) . Gli indirizzi MAC sono simili a 50-c5-8d-26-c2-06, ovvero gli indirizzi MAC Ethernet e Wi-Fi vengono solitamente visualizzati con trattini o due punti tra ogni due cifre esadecimali per un totale di 12 cifre, ovvero 48 -bit indirizzi. Quello che stai vedendo è invece un indirizzo IPv6 : ci sono due versioni del protocollo Internet in uso oggi su Internet, il protocollo Internet versione 4 (IPv4) a lungo usato e il protocollo Internet versione 6 (IPv6) più recente.

SSDP è l'acronimo di Simple Service Discovery Protocol , un protocollo utilizzato per Universal Plug and Play (UPnP) . Alcuni sistemi sulla rete locale, quello con indirizzo IPv6 fe80 :: 50e7: d4f0: db: c4dc, sta inviando un pacchetto a un indirizzo IP multicast , ff02 :: c. Per IPv4, l'indirizzo multicast è 239.255.255.250 mentre SSDP su IPv6 utilizza il set di indirizzi ff0X :: c per tutti gli intervalli di portata indicati da X ("X" nel pacchetto visualizzato è "2").

Non so perché il tuo sistema stia contattando l' indirizzo IP di Amazon Web Services (AWS) né l'indirizzo di Google.

C:\>nslookup 52.203.205.255 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Name:    ec2-52-203-205-255.compute-1.amazonaws.com
Address:  52.203.205.255


C:\>nslookup 216.58.212.78 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Name:    lhr35s05-in-f78.1e100.net
Address:  216.58.212.78 

Vedo che la connessione è alla porta 443, la ben nota porta per il traffico HTTPS, ma quando ho eseguito una ricerca IP inversa 52.203.205.255 utilizzando la funzione di ricerca IP inversa di DomainTools , è stato riportato "Non abbiamo trovato risultati per la tua ricerca." Spesso, inserendo un indirizzo IP in quello strumento di ricerca verranno mostrati i nomi di dominio completi (FQDN) per i siti Web ospitati all'indirizzo IP (più siti Web possono essere ospitati sullo stesso indirizzo IP), ma non in questo caso.

Una ricerca IP inversa 216.58.212.78 ha restituito lo stesso messaggio. Se vedi un 1e100.net, è un sistema Google. Google usa "1e100" nel nome perché è un modo per rappresentare un "1" con cento zero dopo di esso, che è un googol .

Entrambi questi pacchetti potrebbero non essere correlati alle comunicazioni con il server Battlefield. Il fatto che si tratti di ritrasmissioni, che vengono inviate quando un sistema ha inviato un pacchetto, ma non ha ricevuto un pacchetto di riconoscimento dall'altra parte che indica che è stato ricevuto, può tuttavia indicare che il traffico verso altri siti sta anche subendo una perdita di pacchetti sul contemporaneamente a problemi con il server Battlefield. È possibile filtrare questi due indirizzi IP per visualizzare altri pacchetti verso / da essi per avere una migliore idea del motivo per cui potrebbero apparire nell'acquisizione di pacchetti, se si fosse interessati al motivo per cui il proprio sistema sta comunicando con quei due indirizzi IP.