一句话概括：TCP 就像寄快递时非要对方"签收确认"的顺丰特快——每一个包裹都要编号、都要对方回执确认收到，丢了就重发，乱了就重排——这份"偏执"的背后，是一整套精妙的工程设计。这篇文章会带你从三次握手讲到粘包处理，再到 C# 实战，把 TCP 这个几乎撑起整个互联网的协议，彻底讲透。
目录
- TCP 是什么，它在网络世界里扮演什么角色
- 三次握手：一场严谨的"确认仪式"
- 四次挥手：为什么分手比相识更麻烦
- TCP 如何做到"可靠"：确认应答、超时重传、滑动窗口
- TCP vs UDP：可靠与效率的权衡
- 粘包与拆包：TCP 应用开发绕不开的坑
- C# 实战：用 TcpListener / TcpClient 搭建一个简易聊天服务器
- 实战演练：设计一个带长度前缀的应用层协议，彻底解决粘包
- 高手都会踩的 6 个坑
- 写在最后 & 课后练习
一、TCP 是什么，它在网络世界里扮演什么角色
1.1 一个生活化的类比
打电话和写信，是两种完全不同的沟通方式：
- 打电话：拨通之后，双方要先"喂喂喂"确认对方在线，通话过程中持续保持连接，说完之后还要说"拜拜"挂断——这就是 TCP。
- 写信：直接把信投进邮筒，不管对方在不在家，也不确认对方收没收到——这就是 UDP（我们会在第五节详细对比）。
1.2 TCP 的官方定义
TCP（Transmission Control Protocol，传输控制协议）：一种面向连接、可靠的、基于字节流的传输层协议。
这句定义里藏着三个关键词，也是理解 TCP 的三把钥匙：
| 关键词 | 含义 |
|---|---|
| 面向连接 | 通信前必须先"建立连接"（三次握手），通信结束后要"释放连接"（四次挥手） |
| 可靠 | 保证数据不丢失、不重复、按顺序到达，出问题会自动重传 |
| 字节流 | 数据被当作一串连续的字节来传输，没有天然的"消息边界"（这一点会在第六节引发大问题） |
1.3 为什么 TCP 如此重要
你每天打开的网页（HTTP/HTTPS）、发送的邮件（SMTP）、上传下载的文件（FTP）、远程登录服务器（SSH）……几乎所有对"数据完整性"有要求的互联网应用，底层都跑在 TCP 之上。可以说，TCP 是支撑起现代互联网可靠性的基石之一，理解它，是每一个后端、网络编程、分布式系统方向的程序员必须迈过的门槛。
二、三次握手：一场严谨的"确认仪式"
2.1 为什么要"握手"？
在正式收发数据之前，TCP 需要先确认一件事：通信双方确实都准备好了，而且这条网络链路确实是通的。这个确认过程，就是大名鼎鼎的"三次握手（Three-way Handshake）"。
2.2 握手全过程图解
客户端(Client) 服务端(Server) │ │ │ 状态: CLOSED 状态: LISTEN（正在监听） │ │ │──── 第1次：SYN(seq=x) ───────────────►│ "我要建立连接，我的初始序号是x" │ 状态: SYN_SENT │ │ │ 状态: SYN_RCVD │◄─── 第2次：SYN(seq=y), ACK(x+1) ───────│ "收到，我也同意，我的初始序号是y， │ │ 并确认收到了你的x号" │ 状态: ESTABLISHED │ │ │ │──── 第3次：ACK(y+1) ──────────────────►│ "收到，确认收到你的y号" │ │ 状态: ESTABLISHED │ │ │ ✅ 连接建立完成，可以开始收发数据了 │2.3 为什么必须是"三次"，两次不行吗？
这是面试中被问到烂的经典问题，我们用反证法来理解：
如果只握手两次会怎样？
客户端 ──── SYN ────► 服务端 客户端 ◄─── SYN+ACK ── 服务端 （如果到这里就算连接建立完成……）问题出在：服务端无法确认"客户端有没有真的收到自己的响应"。想象一种极端情况：客户端发出的第一个 SYN 因为网络延迟，在"半路上滞留"了很久很久，客户端等不及超时重发了一次，新的 SYN 顺利建立了连接并完成了数据传输。这时候，那个"迟到"的旧 SYN 才姗姗来迟地到达服务端——如果只有两次握手，服务端收到这个过期的 SYN 后，会误以为客户端又要建立一个新连接，直接进入"已建立"状态并傻等客户端发数据，但客户端压根不知道这回事，导致服务端的资源被白白浪费（这就是所谓的"已失效的连接请求报文段"问题）。
第三次握手（客户端发送 ACK）的意义就在于：它让服务端能够确认"客户端确实收到了我的响应，这是一次真实、双方都认可的连接请求"，从而避免了资源被过期请求错误占用的问题。
2.4 序号（Sequence Number）的作用
握手过程中双方交换的seq（序号），并不是简单的"1、2、3"计数，而是各自随机生成的初始值，之后每传输一个字节，序号就递增1。这套序号机制正是 TCP 实现"数据按顺序到达、丢失可检测、重复可去除"的核心基础，我们在第四节会看到它如何发挥作用。
三、四次挥手：为什么分手比相识更麻烦
3.1 挥手全过程图解
客户端(Client) 服务端(Server) │ │ │──── 第1次：FIN ───────────────────────►│ "我这边数据发完了，准备关闭" │ 状态: FIN_WAIT_1 │ │◄─── 第2次：ACK ────────────────────────│ "收到，稍等，我这边可能还有数据没发完" │ 状态: FIN_WAIT_2 │ 状态: CLOSE_WAIT │ │ （服务端继续发送剩余数据……） │ │ │◄─── 第3次：FIN ────────────────────────│ "我这边也发完了，可以关闭了" │ 状态: TIME_WAIT │ 状态: LAST_ACK │──── 第4次：ACK ───────────────────────►│ "收到，确认关闭" │ │ 状态: CLOSED │ （等待2倍最大报文段生存时间后） │ │ 状态: CLOSED │3.2 为什么挥手需要四次，而握手只要三次？
核心原因：TCP 连接是全双工的（双向都能独立发送数据），关闭连接时，两个方向必须分别关闭。
握手时，服务端收到 SYN 后，"同意连接"和"确认收到"这两件事可以合并在同一个 ACK+SYN 包里一起发出去，所以能压缩成三次。
而挥手时：客户端说"我发完了"（FIN），服务端只能先回复"知道了"（ACK）——但这不代表服务端自己也发完了，它可能还有数据要继续发送给客户端。所以服务端的"确认收到"和"我也要关闭了"这两个动作，通常无法合并在一起发送，必须分成两步——这正是挥手比握手多一次的根本原因。
3.3TIME_WAIT状态：客户端为什么要"多等一会儿"
细心的你可能发现，客户端在发送完最后一个 ACK 后，并没有立刻进入CLOSED状态，而是先进入了一个叫TIME_WAIT的状态，等待 2 倍的"最大报文段生存时间（2MSL）"之后，才真正关闭。这么设计有两个重要原因：
- 确保最后一个 ACK 能够到达服务端。如果这个 ACK 在网络中丢失了，服务端会因为没收到确认而超时重传 FIN，客户端此时如果还处于
TIME_WAIT状态，就能重新收到这个 FIN 并再发一次 ACK；但如果客户端已经直接关闭了，就没法响应这次重传，服务端会一直卡在等待关闭的状态。 - 防止"已失效的连接请求"污染后续的新连接。等待足够长的时间，能确保这次连接中所有滞留在网络里的旧数据包都已经消散，不会在未来"复用同一个端口号"建立新连接时，被误认为是新连接的数据。
四、TCP 如何做到"可靠"：确认应答、超时重传、滑动窗口
4.1 确认应答（ACK）机制：一收一答的"回执"
TCP 发送的每一个数据段，都带有一个序号；接收方每收到一段数据，都会回复一个 ACK，告诉发送方"我已经成功收到了截止到哪个序号的数据"。
发送方 ──── 数据段(seq=1, 100字节) ────► 接收方 发送方 ◄──── ACK(ack=101) ───────────── 接收方 "我收到了1~100，下次请从101开始发"如果发送方迟迟等不到 ACK，就会判断这段数据可能丢失了，于是重新发送一遍——这就是"超时重传（Retransmission Timeout）"机制。
4.2 超时重传：等多久才算"超时"？
这里有一个有趣的工程难题：超时时间设置太短，网络稍微一卡顿就误判为丢包、频繁重传，浪费带宽；设置太长，真正丢包时要等很久才会重发，影响传输效率。
TCP 的解决方案是动态计算——通过持续采样"发送数据到收到确认"之间的往返时间（RTT，Round-Trip Time），并结合网络抖动情况，自适应地调整超时时间，而不是用一个写死的固定值。这背后有一套叫做 Jacobson/Karels 算法的经典公式，本文不做展开，但理解"超时时间是动态计算出来的，而非固定值"这一点，能帮你理解为什么 TCP 在不同网络环境下表现出的"重传敏感度"会有明显差异。
4.3 滑动窗口：为什么不是"一发一答"，而是"批量发送"
如果每发一个数据段都要死等对方的 ACK 才能发下一个，在网络延迟较高的场景下，效率会低得令人发指（比如跨洋网络，一来一回可能就要几百毫秒）。
TCP 用"滑动窗口（Sliding Window）"机制解决了这个问题——发送方可以在收到确认之前，连续发送一批数据（窗口大小决定了这批数据有多少），接收方也可以累积确认一批数据，大幅提升了吞吐效率。
窗口大小 = 4个数据段： 第一轮：发送方连续发出 [1][2][3][4]（不需要等每一个都被确认） 接收方陆续收到后，回复累积确认 ACK(5)（表示1~4都收到了） 第二轮：窗口"向前滑动"，发送方继续发 [5][6][7][8] ……如此循环，持续向前推进滑动窗口的大小并不是固定的——接收方会根据自己的处理能力和缓冲区空闲情况，动态告知发送方"你还能再发多少"（这个值会包含在 ACK 报文的"窗口大小"字段中），这就是所谓的"流量控制（Flow Control）"，用来防止发送方发得太快，压垮接收方。
4.4 拥塞控制：TCP 对"整个网络"的责任感
除了照顾接收方，TCP 还会照顾整个网络链路的拥堵状况——如果连续出现丢包，TCP 会判断"网络可能拥堵了"，主动大幅降低自己的发送速度（经典的"慢启动 + 拥塞避免"算法），等网络状况好转后再逐渐提速。这是一种非常"讲道理"的设计——TCP 不会因为"我要传得快"就不顾一切地疯狂发送数据，而是会主动为整个共享网络的健康状况让路，这也是为什么互联网在极高的并发流量下依然能保持相对稳定运行的重要原因之一。
五、TCP vs UDP：可靠与效率的权衡
| 对比维度 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手/四次挥手） | 无连接，直接发送 |
| 可靠性 | 可靠（确认、重传、排序、去重） | 不可靠（发出去就不管了） |
| 传输方式 | 字节流 | 数据报（每次发送有明确的消息边界） |
| 速度 | 相对较慢（握手、确认机制带来额外开销） | 更快（没有这些额外开销） |
| 适用场景 | 文件传输、网页浏览、邮件——任何不能丢数据的场景 | 视频直播、语音通话、DNS查询——能容忍少量丢失，但追求实时性的场景 |
一个很多人会问的问题：“视频通话丢一点数据不是很影响体验吗，为什么还用 UDP？”答案是：对于实时音视频而言，"迟到的数据"比"丢失的数据"危害更大——如果用 TCP，一旦某个数据包丢失，TCP 会执着地等待重传、并且会阻塞后续所有数据的处理（保证顺序），这会导致画面/声音卡顿甚至冻结；而 UDP 丢了就丢了，直接跳过继续播放下一帧，用户感知到的可能只是一瞬间的轻微花屏或杂音，而不是长达几秒的卡死——这正是"可靠"未必总是"更好"的经典案例，技术选型的核心永远是"权衡"，而不是"哪个更先进"。
六、粘包与拆包：TCP 应用开发绕不开的坑
6.1 问题的根源：TCP 是"字节流"，没有消息边界
回到第一节强调的关键词——TCP 传输的是一串连续的字节流，它完全不知道、也不关心"应用层认为一条消息应该在哪里结束"。
应用层发送方连续调用了两次 Send： Send("Hello") Send("World") 但 TCP 底层可能把它们合并成一次传输： 接收方 Receive() 一次性收到 "HelloWorld" ← 这就是"粘包" 或者反过来，一条消息被拆成了好几次到达： Send("HelloWorld，这是一条较长的消息") 接收方可能分三次才收全： 第一次 Receive() 收到 "HelloWo" 第二次 Receive() 收到 "rld，这是一" 第三次 Receive() 收到 "条较长的消息" ← 这就是"拆包"这不是 bug，而是 TCP 协议本身"面向字节流"这个设计特性的必然结果——TCP 只保证"字节按顺序、不丢失地到达"，至于这些字节该如何被"切分成一条一条有意义的消息"，完全是应用层自己的责任。
6.2 为什么很多新手完全没意识到这个问题？
因为在本地测试、小数据量、网络状况良好的环境下，"一次 Send 恰好对应一次 Receive"的情况出现概率很高，很多程序在开发阶段"看起来工作正常"，却在真实生产环境（高并发、网络波动、大数据量）下突然出现"消息错乱"的诡异 bug——这正是粘包/拆包问题最容易被忽视、又最容易在生产环境"埋雷"的原因。任何严肃的 TCP 应用开发，都必须在应用层设计自己的协议来解决这个问题，我们会在第八节给出具体方案。
七、C# 实战：用 TcpListener / TcpClient 搭建一个简易聊天服务器
7.1 服务端代码
usingSystem;usingSystem.Net;usingSystem.Net.Sockets;usingSystem.Text;usingSystem.Threading.Tasks;classChatServer{staticasyncTaskMain(){TcpListenerlistener=newTcpListener(IPAddress.Any,9000);listener.Start();Console.WriteLine("服务器已启动，监听端口 9000……");while(true){// 异步等待客户端连接，不阻塞其他已连接客户端的处理TcpClientclient=awaitlistener.AcceptTcpClientAsync();Console.WriteLine($"客户端已连接：{client.Client.RemoteEndPoint}");// 每个客户端连接开一个独立任务处理，避免互相阻塞_=HandleClientAsync(client);}}staticasyncTaskHandleClientAsync(TcpClientclient){NetworkStreamstream=client.GetStream();byte[]buffer=newbyte[1024];try{while(true){intbytesRead=awaitstream.ReadAsync(buffer,0,buffer.Length);if(bytesRead==0)break;// 对方已关闭连接stringmessage=Encoding.UTF8.GetString(buffer,0,bytesRead);Console.WriteLine($"收到：{message}");// 简单回显stringresponse=$"服务器已收到：{message}";byte[]responseBytes=Encoding.UTF8.GetBytes(response);awaitstream.WriteAsync(responseBytes,0,responseBytes.Length);}}catch(Exceptionex){Console.WriteLine($"连接异常：{ex.Message}");}finally{client.Close();Console.WriteLine("客户端已断开");}}}7.2 客户端代码
usingSystem;usingSystem.Net.Sockets;usingSystem.Text;usingSystem.Threading.Tasks;classChatClient{staticasyncTaskMain(){usingTcpClientclient=newTcpClient();awaitclient.ConnectAsync("127.0.0.1",9000);Console.WriteLine("已连接到服务器");NetworkStreamstream=client.GetStream();while(true){Console.Write("请输入消息（输入 exit 退出）：");string?input=Console.ReadLine();if(input=="exit")break;byte[]data=Encoding.UTF8.GetBytes(input??"");awaitstream.WriteAsync(data,0,data.Length);byte[]buffer=newbyte[1024];intbytesRead=awaitstream.ReadAsync(buffer,0,buffer.Length);stringresponse=Encoding.UTF8.GetString(buffer,0,bytesRead);Console.WriteLine($"服务器回复：{response}");}}}这个基础版本能跑通"一发一收"的场景，但正如第六节所说，它完全没有处理粘包问题——一旦消息发送得又快又密集，或者消息内容较大超过缓冲区，就会出现数据错乱。下一节我们来彻底解决这个问题。
八、实战演练：设计一个带长度前缀的应用层协议，彻底解决粘包
8.1 核心思路：用"长度前缀"标注每条消息有多长
这是业界最经典、最通用的粘包解决方案——在每条消息正式内容之前，先用固定字节数（比如4字节）写入"这条消息总共有多长"，接收方先读取这个长度字段，再根据这个长度精确地读取对应数量的字节，就能准确地切分出一条条完整的消息，不管底层 TCP 把数据合并了多少次发送、或者拆成了多少次到达。
消息格式：[4字节长度前缀][消息内容] 发送 "Hello"（5字节）时，实际在线路上传输的是： [0x00, 0x00, 0x00, 0x05] + "Hello" └──────4字节长度值──────┘ └─内容─┘8.2 封装一个"按长度前缀收发消息"的工具类
usingSystem;usingSystem.IO;usingSystem.Net.Sockets;usingSystem.Text;usingSystem.Threading.Tasks;publicstaticclassMessageFramer{// 发送：自动加上4字节长度前缀publicstaticasyncTaskSendMessageAsync(NetworkStreamstream,stringmessage){byte[]contentBytes=Encoding.UTF8.GetBytes(message);byte[]lengthPrefix=BitConverter.GetBytes(contentBytes.Length);// 统一转换成大端字节序，避免不同机器架构下字节序不一致导致的解析错误if(BitConverter.IsLittleEndian)Array.Reverse(lengthPrefix);awaitstream.WriteAsync(lengthPrefix,0,4);awaitstream.WriteAsync(contentBytes,0,contentBytes.Length);}// 接收：先严格读满4字节拿到长度，再严格读满该长度的内容publicstaticasyncTask<string?>ReceiveMessageAsync(NetworkStreamstream){byte[]lengthPrefix=newbyte[4];if(!awaitReadExactAsync(stream,lengthPrefix,4))returnnull;// 对方已断开if(BitConverter.IsLittleEndian)Array.Reverse(lengthPrefix);intcontentLength=BitConverter.ToInt32(lengthPrefix,0);byte[]contentBytes=newbyte[contentLength];if(!awaitReadExactAsync(stream,contentBytes,contentLength))returnnull;returnEncoding.UTF8.GetString(contentBytes);}// 关键辅助方法：确保"读满"指定字节数，哪怕底层需要拆分成好几次 ReadAsync 才能读够staticasyncTask<bool>ReadExactAsync(NetworkStreamstream,byte[]buffer,intcount){inttotalRead=0;while(totalRead<count){intbytesRead=awaitstream.ReadAsync(buffer,totalRead,count-totalRead);if(bytesRead==0)returnfalse;// 连接已被对方关闭totalRead+=bytesRead;}returntrue;}}8.3 应用到聊天服务器中
// 服务端处理逻辑替换为：while(true){string?message=awaitMessageFramer.ReceiveMessageAsync(stream);if(message==null)break;// 客户端已断开Console.WriteLine($"收到完整消息：{message}");awaitMessageFramer.SendMessageAsync(stream,$"服务器已收到：{message}");}// 客户端发送逻辑替换为：awaitMessageFramer.SendMessageAsync(stream,input??"");string?response=awaitMessageFramer.ReceiveMessageAsync(stream);Console.WriteLine($"服务器回复：{response}");8.4 这个方案解决问题的核心在哪？
关键在于ReadExactAsync这个辅助方法——它不轻易相信"一次ReadAsync调用就能读到期望的所有字节"，而是用一个循环，持续读取，直到真正凑够了指定的字节数为止。这正是应对"拆包"问题的标准写法；而"长度前缀"本身，则从根本上解决了"粘包"问题——不管 TCP 底层怎么切分/合并数据包，只要严格按照"先读4字节长度、再按长度精确读取内容"这套规则来解析，就永远能准确无误地切分出一条条完整的消息。
除了长度前缀法，另一种常见方案是"特殊分隔符法"（比如用换行符
\n或者某个不会出现在正文中的特殊字符标记消息结束），HTTP 协议的请求头部分就是用\r\n作为分隔符的经典案例——但分隔符法有一个天然缺陷：如果消息内容本身可能包含分隔符字符（比如传输的是二进制文件数据），就必须做转义处理，反而更复杂。因此在传输二进制数据、或者对性能有较高要求的场景下，长度前缀法通常是更稳妥、更通用的选择。
九、高手都会踩的 6 个坑
坑 1：以为"一次 Send 对应一次 Receive"
这是本文反复强调的核心坑，再次总结：永远不要假设发送方调用几次Write/Send，接收方就会对应触发几次Read/Receive——TCP 完全不保证这种对应关系，必须在应用层自己设计协议来界定消息边界。
坑 2：忘记处理Read返回 0 的情况
intbytesRead=awaitstream.ReadAsync(buffer,0,buffer.Length);// ❌ 如果没有判断 bytesRead == 0，continue 循环读取时会陷入死循环，疯狂占用CPU！当Read/ReadAsync返回0时，意味着对方已经正常关闭了连接（而不是"暂时没有数据"）——必须显式判断这种情况并跳出循环，否则会导致程序在一个已经断开的连接上持续空转，白白消耗大量 CPU 资源。
坑 3：主线程直接用同步 API 处理多个客户端，导致阻塞
// ❌ 反面教材：用同步方式在主线程里一个个"死等"处理客户端，第二个客户端永远排不上号while(true){TcpClientclient=listener.AcceptTcpClient();// 同步阻塞HandleClient(client);// 同步阻塞，处理完一个才能接下一个}真实的 TCP 服务器必须支持"同时处理多个客户端连接"，本文第七节的示例中用了async/await+ "每个连接单独起一个 Task"的方式来解决——这是现代 C# 网络编程处理高并发连接的标准范式，比传统的"每个连接开一个线程"更节省系统资源。
坑 4：字节序（大端/小端）不一致导致的数据解析错误
// ⚠️ 危险：不同架构的机器，int 转 byte[] 时字节顺序可能不同byte[]lengthBytes=BitConverter.GetBytes(1000);// 在小端机器上是一种顺序，大端机器上是相反顺序网络传输的惯例是使用"大端序（Big-Endian，也叫网络字节序）"，而大部分常见的桌面/服务器 CPU（x86、x64）内部使用的是"小端序（Little-Endian）"——如果通信双方对字节序的处理方式不统一，同样的字节数据会被解析成完全不同的数值。第八节代码中if (BitConverter.IsLittleEndian) Array.Reverse(...)这一步，正是在显式处理这个容易被忽视的兼容性问题。
坑 5：TcpClient/NetworkStream没有正确释放，导致端口/连接资源耗尽
// ❌ 没有用 using，异常发生时资源可能得不到释放TcpClientclient=newTcpClient();client.Connect(host,port);// ……如果这里抛异常，client 永远不会被 Dispose// ✅ 用 using 语句，确保无论是否异常都会正确释放usingTcpClientclient=newTcpClient();client.Connect(host,port);长期运行的服务在高并发场景下，如果每次都"忘记释放"连接资源，很容易在压力测试或生产环境中遭遇"端口耗尽"或者"连接数超限"的严重故障。
坑 6：把 TCP 的"可靠"误解为"实时"或"绝对不丢消息"
TCP 保证的是**“如果连接没有中断，数据最终一定会按顺序、完整地到达”，但它并不保证"传输速度很快"，也不能防止"应用层逻辑本身的消息丢失"**（比如服务器进程崩溃、还没来得及处理完缓冲区里的数据）。真正对可靠性要求极高的业务场景（比如金融交易），通常还需要在应用层叠加"业务确认机制"（比如客户端收到服务端明确的业务处理成功回执后，才认为这笔操作真正完成），不能盲目迷信"用了 TCP 就绝对万无一失"。
十、写在最后
TCP 之所以能撑起大半个互联网的可靠通信，靠的从来不是什么"黑科技"，而是一整套朴实但极其严谨的工程设计——三次握手确保双方"确实都在线"，序号和确认应答确保数据"不丢不乱"，滑动窗口和拥塞控制确保效率与网络健康的平衡，四次挥手确保连接"体面收场"。
而学习 TCP 最容易被忽视、却在实际工程中最容易"埋雷"的一课，恰恰是"粘包与拆包"——它提醒我们：TCP 保证的是"字节流"的可靠传输，而"消息"的边界，永远是应用层自己的责任。理解了这一点，你才算真正跨过了"会调用 Socket API"和"真正理解网络编程"之间的那道门槛。
📝 课后练习
- 尝试用 JSON 序列化替换第八节协议中的纯文本消息体，设计一个更贴近真实业务的"长度前缀 + JSON 内容"通信协议。
- 改造第七节的聊天服务器，支持"广播"功能——当任意一个客户端发送消息时，服务器把这条消息转发给所有其他在线的客户端。
- 思考题：如果客户端和服务器之间的网络突然断开（比如拔掉网线），双方各自的 TCP 连接状态会发生什么变化？程序应该如何检测到这种"异常断连"，而不是傻等一个永远不会到来的响应？
觉得有收获？欢迎点赞收藏，下次面试官再问"讲讲三次握手为什么不能是两次"，你已经能从"失效连接请求"的角度，讲得明明白白 😉
