企业官网建设流程全解析

我一直觉得，TCP 是网络知识里最被“背烂”、又最没被真正理解的一块。面试场合大家都在复述三次握手、四次挥手，可到了线上问题面前，什么Connection reset、超时、重传率高、时延不稳定，不少人还是只能靠猜。这一篇我按自己的理解，把TCP的核心原理和实战经验串一遍，尽量不用教科书式的讲法，讲清楚它为什么要这样设计，以及排查时怎么用它来定位问题。

适合谁看？刚学完计算机网络、想真正把TCP串起来的同学，写网络服务的后端开发，做运维和SRE的同行，甚至要对网络参数做调优的，这篇都能用得上。我自己最早也是在某个售后系统压测时，被客户端报错Connection reset by peer搞得焦头烂额，然后才开始把TCP的机制一点点抠透的。希望你读完之后，至少再遇到这类问题能有一个清晰的排查路径。

1. 先搞清楚 TCP 到底解决什么问题

1.1 IP 只负责“尽力送达”，活干得并不漂亮

要理解TCP，先得知道它站在IP的肩膀上，而IP的这个肩膀并不靠谱。IP协议做的事情很简单：把数据包从一台机器送到另一台机器，中间经过路由、交换机，它只承诺“我尽量送”，却不承诺一定送到、按顺序送到、只送一次。这就像一个快递公司说“我尽力送，但如果件丢了、中途碎了、甚至送了两遍，你别怪我，这是正常的”。

现实网络里丢包、乱序、重复、延迟这四件事是常态，尤其是在跨运营商、跨国、无线网络这种环境里，丢包率哪怕只有百分之一，对应用的伤害也是放大的。TCP存在的意义，就是在IP这种“尽力而为”的底座上，帮上层应用把这些问题全部兜住。你在应用层写socket时，根本不用关心底层有没有丢包，因为TCP已经在上层给你提供了一条看起来完全可靠的字节流通道。

1.2 字节流而不是数据报：TCP 给应用的抽象

UDP面对的是一个一个的数据报，发一个是一个，边界非常清楚。TCP不一样，它给应用层提供的是一个没有边界的字节流。你调用send()写1000字节，再调用send()写1000字节，对端read()出来不一定是2000字节，可能是500字节，也可能是3000字节——中间被内核重新切分、粘合过。

这个设计其实很聪明。TCP内部会把字节流按MSS（最大分段大小）切片成一个个数据段，再交给IP层发送。因为网络路径的MTU（最大传输单元）在变化，TCP可以根据探测到的路径MTU动态调整切片大小，如果TCP像UDP一样硬性保持消息边界，这个灵活性就没了。字节流抽象也简化了可靠传输的实现：给每一个字节一个序号，确认的时候只需要告诉对方“我收到了到某个序号为止的所有字节”，逻辑非常清爽。

1.3 面向连接、全双工、点对点

TCP还有一个特点：连接是点对点的、全双工的。也就是说，一条TCP连接只存在于两个端点之间，数据可以双向同时流动，不存在“一个发送端，多个接收端”的广播场景。你也许会觉得这是废话，但很多实际设计问题恰恰源于这里——比如有人想在多个接收端之间共享一条TCP连接做分发，这本身就违反TCP的语义，正确做法应该起多条独立连接，或者用UDP做应用层封装。

“面向连接”也不是说物理上真的拉了一根线，而是两端内核各自维护一套状态，协商好初始序号、窗口大小、各种选项，然后共同维持这套状态直到连接关闭。所以TCP连接是逻辑上的“虚拟链路”，这条链路的建立、维护、拆除，就是我们熟悉的握手、保活、挥手。很多调优参数改的其实就是这几个阶段相关的内核状态和行为。

2. 三次握手与四次挥手：别只背状态机

2.1 为什么握手必须是三次，而不是两次或四次

三次握手最容易被忽略的一个问题是：它不只是为了确认双方“都在线”，更关键的是同步初始序号（ISN）。序列号是TCP可靠传输的地基，双方必须知道对方的起始序号，后续的确认和重传才有参照物。

