RST发生原因
一般来说，TCP发送RST消息的原因有以下3种。
1、接收进程未在SYN数据段指定的目标端口上等待。
2、TCP想放弃已经存在的连接。
3、TCP接收到数据段，但不存在由该数据段所标识的连接。
在第一种情况下，终端访问服务器上未打开的端口，服务器返回RST消息的例子很常见。 例如，在访问Web服务器的21端口(FTP )的情况下，若该端口服务器未被开放或者被阻塞对该端口的请求消息，则服务器很可能将RST消息应答给终端SYN消息。 因此，服务器对终端的SYN消息作出RST消息的响应往往是端口扫描仪确定目标端口未打开的一个可靠依据。 当然，在许多情况下，更安全的实现是服务不响应到达其未监听的端口的消息就丢弃。
第二种情况很容易理解。 成功断开现有TCP连接的方法是发送FIN。 FIN消息在发送所有队列数据后才发送，通常不会丢失数据。 因此，这也被称为有序释放。 另一种断开现有TCP连接的方法是发送RST。 这种方法的优点是可以立即关闭连接，而无需等待数据传输完成。 这种通过RST断开连接的方式称为异常开路。 在很多情况下，服务器需要对两种不同的解链方式提供不同的处理方法，很多服务器无法识别RST方式的解链，所以在这种情况下，特别是在很多终端使用RST方式解链时
在最后一种情况下，TCP通过四对(源目标IP和源目标端口)唯一地标识连接。 由于TCP状态机的存在，触发TCP连接建立的第一个消息标志始终是SYN集，因此当服务器接收到新的四组非SYN包时，该消息将被丢弃，并向终端响应RST消息。 在最后一种情况下，TCP通过四对(源目标IP和源目标端口)唯一地标识连接。 由于TCP状态机的存在，触发TCP连接建立的第一个消息标志始终是SYN集，因此当服务器接收到新的四组非SYN包时，该消息将被丢弃，并向终端响应RST消息。
问题现象
从终端登录到Web并输入用户名和密码后，网页显示连接将重置。 数据包消息如下。
终端10.153.47.104访问服务器10.153.42.65上的8051端口，建立三次握手后，终端向服务器发送认证请求，提交用户名和密码，服务器立即响应RST
分析问题
通过比较上述三种情况，发现只匹配以上原因2，但从原因2来看，也只是表示服务器可以在该位置可靠地返回RST消息，无法解释服务器为什么要返回RST。
这个时候，我们需要考虑一个问题。 这个RST消息真的是服务器回复的吗？ 从RST消息的seq来看，确实能够对应于在先消息(由于SYN标志位在逻辑上占用1字节的序号，所以RST消息的序号为第二消息的序号加1 )。 一种经常确定一个流是否是从同一服务器发送的方法是对相同方向上的消息的IP报头中的TTL值进行比较。 TCP对顺序混乱非常敏感，而网络设备逐包传输数据会导致更严重的顺序混乱，因此网络中的设备通常按包发送。 因此，基于这个判断，让我们来看看上面截图中的第二条和第五条消息
第二条消息的TTL值为251 :
第五条消息的TTL是122 :
因此，基本上，该RST消息可以是从中间转发设备发送的。 排除通信路径上的安全设备故障，并在IPS中找到相应的日志。
由于用户名和密码以admin和明文形式发送，Web用户登录弱密码的防御规则启动，连接被重置，IPS欺骗服务器向终端发送RST消息并断开链接，IPS数据
在许多环境中，当中间安全设备在RST上监听消息时，初始TTL通常为64、128、255，它们可以被终端抓住分组的TTL反向推出监听安全设备的位置。 当然，在某些安全设备进行监听时，可能找不到TTL的初始值。 在这种情况下，只能按跳进行故障排除。
关于寻找教程网
本网站文章只是代表的观点，不代表本网站的立场，所有文章都是非盈利的、免费共享的。
本网站提供软件编程、网站开发技术、服务器运维、人工智能等IT技术文章。 很多程序员努力学习，希望我们能用科技改变世界。
[为什么服务器突然回复rst —— ] http://www.zyiz.net/tech/detail-96272.html