TCP可靠传输核心机制与Linux排查实战-平芜编程栈

手写TCP这块，很多人第一步就理解歪了：拿个tcpdump抓包，看到三次握手四次挥手就觉得自己懂了，但其实TCP最值钱的东西全在数据面里——序号怎么保证不乱、丢包怎么被感知、窗口怎么卡着发送方、拥塞怎么逼着两端降速。这篇我按自己的理解把TCP可靠传输的主线串一遍，结合Linux上的真实排查经验讲，不用背字段，把机制背后的“为什么”整明白。适合刚接触Linux网络、准备面试、或者线上TCP出问题不知道怎么下手的同学。

1. 先别急着背字段：TCP到底在解决什么问题

在聊机制之前，必须把TCP的定位弄清楚。TCP（Transmission Control Protocol）工作在传输层，跑在不可靠的IP协议之上，提供的是面向连接、可靠、基于字节流的传输服务。

这句话信息量很大。

“面向连接”意味着通信双方要先建立一个逻辑通道，通信完之后还要“拆”掉它。“可靠”意味着数据不能丢、不能错、不能重、不能乱——或者说，即使下层出了幺蛾子，TCP也能通过自己的机制把它纠正回来。“基于字节流”意味着TCP不关心你上层发的是什么类型的数据，它把数据看成一串没有边界的长流，怎么分块、怎么装进报文段，是TCP自己决定的事。

可靠传输，是TCP最核心的价值。IP层只负责尽力而为地把数据报送到目的地，不保证顺序、不保证可靠、甚至可能丢包。TCP要想在这上面建可靠传输，必须自己解决四个问题：

接收方怎么知道数据有没有收到——所以有确认（ACK）机制；
发送方怎么判断是不是丢了——所以有超时重传机制；
接收方怎么处理乱序和重复——所以有序号和去重机制；
双方怎么避免把对方or网络打爆——所以有流量控制和拥塞控制。

这四板斧之间不是孤立的，序号是地基，确认和重传是“发现错误并纠正”，窗口是“控制发送节奏”。下面我把这些机制整体串一遍，你会发现TCP并不复杂，它只是把一整套“收发快递”的逻辑搬到了网络里。

2. 连接的建立与拆除：三次握手和四次挥手为什么非要是这个形状

这一节讲TCP连接管理，这是面试高频题，也是线上问题重灾区。但我不是让你背状态名，而是理解每一步的意义：之所以是这个形状，是因为每一步都在传递不可或缺的“事实”。

2.1 三次握手：不是礼貌，是双方在同步序列号

三次握手的整个过程：客户端发送SYN，服务端回SYN+ACK，客户端再回ACK。很多资料说这是为了让双方确认“能收能发”，这个说法没错，但不够本质。

握手的核心目的其实是同步初始序列号（ISN，Initial Sequence Number）。序号是TCP可靠传输的地基，接收方要靠序号对数据排序，所以通信双方必须都知道对方的起始序号是什么。

第一次握手：客户端发SYN（seq=x），相当于告诉服务端“我从x号开始编号，你准备接我数据”；
第二次握手：服务端回SYN+ACK（seq=y，ack=x+1），相当于说“收到你的请求，我从y号开始编号；此刻我已经成功收到你的x，所以你接下来从x+1开始发就行”；
第三次握手：客户端发ACK（seq=x+1，ack=y+1），相当于说“我收到你的编号了，你的y+1是下一个我要接收的数据号”。

如果只有两次握手，服务端没法确认客户端的接收能力是正常的。网络上有个经常提到的例子——旧的连接请求在网络中滞留，如果只有两次握手，服务端傻傻地建立连接并等待数据，客户端这边根本不想要这个连接，资源就白白浪费了。加上第三次握手，服务端收不到客户端的ACK就会明白对方“变卦”了，不会傻等。

