TCP与UDP深度解析：从协议原理到工程实践与性能调优-育师

1. 项目概述：为什么我们还在争论TCP和UDP？

如果你写过网络应用，或者调试过网络问题，大概率都听过这两个名字：TCP和UDP。它们就像网络世界的“快递公司”，负责把数据从一台计算机搬运到另一台。但这两家“公司”的风格截然不同：一家是“顺丰”，承诺必达、保证顺序、丢了包还给你重发；另一家是“同城闪送”，只管发、不管到，速度飞快但可能丢件。这个项目，就是要把这两大传输层协议的里里外外、前世今生、应用场景和实操细节，掰开揉碎了讲清楚。

这不仅仅是应付考试的理论知识。理解TCP和UDP的差异，直接决定了你写的程序在网络上的表现。比如，你做一个实时视频会议软件，用TCP可能会因为重传导致画面卡顿和延迟飙升，而UDP虽然会丢几帧画面，但整体流畅度反而更好。反过来，你做一个文件传输或者网页浏览服务，用UDP的话，丢一个关键数据包整个文件可能就废了，而TCP能确保数据完整无误。所以，搞懂它们，是每一个需要和网络打交道的开发者、运维甚至产品经理的基本功。这篇文章，我会结合我十多年踩坑的经验，不仅讲清楚原理，更会聚焦于它们在实际开发、运维中的选择、调优和问题排查。

2. 核心协议原理深度对比：不只是“可靠”与“不可靠”

很多人对TCP和UDP的认知停留在“TCP可靠，UDP不可靠”这个层面。这没错，但太笼统了。我们需要深入它们的“基因”层面，看看这种差异是如何产生的，以及带来了哪些连锁反应。

2.1 TCP：面向连接的“会话大师”

你可以把TCP想象成打电话。拨号（三次握手）建立连接，双方确认在线，然后开始通话（数据传输），期间你会说“嗯”、“对”来确认对方的话你听到了（ACK确认），最后说“再见”挂断（四次挥手）。这个过程保证了对话的完整性和顺序。

1. 核心机制拆解：

三次握手建立连接：这是TCP可靠性的基石。客户端发送SYN，服务器回复SYN+ACK，客户端再回复ACK。这个过程同步了双方的初始序列号，为后续的按序传输和流量控制打下基础。为什么是三次，不是两次？主要是为了防止已失效的连接请求报文突然又传到了服务器，导致服务器错误地打开连接。三次握手是理论上建立可靠连接的最小次数。
序列号与确认应答：每个字节的数据都被赋予一个序列号。接收方收到数据后，会回复一个ACK包，指明“我期望收到的下一个序列号是什么”。如果发送方在一定时间（超时重传时间RTO）内没收到ACK，就会认为数据包丢失，触发重传。这是可靠传输的核心。
流量控制：通过滑动窗口机制实现。接收方在ACK包中会告知发送方自己当前还有多少缓冲区（接收窗口大小）。发送方根据这个窗口大小调整发送速率，防止发送过快导致接收方缓冲区溢出、数据被丢弃。这解决了“发得快”和“收得慢”的矛盾。
拥塞控制：这是TCP最精妙的部分之一，它解决的是“网络堵车”问题。TCP会动态探测网络的拥堵程度，并通过一系列算法（如慢启动、拥塞避免、快速重传、快速恢复）来调整自己的发送窗口。核心思想是：网络空闲时大胆加速，有丢包（拥堵信号）时迅速减速。这保证了TCP不会成为网络的“洪水猛兽”。

2. TCP的“代价”：可靠性不是免费的。三次握手带来了至少1.5个RTT（往返时间）的连接建立延迟。确认、重传机制在丢包严重的网络（如无线网络）下会导致延迟抖动剧烈。头部开销较大（至少20字节），且由于要保证顺序，后发的包必须等先发的包确认后才能继续，这被称为“队头阻塞”。

