189 8069 5689
关于 400Gbps+ 场景的概括，参见：400Gbps 网络面临的挑战
网站设计、成都网站建设的开发，更需要了解用户，从用户角度来建设网站，获得较好的用户体验。成都创新互联多年互联网经验，见的多，沟通容易、能帮助客户提出的运营建议。作为成都一家网络公司，打造的就是网站建设产品直销的概念。选择成都创新互联，不只是建站，我们把建站作为产品，不断的更新、完善，让每位来访用户感受到浩方产品的价值服务。
首先定义规则：
然后看图：
若说到达率和服务率相等，在足够久的相同一段时间，垂直线和水平线的数量是相等的，但表示到达的垂直线是实在累加的，而表示处理的水平线中有很多空闲的浪费，所谓逝去时间不可追回。
删掉空闲水平线后，垂直线数量将大于水平线数量，二者的差值就是平均队列长度。因此有：
这大致直观诠释了排队论的那些个公式。有下图做统一展示：
看这个链接：Towards 800G and 1600G Ethernet，网卡的发展似乎比 DDRx 快，几乎有追赶 CPU 内存带宽的趋势，当网卡速率与 CPU 读写内存的速率趋同甚至超越时，按照上图展示的排队率原理，a >= b，没得玩了。
回到 CPU 处理 TCP 的问题。
TCP 必须保序，故在单 CPU 串行处理比 “多 CPU 并行 + 同步” 的总效能更高。但 CPU 处理 TCP 逻辑时间约定值，以 Linux Kernel TCP 为例，即 tcp_v4_rcv 函数的指令时间(包括内存拷贝时间)约定值，该时间很难压缩到 500ns 以内。
假设 TCP 报文的到达与 CPU 的处理已完全校准，统一达到 100Gbps 的速率。
TCP 报文的到达虽非完全随机分布，但一定不是均匀的，只要两次到达时间稍微错过 1 个处理周期，依照上图解释，排队即将无穷增加，为清空队列，TCP 只能降速。
为实现初始假设，CPU 处理 100Gbps 到达率，需在 100ns 内完成 tcp_v4_rcv 调用(除 CPU 执行冗长的指令，还要加入内存操作，batch 只降低 overhead，但内存时间也相应越久，ZeroCopy 也不例外，稍好，但不完全)，CPU 很难完成该任务，初始假设都难，匡论后续随机过程。
难道不能提升 CPU 和内存的能力？当然可以，但 CPU 主频已经接近极限，内存带宽已经上百 GB，还能提升多少呢？正如大家说，不如上专门硬件，FPGA，SmartNIC，… 可为什么非要猛件迎合 TCP 呢？难道不是 TCP 自己的问题吗？
假设 TCP 可以乱序接收，就可以并行多路径传输并行处理 TCP 报文了，1 个 CPU 处理 25Gbps 绰绰有余，20 个 CPU 不就可以处理 500Gbps 了吗？问题不在硬件，问题在 TCP。
再给个形象的类比，工地上工人往楼上接力扔砖。
Linux Kernel TCP 就是如此这般扔砖接力，换个实现方式就好很多：
那么，以上就是乱序传输的好处，可以并行处理。然而 TCP 并不具备这能力。
这还不算拥塞控制的副作用，比如丢包，乱序带来的损耗，全在 TCP 保序约束。
放弃 TCP，人们一时半会儿不能接受，且不说新协议部署升级问题，人们从心理上也不能接受，但凡说了这话，大部分人都觉得此人在瞎咧咧，那就不再说，但 TCP 也不是什么都不能做：
单流 TCP 挑战 100Gbps+ 是难成功的，但 100Gbps+ 的网络根本就不是让单流跑满的，那么似乎多线程多流 TCP 跑满 100Gbps+ 也算。但是还有更有趣的，那就是不用 TCP，It’s Time to Replace TCP in the Datacenter 这篇不错，读后感也写过：It’s Time to Replace TCP in the Datacenter 读后 本文接着写点感想。
浙江温州皮鞋湿，下雨进水不会胖。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