在Linux上排查握手问题，最直接的是看ss -tnp里的连接状态。大量SYN_RECV状态的连接，基本可以判定半连接队列被塞满或遭遇了SYN Flood。这时候net.ipv4.tcp_syncookies这个内核参数就该出场了——它能在半连接队列用尽时，通过编码ISN来校验握手，省下维护半连接的状态。

2.2 四次挥手：为什么被动关闭方要多走一步

四次挥手：主动方发FIN，被动方回ACK，被动方再发FIN，主动方回ACK。

这里的关键是，FIN只是一个“我这边数据发完了”的声明，不等于“我不接收数据了”。所以被动关闭方在收到FIN之后，可能还需要继续发送自己剩余的数据。它回ACK，表示“我知道了”，然后接着发还没发完的数据，直到自己也发完，才发FIN。

一条宝贵的实战经验：如果你用close关闭socket，内核会立即发FIN，哪怕接收缓冲区还有没被应用读完的数据，也会被丢弃。如果只是想表示“我不再发送数据了”，但是还希望把未读完的接收数据读完，应该用shutdown(fd, SHUT_WR)，让TCP进入半关闭状态，保留读通道继续收数据。

关于四次挥手，最磨人也是面试最爱问的永远是TIME_WAIT。主动关闭方在收到对方的FIN并回完ACK之后，不会立刻进入CLOSED，而是进入TIME_WAIT，持续2MSL（Maximum Segment Lifetime，报文最大生存时间）。MSL在Linux默认是30秒或60秒，不同内核版本配置不一样，所以TIME_WAIT一般会持续60秒左右——其实不用刻意去背这个数字，理解它存在的两个原因就够了：

确保“最后一个ACK”万一丢了，对方会重发FIN，自己还能再回一次ACK，不至于让对方永远挂在LAST_ACK；
让这条连接上的旧报文在网络上彻底消散，防止它串到新连接里，造成数据错乱。

在Linux高并发短连接场景（比如Nginx代理、RPC短连接）下，TIME_WAIT连接可能堆积到上万条。这在Linux 4.x以上内核不算大问题，真正的风险是它占用本地端口（四元组中本地端口有限），害得新连接无法建立。这时候可以谨慎开net.ipv4.tcp_tw_reuse=1，让内核在安全前提下复用TIME_WAIT连接，但请注意，它只能用于主动发起连接的一端（通常是客户端），不能无脑在两端都开。

2.3 TCP状态机与Linux排查命令

掌握了握手挥手的报文变化，就能串起TCP状态机：CLOSED → LISTEN → SYN_SENT / SYN_RECV → ESTABLISHED → FIN_WAIT_1/2、TIME_WAIT、CLOSE_WAIT、LAST_ACK → CLOSED。

我之前排查过一个接口超时问题，ss -tn刷出来一堆CLOSE_WAIT连接，就立刻明白了——是服务端应用代码没关闭socket。因为对端发了FIN（想优雅关闭），内核和应用层都收到了EOF信号，但进程没调用close，连接就停在CLOSE_WAIT。这个状态的本质是：对方想分手，你这边程序忘了说“好”。排查CLOSE_WAIT，第一件事就是去查应用层代码里的socket释放逻辑，不要先怀疑什么内核参数问题。

状态	含义	常见原因	初步排查方向
SYN_RECV	收到SYN，半连接建立	半连接队列满、SYN Flood	tcp_syncookies、tcp_max_syn_backlog
ESTABLISHED	正常建立连接	-	-
CLOSE_WAIT	收到对方FIN，自己没关socket	应用未关闭连接	查代码，检查资源泄漏
LAST_ACK	等待最后的ACK	对方不回了/网络异常	抓包看ACK是否送达
TIME_WAIT	主动关闭后等待2MSL	大量短连接	tcp_tw_reuse（主动方）

3. 数据面可靠传输：序号、确认、重传、去重

