故障排除 Socket 站点数据包丢失

问题

确定数据包丢失的来源及其原因并不总是容易。数据包在互联网上通过不同ISP和组织拥有的多个网络传输，并且您无法访问路径中的每个路由器以检查链接状态和中央处理器使用率等。此外，数据包丢失可能发生在网络路径的任何点。

可能的原因

数据包在途中丢失的原因有很多。一些常见的原因有：

ISP 对等问题
链接拥堵
配置错误（带宽设置或网卡速度和双工）
硬件故障
网络设备上的高中央处理器使用率
微爆处理

了解 Cato 的数据包丢失

识别 Cato 数据包丢失的一个良好方法是使用 Cato 管理应用程序中的分析屏幕。 数据包丢失和丢弃图显示了随时间的数据包丢失，并可让您专注于特定的时间段。这些图表帮助识别数据包丢失是否正在发生，以及过去何时发生。

注意：分析图中的最小数据存储桶样本大小为5秒。因此，5ms 内的微爆将会在显示的平均值中被标准化，而不会在分析图中显示为峰值。

1. 提供商丢失

发生在Socket和PoP之间。尽管大多数提供商数据包丢失是由 Cato 控制范围之外的最后一英里网络连接问题导致，但这不一定排除与 Cato 相关的问题。

Cato 如何测量提供商丢失

通过比较Socket和PoP上的给定链路上发送和接收的数据包数量来衡量提供商丢失。

下游数据包丢失是PoP发送的数据包数量与Socket接收的数据包数量之差，用百分比表示。

公式：

上游数据包丢失是Socket发送的数据包数量与PoP接收的数据包数量之差，用百分比表示。

公式：

由于Cato计算提供商数据包丢失的方式，尽管可能很容易，但你不能马上将所有责任归咎于ISP。可能是您在 Socket 和 ISP 路由器之间的设备导致了数据包丢失，或者可能网络路径靠近 PoP 的部分存在问题超出 ISP 的控制。

2. Cato 丢弃

发生在Cato QoS故意丢弃数据包时。 QoS引擎开始丢弃低优先级数据包当：

当链接上的总吞吐量与配置的带宽一致时，就会发生拥堵。
如果 BW 管理优先级配置了严格的吞吐量限制，并且匹配优先级的流量达到限制，Cato 也会丢弃数据包。
在突发期间（即使高优先级队列也可能丢失数据包）。

Cato丢弃的数据包丢失属于预期行为，不一定是问题的征兆。

与 Cato 丢弃数据包丢失相关的任何问题可能是由于配置错误造成。关键应用程序，如VoIP，应该被赋予最高的带宽管理优先级。如果发生拥塞，Cato会丢弃低优先级流量，但不会丢弃高优先级流量。确保适当的带宽管理优先级已分配给流量。

分析提供了对数据包丢失的广泛视图。然而，除非你正在处理Cato丢弃的数据包丢失，否则仅凭分析不能告诉你数据包丢失的原因或发生地点。

如何排除数据包丢失故障

1. 确定数据包丢失的范围

当你开始时，找出谁或什么正在经历数据包丢失是非常重要的。

所有用户都在一个站点经历数据包丢失，还是仅限于单个终端？
数据包丢失发生在互联网还是WAN上？
是多个站点受数据包丢失影响，还是只有一个站点？
所有流量是否受到影响，还是仅限于某个应用程序？
数据包丢失是持续的，还是仅间歇性发生？

了解上述问题的答案可以帮助您识别相关的CMA 事件，并在故障排除过程中节省时间。您提前知道的细节越多，故障排除的重点就越明确。

2. 检查站点分析 - 数据包丢失图

数据包丢失是否显示在站点分析数据包丢失图上？我们根据可能显示数据包丢失和丢弃的分析图给出不同的建议。

无数据包丢失

存在数据包丢失但是分析屏幕中未显示任何数据包丢失的可能性。可能存在本地网络问题，也可能是 PoP 相关问题。使用 UI 网络工具从 Socket 进行 LAN 端 IP 的 ping 操作可以有效识别根本原因。

数据包丢失

如果图上显示了数据包丢失，可能是由带宽配置错误引起的。请检查下面检查带宽配置中所述的已配置带宽。

对于提供商的数据包丢失，请检查是否仅在流量峰值（爆发）发生时出现丢弃。如果是这种情况，请使用应用分析页面识别导致峰值的流量。您可以通过将应用流量分配给限制性带宽管理配置文件来限制应用流量。

通常，我们会看到一些情况，总体吞吐量较低但爆发峰值导致数据包丢失。我们必须考虑到ISP有其自己的流量整形政策，在这种情况下，ISP的政策和Cato的流量整形政策可能有不同的突发性政策。有关突发性的更多信息，请参阅下面的检查微突发。