如果你只发一次SYN然后等对方回复，也就是“两次握手”，会有什么问题？考虑一个经典场景：一条延迟很大的链路上，客户端A发了一个SYN，因为网络卡顿，这个SYN在路上滞留了很久，A等不到回复就超时重发了一个SYN，第二次成功建立了连接并传输完数据关闭了。结果第一那个“迟到的SYN”又飘到服务端B——B收到这个SYN，以为A要新建连接，就会傻乎乎地分配资源、进入等待状态，但A根本不知道这个连接的存在。于是B这边白白占用资源，甚至会产生数据错乱的风险。

所以第三次握手非常重要：由发起方A对B的SYN-ACK再做一次确认，告诉B“我之前那个SYN确实是当前这个连接要用的，我确认你的初始序号了”。反过来，如果这个确认迟到或丢了，B收不到ACK会重发SYN-ACK，A收到一个重复SYN-ACK后会重新ACK，这样双方始终能围绕同一套连接状态对齐。三次握手本质上是在“不可靠的IP之上，可靠地同步两个端点的初始状态”。

抓包的时候，你会看到SYN报文里除了SYN标志，还会带一个Seq=0，但这只是相对序号，Wireshark默认显示相对值。实际ISN是一个随机生成的值，防止被预测攻击，这也是早期TCP协议被人诟病的一个安全性漏洞。

2.2 握手队列与半连接、全连接

服务端收到SYN后，并不会立刻完成握手，而是先把连接放进一个半连接队列（SYN队列），当收到最后一个ACK，连接才从SYN队列挪到全连接队列（Accept队列），等待应用层调用accept()取走。如果应用层处理慢，Accept队列会堆积，满了之后内核开始丢弃连接，客户端表现就是握手超时、连接不上。

排查这个特别适合用ss -lnt看Recv-Q和Send-Q的值。Recv-Q表示Accept队列当前堆积的连接数，Send-Q是队列上限。两者相等且不为0，说明队列满了，应用进程没来得及accept。性能调优时，这三个参数值得关注：

net.core.somaxconn = 4096 # Accept队列上限的帽子 net.ipv4.tcp_max_syn_backlog = 1024 # SYN队列上限

改了somaxconn还不够，应用层listen()的第二参数backlog也要跟着放大，否则内核队列上限设置了也白搭。有些框架内部还会自己限制accept队列长度，需要一起调。

2.3 四次挥手：FIN 和 ACK 为什么要拆开

关闭连接时为什么是四次？因为TCP是双工的，每一方向对另一方向的关闭都是独立的。一方关闭只代表它不再发数据，但可能还要继续收数据，直到自己也发FIN。也就是说，关闭需要双方各自声明一次“我不再发了”，所以至少两次FIN-ACK交换，看起来就是四次。

但实际抓包里，如果你看到服务端收到FIN后马上回复FIN，第2次和第3次挥手会合并成一个包，抓包看起来就只看到三次。这种“半关闭”状态值得留意：对端收到的FIN只代表对方不再发送，不代表你能立刻放弃读缓冲区，否则可能丢尾包。

2.4 TIME_WAIT：主动关闭方绕不开的坎

四次挥手里最容易被低估的是TIME_WAIT状态。主动关闭的一方在发送最后一个ACK之后，不会立刻释放连接，而是要等2个MSL（Maximum Segment Lifetime，报文最大生存时间）才真正关闭。为什么要等这么久？两个原因：

第一，防止最后一个ACK丢失。如果被动关闭方没收到最后这个ACK，它会重发FIN，主动关闭方需要还在TIME_WAIT状态里才能重新响应ACK。

第二，让这条连接上迟到的旧报文在网络里自然消亡，避免它们出现在一个同IP同端口的新连接里，造成数据污染。

