Wireshark中常见的TCP Info

Wireshark中常见的TCP Info

1. TCP out-of-order segment

TCP存在问题。
Wireshark判断TCP out-of-order是基于TCP包中SEQ number并非期望收到的下一个SEQ number,则判断为out-of-order。因此,出现TCP out-of-order时,很大可能是TCP存在乱序或丢包,导致接收端的seq number不连续。
如下图,第4包数据,在客户端已经收到服务端的SYN ACK后,服务端再次发送了SYN ACK,wireshark将此包标记为out-of-order。
这里写图片描述
如下图,第7包数据,本应收到seq number为1366882的TCP包,但却收到了1044834的包,这包数据应该是晚到了,因此wireshark标记为out-of-order。
这里写图片描述
如果抓包中出现大量的out-of-order包,则说明网络存在较大的TCP乱序或丢包。

2. TCP Previous segment not captured

前一个TCP分段没有抓到。
在TCP连接建立的时候,SYN包里面会把彼此TCP最大的报文段长度,即MSS标志,一般都是1460.如果发送的包比最大的报文段长度长的话就要分片了,被分片出来的包,就会被标记了“TCP segment of a reassembled PDU”,这些包分片存在同样的ack number,且每个分片的seq number不同。
这里写图片描述
这些分片正常应该是连续接收的,即前一个分片指示的next seq number即为下一个收到的分片的seq number。假如收到的下一个分片的seq number与上一个比不连续的话,wireshark就会将该分片标记为TCP Previous segment not captured。如下图,ack number为705的TCP包被分为多个分片发送,其中有一个长度为1408的分片没有被抓到。
这里写图片描述
需要注意的是,前一个分片丢失,有可能是网络中确实丢失了,或者晚到了,也有可能是wireshark本身并没有抓到。

3. TCP Spurious Retransmission

TCP虚假重传。
当抓到2次同一包数据时,wireshark判断网络发生了重传,同时,wireshark抓到初传包的反馈ack,因此wireshark判断初传包实际并没有丢失,因此称为虚假重传。基于wireshark的判断机制,如果抓包点在客户端的话,虚假重传一般为下行包,因为这时,客户端在收到服务端的下行包后发送反馈ack,并被wireshark抓到,但很有可能服务端未收到此反馈ack,RTO超时,触发服务端重传。如下图,红框内出现了2次虚假重传,其中绿色的两条为同一包数据,粉色的两条为同一包数据。
这里写图片描述

4. TCP Retransmission

TCP重传。
当抓到2次同一包数据时,wireshark判断发生了重传,同时wireshark没有抓到初传包的反馈ack,因此,wireshark判定重传有效,标记为TCP Retransmission。基于软件的判定机制,如果抓包点在客户端的话,TCP重传一般为上行包,因为这时,客户端并没有收到服务端的反馈ack,无从知晓服务端是否收到了初传包,RTO超时后触发客户端重传。此时存在2种情况,即1)服务端收到了初传包,只是下发的反馈ack丢包,客户端没有收到;2)服务端没有收到初传包,因此也就没有下发反馈ack。对于第一种情况,如果抓包点在服务端的话,wireshark很有可能就会把来自客户端的重传包标记为TCP Spurious Retransmission。
如下图,红线的TCP包为重传包,wireshark为该包添加了重传原因,是由于TRO超时导致,以及初传包序号45,并给出了当前的RTO超时时间。
这里写图片描述

5. TCP fast Retransmission

TCP快速重传。
TCP协议设定了快速重传机制以避免过多的慢启动对传输速率的影响。快速重传通过接收到3个或3个以上重复的ack反馈触发。快速重传不需要等待RTO超时。如下图。
325包,客户端向服务端反馈ack=133251,说明下一个期望收到服务端seq=133251的包;
326包,服务端向客户端发送了seq=135771的数据包,与客户端的期望不符,因此客户端在327包重传了ack=133251的包,再次申明期望收到seq=133251的包。Wireshark将重复ack标记为TCP Dup ACK,#后边指明为第几次重传。
328包,服务端向客户端发送了seq=137031的数据包,仍然与客户端期望不符,客户端在329包再次重传ack=133251的包。
330包,服务端收到3次重复ack,触发快速重传,重传了seq=133251的TCP分片。
这里写图片描述

6. TCP Dup ACK