注意：很多人误以为TCP绝对不丢数据。实际上，TCP的“可靠”是指它在协议层面尽力通过重传来保证数据交付。但如果网络彻底中断，或者连接因异常断开，应用层没有及时保存已接收的数据，数据依然会丢失。TCP提供的是传输通道的可靠性，而非应用状态的持久性。

2.2 UDP：无连接的“独行侠”

UDP则像寄明信片。你写好地址内容扔进邮筒，邮局（网络）会尽力帮你送，但不保证一定能送到，也不保证按你投递的顺序到达，更不会告诉你对方收没收到。它极其简单。

1. 核心特性解析：

无连接：发送数据前无需建立连接，减少了延迟。
不可靠：不提供确认、重传、排序机制。数据报可能丢失、重复、乱序。
面向报文：对应用层交下来的报文，添加UDP头部后直接交给网络层，不会合并或拆分。这保留了报文的边界。
头部开销小：只有8字节（源端口、目的端口、长度、校验和），效率高。
无拥塞控制：发送速率完全由应用层控制。这既是优点（速度上限高），也是缺点（容易加剧网络拥堵）。

2. UDP的“用武之地”：正是因为它“不可靠”和“无控制”，UDP在特定场景下优势巨大。它没有连接建立延迟，没有重传导致的延迟抖动，没有拥塞控制的速度限制，头部开销小。这使得它成为对延迟极度敏感、允许少量数据丢失的应用的首选。

3. 关键误区澄清：“UDP比TCP快”是一个不严谨的说法。在理想网络（零丢包、低延迟）下，两者传输速度的瓶颈在于带宽和主机处理能力，差异不大。UDP的“快”，主要体现在低延迟和低延迟抖动上，因为它避免了TCP握手、重传、拥塞控制算法引入的等待时间。在网络拥堵时，无拥塞控制的UDP可能会抢占大量带宽，导致自身和TCP流都性能下降。

3. 应用场景抉择：何时用TCP？何时用UDP？

理论懂了，到底怎么选？这没有银弹，完全取决于你的应用需求。我画了一个简单的决策流程图，但更重要的是理解背后的权衡。

选择TCP的场景（需要可靠、有序的数据流）：

Web服务：HTTP/HTTPS、FTP、SMTP等，一个字节的错误都可能导致页面无法渲染或文件损坏。
文件传输：任何需要完整无误传输数据的场景，如云盘同步、软件更新。
数据库访问：查询和事务操作必须保证数据的准确性和一致性。
远程登录：SSH、Telnet，你的每一条命令都需要被服务器准确接收和执行。
消息队列：如RabbitMQ的AMQP协议，需要保证消息不丢失、不重复。

选择UDP的场景（容忍丢失，追求实时性）：

实时音视频：视频会议（Zoom、Teams底层大量用UDP）、直播、在线游戏语音。丢失一两个视频帧或音频包，人眼/人耳几乎无法察觉，但等待重传导致的卡顿是无法接受的。
实时游戏：多人在线游戏（如MOBA、FPS）的状态同步。玩家的位置信息更新极快，旧的位置信息很快失效，丢失一个包直接用最新的状态更新即可，重传旧数据毫无意义。QUIC（HTTP/3的基础）就在UDP上实现了可靠传输，以解决TCP队头阻塞问题。
DNS查询：域名解析请求很小，且需要快速响应。如果一次查询失败，应用可以立即重试，使用UDP效率更高。
网络监控与发现：如DHCP、SNMP Trap、服务发现协议（如mDNS/Bonjour）。这些协议通常是广播或单次请求/响应模式，无连接特性很合适。
IoT传感器数据流：某些传感器高频发送读数，丢失个别数据点对整体趋势分析影响不大，但低功耗和实时性更重要。

一个重要的混合模式：在UDP之上实现自定义可靠性。这是很多高级应用的玩法。比如，一个游戏引擎可能用UDP发送玩家的实时位置和动作（不可靠），但同时用一条在UDP上自研的可靠信道来发送关键的聊天消息或交易指令。这样既享受了UDP的低延迟，又在需要的地方保证了可靠。