TIME_WAIT会带来一个实际问题：高并发短连接场景下（比如大量HTTP请求），主动关闭方会积压一大片TIME_WAIT连接。有人图省事，直接开net.ipv4.tcp_tw_reuse，但这要非常谨慎。tcp_tw_reuse的作用是允许客户端复用一个TIME_WAIT状态的连接作为新的对外连接，前提是开启时间戳选项且新连接的起始时间戳更大。它只对主动发起连接的一方有效，不能解决服务端TIME_WAIT堆积，而且如果后端有多台机器、NAT环境里时间戳不统一，开启它可能导致序列号混乱。另一个曾经存在的tcp_tw_recycle参数，因为有同样的时间戳问题，在后续内核版本里已经移除了——遇到老文章里无脑推荐这个参数的，可以直接跳过。

我的建议是：优先调整应用层，减少不必要的短连接；实在要复用，从业务上做连接池，而不是依赖内核参数走捷径。TIME_WAIT本身并不可怕，只要数量不导致端口耗尽或者内存明显上涨，多让它待一会儿反而是网络安全的保障。

3. 可靠传输靠什么：序号、确认与重传

3.1 每一个字节都有自己的编号

TCP的序号是字节序号，不是报文序号。这是个特别容易混淆的点。比如发送方要发1000字节数据，MSS是1000，那么它发第1个段Seq=1，长度1000，下一个段的Seq就是1001。接收方回复的ACK号表示“我已经连续收到第N个字节之前的所有数据，下一个我期待接收的是Seq=N的数据”。

ACK是累计的。这个“累计确认”是TCP一个核心设计：接收方不需要对每一段单独确认，只要连续收到了，就回一个最大的连续序号即可。好处是极大减少了确认报文的数量，坏处是一旦中间丢了一段，后面即使连续收到好几段，接收方也只能不断重复确认那个丢失序号之前的ACK，无法告诉发送方“后面那些其实我也收到了”。

这就是经典的重传问题。发送方收到多个重复ACK时，第一反应是“中间丢了包”，于是触发重传机制。基础做法的效率瓶颈非常明显：如果一次丢了一大片数据，接收方只能重复确认丢点之后的所有数据，而发送方也会重传丢失之后整段窗口数据，造成大量浪费。

3.2 超时重传与 RTO 的估算逻辑

最朴实的重传方式是“等一段超时时间，没收到ACK就重发”。这段等待时间叫RTO（Retransmission Timeout）。RTO不能拍脑袋定死，因为网络时延动态变化。局域网里1毫秒就能收到ACK，跨洋链路可能要一两百毫秒，如果RTO定死了要么等太久、要么频繁误重传。

TCP的做法是持续采样往返时间RTT，然后用一个加权平均去估计当前应该用的RTO。早期算法很简单：SRTT = (α × SRTT) + ((1-α) × RTT)，再乘一个余量。后面RFC 6298把公式优化得更复杂，还会考虑RTT抖动。说到底，它是在“等待有把握”和“尽快重发”之间找到平衡。

超时重传有个问题：一旦真的发生超时，发送方对网络状况的预估往往也失效了。所以出现RTO超时后，TCP会做两件事：第一，把拥塞窗口降到很低，减轻网络负担；第二，把后续重传的RTO按指数退避，给网络更长的恢复时间。你在抓包里如果看到一连串Retransmission包，间隔呈指数增长，那就是标准退避。

3.3 快速重传与 SACK

超时重传太被动了。实际上大部分丢包不至于让ACK完全消失，接收方还会继续发送重复ACK。TCP用“收到3个重复ACK”作为一个提示：该段大概丢了，别等超时，立刻重传。这就是快速重传。

后来，为了让发送方知道重复ACK之外“到底收了多少后续数据”，协议族里加了一个SACK选项。接收方可以在ACK包里附加一段范围：我除了这个序号没收到，后面从X到Y、从Z到W这些我都收到了。发送方根据SACK就能精确地进行选择性重传，只补丢掉的缺口，而不是重传整个窗口，这对高丢包率、大窗口的网络帮助非常明显。