重复ack。
当网络中存在乱序或者丢包时,将会导致接收端接收到的seq number不连续。此时接收端会向发送端回复重复ack,ack值为期望收到的下一个seq number。重复ack数大于等于3次将会触发快速重传。如下图,
315包,客户端向服务端发送ack=126951的反馈,期望下一包收到seq=126951的TCP包。但下一包接收到的却是seq=128211的TCP包,由于seq不连续,wireshark将该报标记为TCP Previous segment not captured。
317包,客户端向服务端重复发送ack=126951的包,第一次重发,#后边带1。
318包,客户端收到seq=126951的TCP包。
319包,截止到seq=129471的所有TCP包全部收到,因此客户端回复了ack=129471的反馈。
这里写图片描述

7. TCP window update

TCP窗口更新。
当接收方的TCP window发生突变时,接收方通过TCP window update消息告知对方当前的接收窗口大小。如下图,TCP window Update同时携带了反馈ack,ack序列号与前一个反馈ack序列号相同,但这并不是重复ack。
这里写图片描述

8. TCP acked unseen segment

反馈ACK指向了一个未知的TCP片段。
这个意思是说ACK反馈的是一个wireshark上不存在的TCP包。很可能是wireshark漏抓了这个包,但却抓到了对端反馈的该报的ack包。如下图,标记为ack unseen segment的包反馈的ack=2721,看着像是反馈的seq=1361的包,但其实这个ack还反馈了seq=1的包,由于seq=1的包没有抓到,因此wireshark将反馈ack标记为ack unseen segment。从下面的图还可知,由于对端已经反馈了ack=2721,说明发端发送的seq=1的包,对端也收到了,只不过wireshark可能漏抓了而已。
这里写图片描述

9. TCP ZeroWindow

TCP滑动窗口为0。
当发送端发包速率大于接收端的接收速率时,会造成接收端TCP window越来越小,当接收端在反馈ack时携带的window size=0时,wireshark标记TCP Zero window。此时发送端将暂停发送数据,直到收到接收端window size!=0的标志。
这里写图片描述

10. TCP window full

TCP window满。
是指的发送端发送的数据已经达到的接受窗口的上限。发送端暂停发送,等待新的接收窗口的通告。
如下图,客户端向服务端发送的ack反馈,期望下一包收到的seq=288961,但接收窗口仅有960,服务端在收到ack后发送了960字节的数据,TCP window full。注意,len=1004是整个IP包的长度,需要减去IP头44字节,即960字节。
这里写图片描述

11. TCP RST

TCP 重置。
是TCP协议结束异常连接的一种方式,通过flog中的reset=1标记。当TCP连接无法通过正常的4次挥手结束时,一方可以通过发送携带reset标志的TCP包结束TCP连接。
如下图,发送方通过2个TCP流发送数据,截图中,接收方首先向发送方反馈了TCP window=0,让发送方暂缓发送数据,之后紧接着发送了TCP RST标记,释放了TCP连接。猜测可能接收方程序突然崩溃了,导致缓存区数据没法清空,之后接收方系统发送了TCP reset释放TCP连接。
这里写图片描述

