TCP传输控制协议在面试中出现的评频率也很高为了自己的复习和帮助大家备战面试今天特别把TCP核心的知识点串起来过一遍。今天我从 TCP 是什么、优缺点、长什么样报文组成一路深挖到它的连接管理握手与挥手帮你建立起 TCP 体系结构一、 什么是 TCP如果把互联网比作一个庞大的物流系统IP 协议负责的是“根据地址把包裹从 A 运到 B”但 IP 协议是个“渣男”它只管发丢了不管乱序了也不管。这时候就需要TCP出马了。TCP 就像是一位负责的快递站点主管。它的官方定义是面向连接的、可靠的、基于字节流的传输层通信协议。面向连接送货前必须先打电话确认你在家建连送完货还要互相道别断开。可靠的保证包裹准时、按序、完整地送到。如果半路丢了他会自己回去重发。基于字节流它不管你发的是一段话还是一张图在它眼里都是一串连续的水流这也是导致“粘包”现象的根本原因。二、 TCP 的优缺点面试官问“既然 TCP 这么好为什么还要用 UDP”这时候你就要抛出它的优缺点了。优点绝对可靠不丢包、不重包、不乱序。流量/拥塞控制能根据接收方的消化能力滑动窗口和整个网络的拥堵情况拥塞控制算法动态调整自己的发送速度不会把网络搞瘫痪。缺点延迟高建立连接要 3 次握手断开要 4 次挥手。如果你只是想发一句“在吗”TCP 的前期沟通成本太高了。开销大为了保证可靠性TCP 头部最少有 20 个字节而 UDP 只有 8 个字节。队头阻塞因为必须按顺序交付如果前面的一个包丢了后面已经到达的包也得在缓冲区里干等着导致整个数据流卡住。三、 TCP 的组成在讲握手之前必须先看看 TCP 的“快递单”上写了什么。以下给出核心组成源端口 / 目的端口这是快递单上的收发件人告诉操作系统这个包该交给哪个应用程序比如 80 端口给 Nginx。序列号 (seq)给每个字节编的号。解决乱序和去重就靠它。确认号 (ack)告诉对方“这个序号之前的数据我都收到了下一个请发这个序号”。标志位 (Flags)核心状态开关SYN申请建立连接。ACK确认收到。FIN申请断开连接。RST连接出了大问题强制重置断开。窗口大小 (Window)告诉对方“我的仓库还能放下多少东西”这是流量控制的核心字段。四、 三次握手了解了头部结构我们来看看它们是怎么交互的。三次握手的核心目的是为了同步双方的初始序列号 (ISN)并确认双方的双向收发能力。1. 握手全流程与状态流转第一次握手 (SYN)客户端发送一个带有SYN1的报文并随机生成一个初始序列号seq x。此时客户端进入SYN_SENT状态。潜台词“我想和你建立连接我的数据起始编号是 x。”第二次握手 (SYN ACK)服务端收到请求后如果同意会回复一个SYN ACK报文。确认收到了客户端的序号ack x 1同时服务端也生成自己的初始序列号seq y。服务端进入SYN_RCVD状态。潜台词“收到你的 x 了。我也要和你建立连接我的起始编号是 y请确认。”第三次握手 (ACK)客户端回复一个ACK报文ack y 1。发送完毕客户端进入ESTABLISHED已建立状态。服务端收到后也进入ESTABLISHED状态。潜台词“收到你的 y 了。连接正式开启”2. 细节深挖为什么偏偏是 3 次2 次不行吗第一确认双向收发能力。TCP 是全双工的。一去客发服收、一回服发客收、再去客发服收刚好 3 次能验证双方的“发”和“收”功能都正常。第二防止“历史失效连接”浪费资源最核心。假设网络卡顿客户端发的旧 SYN 滞留了客户端超时后重发了新 SYN 并走完了流程。如果后来那个旧 SYN 突然到了服务端若是 2 次握手服务端一收到旧 SYN 就傻傻地建立连接浪费了内存和端口。若是 3 次握手服务端回了 SYN-ACK客户端收到一看“这确认号不对啊是我很久之前发的直接回一个 RST 报文把这个错误的连接掐死在摇篮里。3. 细节深挖SYN Flood 泛洪攻击如果第三次握手的 ACK 迟迟不来服务端会不断超时重传第二次握手包。黑客伪造海量假 IP疯狂发第一次握手SYN但不发第三次。这就导致服务端的半连接队列瞬间被塞满正常的请求根本进不来CPU 也会因为不断重发包而飙升最终导致服务雪崩。五、 优雅的离场四次挥手建立连接需要热情断开连接则需要耐心。断开连接的本质是双方都要单独关闭自己的“发送通道”。1. 挥手全流程与状态流转断开通常由客户端主动发起第一次挥手 (FIN)客户端数据发完了发送FIN报文seq u进入FIN_WAIT_1状态。潜台词“我没数据要发了我要关闭发送通道了”第二次挥手 (ACK)服务端收到 FIN立刻回复ACKack u 1进入CLOSE_WAIT状态。客户端收到后进入FIN_WAIT_2状态。潜台词“知道了。但我可能还有数据没发完你先别彻底挂断继续听我发。”此时是半关闭状态第三次挥手 (FIN)服务端把剩下的数据全发完了发送FIN报文seq v进入LAST_ACK状态。潜台词“我的数据也发完了现在我也要关闭发送通道了再见。”第四次挥手 (ACK)客户端收到 FIN回复ACKack v 1进入TIME_WAIT状态。服务端收到后立刻进入CLOSED状态。潜台词“我的数据也发完了现在我也要关闭发送通道了再见。”2. 细节深挖为什么握手是 3 次挥手却要 4 次握手时服务端是个全新的状态它可以把“确认收到 (ACK)”和“我也要连 (SYN)”合并在一个包里发所以 3 次搞定。挥手时服务端收到客户端的 FIN 时往往还有数据没处理完。它只能先回个 ACK 安抚对方等自己把活干完了再单独发一个 FIN。因为这中间存在“处理剩余数据的时间差”没法合并所以多出了一次。3.CLOSE_WAIT 与 TIME_WAIT最后拓展一下这两个状态是后端排查故障的常客CLOSE_WAIT被动方出现如果服务器上有一堆CLOSE_WAIT说明你的代码出 Bug 了它发生在服务端收到 FIN 回复 ACK 之后。一直卡在这说明你的应用程序迟迟没有调用close()方法释放资源比如数据库连接池泄露。TIME_WAIT主动方出现客户端发完最后一次 ACK 后必须等待2MSL最大报文生存时间的 2 倍约 1 分钟。为什么要等兜底重传万一最后那个 ACK 丢了服务端会重传 FIN。等 2MSL 是为了保证客户端还能收到重传的 FIN 并补发 ACK。清理战场让本次连接产生的所有报文在网络中自然消亡防止“旧报文”跑到下一个复用该端口的新连接里去捣乱。