如果你用Wireshark看包，会看到握手阶段的SYN报文里往往带着“SACK permitted”选项。中间的包偶尔会有“TCP SACK”字段。如果你的网络里大量丢包，检查一下连接两端是否都启用了SACK，现代Linux默认是开的，但有些老系统或某些网络设备可能会把它关掉。

3.4 乱序与重复包：被忽略的另一面

很多人只关注丢包，忽略了乱序。IP层的路径不是固定的，同一个连接的不同报文可能走了不同路径，先发的反而后到。TCP靠序号发现乱序后，会把后到的数据先放进乱序队列，等缺少的段到了再交给应用层。问题在于，如果乱序程度比较大，接收方会回复重复ACK，发送方可能误判为丢包并快速重传，白白浪费带宽。

重复包的处理则相对简单：接收方收到序号小于等于已确认序号的段，会直接丢弃，并且重申一遍当前期待序号。这其实也是一个“正常丢包”的信号，刷屏的重复ACK通常意味着网络里确实有某种程度的传输不稳定。

4. 流量控制与拥塞控制：别把两者混为一谈

4.1 流量控制：收不下就别硬发

很多初学者把流量控制和拥塞控制混在一起，其实动机完全不同。流量控制是“接收方能吃多少，发送方就发多少”，解决的是端到端的缓冲区溢出问题。接收方会在每个ACK里带一个窗口字段rwnd（接收窗口），告诉发送方“我的接收缓冲区还剩多少空间，你最多再发这么多”。

生活化的类比是食堂打饭：窗口里告诉我“我现在就剩3份菜了”，我就只端3份，绝不一次性往窗口里塞20份，否则食堂窗口堆不下。发送方收到rwnd=0时，就进入等待状态，但不能傻等——长效机制是周期性地发送窗口探测报文，问接收方“窗口开了没”。这个探测机制也意味着，如果接收进程一直不读数据，连接可能长期停在这个状态，看起来像是“卡死”了。

这里就引出一个后端调优的经典问题：socket接收缓冲区太小，会导致接收窗口经常变成0，明明网络带宽巨大，应用层吞吐上不去。Linux里可以调整：

net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 16384 16777216

中间那一项是默认值。这个默认值如果设置得过小，即使在高速局域网内传输大文件也跑不满带宽，因为窗口不够，发送方被流量控制掐住了脖子。

4.2 拥塞控制：网络撑不住了，发送方自觉降速

拥塞控制解决的是另一个问题：接收方缓冲区很充裕，但中间网络已经堵死了，继续猛发只会加剧丢包。TCP把发送方自己的窗口叫cwnd（拥塞窗口），实际能发的数据量是min(rwnd, cwnd)。流量控制管rwnd，拥塞控制管cwnd。

拥塞控制的基础流程是慢启动、拥塞避免、拥塞发生时快速恢复。慢启动名字很有迷惑性，实际增长快得吓人：初始cwnd很小，通常只有10个MSS，但每收到一个ACK，窗口就加1个MSS，相当于每个RTT窗口翻倍。刚建立连接时cwnd呈指数增长，直到触碰到慢启动阈值ssthresh。之后进入拥塞避免阶段，每个RTT只增加1个MSS，线性上升。一旦检测到丢包（超时或重复ACK），就把ssthresh降到当前窗口的一半，如果是超时则cwnd直接降到1，开始新一轮慢启动。

这套机制的背后是经典加法增大、乘法减小的算法思想。早期的Reno算法处理单包丢包表现还可以，但多包丢包和大带宽高延迟链路上效果很差。后来Linux默认的CUBIC算法把增长逻辑改成了三次函数，对高带宽环境友好很多。再后面出现的BBR算法更是换了一套思路：不再以丢包作为拥塞信号，而是持续估计瓶颈带宽和最小RTT，用这个估算值来约束发送速率，实测在长肥网络和无线网络里效果常常优于CUBIC。

4.3 为什么说 Nagle 算法和延迟确认是天敌

