JAVAEE之网络原理（2）_传输控制协议(TCP)的连接管理机制，三次握手、四次挥手，及常见面试题

小_Duang

已于 2024-06-22 18:12:22 修改

阅读量990

点赞数 24

分类专栏： JavaEE 文章标签：网络 java-ee tcp/ip

于 2024-06-19 10:43:14 首次发布

本文链接：https://blog.csdn.net/2301_80653026/article/details/139790438

版权

22 篇文章 0 订阅

订阅专栏

前言

在上一节中，我们简单介绍了 TCP 协议的相关概念和基本报文格式，而且还介绍了TCP 协议原理中的确认应答机制（安全机制）、超时重传机制，在本节中我们将会继续介绍 TCP协议原理中的连接管理机制（三次握手、四次挥手）。

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接
在这里插入图片描述

在这里插入图片描述

最开始的时候客户端和服务器都是处于CLOSED关闭状态。主动打开连接的为客户端，被动打开连接的是服务器。TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了 LISTEN 监听状态

三次握手过程可以详细概括如下：

第一次握手:TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT 同步已发送状态。
第二次握手 TCP服务器收到请求报文后，如果同意连接，则会向客户端发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了 SYN-RCVD 同步收到状态
第三次握手 TCP客户端收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED已建立连接状态触发三次握手。

采用三次握手的主要原因：防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

第一次握手：客户端向服务器发送报文，证明客户端的发送能力正常。
第二次握手：服务端接收报文并向服务器发送报文，证明服务器的发送嫩能力和接收能力正常。
第三次握手：客户端向服务器发送报文，证明客户端的接受能力正常。

g.cn/direct/e1a46e31009e44f2980012b823314322.png)
数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于 ESTABLISHED 状态，然后客户端主动关闭，服务器被动关闭。
三次挥手过程可以详细概括如下：

第一次挥手： 客户端发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态
第二次挥手： 服务器端接收到连接释放报文后，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT 关闭等待状态
第三次挥手： 客户端接收到服务器端的确认请求后，客户端就会进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文，服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
第四次挥手： 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态，但此时TCP连接还未终止，必须要经过2MSL后（最长报文寿命），当客户端撤销相应的TCB后，客户端才会进入CLOSED关闭状态，服务器端接收到确认报文后，会立即进入CLOSED关闭状态，到这里TCP连接就断开了，四次挥手完成。

emsp;MSL是TCP报文的最大生存时间
主要原因是为了保证客户端发送那个的第一个ACK报文能到到服务器，因为这个ACK报文可能丢失，并且2MSL是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃，这样新的连接中不会出现旧连接的请求报文。

服务器收到客户端的 FIN 报文时，内核会马上回一个 ACK 应答报文，但是服务端应用程序可能还有数据要发送，所以并不能马上发送 FIN 报文，而是将发送 FIN 报文的控制权交给服务端应用程序：

如果服务端应用程序有数据要发送的话，就发完数据后，才调用关闭连接的函数；
如果服务端应用程序没有数据要发送的话，可以直接调用关闭连接的函数。

从上面过程可知，是否要发送第三次挥手的控制权不在内核，而是在被动关闭方（上图的服务端）的应用程序，因为应用程序可能还有数据要发送，由应用程序决定什么时候调用关闭连接的函数，当调用了关闭连接的函数，内核就会发送 FIN 报文了，所以服务端的 ACK 和 FIN 一般都会分开发送。

当被动关闭方（上图的服务端）在 TCP 挥手过程中，没有数据要发送并且开启了 TCP 延迟确认机制，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手。
在这里插入图片描述

TCP 延迟确认的策略：

以上就是本节的主要内容，我们详细介绍了 TCP原理中的连接管理机制，主要包括三次握手和四次挥手两部分，我们介绍了三次握手、四次挥手的主要过程。在下一节我们将会继续介绍 TCP 原理中的其他机制。

关注