☰

戰地：檢查多人遊戲丟包和回包時間

tag-icon • tag-icon sniffing packet
戰地：檢查多人遊戲丟包和回包時間

我知道這是一個不尋常的問題，但似乎這裡的人很可能可以提供幫助。我正在嘗試與我的 ISP 一起調試為什麼我在遊戲過程中出現極度延遲。

問題：分析資料包運行時和丟失的好方法是什麼，可以為我提供有關連接瓶頸所在位置的更多詳細資訊？有沒有簡單的方法可以在某種程度上人為地重現流量而無需實際玩遊戲？

這是我的情況：

  • 我的 ISP 透過一個大型無線網路為我提供連接，該網路在到達主電纜之前有多個接入點，距離大約 10 公里。一直都是這樣，而且在過去，它被證明是極其可靠的。由於我的 ISP 的硬體變化或其他設定變化，幾個月前遊戲品質下降了。我的 ISP 非常樂於助人，並嘗試尋找並解決問題的根源。
  • 總的來說，我的 ping 值非常好，當我玩遊戲時，遊戲中的信息總是顯示 20-30 毫秒的良好 ping 值。
  • 《戰地》的一個特點是，當幀速率下降、連接週轉時間很差或資料包遺失時，它會顯示警告符號。重複的情況是，我可以在沒有任何警告符號的情況下玩大約 10-60 秒，然後我遇到嚴重的資料包丟失，出現延遲，並且 BF 向我顯示各種連接警告。之後，我可以再玩幾秒鐘，然後再看到這種行為。

ping我專門從事 Linux 工作，並且對、traceroute、nmap和其他網路工具有些熟悉。我知道 BF 使用的高端口，我可以找出使用的資料包大小，當然我可以從遊戲伺服器中提取 IP。有什麼好方法可以開始追蹤這個問題，以便我可以在 ISP 調試其網路中發生的情況時人為地引發資料包遺失？

分析

我按照 Moonpoint 的建議安裝了 WireShark，並捕捉了一些緩慢的遊戲畫面。在第一次分析中，我集中關注來自遊戲伺服器的資料包。我過濾了從伺服器發送到我的 IP 的所有 UDP 封包，並調整了時間以查看這些封包之間的相對時間。排序後，大約有 20 個資料包花費了 650 毫秒到 1300 毫秒的時間，我懷疑這些資料包是我跳過地圖的一半的資料包。大多數其他資料包之間的運行時間幾乎與我在遊戲中看到的「Ping」大約 30 毫秒完全一樣。

標記所有關鍵資料包後，我清除了過濾器並查看所有流量，看看是否可以找到關鍵資料包周圍所有資料包的某種模式。我發現有兩種情況。請注意，94.250.208.153 是遊戲伺服器，藍色突出顯示的是關鍵的 UDP 遊戲包：

首先，在關鍵封包之前大約 10-15 個封包有一個來自 MAC 位址的神秘 SSDP M-Search 封包：

影像

第二種情況是關鍵資料包之前（或有時包圍）有 TCP 重傳，主要發送到 Google 伺服器：

在此輸入影像描述

我可以採取任何進一步的措施嗎？有人可以告訴我如何調查神秘的 SSDP 資料包嗎？

答案1

MTR 結合了 ping 和 Traceroute 的功能，也可以成為一種有用的工具，用於確定網路路徑上發生封包遺失的一個或多個點。抖動高 （例子）。

您還可以使用免費和開源的Wireshark資料包分析器來解決問題，但是要理解它提供的資訊需要熟悉底層是如何運作的。網際網路協定，例如 TCP/IP，可以工作。網路上有關於其使用的課程和教程。儘管學習如何有效地使用它可能需要相當長的時間，但一旦您學會如何使用 Wireshark 等工具，您將能夠更輕鬆地解決涉及網路連線的各種問題。

如果你不熟悉 Wireshark，YouTube 上有WireShark 初學者教學和Wireshark 101：如何使用 Wireshark，Haktip 115;透過搜尋術語「Wireshark 教程」可以找到許多其他內容。提供教學的網站包括快速而骯髒的 Wireshark 教程,如何使用 Wireshark 擷取、過濾和檢查封包， 和Wireshark教程，這是一個由以下人員創建的 PDF 文件安傑洛斯·斯塔夫魯教授在喬治梅森大學計算機科學系。還有有關如何使用 Wireshark 的線上課程。

使用 Wireshark，或tcp轉儲，一個適用於 Linux、OS X 和 Microsoft Windows 的命令列資料包擷取工具（WinDump）系統，當問題發生時，您可以捕獲從系統流入或流向系統的數據包，以便您可以稍後或即時分析數據，或者，因為這兩種工具都可以將您捕獲的數據保存為聚氯乙烯文件中，您可以將數據提供給 ISP 的網路支援人員，因為他們的人員可能熟悉解釋此類數據，因為 pcap 檔案是網路工程師在調試問題時交換有關網路問題的數據的常用方法。

Wireshark 將捕獲網路介面上的所有數據，但由於您知道與戰地遊戲伺服器關聯的網路連接埠號碼和 IP 位址，因此您可以使用 Wireshark 過濾器來過濾連接埠號碼和/或 IP 位址。

更新：

這十六進位您看到的與「SSDP M-Search packet」相關的數字不是媒體存取控制（MAC）地址。 MAC位址類似50-c5-8d-26-c2-06，即乙太網路和Wi-Fi MAC位址通常每兩個十六進位數字之間以破折號或冒號顯示，總共12位，即48位元位址。相反，您所看到的是IPv6地址 - 當今互聯網上使用的互聯網協議有兩個版本，長期使用的網際網路通訊協定版本 4 (IPv4)以及更新的網際網路協定版本 6 (IPv6)。

SSDP 代表簡單服務發現協議，這是一個用於一般即插即用 (UPnP)。本機網路上的某些系統（具有 IPv6 位址 fe80::50e7:d4f0:db:c4dc）正在將封包傳送到IP組播地址，ff02::c。對於 IPv4，多播位址為 239.255.255.250，而 SSDP over IPv6 對 X 指示的所有範圍範圍使用位址集 ff0X::c（您看到的封包中的「X」是「2」）。

我不知道為什麼你的系統會聯繫亞馬遜網路服務 (AWS)IP 位址也不是 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

我看到連接是到連接埠 443，知名港口對於 HTTPS 流量，但是當我執行52.203.205.255 反向 IP 查找使用網域工具反向IP查找功能，它報告“我們沒有找到任何適合您的查找的結果。”通常，在該搜尋工具中輸入 IP 位址會顯示完全限定域名 (FQDN)對於在該 IP 位址上託管的網站（同一 IP 位址上可以託管多個網站），但在這種情況下則不然。

A216.58.212.78 反向 IP 查找返回了相同的訊息。如果您看到 1e100.net，那就是 Google 系統。 Google 在名稱中使用“1e100”，因為這是表示“1”後帶有一百個零的一種方式，這是古戈爾。

這兩個資料包可能與 Battlefield 伺服器的通訊無關。事實上，它們是重傳，當系統發送資料包但沒有從另一端收到表明已收到該資料包的確認資料包時發送，但可能表明到其他網站的流量也在該網站遇到資料包遺失。如果您對系統為何與這兩個IP 位址進行通訊感興趣，您可以對這兩個IP 位址進行過濾，以查看發送/來自它們的其他資料包，以便更好地了解它們為何出現在資料包捕獲中。

相關內容