在最近结束的Netdev 0x16 会议上，斯坦福大学教授就数据中心网络的发展方向发表了个人观点。四川联想代理为了解决他看到的问题，他建议对这些环境进行一些“相当重大的改变”，包括放弃古老的、无处不在的TCP 传输协议。

他说，硬件方面取得了惊人的进步。链接速度现在超过 100Gbps，并且随着硬件往返时间 (RTT) 达到 5 到 10 微秒而上升，未来几年可能会降低。但是应用程序无法访问原始网络速度；特别是，小消息的延迟和吞吐量与硬件数量所支持的相差无几。“我们相差一到两个数量级——甚至更多。” 问题在于软件网络堆栈的开销。

他说，如果我们要让这些功能真正可用于应用程序，就需要进行一些“根本性的改变”。需要做三件事，但最大的是更换 TCP 协议；他“不会争辩说这很容易，但如果你想让硬件潜力发挥作用，真的没有其他方法 [...]”。他说他将把大部分时间花在摆脱 TCP 上，但也需要一个更轻量级的远程过程调用 (RPC) 框架。除此之外，他认为在软件中实现传输协议不再有意义，因此这些协议最终需要转移到网络接口卡 (NIC) 中，这也需要对 NIC 架构进行重大更改。

对于数据中心网络，人们可能有不同的目标，但他希望专注于高性能。当发送大对象时，你想要获得完整的链接速度，这就是他所说的“数据吞吐量”。那“一直是 TCP 的最佳点”，而今天的数据中心网络在这方面做得很好。然而，还有另外两个措施 TCP 也没有发挥作用。

对于短消息，需要低延迟；特别是“低尾延迟”，因此 99% 或 99.9% 的消息具有低往返延迟。他说，原则上，我们应该能够让这个数字低于 10µs，但我们距离这个数字大约相差两个数量级。对于短消息延迟，TCP 在毫秒范围内上升。

另一个他没有听到太多谈论的衡量标准是短消息的消息吞吐量。硬件应该能够每秒发送 10-1 亿条短消息，这“对于紧密协作以执行各种组通信操作的大型数据中心应用程序来说非常重要”。今天，在软件领域，每秒处理一百万条消息几乎是不可能的。“我们就差一点了。” 他重申，目标是在应用程序中一直提供这种性能

这些性能要求意味着其他一些要求。一方面，需要跨多个内核进行负载平衡，因为单个内核无法跟上超过 10Gbps 的速度。但是负载均衡很难做好，因此过载的核心会导致热点，从而影响吞吐量和尾部延迟。这个问题非常严重，这也是他认为传输协议需要移入 NIC 的部分原因。

另一个隐含的要求是在网络中进行拥塞控制。需要正确管理网络设备中的缓冲区和队列。他认为，如果你能正确地进行负载平衡，核心结构中的拥塞是可以避免的，而这在今天是不会发生的。“TCP 无法正确进行负载平衡”。边缘的拥塞（即到终端主机的下行链路）是不可避免的，因为下行链路容量总是可能被多个发送者超过；但是，如果管理不当，由于缓冲的增加，延迟会增加。

TCP的缺点

TCP 是一个了不起的协议，它是在 40 年前设计的，当时互联网看起来与今天大不相同。令人惊讶的是，随着网络在该跨度内的变化，它会持续很长时间。即使在今天，它也适用于广域网，但在设计 TCP 时并没有数据中心，“所以不出所料，它不是为数据中心设计的”。他认为 TCP 设计的每个主要方面对于数据中心来说都是错误的。“我无法确定任何适合数据中心的 TCP。”

他列出了 TCP 设计的五个主要方面（面向流、面向连接、公平调度、发送方驱动的拥塞控制和有序数据包传递），这些方面对于数据中心应用程序是错误的，并表示他将分别讨论每个方面在谈话中；“我们必须改变所有这五个”。为此，必须至少从数据中心中删除大部分 TCP；它需要用新的东西取代，虽然不是完全取代。一个候选者是他和其他人一直在研究的Homa 传输协议。但是，由于从 TCP 切换会很困难，因此在 RPC 框架下添加对 Homa 或其他一些面向数据中心的传输的支持将通过减少所需的应用程序更改数量来简化过渡。

TCP 是面向字节流的，其中每个连接都由一个字节流组成，没有任何消息边界，但应用程序实际上关心消息。接收 TCP 数据通常在固定大小的块中完成，这些块可以包含多条消息、单个消息的一部分或这些消息的混合。因此，每个应用程序都必须在 TCP 之上添加自己的消息格式，并为从接收到的块中重新组装消息付出时间和复杂性的代价。

他说，这很烦人，但不会妨碍表演。您不能使用 TCP 进行负载平衡是显示停止器。您不能将接收到的字节流数据的处理拆分到多个线程，因为线程可能不会收到可以分派的完整消息，并且消息的一部分可能与多个线程共享。试图以某种方式在线程之间以某种方式重新组合消息将是令人担忧的。他说，如果有一天 NIC 开始直接将网络数据分派到用户空间，它们在负载平衡方面也会遇到同样的问题。

