政府网站建设招标标书工业设计公司
一、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次握手原因：增加不必要开销与延迟
欢迎补充，互相学习🤝