TCP干线隧道_tcp隧道-CSDN博客

异步模型建议创建CPU个线程处理所有连接，从而解决为每条连接创建一个线程的可扩展性问题。
TCP也可以这么倒换：

• 为每条业务流分配一条TCP连接 or 将所有业务流塞入固定数量的TCP连接？

资源调度的视角看，拥塞控制和系统任务调度的目标一致，公平性和资源高利用率。

系统任务越多，调度的开销越大，系统的任务数量一定有一个阈值，超过该阈值，调度本身所占用的时间会将任务时间挤兑到不可接受，同理，带宽饱和后，经过同一条链路的TCP连接越多，拥塞控制公平收敛的开销越大。

一个简单的想法是在边缘路由器之间创建固定数量TCP隧道，包括UDP在内的所有流量塞入某一条隧道：

好处是：

• UDP被纳入拥塞控制，抑制UDP抢占性。
• 有限条TCP流公平收敛，隔离短突发流。
• 屏蔽核心网络MTU变化带来的探测开销。
• 隧道入口可实施更灵活的流包调度策略。

如果广域网上都是长大象流，拥塞控制并不难，绝大多数拥塞控制的误判都是UDP以及TCP短突发流造成的，短流的频繁产生和退出会对拥塞控制算法造成极大的困扰。几乎所有拥塞控制算法在这种情况下都无法很好地抵抗抖动。

以上图为例，假设一个短突发流来自边缘路由器B1左侧边缘网络，该流对整网的影响仅局限在B1边缘网络。否则它的影响将充满经过的所有骨干路由器，进而影响更多的连接实施拥塞控制。突发隔离是我喜欢这种玩法的原因。

若网络核心果真只有有限条TCP流，那么拥塞控制将会非常完美。网络核心的拥塞将被所有边缘隧道节点分担，丢包和拥塞将使边缘节点自动降速，畅通的网络核心带宽将被有限条TCP公平共享。

骨干核心的拥塞被有效控制住了，自然也就低延时了。

我推荐这种玩法，还有一个重要原因是边缘节点有能力实施更灵活的QoS策略。如果海量用户流独立通过网络核心，在网络核心实施精细化的QoS策略代价是巨大的，高pps链路对数据包做的任何额外操作都会带来可观测额外延时。当这种代价被所有边缘节点分担后，一个各管各的分治模式就形成了。

每一个边缘节点卸载了网络核心的包分类，调度压力，只需要处理自己携带的边缘网络流量。

我想起这事是因为我曾经做过一个实验，一条50ms的10Gbps专线(具体数据糊化了，但大致是这个意思)，搭建一条隧道承载所有流量要比放任所有流量独立进入这条专线效果好很多。

它是专线，我写死了cwnd和pacing rate刚好匹配已知的带宽和延时，取消了拥塞控制，只有一条TCP流，根本没有拥塞，没有任何探测的必要性，也无需进行任何退避，所以这条隧道满载容量就是10Gbps*50ms。如果没有这条隧道，总有那么一些时间这条专线未能跑满。

是不是很有趣？

有趣就对了，虽然很难控制真正的路由器在上面搭建隧道，但如果有机会和能力构建overlay，这个路子明显就对了。

为什么用端到端TCP协议在骨干上搭隧道？

我很看好TCP端到端方式的拥塞控制，将它用于骨干流量的公平收敛会很有效，可以降低骨干设备的复杂性，这正是互联网端到端原则所追求的。

为何是TCP而不一个新协议，比如边缘到边缘的eTCP协议，一个中间状态的协议，比端到端更接近核心却又不及。为什么不呢？没说不啊，其实已经实现了，很早之前我不是说过吗，一个伪TCP协议，保留拥塞控制，但不做重传。这个协议是具有通用性的，完全可以承载所有TCP和UDP流量，且不会给UDP引入重传延时。eTCP是一个松散版本的TCP。

但如果是要隔离丢包，还是要用纯TCP搭隧道。

回想起之前的那条伪TCP隧道以及长肥管道的相关issue，感觉还是并发问题，面临的选择还是那个倒换问题，是固定资源处理所有连接还是为每一个连接分配固定资源，高并发显然选择前者，这个思想用到TCP拥塞控制上， 发现固定数量TCP隧道是一个好主意。短文，备忘。

浙江温州皮鞋湿，下雨进水不会胖。