Wireshark TS系统吞吐慢问题解决方案

目录
  • 问题背景
  • 问题信息
  • 问题分析
  • 问题总结

问题背景

用户反馈一个场景,说是两个系统之间的吞吐很慢。吞吐量是系统性能分析中一个很重要的衡量指标,相关影响的因素也会有很多,因此反映在网络数据包分析上,也会是一个相对比较复杂的分析过程。

案例取自 SharkFest 2010《Packet Trace Whispering》

问题信息

跟踪文件基本信息如下:

λ capinfos EvilOddFinal.pcap
File name:           EvilOddFinal.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 8192 bytes
Packet size limit:   inferred: 64 bytes
Number of packets:   1004
File size:           80 kB
Data size:           1109 kB
Capture duration:    6.013219 seconds
First packet time:   2010-01-13 04:55:32.247712
Last packet time:    2010-01-13 04:55:38.260931
Data byte rate:      184 kBps
Data bit rate:       1475 kbps
Average packet size: 1104.69 bytes
Average packet rate: 166 packets/s
SHA256:              19cc103f13f74f8c3359f99c5ff883cce880361c823ff736c4b6d89d26e68b9e
RIPEMD160:           d879ea22aaff08a5b7a44ecd68b86cb71053bf46
SHA1:                afc170ee286153a9d9ce8dd19a9a4fe27d3df46b
Strict time order:   True
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 8192
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 1004
λ

跟踪文件在 linux 上通过 tcpdump 所捕获,数据包数量 1004 个,长度截断为 64 字节,文件数据大小 1109K 字节,捕获时长约 6 秒,平均速率 1475 kbps。

专家信息如下,异常简洁,可以看到没有任何一条 Warning 信息,像是重传、乱序等,在简单排除些常见性问题之后,真实原因就需要进一步实际分析了。

此外统计 - 会话信息如下,仅有一条 TCP 流,数据主要传输的方向是 10.10.10.10 -> 192.168.1.10,速率低,仅为 1451 kbps,确实符合吞吐慢的现象。

同样统计 - I/O Graphs 如下,有比较明显一段时间,前后没有任何数据传输,整体速率低。

问题分析

展开数据包跟踪文件的主视图,首先是 TCP 三次握手信息 。

简要分析如下:

  • IRTT 0.000339 秒,判断在一个局域网内;
  • 考虑到 SYN、SYN/ACK、ACK 的时间差,判断抓包点在服务器或者靠近服务器的地方;
  • 客户端 Win 64512,不支持 WS(Window Scale 因子);服务器 Win 32768 ,也不支持 WS;
  • 客户端和服务器 MSS 均为 1460,标准值;
  • 客户端和服务器不支持 SACK 等;
  • 客户端和服务器不支持时间戳。

由于该 TCP Stream 不支持 WS 和 SACK ,此处的低效率可能会是一个问题。

考虑到整体传输速率低以及 I/O Graph 图示结果,可以增加 frame.time_delta_displayed 信息列,检查数据帧之间的时间间隔,并从大到小依次排序。

可见有明显的一些大延迟,包括最大的 3.26s,多个 195ms 等等,依次分析:

  • 3.26s

来自于客户端 No.238 数据帧,Wireshark 也明显的指示出这是一个 TCP Window Update 数据包,为客户端的 Window 更新。

定位到 No.238 前后,可以看到数据传输方向是服务器端 10.10.10.10 -> 客户端 192.168.1.10 ,服务器发送多个 MSS 分段,客户端依次进行 ACK 确认。但在 No.237 的 Window 窗口明显持续降低至 436(可能是客户端的应用处理能力问题,使得窗口未能及时释放),由于接收窗口小于 1 个 MSS,使得服务器无法继续发送数据,直到客户端 No.238 发送的 Window 更新,之后服务器才继续发送数据。

故此处 3.26s 大延迟问题是 TCP Window 过小的原因,建议开启支持 TCP WS 或检查客户端性能解决低效率问题。

  • 195ms