实操心得：不要陷入非此即彼的思维。现代复杂应用往往是混合使用。例如，一个视频会议应用：音视频流用UDP（或基于UDP的RTP协议），而信令控制（如加入房间、举手功能）则用TCP（或基于TCP的WebSocket/HTTP）。在做技术选型时，先分解你的数据流，看每一类数据对可靠性、实时性、吞吐量的要求到底是什么。

4. 协议头部与数据包结构全解析

理解协议，必须看它的“身份证”——协议头部。这能帮你更好地进行网络抓包分析。

4.1 TCP报文段头部详解（通常20字节）

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 源端口号 (16位) | 目的端口号 (16位) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 序列号 (32位) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 确认号 (32位) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 数据偏移 | 保留 | 控制标志位 | 窗口大小 (16位) | | (4位) | (6位)| U A P R S F| | | | | R C S S Y I | | | | | G K H T N N | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 校验和 (16位) | 紧急指针 (16位) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 选项和填充 (可选，变长) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 数据 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键字段实操意义：

序列号/确认号：抓包时（如用Wireshark），这是分析数据流顺序、确认和重传行为的关键。Seq和Ack的数字是相对值还是绝对值，取决于Wireshark的偏好设置，分析时要注意。
控制标志位：
- SYN：同步，用于建立连接。
- ACK：确认，表示确认号字段有效。
- FIN：终止，用于关闭连接。
- RST：复位，用来异常关闭连接。
- PSH：推送，提示接收端应立即将数据提交给应用层。
- URG：紧急，表示紧急指针字段有效（现已很少使用）。
窗口大小：这是接收方通告的剩余缓冲区大小。在分析网络性能瓶颈时，如果看到窗口大小经常变为0或很小，说明接收方应用处理太慢，可能是性能瓶颈点。可以通过调整应用读取Socket缓冲区的速度，或适当增大内核的TCP接收缓冲区来缓解。
校验和：覆盖头部、数据和伪IP头部。用于检测传输过程中的比特错误。虽然现在链路层可靠性很高，但校验和错误仍可能指示硬件问题或内存错误。

4.2 UDP数据报头部详解（固定8字节）

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 源端口号 (16位) | 目的端口号 (16位) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 长度 (16位) | 校验和 (16位) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 数据 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键字段实操意义：

长度：指整个UDP数据报的长度（头部+数据），最小为8字节（只有头部）。这有助于接收方识别数据报边界。
校验和：可选字段，但在IPv4中建议使用，在IPv6中强制使用。如果发送方计算校验和为0，表示未使用校验和。在追求极致性能的内网应用中，有时会禁用UDP校验和以减少CPU开销，但这会牺牲数据完整性，需谨慎评估。

对比小结：TCP头部复杂，承载了连接状态、流量控制、拥塞控制等大量信息；UDP头部极其简洁，只做最基本的多路复用（端口）和错误检查。这种结构差异直接体现了它们设计哲学的不同。

5. 核心机制与算法实战剖析

这部分我们深入两个协议最核心的算法，理解它们如何工作，以及如何影响你的程序。

5.1 TCP的拥塞控制：从“慢启动”到“BBR”

TCP的拥塞控制算法经历了多个版本的演进，目标是公平、高效地利用网络带宽。

1. 经典四阶段（Reno算法及其变种）：

慢启动：连接开始时或超时重传后，拥塞窗口从一个很小的值（如1个MSS）开始，每收到一个ACK，窗口就增加一个MSS。这使窗口呈指数增长，快速探测可用带宽。
拥塞避免：当窗口增长到慢启动阈值时，进入线性增长阶段，每RTT时间窗口增加1个MSS。这是为了避免增长过快冲垮网络。
快速重传与快速恢复：当收到3个重复的ACK时（表明有包丢失，但后续的包还能收到），TCP会立即重传丢失的包，并将窗口减半，然后进入拥塞避免阶段。这比等待超时重传要快得多，是性能优化的关键。

2. 现代算法：CUBIC与BBR