解决此 TCP 限制的主要方法有两种：使用调度程序线程收集完整消息以发送给工作线程，或者通过静态分配连接子集到工作线程。调度程序成为瓶颈并增加延迟；他说，这将性能限制在每秒大约一百万条短消息。但是静态负载均衡容易出现性能问题，因为一些工作人员超载，而另一些工作人员几乎处于空闲状态。

除此之外，由于线头阻塞，小消息可能会被困在大消息后面，需要等待前面的消息传输。TCP 流也不提供应用程序正在寻找的可靠性保证。应用程序希望他们的消息被服务器传递、处理并返回一个响应；如果其中任何一个失败，他们需要某种错误指示。流仅提供该保证的一部分，并且在这些往返事务之一中可能发生的许多故障不会标记给应用程序。这意味着应用程序需要添加自己的某种超时机制，即使 TCP 有各种超时。

有问题的第二个方面是 TCP 是面向连接的。您需要为“有趣的属性，如流量控制和拥塞控制以及从丢失的数据包中恢复等”建立连接，这是一种“网络世界的信条”。但是连接需要存储状态，这可能相当昂贵；在 Linux 上，每个连接大约需要 2000 个字节，不包括数据包缓冲区。然而，数据中心应用程序可能有数千个打开的连接，而服务器应用程序可能有数万个，因此存储状态会增加大量内存开销。尝试将连接池化以减少这种情况最终会增加复杂性和延迟，就像 TCP 负载平衡的调度程序/工作人员解决方法一样。

此外，在发送任何数据之前需要进行往返。传统上，这不是什么大问题，因为连接是长期存在的，而且设置成本可以摊销，但在今天的微服务和无服务器世界中，应用程序可能运行不到一秒，甚至只有几十毫秒. 事实证明，那些被认为需要连接、拥塞控制等的功能，可以在没有它们的情况下实现。

当存在争用时，TCP 使用公平调度在所有活动连接之间共享可用带宽。但这意味着所有的连接完成缓慢；“众所周知，公平调度在最小化响应时间方面是一种糟糕的算法”。由于处理大部分（但不是全部）流程没有任何好处，因此采用运行到完成的方法是有意义的；选择一些流程并处理其所有数据。但这需要知道消息的大小，以便系统知道要发送或接收多少，而 TCP 没有可用的；因此，公平调度是 TCP 能做到的最好的。不过，他展示了他所做的一些基准测试，表明 TCP 实际上并不公平。当短消息在负载网络上与长消息竞争时，短消息显示出更多的减速（“短消息真的被搞砸了”）。

他想强调的 TCP 的第四个方面是发送者驱动的拥塞控制。发送者有责任在拥塞时降低其传输速率，但他们无法直接知道何时需要这样做。发送方试图避免填满中间缓冲区，因此拥塞信号基于 TCP 中缓冲区的填充程度。

极端情况下，队列溢出，丢包，导致报文超时；这是“足够灾难性的”，可以尽可能避免。相反，各种队列长度指示被用作发送方用来缩减其传输的拥塞通知。但这意味着如果没有一定数量的缓冲区积累，就无法了解拥塞情况——这会导致延迟。由于所有 TCP 消息共享同一个服务等级，所有大小的消息都在同一个队列中排队；再次，短消息延迟受到影响。

他说，TCP 设计对数据中心效果不佳的第五个方面是，它希望数据包按照它们发送的顺序发送。如果数据包无序到达，则被视为指示丢弃的数据包。这使得硬件和软件的负载平衡变得困难。在硬件中，流中的每个数据包都必须使用通过路由结构的相同路径，这样就不会有重新排序数据包的风险，但路径是由流独立选择的，如果两个流最终使用相同的链路，两者都不能使用全部带宽。即使网络结构上的整体负载很低，也会发生这种情况；如果用于选择路径的散列函数恰好引起冲突，就会发生拥塞。

他假设当今数据中心网络拥塞的主要原因是 TCP 所需的这种流量一致的路由。他没有看到任何测量结果，但会感兴趣；他邀请可以访问数据中心网络的与会者对其进行调查。

在软件中处理数据包也会遇到这种负载平衡问题。在 Linux 中，通常一个数据包将遍历三个 CPU 内核，一个用于运行驱动程序代码，另一个用于完成网络堆栈处理（在软件中断中），第三个用于应用程序。为了防止数据包乱序，流中的所有数据包都需要使用相同的核心。但是，与硬件一样，如果两个流最终共享一个内核，那么该内核就会成为瓶颈。这会导致系统中的负载不均匀；他测量到这是软件引起的 TCP 尾部延迟的主要原因。他说，Linux 上的 Homa 也是如此。

有一个TCP是否可以修复的问题，但他认为不可能。有太多的基本问题相互关联，无法实现。事实上，他找不到值得为数据中心保留的 TCP 部分。如果有有用的片段，他想听听。因此，为了避开“软件税”并允许应用程序充分利用可用网络硬件的潜力，需要一种在各个方面都不同于 TCP 的新协议。

【公司名称】成都鸿盛广达科技有限公司

【代理级别】成都联想服务器总代理

【销售经理】成都鸿盛广达科技有限公司

【联系方式】座机：028-85952921 手机：13981931555

【公司地址】成都市武侯区人民南路四段一号时代数码广场A座17楼