连接建好了，才开始真正运输数据。这一节是TCP最硬核的部分：数据怎么做到不丢、不乱、不重。核心靠四条：序号机制、确认机制、重传机制、去重机制。

3.1 序号（seq）和确认号（ack）：TCP可靠性的地基

TCP把应用层给的字节流按顺序编号，每个报文段的头部携带两个关键字段：seq（这个报文段里数据的起始序号）和ack（期望对方下次发来的第一个字节序号）。

有了seq，接收方就能对乱序到达的段进行排序；有了ack，发送方才能知道哪些字节已经被对端确认了。这个设计朴素但极其高效——它让可靠性不再依赖每条物理链路的稳定性，而是依赖接收端的反馈。

注意TCP确认是累计确认：ack=n，表示“n之前的所有字节我都收到了”，不需要对每个段单独回复。这个设计简化了接收方的处理，但代价是如果一个段丢了，重传的单位不太好确定。这也是为什么后面会引入SACK。

一个很有用的抓包经验：分析TCP流时，看ack增长了没，比看seq更重要。如果对端一直回同一个ack，说明有数据包丢了，而且丢的恰好就是ack号指向的那个包。

3.2 超时重传与RTO计算

发送方发出数据后，会启动一个定时器，等待对方的ACK。如果等了一阵（RTO，Retransmission Timeout）还没等到，就判定数据丢了，重传这份数据。RTO不能太大，否则网络一抖就严重影响延迟；也不能太小，太小容易在ACK还在路上时就重传，白白浪费带宽。

RTO的依据是RTT——报文往返时间。经典算法里RTT的变化会动态调整RTO，现代内核还引入了Karn算法（重传报文不参与RTT采样）和指数退避（不行就再等更长）。这背后就是“退避”思想：第一次超时可能是抖动，如果真丢了，再传还是丢的概率更高，那就把超时时间加倍，避免把一个坏网络锤死。

在Linux系统上，与重传相关最常用的参数是net.ipv4.tcp_retries1和net.ipv4.tcp_retries2。tcp_retries2默认大概15次，影响TCP判断“连接彻底失败”的时间；如果应用层经常报超时，可能需要配合业务需求调它，但我不建议为了“表面不报错”而盲目调大，那只会让故障反应更慢。

3.3 快速重传与SACK/D-SACK

超时重传等待时间太长，TCP设计了“快速重传”来加速：如果发送方连续收到3个重复的ACK，说明不仅仅是乱序，大概率是丢了包——对端反复提醒“我还在等这个包”，发送方不用等超时，立刻重传。

快速重传的问题在于：它只知道“从哪开始丢”，不知道哪些后续数据已经收到了，所以往往要重传很多数据（Go-Back-N屁股后面一大串全重发）。SACK（Selective Acknowledgment，选择性确认）解决了这个问题。SACK选项允许接收方在ACK里追加几个TLV字段，告诉发送方“我虽然没收到3号包，但是5号包我已经收到了”，发送方就可以只重传真正丢掉的3号包，效率立刻上去。

更精细的是D-SACK（Duplicate-SACK），它能告诉发送方“你重传的数据其实我早就收到了”。这个信息在排查网络问题时非常宝贵：如果经常出现D-SACK，说明存在不必要的重传，多半是RTO太敏感、或链路存在突发延迟导致重复发送了。

Linux上SACK默认是开启的（net.ipv4.tcp_sack=1），很多老教程让你在广域网拥塞时关掉它，但现在基本不需要关了，现代协议栈对SACK的处理已经很成熟。

3.4 滑动窗口与流量控制

TCP的发送方不能一股脑把数据全怼到网络上，接收方也不能一次性处理无限数据。所以TCP用了一个滑动窗口机制：接收方在ACK中带上自己“还能接收多少数据”的能力（rwnd，接收窗口），发送方把未确认的数据限制在这个窗口内，窗口随着ACK的到达而滑动。

这个机制实现了流量控制，保护的是接收方不被发送方打爆。

