TCP(三)异常报文分析

流媒体播放中,常常需要借助wireshark从TCP层面对交互过程进行分析,本文记录一些常见的TCP异常报文及其分析。

乱序与丢包

1、[TCP Previous segment not captured]
[TCP Previous segment not captured]报文指的是在TCP发送端传输过程中,该Seq前的报文缺失了。一般在网络拥塞的情况下,造成TCP报文乱序、丢包时,会出现该标志。
需要注意的是,[TCP Previous segment not captured]解析文字是wireshark添加的标记,并非TCP报文内容。

例子:
流媒体服务器39.135.135.81,端口80,发送序号Seq=147154的包,长度Len=1360,那么下一个数据包序号应该为Seq=147154+1360=148514,可以看到客户端请求的也是Ack=148514。而服务器下一个包序号为Seq=149874,中间的包丢失了。
在这里插入图片描述

2、[TCP Out-Of-Order]
[TCP Out-Of-Order]指的是TCP发送端传输过程中报文乱序了。

例子:
继续上面的包分析,因为208142包序号为Seq=148514,而前一个序号为Seq=149874,故有此错误标志。
Seq=148514实际是208139包的响应,因为网络拥塞的情况下,TCP包不能按顺序到达,所以出现[TCP Previous segment not captured] 和 [TCP Out-Of-Order]标志。

3、[TCP dup ack XXX#X]
[TCP dup ack XXX#X]表示第几次重新请求某一个包,#前XXX表示第几个包(不是Seq),#后的X表示第几次请求。丢包或者乱序的情况下,会出现该标志。

例子:下图表示客户端一直请求101261的包。
在这里插入图片描述

重传

1、[TCP Fast Retransmission]
快速重传,一般快速重传算法在收到三次冗余的Ack,即三次[TCP dup ack XXX#X]后,发送端进行快速重传。
为什么是三次呢?因为两次 duplicated ACK 肯定是乱序造成的,丢包肯定会造成三次 duplicated ACK。
参考https://www.jianshu.com/p/4f2e412b0570

例子:
205113的包Seq=11154,重复请求4次后,发送端快速重传。至于为什么是4次,可能因为Ack包也有丢失。
在这里插入图片描述

2、[TCP Retransmission]
超时重传,如果一个包的丢了,又没有后续包可以在接收方触发[Dup Ack],或者[Dup Ack]也丢失的情况下,TCP会触发超时重传机制。

TCP超时重传参考https://www.cnblogs.com/duan2/p/9180861.html

例子:
在这里插入图片描述

TCP Window

1、[TCP ZeroWindow]
作为接收方发出现的标志,表示接收缓冲区已经满了,此时发送方不能再发送数据,一般会做流控调整。接收窗口,也就是接收缓冲区win=xxx ,告诉对方接收窗口大小。

例子:
传输过程中,接收方TCP窗口满了,win=0,wireshark会打上[TCP ZeroWindow]标签。
在这里插入图片描述

2、[TCP window update]
当接收端接收窗口大小发生变化,可以接收数据了,则有该标志。

例子:
接收方消耗缓冲数据后,更新TCP窗口,,可以看到从win=0逐渐变大,这时wireshark会打上[TCP window update]标签。
在这里插入图片描述

3、[TCP window Full]
作为发送方的标识,当前发送包的大小已经超过了接收端窗口大小,wireshark会打上此标识,标识不能在发送。

例子:
在这里插入图片描述

RST

TCP异常终止的常见情形

我们在实际的工作环境中,导致某一方发送reset报文的情形主要有以下几种:

1,客户端尝试与服务器未对外提供服务的端口建立TCP连接,服务器将会直接向客户端发送reset报文。

在这里插入图片描述

2,客户端和服务器的某一方在交互的过程中发生异常(如程序崩溃等),该方系统将向对端发送TCP reset报文,告之对方释放相关的TCP连接,如下图所示:

在这里插入图片描述

3,接收端收到TCP报文,但是发现该TCP的报文,并不在其已建立的TCP连接列表内,则其直接向对端发送reset报文,如下图所示:
在这里插入图片描述

4,在交互的双方中的某一方长期未收到来自对方的确认报文,则其在超出一定的重传次数或时间后,会主动向对端发送reset报文释放该TCP连接,如下图所示:

在这里插入图片描述

5,有些应用开发者在设计应用系统时,会利用reset报文快速释放已经完成数据交互的TCP连接,以提高业务交互的效率,如下图所示:

在这里插入图片描述

Reset报文的利用

1 安全设备利用reset报文阻断异常连接

安全设备(如防火墙、入侵检测系统等)在发现某些可疑的TCP连接时,会构造交互双方的reset报文发给对端,让对端释放该TCP连接。比如入侵检测检测到黑客攻击的TCP连接,其构造成被攻击端给黑客主机发送reset报文,让黑客主机释放攻击连接。

2 利用reset报文实施攻击

安全设备可以利用reset报文达到安全防护的效果,黑客和攻击者也可以利用reset报文实现对某些主机的入侵和攻击,最常见的就是TCP会话劫持攻击。关于TCP会话劫持的相关知识请参考第三章《TCP会话劫持》一文

  • 21
    点赞
  • 135
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
"TCP previous segment not captured"是指在网络数据包捕获过程中,某个TCP报文的前一个段未被正确捕获到。这可能是由于捕获设备或软件的性能限制或配置问题导致的。 在网络数据包分析和捕获过程中,使用抓包工具(如Wireshark)可以截获网络中的数据包,并提供对这些数据包的分析和解读。当出现"TCP previous segment not captured"的警告或提示时,意味着在捕获网络数据包时,某个TCP报文的前一个段没有被完整地捕获到。 这可能会导致在分析和重构TCP会话时出现一些困难。TCP协议是基于顺序传输的,每个TCP报文都依赖于前一个报文的正确接收和处理。如果前一个报文没有被完整捕获,可能会导致后续报文的重组和解析出现问题。 有几种原因可能导致"TCP previous segment not captured"警告的出现,包括: 1. 捕获设备或软件性能不足,无法及时处理大量的数据包。 2. 捕获设备或软件配置问题,未正确设置过滤规则或缓冲区大小。 3. 网络拥塞或高负载情况下,数据包丢失或延迟导致部分报文未能被捕获。 解决"TCP previous segment not captured"问题的方法包括: 1. 使用更高性能的捕获设备或软件,确保能够处理大量的数据包。 2. 检查捕获设备或软件的配置,确保设置正确的过滤规则和适当的缓冲区大小。 3. 在网络拥塞或高负载情况下,考虑增加带宽或优化网络配置,以减少数据包丢失和延迟。 请注意,"TCP previous segment not captured"只是一个警告或提示,可能不会对网络性能或应用程序产生实质性影响。但如果需要进行深入的网络分析和故障排查,确保准确捕获并解析所有TCP报文是很重要的。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值