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

如果您的TCP连接可能太慢并且UDP"连接"可能太不可靠,您使用什么？有各种标准的可靠UDP协议,你有什么经验吗？

请在每个回复中讨论一个协议,如果其他人已经提到您使用的协议,则考虑将其投票并使用评论进行详细说明(如果需要).

我对这里的各种选项感兴趣,其中TCP位于规模的一端而UDP位于另一端.提供了各种可靠的UDP选项,每个选项都带有TCP到UDP的一些元素.

我知道TCP通常是正确的选择,但是有一个备选列表通常可以帮助我们得出结论.像UDP,RUDP等基于UDP构建的东西各有利弊,你使用它们,你的经历是什么？

为了避免疑问,没有更多的信息,这是一个假设的问题,我希望这个问题会引出一个回复列表,详细说明需要做出决定的人可以使用的各种选项和备选方案.

1> philant..：

---

怎么样SCTP.它是IETF的标准协议(RFC 4960)

它具有分块功能,可以帮助提高速度.

更新:TCP和SCTP之间的比较表明,除非可以使用两个接口,否则性能是可比较的.

更新:一篇很好的介绍性文章.

---

SCTP可以通过UDP进行隧道传输.http://tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt

2> Andrew Edgec..：

---

如果没有关于问题领域的一些额外信息,很难回答这个问题.例如,您使用的数据量是多少？多常？数据的性质是什么？(例如,它是唯一的,一个是关闭数据吗？还是一个样本数据流？等等)你在开发什么平台？(例如,桌面/服务器/嵌入式)要确定"太慢"的含义,您使用的网络介质是什么？

但在(非常!)一般术语中,我认为你必须非常努力地尝试使用tcp来提高速度,除非你可以对你试图发送的数据做出一些严格的假设.

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

但是如果你不能容忍丢失单个数据包,那么你将不得不开始介绍tcp已经拥有的可靠性技术类型.并且,如果不进行合理的工作量,您可能会发现您已经开始将这些元素构建到用户空间解决方案中,并且具有所有固有的速度问题.

---

@Andrew - 在两种情况下击败TCP非常容易:(1)您的应用程序具有比"所有数据,始终有序,无重复,无过多排队"更轻的可靠性要求.或者(2)您正在使用多播.可靠的UDP在多播环境中非常常见.

---

好的,我会调整问题.我对那里各种可靠的UDP协议的优缺点更感兴趣,而不是"使用TCP"响应;)

---

此外,TCP在广域网连接中使用时可能会受到严重影响(长途问题).为什么,简单.TCP使用窗口,窗口中的数据包必须被确认.由于线路距离导致的延迟,ACK协议受到影响.谷歌:WAN TCP"光速"

---

@Ajaxx,你对此非常正确,但是,由于上次互联网崩溃,TCP/IP故意这样做.如果您正在进行高比特率协议而没有任何拥塞控制,那么您基本上都会感到羞耻.如果您拥有网络,那就疯狂吧.

---

"其中采样率明显高于奈奎斯特率" - 根据定义,采样率始终是奈奎斯特率的两倍.

3> Len Holgate..：

---

ENET - http://enet.bespin.org/

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

ENET为您提供了发送多个"通道"数据和发送的数据不可靠,可靠或有序的选项.它还包括前面提到的点对点ping,它起着保持活力的作用.

4> Chris Markle..：

---

我们有一些使用UDT(基于UDP的数据传输)的国防工业客户(请参阅http://udt.sourceforge.net/)并对此非常满意.我看到它也有一个友好的BSD许可证.

---

您能详细说明您的客户及其使用案例,特别是在国防部门吗？可能不是,但值得一试.我实际上已经在文件传输应用程序中向我的上级提出了关于UDT的想法,但它还没有真正去过任何地方.

5> Len Holgate..：

---

RUDP - 可靠的用户数据报协议

这提供:

确认收到的数据包

窗口和拥塞控制

丢失数据包的重传

过度缓冲(比实时流更快)

关于保持alive然后ENet似乎稍微可配置,但是它没有给你那么多的选项(即所有数据都是可靠的并且不仅仅是你决定的比特序列).实施起来看起来相当简单.

6> smo..：

---

正如其他人所指出的那样,你的问题非常笼统,而且某些东西是否比TCP"更快"在很大程度上取决于应用程序的类型.

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

有一个简单的中间地带.Nagle的算法是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");

7> Len Holgate..：

---

任何决定上面的列表不够并且他们想要开发他们的OWN可靠UDP的人肯定应该看看Google QUIC规范,因为这涵盖了许多复杂的角落案例和潜在的拒绝服务攻击.我还没有玩过这个的实现,你可能不想要或者不需要它提供的所有东西,但是在开始一个新的"可靠的"UDP设计之前,这个文件非常值得一读.

在Chromium博客上,QUIC的一个很好的起点就在这里.

可以在此处找到当前的QUIC设计文档.