Linux上有两个方向要区分清楚：

Recv-Q（ss第一列）：接收队列积压，如果一直涨，可能是应用读得慢，接收窗口会不断缩小；
Send-Q（ss第二列）：发送队列积压，如果一直是满的，说明链路拥塞或对端接收窗口为0。

典型场景：对端回了win=0，即零窗口，发送方就得暂停发送，并定期发窗口探测报文去询问接收方窗口是否恢复。如果Windows上开了窗口缩放选项（window scale），抓包时看到的窗口数要乘以缩放因子才是真实窗口。新手排查时经常被这个假窗口误导，以为对端不收数据了。

这里要补充一个很有实战价值的组合：延迟确认（Delayed ACK）与Nagle算法，两者单独用没问题，一旦碰在一起会产生“愚笨窗口综合症”。

延迟确认：接收方不立刻回ACK，而是稍微等一会儿（Linux默认约40ms），等有数据要发时捎带ACK，顺便合并多个ACK；
Nagle算法：发送方要攒够一个MSS或者等到所有数据都收到ACK才发下一批数据。

如果双方都“等”，结果就是：发送方在等ACK腾出窗口，接收方在等更多数据一起确认，双方就这么干等，延迟直接被拉到几十毫秒以上。线上如果遇到小包交互延迟异常偏高，先看是不是Nagle在捣乱，可以考虑在应用里用TCP_NODELAY关闭Nagle（Redis、很多RPC框架都默认关了）。

4. 拥塞控制：当路上的车多到堵死时

流量控制保护的是接收方，那么谁保护网络？答案是拥塞控制。

TCP发送方不能只看接收方的窗口，还要看网络是否吃得消。如果所有主机都不管不顾地同时发数据，路由器缓冲区被占满，新到的包被丢弃，导致大量重传，又加剧拥塞，最后全网瘫痪——这叫“拥塞崩溃”。TCP的拥塞控制就是通过一个发送方维护的“拥塞窗口”（cwnd，congestion window）来动态控制发送速率，实际发送上限 = min( cwnd, rwnd )。

4.1 慢启动、拥塞避免与快速恢复

现代TCP拥塞控制的核心体系包括三个组件：

慢启动：连接刚建立时，cwnd从很小（Linux老版本约10个MSS，新版内核会按BDP动态初始）开始，每收到一个ACK，cwnd翻倍增长。这个阶段是指数增长，增长极快，目的是在短时间内找到带宽的上限。
拥塞避免：当cwnd超过ssthresh（慢启动阈值），不再翻倍，而是每个RTT只增加一个MSS。这是线性增长，增长要“小心翼翼”。
快速恢复：收到3个重复ACK时，因为快速重传已经介入，发送方会标记丢包，把ssthresh降为当前cwnd的一半，然后cwnd从ssthresh开始继续拥塞避免阶段。它避免了一步退回慢启动导致的带宽剧烈抖动。

这套机制统称AIMD（加法增加，乘法减少），它的特点是“缓慢试探、迅速撤退”：网络好就慢慢加码，一旦探测到丢包就迅速砍半。Linux上的默认拥塞控制算法在较新内核中已切换到BBR或CUBIC，具体看发行版版本。CUBIC适合大带宽高延迟网络，BBR则通过建模瓶颈带宽来主动调节，能减少队列延迟。生产环境更换算法前，建议在不同链路类型上先做对比测试，不要一上来就全换。

4.2 Linux中的拥塞控制内核参数

涉及到拥塞控制，最常调的Linux参数就这几个：

参数	作用	建议
net.ipv4.tcp_congestion_control	拥塞控制算法	广域网优先BBR或CUBIC
net.ipv4.tcp_notsent_lowat	发送缓冲区未发送数据阈值	有小包低延迟需求时可调小
net.ipv4.tcp_window_scaling	窗口缩放	大带宽长RTT链路务必保持1
net.ipv4.tcp_slow_start_after_idle	空闲后是否重置cwnd	长连接复用优先设为0

