tcp,icmp,http 基于wireshark报文分析快速过滤报文时延 _wireshark

虚拟网络运维––基于wireshark报文分析快速过滤(tcp,icmp,http)报文时延前言在网络运维中，在报文分析时，时延类问题是比较常见的问题场景，如何快速定位到高时延的报文就会比较有用；这里简单介绍一下基于wireshark快速过滤tcp、http、icmp协议报文的高时延报文；
文章原创输出，请认准作者[[海渊_haiyuan]]，感谢；
tcp协议高时延报文定位在过滤tcp协议报文的高时延报文时，就不得不提到两个字段：
Time since first frame in this TCP stream # 自此TCP流中第一帧以来的时间，tcp.time_relativeTime since previous frame in this TCP stream# 距此TCP流中的上一帧的时间，tcp.time_delta如下图所示：

文章插图

可能部分wireshark 展开tcp协议后无法看到这两个字段；是需要在首选项配置时，进行一下配置，需要勾选“Calculate conversation timestamps”;如果是windows平台下，支持中文的话，就是首选项；

文章插图
【tcp,icmp,http 基于wireshark报文分析快速过滤报文时延】
勾选该字段后，即可在tcp协议层看到该字段；
如前面所讲，这两个字段分配代表一条tcp流中，该帧报文和上一帧报文的时间间隔；该帧报文和所在tcp流的第一帧报文的时间间隔；也就是说这两个字段是代表是一个相对的时间差；
取值来自wireshark中Time那一列，由该列中的时间戳的值相减得到，有关该列的详细说明可见我的其他文档有说明；这里需要提醒的一点是time这列的值，这个时间戳是取值与OS 系统的当前时间，所以在多个节点抓包分析时延时，由于每个机器的OS时间会存在偏差，或大或小，分析时需要将这个因素考量进去，不然会对时延的分析产生极大的干扰，这一点本人曾经吃过亏；
当时是一个高时延的场景，两台物理机之间的复现问题时延是在十几秒；而两台机器的OS时间又相差10s左右；导致抓包分析时，从报文计算的时延只有几秒，而客户端的请求统计却有十几秒；导致没有通过报文精准计算出高时延的链路段，走了很多弯路；
应用为列，快速过滤较大时延：
选中字段“Time since previous frame in this TCP stream”，右键选择“Apply as Column”应用为列；

文章插图

文章插图

然后点击wireshark 列名，wireshark工具就会自动进行从小到大的排序，再点击一下就是从大到小的排序：

文章插图

文章插图

这样就可以快速看到高时延的报文，然后右键追踪流即可详细查看该数据流的情况；
过滤器表达式筛选高时延报文：
可以在wireshark官网查看相关字段对应的wireshark过滤器名称，
https://www.wireshark.org/docs/dfref/t/tcp.html

文章插图

或者直接选择对应字段右键选择“Apply as Filter” 或 “Prepare as Filter” 以及后面的各种条件；

文章插图

实际运维中，常用的场景时，过滤ip为192.168.1.121，tcp协议，时延大于1s 的报文，过滤表达式即为：
ip.addr == 192.168.1.121 and tcp and tcp.time_delta >= 1

文章插图

http协议高时延报文定位http协议是基于tcp协议的7层应用层协议，所以前面所有的tcp报文时延分析同样适用；
不过对于http请求来说，实际场景中也是需要只分析http层的时延，即http request 报文和 http response 报文的时延计算；
这是由于，很多http的 request 和 response 报文中，会有tcp ack 确认报文、tcp psh数据传输报文；
以下图为例：
如果只需要计算http request 和 http response 的时延，即 frame 532 time - frame 526 才是这次http response的时延；