TCP三次握手和四次挥手

目录

TCP 三次握手

TCP 四次挥手

其他问题

为什么建立连接是三次握手，断开连接是四次挥手？

为什么 TIME_WAIT 状态需要经过 2MSL 才能到 CLOSED 状态？

如果已经建立连接，但是客户端突然出现故障。

为什么不能是两次握手或者四次握手？

---

TCP 三次握手

第一次握手：客户端将 TCP 报文标志位 SYN 置为 1，随机产生一个值 seq = J，并将该数据包发送给服务器端，发送完毕后，客户端进入 SYN_SENT状态，等待服务器端确认。

第二次握手：服务器端接收到数据包后由标志位 SYN = 1 知道客户端请求建立连接，服务器端将 TCP 报文标志位 SYN 和 ACK 都置为 1，ack = J + 1，随机产生一个序号值 seq = K，并将该数据包发送给客户端已确认连接请求，服务器端进入 SYN_RCVD 状态。

第三次握手：客户端收到确认后检查 ack 是否为 J + 1，ACK 是否为 1，如果正确则将标志位 ACK 置为 1，ack = K + 1，并将该数据包发送给服务器端，服务器端检查 ack 是否为 K + 1，ACK 是否为 1，如果正确则连接建立成功，客户端和服务器端进入 ESTABLISHED 状态。

完成三次握手后，客户端与服务器端之间可以开始传输数据了。

ack 代表的是头部确认号，ACK 代表 TCP 首部的标志位。

TCP 四次挥手

第一次挥手：客户端发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN = 1，其序列号为 seq = u（等于前面已经传送过来的数据的最后一个字节的序号加 1），此时，客户端进入 FIN-WAIT-1 状态。 TCP 规定，FIN 报文段即使不携带数据，也要消耗一个序号。

第二次挥手：服务器收到连接释放报文，发出确认报文，ACK = 1，ack = u + 1，并且带上自己的序列号 seq = v，此时，服务端就进入了 CLOSE-WAIT 状态。TCP 服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个 CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后，此时，客户端就进入 FIN-WAIT-2 状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

第三次挥手：服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN = 1，

ack = u + 1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为

seq = w，此时，服务器就进入了 LAST-ACK 状态，等待客户端的确认。

第四次挥手：客户端收到服务器的连接释放报文后，必须发出确认，ACK = 1，ack = w + 1，而自己的序列号是 seq = u + 1，此时，客户端就进入了 TIME-WAIT 状态。注意此时 TCP 连接还没有释放，必须经过 2MSL（报文段最大生存时间） 时间后，当客户端撤销相应的 TCB 后，才进入 CLOSED 状态。服务器只要收到了客户端发出的确认，立即进入 CLOSED 状态。同样，撤销 TCB 后，就结束了这次的 TCP 连接。

可以看到，服务器结束 TCP 连接的时间要比客户端早一些。

其他问题

为什么建立连接是三次握手，断开连接是四次挥手？

建立连接时因为当服务器端收到客户端的 SYN 连接请求报文后，可以直接发送 SYN + ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。所以建立连接只需要三次握手。

由于 TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双工模式。
这就意味着，关闭连接时，当客户端发出 FIN 报文段时，只是表示客户端告诉服务器端数据已经发送完毕了。当服务器端收到 FIN 报文并返回 ACK 报文段，表示它已经知道客户端没有数据发送了，但是服务器端还是可以发送数据到客户端的，所以服务器端很可能并不会立即关闭，直到服务器端把数据也发送完毕。
当服务器端也发送了 FIN 报文段时，这个时候就表示服务器端也没有数据要发送了，就会告诉客户端，我也没有数据要发送了，之后就会中断这次TCP连接。

为什么 TIME_WAIT 状态需要经过 2MSL 才能到 CLOSED 状态？

MSL：报文段最大生存时间。

因为网络不可靠等原因，最后一个 ACK 报文可能会丢失。所以 TIME_WAIT 状态就是用来重发可能丢失的 ACK 报文。服务器端如果没有收到 ACK 报文，将不断重复发送 FIN 报文段。所以客户端不能立即关闭，它必须确认服务器端接收到了该ACK报文。客户端会在发送出 ACK 报文之后进入到 TIME_WAIT 状态。客户端会设置一个计时器，等待 2MSL 的时间。如果在该时间内再次收到 FIN报文，那么客户端会重发 ACK 报文并再次等待 2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果 2MSL 后，客户端都没有再次收到 FIN 报文，那么客户端判断 ACK 报文已经被成功接收，则进入到 CLOSED 状态。

如果已经建立连接，但是客户端突然出现故障。

TCP 设有一个保活计时器，如果客户端出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端请求后都会重新复位这个计时器，时间通常设置为 2 小时，若 2 小时后还没有收到客户端的任何数据，服务器都会发送一个探测报文段，以后每隔 75 秒发送一次。若一连发送 10 个探测报文段都没有反应，服务器就认为客户端出了故障，接着就关闭连接。

为什么不能是两次握手或者四次握手？

三次握手的两个作用：

（1）让客户端和服务器端都知道双方可以发送和收到消息

（2）为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

作用（1）意思是，假设 A 给 B 打电话，A 说：你能听到吗？B 听到后说：能听到，你能听到吗？A听到后说：能听到，......。这样就确保 A 和 B 都确定对方能够发送和收到消息。

作用（2）意思是：有种情况，客户端发出的第一个连接请求报文没有丢失，而是在某个网络结点长时间的滞留了，然后客户端发送了新的连接请求报文，两个（或者多个）连接请求报文到达服务器端，这时，在最新发送的请求报文之前发送的请求报文都是无效的，三次握手就是防止服务器端为无效的连接请求建立连接而造成资源浪费。

两次握手：无法确定双方都能发送和收到消息，可能发生死锁。

作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
四次握手：三次握手已经足够，四次握手浪费资源。

文章部分内容参考自：TCP的三次握手与四次挥手理解及面试题（很全面）_lucky_jun-CSDN博客_三次握手和四次挥手