CUBIC：Linux默认的算法。它使用一个立方函数来调整窗口大小，在丢包后能更快地恢复到之前的峰值速率，在高带宽、高延迟的网络（如跨洋链路）上表现比Reno更好。
BBR：由Google提出，其思路是主动测量网络的最小RTT和最大带宽，并以此为基础来 pacing 发送速率，而不是依赖丢包作为拥塞信号。BBR在有一定丢包率的网络（如无线网络）上往往能获得更高的吞吐量和更低的延迟。你可以通过sysctl net.ipv4.tcp_congestion_control查看和修改Linux系统的拥塞控制算法。

3. 对应用层的影响：拥塞控制决定了TCP连接的吞吐量随时间变化的曲线。对于需要稳定高带宽的应用（如大文件下载），理解这一点很重要。有时，一个TCP连接在刚开始的几秒内速度很慢（慢启动），然后才逐渐跑满带宽。对于短连接（如HTTP请求），可能整个生命周期都处在慢启动阶段，性能受限。这就是为什么HTTP/2和QUIC要复用连接，避免频繁的慢启动。

5.2 UDP的应用层可靠性实现思路

既然UDP不可靠，那如何在需要可靠性的场景下使用它呢？答案是在应用层实现部分可靠性机制。

1. 选择性重传：不像TCP的累积确认，应用层可以实现类似SACK（选择性确认）的机制。接收方可以明确告知发送方：“我收到了包1，3，4，但包2丢了”。发送方只需重传包2，而不是像早期TCP那样重传2及之后的所有包。这大大提高了重传效率。

2. 前向纠错：在发送数据时，额外发送一些纠错信息（如使用Reed-Solomon编码）。即使丢失了部分原始数据包，接收方也能通过纠错信息恢复出原始数据。这在直播等场景中常用，用一定的带宽开销换取更低的延迟（无需等待重传）。

3. 速率控制：UDP本身没有拥塞控制，所以应用层必须自己实现，否则会成为“网络公敌”。一种简单的方法是实现一个与TCP友好的速率控制算法，例如模仿TCP的AIMD（加性增、乘性减）逻辑，根据丢包或延迟增加来调整发送速率。

4. 序列号与定时器：为每个数据包分配一个应用层的序列号，用于检测丢包和乱序。为每个已发送但未确认的包启动一个定时器，超时则重传。这其实就是实现了一个简化版的TCP。

注意事项：自己实现一套完整的可靠UDP协议非常复杂，容易引入bug，且很难做到像TCP那样经过几十年锤炼的健壮性和公平性。除非有非常特殊的性能需求（如定制游戏协议），否则建议优先使用成熟的库，如用于可靠UDP传输的ENet，或者直接使用基于UDP的QUIC协议。

6. 套接字编程实战要点与代码示例

理论最终要落地到代码。这里以Linux C/C++为例，讲解TCP和UDP套接字编程的关键区别和易错点。

6.1 TCP套接字编程流程与陷阱

TCP是面向流的，这意味着在接收端，你读取到的字节流可能不完整对应发送端的一次send调用。

服务端典型流程：

socket()创建套接字。
bind()绑定IP和端口。
listen()开始监听。
accept()接受连接，返回一个新的连接套接字用于通信。
用连接套接字进行read()/write()或recv()/send()。
通信完毕，close()套接字。

客户端典型流程：

socket()创建套接字。
connect()连接服务器（触发三次握手）。
连接成功后进行read()/write()。
close()关闭连接（触发四次挥手）。

关键陷阱与解决方案：