wireshark源码分析问题这几天在看wireshark(ethereal)源代码。看源代码的主要兴趣点是它的分析模块(dissect)。分析之后他的数据存在哪儿,怎么打印的(-V参数)。我想把分析后的数据,提取出来,存在自己定义的数据结构里面,或者按我自己的格式写入文本。 看了几天,对一些数据结构,似懂非懂,一些流程也是似懂非懂。可能由于经验不足的原因,搞来搞去就在几个函数,结构体里面打转。好几次以为找到切入点,发现又回来原来的起点。 这两天看晕了。有点打击,水平太差劲了。。呵呵。先这边问问,看看有没有熟悉的朋友。指点一下。先谢谢了。 这样问问题可能太细了。感觉也不大合适。 1. 我应该如何来看代码?如何找到突破点? 2. 有wireshark有了解的朋友,说说你们关于源码剖析的体会。 3. 说什么都可以,朋友觉得对我有用,有启发就好。千万别 “我顶,UP啊”。呵呵:emn23:我觉得重要的是看 pcap库 本帖最后由 peidright 于 2010-04-02 16:36 编辑 楼上说得对!。 看源代码之前,问下你自己,看代码的目的是什么? 对于 wireshark 来说,你是想学他写界面? 还是抓包? 还是业务逻辑? 界面的话,wireshark 还行 抓包的话,应该看pcap库 业务逻辑的话。不应该看wireshark,看tcpdump.看下啊,:em03:看看这个也许对你有帮助 添加一个基础的RDP解析器 下面我们将循序渐进地设计一个基础的RDP解析器。它依次包含如下构成要素: 包类型字段(占用8比特位,可能的值为:1,初始;2,终结;3,数据); 标志集字段(占用8比特位:0x01,开始包;0x02,结束包;0x04先包); 序列号字段(占用16比特位); 1. 创建解析器 首先您需要选择解析器的类型:内置型(包含在主程序)或插件型。 插件是容易编写的,先做一个插件型解析器吧。 例1. 解析器初始设定. #ifdef HAVE_CONFIG_H #include "config.h" #endif #include #include void proto_register_rdp(); void proto_reg_handoff_rdp(); static void dissect_rdp(tvbuff_t *tvb,packet_info *pinfo,proto_tree *tree); static int proto_rdp=-1; static dissector_handle_t rdp_handle; static gint ett_rdp = -1; define TCP_PORT_RDP 3389 void proto_register_rdp(void) { proto_rdp=proto_register_protocol( "RDP Protocol", "RDP", "rdp"); } 现在来逐一分析这段代码。首先我们有一些常规的包含文件,最好依惯例在文件开始包含进来。随后是一些函数的前置声明,我们稍后定义它们。 接下来我们定义了一个整型变量"proto_rdp"用于记录我们的协议注册信息。它被初始化为"-1",当解析器注册到主程序后,其值便会得到更新。这样做可保证我们方便地判断是否已经做了初始工作。将所有不打算对外输出的全局变量和函数声明为"static"是一个良好的习惯,因为这可以保证命名空间不被污染。通常这是容易做到的,除非您的解析器非常庞大以致跨越多个文件。 之后的模块变量"TCP_PORT_RDP"则包含了协议使用的TCP端口号,我们会对通过该端口的数据流进行解析。 solaris10下proc编译问题 >紧随其后的是解析器句柄"rdp_handle",我们稍后对它进行初始化。 至此我们已经拥有了和主程序交互的基本元素,接下来最好再把那些预声明的函数定义一下,就从注册函数"proto_register_rdp"开始吧。 首先调用函数"proto_register_protocol"注册协议。我们能够给协议起3个名字以适用不同的地方。全名和短名用在诸如"首选项(Preferences)"和"已激活协议(Enabled protocols)"对话框以及记录已生成的域名列表内。缩略名则用于过滤器。 下面我们需要一个切换函数。 例2. 解析器切换. void proto_reg_handoff_rdp(void) { static gboolean initialized=FALSE; if(!initialized) { rdp_handle = create_dissector_handle(dissect_rdp, proto_rdp); dissector_add("tcp.port", TCP_PORT_RDP, rdp_handle); initialized=TRUE; } } 这段代码做了什么呢?如果解析器尚未初始化,则对它进行初始化。首先创建解析器。这时注册了了函数"dissect_rdp"用于完成实际的解析工作。之后将该解析器与TCP端口号相关联,以使主程序收到该端口的UDP数据流时通知该解析器。 至此我们终于可以写一些解析代码了。不过目前我们仅写点儿基本功能占个位置。 例3.解析 static void dissect_rdp(tvbuff_t *tvb,packet_info *pinfo,proto_tree *tree) { if(check_col(pinfo->cinfo, COL_PROTOCOL)) { col_set_str(pinfo->cinfo, COL_PROTOCOL, "RDP"); } if(check_col(pinfo->cinfo,COL_INFO)) { col_clear(pinfo->cinfo,COL_INFO); } } 该函数用于解析传递给它的数据包。包数据由"tvb"参数指向的特殊缓冲区保管。现在我们已深入到协议的细节,对它们您肯定是了若指掌。包信息结构参数"pinfo"包含了协议的基本数据,以供我们更新。参数"tree"则指明了详细解析发生的地方。 这里我们仅做了保证通过的少量工作。前两行检查UI"协议(Protocol)"列是否已显示。如果该列已存在,就在这儿显示我们的协议名称。这样人们就知道它被识别出来了。另外,如果"信息(INFO)"列已显示,我们就将它的内容清除。 至此我们已经准备好一个可以编译和安装的基本解析器。不过它目前只能识别和标示协议。 为了编译解析器并创建插件,还需要在解析器代码文件"packet-rdp.c"所在目录下创建一些提供支持的文件: - Makefile.am - UNIX/Linux的makefile模板 - Makefile.common - 包含了插件文件的名称 - Makefile.nmake - 包含了针对Windows平台的Wireshark插件makefile - moduleinfo.h - 包含了插件版本信息 - moduleinfo.nmake - 包含了针对Windows平台的DLL版本信息 - packet-rdp.c - 这是您的解析器原代码文件 - plugin.rc.in - 包含了针对Windows平台的DLL资源模板 "Makefile.common"和"Makefile.am"文件涉及到相关文件和解析器名称的地方一定要修改正确。"moduldeinfo.h"和"moduleinfo.nmake"文件的版本信息也需要正确填充。一切准备妥善后就可以将解析器编译为DLL或共享库文件了(使用nmake工具)。在wireshark文件夹下的"plugins"文件夹,建立"rdp"文件夹。将修改过的Makefile.common,Makefile.am,moduleinfo.nmake,moduldeinfo.h,Makefile.nmake及packet-rdp.c文件考到"rdp"文件夹下,然后进行编译,rdp插件自动生成完整,就可以正常工作了。 1. 解析协议细节 现在我们已经有了一个可以运用的简单解析器,让我们再为它添点儿什么吧。首先想到的应该就是标示数据包的有效信息了。解析器在这方面给我们提供了支持。 首先要做的事情是创建一个子树以容纳我们的解析结果。这会使协议的细节显示得井井有条。现在解析器在两种情况下被调用http://www.boomss.com:其一,用于获得数据包的概要信息;其二,用于获得数据包的详细信息。这两种情况可以通过树指针参数"tree"来进行区分。如果树指针为NULL,我们只需要提供概要信息;反之,我们就需要拆解协议完成细节的显示了。基于此,让我们来增强这个解析器吧。 例4 static void dissect_rdp(tvbuff_t *tvb,packet_info *pinfo,proto_tree *tree) { proto_item *ti=NULLV; if(check_col(pinfo->cinfo,COL_PROTOCOL)) { col_set_str(pinfo->cinfo,COL_PROTOCOL,"RDP"); } if(check_col(pinfo->cinfo,COL_INFO)) { col_clear(pinfo->cinfo,COL_INFO); } if(tree) { ti = proto_tree_add_item(tree, proto_rdp, tvb, offset, -1, FALSE);} } 这里我们为解析添加一个子树。它将用于保管协议的细节,仅在必要时显示这些内容。 我们还要标识被协议占据的数据区域。在我们的这种情况下,协议占据了传入数据的全部,因为我们假设协议没有封装其它内容。因此,我们用"proto_tree_add_item"函数添加新的树结点,将它添加到传入的协议树"tree",用协议句柄"proto_rdp"标识它,用传入的缓冲区"tvb"作为数据,并将有效数据范围的起点设为"0",长度设为"-1"(表示缓冲区内的全部数据)。至于最后的参数"FALSE",我们暂且忽略。 做了这个更改之后,在包明细面板区应该会出现一个针对该协议的标签;选择该标签后,在包字节面板区包的剩余内容就会高亮显示。 现在进入下一步,添加一些协议解析功能。在这一步我们需要构建一组帮助解析的表结构。这需要对"proto_register_rdp"函数做些修改。首先定义一组静态数组。 例5 定义数据结构 static hf_register_info hf[]= { { &hf;_rdp_version, { "TPKT Header:Version", "rdp.version",
WiresharkTCP功能主要用于抓取和分析经过电脑网卡的TCP数据包。 TCP是一种可靠的传输协议,但是在网络传输过程可能会出现分组失序、丢包和重传等问题,这些问题可能会导致TCP数据包的顺序错误或者不完整。对于这种情况,Wireshark在处理TCP失序时可能存在一些问题,其包括一些Bug尚未修复。因此,在使用Wireshark分析TCP包时,需要注意可能存在的顺序错误和不完整的情况。同时,Wireshark也提供了TCP报文的详细构成信息,可以帮助我们深入了解TCP协议的工作机制。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *3* [使用Wireshark浅析Tcp三次握手](https://blog.csdn.net/weixin_42931631/article/details/122165715)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v92^chatsearchT0_1"}}] [.reference_item style="max-width: 50%"] - *2* [WiresharkTCP-TLS-HTTP2协议栈解析研究](https://blog.csdn.net/qq_39091609/article/details/117363275)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v92^chatsearchT0_1"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值