这是实践里非常常见、又特别隐蔽的一种坑。Nagle算法的出发点是避免发送大量小报文：如果一个TCP连接上还有未确认的数据，那么新产生的小数据会被“合并”到同一个数据段里，等前一段的ACK回来了再一起发送。这对减少网络中小包数量很有帮助，但对交互性强的应用就是灾难，会导致一个请求要等上一个包的ACK才发出去，多出一整轮RTT的延迟。

延迟确认则是接收方的策略：不会收到数据立刻回ACK，而是稍微等一会儿，看能不能把ACK捎带在响应数据里一起发，或者合并多个数据段的确认。Linux下延迟确认默认是40ms的尺度。

两者一叠加，就会出现一个非常委屈的场景：客户端发一个请求过去，因为Nagle算法在等待之前数据的ACK；服务端收到请求后，因为延迟确认本能地等一会儿，希望响应数据能直接携带ACK。于是双方都在等对方先动，白白多出40ms甚至更高延迟。这种问题在SQL客户端、Redis这种高频小请求场景里特别要命——明明每次操作只要零点几毫秒，总耗时却偏高。

解法很简单也比较粗暴：如果确认自己的业务是交互性的小包请求，关闭Nagle算法，也就是把TCP_NODELAY打开。Redis、很多数据库驱动默认就是这么干的。延迟确认做不做妥协要谨慎，因为它是接收端全局行为，很难针对单条连接修改，所以我通常建议优先打开TCP_NODELAY，实测延迟改善立竿见影。

4.4 窗口缩放和现代高速网络

早期TCP的窗口字段只有16位，最大只能表示65535字节。这个上限在百兆网时代没问题，到了千兆、万兆环境就完全不够看。既然窗口不够，数据链路再宽也跑不起来——这就是著名的“长肥网络问题”。后来TCP加上了Window Scale选项，在握手阶段两边协商一个缩放因子，把窗口表示范围扩大到千兆级以上。抓包里看到Window Scale=7、Window=64240这样的组合，说明实际窗口是64240左移7位，大约是8兆字节。

排查吞吐率上不去时，一定要先确认握手包里是否带了Window Scale，以及双方实际协商的最大窗口是多少。有些老设备和老系统不支持这个选项，结果就是带宽利用率只能到几十兆，看起来网络正常，但传输速度怎么都不对。顺着这个思路，很多“带宽上不去”的问题其实不是带宽本身，而是窗口模型跟不上。

5. 实操：抓包验证 TCP 核心机制

5.1 用 tcpdump 完整看一次三次握手

纸上谈兵太多，抓个包比什么都直观。假设你要访问一台服务器，可以用如下命令抓本机到目标端口的流量：

sudo tcpdump -i eth0 -nn tcp and host 10.0.0.5 and port 443 -c 20

加上-nn表示不解析主机名和端口，速度快且输出干净。抓到的关键行大概是：

10.0.0.1.53740 > 10.0.0.5.443: Flags [S], seq 1219876554, win 64240, options [mss 1460,sackOK,TS val ...], length 0 10.0.0.5.443 > 10.0.0.1.53740: Flags [S.], seq 1946982134, ack 1219876555, win 65160, options [mss 1460,sackOK,TS val ...], length 0 10.0.0.1.53740 > 10.0.0.5.443: Flags [.], ack 1946982135, win 64240, length 0

第一次握手SYN只有Seq，第二次握手SYN-ACK同时带自己的Seq并把对端的Seq+1作为Ack，第三 次握手ACK带上两个序列号，确认双方都准备好了。这里面seq全是绝对序号，看着很大很吓人，但Ack正好是对方Seq+1。注意ack=1219876555，说明接收方期待的是1219876554之后的字节。

win 64240是通告的接收窗口。两个包之间的窗口在变化是因为双方各自启用了Window Scale选项。如果没开这个选项，而且在高速网络里看到win始终卡在65535，那就要怀疑内核或设备限制。