陷阱	现象	原因与解决方案
粘包/拆包	发送方分两次发送“Hello”和“World”，接收方一次收到“HelloWorld”。	TCP是字节流，无边界。解决方案：1. 定长报文；2. 使用分隔符（如`\n`）；3. 在报文头部添加长度字段（最常用）。
`close()`与`shutdown()`	调用`close()`后，对方可能收不到最后的数据。	`close()`立即终止读写两个方向。`shutdown()`可以只关闭读或写方向。优雅关闭通常：先`shutdown(SHUT_WR)`发送FIN，然后继续`read()`直到收到对方的FIN（返回0），最后再`close()`。
TIME_WAIT状态	服务器主动关闭连接后，端口会处于TIME_WAIT状态约2MSL时间，无法立即重用。	这是TCP协议为了保证可靠终止设计的。解决方案：设置套接字选项`SO_REUSEADDR`，允许端口重用。`setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval))`。
非阻塞IO与EAGAIN	在非阻塞套接字上调用`read()`，返回-1且errno为`EAGAIN`或`EWOULDBLOCK`。	这不是错误，表示当前无数据可读。应用层需要等待（如用`select/poll/epoll`）直到套接字可读再尝试。

一个简单的带长度头的TCP消息处理示例（伪代码）：

// 发送方 void send_message(int sockfd, const char* data, int len) { uint32_t net_len = htonl(len); // 将长度转换为网络字节序 write(sockfd, &net_len, sizeof(net_len)); // 先发送4字节长度头 write(sockfd, data, len); // 再发送实际数据 } // 接收方 int read_message(int sockfd, char* buffer, int buf_size) { uint32_t net_len; int n = read(sockfd, &net_len, sizeof(net_len)); if (n != sizeof(net_len)) return -1; // 读取长度头失败 int len = ntohl(net_len); // 转换为主机字节序 if (len > buf_size) return -2; // 消息太长，缓冲区不足 int total = 0; while (total < len) { n = read(sockfd, buffer + total, len - total); if (n <= 0) return -1; // 读取数据失败或连接关闭 total += n; } return len; // 返回实际读取的消息长度 }

6.2 UDP套接字编程流程与要点

UDP是面向数据报的，一次sendto对应一次recvfrom，消息边界自然保持。

服务端/客户端流程类似（无连接概念）：

socket()创建套接字（类型为SOCK_DGRAM）。
bind()（服务端必须，客户端可选）。
使用sendto()和recvfrom()指定对端地址进行通信。
close()。

关键陷阱与解决方案：

陷阱	现象	原因与解决方案
数据报丢失	`sendto`成功，但对方没收到。	UDP不保证交付。解决方案：应用层实现确认重传机制，或接受丢失（如音视频）。
缓冲区大小	发送的数据报大于路径MTU，导致IP层分片。	IP分片降低效率且易丢失（一片丢，全部丢）。解决方案：应用层控制发送的UDP包大小，通常不超过1472字节（以太网1500 MTU - IP头20 - UDP头8）。使用`setsockopt`设置`SO_SNDBUF`和`SO_RCVBUF`。
`recvfrom`地址复用	从多个客户端接收数据，需要区分来源。	`recvfrom`的地址参数会填充发送方的地址。服务端必须根据此地址回复特定客户端。
ICMP错误处理	向一个未监听的端口发送UDP，可能收到ICMP“端口不可达”错误。	默认情况下，这个错误不会直接反馈给应用层，后续的`recvfrom`可能会阻塞或失败。可以设置套接字为非阻塞，或使用`connect()`到UDP套接字（使该套接字与特定地址关联），这样ICMP错误会导致后续的`send`或`recv`失败。

UDP服务端处理多个客户端的典型模式：