195ms 同样是来自于客户端的延迟,展开其中一个 No.570 数据帧前后,也是可以看到数据传输方向是服务器端 10.10.10.10 -> 客户端 192.168.1.10 ,服务器发送多个 MSS 分段,客户端依次进行 ACK 确认。

客户端 No.569 ACK 确认 No.553,但在收到服务器应用所发送数据的最后一个分段 No.554 (带有 PSH 标志位),由于延迟 ACK 的机制,客户端在等待服务器的第二个数据包到达,但是刚好是应用发送的最后一个分段,奇数问题~ 所以延迟确认约 200ms 左右,客户端才发送了 No.570 ACK 。

虽然看起来仅延迟了 200ms,但随着数据传输的进行,会产生很多次类似这样奇数包的接收延迟确认(以下 No.632 同样),所以加总起来也是一段比较大的空闲等待时间。实际上延迟确认本身并没有什么问题,但视实际应用场景,也是可以通过设置像是 TCP_QUICKACK 选项来取消延迟确认。

延迟 ACK参考

TCP Delayed ACK(延迟确认)为了努力改善网络性能,它将几个 ACK 响应组合合在一起成为单个响应,或者将 ACK 响应与响应数据一起发送给对方,从而减少协议开销。 具体的做法:

  • 当有响应数据要发送时,ACK 会随响应数据立即发送给对方;
  • 如果没有响应数据,ACK 将会延迟发送,以等待看是否有响应数据可以一起发送;
  • 如果在等待发送 ACK 期间,对方的第二个数据包又到达了,这时要立即发送 ACK。但是如果对方的三个数据包相继到达,第三个数据段到达时是否立即发送 ACK,则取决于以上两条。

问题总结

所以总体来说,系统吞吐慢,不一定全是网络拥塞、丢包所产生的问题,TCP 窗口以及协议层面的一些机制,同样也有可能是原因所在。

以上就是Wireshark TS系统吞吐慢问题解决方案的详细内容,更多关于Wireshark TS系统吞吐的资料请关注我们其它相关文章!

(0)