那一年我们一台大带宽业务的服务器间歇性卡顿，排查很久，最后发现是链路中某个中间设备的队列缓冲区被占满，服务端开启BBR之后，卡顿明显缓解。原因就是BBR能感知瓶颈带宽，主动限制发送速率，避免把中间设备的缓冲打满。大家在线上遇到“链路明明带宽很足，但TCP传输速度上不去”这种问题，优先检查拥塞控制算法的选择和cwnd的初始值，而不是无脑调大socket缓冲区。

5. 在Linux上“看见”TCP机制：抓包、计数器和工具

理解了机制，还得会观察。TCP设计得非常精巧，几乎每个机制都会在某个计数器或报文特征中留下痕迹，排查问题就是顺着这些痕迹往上找源头。

5.1 ss命令与TCP状态解读

排查TCP问题，第一步永远是ss -tanp，看连接状态、Recv-Q/Send-Q积压情况。

ss -s可以输出TCP连接汇总，比如当前系统timewait、closed、syn_recv、established数量。如果syn_recv的数量与syn_dropped同步上涨，说明半连接队列溢出；如果timewait数量巨大但端口资源耗尽了，看established里是不是有无数对外短连接。

还有一个容易被忽略的字段：Send-Q显示的是发送队列中还没被确认的数据量。在做大文件传输时，如果Send-Q一直高企而Recv-Q为0，通常表示数据停在本地协议栈没发出去或发出去没收到确认，更偏向于网络链路问题；反过来Recv-Q持续上涨，说明应用层消费慢，更偏向于应用处理性能问题。

5.2 tcpdump抓包观察握手、重传与窗口

多数时候，ss只能看到表象，要想验证到底是网络丢包还是对端没回ACK，必须抓包。

tcpdump -i eth0 tcp port 8080 -nn -w /tmp/tcp.pcap

抓包后重点看几个特征：

三次握手：SYN、SYN+ACK、ACK，三个包seq/ack的编号关系和本章第2节一致；
重传包：抓包文件里会出现大量[TCP Retransmission]标记，说明发送方触发了超时重传或快速重传；
零窗口：对端持续回[TCP ZeroWindow]，这就是流量控制生效，接收方已经吃不消了；
重复ACK：如果收到多个[TCP Dup ACK]，说明发生了乱序或丢包，但要结合SACK来判断到底是哪种。

我自己的习惯是先用nstat -az看本机TCP栈的统计计数（比如TcpRetransSegs、TcpInSegs、TcpOutSegs），确认有重传趋势，再抓包精确定位丢包位置。这样能大幅减少无头绪抓包的时间。

5.3 用netstat和nstat快速定位重传率

Linux自带的nstat命令可以直接输出TCP协议栈的累计计数：

nstat -az | grep -E "TcpRetrans|TcpOut|TcpIn|TcpTimeouts|TcpLoss"

关键的几个指标：

TcpRetransSegs：累计重传段数量，长时间持续增长说明网络环境堪忧；
TcpOutSegs：累计发送段数量。重传率 = TcpRetransSegs / TcpOutSegs，一般超过1%就要关注；
TcpTimeouts：TCP超时次数，频繁超时会直接影响应用延迟；
TcpLoss：丢包事件计数，丢包率升高往往伴随页面卡顿、接口变慢。

如果重传率高于阈值，先检查本地网卡是否有大量错误包（ethtool -S eth0看dropped/errors）、是否存在网卡降速和链路不稳定，再怀疑中间网络设备。很多超时问题其实是网线/光模块松了，排查优先级要放在最前面。

5.4 半连接队列与全连接队列溢出

TCP服务器监听接口时有两个队列：

半连接队列（SYN队列）：存已经收到SYN但还没完成握手的连接；
全连接队列（Accept队列）：存已完成握手、等待应用accept()取走的连接。

