1. 项目概述为什么我们需要握手与挥手如果你用过微信或者QQ你一定知道想和一个人聊天得先加他为好友等对方同意后你们才能开始发消息。聊完了觉得没话说了或者要下线了你们可能会互相道个别然后结束这次对话。计算机网络里的TCP协议干的事儿和这个差不多只不过它更严谨、更“有仪式感”。它负责在两个程序比如你的浏览器和某个网站的服务器之间建立一条可靠的、不会丢数据的“对话通道”。这个“建立通道”的过程就叫“三次握手”而“结束对话、关闭通道”的过程就叫“四次挥手”。听起来有点抽象别急我打个比方。假设你客户端想给一个朋友服务器打电话。三次握手就像打电话的拨号、接通和确认过程你拨通电话第一次握手客户端说“喂能听到吗”。朋友接起电话说“喂我能听到你能听到我吗”第二次握手服务器回应并确认。你听到朋友的声音回答“嗯我也能听到你那我们开始聊吧”第三次握手客户端最后确认。只有这三步都完成了你们才确信这条电话线路是通的双方都能正常收发声音可以开始正式交谈了。TCP的三次握手核心目的就是为了确认双方的“发送”和“接收”能力都正常并为后续的数据传输同步一些必要的初始参数。四次挥手则像挂电话前的礼貌告别你说“我要说的事儿都说完了我准备挂电话了哦。”第一次挥手客户端发起关闭。朋友说“好的我知道你要挂了我这边也准备一下。”第二次挥手服务器确认收到关闭请求。朋友可能还有最后一两句话要补充说完后他说“好了我也说完了我也要挂了。”第三次挥手服务器发起关闭。你最后说“好的收到那我们都挂了吧。”第四次挥手客户端确认连接彻底关闭。这个过程确保了双方都说完了所有话并且都同意结束避免了任何一方突然“啪”一下挂断导致另一方还在傻等的尴尬局面。TCP的四次挥手就是为了确保数据能够完整传输完毕并安全、有序地释放连接资源。所以无论你是刚入门网络编程的新手还是经常遇到“连接超时”、“连接被重置”等问题需要排查的开发者甚至是运维和测试人员理解TCP三次握手和四次挥手的细节都是你深入理解网络通信、诊断网络问题的基石。这篇文章我就用最直白的方式带你把这“三握四挥”的每一个步骤、每一个标志位都掰开揉碎了讲清楚保证你看完就能懂懂了就能用。2. TCP连接建立三次握手全流程拆解TCP协议在传输数据前必须首先建立连接。这个建立过程不是一蹴而就的它通过三次报文交互来确保连接的可靠性。我们把这个过程称为“三次握手”。下面我们深入到每一个报文的内部看看它们到底交换了什么信息。2.1 第一次握手SYN报文与序列号同步想象一下客户端比如你的电脑上的浏览器决定要连接服务器比如某个网站的Web服务器。它不能直接开始发送网页请求数据必须先打个招呼建立一条虚拟的“管道”。客户端会主动发送一个特殊的TCP报文。这个报文的核心是将其SYN标志位设置为1表示这是一个“同步Synchronize”报文目的是发起连接。同时客户端会随机生成一个初始序列号Initial Sequence Number, ISN假设是client_isn 1000并放在报文的“序列号Sequence Number”字段里。这个序列号非常关键。TCP协议是面向字节流的它把要发送的数据看作一串字节流。序列号就是用来给这串字节流中的每一个字节进行编号的起点。选择随机数而不是固定从0或1开始主要是出于安全考虑防止被恶意预测和攻击。此时客户端进入SYN-SENT同步已发送状态。它就像发出了一个询问“服务器你好我的初始号是1000你愿意和我建立连接吗”注意这个第一次握手的报文不携带任何应用层数据比如HTTP请求内容。它的 payload数据部分长度是0。它的唯一使命就是协商连接的开始。2.2 第二次握手SYN-ACK报文与双向确认服务器一直在某个端口比如Web服务的80或443端口上监听。当它收到客户端发来的SYN报文后如果它同意建立连接就会回复一个同样特殊的报文。这个回复报文同时设置了两个标志位SYN1 和 ACK1。因此它被称为SYN-ACK报文。SYN1表示这是服务器对连接请求的回应同时服务器也告诉客户端“我这边也要同步一下”。所以服务器也会生成自己的初始序列号假设是server_isn 5000放在报文的“序列号”字段里。ACK1表示这是一个确认报文。TCP报文中还有一个“确认号Acknowledgment Number”字段。服务器会把这个字段的值设置为client_isn 1也就是1000 1 1001。这个“确认号1001”的含义是“客户端我已经成功收到了你序列号为1000的SYN报文我期望你下一次发送数据的序列号从1001开始。” 这完成了对客户端第一次握手的确认。此时服务器进入SYN-RCVD同步已接收状态。它的回复包含了双重信息“我收到你的连接请求了ACK并且我也准备好了我的初始号是5000SYN。”2.3 第三次握手ACK报文与连接确立客户端收到服务器的SYN-ACK报文后需要对这个报文进行最后的确认以完成连接的建立。客户端会发送第三个报文。这个报文将ACK标志位设置为1表示确认。同时它的“序列号”字段设置为client_isn 1也就是1001。这是因为第一次握手消耗了一个序列号1000虽然没数据但SYN标志位占用一个序号所以下一个可用的序号就是1001。它的“确认号”字段设置为server_isn 1也就是5000 1 5001。这个“确认号5001”的含义是“服务器我已经成功收到了你序列号为5000的SYN报文我期望你下一次发送数据的序列号从5001开始。” 这完成了对服务器第二次握手的确认。当这个ACK报文到达服务器后服务器端进入ESTABLISHED已建立连接状态。客户端在发出这个ACK后也立即进入ESTABLISHED状态。至此三次握手完成。双方就以下关键信息达成一致双方都确认了对方的发送和接收能力正常。双方交换并确认了彼此的初始序列号client_isn1000,server_isn5000为后续的字节流传输奠定了编号基础。一条全双工的、可靠的TCP连接通道正式建立成功双方可以开始传输应用层数据了比如HTTP请求和响应。实操心得为什么是三次不是两次或四次这是一个经典面试题。核心在于防止已失效的连接请求报文突然又传到了服务器导致服务器错误开启连接。 假设只有两次握手客户端发送一个SYN但由于网络拥堵这个SYN迟迟未到服务器。客户端超时后重发一个SYN并成功建立连接、传输数据、关闭连接。此时那个迟到的第一个SYN终于到达了服务器服务器误以为这是新的连接请求于是回复SYN-ACK并进入等待状态。而客户端早已关闭不会理会这个ACK导致服务器白白空等浪费资源。 采用三次握手后即使那个失效的SYN到达服务器回复SYN-ACK但由于客户端不会对此进行第三次ACK确认服务器在等待超时后就会关闭这个半连接避免了资源浪费。三次是保证双方互相确认对方存活的最小次数。3. TCP连接终止四次挥手流程深度解析天下没有不散的筵席TCP连接也一样。当数据传送完毕后通信的任何一方都可以发起关闭连接的请求。由于TCP连接是全双工的即数据可以同时在两个方向上独立传输因此每个方向都必须单独进行关闭。关闭的原则是当一方发送完数据后发送一个FIN报文来终止本方向的数据发送当另一方收到这个FIN后它知道这个方向上没有数据再来了但可能它自己还有数据要发送所以它先确认这个FIN等自己的数据也发送完毕后再发送自己的FIN报文。这就导致了需要四次报文交互。3.1 第一次挥手FIN报文与主动关闭假设客户端的数据已经发送完毕决定主动关闭连接服务器也可以主动关闭过程对称。客户端会发送一个TCP报文将其FIN标志位设置为1表示“我这边数据发完了准备关闭我这一侧的连接”。同时这个报文会携带一个序列号假设是seq 2000这个数字是之前数据传输累积下来的。发送完这个FIN报文后客户端进入FIN-WAIT-1终止等待1状态。此时客户端不能再向服务器发送应用层数据但它仍然可以接收来自服务器的数据。3.2 第二次挥手ACK报文与半关闭状态服务器收到客户端发来的FIN报文后立即明白客户端已经完成了数据发送想要关闭连接。服务器会回复一个ACK报文ACK1。这个ACK报文的“确认号”字段会设置为收到的FIN报文的序列号 1即2000 1 2001。意思是“客户端你的FIN报文seq2000我收到了我知道你那边要关了。”发送完这个ACK后服务器进入CLOSE-WAIT关闭等待状态。此时连接进入了一种“半关闭Half-Close”状态从客户端到服务器这个方向的数据通道关闭了客户端不会再发数据过来但从服务器到客户端这个方向的数据通道仍然是打开的服务器可能还有未发送完的数据需要继续传送给客户端。客户端收到这个ACK后就从FIN-WAIT-1状态进入FIN-WAIT-2终止等待2状态。在这个状态下客户端等待服务器发送它自己的FIN报文。3.3 第三次挥手服务器的FIN报文当服务器也将自己要发送给客户端的数据全部发送完毕后它就需要关闭自己这一侧的连接了。于是服务器发送自己的FIN报文FIN1。这个报文也会携带一个序列号假设是seq 7000服务器自己数据流的序列号。发送完这个FIN报文后服务器进入LAST-ACK最后确认状态。它等待客户端对它的这个FIN报文进行最后的确认。3.4 第四次挥手最后的ACK与资源释放客户端收到服务器的FIN报文后知道服务器那边也完事儿了。客户端必须对这个FIN报文进行确认。它发送最后一个ACK报文ACK1。这个ACK报文的“确认号”字段设置为收到的服务器FIN报文的序列号 1即7000 1 7001。发送完这个ACK后客户端进入TIME-WAIT时间等待状态。请注意此时客户端的TCP连接并没有立刻释放它需要等待一个特定的时间这个时间称为2MSLMaximum Segment Lifetime报文最大生存时间的两倍通常是2分钟具体实现可能不同如Linux一般是60秒。为什么需要TIME-WAIT状态和等待2MSL主要有两个原因可靠地终止连接客户端发送的最后一个ACK有可能丢失。如果丢失服务器在LAST-ACK状态会因为超时未收到ACK而重发它的FIN报文。客户端在TIME-WAIT状态下收到这个重传的FIN后可以重发ACK确保连接能正常关闭。2MSL时间足以让这个方向上的报文最多存活一个MSL也让对端重传的报文最多存活一个MSL从而处理这种极端情况。让旧连接的报文在网络中消逝防止之前连接延迟的报文段属于旧的、已关闭的连接被误认为是新建立的同名连接相同IP和端口的数据造成数据混乱。服务器一旦收到客户端发来的最终ACK就立即从LAST-ACK状态进入CLOSED关闭状态连接完全关闭释放所有资源。客户端在经历了2MSL的等待时间后也进入CLOSED状态释放资源。注意事项CLOSE-WAIT状态过多的问题在实际运维中CLOSE-WAIT状态是一个需要警惕的信号。如果服务器上出现大量处于CLOSE-WAIT状态的连接通常意味着服务器端的应用程序没有正确地关闭Socket。在收到客户端的FIN并回复ACK后应用程序没有调用close()函数来发送自己的FIN导致连接一直卡在CLOSE-WAIT状态无法彻底关闭。这会造成服务器文件描述符fd泄漏最终可能导致“Too many open files”错误使服务不可用。排查这类问题的关键点是检查服务器端应用程序的Socket关闭逻辑。4. 核心标志位与序列号机制详解理解了握手和挥手的流程我们还需要深入看看驱动这些流程的“幕后英雄”——TCP报文头中的几个关键字段。正是它们赋予了TCP可靠性。4.1 六大控制标志位指挥通信的旗帜TCP报文头中有6个重要的控制位Flags每个占1比特它们像一面面小旗子指挥着报文的用途。SYN (Synchronize)同步序列号。仅在建立连接时使用。当SYN1而ACK0时表示这是一个连接请求报文当SYN1且ACK1时表示这是一个连接接受报文即第二次握手。ACK (Acknowledgment)确认号有效。绝大多数TCP报文都会设置这个标志位表示报文头中的“确认号”字段是有效的。一旦一个连接建立起来ACK通常总是被置为1。FIN (Finish)终止连接。用来释放一个连接。当FIN1时表明此报文段的发送方的数据已经发送完毕并要求释放连接。RST (Reset)重置连接。当RST1时表示TCP连接中出现严重差错如主机崩溃、端口未打开必须释放连接然后再重新建立连接。它还可以用来拒绝一个非法的报文段或拒绝打开一个连接。你经常看到的“Connection reset by peer”错误就和它有关。PSH (Push)推送。接收方应尽快将这个报文段交给应用层而不是等缓冲区满了再提交。常用于需要实时交互的场景。URG (Urgent)紧急指针有效。表示报文段中有紧急数据应尽快传送。需要和“紧急指针”字段配合使用现在已较少使用。在三次握手中我们主要看到SYN和ACK的配合。在四次挥手中则主要看到FIN和ACK的配合。RST则像一个“紧急刹车”用于异常处理。4.2 序列号与确认号可靠传输的基石这是TCP实现可靠性的核心机制理解了它们就理解了TCP如何保证数据不乱序、不丢失。序列号 (Sequence Number, seq)标识本报文段所发送的数据的第一个字节的编号。在建立连接时双方会同步初始序列号ISN。之后每发送一个字节的数据序列号就加1。例如初始序列号为1000如果发送了一个长度为100字节的数据段那么这个数据段的序列号就是1000下一个数据段的序列号就是1100。确认号 (Acknowledgment Number, ack)期望收到对方下一个报文段的第一个数据字节的序列号。同时确认号ackN也表示序号N-1及之前的所有数据都已被正确接收。例如B收到A发来的一个序列号为1000、长度为100的数据段那么B回复给A的确认号就是1000 100 1100意思是“A我已经收到了你序列号到1099的数据我接下来期望你从1100开始发。”确认机制是累积确认。如果B收到了A发来的seq1000长度100和seq1100长度200两个数据段它可以直接回复一个ack1300表示1000到1299的数据都收到了无需对每个小段单独确认。这种“带重传的肯定确认”机制结合超时重传和滑动窗口流量控制共同构成了TCP的可靠性保障。发送方发送数据后会启动一个定时器如果在规定时间内没有收到对方的确认就会重发该数据。实操心得Wireshark抓包看握手挥手理论说得再多不如亲眼一见。我强烈建议你用Wireshark这个网络抓包工具实际抓取一次TCP流量看看。打开Wireshark选择你的活动网卡如Wi-Fi或以太网开始抓包。在浏览器中访问一个HTTP网站比如http://example.com。在Wireshark的过滤栏输入tcp and ip.addr 网站IP来过滤流量。你就能清晰地看到最开始的三个包[SYN]-[SYN, ACK]-[ACK]这就是三次握手。观察它们的序列号和确认号完全符合我们讲的规律。关闭浏览器标签页你可能会看到随后的[FIN, ACK]-[ACK]-[FIN, ACK]-[ACK]四个包顺序可能因谁主动关闭而异这就是四次挥手。 亲手操作一遍这些抽象的概念会立刻变得无比具体和牢固。5. 常见问题与实战场景深度剖析理解了基本原理后我们来看看在实际开发、运维和面试中围绕三次握手和四次挥手会遇到哪些典型问题。5.1 连接建立失败原因与排查思路当你遇到“Connection timeout”、“Connection refused”或“No route to host”等错误时问题可能出在握手阶段。服务器端口未监听这是“Connection refused”的常见原因。客户端发送SYN报文到服务器的某个端口但该端口上没有进程在监听。服务器操作系统会直接回复一个[RST, ACK]报文来拒绝连接。排查在服务器上使用netstat -tlnp或ss -tlnp命令检查目标端口是否处于LISTEN状态。SYN报文被防火墙拦截客户端发出的SYN报文根本没能到达服务器或者在到达服务器网卡后被iptables等防火墙规则丢弃。客户端会一直重试发送SYN直到超时。排查检查服务器和中间网络设备的防火墙规则确保目标端口是开放的。可以使用tcpdump在服务器端抓包看是否能收到客户端的SYN报文。服务器SYN-ACK报文丢失服务器回复了SYN-ACK但这个报文在网络上丢失了。客户端收不到回复会重传SYN服务器则处于SYN-RCVD状态等待客户端的ACK。如果服务器长时间收不到ACK会重传SYN-ACK最终超时关闭这个“半连接”。排查这种情况较难直接定位需要同时在客户端和服务器抓包对比分析。客户端ACK报文丢失客户端发出的第三次握手ACK丢失。服务器处于SYN-RCVD状态并等待超时而客户端在发出ACK后认为连接已建立进入ESTABLISHED可能会开始发送数据。服务器收到这些数据序列号正确但状态不对会回复RST报文重置连接导致客户端出现“Connection reset”错误。排查同样需要双向抓包分析。5.2 连接终止异常TIME_WAIT与CLOSE_WAIT这是挥手阶段最常见的问题。TIME_WAIT状态过多在高并发短连接的场景下例如Web服务器主动关闭连接的客户端对于服务器来说它也可能是主动关闭方如Nginx反向代理后端服务会产生大量的TIME_WAIT状态连接。每个TIME_WAIT连接会占用一个本地IP:端口四元组并持续2MSL时间。如果短时间内连接数巨大可能导致本地端口被耗尽无法建立新连接出现“Cannot assign requested address”错误。解决方案启用端口复用在服务器Socket上设置SO_REUSEADDR选项允许新的连接重用处于TIME_WAIT状态的端口。这是最常用、最有效的解决方案。调整内核参数减少MSL时间net.ipv4.tcp_fin_timeout但需谨慎可能影响可靠性或开启tcp_tw_recycle在NAT环境下有严重问题Linux 4.12内核已移除和tcp_tw_reuse较安全允许将TIME_WAIT连接用于新的出向连接。优化架构使用连接池、长连接减少短连接数量。CLOSE_WAIT状态过多如上文所述这本质是应用程序Bug。服务器程序在收到对端的FIN后没有调用close()来关闭本端的Socket。连接永远卡在CLOSE-WAIT状态导致文件描述符泄漏。排查与解决使用netstat -n | awk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]}或ss -ant | awk NR1 {s[$1]} END {for(k in s) print k,s[k]}统计各状态连接数如果CLOSE-WAIT数量持续增长基本可以确定。使用lsof -p 进程PID查看具体是哪个进程的哪个Socket处于该状态。根本解决必须修复应用程序代码确保在所有执行路径上包括异常处理都正确关闭了Socket。使用 try-with-resourcesJava、defer closeGo、using语句C#或RAIIC等机制可以有效避免此类问题。5.3 半连接队列与全连接队列溢出这是服务器端在握手阶段可能遇到的性能瓶颈。半连接队列SYN Queue服务器收到SYN报文回复SYN-ACK后连接进入SYN-RCVD状态该连接被放入“半连接队列”。全连接队列Accept Queue服务器收到客户端的第三次握手ACK后连接进入ESTABLISHED状态从半连接队列移出放入“全连接队列”等待应用程序调用accept()函数取走。如果瞬间有大量连接请求如SYN Flood攻击可能导致半连接队列满新的SYN会被丢弃。如果应用程序处理连接的速度跟不上会导致全连接队列满此时服务器的行为由tcp_abort_on_overflow参数决定通常默认是0即悄悄丢弃客户端发来的ACK导致客户端重传但服务器已无法处理。排查与调优查看队列溢出统计netstat -s | grep -i listen或ss -lnt查看Send-Q列表示当前全连接队列长度和Recv-Q列表示等待被accept的连接数。调整队列大小通过内核参数net.core.somaxconn系统级别最大全连接队列长度和应用程序的listen()函数第二个参数backlog指定该Socket的全连接队列最大长度取两者较小值来调整全连接队列大小。半连接队列大小通常由net.ipv4.tcp_max_syn_backlog等参数控制。6. 从协议到实践抓包分析与性能调优理论最终要服务于实践。我们如何利用对握手挥手的理解来解决实际问题6.1 使用Wireshark/Tcpdump进行网络诊断网络问题排查抓包是终极武器。结合三次握手和四次挥手的知识你可以像法医一样解读网络流量。场景分析一个HTTP请求为什么慢。过滤tcp and ip.addr 目标服务器看握手延迟观察第一个SYN包和SYN-ACK包之间的时间差。这个时间差基本代表了网络往返时间RTT。如果这个时间异常大比如几百毫秒以上可能是网络链路问题。看挥手过程请求结束后看挥手是否正常完成。如果看到大量的[RST]报文说明连接被异常重置可能是程序bug或防火墙策略。看重传在抓包界面Wireshark会将重传的报文标记为黑色或红色。频繁的重传意味着网络丢包严重会极大影响性能。你可以通过tcp.analysis.retransmission过滤器专门查看重传包。一个典型的连接问题排查流程客户端报错“连接超时”。在客户端抓包发现发送了SYN但没有收到SYN-ACK。结论SYN包可能被中间网络丢弃或服务器未响应。在服务器抓包如果根本没收到SYN问题在客户端到服务器的网络路径上。如果收到了SYN并回复了SYN-ACK但没收到ACK问题可能在服务器到客户端的路径或者客户端问题。6.2 内核参数调优思路对于高性能服务器针对TCP连接管理的内核调优是必不可少的。这里提供一些常见参数的调优思路修改前请务必理解其含义并在测试环境验证。net.ipv4.tcp_syn_retries客户端SYN包的重试次数。默认是6意味着总超时时间可能长达127秒。对于内网或对延迟敏感的服务可以适当降低如设为2或3让失败连接快速超时。net.ipv4.tcp_synack_retries服务器SYN-ACK包的重试次数。类似地可以调整以控制半连接存活时间。net.ipv4.tcp_max_syn_backlog增大半连接队列大小以抵御轻微的SYN Flood或应对突发连接。net.core.somaxconn应用程序backlog增大全连接队列大小防止连接被丢弃。确保应用程序如Nginx的listen指令的backlog参数和系统参数都进行了调整。net.ipv4.tcp_tw_reuse对于出向连接客户端角色允许重用处于TIME_WAIT状态的Socket。对于负载均衡器、代理服务器等大量主动出向短连接的场景开启此选项设置为1可以缓解端口压力。net.ipv4.tcp_fin_timeout调整FIN-WAIT-2状态的超时时间实际上TIME_WAIT的2MSL也受此影响这里需要注意在Linux中tcp_fin_timeout控制的是FIN-WAIT-2状态的超时而TIME_WAIT的超时是固定的2MSL由TCP_TIMEWAIT_LEN定义通常不可直接调节。减少此值可以加快释放资源但可能影响连接终止的可靠性。调优黄金法则监控先行。使用netstat,ss,/proc/net/netstat等工具持续监控连接状态分布、重传率、队列溢出计数等指标再根据实际瓶颈进行有针对性的调整而不是盲目套用“优化清单”。我个人在管理高并发服务时会特别关注ss -s命令输出的TCP:段信息尤其是timewait和orphaned孤立的、未关联到任何进程的TIME_WAIT的数量以及netstat -s中关于times listen queue overflowed全连接队列溢出和SYNs to LISTEN sockets dropped半连接队列溢出的计数。这些数字是连接层健康度的晴雨表。