SRD是否能真的代替TCP？

2022年AWS re:invent大会如期举行，Reinvent全球大会是面向创新的技术盛会，在这次会议中，AWS介绍了 Nitro v5 系统、Graviton3E 芯片以及高性能计算实例 HPC7g、C7gn、网络优化机器学习实例 Trn1n，还有包含计算、网络、算法及 Serverless 等最新功能特性并再次提到了高性能网络技术SRD协议，SRD 是 AWS 为提高 HPC 性能而开发的一种高吞吐、低延迟的网络传输协议，如果SRD协议真的优于TCP协议，那是否SRD是否能真的代替TCP协议呢？

本文将对计算领域的EFA SRD协议进行分析和探索，如有疑问还请留言指正！

谈到SRD协议，我们不得不提到传统的TCP/IP协议,还有近期的RDMA协议，这里我们不会涉及到讲解TCP/IP和RDMA的历史，如有疑问可自行研究其相关资料，我们主要探讨的是AWS为什么要研发SRD，未来外界宣称的SRD是否可以替代TCP？

云计算的优势是，按需分配，随时增加或取消资源，灵活性是最大的特征之一，然而传统的超级计算，也就是我们日常听到的HPC，这种类型的计算是需要一定的定制化的，在云计算环境中，使用商用或定制化的硬件都是无比昂贵的，同时难以扩展和快速发展。

AWS使用商用以太网交换机来构建具有等价多路径(ECMP)路由的高基数折叠 Clos 拓扑。ECMP通常用于使用流哈希在可用路径上静态地对流进行条带化。流到路径的这种静态映射有利于保持TCP的每个流的顺序，但它不考虑当前的网络利用率或流率。哈希冲突会导致某些链路上出现“热点”，从而导致路径间负载分布不均匀、数据包丢失、吞吐量降低和尾部延迟高。

我们来分析下这三种协议的数据包发送过程：

TCP/IP：主要的数据流程是从用户空间复制数据到内核空间，复制由CPU完成，内核中TCP/IP协议给数据添加各层的头部和校验信息，最后网卡会从内存中复制数据，通过物理链路发送给另一端的网卡，完成一次数据的传输。对端是完全相反的过程，也需要CPU对数据包的组装和解析。

RDMA（Remote Direct Memory Access）：数据流程主要是通过硬件将数据发送到选定的内存，网卡从内存中搬移数据，组装报文发送给对端，对端收到数据后进行解析，将数据写入内存，通知用户存储位置。

数据收发绕过了内核并且数据交换过程并不需要CPU参与，报文的组装和解析是由硬件完成的

SRD（Scalable Reliable Datagram）：是AWS研发的一种高吞吐、低延迟的网络协议，通过乱序交付和多路劲负载均衡，消除排队阻塞，进一步降低丢包的机会并最大限度地减少重传时间。

通过对TCP/RDMA/SRD多维度的特征对比，我们可以看到传统的基于软件的网络堆栈已经不能满足关键的时延和带宽的要求，将网络堆栈卸载到硬件上是目前发展的趋势，考虑TCP最初的设计并不是为性能而生，在应对HPC及低延迟场景方面，TCP在延迟和丢包重传方面，远远不满足要求，那么它的不适也就是必然，虽然RDMA是当前硬件的主流卸载方案，但是在云计算数据中心这种大规模的场景下，抛开成本因素外，RDMA在平衡延迟、带宽、高可用性方面具有一些局限性，RDMA首先考虑的是流量控制（PFC一种有效避免丢包的流量控制技术），这样会造成大量的堵塞，这也是不可行的，并不能完全满足当下的需求。

那么SRD的诞生就是必然的结果，也就解释了为什么AWS要开发SRD呢，而不是使用TCP或者RDMA。

那么AWS新设计的网络传输协议SRD，是如何解决这个问题的呢？

SRD 的创新在于有意通过多个路径分别发包，虽然包到达后通常是乱序的，但AWS实现了在接收处以极快的速度进行重新排序，最终在充分利用网络吞吐能力的基础上，极大地降低了传输延迟。其主要功能包括：

l 乱序交付：取消按顺序传递消息的约束，消除了队头阻塞，AWS在EFA用户空间软件堆栈中实现了数据包重排序处理引擎

l 等价多路径路由（ECMP）:两个EFA实例之间可能有数百条路径，通过使用大型多路径网络的一致性流哈希的属性和SRD对网络状况的快速反应能力，可以找到消息的最有效路径。数据包喷涂（Packet Spraying）可防止出现拥塞热点，并可以从网络故障中快速无感地恢复

l 快速的丢包响应：SRD对丢包的响应比任何高层级的协议都快得多。偶尔的丢包，特别是对于长时间运行的HPC应用程序，是正常网络操作的一部分，不是异常情况

l 可扩展的传输卸载：使用SRD，与其他可靠协议（如InfiniBand可靠连接IBRC）不同，一个进程可以创建并使用一个队列对与任何数量的对等方进行通信

目前AWS 在EFA、EBS、ENA上都使用了SRD。

综上所述，SRD是aws在计算领域探索的重要一步，在应对低延敏感的业务场景上具备极大优势，但是在全量业务上，目前还不足以代替TCP。