3. 检查站点分析 - 丢弃的数据包图表

对于Cato丢弃的数据包，您还应调查带宽优先级。在站点的分析屏幕下，检查优先级分析器以查看哪些优先级被丢弃。您可以扩展优先部分，以显示该优先级中的主要应用程序。如果数据包丢失仅影响特定应用程序，您可能需要提高网络规则中该应用程序的优先级。请记住，Cato的QoS设计用于在发生拥堵时丢弃低优先级的数据包，因此Cato丢弃的数据包丢失并不总是一个问题。

Cato的QoS还可能因队列中的突发性而丢弃任何数据包，无论优先级如何。此行为也是由于突发管理的性质而预期的。优先级分析器页面可用于确定交通突发是否与数据包丢弃同时发生。更多信息，请参见Socket流量优先级和QoS。

分析屏幕中的优先级分析器显示每个QoS优先级在上下行方向的数据包丢失。

4. 检查站点分析 - 最后一公里丢包率

为了评估ISP是否遇到问题，请使用分析屏幕中的最后一英里标签来检查WAN链路上是否有任何延迟变化或数据包丢失。与提供商的数据包丢失不同，最后一英里的数据基于对热门网站的ICMP测试。建议添加可ping的额外服务IP到最后一英里监控页面。例如，如果存在与VoIP相关的问题，SIP服务器IP可以作为其中一个IP。

如果怀疑与ISP相关的数据包丢失，请向您的ISP询问以下问题：

您是否在UDP/443或UDP/1337（DTLS）流量上应用QoS？
您是否对UDP流量应用任何DoS保护可能导致指向PoP IP的数据包丢失？
您的路由器在到PoP IP的路径上是否存在拥堵或高CPU情况？
您是否允许超过订阅线路速率的突发？

5. （可选）体验监控最后一英里

拥有体验监控许可证的客户可以检查最后一英里和应用程序性能选项卡，以查看可能的数据包丢失和丢弃。可以将数据与站点网络分析页面的结果关联，以更好地了解问题源头。

6. 更改DTLS端口UDP/443

有些ISP可能对UDP/443应用流量整形或QoS。即使链接稳定，这也可能导致数据包丢失。

在Socket配置中，将DTLS隧道端口从443更改为1337。
应用更改后，在分析屏幕监控数据包丢失和延迟。
如果数据包丢失改善，这证实ISP正在整形UDP/443流量。在这种情况下，将隧道保持在1337端口或向ISP升级问题。

7. 检查带宽配置

数据包丢失可能由链路拥堵引起，重要的是为每个WAN链路正确配置Cato 管理应用程序中的带宽。确保配置的带宽与ISP在站点配置中提供的带宽相匹配。根据Cato站点许可证的条款配置Socket WAN接口带宽设置。

Azure/AWS环境没有传统的带宽限制。相反，配置的站点带宽不应超过vSocket支持的带宽。对Azure而言，从版本21开始，Standard_D8ls_v5虚拟机尺寸支持高达2Gbps。在AWS中，c5n.xlarge实例尺寸提供超过2Gbps的带宽。确保站点配置的带宽在支持的限制范围内，以实现最佳性能至关重要。

如果配置的带宽低于ISP提供的带宽，当超过配置的带宽限制时，Cato的QoS引擎可能开始丢弃数据包。如果是这种情况，站点的分析吞吐量图表上会有一条与站点配置的带宽相等的水平线，以及Cato丢弃的数据包。

如果带宽配置正确，但ISP链路拥堵，这种行为也可能发生。尽管这种行为不能保证会出现问题，但在这种情况下，确认带宽配置正确是一个好习惯。

如果配置的带宽高于ISP提供的带宽，当超过ISP的带宽限制时，Cato的QoS引擎不会启动，因此ISP可能会随机丢弃数据包。如果是这种情况，您会看到站点分析吞吐量图表上水平线在配置的带宽水平以下以及提供商的数据包丢失。

每个Socket型号的Socket吞吐量和容量信息可以在Socket规格表中找到，请参阅本文：X1700，X1600 & X1500 Socket指南。

8. 检查Socket CPU性能

在 CMA 中的 网络分析 中，选择硬件标签。此部分显示每个核心的历史中央处理器使用率。

持续的中央处理器使用率超过 90% 可能对套接字性能产生负面影响，并可能导致丢包率和高延迟。如果观察到持续的高中央处理器使用率，请联系您的管理代表评估潜在的硬件更换（例如，从 X1500 到 X1600）。

如需进一步的故障排除，联系支持

实时Socket中央处理器使用率可以从Socket WebUI中的状态标签页查看。比较活跃使用情况与历史数据，以识别性能趋势。

9. 排除站点重新连接

