【计算机网络】描述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次握手原因:增加不必要开销与延迟
欢迎补充,互相学习🤝