【计算机网络】描述TCP建立连接与断开的过程

一、TCP连接的建立与断开

1、建立连接——三次握手

1、A的TCP向B发出连接请求报文段

其首部中的同步位SYN = 1，并选择序号seq = x，表明传送数据时的第一个数据字节的序号是 x

2、B的TCP收到连接请求报文段后，如同意，则发回确认。

B 在确认报文段中应使SYN = 1，使ACK = 1，其确认号ack = x + 1，自己选择的序号seq = y

3、A收到此报文段后向B给出确认，其ACK = 1，确认号ack = y + 1。

A 的 TCP 通知上层应用进程，连接已经建立。

2、断开连接——四次挥手

数据传输结束后，通信的双方都可释放连接。现在A 的应用进程先向其TCP 发出连接释放报文段，并停止再发送数据，主动关闭TCP连接

1、A 连接释放报文段首部的FIN = 1，其序号seq = u，等待B的确认。

2、B发出确认ACK = 1，确认号 ack = u + 1，而这个报文段自己的序号 seq = v。TCP 服务器进程通知高层应用进程。

从A到B这个方向的连接就释放了，TCP 连接处于半关闭状态。B若发送数据，A仍要接收。

3、若B已经没有要向A发送的数据，其应用进程就通知TCP 释放连接 ACK = 1。

此时报文首部FIN = 1，报文序列号seq = w，确认号 ack = u + 1。

4、A 收到连接释放报文段后，必须发出确认。确认报文段中 ACK = 1，确认号 ack = w + 1，自己的序号 seq = u + 1。

二、TCP建立连接过程为何是3次握手，不是2次，4次？

1、选择3次原因

①防止重复历史连接的初始化，从而浪费网络资源

网络拥塞、延迟情况下，旧的连接请求（SYN报文）可能会比新的连接请求更晚到达服务器。

3次握手过程中，服务器发送SYN-ACK后，需要等待客户端ACK确认连接有效性

避免了旧连接的初始化

②同步双方初始序列号

TCP序列号，可以确保数据的顺序与完整性；3次握手过程中，双方可以确认初始序列号，从而确保数据传输的正确性

③确保双方具有发送、接受数据能力

2、非2次原因

①无法避免历史连接的初始化、浪费网络资源

如果采用两次握手，服务器可能会错误地响应旧的连接请求，导致资源浪费和混乱

·或者由于旧连接请求滞留网络，服务器端开辟网络资源持续等待，到达时已经失效，浪费资源；

·或者服务器依旧响应建立连接后，开辟网络资源等待旧连接发送数据；但由于旧连接请求已经超时失效，客户端已发出新连接请求；服务端开辟的网络资源浪费

②只能保证连接单向畅通

客户端发出的连接，服务器确认收到后；

服务器返回的应答，客户端无法确认是否成功收到。

此部分解释可参考博文中描述，写得很好：

《对线面试官》| 高频计算机网络面试题_计算机网络高频面试题-CSDN博客

3、非4次原因

①增加通信开销与延迟

连接建立过程中传输的数据量增加，且由于操作增加，建立连接时间增加。

②降低连接建立效率

三、TCP断开连接过程为何是4次挥手，不是3次，5次

1、选择4次原因

①全双工特性

数据可以在两个方向同时传输，故关闭连接时，每个方向上都需要发送一次FIN和对应的ACK，共4次

②确保数据完整传输

每次挥手均有对上次动作确认ACK，确保数据的可靠传输直到连接断开

③进入客户端TIME_WAIT状态

·保证客户端A 发送的最后一个 ACK 报文段能够到达服务器B。

·处理延迟的数据包，防止 “已失效的连接请求报文段”出现在本连接中。

客户端A 在发送完最后一个ACK 报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产

生的所有报文段，都从网络中消失。

这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

2、非3次原因

①无法确保双方均准备关闭连接

②无法处理延迟到达的数据包

客户端发送FIN后直接关闭连接，服务器仍然需要继续发送的数据无法传输

3、非5次原因

参考建立连接过程不选择4次握手原因：增加不必要开销与延迟