相关推荐

  • Wireshark TS FTP 传输失败问题解决

    目录 问题背景 问题信息 问题分析 问题总结 问题背景 用户反馈说当与外部客户端进行 FTP 传输时,可以成功登录,但无法传输任何数据.总之 FTP 传输失败,需要来弄清楚到底发生了什么. 案例取自 SharkFest 2010<Packet Trace Whispering> 问题信息 跟踪文件基本信息如下: λ capinfos FTPFinal.pcap File name: FTPFinal.pcap File type: Wireshark/tcpdump/... - pcap Fi

  • c#.NET中日志信息写入Windows日志中解决方案

    1. 目的   应用系统的开发和维护离不开日志系统,选择一个功能强大的日志系统解决方案是应用系统开发过程中很重要的一部分.在.net环境下的日志系统解决方案有许多种,log4net是其中的佼佼者.  在Windows2000及以上操作系统中,有一个Windows日志系统,它包括应用程序(Application)事件日志.系统(System)日志和安全(Security)日志,事件日志也可以是自定义日志.在.net Framework中也提供了相应的类和接口来使用应用程序事件日志或者自定义事件日志

  • Mac GoLand打不开(闪退)也不报错的解决方案

    Mac用过GoLand,电脑应用初始化后就打不开了,下其他版本也不行 原因就是之前的配置文件还在需要清理: /Users/你的文件/Library/Preferences/ 配置文件在这个文件下 补充:Windows下Goland无法启动问题 最近使用Goland的时候遇到了无法启动的问题(双击启动程序后,无反应),使用的是Windows 10系统,查找网上解决方案后仍无法启动. 重装也无法解决问题,下面提供一种解决思路: 思路: 怀疑是系统有与Goland相关文件没有删除干净.把Goland卸

  • 如何理解软件系统的高并发

    概述 当前,数字化在给企业带来业务创新,推动企业高速发展的同时,也给企业的IT软件系统带来了严峻的挑战.面对流量高峰,不同的企业是如何通过技术手段解决高并发难题的呢? 引言 软件系统有三个追求:高性能.高并发.高可用,俗称三高.三者既有区别也有联系,门门道道很多,全面讨论需要三天三夜,本篇讨论高并发. 高并发(High Concurrency).并发是操作系统领域的一个概念,指的是一段时间内多任务流交替执行的现象,后来这个概念被泛化,高并发用来指大流量.高请求的业务情景,比如春运抢票,电商双十一

  • utf8和unicode编码究竟是什么关系?有何区别?

    UTF8 == Unicode Transformation Format -- 8 bit  是Unicode传送格式.即把Unicode文件转换成BYTE的传送流. UTF8流的转换程序:  Input: unsigned integer c - the code point of the character to be encoded (输入一个unicode值)  Output: byte b1, b2,b3, b4 - the encoded sequence of bytes (输出

  • 解读什么是防火墙

    一. 防火墙的概念  近年来,随着普通计算机用户群的日益增长,"防火墙"一词已经不再是服务器领域的专署,大部分家庭用户都知道为自己爱机安装各种"防火墙"软件了.但是,并不是所有用户都对"防火墙"有所了解的,一部分用户甚至认为,"防火墙"是一种软件的名称--  到底什么才是防火墙?它工作在什么位置,起着什么作用?查阅历史书籍可知,古代构筑和使用木制结构房屋的时候为防止火灾的发生和蔓延,人们将坚固的石块堆砌在房屋周围作为屏障,这种

  • 数据库备份 SQLServer的备份和灾难恢复

    各大服务器硬件厂商(IBM,HP等)提供有很好的数据保护策略(硬件或软件).如大家熟知的RAID磁盘阵列(Redundant Array of Independent Disks)就是很好的数据保护方法.就SQL Server而言,通过维护计划可以制定详细的数据备份计划. 数据备份策略(full backup, differential backup and  transaction log backup) 数据备份是为数据恢复服务的,所以建立数据备份计划之前,应先考虑是否能利用该备份有效的恢复

  • 路由器的关键技术

    近年来,互联网的发展异常迅猛,应用日益商业化,网上用户数的发展难以预测.此外,越来越多的用户需要高速接入.有关资料表明,在我国,上网速度慢是众多网民抱怨的首要问题.因此,提高网络带宽.网络服务质量.路由器上的网络管理系统变得日益重要.在保证质量的前提下,最大限度地利用带宽,及早发现并诊断设备故障,迅速方便地根据需要改变配置等网络管理功能,成为直接影响网络用户和网络运营商利益的重要因素.总地来说,路由器的结构正朝着速度更快.服务质量更好和更易于综合化管理三个方向发展. 路由器的两大功能 数据通路功

  • C# TSC打印二维码和条形码的实现方法

    效果图 开发.使用环境说明 安装TSC_7.3.8_M-3.exe打印机驱动,安装时选择对应的ttp 244 pro 将TSCLIB.dll复制到C:\Windows\system 驱动安装说明 选择下一步 选择安装路径,默认即可,选择下一步 选择安装打印机,选择下一步 选择其他,点击下一步 选择对应的打印机型号,点击下一步 选择USB端口,点击下一步 直接默认即可,点击下一步 驱动安装完成! TSCLIB.cs代码: using System; using System.Collections

  • SpringCloud Bus消息总线的实现

    好了现在我们接着上一篇的随笔,继续来讲.上一篇我们讲到,我们如果要去更新所有微服务的配置,在不重启的情况下去更新配置,只能依靠spring cloud config了,但是,是我们要一个服务一个服务的发送post请求, 我们能受的了吗?这比之前的没配置中心好多了,那么我们如何继续避免挨个挨个的向服务发送Post请求来告知服务,你的配置信息改变了,需要及时修改内存中的配置信息. 这时候我们就不要忘记消息队列的发布订阅模型.让所有为服务来订阅这个事件,当这个事件发生改变了,就可以通知所有微服务去更新

随机推荐