【网络基础】TCP协议之三次握手和四次挥手

拼搏现实的明天。 2022-07-08 17:28 167阅读 0赞

前面提到了TCP数据报以及TCP是通过什么进行可靠传输的，相关知识点请关注下面的博客：  
**[http://blog.csdn.net/bit\_clearoff/article/details/60469790][http_blog.csdn.net_bit_clearoff_article_details_60469790]**

这篇文章的要点是

*  三次握手
 *  四次挥手
 *  为什么要三次握手
 *  为什么要四次挥手
 *  TCP的有限状态机

**本篇文章参考内容**

*  **《计算机网络》（第五版）——谢希仁**。
 *  **[http://blog.csdn.net/xifeijian/article/details/12777187][http_blog.csdn.net_xifeijian_article_details_12777187]**

## TCP的有限状态机 ##

TCP的有限状态机反映了一个TCP连接中各种状态之间的关系，下面给出有限状态机的转换图：（有限状态机）

上图反映了各个TCP连接状态发生转换的原因。

## TCP链接的建立——三次握手 ##

首先，我们来看一下三次握手这个过程：  
![（三次握手.PNG）][.PNG]

下面，简要的解释一下链接过程中的所发送的消息：

**第一次握手**：客户向服务器发送了SYN=1的TCP报文，SYN=1表示该报文是一个连接请求报文，另外TCP规定，SYN报文不能携带数据，但要消耗一个序号，所以我们任选一个序号，当SYN=1的报文段发送出去后，客户端进入**SYN-SENT**状态。

**第二次握手** ： 第二次握手是服务端回复客户端的连接请求报文，向客户端确定自己也同步了连接，在确认报文段中，需要将ACK和SYN同时置为1，同时任意选择一个序号作为消耗的序号；另外，确认报文段中将连接请求报文段发来的序号+1然后再发送回去，表示客户端发来的请求已经确认收到了。发送完确认报文段后，服务端也进入**SYN-SENT**状态。

**第三次握手** ：第三次握手是客户端向服务端发送的，因为第二次握手中，服务端向客户端也发送了同步连接请求，所以客户端要向服务端的请求作出应答，在第三次握手报文发送出去后，客户端便进入了**ESTAB-LISHED**状态，服务端在收到报文后也进入了该状态。

下面，我们再来解释一下三次握手过程中所涉及到的状态：

**LISTEN**:这个状态很容易理解，表示服务器端的某个端口处于监听状态，处于该状态的端口可以接收连接。  
**SYN-RCVD**:这个状态表示接收到了客户端发过来的SYN报文，这个状态其实很短暂，只是个中间状态。  
**SYN-SENT**:当客户端发送了SYN报文后，它会直接从CLOSED状态转换为该状态，并等待发送第二次确认报文。  
**ESTBLISHED**:表示客户端和服务端之间的链接已经建立了。

## 为什么要有第三次握手？ ##

相信前两次握手大家都很好理解，一次是客户端向服务端发出连接请求，此时只能是客户端向服务端发送数据，而服务端不能向客户端发送数据；第二次是服务端向客户端发送的连接请求，这次过后双方都可以发送数据了；那其实两次连接就能解决问题的，为什么还要第三次呢？  
其实，第三次的握手是为了防止已经失效的连接请求报文段突然又传送到了服务端，从而产生错误。这个已经失效的连接报文段是怎么来的？ 因为客户端在发送了SYN数据报后可能又这种情况，因为当时**网络拥塞**，所以过了超时重传的等待时间后客户端没有收到服务端的确认，所以它又发送了第二次SYN报文段，此时服务端发送过来了SYN应答报文段。但是可能过了一会，刚刚处于拥塞环境的SYN报文段又到达了服务端，这时服务端会认为客户端想和自己建立第二次连接，于是又向客户端发送了SYN应答报文段，而此时客户端可能已经完成了数据传送并释放了和服务端的连接，它的状态会变为**CLOSED**,从而导致永远无法收到服务端发来的SYN报文段，从而使服务端一直再等待客户端发来数据，这样会浪费许多服务端的资源。  
所以，就引入了第三次握手，例如上面的情况，客户端在收到应答报文段后不会想服务端再次发送确认，所以服务端也就无法建立连接。

## TCP连接的释放——四次挥手 ##

下面展示的是TCP释放连接的过程——四次挥手。  
![（四次挥手）][SouthEast]

下面，我们还是解释一下四次挥手过程中的相关信息：

**第一次挥手**：由客户端向服务器端发送FIN报文段，发送了FIN=1的报文段表明发送方告诉对方自己的数据已经发送完毕，发送完FIN=1的报文后，客户端进入**FIN-WAIT-1**(终止等待状态1)。

**第二次挥手**：由服务端对客户端的终止请求报文进行应答并确认服务端报文段的序号，发送完后服务端进入**CLOSE-WAIT**（关闭等待状态），此时连接已经处于半关闭状态了，只有服务端能向客户端发送数据了，而客户端收到该报文后会进入**FIN-WAIT-2**（终止等待状态2）。

**第三次挥手**：有服务端向客户端发送终止请求报文，发送完毕后服务端进入了**LAST-ACK**(最后确认状态)。

**第四次挥手**：客户端收到服务端的终止请求后必须做出确认，于是发出了对第三次挥手的应答报文，发送完毕后，服务端在接收到确认报文后直接进入**CLOSED**状态，而客户端在等待2\*MSL时间后也进入了**CLOSED**状态。

下面对四次挥手过程的状态进行解释：  
**FIN-WAIT-1**：等待对方对自己的FIN报文的确认报文，当某个端口想主动关闭连接时就会进入该状态。  
**FIN-WAIT-2**:表示等待对方的FIN报文，此时连接处于半连接状态。  
**TIME-WAIT**:表示收到了对方的FIN报文，并发送出了ACK报文，这个状态是为了防止如果服务端没有收到确认报文的话，客户端可能需要启动超时重传。  
**CLOSE-WAIT**:这种状态表示在等待关闭，处于这个状态的一方要考虑还有没有数据要发送给对方，如果没有了的话就要向对方发送FIN报文。

## 为什么需要四次挥手？ ##

为什么要有四次挥手相比于为什么要有三次握手应该不难理解，四次挥手分别是各自互相发送FIN报文，以及发送对对方FIN报文的确认报文，值得一提的是为什么在最后一次挥手后要等待2\*MSL的时间？  
这样做是为了保证A的最后一次挥手（ACK报文段）能够到达B。出了**LAST-ACK**状态的B如果收不到A的ACK字段，那么他会在重传一次**FIN+ACK**字段，A收到后会重传一次确认，重新启动时间等待计时器（2\*MSL），如果A不等待2MSL，如果最后一次确认没有传到B， 那么B的重传A就再也收不到了，那么B就会一直重传，并永远无法释放连接。

[http_blog.csdn.net_bit_clearoff_article_details_60469790]: http://blog.csdn.net/bit_clearoff/article/details/60469790
[http_blog.csdn.net_xifeijian_article_details_12777187]: http://blog.csdn.net/xifeijian/article/details/12777187
[.PNG]: /images/20220708/8b596300227a49e3bee163b44c3ed790.png
[SouthEast]: /images/20220708/0feb0e6142cf4ec1870a80ede29f4cea.png