18 | 偶发性问题如何排查？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了使用 tshark 命令行工具进行网络排查和分析的方法。作者首先指出了排查过程中的两个常见误区，然后提出了针对偶发性问题的重现和排查策略，包括预估问题出现的时间跨度、抓包时长的确定、定时观察和导出抓包文件等步骤。通过一个实际案例展示了如何利用这些策略来解决偶尔网站变慢的问题。文章还介绍了如何在网络视角上精确定义问题，并使用 tshark 实现对大量 HTTP 事务的性能分析。通过过滤器和自定义列，读者可以方便地进行数据分析和统计，从而快速定位问题。最后，文章提到了可能存在的其他排查可能性，并指出了相应的解决方法。整体而言，本文提供了实用的排查方法和技巧，对于面临类似问题的读者具有一定的指导意义。文章还提到了 tshark 在命令行形式下的优势，以及如何利用 tshark 对大量 HTTP 事务的耗时进行统计，为问题排查和性能调优提供帮助。文章内容丰富，技术性强，对读者进行了全面的指导和启发。
《网络排查案例课》，新⼈⾸单¥59
全部留言(8)
- 最新
- 精选
分清云淡tshark、tcpdump常用案例我整理了文字版放这里了：https://www.weibo.com/1667773473/LrrLQirmv 基本上我们的服务器模板里必备这些，紧急情况下让远程复制粘贴就行作者回复: 确实，很多命令全记住也不容易，我也有很多小本本：）
2022-05-2124
那时刻请问老师，[Time since request: xxx seconds]对应于 http.time，这个对应关系在哪里可以查找到呢？作者回复: 你把[Time since request: xxx seconds]右单击选择apply as column，然后主窗口里多了一个列。你对这个列右单击选择edit column，就能看到它的fields里面的内容就是http.time了~
2022-03-0223
晴天了有一个疑问 问下老师. 场景: 客户端a 请求 nginx b. nginx b将请求通过tcp转发给php-fpm c 开启的9000端口. 问题: a 到 b的http包可以抓到. 但是b到c的请求我就不知道该怎么筛选了. 目前想到的办法是将http的内容转为16进制, 然后在wareshark通过data.data contains hexString 进行筛选. 但是http是分段的, 有时可能会抓不到. 老师有没有更准确的办法教授一下 感谢.作者回复: 你好，这里应该是两个不同的TCP连接： 连接1：a到b 连接2：b的nginx到b自己的php-fpm，通过本地的TCP 9000端口 HTTP事务是在这两个中传输的时候，大部分信息是不变的，特别是payload。所以你可以尝试我在第17讲介绍的方法，当时也是在HAProxy两侧不同TCP连接中定位同一个HTTP事务。具体来说就是利用下面这种过滤器，在连接1和连接2中分别找到它： tcp contains "xxxx"
2022-03-2822
Bachue Zhou抓包常态化的误区，搞技术的人都能理解，偏偏某些领导无法理解或不愿意理解。作者回复: 这种情况是有点无奈。不过可以换一个想法，看看领导的诉求是什么。“常态化抓包”是目标还是手段？看看领导的目标具体是什么，达成这个目标的手段可以是什么，可以不是什么？ 我们常犯的错误，是把手段当成了目标：）
2022-11-01归属地：上海21
Realm1 tshark -R "tcp.analysis.retransmission || tcp.analysis.out_of_order" 通过-R 指定过滤条件，抓重传和乱序的包 2 双向抓包对比，确认是否有重传；作者回复: 两个都对了，厉害了！tshark的功能确实很强大，也很实用，在后续课程里会继续介绍的
2022-03-021- kissingers最终还是通过抓包来分析的，有没有这类问题不通过抓包，比如通过现象--->可能原因分析---->找到原因比如配置等问题的案例分享
作者回复: 这种案例当然有，不过有点过于经验性，我希望这个课程是提供一种具体到细节和原理性的分析。这种分析方法应该是要掌握的，即使你到后期可以做到“通过现象--->可能原因分析---->找到原因”，但脱离了这个抓包分析的能力，就有点不扎实。各种软件的配置项都会变化，我们需要学习的知识最好要少一些“偶然性知识”（比如某个软件的某个配置叫某个名字，在它的值为某个数字的时候会出现某种问题），而多一些“必然性知识”（网络协议是十多年二十多年都不会有大的改变的）。
2022-05-10 
汤玉民老师 非常棒的课程作者回复: 谢谢你的支持：）
2022-03-29
JianXu看到这里我觉得抓包对老师来说基本上就是“瑞士军刀”。对于偶发性问题，监控数据挺重要的。我司就要全面上线SLB , Mesh … 节点多，还是分布式系统，排查偶发性问题更难了。作者回复: 是的，对于我们大规模应用，对各种数据源的依赖性更高。另外，跳数越多，排查复杂度越高，课程里的案例算比较简单的，大规模应用下的问题耗时更长，基本上少不了多次的来回，比如： 第一回：大致确定问题位置，比如是靠近客户端，还是靠近LB，还是靠近服务端 第二回：在这个相对小的范围里利用现有的日志或者打开新的debug日志，进一步缩小范围 第三回：上tcpdump等工具来定位根因
2022-03-21
