这段时间后台收到不少朋友私信说面试的时候被TCP三次握手和四次挥手问得手心冒汗还有人在公司排查线上连接问题的时候对着状态码一头雾水。TCP这个协议确实是网络基础里的硬骨头光背“三次握手、四次挥手”八个字没用你得真正搞懂它在什么场景下产生、每个报文段承载了什么、状态机是怎么流转的才能看透各种连接异常的本质。这篇文章我打算把三次握手和四次挥手从原理到底层报文再到实际排障完整掰开揉碎讲一遍。不管是准备面试的后端开发还是天天跟连接状态打交道的运维或者正在学网络协议的学生都能在这里找到能直接上手用的东西。我会把Wireshark筛选、状态转换、异常排查这些实操细节全部铺开争取让你看完之后不只是记住四次挥手里有TIME_WAIT而是真正理解为什么要有它、没了它会怎样。1. 三次握手建立连接背后的状态机与报文逻辑1.1 三次握手到底“握”的是什么TCP是面向连接的可靠传输协议这个“连接”不是物理上拉了一根线而是通信双方在内存里要同步维护一套连接状态而且要确认对方的收发能力都正常。三次握手就是双方交换初始序列号、协商窗口大小、确认彼此就绪的过程。先看一次标准握手过程Client Server |------- SYN, seqx ----------| |------ SYNACK, seqy, ackx1 -----| |------- ACK, seqx1, acky1 -----|三个报文段各干一件事客户端发送SYN报文携带一个随机初始序列号x并进入SYN_SENT状态。这一步是告诉服务端我要建立连接我的起始序号是x你能听到吗服务端收到后如果愿意建立连接就回复SYNACK报文携带自己的初始序列号y并把确认号ack设为x1服务端进入SYN_RCVD状态。这一步同时做了两件事确认了客户端的SYN并请客户端确认自己的SYN。客户端收到SYNACK后再发一个ACK报文确认号设为y1双方进入ESTABLISHED状态。有人会问为什么客户端最后一个ACK空荡荡的只带一个ack号因为TCP头部里的ACK标志位一旦置1确认号就有意义。这个ACK报文本身不携带业务数据纯粹是为了让服务端确认“客户端已经收到了我的SYNACK”。如果去掉这一步服务端无法确认客户端是否拿到了自己的初始序列号后续数据传输就会失序。还有一个很容易被忽略的细节序列号x和y是随机生成的不是从0开始。这是为了防止TCP连接欺骗和序列号预测攻击。如果序列号固定攻击者很容易伪造一个RST报文把连接打断。1.2 为什么必须是三次两次和四次差在哪这个话题面试必问核心答案要落在“双方都要确认自己的收发能力”上。如果用两次握手假设客户端发的SYN因为网络延迟卡了很久客户端超时重传了一个SYN服务端回SYNACK后连接建立。但此时第一个迟到的SYN又到达服务端服务端不知道这是旧报文又回了一个SYNACK并认为新连接建立。客户端收到这个迟到的SYNACK后发现ack号对不上直接丢弃但服务端这边已经为这个“幽灵连接”分配了资源连接就一直挂着浪费内存和端口。三次握手能解决这个问题因为客户端第三次ACK会带上确认号服务端发现ack号不匹配就能把这条畸形连接关掉。两次握手还有一个更大的缺陷无法确认服务端的发送能力和客户端的接收能力。第一次握手只能证明客户端能发、服务端能收第二次握手能证明服务端能发、客户端能收。但服务端不知道自己的报文客户端能否成功收到只有等到第三次ACK到来服务端才能确认“我发的包你也收到了”。不确认这一点服务端就开始发数据如果客户端压根收不到连接就名存实亡了。那四次为什么没必要因为SYN和ACK完全可以合并在一个报文里。三次握手已经是“信息交换完备且效率最高”的方案多一次只是冗余。这也是为什么TCP设计者最终选了三次而不是更稳妥但浪费的四次。值得一提的还有半连接队列和SYN Flood防护。服务端在SYN_RCVD状态时连接信息会放进半连接队列也叫SYN队列所以恶意攻击可以伪造海量SYN报文塞满这个队列让正常请求无法建立连接。现代系统里常见的缓解手段就是SYN cookies当半连接队列满的时候服务端不再为SYN分配资源而是把连接信息加密编码进SYNACK的序列号返回等收到客户端ACK后再还原连接。这部分内容排查连接异常时经常遇到后面第三节再展开。1.3 Wireshark 里如何快速筛选三次握手报文既然原理都懂了动手验证是必须的。Wireshark里抓包虽然简单但流量一多想快速定位握手报文就得靠过滤语法。抓本机回环流量最简单的方式:# 抓取本机回环接口端口以5200为例 sudo tcpdump -i lo -nn port 5200 -w handshake.pcap也可以用Wireshark直接抓Loopback: lo接口然后输入显示过滤器。一次性过滤出三次握手的核心报文tcp.flags.syn 1 tcp.flags.ack 0这是第一次握手的SYN报文。这里有个细节SYN置1但ACK置0说明是纯粹握手发起方不带确认性质。tcp.flags.syn 1 tcp.flags.ack 1这是第二次握手的SYNACK报文。确认号ack的值应该等于第一次握手的seq值加1。tcp.flags.ack 1 tcp.flags.syn 0 tcp.len 0这是第三次握手的纯ACK报文不带任何载荷。之所以加一个tcp.len 0是为了排除那些同样只有ACK标志位但是携带数据的数据包。如果你想一次性把三次握手都挑出来可以直接用tcp.stream eq N。右键点击任何一个握手报文选择“Follow - TCP Stream”Wireshark会自动给这条连接分配一个stream编号。比如这里看到TCP Stream index是5过滤器直接输入tcp.stream eq 5所有这条连接的报文都会展示出来从三次握手到中间的传输数据再到最后的挥手一目了然。抓包时要注意一个细节如果Wireshark里看到第一次握手重传TCP Retransmission而你的网络环境是在本机测试那多半不是网络丢包而是对端半连接队列满了或者服务端单线程accept处理不过来。别把抓包结果直接当成链路质量问题要先排除本机服务处理能力。2. 四次挥手断开连接的完整状态流转与TIME_WAIT的执念2.1 挥手的四个报文段分别是谁发的、为什么是四次三次握手是建立连接四次挥手是关闭连接同样的对称逻辑但报文段数量却差了一次。原因在于TCP连接是全双工的两个方向的数据通道需要独立关闭。发出FIN报文只代表“我这边没有数据要发了”但如果我还想收对端的数据仍可以继续接收。所以主动关闭方和被动关闭方各自要发一次FIN、各自要确认一次加在一起就是四次。标准挥手过程Client (主动关闭) Server (被动关闭) |------- FIN, seqm ----------| Client - FIN_WAIT_1 |------ ACK, ackm1 ---------| Server - CLOSE_WAIT, Client - FIN_WAIT_2 |------ FIN, seqn -----------| Server - LAST_ACK |------- ACK, ackn1 --------| Client - TIME_WAIT, Server - CLOSED这里最关键的一步在第二个和第三个报文之间。服务端收到FIN后先回一个ACK表示“我知道你要关了”但这并不意味着服务端立刻就能关闭连接因为服务端可能还有数据没发完。等服务端把剩下的数据传完才会发出自己的FIN报文。数据没发完的这段时间服务端一直处于CLOSE_WAIT状态。在实际开发中CLOSE_WAIT堆积是非常常见的线上故障。如果服务端代码写得不够健壮没有正确关闭socket或者业务线程阻塞客户端已经发FIN走了服务端却一直停留在CLOSE_WAIT大量连接把文件描述符耗尽新连接就进不来了。排查这类问题用ss命令看状态分布一目了然后面第四节会带一个实际案例。2.2 TIME_WAIT 为什么非要等 2MSL一秒钟行不行第四次挥手后主动关闭方不会立刻进入CLOSED而是停在TIME_WAIT状态等待2MSLMaximum Segment Lifetime报文最大生存时间之后才彻底关闭。这个设计看起来有点“拖泥带水”但作用非常关键。一是要确保最后一个ACK能到达对端。如果这个ACK在网络中丢失被动关闭方会因为没收到确认而重发FIN。主动关闭方若已经关闭就收不到这个重发的FIN更没法再次回复ACK被动关闭方就只能无限重传直到超时关闭状态资源被白白占用。TIME_WAIT等待2MSL恰好是“一个报文在网络里存活的最长时间 对端处理并重发的最坏情况”足以覆盖一次丢失重传的完整周期。二是要让旧连接的报文在网络中完全消散。如果没有TIME_WAIT连接关闭后立刻用相同的四元组源IP、源端口、目标IP、目标端口建立新连接前一个连接在网络中残留的迟到数据包就可能被新连接误认为有效载荷造成数据污染。2MSL时间过去之后旧报文已经全部消亡新连接拿到的一定是干净的历史。那2MSL具体是多久Linux下可以查看cat /proc/sys/net/ipv4/tcp_fin_timeout默认值通常是60秒也就是TIME_WAIT在Linux上实际等待时间并不是传统的2分钟或4分钟而是可以通过内核参数调整的。需要明确这个参数含义在不同内核版本里稍有差异但基本可以把它理解成TIME_WAIT的实际等待时长。高并发短连接场景下TIME_WAIT连接过多是一个经典困境。每次短连接关闭都会让主动关闭方留下一个TIME_WAIT如果主动关闭方是需要大量发起连接的客户端短时间内的端口可能被TIME_WAIT占满导致无法建立新连接。那篇文章里提到的bind报错error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address虽然这个报错本身是端口被占用或服务重复启动导致的但在TIME_WAIT堆积的场景下同样会遇到类似的socket资源受限问题。对服务端来说TIME_WAIT大多出现在主动关闭连接的一方。短连接服务如果主动关连接就会积累大量TIME_WAIT虽然不会立刻导致端口不可用服务端监听同一个固定的端口可以继续accept新连接但每个TIME_WAIT都占用内存描述符量大了还是会影响性能。解决办法后面第四节单独讲。2.3 长连接与短连接挥手次数如何反向影响业务设计四次挥手不是白白浪费的它直接影响业务架构的连接策略。理解TCP挥手后再看长连接与短连接的选型就会清晰很多。短连接的特点就是“用完即关”典型场景是HTTP/1.0。每次请求都经历三次握手、数据传输、四次挥手。这种模式实现简单服务端不需要维护大量并发连接状态但握手和挥手的开销占比很高尤其当单个请求数据量很小时光建立和释放连接的时间就超过了数据传输本身。所以短连接适合低频、小数据量的场景比如简单的API调用。长连接则是在一次握手后保持连接持续复用典型场景是数据库连接池、消息推送、即时通讯。长连接省去了反复握手的开销适合高频交互或需要服务端主动推送的场景。但长连接也带来一个麻烦连接长时间空闲中间的网络设备可能静默回收这条连接导致连接虽然建立着但实际上已经无法收发数据。这时候就需要心跳包。心跳包的本质就是在应用层定时发送小数据包维持连接活性同时探测对端是否还活着。从挥手角度再看一层短连接造成TIME_WAIT集中在主动关闭方长连接造成CLOSE_WAIT堆积则多半在服务端代码没优雅关闭的场景。所以当你看到TIME_WAIT很多先判断谁是主动关闭方、为什么主动关闭当你看到CLOSE_WAIT很多先检查服务端有没有正确关闭socket。这种判别思路比死记状态转换图有用得多。3. 常见报错与异常排查从握手到挥手路上的坑3.1 端口被占用与bind错误文章开头提到的bind报错error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address这行报错最常见的原因是同一个服务重复启动了多个进程或者端口被其他进程占用。排查方法非常简单# 查看哪个进程占用了11434端口 sudo lsof -i :11434 # 或者使用ss ss -tlnp | grep 11434 # 找到PID后确认进程信息 ps -fp PID还有一种可能性是前一个进程退出后没有释放端口进入了TIME_WAIT状态。TCP协议里主动关闭方会进入TIME_WAIT如果这个时候服务端马上重启监听同一个端口可能会失败。解决思路是设置SO_REUSEADDR。在Linux下这个选项允许新监听的socket绑定到TIME_WAIT状态的端口这是非常实用的经验。服务端代码里加上这一句能避免很多重启时的端口占用幽灵问题。对Go语言来说常见写法ln, err : net.Listen(tcp, 127.0.0.1:11434) if err ! nil { log.Fatal(err) }Go在底层默认已经设置了SO_REUSEADDR所以上面的报错更多还是进程未退出或端口真被占用优先用lsof排查。3.2 TCP Connection Reset by Peercurl报错curl: (35) TCP connection reset by peer这个报错翻译过来就是“TCP连接被对端重置了”。连接重置RST通常发生在以下几种场景场景一服务端根本没有进程在监听这个端口客户端发SYN过去内核直接回RST。这属于“端口敲门失败”排查思路跟上面的端口检查一样。场景二连接已经建立了但服务端进程崩溃内核在进程退出时发送RST客户端再往这个连接上写数据就收到Connection reset。场景三服务端主动关掉了连接但客户端还在发数据或者客户端收到数据后才发现连接已经关闭这时也会触发RST。场景四TCP的keepalive超时或者中间设备比如Nginx、防火墙清掉了空闲连接对端再发数据就会收到RST。这属于“半开连接”问题根本解决方案是应用层心跳。遇到Connection reset优先打开抓包sudo tcpdump -i eth0 -nn port 8080 -w reset.pcap然后在Wireshark里过滤RST报文tcp.flags.reset 1同时要结合时序判断RST出现在三次握手阶段?还是传输阶段?还是挥手阶段?不同的出现位置排查方向完全不一样。这里还要补充一个和TCP有强关联但方向上不同的词Modbus TCP。很多工控场景里PLC和上位机通过Modbus TCP通信Modbus报文承载在TCP之上如果出现Connection reset多半也是上面的几种原因。在S7-1200与多个Modbus TCP从站轮询的场景里经常遇到的问题是轮询周期太短上一个请求还没处理完下一个请求就来了导致从站主动RST。解决思路是适当拉长轮询间隔或者对单个从站的连接做超时重连机制。STM32这类嵌入式设备跑FreeModbus TCP时因为资源有限尤其要注意服务端主动关闭连接时的TIME_WAIT管理不然设备长时间运行后端口资源会耗尽。3.3 SYN重传与半连接队列溢出如果客户端发出SYN后一直收不到SYNACK就会反复重传SYN。抓包里看到大量的TCP Retransmission且重传的都是SYN报文说明SYN报文根本没到达服务端或者服务端压根没回应。客户端视角的可能原因服务端IP或端口错误网络不可达被防火墙或安全组规则拦截服务端的半连接队列已经满了新的SYN被内核丢弃服务端视角的排查方法# 查看SYN重传次数 sysctl net.ipv4.tcp_syn_retries # 查看半连接队列溢出统计 netstat -s | grep -i SYNs to LISTEN内核参数tcp_max_syn_backlog和somaxconn共同决定半连接队列大小。如果发现SYN包丢包严重且服务端负载不高可以考虑调大这两个参数。但如果是被SYN Flood攻击盲目调大参数反而会加剧资源消耗这时候应该启用SYN cookiestcp_syncookies 1。对应用层开发来说还有一层容易踩坑服务端listen的backlog参数设置得过小即使内核半连接队列和全连接队列都正常应用层来不及accept连接也会堆积。很多语言里listen的第二个参数就是backlog如果写得太小压测时就会看到一部分连接建立失败但抓包看三次握手是正常的问题出在全连接队列溢出。用ss -lnt可以看到当前socket的Send-Q和Recv-QRecv-Q表示等待accept的连接数如果这个值长期接近backlog上限就要调大应用层的backlog或者增加accept线程。4. 用状态机看待一条连接的一生从请求到关闭的完整实操4.1 用ss和netstat查看连接状态纸上谈兵没用连接状态一定要上机器看。# 查看所有TCP连接及状态 ss -tan # 只看监听状态的端口 ss -tln # 查看连接状态分布统计 ss -tan | awk {print $1} | sort | uniq -c # 查看指定端口的连接 ss -tan | grep 8080netstat命令用法类似但ss的效率更高尤其在连接数上万的机器上netstat会明显卡顿。日常排查建议习惯用ss。一条完整的TCP连接从建立到关闭会经历这些状态状态含义常见出现位置LISTEN服务端监听端口等待连接服务端SYN_SENT客户端已发出SYN等待SYNACK客户端SYN_RCVD服务端已收到SYN回复SYNACK服务端ESTABLISHED连接建立成功正常传输数据双方FIN_WAIT_1主动关闭方已发FIN等待ACK主动关闭方FIN_WAIT_2主动关闭方已收到ACK等待对端FIN主动关闭方CLOSE_WAIT被动关闭方已收到FIN等待应用层关闭socket被动关闭方LAST_ACK被动关闭方已发FIN等待最终ACK被动关闭方TIME_WAIT主动关闭方等待2MSL主动关闭方CLOSED连接完全关闭双方如果ss的输出里某一种状态异常多基本就有了排查方向。比如CLOSE_WAIT几百个说明服务端代码里socket没关干净TIME_WAIT几千个说明主动关闭连接太频繁考虑连接复用或调优参数。4.2 从客户端和服务端视角分别观察三次握手我们用一个真实的连接受命过程来演示。假设服务端监听在127.0.0.1:8080客户端发起一个HTTP请求。第一步服务端启动后执行ss -tln | grep 8080输出里可以看到LISTEN 0 128 127.0.0.1:8080 0.0.0.0:*第二列是当前等待accept的连接数第三列是backlog上限。如果第二列长期等于第三列说明accept速度跟不上请求速度。第二步客户端发起请求后在服务端和客户端同时用ss看状态。一瞬之间你可能会看到SYN_RCVD一闪而过然后立刻变成ESTABLISHED。如果SYN_RCVD持续存在很久说明服务端收到了SYN但应用层没有及时accept或者半连接队列处理存在问题。第三步抓包看完整流程。用tcpdump抓完整过程sudo tcpdump -i lo -nn port 8080 -w curl_test.pcap再用curl发起请求curl http://127.0.0.1:8080/抓包文件里应该依次出现三次握手、HTTP请求报文、HTTP响应报文、四次挥手记录。在Wireshark里选中第一个SYN报文看它的TCP头部Sequence Number是随机值Flags标记里SYN置位。再选中SYNACK报文可以看到它的Sequence Number是另一个随机值Acknowledgment Number正好是前一个SYN的seq加1。选中第三个ACK报文确认号又是SYNACK的seq加1。这就是握手全过程最直观的体现。实际操作中如果你抓本机回环流量tcpdump的过滤器可以这样写sudo tcpdump -i lo -nn tcp port 8080 and (tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0)这个过滤器可以抓出SYN、FIN、RST三类关键控制报文直接看清连接建立和关闭的全过程数据报文被过滤掉了看状态流转更清爽。4.3 程序里如何优雅处理断开与重连很多网络故障的根源不在协议栈而在应用层没有处理好连接生命周期。我总结了几条实际开发里比较重要的经验。一是要设置合理的读写超时。如果对端一直不返回数据socket读操作会一直阻塞。设置超时后超时异常可以用来触发重连逻辑。Go语言里conn.SetReadDeadline(time.Now().Add(10 * time.Second)) conn.SetWriteDeadline(time.Now().Add(10 * time.Second))二是要处理对端异常关闭的情况。对端崩溃后本端可能不会立刻感知。只有往一个已经关闭的连接上写数据时才会触发EPIPE或者ECONNRESET错误。所以除了心跳还要养成“每次读写都检查错误”的习惯读到EOF对端正常关闭和读到RST对端异常关闭要区别对待。三是重连要加退避。如果服务端短暂不可用客户端不要疯狂重连。用指数退避策略第一次等1秒第二次2秒第三次4秒最多等到30秒或60秒封顶既能快速恢复又不会把服务端打爆。四是客户端主动关闭连接时尽量不要复用处于TIME_WAIT状态的端口去立即发起新连接。这在连接池场景里比较常见。比较好的做法是复用长连接减少主动关闭的次数。如果必须大量短连接客户端侧也可以调节tcp_max_tw_buckets等参数但修改内核参数要谨慎分清系统调优和应用调优的边界。写一个最简单的TCP服务端示例演示优雅关闭import socket import signal import sys server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((127.0.0.1, 8080)) server.listen(128) server.settimeout(1) running True def handler(signum, frame): global running running False signal.signal(signal.SIGINT, handler) signal.signal(signal.SIGTERM, handler) while running: try: conn, addr server.accept() except socket.timeout: continue except OSError: break with conn: data conn.recv(1024) if data: conn.sendall(bhello from tcp server) conn.close() server.close() print(server closed gracefully)这段代码的关键在于SO_REUSEADDR设置和信号处理。收到SIGTERM时先停止accept新连接处理完当前连接后释放socket避免进程退出后端口还被占用。很多线上端口冲突问题就是没有做这种优雅退出导致的。4.4 挥手过程抓包实操亲眼验证TIME_WAIT平时在机器上很难肉眼看到TIME_WAIT因为2MSL的时间窗口短暂且连接很快就关闭了。但我们可以通过抓包方式验证完整的挥手流程。准备一个小工具主动关闭方发起连接后立即断开。在服务端和客户端同时抓包可以看到时间点1 客户端 - 服务端 FIN, seqxxx 时间点2 服务端 - 客户端 ACK, ackxxx1 时间点3 服务端 - 客户端 FIN, seqyyy 时间点4 客户端 - 服务端 ACK, ackyyy1第四个ACK发出后用ss查看客户端连接状态ss -tan | grep 8080输出里会有TIME-WAIT 0 0 127.0.0.1:54321 127.0.0.1:8080这条连接并不会立刻消失而是要等tcp_fin_timeout秒之后才被系统清理。如果在TIME_WAIT期间用相同端口重新发起连接会发现无法复用这个端口。这就是TIME_WAIT的直观体现。如果你的服务是主动关闭方大量的TIME_WAIT可能导致新连接建立变慢。有些团队会用tcp_tw_reuse来缓解sysctl net.ipv4.tcp_tw_reuse1这里必须说明tcp_tw_reuse只对客户端出站连接有效它允许内核在新建连接时复用TIME_WAIT状态的端口前提是新的连接序号大于旧连接的最后序号。它并不能减少服务端这边的TIME_WAIT。至于tcp_tw_recycle参数由于它的实现存在较多兼容性问题NAT环境下容易导致连接异常实际生产中并不推荐开启。对大多数场景来说更稳妥的方案是调整连接池、复用长连接从应用层面减少TIME_WAIT的产生。5. 握手挥手之外的TCP实用边界和UDP怎么选、状态检查如何辅助排障5.1 TCP和UDP的区别聊到哪个粒度就够了每次聊TCP就一定绕不开UDP。我的看法是梳理一遍底层的区别再带到应用选型里去比单纯背对比列表靠谱得多。TCP面向连接、可靠、有序、有流量控制和拥塞控制。它把所有可靠性问题都扛在了协议栈里应用层只需要读写数据流即可。代价是头部开销大、连接管理复杂、存在队头阻塞。UDP无连接发送方只管把数据报扔出去能不能到、什么时候到、顺序对不对都不保证。代价少了一大堆换来的是低延迟、低开销、实现简单。哪些场景更适合UDP实时音视频、游戏同步、DNS查询都算。这些场景丢一个包可以接受但延迟高不可接受TCP的重传机制反而成了累赘。哪些场景必须用TCP文件传输、数据库事务、消息队列、Web API等任何要求数据完整到达的场景都是TCP的天下。还有一个容易被忽略的点很多应用层协议比如HTTP/3和QUIC实际上基于UDP实现了自己的可靠传输。这说明TCP和UDP之间并不是“谁替代谁”的关系而是不同可靠性机制在不同场景下的取舍。面试时如果能从这个角度回答说明你是真的理解了传输层的设计逻辑。5.2 用三次握手和四次挥手的底层知识反推线上问题TCP的原理记熟了真正大的价值在于遇到线上问题能快速定位。我举一个真实的工作场景。某天同事反馈服务A到服务B的接口偶发超时看了监控连接建立成功率正常但有少量请求耗时超过5秒。抓包后发现部分请求的三次握手中出现了SYN重传确认是网络层丢包。但奇怪的是丢包只发生在特定时间段。后来检查发现服务B所在的机器在同一时间段有大量日志写入磁盘IO打满导致内核网络栈处理延迟SYN包排队处理客户端等不及就重传了。这个问题的定位完全依赖对握手超时和重传机制的理解。又比如线上服务大量CLOSE_WAIT打开ss一看几百个连接停在CLOSE_WAIT。查应用日志发现服务端代码里有一段网络请求忘记加超时保护对端不返回时线程一直阻塞socket得不到关闭即使收到FIN也无法进入后续的LAST_ACK和CLOSED状态。这个问题对应的核心知识点就是前面讲过的被动关闭方状态转换。所以说TCP三次握手和四次挥手不是一个八股问题它是排查一切连接异常的地基。地基不牢看到CLOSE_WAIT不知从何下手看到TIME_WAIT也只能瞎改内核参数。6. 一些值得记住的实测参数与后续扩展方向6.1 快速参考常用TCP排障命令与参数以下是我日常排查TCP问题时比较常用的命令集合做成速查表方便收藏需求命令查看整体连接状态分布ss -tan | awk {print $1} | sort | uniq -c查看监听端口和队列ss -tln查看某个端口的established连接数ss -tan state established | grep :8080抓包指定端口sudo tcpdump -i any -nn port 8080 -w file.pcap过滤RST包tcpdump tcp[tcpflags] tcp-rst ! 0TCP连接跟踪ss -tan | grep ESTAB查看TCP重传统计netstat -s | grep -i retrans查看半连接溢出netstat -s | grep -i SYNs to LISTEN内核参数方面最有实践意义的几个net.ipv4.tcp_syn_retries # SYN重传次数默认6 net.ipv4.tcp_synack_retries # SYNACK重传次数默认5 net.ipv4.tcp_fin_timeout # TIME_WAIT实际等待时间默认60秒 net.ipv4.tcp_tw_reuse # 客户端复用TIME_WAIT端口默认0 net.ipv4.tcp_max_syn_backlog # 半连接队列上限 net.core.somaxconn # 全连接队列上限 net.ipv4.tcp_syncookies # 是否启用SYN Cookies默认1强调一下修改内核参数要看场景。比如tcp_syn_retries调小了服务端不可达时客户端能更快失败这是好事但如果是弱网环境调小了反而容易把原本能成功的连接搞失败。参数没有绝对的好坏只有适不适合运行环境和业务模型。6.2 嵌入式与工业场景里的TCP细节热词列表里有不少工业自动化和嵌入式相关的内容比如Modbus TCP、S7-1200轮询、STM32F407移植FreeModbus TCP。这些场景里TCP协议本身的机制不变但资源约束和网络环境完全不同。嵌入式设备内存小、CPU弱跑TCP协议栈时要特别注意内存池和收发缓冲区配置。lwIP里经常要调整TCP_MSS、TCP_WND、PBUF_POOL_SIZE这些参数。如果配置太小大报文会被分片传输效率明显下降。如果配置太大内存又可能不够用。这是典型的“根据环境调协议参数”的实践。PLC轮询场景里S7-1200作为Modbus TCP主站轮询多个从站时连接管理和超时设置是关键。每个从站的连接如果在轮询间隙长期保持会占用大量资源如果频繁关闭重建又会受TIME_WAIT影响。实际项目中比较稳妥的方案是保活少量长连接但应用层实现看门狗发现连接异常就主动断开重建。Modbus TCP的报文结构本身不复杂复杂的是在工业现场的不稳定网络里维持连接可靠性。ESP01S这类WiFi模块发送TCP消息也属于嵌入式范畴。模块固件通常已经封装好了AT指令开发者要注意的是TCP客户端模式下的连接保活机制。如果模块和服务端之间长时间没有数据交互路由器可能会回收这条连接。定期发送心跳或者依赖模块自带的TCP keepalive配置可以缓解这个问题。这些场景有一个共同的启示TCP协议栈是操作系统和硬件提供的底座但要不要用长连接、怎么处理重连、怎么检测对端存活永远是应用层的设计责任。这也是为什么我前几节花了大量篇幅讲状态和参数而不是只看报文格式。报文格式只是表状态管理和异常处理才是里子。我个人在实际排查中最大的一个体会是遇到TCP相关的问题一定不要只看应用层日志先把状态机和抓包结合起来看。很多看起来莫名其妙的超时和重置抓一次包就原形毕露了。再分享一个小技巧排查的时候尽量抓两端的数据包只抓一端很容易被误导比如客户端看到SYN没回应可能是服务端收到了但回包丢了也可能是服务端根本没收到两个方向的数据一对比问题出在哪一层立即清楚。这个做法在实践中帮我省了非常多的时间。 TCP三次握手与四次挥手：从原理到排障的完整指南
这段时间后台收到不少朋友私信说面试的时候被TCP三次握手和四次挥手问得手心冒汗还有人在公司排查线上连接问题的时候对着状态码一头雾水。TCP这个协议确实是网络基础里的硬骨头光背“三次握手、四次挥手”八个字没用你得真正搞懂它在什么场景下产生、每个报文段承载了什么、状态机是怎么流转的才能看透各种连接异常的本质。这篇文章我打算把三次握手和四次挥手从原理到底层报文再到实际排障完整掰开揉碎讲一遍。不管是准备面试的后端开发还是天天跟连接状态打交道的运维或者正在学网络协议的学生都能在这里找到能直接上手用的东西。我会把Wireshark筛选、状态转换、异常排查这些实操细节全部铺开争取让你看完之后不只是记住四次挥手里有TIME_WAIT而是真正理解为什么要有它、没了它会怎样。1. 三次握手建立连接背后的状态机与报文逻辑1.1 三次握手到底“握”的是什么TCP是面向连接的可靠传输协议这个“连接”不是物理上拉了一根线而是通信双方在内存里要同步维护一套连接状态而且要确认对方的收发能力都正常。三次握手就是双方交换初始序列号、协商窗口大小、确认彼此就绪的过程。先看一次标准握手过程Client Server |------- SYN, seqx ----------| |------ SYNACK, seqy, ackx1 -----| |------- ACK, seqx1, acky1 -----|三个报文段各干一件事客户端发送SYN报文携带一个随机初始序列号x并进入SYN_SENT状态。这一步是告诉服务端我要建立连接我的起始序号是x你能听到吗服务端收到后如果愿意建立连接就回复SYNACK报文携带自己的初始序列号y并把确认号ack设为x1服务端进入SYN_RCVD状态。这一步同时做了两件事确认了客户端的SYN并请客户端确认自己的SYN。客户端收到SYNACK后再发一个ACK报文确认号设为y1双方进入ESTABLISHED状态。有人会问为什么客户端最后一个ACK空荡荡的只带一个ack号因为TCP头部里的ACK标志位一旦置1确认号就有意义。这个ACK报文本身不携带业务数据纯粹是为了让服务端确认“客户端已经收到了我的SYNACK”。如果去掉这一步服务端无法确认客户端是否拿到了自己的初始序列号后续数据传输就会失序。还有一个很容易被忽略的细节序列号x和y是随机生成的不是从0开始。这是为了防止TCP连接欺骗和序列号预测攻击。如果序列号固定攻击者很容易伪造一个RST报文把连接打断。1.2 为什么必须是三次两次和四次差在哪这个话题面试必问核心答案要落在“双方都要确认自己的收发能力”上。如果用两次握手假设客户端发的SYN因为网络延迟卡了很久客户端超时重传了一个SYN服务端回SYNACK后连接建立。但此时第一个迟到的SYN又到达服务端服务端不知道这是旧报文又回了一个SYNACK并认为新连接建立。客户端收到这个迟到的SYNACK后发现ack号对不上直接丢弃但服务端这边已经为这个“幽灵连接”分配了资源连接就一直挂着浪费内存和端口。三次握手能解决这个问题因为客户端第三次ACK会带上确认号服务端发现ack号不匹配就能把这条畸形连接关掉。两次握手还有一个更大的缺陷无法确认服务端的发送能力和客户端的接收能力。第一次握手只能证明客户端能发、服务端能收第二次握手能证明服务端能发、客户端能收。但服务端不知道自己的报文客户端能否成功收到只有等到第三次ACK到来服务端才能确认“我发的包你也收到了”。不确认这一点服务端就开始发数据如果客户端压根收不到连接就名存实亡了。那四次为什么没必要因为SYN和ACK完全可以合并在一个报文里。三次握手已经是“信息交换完备且效率最高”的方案多一次只是冗余。这也是为什么TCP设计者最终选了三次而不是更稳妥但浪费的四次。值得一提的还有半连接队列和SYN Flood防护。服务端在SYN_RCVD状态时连接信息会放进半连接队列也叫SYN队列所以恶意攻击可以伪造海量SYN报文塞满这个队列让正常请求无法建立连接。现代系统里常见的缓解手段就是SYN cookies当半连接队列满的时候服务端不再为SYN分配资源而是把连接信息加密编码进SYNACK的序列号返回等收到客户端ACK后再还原连接。这部分内容排查连接异常时经常遇到后面第三节再展开。1.3 Wireshark 里如何快速筛选三次握手报文既然原理都懂了动手验证是必须的。Wireshark里抓包虽然简单但流量一多想快速定位握手报文就得靠过滤语法。抓本机回环流量最简单的方式:# 抓取本机回环接口端口以5200为例 sudo tcpdump -i lo -nn port 5200 -w handshake.pcap也可以用Wireshark直接抓Loopback: lo接口然后输入显示过滤器。一次性过滤出三次握手的核心报文tcp.flags.syn 1 tcp.flags.ack 0这是第一次握手的SYN报文。这里有个细节SYN置1但ACK置0说明是纯粹握手发起方不带确认性质。tcp.flags.syn 1 tcp.flags.ack 1这是第二次握手的SYNACK报文。确认号ack的值应该等于第一次握手的seq值加1。tcp.flags.ack 1 tcp.flags.syn 0 tcp.len 0这是第三次握手的纯ACK报文不带任何载荷。之所以加一个tcp.len 0是为了排除那些同样只有ACK标志位但是携带数据的数据包。如果你想一次性把三次握手都挑出来可以直接用tcp.stream eq N。右键点击任何一个握手报文选择“Follow - TCP Stream”Wireshark会自动给这条连接分配一个stream编号。比如这里看到TCP Stream index是5过滤器直接输入tcp.stream eq 5所有这条连接的报文都会展示出来从三次握手到中间的传输数据再到最后的挥手一目了然。抓包时要注意一个细节如果Wireshark里看到第一次握手重传TCP Retransmission而你的网络环境是在本机测试那多半不是网络丢包而是对端半连接队列满了或者服务端单线程accept处理不过来。别把抓包结果直接当成链路质量问题要先排除本机服务处理能力。2. 四次挥手断开连接的完整状态流转与TIME_WAIT的执念2.1 挥手的四个报文段分别是谁发的、为什么是四次三次握手是建立连接四次挥手是关闭连接同样的对称逻辑但报文段数量却差了一次。原因在于TCP连接是全双工的两个方向的数据通道需要独立关闭。发出FIN报文只代表“我这边没有数据要发了”但如果我还想收对端的数据仍可以继续接收。所以主动关闭方和被动关闭方各自要发一次FIN、各自要确认一次加在一起就是四次。标准挥手过程Client (主动关闭) Server (被动关闭) |------- FIN, seqm ----------| Client - FIN_WAIT_1 |------ ACK, ackm1 ---------| Server - CLOSE_WAIT, Client - FIN_WAIT_2 |------ FIN, seqn -----------| Server - LAST_ACK |------- ACK, ackn1 --------| Client - TIME_WAIT, Server - CLOSED这里最关键的一步在第二个和第三个报文之间。服务端收到FIN后先回一个ACK表示“我知道你要关了”但这并不意味着服务端立刻就能关闭连接因为服务端可能还有数据没发完。等服务端把剩下的数据传完才会发出自己的FIN报文。数据没发完的这段时间服务端一直处于CLOSE_WAIT状态。在实际开发中CLOSE_WAIT堆积是非常常见的线上故障。如果服务端代码写得不够健壮没有正确关闭socket或者业务线程阻塞客户端已经发FIN走了服务端却一直停留在CLOSE_WAIT大量连接把文件描述符耗尽新连接就进不来了。排查这类问题用ss命令看状态分布一目了然后面第四节会带一个实际案例。2.2 TIME_WAIT 为什么非要等 2MSL一秒钟行不行第四次挥手后主动关闭方不会立刻进入CLOSED而是停在TIME_WAIT状态等待2MSLMaximum Segment Lifetime报文最大生存时间之后才彻底关闭。这个设计看起来有点“拖泥带水”但作用非常关键。一是要确保最后一个ACK能到达对端。如果这个ACK在网络中丢失被动关闭方会因为没收到确认而重发FIN。主动关闭方若已经关闭就收不到这个重发的FIN更没法再次回复ACK被动关闭方就只能无限重传直到超时关闭状态资源被白白占用。TIME_WAIT等待2MSL恰好是“一个报文在网络里存活的最长时间 对端处理并重发的最坏情况”足以覆盖一次丢失重传的完整周期。二是要让旧连接的报文在网络中完全消散。如果没有TIME_WAIT连接关闭后立刻用相同的四元组源IP、源端口、目标IP、目标端口建立新连接前一个连接在网络中残留的迟到数据包就可能被新连接误认为有效载荷造成数据污染。2MSL时间过去之后旧报文已经全部消亡新连接拿到的一定是干净的历史。那2MSL具体是多久Linux下可以查看cat /proc/sys/net/ipv4/tcp_fin_timeout默认值通常是60秒也就是TIME_WAIT在Linux上实际等待时间并不是传统的2分钟或4分钟而是可以通过内核参数调整的。需要明确这个参数含义在不同内核版本里稍有差异但基本可以把它理解成TIME_WAIT的实际等待时长。高并发短连接场景下TIME_WAIT连接过多是一个经典困境。每次短连接关闭都会让主动关闭方留下一个TIME_WAIT如果主动关闭方是需要大量发起连接的客户端短时间内的端口可能被TIME_WAIT占满导致无法建立新连接。那篇文章里提到的bind报错error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address虽然这个报错本身是端口被占用或服务重复启动导致的但在TIME_WAIT堆积的场景下同样会遇到类似的socket资源受限问题。对服务端来说TIME_WAIT大多出现在主动关闭连接的一方。短连接服务如果主动关连接就会积累大量TIME_WAIT虽然不会立刻导致端口不可用服务端监听同一个固定的端口可以继续accept新连接但每个TIME_WAIT都占用内存描述符量大了还是会影响性能。解决办法后面第四节单独讲。2.3 长连接与短连接挥手次数如何反向影响业务设计四次挥手不是白白浪费的它直接影响业务架构的连接策略。理解TCP挥手后再看长连接与短连接的选型就会清晰很多。短连接的特点就是“用完即关”典型场景是HTTP/1.0。每次请求都经历三次握手、数据传输、四次挥手。这种模式实现简单服务端不需要维护大量并发连接状态但握手和挥手的开销占比很高尤其当单个请求数据量很小时光建立和释放连接的时间就超过了数据传输本身。所以短连接适合低频、小数据量的场景比如简单的API调用。长连接则是在一次握手后保持连接持续复用典型场景是数据库连接池、消息推送、即时通讯。长连接省去了反复握手的开销适合高频交互或需要服务端主动推送的场景。但长连接也带来一个麻烦连接长时间空闲中间的网络设备可能静默回收这条连接导致连接虽然建立着但实际上已经无法收发数据。这时候就需要心跳包。心跳包的本质就是在应用层定时发送小数据包维持连接活性同时探测对端是否还活着。从挥手角度再看一层短连接造成TIME_WAIT集中在主动关闭方长连接造成CLOSE_WAIT堆积则多半在服务端代码没优雅关闭的场景。所以当你看到TIME_WAIT很多先判断谁是主动关闭方、为什么主动关闭当你看到CLOSE_WAIT很多先检查服务端有没有正确关闭socket。这种判别思路比死记状态转换图有用得多。3. 常见报错与异常排查从握手到挥手路上的坑3.1 端口被占用与bind错误文章开头提到的bind报错error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address这行报错最常见的原因是同一个服务重复启动了多个进程或者端口被其他进程占用。排查方法非常简单# 查看哪个进程占用了11434端口 sudo lsof -i :11434 # 或者使用ss ss -tlnp | grep 11434 # 找到PID后确认进程信息 ps -fp PID还有一种可能性是前一个进程退出后没有释放端口进入了TIME_WAIT状态。TCP协议里主动关闭方会进入TIME_WAIT如果这个时候服务端马上重启监听同一个端口可能会失败。解决思路是设置SO_REUSEADDR。在Linux下这个选项允许新监听的socket绑定到TIME_WAIT状态的端口这是非常实用的经验。服务端代码里加上这一句能避免很多重启时的端口占用幽灵问题。对Go语言来说常见写法ln, err : net.Listen(tcp, 127.0.0.1:11434) if err ! nil { log.Fatal(err) }Go在底层默认已经设置了SO_REUSEADDR所以上面的报错更多还是进程未退出或端口真被占用优先用lsof排查。3.2 TCP Connection Reset by Peercurl报错curl: (35) TCP connection reset by peer这个报错翻译过来就是“TCP连接被对端重置了”。连接重置RST通常发生在以下几种场景场景一服务端根本没有进程在监听这个端口客户端发SYN过去内核直接回RST。这属于“端口敲门失败”排查思路跟上面的端口检查一样。场景二连接已经建立了但服务端进程崩溃内核在进程退出时发送RST客户端再往这个连接上写数据就收到Connection reset。场景三服务端主动关掉了连接但客户端还在发数据或者客户端收到数据后才发现连接已经关闭这时也会触发RST。场景四TCP的keepalive超时或者中间设备比如Nginx、防火墙清掉了空闲连接对端再发数据就会收到RST。这属于“半开连接”问题根本解决方案是应用层心跳。遇到Connection reset优先打开抓包sudo tcpdump -i eth0 -nn port 8080 -w reset.pcap然后在Wireshark里过滤RST报文tcp.flags.reset 1同时要结合时序判断RST出现在三次握手阶段?还是传输阶段?还是挥手阶段?不同的出现位置排查方向完全不一样。这里还要补充一个和TCP有强关联但方向上不同的词Modbus TCP。很多工控场景里PLC和上位机通过Modbus TCP通信Modbus报文承载在TCP之上如果出现Connection reset多半也是上面的几种原因。在S7-1200与多个Modbus TCP从站轮询的场景里经常遇到的问题是轮询周期太短上一个请求还没处理完下一个请求就来了导致从站主动RST。解决思路是适当拉长轮询间隔或者对单个从站的连接做超时重连机制。STM32这类嵌入式设备跑FreeModbus TCP时因为资源有限尤其要注意服务端主动关闭连接时的TIME_WAIT管理不然设备长时间运行后端口资源会耗尽。3.3 SYN重传与半连接队列溢出如果客户端发出SYN后一直收不到SYNACK就会反复重传SYN。抓包里看到大量的TCP Retransmission且重传的都是SYN报文说明SYN报文根本没到达服务端或者服务端压根没回应。客户端视角的可能原因服务端IP或端口错误网络不可达被防火墙或安全组规则拦截服务端的半连接队列已经满了新的SYN被内核丢弃服务端视角的排查方法# 查看SYN重传次数 sysctl net.ipv4.tcp_syn_retries # 查看半连接队列溢出统计 netstat -s | grep -i SYNs to LISTEN内核参数tcp_max_syn_backlog和somaxconn共同决定半连接队列大小。如果发现SYN包丢包严重且服务端负载不高可以考虑调大这两个参数。但如果是被SYN Flood攻击盲目调大参数反而会加剧资源消耗这时候应该启用SYN cookiestcp_syncookies 1。对应用层开发来说还有一层容易踩坑服务端listen的backlog参数设置得过小即使内核半连接队列和全连接队列都正常应用层来不及accept连接也会堆积。很多语言里listen的第二个参数就是backlog如果写得太小压测时就会看到一部分连接建立失败但抓包看三次握手是正常的问题出在全连接队列溢出。用ss -lnt可以看到当前socket的Send-Q和Recv-QRecv-Q表示等待accept的连接数如果这个值长期接近backlog上限就要调大应用层的backlog或者增加accept线程。4. 用状态机看待一条连接的一生从请求到关闭的完整实操4.1 用ss和netstat查看连接状态纸上谈兵没用连接状态一定要上机器看。# 查看所有TCP连接及状态 ss -tan # 只看监听状态的端口 ss -tln # 查看连接状态分布统计 ss -tan | awk {print $1} | sort | uniq -c # 查看指定端口的连接 ss -tan | grep 8080netstat命令用法类似但ss的效率更高尤其在连接数上万的机器上netstat会明显卡顿。日常排查建议习惯用ss。一条完整的TCP连接从建立到关闭会经历这些状态状态含义常见出现位置LISTEN服务端监听端口等待连接服务端SYN_SENT客户端已发出SYN等待SYNACK客户端SYN_RCVD服务端已收到SYN回复SYNACK服务端ESTABLISHED连接建立成功正常传输数据双方FIN_WAIT_1主动关闭方已发FIN等待ACK主动关闭方FIN_WAIT_2主动关闭方已收到ACK等待对端FIN主动关闭方CLOSE_WAIT被动关闭方已收到FIN等待应用层关闭socket被动关闭方LAST_ACK被动关闭方已发FIN等待最终ACK被动关闭方TIME_WAIT主动关闭方等待2MSL主动关闭方CLOSED连接完全关闭双方如果ss的输出里某一种状态异常多基本就有了排查方向。比如CLOSE_WAIT几百个说明服务端代码里socket没关干净TIME_WAIT几千个说明主动关闭连接太频繁考虑连接复用或调优参数。4.2 从客户端和服务端视角分别观察三次握手我们用一个真实的连接受命过程来演示。假设服务端监听在127.0.0.1:8080客户端发起一个HTTP请求。第一步服务端启动后执行ss -tln | grep 8080输出里可以看到LISTEN 0 128 127.0.0.1:8080 0.0.0.0:*第二列是当前等待accept的连接数第三列是backlog上限。如果第二列长期等于第三列说明accept速度跟不上请求速度。第二步客户端发起请求后在服务端和客户端同时用ss看状态。一瞬之间你可能会看到SYN_RCVD一闪而过然后立刻变成ESTABLISHED。如果SYN_RCVD持续存在很久说明服务端收到了SYN但应用层没有及时accept或者半连接队列处理存在问题。第三步抓包看完整流程。用tcpdump抓完整过程sudo tcpdump -i lo -nn port 8080 -w curl_test.pcap再用curl发起请求curl http://127.0.0.1:8080/抓包文件里应该依次出现三次握手、HTTP请求报文、HTTP响应报文、四次挥手记录。在Wireshark里选中第一个SYN报文看它的TCP头部Sequence Number是随机值Flags标记里SYN置位。再选中SYNACK报文可以看到它的Sequence Number是另一个随机值Acknowledgment Number正好是前一个SYN的seq加1。选中第三个ACK报文确认号又是SYNACK的seq加1。这就是握手全过程最直观的体现。实际操作中如果你抓本机回环流量tcpdump的过滤器可以这样写sudo tcpdump -i lo -nn tcp port 8080 and (tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0)这个过滤器可以抓出SYN、FIN、RST三类关键控制报文直接看清连接建立和关闭的全过程数据报文被过滤掉了看状态流转更清爽。4.3 程序里如何优雅处理断开与重连很多网络故障的根源不在协议栈而在应用层没有处理好连接生命周期。我总结了几条实际开发里比较重要的经验。一是要设置合理的读写超时。如果对端一直不返回数据socket读操作会一直阻塞。设置超时后超时异常可以用来触发重连逻辑。Go语言里conn.SetReadDeadline(time.Now().Add(10 * time.Second)) conn.SetWriteDeadline(time.Now().Add(10 * time.Second))二是要处理对端异常关闭的情况。对端崩溃后本端可能不会立刻感知。只有往一个已经关闭的连接上写数据时才会触发EPIPE或者ECONNRESET错误。所以除了心跳还要养成“每次读写都检查错误”的习惯读到EOF对端正常关闭和读到RST对端异常关闭要区别对待。三是重连要加退避。如果服务端短暂不可用客户端不要疯狂重连。用指数退避策略第一次等1秒第二次2秒第三次4秒最多等到30秒或60秒封顶既能快速恢复又不会把服务端打爆。四是客户端主动关闭连接时尽量不要复用处于TIME_WAIT状态的端口去立即发起新连接。这在连接池场景里比较常见。比较好的做法是复用长连接减少主动关闭的次数。如果必须大量短连接客户端侧也可以调节tcp_max_tw_buckets等参数但修改内核参数要谨慎分清系统调优和应用调优的边界。写一个最简单的TCP服务端示例演示优雅关闭import socket import signal import sys server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((127.0.0.1, 8080)) server.listen(128) server.settimeout(1) running True def handler(signum, frame): global running running False signal.signal(signal.SIGINT, handler) signal.signal(signal.SIGTERM, handler) while running: try: conn, addr server.accept() except socket.timeout: continue except OSError: break with conn: data conn.recv(1024) if data: conn.sendall(bhello from tcp server) conn.close() server.close() print(server closed gracefully)这段代码的关键在于SO_REUSEADDR设置和信号处理。收到SIGTERM时先停止accept新连接处理完当前连接后释放socket避免进程退出后端口还被占用。很多线上端口冲突问题就是没有做这种优雅退出导致的。4.4 挥手过程抓包实操亲眼验证TIME_WAIT平时在机器上很难肉眼看到TIME_WAIT因为2MSL的时间窗口短暂且连接很快就关闭了。但我们可以通过抓包方式验证完整的挥手流程。准备一个小工具主动关闭方发起连接后立即断开。在服务端和客户端同时抓包可以看到时间点1 客户端 - 服务端 FIN, seqxxx 时间点2 服务端 - 客户端 ACK, ackxxx1 时间点3 服务端 - 客户端 FIN, seqyyy 时间点4 客户端 - 服务端 ACK, ackyyy1第四个ACK发出后用ss查看客户端连接状态ss -tan | grep 8080输出里会有TIME-WAIT 0 0 127.0.0.1:54321 127.0.0.1:8080这条连接并不会立刻消失而是要等tcp_fin_timeout秒之后才被系统清理。如果在TIME_WAIT期间用相同端口重新发起连接会发现无法复用这个端口。这就是TIME_WAIT的直观体现。如果你的服务是主动关闭方大量的TIME_WAIT可能导致新连接建立变慢。有些团队会用tcp_tw_reuse来缓解sysctl net.ipv4.tcp_tw_reuse1这里必须说明tcp_tw_reuse只对客户端出站连接有效它允许内核在新建连接时复用TIME_WAIT状态的端口前提是新的连接序号大于旧连接的最后序号。它并不能减少服务端这边的TIME_WAIT。至于tcp_tw_recycle参数由于它的实现存在较多兼容性问题NAT环境下容易导致连接异常实际生产中并不推荐开启。对大多数场景来说更稳妥的方案是调整连接池、复用长连接从应用层面减少TIME_WAIT的产生。5. 握手挥手之外的TCP实用边界和UDP怎么选、状态检查如何辅助排障5.1 TCP和UDP的区别聊到哪个粒度就够了每次聊TCP就一定绕不开UDP。我的看法是梳理一遍底层的区别再带到应用选型里去比单纯背对比列表靠谱得多。TCP面向连接、可靠、有序、有流量控制和拥塞控制。它把所有可靠性问题都扛在了协议栈里应用层只需要读写数据流即可。代价是头部开销大、连接管理复杂、存在队头阻塞。UDP无连接发送方只管把数据报扔出去能不能到、什么时候到、顺序对不对都不保证。代价少了一大堆换来的是低延迟、低开销、实现简单。哪些场景更适合UDP实时音视频、游戏同步、DNS查询都算。这些场景丢一个包可以接受但延迟高不可接受TCP的重传机制反而成了累赘。哪些场景必须用TCP文件传输、数据库事务、消息队列、Web API等任何要求数据完整到达的场景都是TCP的天下。还有一个容易被忽略的点很多应用层协议比如HTTP/3和QUIC实际上基于UDP实现了自己的可靠传输。这说明TCP和UDP之间并不是“谁替代谁”的关系而是不同可靠性机制在不同场景下的取舍。面试时如果能从这个角度回答说明你是真的理解了传输层的设计逻辑。5.2 用三次握手和四次挥手的底层知识反推线上问题TCP的原理记熟了真正大的价值在于遇到线上问题能快速定位。我举一个真实的工作场景。某天同事反馈服务A到服务B的接口偶发超时看了监控连接建立成功率正常但有少量请求耗时超过5秒。抓包后发现部分请求的三次握手中出现了SYN重传确认是网络层丢包。但奇怪的是丢包只发生在特定时间段。后来检查发现服务B所在的机器在同一时间段有大量日志写入磁盘IO打满导致内核网络栈处理延迟SYN包排队处理客户端等不及就重传了。这个问题的定位完全依赖对握手超时和重传机制的理解。又比如线上服务大量CLOSE_WAIT打开ss一看几百个连接停在CLOSE_WAIT。查应用日志发现服务端代码里有一段网络请求忘记加超时保护对端不返回时线程一直阻塞socket得不到关闭即使收到FIN也无法进入后续的LAST_ACK和CLOSED状态。这个问题对应的核心知识点就是前面讲过的被动关闭方状态转换。所以说TCP三次握手和四次挥手不是一个八股问题它是排查一切连接异常的地基。地基不牢看到CLOSE_WAIT不知从何下手看到TIME_WAIT也只能瞎改内核参数。6. 一些值得记住的实测参数与后续扩展方向6.1 快速参考常用TCP排障命令与参数以下是我日常排查TCP问题时比较常用的命令集合做成速查表方便收藏需求命令查看整体连接状态分布ss -tan | awk {print $1} | sort | uniq -c查看监听端口和队列ss -tln查看某个端口的established连接数ss -tan state established | grep :8080抓包指定端口sudo tcpdump -i any -nn port 8080 -w file.pcap过滤RST包tcpdump tcp[tcpflags] tcp-rst ! 0TCP连接跟踪ss -tan | grep ESTAB查看TCP重传统计netstat -s | grep -i retrans查看半连接溢出netstat -s | grep -i SYNs to LISTEN内核参数方面最有实践意义的几个net.ipv4.tcp_syn_retries # SYN重传次数默认6 net.ipv4.tcp_synack_retries # SYNACK重传次数默认5 net.ipv4.tcp_fin_timeout # TIME_WAIT实际等待时间默认60秒 net.ipv4.tcp_tw_reuse # 客户端复用TIME_WAIT端口默认0 net.ipv4.tcp_max_syn_backlog # 半连接队列上限 net.core.somaxconn # 全连接队列上限 net.ipv4.tcp_syncookies # 是否启用SYN Cookies默认1强调一下修改内核参数要看场景。比如tcp_syn_retries调小了服务端不可达时客户端能更快失败这是好事但如果是弱网环境调小了反而容易把原本能成功的连接搞失败。参数没有绝对的好坏只有适不适合运行环境和业务模型。6.2 嵌入式与工业场景里的TCP细节热词列表里有不少工业自动化和嵌入式相关的内容比如Modbus TCP、S7-1200轮询、STM32F407移植FreeModbus TCP。这些场景里TCP协议本身的机制不变但资源约束和网络环境完全不同。嵌入式设备内存小、CPU弱跑TCP协议栈时要特别注意内存池和收发缓冲区配置。lwIP里经常要调整TCP_MSS、TCP_WND、PBUF_POOL_SIZE这些参数。如果配置太小大报文会被分片传输效率明显下降。如果配置太大内存又可能不够用。这是典型的“根据环境调协议参数”的实践。PLC轮询场景里S7-1200作为Modbus TCP主站轮询多个从站时连接管理和超时设置是关键。每个从站的连接如果在轮询间隙长期保持会占用大量资源如果频繁关闭重建又会受TIME_WAIT影响。实际项目中比较稳妥的方案是保活少量长连接但应用层实现看门狗发现连接异常就主动断开重建。Modbus TCP的报文结构本身不复杂复杂的是在工业现场的不稳定网络里维持连接可靠性。ESP01S这类WiFi模块发送TCP消息也属于嵌入式范畴。模块固件通常已经封装好了AT指令开发者要注意的是TCP客户端模式下的连接保活机制。如果模块和服务端之间长时间没有数据交互路由器可能会回收这条连接。定期发送心跳或者依赖模块自带的TCP keepalive配置可以缓解这个问题。这些场景有一个共同的启示TCP协议栈是操作系统和硬件提供的底座但要不要用长连接、怎么处理重连、怎么检测对端存活永远是应用层的设计责任。这也是为什么我前几节花了大量篇幅讲状态和参数而不是只看报文格式。报文格式只是表状态管理和异常处理才是里子。我个人在实际排查中最大的一个体会是遇到TCP相关的问题一定不要只看应用层日志先把状态机和抓包结合起来看。很多看起来莫名其妙的超时和重置抓一次包就原形毕露了。再分享一个小技巧排查的时候尽量抓两端的数据包只抓一端很容易被误导比如客户端看到SYN没回应可能是服务端收到了但回包丢了也可能是服务端根本没收到两个方向的数据一对比问题出在哪一层立即清楚。这个做法在实践中帮我省了非常多的时间。