TCP收到RST的几种情况

最新推荐文章于 2023-10-19 11:45:39 发布

knowledgebao

最新推荐文章于 2023-10-19 11:45:39 发布

阅读量8.3k

点赞数 1

分类专栏：网络相关

本文链接：https://blog.csdn.net/knowledgebao/article/details/84644233

版权

网络相关专栏收录该内容

19 篇文章 0 订阅

订阅专栏

关于三次握手，四次挥手过程及状态变化，请参考https://blog.csdn.net/knowledgebao/article/details/84626238

关于TCP的接口，请参考：https://blog.csdn.net/knowledgebao/article/details/85384510

产生RST的原因

1. 访问不存在的端口。

若端口不存，则直接返回RST，同时RST报文接收通告窗口大小为0.其实客户端向服务器的某个端口发起连接，如果端口被处于TIME_WAIT 状态的连接占用时，客户端也会收到RST。这种情况很常见。特别是服务器程序core dump之后重启之前连续出现RST的情况会经常发生。

2. 异常终止连接。

一方直接发送RST报文，表示异常终止连接。

一旦发送方发送复位报文段，发送端所有排队等待发送的数据都被丢弃。应用程序可以通过socket选项SO_LINGER来发送RST复位报文。而接收端收到RST包后，不必发送ACK包来确认。
接收方如果不接受完所有的数据，就关闭链接，底层TCP会给发送方返回一个RET报文，表示数据没有被完全接受，并且关闭里。参考文章3有Demo实现。

3.处理半打开连接。

一方关闭了连接，另一方却没有收到结束报文（如网络故障），此时另一方还维持着原来的连接。而一方即使重启，也没有该连接的任何信息。这种状态就叫做半打开连接。而此时另一方往处于半打开状态的连接写数据，则对方回应RST复位报文。此时会出现connect reset by peer错误。

4.请求超时

设置 connect_timeout，应用设置了连接超时，sync 未完成时超时了，会发送rst终止连接。

曾经遇到过这样一个情况:一个客户端连接服务器，connect返回-1并且error=EINPROGRESS。直接telnet发现网络连接没有问题。ping没有出现丢包。用抓包工具查看，客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。

比如像下面这样：

有89、27两台主机。主机89向主机27发送了一个SYN，表示希望连接8888端口，主机27回应了主机89一个SYN表示可以连接。但是主机27却很不友好，莫名其妙的发送了一个RST表示我不想连接你了。

后来经过排查发现，在主机89上的程序在建立了socket之后，用setsockopt的SO_RCVTIMEO选项设置了recv的超时时间为100ms。而我们看上面的抓包结果表示，从主机89发出SYN到接收SYN的时间多达110ms。（从15:01:27.799961到15:01:27.961886，小数点之后的单位是微秒）。因此主机89上的程序认为接收超时，所以发送了RST拒绝进一步发送数据。

5，keepalive 超时

公网服务tcp keepalive 最好别打开；移动网络下会增加网络负担，切容易掉线；非移动网络核心ISP设备也不一定都支持keepalive，曾经也发现过广州那边有个核心节点就不支持。

6， TIME_WAIT 状态

　　tw_recycle = 1 时，sync timestamps 比上次小时，会被rst。

RST攻击

服务器A和服务器B之间建立了TCP连接，此时服务器C伪造了一个TCP包发给B，使B异常的断开了与A之间的TCP连接，这就是RST攻击。
那么伪造什么样的TCP包可以达成目的呢？我们至顶向下的看：

假定C伪装成A发过去的包，这个包如果是RST包的话，毫无疑问，B将会丢弃与A的缓冲区上所有数据，强制关掉连接；
如果发过去的包是SYN包，B会表示A已经发疯了（与OS的实现有关），正常连接时又来建新连接，B主动向A发个RST包，并在自己这端强制关掉连接；

这两种方式都能够达到复位攻击的效果。似乎挺恐怖，然而关键是C如何能伪造成A发给B的包呢？这里有两个关键因素，源端口和序列号。

一个TCP连接都是四元组，由源IP+源端口、目标IP+目标端口唯一确定一个连接。所以，如果C要伪造A发给B的包，要在上面提到的IP头和TCP头，把源IP、源端口、目标IP、目标端口都填对。这里B作为服务器，IP和端口是公开的，A是我们要下手的目标，IP当然知道，但A的源端口就不清楚了，因为这可能是A随机生成的。当然，如果能够对常见的OS如windows和linux找出生成source port规律的话，还是可以搞定的。

此外，伪造的TCP包里需要填序列号（SeqNum），如果序列号的值不在A之前向B发送时B的滑动窗口内，B是会主动丢弃的。所以我们要找到能落到当时的AB间滑动窗口的序列号。这个可以暴力解决，因为一个sequence长度是32位，取值范围0-4294967296，如果滑动窗口大小为65535的话，则最多只需要发65537（4294967296/65535=65537）个包就能有一个序列号落到滑动窗口内。RST包是很小的，IP头＋TCP头也才40字节，算算我们的带宽就知道这实在只需要几秒钟就能搞定。

参考文章：

1，https://blog.csdn.net/a_tu_/article/details/80389878

2，https://blog.csdn.net/hhgggggg/article/details/77678687

3，https://www.cnblogs.com/JohnABC/p/6323046.html

4，https://blog.csdn.net/ilozk/article/details/78667499

有任何问题，请联系：knowledgebao@163.com

knowledgebao

关注

1
点赞
踩
16

收藏

觉得还不错? 一键收藏
0
评论
TCP收到RST的几种情况

相关索引：https://blog.csdn.net/knowledgebao/article/details/84626184关于三次握手，四次挥手过程及状态变化，请参考https://blog.csdn.net/knowledgebao/article/details/84626238关于TCP的接口，请参考：https://blog.csdn.net/knowledgebao/art...
复制链接

扫一扫