昨天下班路上，发了一条朋友圈:今天钓到一条大鱼，隧道的TCP负载吞吐量翻了一倍多。哈哈，周末愉快！很多隧道用同一个线程来解决同一个tcp流，这显然是错误的。应该使用不同的线程来解决两个方向的流。 但是很多客户端隧道都是用同一个线程解决同一个tcp连接，这是个问题。 在很多人眼里，这个问题真的很低级，还是那种无非如此的问题。因为怕被嘲笑，我的意思是把事情说得很低，但这只是用文字解决问题的一种技巧。本来这个事情就这么过去了。 但深入思考是我的习惯。我发现这是一个普遍的问题，所以我要把它写下来。 这不是一个关系到性能的多解优化问题，而是一个非常简单的维护全双工的问题！如果一个中盒不能维持全双工解决方案，就会破坏互联网的基本原理。 当TCP流通过隧道时，其跟踪波形如下所示:image，而正常的跟踪图应如下所示:image。我不会分析TCP如何均匀填充整个BDP管道的动态。我之前说的太多了。 看到上面的*梯*迹图你会怎么做？让我先告诉你我要做什么。 了不起。首先我不会去查中间环节的隧道，看到这么显著的*空窗期*，我就去填*。 所以通过镜像调试TCP CC绝对是一个类似拆弹的技术活，但也能显示一个人的技术素质。比如我不够格:不去分析这个阶梯波形产生的原因，一上来就想尽办法去填充空窗口……这样填充窗口很简单，一个stap -g脚本就能做到。 但是，窗口填满后，迹波形很可怕……丢了很多包，是红色的，队形很乱！形象点，我就是那个没坐着就开脑壳的庸医华佗！好了，现在收起生锈的手术刀，开始分析根本原因。 同时对比接收端的trace波形可以发现线索:imageTCP平滑trace波形由背靠背的数据和ack形成，ack提供反馈触发数据的发送:image TCP平滑trace图形是什么意思？平滑迹图是指*每个数据段之间的间隔相同或大致相同！*这要求每个ACK之间的间隔相同或大致相同(不考虑延迟ACK或完全考虑延迟ACK) 流畅的ACK流促进了流畅的数据流！简而言之，*网络必须“同时”解决数据段和ACK段！*只有这样，数据段和ACK段之间才不会因为互斥而引入延迟。我们知道，任何连续引入的延迟都会被逐渐放大，使得迹线波形成为阶梯。 假设网络中间有一个中间盒，一次只能解决一条消息，那么会发生什么？本来图像的背靠背交通被midbox塑造成有间隙的，所以迹线波形明显从对角线变成了阶梯。 仅仅是一个台阶吗？它的实际后果是什么？看梯形迹图，可以看到发送方向的空窗其实是中间盒正在解的另一个方向的ACK。很明显，时间被两个方向共享，吞吐量翻倍。 当两个方向分开时，正如预期的那样，吞吐量增加了一倍。 好了，现在结论很明确了，就是midbox的锅！但是什么是中置盒呢？midbox有哪些特征会导致阶梯形迹线波形？如果midbox是单进程单线程的服务，需要OpenVXY，那将是必然的结果。 但如果midbox是多进程多线程服务，会不会避免这个坑？不一定。 说到这个中框解决更多的话题，很多人会想当然的认为直接把它拆散就好了，不管是按流还是按包，但是有漏洞:按流拆散会造成本文所描述的现象。同一个线程解一个流，但是一个线程同一时间只能解一个方向！根据分组进行分解将导致单个流被无序地添加。如果SACK超过了发送方对无序的容忍度，就会增加重传来减少有效带宽。 其实还有另外一个维度，就是*按方向散射*，再按每个方向的流量散射。 我们有一个现成的例子可以做到这一点，那就是Linux内核协议栈:网卡可以根据包元组hash做RSS(明显有方向性)，然后Linux内核协议栈保证从接收到转发的过程在同一个CPU核上完成。 很简单。网络是什么样的？别毁了它，midbox。 显然，网络是全双工的，中置盒也应该如此。要实现全双工，至少需要两条线程，一个方向一条，不是吗？这里的原因显然很简单。与并发和多核编程模型无关，与hash无关。只是保持全双工的问题。 缓冲区膨胀还有另一个问题。 单线程解决一个流的半双工中间盒实际上促进了数据段和ACK段的排队。如果一个方向来的包不能马上解决，当然要排队。 我们可以想象，很多midbox实际上可以称为排队缓冲区，因此在几次跳跃后很难保持起搏队形，这也是BBR很多时候达不到预期的原因之一。 总之，我不信任运营商的大部分转发设施。我不认为他们能保持你的配速(*如果他们不做是因为他们没有这个义务，他们就没有这个能力*)。即使这个起搏速率低于他们的速度极限，他们也能给你一个完整的爆发。 纯粹的BBR行为还是需要在内网上观察，放到运营商的公网上。纯阵型就像坎尼战役中的罗马军团，一瞬间就被冲散了！浙江皮鞋是湿的，下雨不会胖。