TCP的连接与释放

左手的ㄟ右手 2024-04-01 09:53 37阅读 0赞

### 1.TCP/IP网络模型 ###

**协议：** 不同计算机与网络设备硬件与操作系统之间的通信都需要一种规则，这种规则就是**协议**  
**TCP/IP**是网络中各类协议族的总称，比如：**TCP、UDP、IP、FTP、HTTP、ICMP、SMTP** 等都属于TCP/IP族内的协议。

**网络协议可以划分为四层**

*  **链路层：** 负责封装和解封装IP报文，发送和接受ARP/RARP报文等。
 *  **网络层：** 负责路由一级把分组报文发送给目标网络或主机。
 *  **传输层：** 负责对报文进行分组和重组，并以TCP或UDP协议格式封装报文
 *  **应用层：** 计算机网络的顶层，负责向用户提供应用程序，如HTTP、域名系统DNS、文件传送协议FTP

### 2.TCP和UDP ###

**UDP全称用户数据报协议**

**TCP全称传输控制协议**

**区别:**

*  **连接：** UDP是无连接的，TCP是面向连接
 *  **可靠性传输：** TCP实现可靠传输。UDP则是不可靠传输尽力交付。
 *  **传输方式：** TCP面向字节流。UDP面向报文，对于应用层交付下来的报文，既不合并，也不拆分
 *  **适用场景：** TCP适用于可靠传输的应用，如文件传输。UDP适用实时性的传输，如电话会议、直播
 *  **传输速度：** TCP由于实现可靠传输速度相对较慢，UDP速度快

### TCP的连接与释放 ###

**TCP建立连接（三次握手）**

1.  第一次握手，客服端向服务端发送建立连接的请求，将**SYN**置为1，初始化通信序号seq为x，客户端进入**SYN-SENT**状态
2.  第二次握手，服务端接收到连接请求后，若同意连接，则向客户端发送建立连接的应答，**SYN**置为1，初始通信序号seq为y，**ACK**为1，确认序号ack为x+1，随后进入**SYN-RECEIVED**状态
3.  第三次握手，客户端收到应答后，需要再向服务端发送一个确认报文，**ACK**为1，确认序号**ack**为y+1 通信序号**seq**为x+1。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。  
    ![在这里插入图片描述][15dac83b0d9d4c55ace23486d36f4b05.png]

注：TCP规定SYN为1的报文段不能携带数据，但是要消耗一个序号，前二次报文段是TCP连接请求确认报文段，不能携带数据。第三个报文段是普通的TCP确认报文段可以携带数据，也可以不携带数据，若不携带则不消耗序号。

> 为什么不能两次握手？

> 因为加入一个失效的TCP连接请求延迟与TCP服务端建立连接，而此时TCP客户端处于连接关闭状态，TCP服务端会一直处于连接建立状态，浪费资源。  
> 服务端为了确保客户端有正常的数据接受能力，在客户端接受到服务端应答后，要及时的向服务端发送一个确认应答，以证明客户端的有效性。  
> ![在这里插入图片描述][4e3614de84a44a73ba685074e4ed6427.png]

**TCP释放连接(四次挥手)**

1.  第一次挥手：客户端向服务端发送释放连接的请求，**FIN（终止位）** 为1，客户端进入 **FIN\_WAIT\_1** 状态
2.  第二次挥手：服务端收到释放请求后，向客户端发送应答**ACK**为1，并带上自己的seq，随后进入**CLOSE\_WAIT**状态，此时客户端和服务端的连接已经释放，服务端不再接受客户端发送的数据。但是由于TCP是全双工的，服务端还可以向客户端发送数据，客户端收到应答后进入**FIN\_WAIT\_2**状态并持续60s，若60s内没有收到服务端发送的请求会直接关闭。
3.  第三次挥手：服务端将还没有发送完的数据发送，完毕后向客户端发送释放连接请求**FIN**为1，随后进入**LAST\_ACK**状态
4.  第四次挥手：客户端收到释放请求后，向服务端发送**ACK**确认应答，随后进入**TIME\_WAIT**状态，并持续**2MSL**(最长报文段寿命)，在该时间段客户端没有收到服务端的重发请求后，进入**CLOSED**状态。服务端收到应答后也进入**CLOSED**状态，连接断开。  
    ![在这里插入图片描述][1d1ba1cfa15143eab97c62d411e248ae.png]

> TCP客户进程在发送完最后一个确认报文段后，为什么不直接关闭而是要等待2MSL时间后才关闭？

> 因为如果第四个报文段丢失，那么TCP服务端进程会一直进行TCP连接释放的超时重传，但是此时TCP客户端已经关闭，导致服务端进程一直无法关闭浪费资源。  
> ![在这里插入图片描述][6244c5ecbab94446b43ed3cdad7e8823.png]

>  为什么TIME\_WAIT时间这么久？

>  1. 保证客户端ACK确认应答能够被服务端接收到，并正常的断开连接进入CLOSED状态释放资源。  
> 2. 防止具有相同四元组的数据包被找到，如果第四次挥手中没有了time\_wait，服务端发送的数据包客户端就无法收到，等到下次重新启用时客户端就收到了上次的旧数据包

[15dac83b0d9d4c55ace23486d36f4b05.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5ebea192039544bea7a4463f97225afb.png
[4e3614de84a44a73ba685074e4ed6427.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/cd796cf568324e89b20eab3dbbd05f84.png
[1d1ba1cfa15143eab97c62d411e248ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/eee0ee38ac064b4a8221f74ab92840c7.png
[6244c5ecbab94446b43ed3cdad7e8823.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/8c19ceca601d4d4494acaac4d639df4f.png