站点重新连接到Cato Cloud是数据包丢失的一个来源。检查主页 > 事件以查看数据包丢失是否与重新连接事件相关。筛选事件为子类型=“重新连接”。

重新连接事件将显示一个说明断开连接原因的消息。查看了解重新连接事件

10. 绕过Cato

对于互联网数据包丢失，设置来源或目的地绕过以快速排除Cato Cloud的问题。最简单的方法是为单个用户IP地址在站点配置中设置来源绕过，看看数据包丢失是否继续。如果数据包丢失继续，问题可能出在局域网、Socket或ISP，但问题与PoP无关。

3._绕过_Cato_.png

11. 运行Ping测试

启动一个持续的ping，连接受数据包丢失影响的来源和目的地IP地址。 Ping更容易追踪，可以在数据包捕获中进行分析。当一些ping请求未到达目的地时，可能会出现数据包丢失，并显示为请求超时。

注意： 数据包捕获耗费CPU资源，可能导致性能下降。请确保数据包捕获已禁用，除非正在主动进行故障排除。

Socket UI还允许您使用ping工具通过主机名或IP进行ping。您可以选择要发送ping的接口，通过Cato或直接通过WAN链接发送。查找ping结果中的任何不一致，比如数据包丢失或高延迟。如果数据包丢失在Cato和不使用Cato的情况下都存在，则可能表明ISP问题。此外，如果其中一个链路是4G/LTE，您需要记住这些链路对数据包丢失更为敏感。

UI只发送10个ping请求，因此如果您需要更多ping，您将需要再次点击Ping按钮。

注意： Ping测试适合检查网络基本健康，但没有ping丢失不一定意味着线路干净。

12. 运行Traceroute测试

追踪路由用于识别来源和目的地之间的路由器（跳跃）。它将显示每个跳跃的数据包丢失和延迟。

可以通过Socket UI使用追踪路由工具运行追踪路由。运行追踪路由以查找套接字和目的地之间的WAN链路上的任何数据包丢失或非预期的高延迟。建议在运行测试和验证丢包率时设置最大计数（200）和最小间隔（0.1）。

Traceroute结果分析

请注意，任何单个跳跃显示的数据包丢失并不一定是问题的标志。单个跳跃可能会显示100%的数据包丢失，仅仅是因为路由器上未启用ICMP。由于ICMP速率限制，一个跳跃也可能显示小于100%的数据包丢失而没有问题。如果您在一个跳跃上看到一些数据包丢失而在下一个跳跃上是0%数据包丢失，您可能目睹了ICMP速率限制。

如果数据包丢失问题是真实存在的，它会从一个跳开始并在多个跳中继续，每个跳都会显示数据包丢失。也有可能是路径上的多个路由器导致数据包丢失，因此每个跳跃的数据包丢失量可能不同。例如，路线中有八个跳，追踪路由显示跳3-7的数据包丢失。

13. 使用Speedtest测试链接

实时屏幕可以帮助检测任何当前的吞吐量变化，以识别即时数据包丢失和丢弃的数据包。在故障排除时，使用Socket的速度测试工具模拟高负载并因需求过高而重现数据包丢失。

通过Cato的Socket Speedtest 结果预计应接近在Cato管理应用程序中配置的链路带宽。然而，DTLS隧道开销（117字节）会稍微减少吞吐量。

测试将使链路饱和，并在网络分析屏幕上显示任何与ISP相关的数据包丢失。如果配置的链路带宽小于ISP提供的带宽，则运行测试时预计会产生丢弃的数据包。

直接速度测试

通过WAN端口直接运行速度测试时，上行结果应接近Cato管理应用程序中配置的带宽许可。 Socket仍将按照站点的带宽许可为上行直接速度测试使用QoS。另一方面，下行结果将显示本地ISP的全部容量。

14. 使用iPerf测试链接

Socket WebUI允许您使用iPerf工具来解决Socket和Cato Cloud中已连接PoP之间的最后一英里性能问题。运行iPerf客户端的Socket会对运行在连接PoP上的iPerf服务器执行测试。

通过Cato和直接在Socket UI的工具页面上通过WAN运行iPerf测试。选择UDP作为协议（以排除TCP流控制），设置方向（上行或下行），目标速率为已配置带宽。此工具可以更好地确认通过Cato和WAN的吞吐量是否如预期。请注意DTLS隧道开销（117字节）可能会略微减少吞吐量。

在下例中，我们将目标速率设置为45Mbps（与Cato管理应用程序中配置的带宽相同），接收速率低于预期，丢包率为3.7%

15. 检查链路聚合（LAG）链接

数据包丢失和高延迟可能由Socket与内部交换机之间的链路聚合（LAG）配置错误引起。此特定问题无法在网络分析中检测到，而是需要在局域网中进行故障排除。 Cato仅支持静态LAG，且LAG对等体必须支持相同的模式。 LAG配置不匹配将导致数据包丢失。

