http的三次握手四次挥手

最新推荐文章于 2024-08-28 14:19:12 发布

转载最新推荐文章于 2024-08-28 14:19:12 发布 · 177 阅读

计算机网络专栏收录该内容

2 篇文章

订阅专栏

本文详细解析了TCP协议中的三次握手和四次挥手的过程及其背后的原理。包括ACK、SYN、FIN等关键字段的意义，握手和挥手的具体步骤，以及为何采用这种方式确保连接的可靠性。

参考：https://blog.youkuaiyun.com/charking_gg/article/details/81663768

基础含义：

ACK ：ACK (Acknowledgement）即是确认字符， TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1。
FIN ：（finis）即完，终结的意思，用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。

SYN:同步序列编号（Synchronize Sequence Numbers）,既同步的含义。

发送序列号：Sequence Number
确认序列号：Acknowledgment Number

FIN_WAIT_1：表示等待对方的FIN报文。当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET进入到FIN_WAIT_1 状态
FIN_WAIT_2：也表示等待对方的FIN报文。FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。你回复一个ACK给对方，并进入CLOSE_WAIT状态。接下来就是查看你是否还有数据要发送给对方，如果没有，就可以close这个socket，并发送FIN给对方，即关闭连接。
CLOSING：表示主机1给主机2发送FIN后，并没有收到主机2回应的ACK，而收到了主机2发送的FIN。表示双方同时close一个socket，出现同时发送FIN现象。
LAST_ACK: 发送FIN报文后，等待对方的ACK报文，当收到ACK报文后，进入到CLOSED状态。
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK确认，等2MSL（2个报文最大生存时间）后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态。

三次握手：

第一次握手：建立连接时，客户端发送syn（同步序列编号（Synchronize Sequence Numbers））包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据.

四次挥手：

第一次挥手：主机1向主机2，发送FIN报文段，表示关闭数据传送，并主机1进入FIN_WAIT_1状态，表示没有数据要传输了
第二次挥手：主机2收到FIN报文段后进入CLOSE_WAIT状态（被动关闭），然后发送ACK确认，表示同意你关闭请求了，主机到主机的数据链路关闭，主机1进入FIN_WAIT_2状态
第三次挥手：主机2等待主机1发送完数据，发送FIN到主机1请求关闭，主机2进入LAST_ACK状态
第四次挥手：主机1收到主机2发送的FIN后，回复ACK确认到主机2，主机1进入TIME_WAIT状态。主机2收到主机1的ACK后就关闭连接了，状态为CLOSED。主机1等待2MSL，仍然没有收到主机2的回复，说明主机2已经正常关闭了，主机1关闭连接。

为什么设计这种三次握手四次挥手的方式？

参考：https://blog.youkuaiyun.com/yu876876/article/details/81560122

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

第一次握手：

Client什么都不能确认
Server确认了对方发送正常
第二次握手：

Client确认：自己发送/接收正常，对方发送/接收正常
Server确认：自己接收正常，对方发送正常

第三次握手：

Client确认：自己发送/接收正常，对方发送/接收正常
Server确认：自己发送/接收正常，对方发送/接收正常
可见三次握手后，客户端和服务端都可以确认自己接发正常以及对方接发正常。

问：那只有两次握手可以嘛？

不可以的！

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

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

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

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

问：为什么握手时三次而挥手时四次？

建立连接

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

关闭连接

当收到对方的FIN报文时，仅表示对方不再发送数据但还能接收收据，我们也未必把全部数据都发给了对方，所以我们可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方表示同意关闭连接。因此我们的ACK和FIN一般会分开发送，故每个端都会一次FIN（结束）一次 ACK（确认），故有四次挥手。