聊到传输层协议TCP是怎么也绕不过去的一座山。很多人能把三次握手、四次挥手背得滚瓜烂熟可一上生产环境就露馅连接数只涨不降、带宽明明很充足但单连接就是跑不快、CLOSE_WAIT堆了一屏还不知道从哪儿查起。这篇文章是TCP系列的第二篇上一篇聊完协议定义和基础报文结构这篇集中讲我在实际排障和性能调优过程中反复用到的东西——连接管理的本质、状态机里那些容易被忽略的细节、可靠传输的重传博弈、三个窗口如何决定吞吐上限以及动内核参数之前应该想清楚的事。读这篇文章不需要你把RFC倒背如流但最好已经对TCP的三次握手、四次挥手、TCP头基本字段有概念。如果你只是听说过TCP这个词建议先补一点基础再回来。下面这些内容都是我在处理真实业务问题时用过、踩过、验证过的思路不是教科书复读。1. 连接不是“通路”而是两个方向各自独立的状态机1.1 双向字节流到底意味着什么TCP提供的是全双工可靠字节流。这句话拆开来看分量很重。“全双工”意味着两个方向上的数据传输互不干扰各自维护独立的序号空间、确认号和窗口信息。A发给B的数据包和B发给A的数据包虽然在物理网络上走的可能是同一条路但在TCP的逻辑里完全是两个独立的数据流。发送方A需要维护自己的发送序号、已经发送但还没被确认的字节范围接收方B需要维护“我希望收到的下一个字节序号”。反过来B到A的方向同样如此。所以一个TCP连接本质上不是一根“管道”而是两根逻辑上独立的“传送带”只是被协议封装成了同一个socket对象。这个区别在写代码时影响很大。比如你调用shutdown(fd, SHUT_WR)只关闭发送方向接收方向依然可以继续收数据。这是TCP半关闭能力HTTP/1.1的有些场景会用到但很多新手容易忽略它。还有一点经常被误解ACK不是“收到包”的回执而是“我期待的下一个字节序号”。也就是说ACK1000代表1到999全部收到这种累计确认模型是TCP可靠传输的地基。1.2 三次握手的语义为什么必须是三次三次握手看起来简单但很多人没有真正理解它解决的对称性问题。A发送SYN携带A的初始序号B回复SYNACK既确认了A的序号也带出自己的初始序号A再回复ACK确认B的序号。关键点在于只有经过这三步双方才能互相确认“我的初始序号你收到了你的初始序号我也收到了”。如果只有两次握手A能确认B收到了自己的SYN因为B的ACK就是证据但B无法确认自己的SYNACK是否被A收到也就是说B不知道A是否已经准备好进入数据收发状态。三次握手在工程上的另一个作用是双方在建立阶段就可以协商连接参数——MSS最大报文段长度、窗口缩放因子、SACK支持、时间戳选项等。这些选项协商失败或配置不对称时后续性能问题会非常隐蔽。我见过一个案例两端MSS协商出了一个很保守的值导致有效载荷利用率极低业务吞吐怎么都上不去查了很久才发现是中间MTU限制导致MSS被钳制。1.3 四元组、连接复用与“连接数上限”的误解TCP连接由四元组唯一标识源IP、源端口、目的IP、目的端口。这意味着服务器端同时支持的连接数并不受65535个端口限制。只要客户端来自不同IP或不同源端口四元组就不会冲突。真正限制连接数的是文件描述符上限、内存、内核连接跟踪表大小以及epoll等事件驱动模型的事件处理能力。我在很早之前踩过一个坑把服务器的ulimit文件描述符调上去了但忽略了内核netfilter连接跟踪表的默认上限高并发下一半的连接建立请求被静默丢弃。后来调整了相关内核参数配合连接复用策略才把问题解决。另外要注意区分“连接建立快”和“连接可用”。生产环境中SYN_RECV状态大量堆积往往是握手阶段出了问题可能是被防火墙丢包也可能是SYN队列半连接队列溢出。而ESTABLISHED异常增多则可能是应用层没有正确关闭连接。状态分布的解读是整个TCP排障的基础。2. 状态机里最容易被忽略的两个状态TIME_WAIT与CLOSE_WAIT2.1 TIME_WAIT的2MSL到底在保护什么主动关闭方在发出最后一个ACK之后会进入TIME_WAIT状态且必须等待2MSLMSLMaximum Segment Lifetime报文最大生存时间才能彻底释放连接。TIME_WAIT不是连接泄漏它保护的是两件事。第一确保对方收到最后的ACK。如果被动关闭方没有收到ACK它会超时重发FIN主动关闭方此时可以再次回应ACK。如果直接释放连接这个最后的ACK一旦丢失对方会永远卡在等待关闭的状态。第二让本连接的所有旧报文在网络中自然消失。MSL是IP报文在网络上允许存活的最长时间。等待2MSL才能保证一个方向的旧报文消失后另一个方向的旧报文也消失。这样同一个四元组复用之后就不会出现“新连接收到了旧连接的迟到数据”这种幽灵报文问题。Linux的TIME_WAIT实际周期通常是60秒小于RFC建议的2分钟但对绝大多数业务来说足够。我之前排查过一个高并发短连接服务TIME_WAIT数量峰值达到几十万看起来吓人但用不同维度观察下来内存占用和端口使用都在可控范围加上开启了端口复用策略最终并没有影响业务。真正需要警惕的不是TIME_WAIT的数量而是它是否导致了本地端口耗尽或者与新连接的四元组冲突。2.2 CLOSE_WAIT堆积被动关闭方忘了closeCLOSE_WAIT是被动关闭方收到对方FIN、已经回复ACK但自己还没有调用close时进入的状态。如果应用代码里没有正确关闭socket连接就会一直停留在CLOSE_WAIT。这类问题在实际生产中出现频率极高。常见原因有几个处理请求的代码只关注正常分支异常分支没有释放连接使用了连接池但回收逻辑没有覆盖空闲超时的场景依赖的第三方客户端库内部出错但没有触发连接清理。CLOSE_WAIT堆积无法靠改内核参数解决因为内核已经把“对方关闭”这个事实告诉了你接下来是由应用决定何时关闭自己的socket。我排查CLOSE_WAIT时有一套固定的流程。先用以下命令看状态分布ss -ant | awk {print $1} | sort | uniq -c如果看到CLOSE_WAIT数量持续增长且不下降再用ss -antp找到具体持有连接的进程。然后抓包确认对方是否已经发出FIN本端是否只回了ACK而没有继续发FIN。定位到代码层面之后通常就是给每个连接路径补上finally式清理逻辑。CLOSE_WAIT出现本身不可怕可怕的是它在压测和线上长时间只增不减。2.3 一个典型的排查链路复盘有次排查一个“连接数只涨不降”的问题第一眼看到的是CLOSE_WAIT维持在6000以上正常应该是个位数到几十。第一步排除内核问题服务器负载正常文件描述符没有跑满连接跟踪表也没有溢出。第二步抓包发现客户端已经发了FIN服务端回了ACK之后再也没有后续报文。到这一步基本确定服务端应用层收到了EOF但相关socket没有被业务代码关闭。顺着代码往上追最终定位到某个连接池模块的异常回调里数据库连接对象虽然被标记释放但底层的TCP socket没有调用close。这类问题有个特点压测初期不明显随着连接持续创建和异常触发CLOSE_WAIT会像滚雪球一样涨起来。教训也很直白只要你的代码打开了socket或者接受了连接就必须保证所有分支最终都会走关闭逻辑不能依赖“对方先关”的侥幸。3. 可靠传输的真正核心确认与重传的博弈3.1 累计确认与SACK补漏的两种思路TCP的ACK字段表示“期望收到的下一个序号”所以收到ACK1000时发送方就知道1到999已经全部到达。累计确认的好处是状态简单不好之处是当中间一段丢了接收方只能不断重复确认那个“期望序号”发送方无法知道丢包之后的那些字节是否也已经到达。于是就有了SACKSelective Acknowledgment选择性确认选项。SACK允许接收方在ACK里附加多段不连续数据的边界信息告诉发送方“我收到了哪些块”。发送方只需要重传缺失部分不必把后续未确认的数据全量重发。在丢包率偏高的网络环境中SACK能显著节省带宽和重传时间。SACK看似只是一个小选项但部署时的兼容性问题很容易被忽略。连接建立时双方会在SYN中协商SACK支持能力如果中间设备或者某些协议栈不支持SACK选项就会出现握手正常但后续性能异常的情况。我之前遇到过抓包看到大量重复ACK实际就是SACK协商失败后发送方退化为整段重传表现上跟“网络特别差”一模一样。3.2 RTO为什么难算Karn算法与重传二义性发送方不能无限等地ACK否则一个丢失的包会让整个传输挂死。它需要根据RTT动态计算重传超时时间RTO。但问题在于如果一个报文触发了重传那么之后到达的ACK到底是对应第一次发送的报文还是对应重传后的报文这个“重传二义性”会让RTT采样失真。Karn算法解决了这个问题重传过的报文段其RTT样本不参与RTO估计并且一旦发生重传RTO按指数退避通常乘以2。这是为了避免在已经拥塞的网络中短RTO再一次次触发重传把网络推入更严重的拥塞。现代Linux使用的是RFC 6298推荐的估算模型基于SRTT平滑RTT和RTTVARRTT方差计算RTO同时设置了时钟粒度G和1秒的下限。这个1秒下限很关键它防止在内核时钟粒度极细时RTO被算成一个不现实的小值导致大量误重传。我之前分析一个高精度时钟环境下的传输抖动问题最终发现就是RTO计算过于敏感频繁重传反而把管道打满限制RTO下限之后吞吐立刻稳了。3.3 快速重传与拥塞控制的联动连续收到3个重复ACK会触发快速重传。为什么是3个而不是1个因为网络乱序也会产生重复ACK一个重复ACK可能只是某个包饶了点路后面马上就到连续出现3个重复ACK则大概率是真的丢了。快速重传的好处是无需等待RTO超时节省了宝贵的等待时间。但快速重传不只是“重传”这么简单。同一时刻它意味着发送方收到了乱序的ACK这在TCP的拥塞控制模型里被视为网络可能拥塞的信号。于是发送方要进入拥塞控制流程ssthresh减半cwnd调整从激进发送转向保守试探。一个常见误区是把快速重传当成万能药为什么开了快速重传丢包时传输还是慢原因往往不在重传本身而在拥塞窗口的恢复策略。比如超时重传会导致cwnd直接回到初始窗口需要重新慢启动而快速重传进入快速恢复窗口可以维持在一个较高水平。如果大量丢包是偶发散发的快速恢复表现良好如果是持续性拥塞合理策略反而是主动降速。4. 三个窗口共同决定你能跑多快4.1 rwnd接收方说“我吃不动了”rwnd接收窗口是TCP头部16位窗口字段承载的值配合窗口缩放选项后可以支持非常大的窗口。它表示接收方当前还能接收多少数据。rwnd0意味着接收缓冲区已满发送方必须停下来并通过persist定时器周期发送窗口探测报文。如果没有这个机制一旦窗口恢复而发送方不知道双方就可能一直僵持。实际业务中接收方窗口变小最常见的场景是应用层读取太慢。数据库批量插入、磁盘IO抖动、业务逻辑阻塞都会导致socket接收缓冲区被积压数据填满rwnd逐渐缩小到0。此时抓包会看到一串连续的ACK窗口字段从大变小直到0。遇到这种问题优先优化应用读取和消费速度而不是调大缓冲区。缓冲区调大了只是把问题往后拖消费端跟不上窗口迟早还是会归零。4.2 cwnd发送方给自己画的边界cwnd拥塞窗口是发送方基于对网络状况的判断自己允许连续发送的数据量。它和rwnd共同构成有效窗口发送方实际可以发送的数据量是两者中的较小值。cwnd的演进是整个TCP性能行为最精彩的部分。慢启动阶段每收到一个ACKcwnd增加一个MSS所以每个RTT窗口翻倍指数增长。当cwnd达到ssthresh慢启动阈值后进入拥塞避免阶段每收到一个ACK只增加MSS/cwnd相当于每个RTT线性增长。一旦检测到丢包超时重传是猛药cwnd回到初始窗口重新慢启动快速重传则触发快速恢复ssthresh设置为cwnd的一半cwnd设置为ssthresh加3个MSS。这套设计背后的逻辑是TCP不知道网络还有多少剩余容量只能通过“试探-反馈-修正”来逼近。慢启动快速上升是为了尽快找到可用带宽的近似值拥塞避免线性增长是为了在接近上限时平稳试探丢包降窗则是反馈机制防止持续拥塞打垮网络。4.3 BDP视角为什么带宽高但单连接依然很慢有一个公式值得反复默念TCP单连接稳态吞吐上限约等于窗口大小除以RTT。这里窗口取rwnd和cwnd中较小值。假设带宽是100MbpsRTT是100ms带宽时延积BDP算下来大约是1.25MB。如果接收窗口只有64KB理论吞吐就被限制在640KB/0.1秒约6.4MB/s也就是50Mbps左右——带宽再高也跑不上去。很多“服务器带宽很大但单连接下载很慢”的排查最终都能归到BDP上。先看接收窗口和拥塞窗口再算BDP就能判断瓶颈是窗口不够还是丢包降窗。实际调优时我会先用iperf做一个长流测试如果发现窗口总是触顶就增大发送接收缓冲区如果窗口没触顶但吞吐低则去抓包看是否是丢包和重传导致的cwnd收缩。5. 生产环境中调整TCP参数后积累的教训5.1 缓冲区默认值在高延迟链路上不够用Linux的tcp_rmem和tcp_wmem各包含三个值最小值、默认值和最大值。对于跨地域、跨机房的传输链路RTT通常几十到几百毫秒BDP可能远大于内核默认缓冲区大小。比如RTT为80ms带宽为200Mbps时BDP约2MB。如果默认缓冲区只有几十KB单连接吞吐就会被缓冲区大小卡死。所以我的经验是先测算BDP再把缓冲区默认值调到BDP量级附近。但改默认值影响所有新建连接要在一个可控范围或测试环境先验证不要直接在核心生产机上全局修改。曾经调大默认缓冲区后内存占用上升明显但吞吐并没有随之线性增长——后来发现是接收端消费慢再大的缓冲区也只是增加等待时间。调参前一定要先搞清楚瓶颈在哪个方向。5.2 Nagle算法与延迟确认的互相等待Nagle算法会把多个小数据包合并成一个大包再发送目的是减少网络中的小报文数量。延迟确认则是接收方不立刻回复ACK而是等待一小段时间期望能搭上反向数据包一起发送。两个机制单独看都合理但组合在一起就可能出现“互相等待”发送方因为Nagle算法攒着新数据不发等之前的包被确认接收方因为延迟确认不发送ACK等新数据到达或超时。最终结果就是额外的几十甚至上百毫秒延迟。曾经有个“程序里加个sleep反而更快”的案例原因就是Nagle和延迟确认互相卡住。处理办法其实不复杂小包交互、低延迟优先的场景在socket上启用TCP_NODELAY禁用Nagle高频大块数据传输场景Nagle对吞吐影响不大不必强行关闭。关键是要理解机制而不是靠网络流传的“加个sleep”玄学。5.3 超时与保活配置必须匹配全链路TCP SYN重传、SYN-ACK重传、Keepalive探测这些参数在排障时很容易被忽略。前端网关通常有自己的超时时间后端服务的TCP Keepalive周期如果远大于网关超时就可能出现“网关以为连接还在后端其实已经释放了”的错位。下次请求打过来时表现就是Connection reset。TCP Keepalive默认两小时才启动一次探测对大多数互联网业务来说太慢了。更可靠的做法是在应用层做心跳周期可控能携带业务信息也比TCP层探测更容易定位问题。同时网关超时时间要大于后端最长处理时间重试请求要保证幂等。这些不完全是TCP参数问题但如果你只看内核参数而忽略整条链路的超时设计TCP状态再正常业务照样会失败。最后再分享一个小习惯排查任何TCP相关问题时我都是先看状态分布再抓包看时序最后才考虑动内核参数。顺序反了往往会把原本简单的应用层问题变成一次复杂且低效的内核调优。TCP的知识点很多但真正决定线上表现的是对“连接生命周期”和“窗口变化”的敏感度。下一篇如果继续写我想专门聊聊拥塞控制算法在不同网络场景下的行为差异以及eBPF观测连接状态的实践。