最近复习《计算机网络》被 TCP 的三次握手和四次挥手虐了一个晚上。索性一咬牙把传输层这块从头到尾捋了一遍整理成这篇笔记。文章尽量用说人话的方式来讲配了不少简图希望和我一样正在被 TCP 折磨的同学看完能少掉几根头发。一、TCP 是个啥先搞清楚它在哪一层讲协议之前先定位。我们熟知的 TCP/IP 体系分为四层TCP 工作在传输层应用层 HTTP、FTP、SMTP、DNS…… 数据 ↓ 传输层 TCP / UDP TCP 报文段 ↓ 网络层 IP IP 数据报 ↓ 网络接口层 网卡、驱动程序 帧一句话总结TCP 是传输层的协议为应用层提供面向连接的、可靠的字节流服务。这里先拉一个对照组——UDP无连接、不可靠、但简单高效。TCP 的可靠不是白来的是靠后面要讲的一整套机制序号、确认应答、超时重传、连接管理换来的。这篇文章就围绕TCP 是怎么做到可靠的这条主线展开。二、TCP 报文段格式简单版TCP 是面向字节流的但在网络层看来它传输的数据是一个个报文段Segment。可以把报文段理解成一张快递单 货物前面是固定格式的头部快递单后面跟着数据货物。报文段头部字段一览挑重点的讲字段位数作用源端口16数据从哪个进程来目的端口16数据到哪个进程去序号 seq32本报文段第一个字节的编号确认号 ack32期望收到对方下一个字节的编号4 位首部长度4头部有多长单位是 4 字节最大 60 字节保留位6目前全为 0控制位6URG / ACK / PSH / RST / SYN / FIN窗口大小16告诉对方我这边还能收多少流量控制用校验和16检验报文段是否损坏紧急指针16配合 URG 使用用一张图看整体结构0 3 4 7 8 15 31 位 ------------------------------------------------------------ | 源端口16 bit | 目的端口16 bit | ------------------------------------------------------------ | 序号 seq32 bit | ------------------------------------------------------------ | 确认号 ack32 bit | ------------------------------------------------------------ | 4位首部长度 | 保留6位 |U|A|P|R|S|F| 窗口大小16 bit | ------------------------------------------------------------ | 校验和16 bit | 紧急指针16 bit | ------------------------------------------------------------ | 选项长度可变如 MSS | ------------------------------------------------------------ | 数据可以没有 | ------------------------------------------------------------控制位只重点记这四个6 个控制位里面试和学习中最常用的是下面四个先记住它们标志位全称含义ACKAcknowledgment确认标志位。为 1 时确认号字段才有效SYNSynchronize请求建立连接的标志位FINFinish请求释放连接的标志位我说完了RSTReset重置连接。连接出现严重错误时强制断开重新来另外两个一笔带过URG紧急指针有效、PSH推送尽快把数据交给应用层了解即可。敲黑板报文格式不用死记硬背记住端口 序号 确认号 控制位这条主干剩下的字段用到再查。三、确认应答你发货我回执TCP 可靠传输的第一块基石是确认应答机制。思想非常朴素发送方每发一段数据接收方收到后要回一个我收到了ACK发送方确认对方收到了才继续放心发后面的数据。这里就要用到头部里的序号 seq和确认号 ack了它们的含义是seq本报文段中数据的第一个字节在整个字节流中的编号ack期望收到对方下一个字节的编号同时隐含ack 之前的字节我都正确收到了。看个例子客户端 服务端 seq 1发送 100 字节数据 ─────────▶ 收到数据校验无误 ◀───────── ACK 1ack 101 含义101 之前的我都收到啦 seq 101继续发下一段……注意上图中 ack 101 的含义不是我收到了编号 101而是我已经收到 100 号为止的数据下次请从 101 开始发。这个细节刚开始学特别容易搞混多品两遍。有了确认应答发送方就能知道哪段数据对方确实收到了。但问题来了如果数据包在路上丢了呢四、超时重传发货丢了怎么办网络是不靠谱的数据包可能丢失。TCP 的对策是发送方发出数据后启动一个超时计时器如果在规定时间内没收到对应的 ACK就重新发送这段数据。这就是超时重传。丢包分两种情况情况一数据包本身丢了。客户端 服务端 发送 seq 1 ~ 100 ──── ╳ ────▶ 数据包在路上丢失 启动超时计时器 等待中…… ⏰ 超时没等到 ack 101 重发 seq 1 ~ 100 ─────────▶ ACK 1ack 101情况二数据到了但 ACK 回执丢了。这种情况下接收方其实已经收到了数据。当发送方超时重发时接收方会发现这段数据我见过通过序号判断于是丢弃重复的数据并重新发一次 ACK。所以接收方也有一套去重机制重传不会导致数据重复堆积。敲黑板超时时间不是固定值TCP 会持续测量数据包的往返时间RTT动态调整超时阈值——网络快就少等会儿网络慢就多等会儿。具体算法如 Jacobson 算法了解思路即可不用记公式。到这一步可靠传输的两个核心手段——确认应答和超时重传——就都登场了。但只有这两样还不够传输之前总得先确认对方在不在、通不通。这就引出了 TCP 最经典的环节——连接管理。五、连接管理重点TCP 是面向连接的协议正式传数据之前要先打电话确认双方都在建立连接传完了要说再见挂电话释放连接。前者叫三次握手后者叫四次挥手。5.1 三次握手过程图解假设客户端主动发起连接服务端在 80 端口监听客户端CLOSED 服务端LISTEN ① SYN 1seq x ─────────▶ 客户端状态CLOSED → SYN_SENT ◀───────── ② SYN 1ACK 1 seq yack x 1 服务端状态LISTEN → SYN_RCVD ③ ACK 1seq x 1 ─────────▶ ack y 1 客户端状态SYN_SENT → ESTABLISHED 服务端状态SYN_RCVD → ESTABLISHED三次报文走完双方进入ESTABLISHED已建立连接状态可以开始互相传数据了。每一步在干嘛第一次握手客户端把SYN置 1、随机生成一个初始序号seq x发给服务端相当于说我想跟你建立连接我的数据从 x 开始编号。发完进入SYN_SENT状态。第二次握手服务端收到后如果同意建立连接就回一个SYN 1, ACK 1的报文SYN表示我也想跟你连接我的序号是 yACK x 1表示你的请求我收到了。之后服务端进入SYN_RCVD状态半连接状态。第三次握手客户端回一个ACK 1, ack y 1表示你的建立请求我也收到了。双方正式进入ESTABLISHED。这里有两个常见小疑问顺手解答Q1seq x 为什么是随机的初始序号ISN随机生成是为了防止网络中滞留的、上一个旧连接的报文段被新连接误收。如果序号从固定值开始历史残留报文就可能混进新连接造成数据错乱。Q2为什么握手是三次不是两次这是面试高频题分两个角度回答两次无法可靠确认双方的收发能力。TCP 是全双工的连接建立后双方都要能收能发。三次是确认双方收发能力都正常的最小次数第一次服务端确认客户端能发、我能收第二次客户端确认服务端能收能发、我也能发第三次服务端确认客户端能收。 只有三次双方才能都确认彼此的收发通道是通的。两次无法防止历史重复连接造成错误。设想客户端发的第一个 SYN 在网络里滞留了客户端超时后重发 SYN 并正常完成传输、关闭了连接这时那个滞留的旧 SYN 才到达服务端。如果是两次握手服务端收到 SYN 就直接建立连接、干等客户端发数据——但客户端早就走了这个连接就白占着资源。而三次握手中服务端必须再等客户端回最后一次 ACK 才算建立滞留在历史洪流里的旧 SYN 就不会被将错就错地接受。敲黑板记住这个比喻——两次握手就像你打电话喊了一句喂没听到对方回应就开始自说自话三次握手中双方都确认了对方既在听也能说通话才算真正建立。三次握手状态迁移图客户端 服务端 ┌───────┐ ┌─────────┐ │CLOSED │ │ CLOSED │ └───┬───┘ ① SYN1, seqx └────┬────┘ │ ─────────────────────────────────────────────▶ │ 服务端 listen ▼ ▼ ┌──────────┐ ┌──────────┐ │SYN_SENT │ │ LISTEN │ └────┬─────┘ ◀───────────────────────────── └────┬─────┘ │ ② SYN1, ACK1, ackx1 │ │ ▼ │ ┌──────────┐ │ │SYN_RCVD │ │ ③ ACK1, acky1 └────┬─────┘ │ ───────────────────────────────────────────▶ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ESTABLISHED │ ◀────────────────────────▶ │ESTABLISHED │ └──────────────┘ 双方开始正常传输数据 └────────────────┘5.2 四次挥手数据传完了要断开连接。TCP 是全双工的两个方向的数据通道要各自关闭所以断开需要四次报文俗称四次挥手。以客户端主动关闭为例过程图解客户端ESTABLISHED 服务端ESTABLISHED ① FIN 1seq u ─────────▶ 客户端状态ESTABLISHED → FIN_WAIT_1 ◀───────── ② ACK 1ack u 1 服务端状态ESTABLISHED → CLOSE_WAIT 客户端状态FIN_WAIT_1 → FIN_WAIT_2 服务端可能还有数据没发完继续发……发完了才能告别 ④ ACK 1ack w 1 ─────────▶ ③ FIN 1ACK 1 客户端状态TIME_WAIT等待 2MSL seq wack u 1 之后 → CLOSED 服务端状态CLOSE_WAIT → LAST_ACK 收到④后 → CLOSED每一步在干嘛第一次挥手客户端数据发完了发一个FIN 1的报文我没话说了进入FIN_WAIT_1状态。注意此时客户端只是不再发数据还能收。第二次挥手服务端收到 FIN回一个 ACK知道了进入CLOSE_WAIT状态。此时客户端进入FIN_WAIT_2。这个状态很关键服务端进入 CLOSE_WAIT 说明它还有数据要发——如果服务端一直停在 CLOSE_WAIT 不往前走通常意味着服务端还有数据没发完或者代码没正常关闭连接。第三次挥手服务端把剩下的数据发完也发一个FIN 1我也说完了进入LAST_ACK状态。第四次挥手客户端回最后一个 ACK然后进入TIME_WAIT状态等2MSL时间后才进入CLOSED。服务端收到这个 ACK 后直接CLOSED。为什么挥手是四次握手却是三次因为握手时服务端对请求建立连接的回应SYN和确认收到你的 SYNACK可以合并成一个报文SYN ACK 一起发所以三次就够。而挥手时被动关闭方收到 FIN 后往往还有数据要发只能先回一个 ACK我知道了但我还没说完等数据发完才能发自己的 FIN。ACK 和 FIN 没法合并所以是四次。TIME_WAIT 为什么要等 2MSLMSLMaximum Segment Lifetime是报文在网络中的最大存活时间。TIME_WAIT 等 2MSL 有两个原因保证最后一个 ACK 能被对方收到。如果这最后一个 ACK 丢了服务端会重发自己的 FIN客户端在 TIME_WAIT 期间还能收到并重新回 ACK。如果客户端发完 ACK 立刻 CLOSED服务端就会一直重发 FIN 无法正常关闭。让旧连接的报文彻底消散。等待 2MSL 后本次连接产生的所有报文都从网络中消失了防止这些迟到的报文被下一个使用相同端口的新连接误收。敲黑板面试常追问服务器出现大量 TIME_WAIT 怎么办——TIME_WAIT 出现在主动关闭连接的一方。对主动关闭的服务器如短连接 HTTP 服务可以用长连接keep-alive减少关闭次数或调整内核参数如tcp_tw_reuse复用 TIME_WAIT 连接。点到为止原理理解了参数用到再查。四次挥手状态迁移图客户端 服务端┌──────────────┐ ┌──────────────┐│ESTABLISHED │ │ESTABLISHED │└──────┬───────┘ └──────┬───────┘│ ① FIN1, sequ │▼ ▼┌──────────────┐ ② ACK1, acku1 ┌──────────────┐│ FIN_WAIT_1 │ ◀────────────────────── │ CLOSE_WAIT │└──────┬───────┘ └──────┬───────┘│ │ ③ FIN1, ACK1▼ ▼ 数据发完后┌──────────────┐ ┌──────────────┐│ FIN_WAIT_2 │ ④ ACK1, ackw1 ──▶ │ LAST_ACK │└──────┬───────┘ └──────┬───────┘│ │▼ ▼┌──────────────┐ 收到④ ┌──────────────┐│ TIME_WAIT │ ────────────────────────▶ │ CLOSED ││ 等2MSL │ └──────────────┘│▼┌──────────────┐│ CLOSED │└──────────────┘六、TCP 的特点总结最后把 TCP 的各个特点集中梳理一遍方便收藏复习特点说明面向连接传输数据前先三次握手建立连接传完四次挥手释放连接可靠传输确认应答 超时重传 序号去重 校验和保证数据不丢、不重、不错字节流数据像水流一样传输没有消息边界发送方写几次、接收方读几次不一定对应需要应用层自己处理粘包全双工通信连接双方可同时收发数据两个方向独立关闭点对点一对一通信不支持广播和多播UDP 可以流量控制通过滑动窗口接收方用窗口大小字段告诉发送方自己还能收多少防止发太快把接收方淹没拥塞控制感知网络拥堵程度动态调整发送速率慢启动、拥塞避免、快重传、快恢复流量控制和拥控制粗看很像区别在于流量控制解决的是接收方收不过来——点对点照顾你一个人拥塞控制解决的是网络堵车了——全局视角别把互联网搞崩。七、写在最后学 TCP 最大的感受是它的每一个机制都不是凭空设计的而是在回答一个具体的问题——数据会丢确认应答 超时重传连接会乱三次握手 随机序号发太快流量控制 拥塞控制。带着它在解决什么问题的角度去学比死记硬背状态图舒服得多。最后给个实操建议下载一个 Wireshark随便访问一个 HTTP 网站过滤tcp亲眼看一次三次握手和四次挥手的报文。当你在屏幕上指着说这个是 SYN这个是 FIN的时候TCP 就算真正入门了。如果这篇文章对你有帮助欢迎点赞收藏评论交流咱们一起进步
最近复习《计算机网络》被 TCP 的三次握手和四次挥手虐了一个晚上。索性一咬牙把传输层这块从头到尾捋了一遍整理成这篇笔记。文章尽量用说人话的方式来讲配了不少简图希望和我一样正在被 TCP 折磨的同学看完能少掉几根头发。一、TCP 是个啥先搞清楚它在哪一层讲协议之前先定位。我们熟知的 TCP/IP 体系分为四层TCP 工作在传输层应用层 HTTP、FTP、SMTP、DNS…… 数据 ↓ 传输层 TCP / UDP TCP 报文段 ↓ 网络层 IP IP 数据报 ↓ 网络接口层 网卡、驱动程序 帧一句话总结TCP 是传输层的协议为应用层提供面向连接的、可靠的字节流服务。这里先拉一个对照组——UDP无连接、不可靠、但简单高效。TCP 的可靠不是白来的是靠后面要讲的一整套机制序号、确认应答、超时重传、连接管理换来的。这篇文章就围绕TCP 是怎么做到可靠的这条主线展开。二、TCP 报文段格式简单版TCP 是面向字节流的但在网络层看来它传输的数据是一个个报文段Segment。可以把报文段理解成一张快递单 货物前面是固定格式的头部快递单后面跟着数据货物。报文段头部字段一览挑重点的讲字段位数作用源端口16数据从哪个进程来目的端口16数据到哪个进程去序号 seq32本报文段第一个字节的编号确认号 ack32期望收到对方下一个字节的编号4 位首部长度4头部有多长单位是 4 字节最大 60 字节保留位6目前全为 0控制位6URG / ACK / PSH / RST / SYN / FIN窗口大小16告诉对方我这边还能收多少流量控制用校验和16检验报文段是否损坏紧急指针16配合 URG 使用用一张图看整体结构0 3 4 7 8 15 31 位 ------------------------------------------------------------ | 源端口16 bit | 目的端口16 bit | ------------------------------------------------------------ | 序号 seq32 bit | ------------------------------------------------------------ | 确认号 ack32 bit | ------------------------------------------------------------ | 4位首部长度 | 保留6位 |U|A|P|R|S|F| 窗口大小16 bit | ------------------------------------------------------------ | 校验和16 bit | 紧急指针16 bit | ------------------------------------------------------------ | 选项长度可变如 MSS | ------------------------------------------------------------ | 数据可以没有 | ------------------------------------------------------------控制位只重点记这四个6 个控制位里面试和学习中最常用的是下面四个先记住它们标志位全称含义ACKAcknowledgment确认标志位。为 1 时确认号字段才有效SYNSynchronize请求建立连接的标志位FINFinish请求释放连接的标志位我说完了RSTReset重置连接。连接出现严重错误时强制断开重新来另外两个一笔带过URG紧急指针有效、PSH推送尽快把数据交给应用层了解即可。敲黑板报文格式不用死记硬背记住端口 序号 确认号 控制位这条主干剩下的字段用到再查。三、确认应答你发货我回执TCP 可靠传输的第一块基石是确认应答机制。思想非常朴素发送方每发一段数据接收方收到后要回一个我收到了ACK发送方确认对方收到了才继续放心发后面的数据。这里就要用到头部里的序号 seq和确认号 ack了它们的含义是seq本报文段中数据的第一个字节在整个字节流中的编号ack期望收到对方下一个字节的编号同时隐含ack 之前的字节我都正确收到了。看个例子客户端 服务端 seq 1发送 100 字节数据 ─────────▶ 收到数据校验无误 ◀───────── ACK 1ack 101 含义101 之前的我都收到啦 seq 101继续发下一段……注意上图中 ack 101 的含义不是我收到了编号 101而是我已经收到 100 号为止的数据下次请从 101 开始发。这个细节刚开始学特别容易搞混多品两遍。有了确认应答发送方就能知道哪段数据对方确实收到了。但问题来了如果数据包在路上丢了呢四、超时重传发货丢了怎么办网络是不靠谱的数据包可能丢失。TCP 的对策是发送方发出数据后启动一个超时计时器如果在规定时间内没收到对应的 ACK就重新发送这段数据。这就是超时重传。丢包分两种情况情况一数据包本身丢了。客户端 服务端 发送 seq 1 ~ 100 ──── ╳ ────▶ 数据包在路上丢失 启动超时计时器 等待中…… ⏰ 超时没等到 ack 101 重发 seq 1 ~ 100 ─────────▶ ACK 1ack 101情况二数据到了但 ACK 回执丢了。这种情况下接收方其实已经收到了数据。当发送方超时重发时接收方会发现这段数据我见过通过序号判断于是丢弃重复的数据并重新发一次 ACK。所以接收方也有一套去重机制重传不会导致数据重复堆积。敲黑板超时时间不是固定值TCP 会持续测量数据包的往返时间RTT动态调整超时阈值——网络快就少等会儿网络慢就多等会儿。具体算法如 Jacobson 算法了解思路即可不用记公式。到这一步可靠传输的两个核心手段——确认应答和超时重传——就都登场了。但只有这两样还不够传输之前总得先确认对方在不在、通不通。这就引出了 TCP 最经典的环节——连接管理。五、连接管理重点TCP 是面向连接的协议正式传数据之前要先打电话确认双方都在建立连接传完了要说再见挂电话释放连接。前者叫三次握手后者叫四次挥手。5.1 三次握手过程图解假设客户端主动发起连接服务端在 80 端口监听客户端CLOSED 服务端LISTEN ① SYN 1seq x ─────────▶ 客户端状态CLOSED → SYN_SENT ◀───────── ② SYN 1ACK 1 seq yack x 1 服务端状态LISTEN → SYN_RCVD ③ ACK 1seq x 1 ─────────▶ ack y 1 客户端状态SYN_SENT → ESTABLISHED 服务端状态SYN_RCVD → ESTABLISHED三次报文走完双方进入ESTABLISHED已建立连接状态可以开始互相传数据了。每一步在干嘛第一次握手客户端把SYN置 1、随机生成一个初始序号seq x发给服务端相当于说我想跟你建立连接我的数据从 x 开始编号。发完进入SYN_SENT状态。第二次握手服务端收到后如果同意建立连接就回一个SYN 1, ACK 1的报文SYN表示我也想跟你连接我的序号是 yACK x 1表示你的请求我收到了。之后服务端进入SYN_RCVD状态半连接状态。第三次握手客户端回一个ACK 1, ack y 1表示你的建立请求我也收到了。双方正式进入ESTABLISHED。这里有两个常见小疑问顺手解答Q1seq x 为什么是随机的初始序号ISN随机生成是为了防止网络中滞留的、上一个旧连接的报文段被新连接误收。如果序号从固定值开始历史残留报文就可能混进新连接造成数据错乱。Q2为什么握手是三次不是两次这是面试高频题分两个角度回答两次无法可靠确认双方的收发能力。TCP 是全双工的连接建立后双方都要能收能发。三次是确认双方收发能力都正常的最小次数第一次服务端确认客户端能发、我能收第二次客户端确认服务端能收能发、我也能发第三次服务端确认客户端能收。 只有三次双方才能都确认彼此的收发通道是通的。两次无法防止历史重复连接造成错误。设想客户端发的第一个 SYN 在网络里滞留了客户端超时后重发 SYN 并正常完成传输、关闭了连接这时那个滞留的旧 SYN 才到达服务端。如果是两次握手服务端收到 SYN 就直接建立连接、干等客户端发数据——但客户端早就走了这个连接就白占着资源。而三次握手中服务端必须再等客户端回最后一次 ACK 才算建立滞留在历史洪流里的旧 SYN 就不会被将错就错地接受。敲黑板记住这个比喻——两次握手就像你打电话喊了一句喂没听到对方回应就开始自说自话三次握手中双方都确认了对方既在听也能说通话才算真正建立。三次握手状态迁移图客户端 服务端 ┌───────┐ ┌─────────┐ │CLOSED │ │ CLOSED │ └───┬───┘ ① SYN1, seqx └────┬────┘ │ ─────────────────────────────────────────────▶ │ 服务端 listen ▼ ▼ ┌──────────┐ ┌──────────┐ │SYN_SENT │ │ LISTEN │ └────┬─────┘ ◀───────────────────────────── └────┬─────┘ │ ② SYN1, ACK1, ackx1 │ │ ▼ │ ┌──────────┐ │ │SYN_RCVD │ │ ③ ACK1, acky1 └────┬─────┘ │ ───────────────────────────────────────────▶ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ESTABLISHED │ ◀────────────────────────▶ │ESTABLISHED │ └──────────────┘ 双方开始正常传输数据 └────────────────┘5.2 四次挥手数据传完了要断开连接。TCP 是全双工的两个方向的数据通道要各自关闭所以断开需要四次报文俗称四次挥手。以客户端主动关闭为例过程图解客户端ESTABLISHED 服务端ESTABLISHED ① FIN 1seq u ─────────▶ 客户端状态ESTABLISHED → FIN_WAIT_1 ◀───────── ② ACK 1ack u 1 服务端状态ESTABLISHED → CLOSE_WAIT 客户端状态FIN_WAIT_1 → FIN_WAIT_2 服务端可能还有数据没发完继续发……发完了才能告别 ④ ACK 1ack w 1 ─────────▶ ③ FIN 1ACK 1 客户端状态TIME_WAIT等待 2MSL seq wack u 1 之后 → CLOSED 服务端状态CLOSE_WAIT → LAST_ACK 收到④后 → CLOSED每一步在干嘛第一次挥手客户端数据发完了发一个FIN 1的报文我没话说了进入FIN_WAIT_1状态。注意此时客户端只是不再发数据还能收。第二次挥手服务端收到 FIN回一个 ACK知道了进入CLOSE_WAIT状态。此时客户端进入FIN_WAIT_2。这个状态很关键服务端进入 CLOSE_WAIT 说明它还有数据要发——如果服务端一直停在 CLOSE_WAIT 不往前走通常意味着服务端还有数据没发完或者代码没正常关闭连接。第三次挥手服务端把剩下的数据发完也发一个FIN 1我也说完了进入LAST_ACK状态。第四次挥手客户端回最后一个 ACK然后进入TIME_WAIT状态等2MSL时间后才进入CLOSED。服务端收到这个 ACK 后直接CLOSED。为什么挥手是四次握手却是三次因为握手时服务端对请求建立连接的回应SYN和确认收到你的 SYNACK可以合并成一个报文SYN ACK 一起发所以三次就够。而挥手时被动关闭方收到 FIN 后往往还有数据要发只能先回一个 ACK我知道了但我还没说完等数据发完才能发自己的 FIN。ACK 和 FIN 没法合并所以是四次。TIME_WAIT 为什么要等 2MSLMSLMaximum Segment Lifetime是报文在网络中的最大存活时间。TIME_WAIT 等 2MSL 有两个原因保证最后一个 ACK 能被对方收到。如果这最后一个 ACK 丢了服务端会重发自己的 FIN客户端在 TIME_WAIT 期间还能收到并重新回 ACK。如果客户端发完 ACK 立刻 CLOSED服务端就会一直重发 FIN 无法正常关闭。让旧连接的报文彻底消散。等待 2MSL 后本次连接产生的所有报文都从网络中消失了防止这些迟到的报文被下一个使用相同端口的新连接误收。敲黑板面试常追问服务器出现大量 TIME_WAIT 怎么办——TIME_WAIT 出现在主动关闭连接的一方。对主动关闭的服务器如短连接 HTTP 服务可以用长连接keep-alive减少关闭次数或调整内核参数如tcp_tw_reuse复用 TIME_WAIT 连接。点到为止原理理解了参数用到再查。四次挥手状态迁移图客户端 服务端┌──────────────┐ ┌──────────────┐│ESTABLISHED │ │ESTABLISHED │└──────┬───────┘ └──────┬───────┘│ ① FIN1, sequ │▼ ▼┌──────────────┐ ② ACK1, acku1 ┌──────────────┐│ FIN_WAIT_1 │ ◀────────────────────── │ CLOSE_WAIT │└──────┬───────┘ └──────┬───────┘│ │ ③ FIN1, ACK1▼ ▼ 数据发完后┌──────────────┐ ┌──────────────┐│ FIN_WAIT_2 │ ④ ACK1, ackw1 ──▶ │ LAST_ACK │└──────┬───────┘ └──────┬───────┘│ │▼ ▼┌──────────────┐ 收到④ ┌──────────────┐│ TIME_WAIT │ ────────────────────────▶ │ CLOSED ││ 等2MSL │ └──────────────┘│▼┌──────────────┐│ CLOSED │└──────────────┘六、TCP 的特点总结最后把 TCP 的各个特点集中梳理一遍方便收藏复习特点说明面向连接传输数据前先三次握手建立连接传完四次挥手释放连接可靠传输确认应答 超时重传 序号去重 校验和保证数据不丢、不重、不错字节流数据像水流一样传输没有消息边界发送方写几次、接收方读几次不一定对应需要应用层自己处理粘包全双工通信连接双方可同时收发数据两个方向独立关闭点对点一对一通信不支持广播和多播UDP 可以流量控制通过滑动窗口接收方用窗口大小字段告诉发送方自己还能收多少防止发太快把接收方淹没拥塞控制感知网络拥堵程度动态调整发送速率慢启动、拥塞避免、快重传、快恢复流量控制和拥控制粗看很像区别在于流量控制解决的是接收方收不过来——点对点照顾你一个人拥塞控制解决的是网络堵车了——全局视角别把互联网搞崩。七、写在最后学 TCP 最大的感受是它的每一个机制都不是凭空设计的而是在回答一个具体的问题——数据会丢确认应答 超时重传连接会乱三次握手 随机序号发太快流量控制 拥塞控制。带着它在解决什么问题的角度去学比死记硬背状态图舒服得多。最后给个实操建议下载一个 Wireshark随便访问一个 HTTP 网站过滤tcp亲眼看一次三次握手和四次挥手的报文。当你在屏幕上指着说这个是 SYN这个是 FIN的时候TCP 就算真正入门了。如果这篇文章对你有帮助欢迎点赞收藏评论交流咱们一起进步
