网络丢包引发页面卡顿

最好的事情总在不经意的时候出现，所以不必慌张赶路，按自己的节奏，步履不停地走过每一个今天

问题现象

最近，我们收到了公司的译码员反馈，称译码页面加载存在卡顿问题。从页面开始加载到能够进行交互需要花费5到6秒的时间，这对译码员的工作效率造成了严重影响。

分析与结论

我们意识到译码页面加载卡顿的问题对译码员的工作流程带来了不利影响。因此，我们立即组织了我们的技术团队对这个问题进行了详尽的定位和分析。

在我们对译码页面加载卡顿问题进行初步排查时，我们注意到与平时相比，获取页面所需资源的时间明显延长。具体表现在连接开始阶段（Connection Start）的初始TCP三次握手建立连接（Initial connection）、SSL/TLS握手过程以及请求/响应阶段（Request/Response）的等待服务器响应（Waiting for server response）。

根据之前提供的信息，我们初步推断译码页面加载卡顿问题可能与网络有关，但具体的原因尚不清楚。进一步地，我们的运维技术人员发现在当天网络环境中存在严重的丢包问题，丢包率高达25%。

在网络通信传输过程中，当数据包丢失时，发送端通常会设置一个超时时间。如果在超时时间内未收到接收端的确认消息，发送端会认为数据包已丢失，并触发重传机制。发送端会重新发送丢失的数据包到目标主机，重发的数据包与原始数据包相同。接收端在接收到重发的数据包后进行处理，并发送确认消息给发送端，表示已成功接收到数据包。

如果发送端在一定次数的重发后仍未收到接收端的确认消息，发送端可能会继续重发数据包，直到达到预设的重发次数上限或其他限制条件。这可以确保数据包的可靠传输，并尽量避免数据丢失。

如果达到重传次数上限后仍未收到确认消息，发送端会认为数据包无法成功传输，并终止通信。这样可以防止数据包无限重传，避免资源浪费和通信延迟。

尽管最终的请求成功了，但由于中间的丢包重传，导致请求过程中花费了大量的时间，进而延迟了后续资源加载和页面解析渲染的进行。

经过大约半个小时的时间，运维团队反馈称丢包率已经下降至2%。由于丢包率降低，译码员访问译码页面时不再遇到卡顿问题。

最终，与华为云技术支持人员的沟通结果揭示，广州城域网出口的一块 400G 板卡发生了故障。这个故障导致了部分网络线路的拥塞，进而影响了广州地区部分用户访问省内流量时出现了丢包问题。

场景复现

为了更好地理解和解决问题，我们决定在测试环境中对这个现象进行还原。

首先，为了模拟丢包现象，您可以使用网络模拟工具来模拟网络环境中的丢包情况。

如果您正在使用 MacBook，您可以使用名为 "Network Link Conditioner" 的工具来模拟网络环境中的丢包情况。关于 Network Link Conditioner 的详细安装和设置步骤参见官网 https://nshipster.com/network-link-conditioner/

创建了一个自定义的 Profile，并将丢包率设置为25%，在 Network Link Conditioner 设置界面中选择该 Profile，并启用它来模拟网络丢包现象。

在MacBook上，您可以使用MTR（My Traceroute）来进行网络诊断和性能分析。以下是在MacBook上安装和使用MTR的步骤：

1、安装MTR：在终端中输入以下命令并按下回车：

brew install mtr

2、运行MTR：在终端中输入以下命令并按下回车，替换目标地址（例如：example.com）：

sudo mtr example.com

然后访问译码页面，并使用 Wireshark 工具进行抓包分析

根据抓包情况分析，网络请求中的数据包丢失可能导致以下问题，从而增加了建立请求连接和客户端接收服务响应的延迟：

1、数据包重传：[TCP Retransmission]是Wireshark中用于标记TCP数据包的一种标记，表示该数据包是TCP协议的重传数据包。

在TCP协议中，发送方发送数据包给接收方，并等待接收方发送确认（ACK）来确认已成功接收数据。如果发送方在一定时间内没有收到确认，它会假设该数据包已丢失，并重新发送该数据包。

出现[TCP Retransmission]标记的数据包表示该数据包是之前发送过但未收到确认的数据包的重传。这可能发生在网络中存在丢包、延迟或拥塞等情况下，导致原始数据包未能按预期到达接收方。

2、数据包重复接收：[TCP Dup ACK 1056#1]（TCP重复确认号ACK 1056#1）是Wireshark中的一条信息，表示TCP通信中发生了重复的确认号（ACK）。

在TCP通信中，接收方会向发送方发送确认号来确认已经成功接收到的数据。当接收方收到重复的数据包时，它会发送重复的确认号。这种情况通常发生在网络中的数据包丢失或乱序到达时。

3、数据包乱序：[TCP Out-Of-Order]（乱序）是Wireshark中的一种标记，用于表示接收到的TCP数据包的顺序与发送方发送的顺序不一致。

在TCP协议中，数据包在传输过程中可能会经过不同的网络路径，这可能导致数据包到达接收方的顺序与发送方发送的顺序不一致。这种情况被称为TCP乱序。

当Wireshark检测到接收到的TCP数据包的顺序不正确时，它会将该数据包标记为[TCP Out-Of-Order]。这通常表示网络中存在一些问题，如网络拥塞、路由路径变化或数据包在网络中的不同路径上以不同的速度到达等。

TCP协议本身具有重新排序机制，接收方可以根据数据包的序号进行重新排序，以确保数据的顺序正确。因此，短暂的乱序通常不会对应用程序产生太大的影响。

然而，过多的乱序可能会导致性能下降和延迟增加。在某些情况下，过多的乱序可能会导致数据重传，从而影响应用程序的性能和吞吐量。