为什么UDP转发在碎片交付上优于WebSocket和gRPC

在实时接收Solana碎片时，传输协议的选择直接影响延迟。不少基础设施提供商通过WebSocket或gRPC提供碎片数据，看似方便，实则引入了显著的额外开销。这两种协议都基于TCP运行，因此不可避免地继承了连接建立成本、拥塞控制延迟，以及最关键的队头阻塞问题——一个丢包就会阻塞整个数据流，直到重传完成。对于像碎片这样的持续时间敏感数据流，这种行为对性能是毁灭性的。

要理解队头阻塞为何如此致命，想象碎片突发交付的场景。领导者每个槽产生数十个碎片，它们快速连续到达您的基础设施。使用基于TCP的WebSocket或gRPC协议时，这些数据包按严格顺序交付。如果流中的第47号数据包因网络抖动而丢失，第48到100号数据包必须在缓冲区中等待，直到第47号数据包重传并被接收。在此暂停期间，您的应用程序什么也看不到——即使第48-100号数据包已经到达了您的网络接口。整个流在一次重传往返中冻结，通常根据网络条件持续1-10ms。

UDP彻底消除了这些问题。没有连接握手、没有确认回路、没有可能导致停顿的排序保证。每个碎片作为独立的数据报到达。如果一个包丢失，其余数据继续流入不受中断。这与Solana的Turbine协议在验证者网络中传播碎片的方式完全一致——使用独立的UDP数据包配合纠删编码实现冗余。通过UDP转发碎片，我们保持了Solana本身使用的相同交付语义，不添加任何人为瓶颈。

Solana碎片格式内置的纠删编码为丢包提供了天然解决方案。每个区块的碎片既包括数据碎片也包括编码（奇偶校验）碎片。即使某些UDP数据包丢失，Reed-Solomon纠删编码也允许从碎片子集完整重建区块。这意味着UDP缺乏保证交付在实际中并不成问题——应用层已经处理了冗余。TCP的重传机制在这种场景下是多余的，甚至是有害的，增加延迟却不提升可靠性。

WebSocket和gRPC还增加了UDP所避免的序列化和帧开销。WebSocket帧包含操作码、掩码密钥和长度字段的头部。gRPC增加了HTTP/2帧、头部压缩状态和Protocol Buffer序列化。这些层在发送端和接收端都增加处理时间。使用原始UDP，碎片数据就是负载——没有包装、没有序列化、没有帧。您的应用程序读取数据包后立即获得准备处理的碎片字节。

GetShreds以Jito兼容格式通过原始UDP转发碎片，您的验证者或自定义管线无需任何额外的反序列化层即可直接消费。我们的基准测试一致表明，使用WebSocket或gRPC相比直接UDP交付会增加5-15ms的额外延迟。对于每毫秒都至关重要的MEV策略而言，这个差距决定了您是抓住机会还是错失良机。我们通过在同一硬件、同一数据中心并行运行相同的碎片处理管线——一个从WebSocket流消费，一个从我们的UDP馈送消费——来测量这一结果。

连接管理是UDP的另一个实际优势。WebSocket和gRPC连接可能因空闲超时、服务器重启、负载均衡器重新配置或网络路径变更而断开。连接断开时，您的客户端必须检测故障、重新连接，并可能重新认证，然后数据才能再次流入。这个重连窗口可能持续数秒，期间您完全错过碎片。UDP没有可断开的连接——数据包只是到达您的端口。如果我们的边缘节点重启，您的应用程序会经历短暂的数据间隙，但在数据包恢复时立即继续接收，零重连逻辑。

我们在法兰克福和阿姆斯特丹运营裸金属边缘节点，每个节点直接接入Turbine并以亚毫秒处理时间通过UDP转发碎片。无需KYC，无需信用卡——使用SOL支付，几分钟内即可开始接收碎片。我们的基础设施专为碎片转发而建，配备内核级数据包处理优化和直连主要Solana验证者集群的网络路径。