Unicorn Tutorials

问题背景 来自于朋友分享的一个案例，某某客户反馈电脑应用软件使用时打开很慢，并提供了一个慢时所捕获的数据包文件以及服务端 IP。以前也说过，所谓的慢有很多种现象，也会有很多原因引起，在没有更多输入条件的情况下，拿到一个数据包捕获文件，如何判断分析，包括一些个人的习惯或者经验，就此简单记录下。 问题信息 数据包跟踪文件信息主要如下： 客户端为 win 7 64 位系统（相当的老。。硬件也老），通过 Wireshark 捕获数据包，捕获时长 246s，数据包数量 8976，文件大小 6913kB，平均速率约 224kbps，总体上来说速率很低。 根据 Wireshark 统计功能，可以关注下协议分层和会话等信息。其中协议方面 IPv6 占到 73.1%，IPv4 中 TCP 占 20.6%，具体到 TCP 通讯会话，可以看到 TCP 会话数量 88 算是很多了。 题外话，如果不是说用户提供了服务器 IP，在这些茫茫多的数据包中是很难找到真正想要的信息，这也扯到常见的话题，在复杂的客户端流量情况下，如何有效地进行捕获过滤。 之前有提到过复杂的客户端流量，关于捕获上的使用错误，说的是需要避免无效流量。作为服务器端自然不用说，流量更多是来自于实际业务，而客户端就比较有讲究了，更多针对的是办公电脑客户端场景，这种情况下由于自身多应用程序的运行，会产生很多的无效流量，干扰后期的分析。 虽然说分析时可以通过显示过滤表达式过滤，但与其这样，在捕获时保持一个纯粹的故障测试环境，岂不是更好，该关的程序能关则关。 专家信息中也是同样的问题，在客户端复杂流量的情况下，专家信息极其繁杂，并不能很好的辅助判断分析。 因此在类似复杂客户端流量的情况下所捕获的数据包文件，可以通过显示过滤表达式过滤掉部分数据包，格式大同小异，如下可参考 问题分析 过滤 根据提供的服务器 IP，构建会话 IPv4 过滤表达式。 这样精准过滤后，统计中协议分层和会话信息缩减如下，TCP 数据包 367 个，服务端口 7001 的会话共 4 个，分别为 TCP Stream 1,…