TCP为什么是三次握手和四次挥手 - 好文

为什么建立连接是三次握手断开连接是四次挥手？
三次握手的流程和四次挥手的流程是什么？

三次握手与四次回收分别对应TCP连接与断开过程

tcp报文格式

标志位含义
ACK：确认序号有效。 SYN：发起一个新连接。 FIN：释放一个连接。
三次握手的过程

注意：三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的

所谓三次握手，即建立TCP连接，需要客户端和服务端总共发送至少三个包确认连接的建立。流程如下

第一次握手

Client将标志位SYN置1，随机产生一个值seq=J,并将数据包发给Server
Client进入SYN_SENT状态，等待Server确认

第二次握手

Server收到数据包后标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置1，随机产生一个值,并将数据包发给Client确认连接请求，Server进入SYN_RCVD状态

第三次握手

Client收到确认后若ACK为1，则将该数据包发送给Server，Server检查ACK为1则连接建立成功，Client与Server进入ESTABLISHED状态完成三次握手，可以传输数据

问题1：为什么建立连接是三次握手，四次不可以吗

第一次握手：
Client什么都不能确认 Server确认了对方发送正常
第二次握手：
Client确认：自己发送/接收正常，对方发送/接收正常 Server确认：自己接收正常，对方发送正常
第三次握手：
Client确认：自己发送/接收正常，对方发送/接收正常 Server确认：自己发送/接收正常，对方发送/接收正常
所以通过三次握手确认双方收发功能都正常，四次也可以但是显得比较多余。

TCP三次握手，如果两次握手会怎么样

设计上的缺陷

有这样一种情况，当A发送一个消息给B，但是由于网络原因，消息被阻塞在了某个节点，然后阻塞的时间超出设定的时间，A会认为这个消息丢失了，然后重新发送消息。

当A和B通信完成后，这个被A认为失效的消息，到达了B
对于B而言，以为这是一个新的请求链接消息，就向A发送确认，
对于A而言，它认为没有给B再次发送消息（因为上次的通话已经结束）所有A不会理睬B的这个确认，但是B则会一直等待A的消息

这就导致了B的时间被浪费（对于服务器而言，CPU等资源是一种浪费），这样是不可行的，这就是为什么不能两次握手的原因了。

所以有了三次握手的修订
第三次握手看似多余其实不然，这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判

四次挥手的过程

所谓四次挥手：即终止TCP连接，需要客户端和服务端总共发送4个包确认连接的断开。流程如下

第一次挥手：

Clien发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

第二次挥手：

Server收到FIN后，发送一个ACK给Client,Server进入CLOSE_WAIT状态。

第三次挥手：

Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：

Client收到FIN后，Client进入TIME_WAIT状态，发送ACK给Server，Server进入CLOSED状态，完成四次握手。

问题：为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

建立连接

因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

关闭连接

当收到对方的FIN报文时，仅表示对方不再发送数据但还能接收收据，我们也未必把全部数据都发给了对方，所以我们可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方表示同意关闭连接。因此我们的ACK和FIN一般会分开发送。

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图

为什么需要TIME_WAIT状态
1、可靠的终止TCP连接
2、保证让迟来的TCP报文段有足够的时间被识别并丢弃

1）为实现TCP这种全双工连接的可靠释放

这样可让TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的FIN)这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口(客户的IP地址和端口号，服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束后才能再被使用。

2）为使旧的数据包在网络因过期而消失

每个具体TCP实现必须选择一个报文段最大生存时间MSL。它是任何报文段被丢弃前在网络内的最长时间。

热门工具换一换