☰

战地：检查多人游戏的数据包丢失和数据包返回时间

tag-icon • tag-icon sniffing packet
战地：检查多人游戏的数据包丢失和数据包返回时间

我知道这是一个不寻常的问题，但似乎这里的人很可能能提供帮助。我正在尝试使用我的 ISP 调试为什么我在玩游戏时会出现极端延迟。

问题：有什么好方法可以分析数据包运行时间和丢失情况，从而为我提供有关连接瓶颈的更多详细信息？有没有一种简单的方法可以在不实际玩游戏的情况下在一定程度上人工重现流量？

我的情况如下：

  • 我的 ISP 通过一个大型无线网络为我提供连接，该网络在到达主电缆之前有 10 公里的多个接入点。它一直都是这样，而且在过去，它被证明是非常可靠的。由于我的 ISP 的硬件或其他设置更改，几个月前游戏质量下降了。我的 ISP 非常乐于助人，并试图找到并解决问题的根源。
  • 我的 ping 值总体来说很好，当我玩游戏时，游戏内的信息总是显示 20-30ms 的良好 ping 值。
  • Battlefield 的一个功能是，当帧率下降、连接周转时间太长或数据包丢失时，它会显示警告符号。重复出现的情况是，我可以玩大约 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，或者tcpdump，适用于 Linux、OS X 和 Microsoft Windows 的命令行数据包捕获工具（转储) 系统，您可以在问题发生时捕获来自和流向系统的数据包，以便稍后或实时分析数据，或者，由于这两种工具都可以将您捕获的数据保存为数据包捕获文件，您可以将数据提供给您的 ISP 的网络支持人员，因为他们的人员可能熟悉解释此类数据，因为 pcap 文件是网络工程师在调试问题时就网络问题交换数据的常用方法。

Wireshark 将捕获网络接口上的所有数据，但由于您知道与 Battlefield 游戏服务器关联的网络端口号和 IP 地址，因此您可以使用 Wireshark 过滤器过滤端口号和/或 IP 地址。

更新：

这十六进制您看到的与“SSDP M-Search 数据包”相关的数字不是媒体访问控制 (MAC)地址。MAC 地址类似于 50-c5-8d-26-c2-06，即以太网和 Wi-Fi MAC 地址通常以每两个十六进制数字之间的破折号或冒号显示，总共 12 位数字，即它们是 48 位地址。您看到的是一个IPv6地址 - 目前互联网上使用的互联网协议有两个版本，长期使用的Internet 协议版本 4 (IPv4)以及更新的互联网协议版本 6 (IPv6)。

SSDP 代表简单服务发现协议，这是用于通用即插即用 (UPnP)。本地网络上的某个系统（IPv6 地址为 fe80::50e7:d4f0:db:c4dc 的系统）正在向IP 多播地址，ff02::c。对于 IPv4，多播地址为 239.255.255.250，而 IPv6 上的 SSDP 对 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 查找使用 DomainTools反向 IP 查询功能，它会报告“我们没有找到任何适合您查找的结果”。通常，在该搜索工具中输入 IP 地址会显示完全限定域名 (FQDN)对于托管在该 IP 地址上的网站（同一个 IP 地址上可以托管多个网站），但在这种情况下不行。

A216.58.212.78 反向 IP 查找返回了相同的消息。如果您看到 1e100.net，则这是 Google 系统。Google 在名称中使用“1e100”，因为这是表示“1”后面有一百个零的一种方式，这是一种古戈尔。

这两个数据包可能与 Battlefield 服务器的通信无关。事实上，它们是重传，即当系统发送数据包但未收到来自另一端的确认数据包（表明已收到数据包）时发送的数据包，这可能表明在您遇到 Battlefield 服务器问题的同时，其他站点的流量也在经历数据包丢失。如果您对系统为何与这两个 IP 地址通信感兴趣，您可以过滤这两个 IP 地址以查看往返于它们的其他数据包，以更好地了解它们为何会出现在数据包捕获中。

相关内容