当您需要可靠的UDP时,您使用什么?

那么...怎么样 SCTP

它具有分块功能,有助于提高速度。

comparison between TCP and SCTP 结果表明,除非可以使用两个接口,否则性能是可比的。

更新:a nice introductory article .

如果没有关于问题领域的额外信息,很难回答这个问题。 例如,您使用的数据量是多少?多久?数据的性质是什么?(例如,它是唯一的、一次性的数据?还是样本数据流?等等) 您开发的平台是什么?(例如桌面/服务器/嵌入式) 要确定“太慢”是什么意思,您使用的是什么网络媒体?

例如,如果您尝试发送的数据能够容忍单个数据包的丢失(例如,采样率比信号带宽高很多倍的定期采样数据),那么您可能会通过确保能够检测到数据损坏而牺牲一些传输可靠性(例如,通过使用良好的crc)

http://enet.bespin.org/

我已经将ENET作为一种可靠的UDP协议使用,并为我的一个客户机编写了一个异步套接字友好版本,该客户机正在其服务器中使用它。它工作得很好,但我不喜欢对等ping给其他空闲连接增加的开销;当你有很多连接时,定期ping所有连接都是一项繁忙的工作。

ENET为您提供了发送多个“通道”数据以及发送的数据不可靠、可靠或按顺序排列的选项。它还包括前面提到的对等ping,它作为保持活动状态的工具。

我们有一些国防工业客户使用UDT(基于UDP的数据传输)(参见 http://udt.sourceforge.net/

任何认为上面的列表还不够,并且想要开发自己的可靠UDP的人都应该看看Google QUIC规范,因为它涵盖了许多复杂的角落案例和潜在的拒绝服务攻击。我还没有研究过它的实现,您可能不想要或不需要它提供的一切,但在开始新的“可靠”UDP设计之前,该文档非常值得一读。

QUIC的一个良好起点是 here ,在Chromium博客上。

here .

陆克文- Reliable User Datagram Protocol

• 接收数据包的确认
• 窗口化与拥塞控制
• 过度缓冲(比实时流媒体更快)

与ENet相比,它在保持生命方面似乎更具可配置性,但它并没有给您提供那么多的选项(即,所有数据都是可靠的,并按顺序排列,而不仅仅是您决定应该排列的位)。它看起来很容易实现。

正如其他人所指出的,您的问题非常笼统,是否比TCP“更快”在很大程度上取决于应用程序的类型。

TCP通常以最快的速度将数据从一台主机可靠地流到另一台主机。但是,如果您的应用程序执行大量小流量突发并等待响应,UDP可能更适合于最小化延迟。

有一个简单的中间立场。 Nagle's algorithm 是TCP的一部分,它有助于确保发送方不会淹没接收方的大量数据流,从而导致拥塞和数据包丢失。

如果您需要可靠、有序的TCP传输,以及UDP的快速响应,并且不需要担心发送大数据流时的拥塞,您可以禁用Nagle的算法:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

如果您遇到TCP连接可能太慢,UDP“连接”可能太不可靠的情况,您会使用什么?有各种标准可靠的UDP协议,您对它们有什么经验?

你句子中的关键词是“潜在”。我认为您确实需要向自己证明,如果您需要协议的可靠性,TCP对于您的需求来说实际上太慢了。

协议DCCP,标准化于 RFC 4340 ,“数据报拥塞控制协议”可能就是您想要的。

看来 implemented in Linux .

可能是 RFC 5405

你考虑压缩数据吗?

RUDP . 许多游戏套接字服务器实现了类似的功能。

很难对这个问题给出一个通用的答案,但最好的方法可能不是停留在“TCP和UDP之间”的线上,而是横着走:)。

更详细的解释:

如果一个应用程序需要为它传输的每一条数据获得确认响应,那么TCP的速度几乎和它所获得的一样快(特别是当您的消息远远小于您连接的最佳MTU时)如果您需要发送在发送时过期的周期性数据,那么出于许多原因,原始UDP是最佳选择,但速度方面也不是特别好。

因此,传统网络协议的问题通常不是速度或可靠性,而是方便性。它是关于获得TCP的一些特性(自动拥塞控制、自动传输单元大小调整、自动重传、基本连接管理等),同时至少获得一些它错过的重要和有用的特性(消息边界-最重要的一个,连接质量监控,连接中的多个流,等等),而不必自己实现它。

从我的观点来看,SCTP现在看起来像是最好的通用选择,但它不是很流行,而且在今天的互联网上可靠地传递它的唯一现实方法仍然是将它封装在UDP中(可能使用 sctplib )。它仍然是一个相对基本且紧凑的解决方案,对于某些应用而言,它本身可能还不够。

ZeroMQ 而且效果很好。这是一个更完整的解决方案,而不仅仅是一个网络协议(它支持TCP、UDP、两个更高级别的协议和一些本地IPC机制来实际传递消息)。自从几次发布以来,它的最初开发者已经将注意力转移到了他的新产品上 纳米味精 现在是最新的 NNG 图书馆。它没有得到充分的开发和测试,也不是很受欢迎,但有一天它可能会改变。如果您不介意CPU开销和一些网络带宽损失,那么一些库可能适合您。还有其他一些面向网络的消息交换库可用。

MoldUDP ,它已经存在了几十年,并被纳斯达克的瘙痒市场数据源使用。我们的信息系统 CoralSequencer 使用它实现来自中央进程的可靠多播事件流。

免责声明:

使用UDP实现可靠性的最佳方法是在应用程序本身中构建可靠性(例如,通过添加确认和重传机制)