了解更多故障排除信息，请参阅链路聚合 (LAG) 链接体验高延迟和数据包丢失

16. 检查Socket的链接速度

提供商丢失的一个可能原因是Socket链路以半双工运行。这意味着数据包只能同时在一个方向（出站或入站）传输，这会严重减少吞吐量并导致数据包丢失。所有Socket链接都应无例外地始终为全双工。

另外，请确保WAN和LAN的链接速度等于或高于为站点配置的带宽。链接速度可能是限制吞吐量的因素。例如，如果站点配置的带宽是200 Mbps 但LAN链接仅协商为100 Mbps全双工，则连接到Socket的计算机无法达到超过100 Mbps的吞吐量。

要检查链接状态，请登录到Socket UI并在监控页面上查看链接状态。下面的示例显示了WAN1链接在100 Mbps半双工时的状态。

如果您发现链接处于半双工或设置为错误的速度，请检查Socket链接所连接的设备上的端口设置。请确保其设置为自动协商或匹配Socket的速度设置。所有Socket链接默认设为自动协商，但您可以在网络设置页面下强制调整速度。

如果其他设备上的端口设置正确，以太网电缆可能已损坏。更换为已知良好的电缆，看看双工或速度是否会变化。如果仍然不行，将笔记本电脑或其他设备连接到Socket的端口并检查链接状态。在另一个设备上也重复这个步骤。如果Socket的链接在预期速度和全双工上线，但其他设备的链接没有，则表明问题出在其他设备上。

17. 检查重复IP

在Socket级别可能导致数据包丢失的另一个问题是网络中的重复IP地址。 Socket通常可以检测到与其已配置的接口IP地址发生的IP冲突。当同一网络上的两个设备被分配相同的IP地址时，就会存在IP冲突。如果发生这种情况，你将在Socket UI的监视页面上看到以下错误。

当WAN接口上配置了静态IP地址时，可能无法检测到重复的IP，因为Socket仅被动监控IP冲突。只有当Socket接收到来自冲突IP设备的ARP时，它才会检测到IP冲突。

一旦解决冲突IP问题，可能需要24小时才能从WebUI中消失警告。参见即使已解决，Socket UI仍报告IP地址冲突

18. 检查微突发

数据包丢失的另一个潜在原因是微爆发（突发性）。微爆发的特征是数据包或数据帧在非常短的时间内突然增加，通常仅持续几微秒到几毫秒。 在发生微爆发并超过链路速率限制的情况下，最后一英里提供商 (ISP) 可能会丢弃过多的流量，导致数据包丢失。

在下面的图表中，您可以看到典型的微爆发引起的数据包丢失以及调整突发值设置后的改进。

Inserting image...

在上述示例中，突发性水平值从默认值0.2已修改为0.01，意味着Socket和PoP对流量应用了更积极的整形，从而解决了数据包丢失的问题。

调整突发级别设置以缓解数据包丢失

上行和下行方向应用的默认突发值为0.2。通过此值，Socket和PoP将数据包尽可能快地序列化到媒体上，使时间段桶的前几微秒内发送更多字节。此设置通过减少序列化延迟和总体延迟来优化性能。

作为故障排除步骤的一部分，您需要逐步降低突发级别，直到数据包丢失得到缓解。随着突发级别值的降低，Socket和PoP在流量上应用更积极的整形，从而平滑微爆发。您可以配置的最低值是0.001。

调整突发级别的最佳实践是逐步降低值（例如，从0.2到0.18）。减少值后，通过分析实时或网络分析屏幕上的站点监控中数据包丢失的情况来监控影响。请记住，站点指标通常需要几分钟才能更新。继续降低突发值，直到数据包丢失得到缓解。

如果通过此程序无法解决数据包丢失，则意味着其原因不同于微爆发。在这种情况下，恢复突发默认值0.2并联系支持以获取进一步帮助。

修改突发级别

突发级别可以根据上行和下行方向进行调整。此设置会影响站点的所有WAN链接。

配置应用于站点级别或帐户级别。站点级别的配置优先于帐户级别。

要配置突发级别：

从导航菜单中，选择资源>高级配置用于帐户级别或选择站点配置>高级配置用于站点级别设置。
选择突发下行值或突发上行值。
启用设置，并在0.001 - 0.2范围内调整值。
点击应用
点击保存

注意：

如果 burstiness 是由 Cato 支持预先调整的，则会显示调整后的值，而不是默认值 0.2
burstiness值只能为Socket站点调整
Cato 管理应用程序中最小的数据存储桶是 5 秒，微型爆发在最小的数据存储桶中被标准化，通常很难识别。
由于可能导致站点的连接问题，因此不推荐将突发性值设置为0.001对于带宽为10 Mbps及以下的站点。