Wireshark TS | DNS 案例分析之外的思考

2024-03-24 07:04

本文主要是介绍Wireshark TS | DNS 案例分析之外的思考,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前言

承接之前一篇《Packet Challenge 之 DNS 案例分析》,在数据包跟踪文件 dnsing.pcapng 中,关于第 4 题(What is the largest DNS response time seen in this trace file? )的分析过程中曾经碰到一个小问题,主要是数据包中存在部分 DNS 查询数据包重传的现象,因此对于 DNS 响应时间的计算可能就有一点不同的见解。

问题

譬如 No.1-4 数据包,No.1 为起始 DNS 查询,No.2 为 DNS 查询的第一次重传,No.3 为 DNS 查询的第二次重传,No.4 为 DNS 响应,那么 DNS 响应时间是 No.4 和 No.1 的差值?还是 No.4 和 No.3 的差值?

关于上述问题的场景,实际上类似 TCP 超时重传中关于 RTO、RTT 如何选取的问题,如下图。

image.png

重传时间的选择是 TCP 最复杂的问题之一,本篇不再展开。

而对于像 dns.timehttp.time 等这些关乎应用性能指标的字段值,倒是没有那么讲究。在 Wireshark 中这样的类似字段,以 [ ] 标注的,实际上并不是数据包本身的实际字段。对比数据包 DNS 响应中的 Transaction IDFlags 等真实字段,可以看到如下:

  1. [Request In: 7] Wireshark 根据上下文提示该 DNS 响应数据包所对应的请求在 No.7 数据包;
  2. [Time:0.037583000 seconds] Wireshark 根据上下文计算出该 DNS 响应数据包和请求数据包之间的时间间隔为 0.037583000 秒。

image.png

分析

再回到 DNS 这个案例上,Wireshark 根据 Transaction ID0x0f39 对应出 No.7-9 为一组 DNS 请求和响应,其中 No.7 为第一次查询,No.8 为第二次查询(也就是重传,Wireshark 会标记提示为 DNS 查询重传,原始请求在 No.7),No.9 为查询响应。

Wireshark 对于 dns.time的取值是 0.037583000 秒,这个是 No.9 和 No.7 的时间间隔,也就是 0.015479000 加上 0.022104000 的结果,因此 Wireshark dns.time 的算法是第一次查询以及响应数据包之间的间隔时间

image.png

其次根据显示过滤表达式,可过滤出和域名相关的所有 DNS 请求和响应,如下。

dns.qry.name == "www.paypal.com"

包括 6 次完整请求和响应,且每次均有重传请求,其中第 5 次还包含有两次请求重传,因此 dns.time 时间较长,超过了 1 秒。

image.png

在 Statistics -> DNS 中,也可以看到相关请求-响应时间,最小 36.8ms 至最长 1041.9ms,平均 212.63ms。

image.png

通过 tshark 也可以输出相关 dns 字段值。

λ tshark -r dnsing.pcapng -Y 'dns.qry.name == "www.paypal.com"' -T fields -e frame.number -e dns.id -e dns.flags.response -e dns.time
7       0x0f39  0
8       0x0f39  0
9       0x0f39  1       0.037583000
10      0x5644  0
11      0x5644  0
12      0x5644  1       0.036807000
40      0x4fa0  0
41      0x4fa0  0
42      0x4fa0  1       0.039575000
88      0x7964  0
89      0x7964  0
90      0x7964  1       0.042819000
110     0xaf9f  0
111     0xaf9f  0
112     0xaf9f  0
113     0xaf9f  1       1.041903000
119     0xc8c8  0
122     0xc8c8  0
125     0xc8c8  1       0.077093000

深入

实际上,对于 DNS 请求和响应的关联,我更愿理解是最后一次 DNS 重传请求和响应之间是对应关系,这样所计算出来的 dns.time 会更小,理论上应该也更精确。

因此对于 DNS Transaction ID 值 0x0f39 的一组,计算 No.8 和 No.9 的间隔时间,也就是 dns.time 的值 22ms

image.png

以上都是手工计算,那么对于整个数据包跟踪文件中,存在很多 DNS 请求响应对的,如何得出所有的 dns.time,可通过如下方式输出相关过滤后的数据包。

tshark -r dnsing.pcapng -w test1.pcapng -Y `tshark -r dnsing.pcapng -Y 'dns.qry.name == "www.paypal.com"' -T fields -e frame.number -e dns.id -e dns.flags.response | sort -rn  | uniq -f 1 | sort -n | awk '{printf("%sframe.number==%d",sep,$1);sep="||"}'`

image.png

通过 tshark 也可以输出相关 dns 字段值。

