内行透底：TCP窗口调优，3步搞定模型毫秒响应

　　去年一月份周中，我蹲在机房机柜边跟运维小周吵架，手里攥着刚从抓包工具导出来的包，屏幕上跳着的延迟数字晃得我眼晕——那时候我们刚把服务器的模型请求响应时间卡到秒级边缘，就差临门一脚，客户的需求是把那“一秒内”的底线再往下压，要到毫秒级，我原以为改改代码的缓存策略，调调线程数就能搞定，结果试了快一个礼拜，连个百毫秒的突破都没有，小周还在旁边叨叨着是不是服务器硬件不够，我把手里的鼠标往操作台上一摔，说再给我半天时间，搞不定就把这台机器拆了当零件卖。

　　抓包文件我翻了不下十遍，从链路层到应用层来回扒，最后在TCP流里看到了一串奇怪的数字——窗口值一会儿大一会儿小，根本不是之前看的稳定阈值。我突然想起哪年给某电商调过节点间的传输，那时候也碰过类似的波动，只不过那时候没把这个当核心问题，这次倒成了卡脖子的地方。我拽着旁边的测试组阿凯，让他去查内核里的tcp_wmem、tcp_rmem这几个参数的当前值，自己蹲在终端里扒了抓包的时序图，把窗口缩小和延迟飙升的时间点一一对应，果然，窗口收窄的那一秒，模型请求的包就卡住了，得等窗口重新扩大才继续传，这中间的间隙，就是用户看到的“卡”，连带着模型推理的毫秒时间都被吞得一干二净。

　　我原以为调TCP窗口是网上说的那套固定参数复制粘贴，把tcp_wmem、tcp_rmem设成某个公认的大值就行，结果改完重启，延迟反而更乱了，有的请求快到二十几毫秒，有的直接卡到六百多毫秒，小周在旁边翻着运维手册笑我，说你这专家是不是把参数改错了，我盯着屏幕上的时序图愣了半天，突然反应过来——TCP窗口的调优不是给个固定值就完事，得跟实际的传输链路匹配，还要结合应用的请求模式，我之前根本没问过阿凯服务器的网卡是千兆还是万兆，也没问过模型请求的数据包是多大，就瞎改参数，能不翻车吗？

　　那天晚上我没走，把抓包的时序图拉到最细，把每次窗口变化和请求延迟的对应关系标成红圈，最后列了三个能落地的步骤——先算实际的链路带宽和RTT，再给TCP窗口设成刚好填满带宽的阈值，最后把应用层的请求包大小跟窗口对齐，不让中间有多余的等待。我跟阿凯说，你去把网卡的实际吞吐量测出来，把RTT的平均数值也给我，别用默认值，用你测的准数，阿凯抱着笔记本蹲在交换机旁边测，测完回来报的数我记不太清了，反正不是网上抄的那套通用数。小周后来也凑过来一起改，他把之前设的参数全清了，换成我算的数，重启完再测，第一个请求就掉到了五十毫秒以内，慢慢调到二十几，最后稳定在十几毫秒，小周拍着我肩膀说，你这哪是调参数，是跟TCP“聊天”呢。

　　不过这事也不是没遗憾，那天改完之后我才想起，我们没测极端场景——比如同时来几百个模型请求的时候，TCP窗口会不会又乱掉，这个得等下周再测，还有个小细节，我忘了把tcp_congestion_control从默认的 cubic 改成 bbr，后来问阿凯，他说改完bbr之后又降了几毫秒，但我总觉得，那几毫秒没什么好说的，核心还是窗口跟实际链路的匹配，换任何算法，只要窗口不对，都白搭。

文章配图，仅供参考

　　哦对了，上周我再查那台服务器的指标，看到窗口已经稳定在一个固定值了，延迟也没再乱跳，小周说客户那边已经把这个案例放到他们的技术分享里了，我没去凑热闹，反正这东西就是这么回事，你以为是调参数，其实是在跟TCP的传输逻辑对齐，别搞那些花里胡哨的，实用就好，要是哪天有人问我具体改了多少，我还是记不太清，因为不同的场景，参数本来就不一样，我可不想给个固定数，害别人再踩坑。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!