int sockfd = socket(AF_INET, SOCK_DGRAM, 0); bind(sockfd, ...); struct sockaddr_in client_addr; socklen_t addr_len = sizeof(client_addr); char buffer[BUFFER_SIZE]; while (1) { // 接收数据，同时获取客户端地址 int n = recvfrom(sockfd, buffer, BUFFER_SIZE, 0, (struct sockaddr*)&client_addr, &addr_len); if (n > 0) { // 处理数据... // 使用获取到的client_addr回复该客户端 sendto(sockfd, response, resp_len, 0, (struct sockaddr*)&client_addr, addr_len); } }

7. 性能调优与网络问题排查实战

理解了协议和编程，我们最终要面对的是真实网络环境中的性能问题和故障。

7.1 TCP性能调优核心参数

在Linux系统中，通过sysctl可以调整大量TCP参数。以下是一些关键参数：

参数	默认值（可能因系统而异）	说明与调优建议
`net.ipv4.tcp_window_scaling`	1	启用窗口缩放因子，支持大于64KB的窗口，必须开启以利用高带宽延迟积网络。
`net.ipv4.tcp_timestamps`	1	启用时间戳，用于精确计算RTT和防止序列号回绕，建议开启。
`net.core.rmem_max`/`wmem_max`	系统定义	设置套接字接收/发送缓冲区的最大字节数。对于高吞吐连接，需要增大。
`net.ipv4.tcp_rmem`/`tcp_wmem`	3个整数：min, default, max	TCP接收/发送缓冲区的自动调整范围。`max`值应足够大以容纳带宽延迟积。例如，100ms RTT，10Gbps带宽，需要的缓冲区大小约为`10Gbit/s * 0.1s / 8 = 125MB`。但实际设置需考虑内存成本。
`net.ipv4.tcp_congestion_control`	cubic (或bbr)	拥塞控制算法。对于有丢包的长肥网络，尝试`bbr`可能有奇效。
`net.ipv4.tcp_slow_start_after_idle`	1	空闲后重新进入慢启动。对于需要保持高速的长连接（如数据库连接池），可以设置为0。
`net.ipv4.tcp_fin_timeout`	60	FIN_WAIT_2状态的超时时间。如果服务器有大量短连接且主动关闭，可能会耗尽端口，可适当调低（如30）。

调优建议：不要盲目修改。先通过监控（如ss -it，nstat，sar -n TCP）了解当前连接的状态、重传率、窗口大小等信息，再有针对性地调整。调整后务必进行压测验证效果。

7.2 常见网络问题排查思路与工具

当应用出现网络慢、连接失败等问题时，可以按以下层次排查：

1. 连通性与路由问题：

工具：ping,traceroute/mtr
查什么：检查目标IP是否可达，网络路径上的延迟和丢包发生在哪一跳。mtr是traceroute和ping的结合，能持续监测路径质量。

2. 端口与服务可用性问题：

工具：telnetnc(netcat)
查什么：telnet <ip> <port>或nc -zv <ip> <port>测试TCP端口是否开放并能完成TCP握手。对于UDP，nc -uzv可以测试，但UDP无连接，成功只表示能发送数据包出去。

3. 连接状态与性能问题（TCP专项）：

工具：netstat,ss,ip命令
查什么：
- ss -tan：查看所有TCP连接的状态。关注TIME-WAIT,CLOSE-WAIT,ESTAB的数量是否异常。
- ss -it：查看每个TCP连接的详细统计信息，包括拥塞窗口、接收窗口、RTT、重传超时等。这是分析TCP性能的利器。
- netstat -s或nstat -az：查看TCP协议的全局统计，如主动/被动打开次数、重传段数、错误数等。重传率是衡量网络质量的关键指标。

4. 数据包层面的深度分析：

工具：Wireshark(图形化),tcpdump(命令行)
查什么：这是终极武器。可以抓取线路上实际的数据包进行分析。
- TCP连接问题：过滤tcp.port == 目标端口，查看三次握手是否成功，是否有RST包异常重置连接。
- TCP性能问题：观察序列号和ACK号的变化，看是否有重复ACK（快速重传触发条件），计算往返时间RTT，查看窗口大小是否经常变小。通过“统计 -> 流量图”可以直观看到数据传输过程。
- UDP问题：查看UDP数据包是否持续发出，是否有ICMP错误报文回复。
- 应用层协议问题：解析HTTP、DNS等应用层协议，查看请求和响应是否完整。

5. 系统资源与配置问题：

工具：sysctl,/proc文件系统，dmesg
查什么：
- sysctl -a | grep tcp：查看当前所有TCP相关内核参数。
- cat /proc/sys/net/ipv4/tcp_retries2：查看TCP超时重试次数。
- dmesg | tail：查看内核日志，是否有网络相关的错误或丢包记录。

一个典型的TCP连接缓慢排查流程：