λ tshark -r test1.pcapng -T fields -e frame.number -e dns.id -e dns.flags.response -e dns.time
1       0x0f39  0
2       0x0f39  1       0.022104000
3       0x5644  0
4       0x5644  1       0.021225000
5       0x4fa0  0
6       0x4fa0  1       0.023975000
7       0x7964  0
8       0x7964  1       0.027038000
9       0xaf9f  0
10      0xaf9f  1       0.026070000
11      0xc8c8  0
12      0xc8c8  1       0.061571000

进阶

在上述分析章节中说到,Wireshark dns.time 的算法是第一次查询以及响应数据包之间的间隔时间,也就是说默认没有考虑有重传请求的存在。

但终究 Wireshark 还是考虑到了这样的场景,在 Perferences -> Protocols -> DNS 中,有如下的选项可以使用:

image.png

也就是说重传之间允许的秒数,该选项默认是 5s,也就是 5s 以内的相同请求,都算成是重传请求,而如果全是重传请求的话,则 dns.time 就是第一次查询以及响应数据包之间的间隔时间。

如下,默认 5s 的情况,No.112 在 2s 之内,所以仍是重传请求,dns.time 值 No.113 和 No.110 的间隔时间为 1.041s

image.png

如果选项 Number of seconds allowed between retransmissions 值改为 1s 呢,那么结果如下,No.112 在 1s 之外,所以不再是重传请求,因此 dns.time 值就变成 No.113 和 No.112 的间隔时间为 0.026s

image.png

那么再如果选项 Number of seconds allowed between retransmissions 值改为 0 呢,那么结果如下,自然也就不存在所谓的重传请求,这样也就直接达到了深入章节中的脚本效果。

image.png

image.png

总结

以上就是在之前 DNS 案例分析中延伸出来的一点思考,选项 Number of seconds allowed between retransmissions 供参考使用。

这篇关于Wireshark TS | DNS 案例分析之外的思考的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/840805

相关文章

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

客户案例:安全海外中继助力知名家电企业化解海外通邮困境

1、客户背景 广东格兰仕集团有限公司(以下简称“格兰仕”),成立于1978年,是中国家电行业的领军企业之一。作为全球最大的微波炉生产基地,格兰仕拥有多项国际领先的家电制造技术,连续多年位列中国家电出口前列。格兰仕不仅注重业务的全球拓展,更重视业务流程的高效与顺畅,以确保在国际舞台上的竞争力。 2、需求痛点 随着格兰仕全球化战略的深入实施,其海外业务快速增长,电子邮件成为了关键的沟通工具。

【区块链 + 人才服务】区块链集成开发平台 | FISCO BCOS应用案例

随着区块链技术的快速发展,越来越多的企业开始将其应用于实际业务中。然而,区块链技术的专业性使得其集成开发成为一项挑战。针对此,广东中创智慧科技有限公司基于国产开源联盟链 FISCO BCOS 推出了区块链集成开发平台。该平台基于区块链技术,提供一套全面的区块链开发工具和开发环境,支持开发者快速开发和部署区块链应用。此外,该平台还可以提供一套全面的区块链开发教程和文档,帮助开发者快速上手区块链开发。

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

MOLE 2.5 分析分子通道和孔隙

软件介绍 生物大分子通道和孔隙在生物学中发挥着重要作用,例如在分子识别和酶底物特异性方面。 我们介绍了一种名为 MOLE 2.5 的高级软件工具,该工具旨在分析分子通道和孔隙。 与其他可用软件工具的基准测试表明,MOLE 2.5 相比更快、更强大、功能更丰富。作为一项新功能,MOLE 2.5 可以估算已识别通道的物理化学性质。 软件下载 https://pan.quark.cn/s/57

【编程底层思考】垃圾收集机制,GC算法,垃圾收集器类型概述

Java的垃圾收集(Garbage Collection,GC)机制是Java语言的一大特色,它负责自动管理内存的回收,释放不再使用的对象所占用的内存。以下是对Java垃圾收集机制的详细介绍: 一、垃圾收集机制概述: 对象存活判断:垃圾收集器定期检查堆内存中的对象,判断哪些对象是“垃圾”,即不再被任何引用链直接或间接引用的对象。内存回收:将判断为垃圾的对象占用的内存进行回收,以便重新使用。

衡石分析平台使用手册-单机安装及启动

单机安装及启动​ 本文讲述如何在单机环境下进行 HENGSHI SENSE 安装的操作过程。 在安装前请确认网络环境,如果是隔离环境,无法连接互联网时,请先按照 离线环境安装依赖的指导进行依赖包的安装,然后按照本文的指导继续操作。如果网络环境可以连接互联网,请直接按照本文的指导进行安装。 准备工作​ 请参考安装环境文档准备安装环境。 配置用户与安装目录。 在操作前请检查您是否有 sud