小林coding tcp断开

1、四次挥手主动关闭连接的,才有 TIME_WAIT 状态。

2、第一次 挥手丢失了,超时重传  有重传次数和最后重传完之后等待时间的限制

3、第二次挥手丢失了,ACK 报文是不会重传的,所以如果服务端的第二次挥手丢失了,客户端就会触发超时重传机制,重传 FIN 报文,直到收到服务端的第二次挥手,或者达到最大的重传次数。否则客户端就会断开连接

4、第三次挥手丢失了,超时重传 ,还没收到服务器就断开连接  客户端因为是通过 close 函数关闭连接的,处于 FIN_WAIT_2 状态是有时长限制的,如果 tcp_fin_timeout 时间内还是没能收到服务端的第三次挥手(FIN 报文),那么客户端就会断开连接

5、第四次挥手丢失   服务器超时重传  客户端在收到第三次挥手后,就会进入 TIME_WAIT 状态,开启时长为 2MSL 的定时器,如果途中再次收到第三次挥手(FIN 报文)后,就会重置定时器,当等待 2MSL 时长后,客户端就会断开连接

6、为什么是等待2MSL   报文最大生存时间   MSL 与 TTL 的区别: MSL 的单位是时间,而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间,以确保报文已被自然消亡   2MSL时长 这其实是相当于至少允许报文丢失一次

7、为什么需要time_wait状态   只有主动发起关闭连接的一方需要time_awit状态

防止历史连接中的数据,被后面相同四元组的连接错误的接收;

保证「被动关闭连接」的一方,能被正确的关闭;(如果出现了最后一个ack的丢失,还有挽救的地步)

8、服务端大量出现time_awit状态的原因——http没有使用长连接、http长连接超时(客户端长时间没有给服务端请求,所以它就主动放弃连接)、http长连接的请求数量达到上限(高QPS的情况下)

9、服务器大量出现close_wait状态 说明服务端的程序没有调用 close 函数关闭连接。主要是代码的问题

10、如果已经建立了连接,但是客户端突然出现故障了怎么办  如果服务端一直不会发送数据给客户端,那么服务端是永远无法感知到客户端宕机这个事件的,也就是服务端的 TCP 连接将一直处于 ESTABLISH 状态,占用着系统资源。  保活机制

11、如果已经建立了连接,但是服务端的进程崩溃会发生什么?TCP 的连接信息是由内核维护的,所以当服务端的进程崩溃后,内核需要回收该进程的所有 TCP 连接资源,于是内核会发送第一次挥手 FIN 报文,后续的挥手过程也都是在内核完成,并不需要进程的参与,所以即使服务端的进程退出了,还是能与客户端完成 TCP 四次挥手的过程。

12、四次挥手能不能变三次   

当被动关闭方在 TCP 挥手过程中,如果「没有数据要发送」,同时「没有开启 TCP_QUICKACK(默认情况就是没有开启,没有开启 TCP_QUICKACK,等于就是在使用 TCP 延迟确认机制)」,那么第二和第三次挥手就会合并传输,这样就出现了三次挥手。

所以,出现三次挥手现象,是因为 TCP 延迟确认机制导致的。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值