5.2 用 Wireshark 看重传和乱序

tcpdump对快速排查够用，但要看细节我更推荐把包存成pcap文件再用Wireshark打开：

sudo tcpdump -i eth0 -nn -w /tmp/tcp.pcap host 10.0.0.5 and port 80

Wireshark里分析重传极其方便。打开后直接在上方过滤栏输入：

tcp.analysis.retransmission

即刻把所有重传包筛出来。同样的诊断里还会有tcp.analysis.fast_retransmission和tcp.analysis.out_of_order，分别对应快速重传和乱序。看到这些信息，就去关注对端的丢包和网络抖动。你说网络好不好，与其看路由器丢包率，不如看抓包里的重传次数来得准。

实际操作里，我在某个文件传输系统上就遇到过这种场景：从客户端抓包，发现某个数据段被重复确认了三次，发送端立刻执行快速重传，但即使重传了，对端依然只确认到原来的位置。后来一看，问题出在中间防火墙把一个带SACK的包拦截了，导致接收方的SACK信息根本传不出去，发送端一直在盲猜要重传哪些段。

5.3 动手制造一次丢包，看看TCP怎么反应

如果你想在可控环境下观察丢包重传，可以用Linux自带的tc工具给某条链路加一点丢包率：

sudo tc qdisc add dev eth0 root netem loss 10%

然后对某个服务发起流量并抓包。你会发现虽然丢包率高达10%，应用层数据几乎不受影响，但包的数量明显增多，里面大量是重复ACK和重传段。这时候把拥塞控制算法切换成不同版本对比，你还能看到窗口和发送速率的变化差异。

看完实验记得取消：

sudo tc qdisc del dev eth0 root

否则所有流量都带着10%丢包走，线上环境容易出事。我踩过这个坑，实验完忘了清理，第二天业务部门反馈网络不稳定，排查半天才发现是netem还在生效。

5.4 用 ss 快速确认连接状态和重传统计

抓包不一定总有条件上。线上排查时，我习惯先用ss看连接状态分布：

ss -s ss -lnt ss -ti

ss -ti输出里藏着很丰富的信息：rto（当前重传超时）、rtt（最近往返时间）、cwnd（拥塞窗口）、ssthresh、retrans总次数。如果看到某个连接的retrans在持续增长，基本可以断定这条路质量有问题。ss -s还会汇总当前系统的TCP状态计数，一眼能看出SYN队列积压、TIME_WAIT过多和内存占用过高的情况。

如果再配合netstat -s看协议级统计，能够得到SYN重传、丢包、停滞的全局视角。先看宏观统计、再看单条连接细节、最后定向抓包，这套三连排查法比在大海一样的数据里盲目翻包高效得多。

6. 常见问题与排坑实录

6.1 Connection timed out 与 Connection refused 到底差在哪

两者经常被混淆，但含义完全不同。Connection refused说明目标端口上根本没有进程监听，操作系统收到SYN后直接回了一个RST包，客户端立刻收到错误。Connection timed out则说明SYN包发出去了，但一直没收到任何响应，这一般意味着对方不可达，或者被防火墙静默丢弃，或者服务端SYN队列满到没有能力响应。

排查时先看端口监听：ss -lnt里有对应端口说明是服务端队列或防火墙问题；没有则说明服务根本没启动。生产环境里“连接超时但有监听”更常见，这时去查SYN队列是否溢出、防火墙是否丢包，观察netstat -s里的SYNs to LISTEN sockets dropped计数值是否在涨。

6.2 Connection reset by peer 到底是什么信号

RST不是谈判，是“单方面撕毁协议”。当一端收到一个在它看来完全不合法的TCP段时，它不会礼貌地回复一个错误，而是直接发送RST终止连接。常见触发场景包括：

• 往一个已经关闭的连接上发数据（应用层bug或超时后依然读写）。
• 服务端程序崩溃、进程退出，之前建立的连接被内核直接RST。
• 有中间设备（防火墙、负载均衡）空闲超时把连接杀掉，之后两侧还有数据流动，其中一侧发现“这个连接不存在了”，于是RST。

