14 案例篇 | TCP端到端时延变大，怎样判断是哪里出现了问题？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了在C/S架构中分析网络抖动问题的方法，并分享了实际案例。作者以MySQL业务为例，介绍了使用tcpdump抓包和tcprstat工具对MySQL协议进行抽象处理的方法，以简化分析过程。文章讨论了在生产环境中部署tcprstat的性能开销较大的问题，并提出了基于tcprstat的轻量级分析系统。通过具体案例分析，展示了如何通过抓包和分析工具来定位网络抖动问题的根源，以及如何针对性地解决这些问题。此外，还介绍了在虚拟机场景下如何判断抖动是发生在宿主机上还是虚拟机内部的方法。总结强调了tcpdump和TCP流关联、RT抖动问题分析工具的重要性，以及针对不同操作系统的合适工具选择。整体而言，本文对于处理C/S架构中网络抖动问题的技术人员具有一定的参考价值，尤其是对于延迟敏感的应用程序，提供了一些实用的解决思路和工具。
《Linux 内核技术实战课》，新⼈⾸单¥59
全部留言(13)
- 最新
- 精选
邵亚方置顶课后作业答案： - 结合这堂课的第一张图，在这张图中，请问是否可以用 TCP 流到达 B 点的时刻（到达 Server 这台主机的时间）减去 TCP 流经过 A 点的时刻（到达 Client 这台主机的时间）来做为网络耗时？为什么？ 很多同学在课后评论里都回答的很好了。比如： “主要原因是两边的时间不统一。 有可能客户端的时间比服务端的快。 只有选取相同的时间基点，算出的差值才有意义。” - 结合我们在“13 讲“里讲到的 RTT 这个往返时延，你还可以进一步思考：是否可以使用 RTT 来作为这次网络耗时？为什么？欢迎你在留言区与我讨论。 也不可以。 rtt时间不仅仅包含网络时间 还有内核软中断处理时间 另外还存在delayed ack，所以它不仅仅是网络传输耗时。2020-10-1110- Geek_circle老师好 有个现象帮忙看下如何分析定位下 centos7.2 长连接redis ，应用日志会显示无规律的出现hmget 间歇性超过200ms，最长达6s返回的情况，持续几分钟后恢复。后续要求定位， 主服务器不可中断， 不准部署抓包，安装bcc 感觉工具又可能消耗资源。排除了中间网络监控的问题 ，redis服务端也未发现超时的记录，怀疑系统层面的，是否有什么思路或者工具手段监控定位呢？
作者回复: 如果redis服务端未发生超时的情况，大概率是数据包阻塞在内核缓冲区太久导致的，也就是说数据包到达了内核缓冲区，但是redis没有及时读取它。没有及时读取的原因可能为： 1. 软中断打断redis 2. redis调度延迟 也可能会有其他原因。 排查思路也有的。这类问题我会有ftrace的kprobe_events机制来排查。比如追踪下面几个内核函数： - tcp_rcv_established ： 数据包到达内核缓冲区 - tcp_recvmsg： 数据包被应用读取 这两个时间戳相减就是数据包在内核缓冲区停留的时间。
2020-09-29210 
tianfeiyu老师，看评论里面多次提到 delayed ack，能详细给说明下这个参数的意义吗作者回复: delayed ack是用来延迟发送ack包的 这样的目的是为了提高网络传输效率 因为一个ack的数据是很小的 主要的数据都是tcp header，如果发送一个ack的话，有效信息就很小。所以一般都会等待有真正数据发送时 和数据一起传输，以减少header的传输开销。
2021-07-246
颛顼这个文中几个时间点，是怎么联系起来，来验证是同一个请求的？作者回复: 根据tcp的sequence number可以确定。就像tcpdump一样。
2021-07-152
我来也思考题2 RTT 是否可以作为这次网络耗时？ 好像不行吧。 看图好像是可以，毕竟就是tcp的一去一回。 但是这个还取决于对方返回ACK时是否及时。 有时ack是会合并的。有些内核参数好像还会延迟ack的返回时机吧。作者回复: 对的 rtt时间不仅仅包含网络时间 还有内核软中断处理时间 另外还存在delayed ack
2020-09-192
stackWarn1.请问作者公司线上机器都装了systemtap吗？ 2.这个systemtap脚本和模块以后会开源吗？作者回复: 1. 部分线上机器装了systemtap，特别是centos7的系统上；在centos8的系统上，我们一般是使用ebpf，比如bcc或者boftrace。 2. 目前还没有开源计划，但是该模块的一些思想以及一些关键的tracepont我在这个系列课程里都讲到了 如果你看到仔细的话你会找到，利用这些tracepoint你也可以实现类似的模块。
2020-09-191
王崧霁不可以，tcp有重传作者回复: 嗯 是的
2020-09-24- 我来也老师公司也在用CentOS7啊。 不知道有没有遇到过7.6版本的3.10.0.957内核bug，导致tcp的Send-Q居高不下的问题，哈哈。
作者回复: 主要是centos7，也有centos6和8，还有一些是Ubuntu。 这个问题倒没有遇到过。
2020-09-19 - 我来也思考题1 我觉得tcp流到B点的时间减出A点的时间做网络延迟 不合适。 主要原因是两边的时间不统一。 有可能客户端的时间比服务端的快。 只有选取相同的时间基点，算出的差值才有意义。 另外，因为TCP流会有很多Segment，可能一次请求就包含多个Segment，取哪一个或平均值，都不好实现。 而取同一个节点的时间，可以取最后一个发出去的报文和第一个发出去的报文来计算真实的时间。 毕竟数据只接收了一半，也是无法开始执行逻辑的。
作者回复: 是的！回答的很好。
2020-09-19 - stackWarnrtt统计的是tcp协议栈发出到收到的时间，包括客户端自身协议栈到发出网卡，网络传输，对方网卡接收并发到服务端协议栈，再经过返回流程到客户端协议栈的时间，rtt延时不能具体区分是哪个部分的问题。
作者回复: 是的 另外还存在delayed ack这种情况。
2020-09-19
