TCP协议中RST异常关闭的问题

Posted 车小胖谈网络

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了TCP协议中RST异常关闭的问题相关的知识,希望对你有一定的参考价值。

斜体部分为读者的提问:

按我理解,发送方送rst后直接释放连接,接收方收到rst后也释放连接,不需要回复ack。那么问题在于,如果发送方发送的rst包本身丢掉了,没有到达接收端,而发送方发送之后就关闭连接,会不会造成接收方连接半关闭的状态?

回答这个问题之前,先要了解在哪些情况下TCP的一方会发送RST(Reset)给另外一方。

学习TCP的很多读者,会知道一个TCP连接在数据传输完毕,通常会关闭连接,以释放通信双方的资源,如内存、端口号,以便于其它程序使用,这种正常释放连接的过程,通常使用FIN(Final)状态位来完成。

但FIN状态位不能用来处理异常情况。

异常情况一:
客户端、服务器端TCP连接一切正常,TCP连接由于没有数据传输而出于空闲(Idle)状态。

突然服务器掉电,当服务器重新启动完毕,与客户端的TCP连接状态由于掉电而完全消失。

之后,客户端发给服务器任何消息,都会触发服务器发RST作为回应。

服务器之所以发RST,是因为连接不存在,通过Reset状态位,间接告诉客户端异常情况的存在。

Reset顺利到达客户端

客户端意识到异常发生了,会立马释放该TCP连接所占用的内存资源(状态、数据)、以及端口号。

客户端TCP会通知数据的主人(应用程序),由于TCP连接被对方Reset,数据发送失败。

客户端无需超时等待,立即使用原有端口号,重新发起一个TCP连接,双方状态再一次同步,进入正常通信状态。

Reset没有到达客户端

客户端的状态依然为“established”状态,反正双方的状态已经不同步了,如果客户端有数据、或keepalive要发送,会继续触发服务器发送Reset。


这种情况是由于外界因素影响,使得双方状态不同步,一方为“established”,另一方为“closed”, 重置(Reset)连接状态是最好的方法!

有读者会问,如果客户端一直没有消息发给服务器端,那双方状态的不同步是否会保持到天长地久?

会的!

但是考虑到当前的网络状况,这种可能性是比较小的,因为目前的网络NAT无处不在,为了克服NAT表项没有流量刷新而删除NAT表项,进而影响客户端、服务器端通信,如今的TCP实现会在几十秒发送一次Keepalive,这样即使没有用户流量,Keepalive也会刷新NAT表项,从而避免NAT设备删表操作。

所以双方通信不同步状态,在当今的TCP实现上会很快监测到、并予以纠正。

异常情况二:
通常服务器在某个端口侦听,欢迎全球各地的主机(IP)连接请求,这是最最常见的Internet部署场景。

但,有些服务器对主机IP有限制,只允许某个、某些(段)IP的连接请求,这就是白名单列表,凡是不在白名单列表上的主机,遭遇的就是Reset对待。

也有一些服务器,不允许某个、某些IP的连接请求,这个是黑名单列表,凡是在黑名单列表上的主机,遭遇的也是Reset对待。

异常情况三:
当客户端发起一个TCP连接请求,途径公司防火墙时,防火墙查询自己的安全策略,这是一个不被允许的连接请求,于是防火墙以服务器IP的名义,返还给用户一个Reset状态位,用户以为是服务器发的,其实服务器压根不知道,是防火墙作为中间人发的。


欢迎扫码关注:


版权所有,禁止任何形式的转载!

以上是关于TCP协议中RST异常关闭的问题的主要内容,如果未能解决你的问题,请参考以下文章

从TCP协议的原理来谈谈rst复位攻击

TCP协议的RST标志位

linux 协议栈tcp的rst报文中,seq的选取问题

协议森林从TCP协议的原理来谈谈rst复位攻击

那些你不知道的 TCP 冷门知识

传输层(TCP与UDP)