梦里花落知多少，网络抖动逃不了
作者 / 丁雪峰（花名：玄拙）
编辑 / 伯瑜 芹菜
出品 / 云巅论剑
食堂
“喂，喂，喂......”
睦晨回过神来，不好意思地对边上已经谢了顶的同事笑了笑。
同事安慰他：“你也别太操心了，这种问题是比较难查的，我们有时候真的很难把这种边界问题说清楚。”正说着，这位谢了顶的同事，又美美地喝了一口枸杞乌鸡汤。
人声鼎沸的食堂， 睦晨朝四周看了看， 叹气道：“肯定是他们那边数据有问题，为什么他们就不承认呢？”
谢顶的同事吹着汤碗上面的油花，回他：“那个有什么办法，nginx 的日志不能代表最终数据包离开机器的时间，他们就是在这个问题上扯皮啊！！！”
睦晨有些气愤，吃了两大口白米饭， 鼓着腮帮子说：“就末友神门絆砝了吗.....”（就没有什么办法了吗？）
“按说如果你们组再没有进展，数据比不过其它厂家，客户就要选择其它厂家或者要求我们公司降价了吧。" 同事喝了一口汤。
“要我说啊，客户也是有病，就差个 50ms，有什么关系，一般用户还真能感知到不成.....”。同事吧啦吧啦地吐糟着。
睦晨没心思听同事的吐糟，主要是他自己主动想解决这个问题，他老大也特别着急。用户拿着其它厂家的对比数据，找过来说睦晨公司的数据的接口响应时间比其它的提供类似服务的厂家要慢 50ms。
虽然大家都知道，对方就是想压价，但是问题不能解决就公司就没有主动权，睦晨自己也测试了一下，量少的情况下根本就测不出来，但是用户的真实数据量大，平均值就会差一些，并且用户只告诉公司最后的平均数据就是不同意给出每一个客户端设备上采集的原始日志。上午老大被老板叫到办公室谈了一个小时，看得出来老大也有些无计可施了。
公司
吃完饭，回到公司，老大叫住了睦晨，再讨论了一下。现在的问题在于，我们这边 nginx 的日志显示，我们处理时间，还有响应都是没有问题的，但是我们发包这个地方有一个情况就是，一般的响应大小只有 100k 不到，这些数据 nginx write 到内核的时候基本都是一次就完成了，都缓存在内核了，所以我们统计到的数据发送数据时间基本都是 0。这个就是问题的核心。问题就在于内核在发送数据的时候可能遇到了一些问题，导致数据发送比较慢，所以用户接收的时间变长了，但是我们对这块的信息是没有记录的。
老大：“睦晨啊，你再测试看看，看看能不能找到什么其它的线索。”
睦晨：“好的，老大，上次压测的数据，他们也不承认吗？”
老大：“不行，他们说那不是正常的业务流量，他们采集的是业务流量就是有问题，我们进行压测的数据正常也不能说明什么？”
“他们这就是在赖皮！！！” 睦晨有些气急。
老大：“其实我大概知道问题在哪里？”
睦晨一惊：“真的吗？怎么老板没有讲啊！！“
老大：“我估计是有小运营商的数据混在里面了，因为我们是用户域名的默认解析，用户只是把电信一些省的数据给了其它厂家。所以理论上所有的小运营商的请求都在我们这边。但是我也只是猜测，没有数据做不得数啊！”
老大：“nginx 的信息，内核还有 buffer，响应包不大，发送都是一次性就传递给内核了，发送时间都是 0，丢包信息也是整机的，要是可以有每一个流的信息就好了。”
老大也揉了揉太阳穴：“唉，我现在也没有什么办法了，你去忙吧。”
睦晨欲言又止，半天再说：“老大，你还没吃吧，我去给你买个外卖吧！”
老大摆摆手：“没什么胃口。”
睦晨：“哦！”
眉目
睦晨，忙了一个下午，没有什么方向，回头看看，老大扶胸皱眉。就在同学大群里请教了一下技术上有没有什么办法：
同学 A：睦晨也没有办法，我们能怎么办？
同学 B：是啊，睦老大我这还有几个问题想请教你呢，什么时候带带我啊？
同学 D：可惜守出是万年潜水，听说是去了阿里吧。真羡慕啊！
同学 C：话说，睦晨为什么去这家小公司啊？
同学 A：我知道，我知道，我见过他老大，大美女啊......
同学 B：是吗？
同学 C：求照片。
同学 Z：老 A 又在造谣了，他们一个天南一个地北，他见个鬼啊！
同学 E：求照片。
同学 F：无图无真像。
同学 G：求照片。
................
楼已经歪了，睦晨嘴角抽了抽，就去吃晚饭了，先不管这帮同学了。
刚吃了两大口白米饭，居然收到同学 Z 的消息：“你可以试试 Alibaba Cloud Linux 2 里面有一个 TCP RT 模块。我之前听守出说的。”
睦晨如同久旱逢甘雨，忙问道："这个 TCP RT 做什么用的？"
同学 Z：说是可以采集 tcp 在内核的一些消息。具体的我也不清楚。
睦晨想了一下，冷静下来分析了一下：感觉没用，我们是长连接，要每一个请求的详细数据，只是 tcp 的数据没有什么用的。一个连接基本要完成几百次请求，需要每一个请求的详细数据。
同学 Z：好吧。那你再找找其它的办法吧。
睦晨又看了一晚上的资料，核心的问题还是不能解决。
峰回路转
晚上九点，加班人下班了，群里又在要照片了，睦晨趁人多又问了一次有没有同学有办法。 就没再管群里的这些同学了。突然一条私信消息惊醒了正在发呆的睦晨，一看是班里的学霸，去了阿里的守出同学：“你试过 Alibaba Cloud Linux 2 里面的 TCP RT 模块吗？”
睦晨有些吃惊，又是这个 TCP RT 回到：“同学 Z 和我说过了，我们要每一个 tcp 里面的请求的详细数据，tcp 的数据虽然也很有用，但是估计是不行的，没有直接的数据说服不了我们客户！”
学霸的专属语气：“没有调查没有发言权。TCP RT 可以自动识别出来 tcp 连接上面传递的请求还有响应。”
睦晨一愣：“这么神奇！”
睦晨：“什么请求都能识别吗？有些神奇啊！出忽我的意料啊！”
守出：“正常只能识别 请求 -> 响应，这样模型，如果是 http2 那种同时多个流的情况就不行了，这个是最大的限制。”
睦晨：“http1.1 还有 https 还有 mysql 可以吗？我们线上主要是这几种服务。”
守出：“都可以的。”
睦晨：“能做什么呢？虽然能自动识别请求和响应很神奇，但是有什么用呢？”
守出：“可以采集一个请求响应花的时间，请求和响应分别多少字节，请求响应过程中有没有重传，请求和响应的时间等等。”
睦晨有些兴奋了，用力挥了挥手，冷静了一下问到：“这个请求和响应的时间不是应用层传递给内核的时间吧。那样的话没什么用啊？”
守出：“是数据包离开机器的时间。”
路转峰回
“耶！！”
睦晨，非常兴奋，本来只是随便找同学问问，没想到还真有办法，真是柳暗花明啊。
开心地找到老大说明情况，老大还是比较冷静的：“我有几个问题——
1. 性能怎么样，我们目前只能测试实际业务，使用这个 TCP RT 会不会影响性能？
2. 这个工具稳定性，怎么样？内核模块使用起来还是要谨慎的，不然直接导致机器挂了也很麻烦？
3. 布署方便吗？这是一个内核模块，我们可能要换操作系统。”
睦晨一听，也冷静了下来，认真脸：“老大，你说得对，我再问问，一会我先线下测试一下？”
老大屏颜一笑：“我也是看你太兴奋了，给你泼点冷水。越是这个时候越不能太急燥了，引出故障就不好了。这几天也是辛苦你了，你仔细看看我刚刚说的几个问题，目前来看，这个工具应该有用，你看看我们能不能实际用得上。加油！！”
睦晨：“好的，老大。”
睦晨把三个问题抛给了守出。
守出很认真的说：“阿里大规模布署了很多年了，最近才开源出来。早几年还发了一篇顶会的论文！。”（论文：https://yq.aliyun.com/download/2718）
守出：“稳定性还是可以的。当然，你们公司有完整的发布流程吧。不会这个都没有吧。真不明白当初你怎么就被迷了心，去这个公司，和我一起来阿里不好吗？”
睦晨听了，撇撇嘴，守出还是和大学的时候一样，老古板，严肃脸，好为人师。难怪你没有女朋友！！
守出：“性能影响理论上是有的，但是实际测试数据来看，影响很小的。基本不会对业务性能产生影响。而且数据采集完了，你可以随时关闭这功能。”
睦晨这下放心了，问到：“这个使用方便吗？”
守出：“很方便的啊，加载模块，配置一下就可以了，从内核 /sys/kernl/debug/tcp-rt 下面直接读取文件就可以获得数据了。”
守出：“哦，当然了， 要先安装 Alibaba Cloud Linux 2 操作系统，安装完成了之后直接加载模块就可以了。你们服务是在阿里云上吗？如果是的话，开一台新机器选择最新的 Alinux2 就可以了。”
峰回路又转
睦晨：“它有什么要特别配置的吗？”
守出：“一般配置一个你们的服务端口就可以了，所有和这个端口建立的连接都会被监听。其它的连接就不会关心了。”
睦晨听了，感觉挺方便的，就准备测试一下。
守出：“我要下了，我女朋友来接我了。”
噗，虽然很感谢，嘴里还是说道：“见色忘义。”
“..... ^_^”
很快睦晨就开了一台新的 ECS，选择了最新的 Alibaba Cloud Linux2。很快机器启动之后，睦晨要安装公司的服务程序，但是这个时候，睦晨突然想起来了一个事情，这个客户很奇怪，居然要求服务端开了很多端口 8000-10000。他们请求也是很随机在这些端口上。这就麻烦了，TCP RT 守出好像说是配置指定的端口的啊，我这是端口范围啊。怎么办，发消息，守出也不回。这下麻烦，听着挺好的东西，居然不支持配置端口范围，什么破玩意。
经过一个白天的爆晒，楼下的柳树本来都有一些无精打采的样子，现在天气凉下来了，虽然柳枝向下，但是透着光的绿给人奋发向上的力量。
睦晨非常烦燥，研究了半天挺好的东西，到最后一步了，居然不支持端口范围。一个人在窗口看着外面的柳树，叫了一个外卖，等外卖的时间看着远处黑洞洞的夜也冷静了下来。拆开外卖，吃了几口白米饭，心想，不能放弃，这是我最接近成功的机会了。想起来，守出说是 Alibaba Cloud Linux 2 开源的项目，那应该有文档吧。睦晨放下外卖到阿里云官网找了一下，还真找到了：
https://www.alibabacloud.com/help/zh/doc-detail/181331.htm
仔细一看，还真支持端口范围，真不愧是应用多年的老项目啊，考虑还真全面，非常棒的项目。
睦晨变脸就和川剧一样。
扒了两口白米饭，开始干活了。
接着就在 /sys/kernel/debug/tcp-rt 下面找到了日志文件，测试了一下，发现没什么问题，数据很详细完全可以满足要求。
仿佛看到了光明，睦晨一点也不累。
睦晨很细心，又测试了一下模块的卸载，先执行了一下这个命令，守出说是这样之后新的连接就不会再使用 tcp rt 了，这样旧的连接都退出之后 tcp rt 就可以卸载了：
然后关闭了测试的连接，一会
就显示 tcp_rt 没有在使用了，执行
整个过程都很顺利，没有遇到什么问题。
然后睦晨就提了申请，老大也还在线把机器加入到了集群。一会就有大量的数据出来了，睦晨化身数据分析工程师。
结尾
老大：“老板，我们找到原因了。”老板刚刚到公司，老大就带着睦晨进了老板办公室。“睦晨，你给老板介绍一下情况。”
睦晨：“老板，是这样的，我们其实是客户的默认厂家，DNS 解析的时候，用户只是把一部分电信的客户切走并给了其它的厂家，而其它的小运营商的量其实都在我们这边。而就是这些小运营商的数据把我们的数据拖慢了。”
老板：“这么简单？之前怎么没想到。”
睦晨：“我们之前有猜测过，但是没有数据支撑。用户的响应其实很小，这导致我们 nginx 上统计的数据，所有的请求响应耗时都很短，看不出来差别。所以之前和用户提了，没有证据用户不认可。”
老板：“哦！这次是怎么就有证据了。”
睦晨：“我们从内核采集到了所有请求的发包的耗时，把慢的这些请求的过滤出来，基本都是小运营商的 ip。”
老大：“我已经和用户沟通过了，我把数据一摆，他们接受了。哈哈哈哈。”
睦晨：“只要把几个小运营端的数据过滤一下，我们的数据和其它的厂家的数据差不多，还要更好一点点。他们也确认了，所有的小运营商的量基本都是在我们这边，因为我们是他们配置的 DNS 默认解析。”
老大：“这些数据还可以挖掘一些其它的信息，我想要做一个平台，把这些数据实时导入进来，以后遇到这样的客户就不怕了。还可以用来监控我们日常的数据，分析出来我们一些自己的问题，及时发一些异常的情况。这个平台就让睦晨来负责吧！”
睦晨，揉着黑眼圈，傻笑：“嘿，嘿，嘿.....好的。”
老板笑呵呵：“很好，很好，很好。小伙子加油啊！！”
中午食堂。
谢了顶的同事喝着黄豆海带排骨汤说：“睦晨啊，你们老大房星真是巾帼不让须眉？”
“话说，你们老大名字还真有些怪啊。”
“这次解决了客户的问题，老板又表扬你们组了。”
“你们老大还特别漂亮，我们组压力山大啊！！”
“......”同事又在不停地吧啦吧啦。
睦晨回忆着早上老大的夸奖，红着脸扒了几大口白米饭。
“听说这次你立了大功啊，给哥说说！”睦晨被打断了扒饭不太高兴，拿起手机甩给他一个链接：
https://www.alibabacloud.com/help/zh/doc-detail/181331.htm
接着，继续扒白米饭。
（完）
版权声明: 本文为 InfoQ 作者【阿里云基础软件团队】的原创文章。
原文链接:【http://xie.infoq.cn/article/af300281b6acb8d0dfeb4b810】。文章转载请联系作者。
期待您的加入！ 2020.03.27 加入
阿里巴巴基础软件团队负责全集团的服务器操作系统，Linux内核，编译器，语言(C&C++，Java等)的研发与产品化, 及软硬件结合的系统性能优化。有alios，alikernel，ajdk(alibabajdk)，alibaba gcc/llvm，SPEED等产品。
评论