【计算机网络】三握四挥相关问题

在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接

服务端状态转化:

  • [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
  • [LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文.
  • [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了.
  • [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;
  • [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
  • [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK,彻底关闭连接。

客户端状态转化:

  • [CLOSED -> SYN_SENT] 客户端调用connect, 发送步报文段;
  • [SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
  • [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入FIN_WAIT_1;
  • [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;
  • [FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
  • [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态

三次握手:

  1. 第一次握手:客户端发送SYN包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;
  2. 第二次握手:服务器收到SYN包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RCVD状态;
  3. 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。

四次挥手:

与建立连接的“三次握手”类似,断开一个TCP连接则需要“四次握手”。

  1. 第一次挥手:主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不会再给你发数据了(当然,在FIN包之前发送出去的数据,如果没有收到对应的ACK确认报文,主动关闭方依然会重发这些数据),但是,此时主动关闭方还可 以接受数据。
  2. 第二次挥手:被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号)。
  3. 第三次挥手:被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了。
  4. 第四次挥手:主动关闭方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1,至此,完成四次挥手。

 

为什么会采用三次握手,若采用二次握手可以吗?

主要防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误

采用三次握手是为了防止失效的连接请求报文段突然又传送到服务端,因而产生错误。失效的连接请求报文段是指:客户端发出的连接请求没有收到服务端的确认,于是经过一段时间后,客户端又重新向服务端发送连接请求,且建立成功,顺序完成数据传输。

考虑这样一种特殊情况,客户端第一次发送的连接请求并没有丢失,而是因为网络节点导致延迟达到服务端,服务端以为是客户端又发起的新连接,于是服务端同意连接,并向客户端发回确认,但是此时客户端根本不会理会,服务端就一直在等待主机A发送数据,导致服务端的资源浪费。所以采用两次握手不行。

如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

 

为什么建立连接是三次握手,关闭连接确是四次挥手呢?

当服务端收到客户端的SYN连接请求报文时,可以直接发送SYN+ACK报文。这时的ACK报文时用来应答的,SYN报文是用来同步的。

但是关闭连接时,当服务端收到FIN报文时,很可能并不会立即就关闭socket,所以只能先回复一个ACK报文,告诉服务端,你发的FIN报文我收到了,但是要等我服务端所有的报文都发完,我才能给你发送FIN报文,所以不能一次发送ACK+FIN报文。所以关闭连接需要四次挥手。

 

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

按道理,四个报文都发送完毕,我们就可以直接进入CLOSE状态了,但是我们必须假想网络是不可靠的,有可能最后一个ACK丢失。所以TIME——WAIT状态就是用来重发可能丢失的ACK报文。

服务端如果没有收到ACK,将不断重复发送FIN片段。所以客户端不能立即关闭,他必须确认服务端接收到了该ACK。客户端会在发送出ACK之后进入到TIME_WAIT状态。客户端会设置一个计时器,等待2MSL时间。如果该时间内再次收到FIN,那么客户端回重发ACK并再次等待2MSL,(所谓的2MSL就是两倍的MSL,MSL是指一个片段在网络中的最大的存活的时间,2MSL就是一个发送和一个回复的最大时间。)如果知道2MSL,客户端都没有再次收到FIN,那么客户端推断ACK已经被成功接收,则结束TCP连接。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值