1. 先搞清楚TCP到底在解决什么问题干网络和系统运维这块的人迟早都得跟TCP协议正面打交道。我入行那会儿第一次背三次握手的状态变迁背得晕头转向后来真正上手抓包排查问题才明白那些状态机不是拿来考试的而是每一个字段、每一次重传背后都对应着真实的网络故障。今天这篇就把TCP从原理到实操完整捋一遍顺便聊聊怎么分析、甚至怎么修改TCP协议包以及UDP和TCP到底怎么选。先说清楚一个前提TCP不是孤立存在的它跑在IP协议之上两者合起来就是常说的TCP/IP协议族。IP协议负责把数据包从一台机器送到另一台机器但它只保证尽力而为——包丢了没人管包重复了没人管顺序乱了也没人管。而TCP做的事情就是在这条不可靠的IP通道之上实现一条逻辑上可靠的字节流。打个比方你就懂了。IP协议就像你往邮筒里扔一封平信寄丢了你也不知道寄到了你可能也收不到回执。TCP则是挂号信服务每一封都有编号收件人要签收寄件人没收到签收回执就重新寄而且收件人收到的信件会按照编号重新排好顺序保证最终读到的是完整连贯的内容。TCP解决的核心问题可以归纳成四个可靠传输、流量控制、拥塞控制和连接管理。这篇文章适合谁看后端开发排查接口超时、运维工程师分析网络延迟、测试同学用抓包工具定位问题、以及对网络协议好奇的学生。前面机制部分我会讲得通俗一点后面实操部分可以直接照着抄。2. TCP的核心机制逐个拆解它凭什么敢说“可靠”2.1 三次握手不是仪式感是双方确认能力的过程TCP建立连接要经过三次握手这是所有教科书里都会画的一张图。客户端先发SYN包服务端回SYNACK包客户端再回ACK包连接建立。为什么必须是三次而不是两次我当年也疑惑过后来用场景推演就明白了。假设只有两次握手客户端发SYN服务端收到后回ACK连接就算建立。问题是如果客户端第一个SYN因为网络拥塞卡在中间超时了客户端迟迟等不到回应于是重发一个SYN给服务端。服务端收到第二个SYN并回复ACK连接建立开始传数据一切正常。但这时候那个卡在半路的旧SYN突然又到了服务端服务端以为客户端又要建立新连接于是又回了一个ACK。这个连接建起来是没有任何意义的——客户端根本不知道这回事也不会往这个连接上发数据。服务端却傻乎乎地维持着这个连接白白占用资源直到超时。三次握手就避免了这个问题。客户端收到服务端的SYNACK后如果发现这个ACK对应的序列号不是自己期望的因为旧SYN已经被客户端抛弃了客户端可以直接发RST把这个幽灵连接杀掉或者干脆不予理会让服务端超时关闭。三次握手的本质是双方各自确认你能收到我的消息我也能收到你的消息同时交换初始序列号ISN让后续的可靠传输有一个共同的起点。实操中有一个点很多人容易忽略第一次握手时客户端发送的SYN包里ISN是随机生成的。这个随机性不是为了花哨而是为了防止序列号预测攻击——如果有人能猜出你的序列号就可以伪造数据包插入到你的连接里。所以现在的操作系统在生成ISN时都加入了随机偏移别觉得这是多余的设计。2.2 四次挥手与TIME_WAIT断开连接比建立连接更讲究断开连接需要四次挥手这个我建议你结合状态变迁来理解。主动关闭的一方发FIN对方回ACK然后对方再发FIN最后主动方回ACK连接关闭。为什么断开要四次因为TCP允许半关闭状态——一端停止发送数据但仍然可以接收数据所以每一端的关闭都需要独立确认。我工作中实际踩得最多的坑是TIME_WAIT状态。主动关闭连接的一方在发出最后一个ACK之后不会立即释放连接而是要进入TIME_WAIT状态等待2MSLMaximum Segment Lifetime报文最大生存时间通常为60秒到2分钟之后才彻底关闭。很多人不理解这最后一步有什么意义觉得是浪费资源。其实这是TCP最精妙的安全设计之一。TIME_WAIT存在两个目的。第一防止最后一个ACK丢失。如果主动方的最后一个ACK在网络中丢了被动方会因为没有收到ACK而重新发送FIN如果主动方已经释放了连接哪还有进程来回应这个FIN老连接彻底断掉新连接还没建立被动方就会一直纠结在LAST_ACK状态。第二防止旧连接的数据包串到新连接。如果主动方关闭后立刻用同一个四元组建立新连接延迟到旧的FIN或数据包到达时新连接就会被污染。TIME_WAIT就是给网络上残留的旧包一个过期作废的缓冲期。2.3 重传机制丢了就重新发什么时候发才是关键TCP保证可靠传输的基础是确认重传。发送方发一个数据段接收方收到后回ACK确认发送方如果在一定时间内没收到ACK就认为包丢了重新发送。这里的核心问题是等多久才算超时最早TCP用固定的超时时间去判断后来发现这行不通——局域网内1毫秒就能确认的包放到跨洲链路上可能要几百毫秒。所以TCP引入了自适应算法根据每次往返时间RTT动态计算超时时间RTO。实测下来RTO通常等于平滑后的RTT加上4倍的均方差这样在网络抖动时能自动放宽超时阈值网络稳定时又能快速重传。还有个机制叫快速重传。发送方连续收到三个重复的ACK说明对端的接收窗口已经空了中间大概率丢了包这时候不用等超时直接重传。这个机制排障时特别有用——在Wireshark里看到一串Duplicate ACK基本就能断定网络上发生了丢包。2.4 滑动窗口与流量控制别人碗多大你就盛多少饭可靠传输解决了包丢了怎么办但没解决对端处理不过来怎么办。想象一下接收方的应用层程序读数据很慢缓冲区已经塞满了发送方还在拼命发结果就是大量数据被接收方丢弃触发重传风暴越传越乱。流量控制就是来解决这个问题的。滑动窗口的核心是一个承诺机制。接收方在每一个ACK里都会带上自己的接收窗口大小rwnd告诉发送方你最多还能发这么多字节多了我接不住。发送方的发送窗口不能超过这个值这就是流量控制。我调试过一个真实的案例一个文件传输服务在内网传输速度正常跨公网就慢得像蜗牛抓包发现接收方的rwnd被人为配置成了极小值导致发送方每发一个窗口的数据就要停下来等窗口更新。后来查下来是应用程序在套接字层面设置了过小的接收缓冲区把系统默认的几百KB改成了几KB。所以排查传输慢问题时别只盯着带宽先看一眼窗口字段——有时候杯小比路堵更致命。2.5 拥塞控制别让全网陪你一起堵流量控制保护的是单个接收端拥塞控制保护的则是整条链路上的路由器。路由器也有缓冲区一旦瞬间到达的数据量超过路由器处理能力路由器只能丢包。TCP为了不把网络堵死设计了拥塞控制机制核心是让发送方主动控制自己的发送速度。拥塞控制有几个关键阶段慢启动、拥塞避免、快速重传和快速恢复。慢启动是连接刚建立时发送方的拥塞窗口从1个报文段开始每收到一个ACK就翻倍增长呈指数级上升。这个机制看起来慢其实是在小心翼翼地探测网络容量。当拥塞窗口增长到慢启动阈值ssthresh就进入拥塞避免阶段改为线性增长。一旦检测到丢包就把ssthresh减半拥塞窗口直接降到1从头开始。我在实践中学到的教训是慢启动对短连接影响很大。比如一个新的HTTP连接往往还没把拥塞窗口涨到全速请求就已经发完了而长连接比如数据库连接池就能在慢启动之后维持一个较大的窗口传输效率高得多。这也是为什么现在很多服务都强调连接复用不只是省去握手开销拥塞窗口的热启动同样重要。3. TCP和UDP没有优劣之分只有合不合适3.1 一张表看懂核心差异很多新人一上来就问TCP好还是UDP好我一般都会说这两个不是竞争关系是分工关系。UDP和TCP协议的区别本质上就是可靠但重和轻量但糙的区别。对比维度TCPUDP连接状态面向连接需三次握手无连接直接发包可靠性可靠有确认重传不可靠丢了就丢了数据有序性保证字节流顺序不保证顺序传输模式字节流数据报头部开销20字节起步固定8字节流量控制/拥塞控制有没有适用场景HTTP、FTP、SSH、数据库DNS、视频直播、语音通话、游戏从这张表能看出来UDP头部只有8个字节没有序列号、没有确认机制、没有窗口字段它就是把数据包直接扔给IP层能不能到、到了乱不乱序它一概不管。代价是它极轻量延迟可控不会因为重传产生额外抖动。3.2 选型经验三个判断标准实际项目里怎么选我总结了一套简单的判断方法。第一数据丢了能不能忍比如网页、文件传输、数据库事务任何一点数据丢失都是不可接受的直接选TCP。但视频通话和在线游戏偶尔丢一帧画面、掉一个操作包用户是感知不到的这时候TCP的重传反而变成灾难——重传的数据已经过期了只会增加延迟和卡顿UDP更合适。第二对延迟的敏感度有多高TCP的拥塞控制遇上网络抖动会主动降速这在实时音视频场景里非常致命。而UDP没有这些制约应用层可以自己决定丢哪些包、重发哪些包策略灵活得多。现在很多音视频传输都是基于UDP做的。第三有没有TCP的替代方案这几年QUIC协议冒头了它基于UDP实现了TCP的可靠性和安全性但把拥塞控制、重传逻辑搬到了用户态还解决了TCP的队头阻塞问题。HTTP/3跑在QUIC上。如果你维护的是面向弱网场景的应用值得认真研究一下QUIC它算是兼顾了TCP和UDP两者优点的新路线。还有一个容易被忽视的细节DNS查询用的就是UDP。你可能觉得DNS丢了就得重新解析不也是重传吗但操作系统的解析器有自己的超时重发机制而且DNS报文通常很小一个包就能装下整个查询和响应用UDP足够应对还省去了握手的开销。4. TCP协议包从读懂结构到动手修改4.1 TCP头部20字节里的信息量既然要把协议包分析明白先得能把TCP头部读懂。TCP头部最小20字节没有选项字段时刚好就是20字节。我建议你把每个字段的位置和含义记清楚抓包的时候下意识就能扫出来源端口16位和目的端口16位标识连接的两端应用。序列号32位本报文段第一个字节的序号。确认号32位期望对方下一个发送的字节序号也代表之前的数据已全部收到。数据偏移4位表示TCP头部的长度以4字节为单位。头部有选项时这个值会大于5。标志位共8位常用6位URG、ACK、PSH、RST、SYN、FIN。握手看SYN和ACK断开看FIN异常复位看RST。窗口大小16位接收方通告的剩余接收能力。校验和16位对整个TCP报文段做校验。紧急指针16位配合URG标志使用平时用不到。选项字段虽然不算在基础20字节里但实际抓包经常见到最常见的三个是MSS最大报文段长度、SACK选择性确认和时间戳。MSS在握手时协商告诉对方自己愿意接收的最大报文段大小一般取网卡MTU减去IP头和TCP头典型的1500字节MTU对应MSS就是1460。SACK允许接收方告诉发送方我缺的是哪一段而不是只报告最后一个连续收到的字节序号配合快速重传能大幅提升丢包场景下的恢复效率。4.2 抓包入门tcpdump和Wireshark的基本操作分析TCP协议包第一步是把它抓下来。Linux服务器上最常用的是tcpdump命令简单但不提一下容易出错。# 抓取指定端口所有流量不解析域名 tcpdump -i eth0 -nn port 8080 -w /tmp/http.pcap # 只抓SYN包 tcpdump -i eth0 -nn tcp[tcpflags] tcp-syn ! 0 and tcp[tcpflags] tcp-ack 0 # 抓带RST标志的包排查连接被重置的问题 tcpdump -i eth0 -nn tcp[tcpflags] tcp-rst ! 0抓下来的pcap文件用Wireshark打开看最直观。Wireshark里我常用的几个操作先用过滤栏输入tcp.stream eq 0把某个连接的完整对话拎出来然后看Expert Infos窗口里面会直接标注出重传、重复ACK、零窗口等异常事件再看Time列能判断每一跳的延迟波动。Wireshark会把TCP的Seq和ACK换算成相对值看起来清晰但如果你要匹配协议字段的原始值记得关掉Preferences里的Relative sequence numbers选项。4.3 改包到底怎么改三种路径和一堆坑说到TCP协议包如何修改这其实是网络排查和协议开发里很常见的需求。改包不是让你去篡改线上数据而是为了测试、定位问题、验证策略。我实际用过的路径大概有三种。第一种调整系统的TCP行为参数间接改变发出的包内容。这是最安全、最常见的方式。比如通过修改MTU和MSS来调整报文段大小命令是ip link set dev eth0 mtu 1400改完TCP握手时协商的MSS也会跟着变。再比如修改TCP时间戳选项Linux内核参数net.ipv4.tcp_timestamps控制是否在TCP头部加时间戳置0关掉后Debian系统才愿意和某些防火墙兼容。这种改法的特点是作用于整个系统不会动到单个应用的数据。第二种用Scapy这类工具精确构造和发送自定义TCP包。Scapy是Python生态里最常用的报文构造库我曾经用它模拟一个畸形握手包来测试服务器的健壮性from scapy.all import IP, TCP, send # 构造一个SYN包故意设置异常的窗口大小 packet IP(src192.168.1.100, dst192.168.1.1) / TCP( sport12345, dport80, flagsS, seq1000, window0 ) send(packet)注意用Scapy构造原始包时IP层和TCP层的字段都是你自己指定的内核的网络协议栈不会插手。这意味着你发的包可能不符合标准TCP行为接收方可能直接丢弃或者触发安全告警。我建议只在测试环境做生产环境别玩这个容易把自己玩进去。第三种如果只是分析线上某个连接的包内容不需要真的修改谁可以用tc的netem内核模块来模拟丢包和延迟从效果上修改链路的体验# 模拟30%丢包10ms延迟 tc qdisc add dev eth0 root netem loss 30% delay 10ms # 清掉所有netem规则 tc qdisc del dev eth0 root netem这种做法在验证TCP拥塞控制、重传行为时非常好用比改包更贴近真实故障。我在测试环境模拟弱网时几乎每天都和netem打交道。4.4 实战复盘一个靠抓包定位的应用层大坑分享一个真实案例。前两年有个同事反馈某内部系统调用外部门户的OpenAPI偶尔出现读超时大概每10次请求有1次必挂。业务日志里没有任何异常应用层代码看了好几遍也没发现问题。我用tcpdump抓了20分钟包发现规律出问题的那次请求客户端发出SYN后服务端立刻回了SYNACK但客户端回应ACK之后服务端没有再往这个连接上发任何HTTP应答数据连接就这么晾着直到客户端超时触发RST。进一步看出错的连接上服务端发过来的SYNACK里MSS协商出来只有1360字节比正常值1460小一点。我当时怀疑是MTU发生了什么一查服务端那条链路确实配置了较小的MTU。问题不在TCP本身而是服务端应用的HTTP框架没有正确处理TCP半连接或代理链路重组。后来联系对方运维调整了中间防火墙的MTU设置把MSS协商恢复了正常值问题就消失了。这个案例给我最大的启发是TCP报文里每一个字段都是线索不要只看协议状态还要看协商出来的参数是否合理。MSS、窗口大小、时间戳任何一个异常都值得深挖。5. 常见问题排查与内核调优实录5.1 连接建立失败SYN风暴和半连接队列线上最常见的问题是连不上。如果客户端发SYN后一直收不到SYNACK或者收到RST基本可以锁定在握手环节。排查思路我一般这么走先在客户端抓包确认SYN确实发出去了再到服务端抓包确认SYN有没有到达两侧一对故障区段就出来了。如果你发现SYN到了服务端但没有响应优先查半连接队列是否溢出。Linux内核接受一个TCP连接前先把连接放到半连接队列syn queue完成握手后再移到全连接队列accept queue给应用accept。如果队列满了内核就直接丢弃新到的SYN包。查看方式很直接netstat -s | grep -i listen输出里如果看到SYNs to LISTEN sockets dropped说明半连接队列丢包了这时候需要调大net.ipv4.tcp_max_syn_backlog同时检查应用是否及时accept连接。有一次我排查一个Tomcat实例连不上就是全连接队列满了Tomcat的accept线程卡死在慢SQL上新连接全部排队等死队列一满内核直接丢包。5.2 传输速度上不去Nagle算法和延迟确认的相爱相杀传输慢的原因千奇百怪但有两个算法导致的经典场景非常值得单独说——Nagle算法和延迟确认。Nagle算法的逻辑是发送方发送一个小包后必须在收到该包的ACK后才能继续发送下一个包本质是把多个小包合并成大包减少小报文数量。延迟确认则是接收方收到数据后不立即回ACK而是等一小段时间希望把多个ACK合并成一个或者捎带上应用层的响应数据。这两者单独工作都合理但如果一边开Nagle一边没关延迟确认就会出现经典的粘包死锁发送方因为Nagle捏着一个未确认的小包不肯发后面的数据接收方因为延迟确认迟迟不回ACK。两边互相等传输延迟瞬间飙高。最典型的就是某些老式Telnet和远程终端场景。解决办法如果应用传输的是交互式小包数据可以在套接字层面关闭Nagle算法int flag 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, flag, sizeof(flag));抓包确认是否受Nagle影响有个简单方法看Wireshark里是不是大量出现发送一个小包等待ACK再发下一个小包的锯齿状时序。如果是关掉Nagle立刻见效。不过话说回来Nagle算法对Bulk传输大块数据是友好的别一上来就盲目关闭得先判断你的业务包大小特征。5.3 TIME_WAIT堆积怎么判断真的有问题短连接高并发的服务TIME_WAIT堆积到几万个是常事。很多人一看ss -s输出里TIME_WAIT很多就慌其实要分情况。TIME_WAIT本身不占用文件描述符也不占用应用内存它只是内核里一个残留的连接记录。真正的问题是TIME_WAIT过多时四元组源IP、源端口、目的IP、目的端口可能短期无法复用导致新连接无法建立。我的处理优先级是这样的先看服务端还是客户端堆积再看应用能不能支持连接复用。HTTP Keep-Alive能极大降低TIME_WAIT数量因为连接可以反复使用。如果业务形态实在无法避免大量短连接再考虑内核参数调整。Linux提供了两个常见参数sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.tcp_fin_timeout10tcp_tw_reuse只对客户端生效允许内核安全地复用处于TIME_WAIT的连接tcp_fin_timeout缩短主动关闭方的等待时间。注意tcp_tw_recycle这个参数我强烈建议不要碰它在NAT环境下会引发严重的连接问题旧版本内核里开启后可能导致部分NAT用户完全无法访问很多运维事故都是因为它。5.4 内核调优速查表记下这几个就够用了Linux网络栈可调的参数非常多但我实际运维中真正用得频繁的就那么几个整理成一张表方便你直接查参数默认值作用建议场景net.core.somaxconn4096全连接队列上限高并发Web服务调到1024以上net.ipv4.tcp_max_syn_backlog128或更高半连接队列上限遭遇SYN丢弃时调大net.ipv4.tcp_slow_start_after_idle1空闲后是否重置拥塞窗口低延迟场景可置0保持热窗口net.ipv4.tcp_fin_timeout60FIN等ACK的超时时间高短期连接场景可设为10net.ipv4.tcp_keepalive_time7200空闲多久开始探测长连接保活可调到300net.ipv4.tcp_tw_reuse0TIME_WAIT快速复用客户端高并发短连接场景我个人的习惯是调参之前一定先抓包看数据用数据说话。很多工程师一上来就照着网上的性能优化十招把参数全改一遍改完发现有些场景反而变慢了——比如tcp_slow_start_after_idle0虽然在空闲重连时能保持拥塞窗口但如果是大量短周期小流量这个改动几乎无感还可能让空闲连接瞬间冲击网络。最后分享一个排查时特别实用的技巧把ss -tinp的输出结合抓包一起看。它能直接显示每个连接当前的cwnd拥塞窗口、ssthresh、RTT等实时值配合Wireshark的IO Graph画出吞吐曲线定位为什么慢的效率会高得多。TCP虽然是个几十年前的老协议但它每一个字段、每一个状态都是一线排障的线索耐心把底层的为什么搞明白比背多少条调优命令都管用。 TCP协议核心机制解析与抓包调优实战指南
1. 先搞清楚TCP到底在解决什么问题干网络和系统运维这块的人迟早都得跟TCP协议正面打交道。我入行那会儿第一次背三次握手的状态变迁背得晕头转向后来真正上手抓包排查问题才明白那些状态机不是拿来考试的而是每一个字段、每一次重传背后都对应着真实的网络故障。今天这篇就把TCP从原理到实操完整捋一遍顺便聊聊怎么分析、甚至怎么修改TCP协议包以及UDP和TCP到底怎么选。先说清楚一个前提TCP不是孤立存在的它跑在IP协议之上两者合起来就是常说的TCP/IP协议族。IP协议负责把数据包从一台机器送到另一台机器但它只保证尽力而为——包丢了没人管包重复了没人管顺序乱了也没人管。而TCP做的事情就是在这条不可靠的IP通道之上实现一条逻辑上可靠的字节流。打个比方你就懂了。IP协议就像你往邮筒里扔一封平信寄丢了你也不知道寄到了你可能也收不到回执。TCP则是挂号信服务每一封都有编号收件人要签收寄件人没收到签收回执就重新寄而且收件人收到的信件会按照编号重新排好顺序保证最终读到的是完整连贯的内容。TCP解决的核心问题可以归纳成四个可靠传输、流量控制、拥塞控制和连接管理。这篇文章适合谁看后端开发排查接口超时、运维工程师分析网络延迟、测试同学用抓包工具定位问题、以及对网络协议好奇的学生。前面机制部分我会讲得通俗一点后面实操部分可以直接照着抄。2. TCP的核心机制逐个拆解它凭什么敢说“可靠”2.1 三次握手不是仪式感是双方确认能力的过程TCP建立连接要经过三次握手这是所有教科书里都会画的一张图。客户端先发SYN包服务端回SYNACK包客户端再回ACK包连接建立。为什么必须是三次而不是两次我当年也疑惑过后来用场景推演就明白了。假设只有两次握手客户端发SYN服务端收到后回ACK连接就算建立。问题是如果客户端第一个SYN因为网络拥塞卡在中间超时了客户端迟迟等不到回应于是重发一个SYN给服务端。服务端收到第二个SYN并回复ACK连接建立开始传数据一切正常。但这时候那个卡在半路的旧SYN突然又到了服务端服务端以为客户端又要建立新连接于是又回了一个ACK。这个连接建起来是没有任何意义的——客户端根本不知道这回事也不会往这个连接上发数据。服务端却傻乎乎地维持着这个连接白白占用资源直到超时。三次握手就避免了这个问题。客户端收到服务端的SYNACK后如果发现这个ACK对应的序列号不是自己期望的因为旧SYN已经被客户端抛弃了客户端可以直接发RST把这个幽灵连接杀掉或者干脆不予理会让服务端超时关闭。三次握手的本质是双方各自确认你能收到我的消息我也能收到你的消息同时交换初始序列号ISN让后续的可靠传输有一个共同的起点。实操中有一个点很多人容易忽略第一次握手时客户端发送的SYN包里ISN是随机生成的。这个随机性不是为了花哨而是为了防止序列号预测攻击——如果有人能猜出你的序列号就可以伪造数据包插入到你的连接里。所以现在的操作系统在生成ISN时都加入了随机偏移别觉得这是多余的设计。2.2 四次挥手与TIME_WAIT断开连接比建立连接更讲究断开连接需要四次挥手这个我建议你结合状态变迁来理解。主动关闭的一方发FIN对方回ACK然后对方再发FIN最后主动方回ACK连接关闭。为什么断开要四次因为TCP允许半关闭状态——一端停止发送数据但仍然可以接收数据所以每一端的关闭都需要独立确认。我工作中实际踩得最多的坑是TIME_WAIT状态。主动关闭连接的一方在发出最后一个ACK之后不会立即释放连接而是要进入TIME_WAIT状态等待2MSLMaximum Segment Lifetime报文最大生存时间通常为60秒到2分钟之后才彻底关闭。很多人不理解这最后一步有什么意义觉得是浪费资源。其实这是TCP最精妙的安全设计之一。TIME_WAIT存在两个目的。第一防止最后一个ACK丢失。如果主动方的最后一个ACK在网络中丢了被动方会因为没有收到ACK而重新发送FIN如果主动方已经释放了连接哪还有进程来回应这个FIN老连接彻底断掉新连接还没建立被动方就会一直纠结在LAST_ACK状态。第二防止旧连接的数据包串到新连接。如果主动方关闭后立刻用同一个四元组建立新连接延迟到旧的FIN或数据包到达时新连接就会被污染。TIME_WAIT就是给网络上残留的旧包一个过期作废的缓冲期。2.3 重传机制丢了就重新发什么时候发才是关键TCP保证可靠传输的基础是确认重传。发送方发一个数据段接收方收到后回ACK确认发送方如果在一定时间内没收到ACK就认为包丢了重新发送。这里的核心问题是等多久才算超时最早TCP用固定的超时时间去判断后来发现这行不通——局域网内1毫秒就能确认的包放到跨洲链路上可能要几百毫秒。所以TCP引入了自适应算法根据每次往返时间RTT动态计算超时时间RTO。实测下来RTO通常等于平滑后的RTT加上4倍的均方差这样在网络抖动时能自动放宽超时阈值网络稳定时又能快速重传。还有个机制叫快速重传。发送方连续收到三个重复的ACK说明对端的接收窗口已经空了中间大概率丢了包这时候不用等超时直接重传。这个机制排障时特别有用——在Wireshark里看到一串Duplicate ACK基本就能断定网络上发生了丢包。2.4 滑动窗口与流量控制别人碗多大你就盛多少饭可靠传输解决了包丢了怎么办但没解决对端处理不过来怎么办。想象一下接收方的应用层程序读数据很慢缓冲区已经塞满了发送方还在拼命发结果就是大量数据被接收方丢弃触发重传风暴越传越乱。流量控制就是来解决这个问题的。滑动窗口的核心是一个承诺机制。接收方在每一个ACK里都会带上自己的接收窗口大小rwnd告诉发送方你最多还能发这么多字节多了我接不住。发送方的发送窗口不能超过这个值这就是流量控制。我调试过一个真实的案例一个文件传输服务在内网传输速度正常跨公网就慢得像蜗牛抓包发现接收方的rwnd被人为配置成了极小值导致发送方每发一个窗口的数据就要停下来等窗口更新。后来查下来是应用程序在套接字层面设置了过小的接收缓冲区把系统默认的几百KB改成了几KB。所以排查传输慢问题时别只盯着带宽先看一眼窗口字段——有时候杯小比路堵更致命。2.5 拥塞控制别让全网陪你一起堵流量控制保护的是单个接收端拥塞控制保护的则是整条链路上的路由器。路由器也有缓冲区一旦瞬间到达的数据量超过路由器处理能力路由器只能丢包。TCP为了不把网络堵死设计了拥塞控制机制核心是让发送方主动控制自己的发送速度。拥塞控制有几个关键阶段慢启动、拥塞避免、快速重传和快速恢复。慢启动是连接刚建立时发送方的拥塞窗口从1个报文段开始每收到一个ACK就翻倍增长呈指数级上升。这个机制看起来慢其实是在小心翼翼地探测网络容量。当拥塞窗口增长到慢启动阈值ssthresh就进入拥塞避免阶段改为线性增长。一旦检测到丢包就把ssthresh减半拥塞窗口直接降到1从头开始。我在实践中学到的教训是慢启动对短连接影响很大。比如一个新的HTTP连接往往还没把拥塞窗口涨到全速请求就已经发完了而长连接比如数据库连接池就能在慢启动之后维持一个较大的窗口传输效率高得多。这也是为什么现在很多服务都强调连接复用不只是省去握手开销拥塞窗口的热启动同样重要。3. TCP和UDP没有优劣之分只有合不合适3.1 一张表看懂核心差异很多新人一上来就问TCP好还是UDP好我一般都会说这两个不是竞争关系是分工关系。UDP和TCP协议的区别本质上就是可靠但重和轻量但糙的区别。对比维度TCPUDP连接状态面向连接需三次握手无连接直接发包可靠性可靠有确认重传不可靠丢了就丢了数据有序性保证字节流顺序不保证顺序传输模式字节流数据报头部开销20字节起步固定8字节流量控制/拥塞控制有没有适用场景HTTP、FTP、SSH、数据库DNS、视频直播、语音通话、游戏从这张表能看出来UDP头部只有8个字节没有序列号、没有确认机制、没有窗口字段它就是把数据包直接扔给IP层能不能到、到了乱不乱序它一概不管。代价是它极轻量延迟可控不会因为重传产生额外抖动。3.2 选型经验三个判断标准实际项目里怎么选我总结了一套简单的判断方法。第一数据丢了能不能忍比如网页、文件传输、数据库事务任何一点数据丢失都是不可接受的直接选TCP。但视频通话和在线游戏偶尔丢一帧画面、掉一个操作包用户是感知不到的这时候TCP的重传反而变成灾难——重传的数据已经过期了只会增加延迟和卡顿UDP更合适。第二对延迟的敏感度有多高TCP的拥塞控制遇上网络抖动会主动降速这在实时音视频场景里非常致命。而UDP没有这些制约应用层可以自己决定丢哪些包、重发哪些包策略灵活得多。现在很多音视频传输都是基于UDP做的。第三有没有TCP的替代方案这几年QUIC协议冒头了它基于UDP实现了TCP的可靠性和安全性但把拥塞控制、重传逻辑搬到了用户态还解决了TCP的队头阻塞问题。HTTP/3跑在QUIC上。如果你维护的是面向弱网场景的应用值得认真研究一下QUIC它算是兼顾了TCP和UDP两者优点的新路线。还有一个容易被忽视的细节DNS查询用的就是UDP。你可能觉得DNS丢了就得重新解析不也是重传吗但操作系统的解析器有自己的超时重发机制而且DNS报文通常很小一个包就能装下整个查询和响应用UDP足够应对还省去了握手的开销。4. TCP协议包从读懂结构到动手修改4.1 TCP头部20字节里的信息量既然要把协议包分析明白先得能把TCP头部读懂。TCP头部最小20字节没有选项字段时刚好就是20字节。我建议你把每个字段的位置和含义记清楚抓包的时候下意识就能扫出来源端口16位和目的端口16位标识连接的两端应用。序列号32位本报文段第一个字节的序号。确认号32位期望对方下一个发送的字节序号也代表之前的数据已全部收到。数据偏移4位表示TCP头部的长度以4字节为单位。头部有选项时这个值会大于5。标志位共8位常用6位URG、ACK、PSH、RST、SYN、FIN。握手看SYN和ACK断开看FIN异常复位看RST。窗口大小16位接收方通告的剩余接收能力。校验和16位对整个TCP报文段做校验。紧急指针16位配合URG标志使用平时用不到。选项字段虽然不算在基础20字节里但实际抓包经常见到最常见的三个是MSS最大报文段长度、SACK选择性确认和时间戳。MSS在握手时协商告诉对方自己愿意接收的最大报文段大小一般取网卡MTU减去IP头和TCP头典型的1500字节MTU对应MSS就是1460。SACK允许接收方告诉发送方我缺的是哪一段而不是只报告最后一个连续收到的字节序号配合快速重传能大幅提升丢包场景下的恢复效率。4.2 抓包入门tcpdump和Wireshark的基本操作分析TCP协议包第一步是把它抓下来。Linux服务器上最常用的是tcpdump命令简单但不提一下容易出错。# 抓取指定端口所有流量不解析域名 tcpdump -i eth0 -nn port 8080 -w /tmp/http.pcap # 只抓SYN包 tcpdump -i eth0 -nn tcp[tcpflags] tcp-syn ! 0 and tcp[tcpflags] tcp-ack 0 # 抓带RST标志的包排查连接被重置的问题 tcpdump -i eth0 -nn tcp[tcpflags] tcp-rst ! 0抓下来的pcap文件用Wireshark打开看最直观。Wireshark里我常用的几个操作先用过滤栏输入tcp.stream eq 0把某个连接的完整对话拎出来然后看Expert Infos窗口里面会直接标注出重传、重复ACK、零窗口等异常事件再看Time列能判断每一跳的延迟波动。Wireshark会把TCP的Seq和ACK换算成相对值看起来清晰但如果你要匹配协议字段的原始值记得关掉Preferences里的Relative sequence numbers选项。4.3 改包到底怎么改三种路径和一堆坑说到TCP协议包如何修改这其实是网络排查和协议开发里很常见的需求。改包不是让你去篡改线上数据而是为了测试、定位问题、验证策略。我实际用过的路径大概有三种。第一种调整系统的TCP行为参数间接改变发出的包内容。这是最安全、最常见的方式。比如通过修改MTU和MSS来调整报文段大小命令是ip link set dev eth0 mtu 1400改完TCP握手时协商的MSS也会跟着变。再比如修改TCP时间戳选项Linux内核参数net.ipv4.tcp_timestamps控制是否在TCP头部加时间戳置0关掉后Debian系统才愿意和某些防火墙兼容。这种改法的特点是作用于整个系统不会动到单个应用的数据。第二种用Scapy这类工具精确构造和发送自定义TCP包。Scapy是Python生态里最常用的报文构造库我曾经用它模拟一个畸形握手包来测试服务器的健壮性from scapy.all import IP, TCP, send # 构造一个SYN包故意设置异常的窗口大小 packet IP(src192.168.1.100, dst192.168.1.1) / TCP( sport12345, dport80, flagsS, seq1000, window0 ) send(packet)注意用Scapy构造原始包时IP层和TCP层的字段都是你自己指定的内核的网络协议栈不会插手。这意味着你发的包可能不符合标准TCP行为接收方可能直接丢弃或者触发安全告警。我建议只在测试环境做生产环境别玩这个容易把自己玩进去。第三种如果只是分析线上某个连接的包内容不需要真的修改谁可以用tc的netem内核模块来模拟丢包和延迟从效果上修改链路的体验# 模拟30%丢包10ms延迟 tc qdisc add dev eth0 root netem loss 30% delay 10ms # 清掉所有netem规则 tc qdisc del dev eth0 root netem这种做法在验证TCP拥塞控制、重传行为时非常好用比改包更贴近真实故障。我在测试环境模拟弱网时几乎每天都和netem打交道。4.4 实战复盘一个靠抓包定位的应用层大坑分享一个真实案例。前两年有个同事反馈某内部系统调用外部门户的OpenAPI偶尔出现读超时大概每10次请求有1次必挂。业务日志里没有任何异常应用层代码看了好几遍也没发现问题。我用tcpdump抓了20分钟包发现规律出问题的那次请求客户端发出SYN后服务端立刻回了SYNACK但客户端回应ACK之后服务端没有再往这个连接上发任何HTTP应答数据连接就这么晾着直到客户端超时触发RST。进一步看出错的连接上服务端发过来的SYNACK里MSS协商出来只有1360字节比正常值1460小一点。我当时怀疑是MTU发生了什么一查服务端那条链路确实配置了较小的MTU。问题不在TCP本身而是服务端应用的HTTP框架没有正确处理TCP半连接或代理链路重组。后来联系对方运维调整了中间防火墙的MTU设置把MSS协商恢复了正常值问题就消失了。这个案例给我最大的启发是TCP报文里每一个字段都是线索不要只看协议状态还要看协商出来的参数是否合理。MSS、窗口大小、时间戳任何一个异常都值得深挖。5. 常见问题排查与内核调优实录5.1 连接建立失败SYN风暴和半连接队列线上最常见的问题是连不上。如果客户端发SYN后一直收不到SYNACK或者收到RST基本可以锁定在握手环节。排查思路我一般这么走先在客户端抓包确认SYN确实发出去了再到服务端抓包确认SYN有没有到达两侧一对故障区段就出来了。如果你发现SYN到了服务端但没有响应优先查半连接队列是否溢出。Linux内核接受一个TCP连接前先把连接放到半连接队列syn queue完成握手后再移到全连接队列accept queue给应用accept。如果队列满了内核就直接丢弃新到的SYN包。查看方式很直接netstat -s | grep -i listen输出里如果看到SYNs to LISTEN sockets dropped说明半连接队列丢包了这时候需要调大net.ipv4.tcp_max_syn_backlog同时检查应用是否及时accept连接。有一次我排查一个Tomcat实例连不上就是全连接队列满了Tomcat的accept线程卡死在慢SQL上新连接全部排队等死队列一满内核直接丢包。5.2 传输速度上不去Nagle算法和延迟确认的相爱相杀传输慢的原因千奇百怪但有两个算法导致的经典场景非常值得单独说——Nagle算法和延迟确认。Nagle算法的逻辑是发送方发送一个小包后必须在收到该包的ACK后才能继续发送下一个包本质是把多个小包合并成大包减少小报文数量。延迟确认则是接收方收到数据后不立即回ACK而是等一小段时间希望把多个ACK合并成一个或者捎带上应用层的响应数据。这两者单独工作都合理但如果一边开Nagle一边没关延迟确认就会出现经典的粘包死锁发送方因为Nagle捏着一个未确认的小包不肯发后面的数据接收方因为延迟确认迟迟不回ACK。两边互相等传输延迟瞬间飙高。最典型的就是某些老式Telnet和远程终端场景。解决办法如果应用传输的是交互式小包数据可以在套接字层面关闭Nagle算法int flag 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, flag, sizeof(flag));抓包确认是否受Nagle影响有个简单方法看Wireshark里是不是大量出现发送一个小包等待ACK再发下一个小包的锯齿状时序。如果是关掉Nagle立刻见效。不过话说回来Nagle算法对Bulk传输大块数据是友好的别一上来就盲目关闭得先判断你的业务包大小特征。5.3 TIME_WAIT堆积怎么判断真的有问题短连接高并发的服务TIME_WAIT堆积到几万个是常事。很多人一看ss -s输出里TIME_WAIT很多就慌其实要分情况。TIME_WAIT本身不占用文件描述符也不占用应用内存它只是内核里一个残留的连接记录。真正的问题是TIME_WAIT过多时四元组源IP、源端口、目的IP、目的端口可能短期无法复用导致新连接无法建立。我的处理优先级是这样的先看服务端还是客户端堆积再看应用能不能支持连接复用。HTTP Keep-Alive能极大降低TIME_WAIT数量因为连接可以反复使用。如果业务形态实在无法避免大量短连接再考虑内核参数调整。Linux提供了两个常见参数sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.tcp_fin_timeout10tcp_tw_reuse只对客户端生效允许内核安全地复用处于TIME_WAIT的连接tcp_fin_timeout缩短主动关闭方的等待时间。注意tcp_tw_recycle这个参数我强烈建议不要碰它在NAT环境下会引发严重的连接问题旧版本内核里开启后可能导致部分NAT用户完全无法访问很多运维事故都是因为它。5.4 内核调优速查表记下这几个就够用了Linux网络栈可调的参数非常多但我实际运维中真正用得频繁的就那么几个整理成一张表方便你直接查参数默认值作用建议场景net.core.somaxconn4096全连接队列上限高并发Web服务调到1024以上net.ipv4.tcp_max_syn_backlog128或更高半连接队列上限遭遇SYN丢弃时调大net.ipv4.tcp_slow_start_after_idle1空闲后是否重置拥塞窗口低延迟场景可置0保持热窗口net.ipv4.tcp_fin_timeout60FIN等ACK的超时时间高短期连接场景可设为10net.ipv4.tcp_keepalive_time7200空闲多久开始探测长连接保活可调到300net.ipv4.tcp_tw_reuse0TIME_WAIT快速复用客户端高并发短连接场景我个人的习惯是调参之前一定先抓包看数据用数据说话。很多工程师一上来就照着网上的性能优化十招把参数全改一遍改完发现有些场景反而变慢了——比如tcp_slow_start_after_idle0虽然在空闲重连时能保持拥塞窗口但如果是大量短周期小流量这个改动几乎无感还可能让空闲连接瞬间冲击网络。最后分享一个排查时特别实用的技巧把ss -tinp的输出结合抓包一起看。它能直接显示每个连接当前的cwnd拥塞窗口、ssthresh、RTT等实时值配合Wireshark的IO Graph画出吞吐曲线定位为什么慢的效率会高得多。TCP虽然是个几十年前的老协议但它每一个字段、每一个状态都是一线排障的线索耐心把底层的为什么搞明白比背多少条调优命令都管用。