如果你在客户端看到“Connection reset by peer”，最值得怀疑的就是服务端进程最近是否异常退出，或中间设备的空闲超时设置太短。抓包时看RST前后的上下文，能找到真正的原因。如果RST来自服务端且之前服务端刚刚发过FIN，那多半是应用层主动关闭后又有读写操作；如果RST来自一个从来没有SYN-ACK关系的IP，那就要警惕中间设备作妖了。

6.3 TIME_WAIT 堆积到六位数，到底慌不慌

高并发的短连接场景下，主动关闭方TIME_WAIT连接上万甚至上十万都出现过。很多人一看到十万级TIME_WAIT就慌，其实它本身只要不耗尽本地端口、不让内存暴涨，对系统没有致命影响。真正要担心的是两种衍生问题：端口耗尽，以及某些内核或设备对四元组数量有限制。

对主动连接方来说，本地端口范围是有限的，默认大约28000多个端口可用。如果TIME_WAIT堆积且不放量复用，很快就会出现“Address already in use”。当时我所在的系统就是这种状况：面对大量短连接出站请求，端口用完是迟早的事。

处理顺序建议先调大端口范围：

echo "net.ipv4.ip_local_port_range=1024 65000" >> /etc/sysctl.conf

再开tcp_tw_reuse让主动连接方安全复用TIME_WAIT连接，但务必确认所有相关机器时间戳一致、时间同步正常。服务端作为被动方一般少见TIME_WAIT堆积，更多的是CLOSE_WAIT堆积——那才是需要警惕的：CLOSE_WAIT意味着对端已关闭连接，但本地应用进程迟迟没有close()，通常就是应用代码漏关了socket。看到大量CLOSE_WAIT，先查应用日志里哪个连接池没有被正确回收。

6.4 TCP keepalive 不是万能心跳

TCP协议自带一个keepalive机制，定期探测连接是否仍然存活。但它的默认参数非常保守，Linux默认7200秒（2小时）才启动第一次探测，之后隔75秒探测一次，最多9次。也就是说一条连接彻底“死亡”，可能要等两小时才会被发现，这对大多数在线业务来说完全没有实用意义。

很多新手把宝压在TCP keepalive上，结果服务一端宕机，另一端用户还傻等着。工程上正确的做法是应用层心跳：自定义一种轻量消息，每几秒或十几秒发一次，超过若干个周期没收到就算连接挂了，主动重连。TCP keepalive可以调低作为辅助手段，但不能作为唯一的存活检测，因为它只能证明“内核协议栈还活着”，不能证明“服务进程和业务逻辑还活着”。如果服务进程死循环了，TCP连接看起来依然“健康”，但应用层早就没反应了。

6.5 最终排查的几条经验

TCP这个问题，越深入越发现它把“可靠性”四个字做得极度精巧。但我实际工作中的最大体会是：不要试图背住所有状态和参数，而是记住一个思维路径——先确认物理链路通不通，再确认端口和服务进程活不活，再确认握手和挥手状态正不正常，最后看抓包找丢包和重传。

分享一个我反复用的口诀：超时看链路，拒绝看监听，重置看进程，CLOSE_WAIT看代码，TIME_WAIT看端口。这一套走下来，绝大多数TCP相关故障都能定位到一个比较窄的范围了。

对后端开发者来说，应用层的心跳、连接池、超时设置往往比内核参数更能决定体验。内核参数是最后的手段，而不是第一选择，因为网络环境千差万别，调错一个参数的影响范围经常远超预期。我自己就在某次调优中把接收缓冲区调得过大，结果高并发场景下内存暴涨，引发了更大规模的服务不可用。

最后再讲一个心得：看书理解协议原理是一层，抓包看真实流量是一层，真正动手做一次丢包实验又是一层。这三层都走一遍之后，TCP对你来说就不再是面试题，而是一个真正趁手的排查工具。