多次RST以及不同场景下的RST报文的差异
来源:互联网 发布:游戏美工培训班 编辑:程序博客网 时间:2024/06/15 23:11
http://www.vants.org/?post=141
多次RST以及不同场景下的RST报文的差异
作者:易隐者 发布于:2012-10-9 11:27 Tuesday 分类:网络分析
在某个TCP交互过程中,我们发现在交互的后期,客户端多次向服务器端发送RST报文,如下图所示:
我们首先来看客户端发出的第一个RST报文的解码:
RST与ACK标志位都置一了,并且具有ACK number,非常明显,这个报文在释放TCP连接的同时,完成了对前面已接收报文的确认。
我们再来看看客户端发出的后续RST报文的解码:
我们可以看到,这些后续的RST报文仅Reset位置一,ACK位未置一,在这种情况下,该报文的ACK确认号应该为0,但是我们留意到在这个报文中,其ACK确认号与序列号是一致的。
这是为什么呢?
因为ACK位未置一,ACK确认号也就失去了意义,因此,不论ACK确认号是什么值都不会对接收端产生影响,因此大部分的系统都会将ACK确认号设置为0,之所以在这个报文中出现ACK确认号非0而是与序列号一致的情况,个人认为应该是该主机端系统的处理机制与大部分系统不一样导致的。
另外,我们也看到了wireshark的专家系统在此处给出了提示,由此可见wireshark在传输层的专家系统的强大之处。
为什么前后RST报文会出现这种差异?
原因为第一个RST报文是异常释放TCP连接的,在端系统发送RST报文之前,这个TCP连接尚在端系统的连接表中,因此其ACK位置一并且具有ACK确认号。而客户端后续收到DATA报文,因其连接表中已经没有相关信息与之对应,此时客户端发送的RST报文ACK位无需置一。
也许有朋友会问:服务器端为什么在收到客户端的RST报文后,还继续给客户端发送报文呢?
原因只有一个,那就是TCP成块数据流。服务器端一次性向客户端发送数个数据块,在客户端发出第一个RST报文之后,后续的报文已经在网络中传输了,并陆续达到客户端。
其交互过程大致如下:
标签: TCP wireshark RST ACK 连接表 TCP成块数据流 端系统 ACK确认号 连接
- 多次RST以及不同场景下的RST报文的差异
- 客户端多次RST以及不同场景下的RST报文的差异
- TCP 的RST 报文
- rst是复位报文 几种TCP链接中出现rst的情况
- Wireshark抓取TCP报文类型为RST的方法
- 分析tcp-rst数据报文产生场景以及判断谁主动断开连接
- 什么是rst以及rst攻击
- rst
- TCP/IP详解--发送ACK和RST的场景
- TCP/IP详解--发送ACK和RST的场景
- TCP/IP详解--发送ACK和RST的场景
- 几种TCP连接中出现RST的场景分析
- 唯快不破:TCP/IP详解--发送ACK和RST的场景
- 发送RST报文
- RST复位报文段
- RST复位报文段
- RST复位报文段
- RST复位报文段
- Ubuntu14.04kylin安装QT
- windbg_cmd
- hogan 2014 donna "too low Meimou treatment
- 基于C++有限状态机的实现技术
- 一个用于白名单服务的布隆过滤器(bloom filter)
- 多次RST以及不同场景下的RST报文的差异
- 验证学号相关问题(异常)
- 提供android 5.0 AOSP源码下载
- Wireshark图解教程(简介、抓包、过滤器)
- linux install 命令
- UVa 140 Bandwidth(DFS 回溯 剪枝)
- 自己选择的路、跪着也要走完
- 15个优秀的 Nosql 数据库
- servlet学习笔记