应用层accept()速度太慢，全连接队列就会爆，新完成的握手连接直接被内核丢弃或RESET。检查方法很直接：

ss -lnt

Send-Q在LISTEN状态下显示的其实是全连接队列的最大长度，Recv-Q则是当前已建立但还没被accept的连接数。如果Recv-Q长期占满Send-Q，或者应用日志出现connection reset by peer、accept queue full之类提示，基本就是全连接队列溢出了。

内核参数net.core.somaxconn和socket监听时传入的backlog参数，共同决定了全连接队列上限。调整时要同时改这两个地方，只改一个不生效：高并发服务端建议把两者都调成2048或更高。

6. TCP排查实战：典型问题的定位思路

最后整理一张速查表，涵盖我在Linux上排查TCP问题时遇到最频繁的几类现象、原因和解决方向。别看它简单，很多时候比翻半天文档有用得多。

现象	可能原因	定位方向
大量SYN_RECV	半连接队列溢出、SYN Flood	`netstat -s`查syn_dropped，开tcp_syncookies
大量CLOSE_WAIT	应用未关闭socket	查代码、查fd泄漏，`lsof -p PID \| wc -l`
大量TIME_WAIT	主动关闭短连接过多	开tcp_tw_reuse（主动方），业务层连接池
Send-Q持续满	网络拥塞或对端不接收	抓包看零窗口、重传标志，ping/mtr查路径
Recv-Q持续增长	应用消费慢	查应用吞吐，优化读取逻辑
接口时快时慢	链路抖动 / RTO不合理	抓包看重传间隔，traceroute观察延迟毛刺
连接被RST重置	全连接队列满、对端崩溃	`ss -lnt`看队列，抓包看RST触发点

这里有一个我重复踩过的坑：线上服务出现大量连接被对端RST，桩了半天中间链路，最后发现是服务端应用监听的backlog队列溢满了，内核没有空间接受新连接，索性直接回了RST。所以每次排查RST问题，第一步不是到网络侧找问题，而是先看本地accept队列压力。

另外，“重传”这个词对不同的人来说含义完全不同。应用层看到的是“接口超时”，内核看到的是“TcpRetransSegs上涨”，抓包看到的是“TCP Retransmission标记”。排查时要沿着应用日志 -> 内核计数 -> 抓包特征这条线逐层下钻，不要一开始就陷入细节里，否则很容易误判。

7. 写在最后：TCP可靠传输的“道”与“术”

TCP可靠传输这套设计，看起来只是一堆状态机、定时器、窗口算法，其实背后就一句话：在不可信的信道上建立可信的通信。它不做“保证不丢”，而是做到“丢了能发现、发现能重传、重传不爆炸”；它不做“保证不慢”，而是做到“能快的时候拼命快，要退的时候果断退”。这种设计哲学放到任何一个分布式系统、消息队列、分布式存储里都成立——先接受底层的不可靠，再在上层做兜底和补偿。

我在实际运维和开发里最深的一个体会是：TCP的可靠性不是免费的。每一次可靠交付，背后都有序号、确认、缓冲、重传、定时器在默默工作。你在Linux上看到的Recv-Q、Send-Q、各种TIME_WAIT堆积，不是内核闲着没事刷数字，而是TCP在跟现实世界的不完美博弈。理解了这层，你再去看ss的输出、tcpdump的报文、nstat的计数器，才算是真正读懂了它们。

实战中还有个容易被忽视的建议：排查TCP问题前，先把应用层的读写逻辑梳理干净。很多所谓“TCP性能问题”，查到最后其实是应用层死等、没及时读走接收缓冲区数据，或者没及时关闭连接导致的——TCP机制本身没毛病，是使用者用错了姿势。把机制搞懂了、把手里的工具用熟了，再遇到奇怪的网络现象，至少知道该往哪个方向使劲，不至于像无头苍蝇一样乱撞。