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

92

如果您遇到TCP连接可能太慢而UDP'连接'可能太不可靠的情况，该怎么使用？有各种各样的标准可靠的UDP协议，您对它们有什么经验？

请针对每个答复讨论一种协议，如果其他人已经提及您使用的协议，则可以考虑将其投票，并在需要时使用评论详细说明。

我对这里的各种选项感兴趣，其中TCP处于规模的一端，而UDP处于另一端。提供了各种可靠的UDP选项，每个选项都将TCP的某些元素引入UDP。

我知道，TCP通常是正确的选择，但是列出替代方案通常有助于帮助得出这一结论。基于UDP构建的诸如Enet，RUDP等之类的东西各有利弊，您使用过它们，您的经验是什么？

为避免疑问，没有更多的信息，这是一个假设性的问题，我希望能引出一系列答复，详细说明需要做出决定的人可以使用的各种选择和替代方案。

sockets  tcp  network-programming  udp 
— 伦·霍尔盖特
source
1
这个问题似乎不切实际，因为它正在调查技术
— Dave Hillier 2014年
那些认为TCP在所有情况下都是最佳的人，请阅读：en.wikipedia.org/wiki/Bandwidth-delay_product
— nullptr
Wikipedia有一张很好的表格，比较了UDP，UDP Lite，TCP，多路径TCP，SCTP，DCCP和RUDP的各个方面。SCTP支持该列表中的大多数功能。
— 尤金·别列索夫斯基
@EugeneBeresovsky我对SCTP进行了一些研究，大部分信息都包括从2013年或更早的SO答复中获得的信息，当时大多数人回信SCTP的采用率很低。我想知道今天的情况如何？stackoverflow.com/questions/1171555/...
— 迈克尔IV
@MichaelIvanov的采用率确实很低。但是，如果您打算在数据中心内部使用它，则无需担心外部采用情况，只要交换机和路由器不会引起问题（在数据中心中不会出现问题），并且您拥有操作系统和库支持，这可能是一个问题，如在一个在您链接到的问题的答案。
— 尤金·别列索夫斯基

Answers:

25

没有有关问题领域的其他信息，很难回答这个问题。例如，您正在使用多少数据？多常？数据的本质是什么？（例如，它是唯一的，一次性的数据吗？还是样本数据流？等）。您正在开发什么平台？（例如，台式机/服务器/嵌入式）要确定“太慢”是什么意思，您使用的是哪种网络介质？

但是总的来说，我认为您将必须非常努力地击败tcp以提高速度，除非您可以对要发送的数据做出一些硬性假设。

例如，如果您尝试发送的数据可以容忍单个数据包的丢失（例如，定期采样的数据，其采样率是信号带宽的许多倍），那么您可能可以通过确保您可以检测到数据损坏（例如通过使用良好的crc）来牺牲传输的可靠性

但是，如果您不能忍受单个数据包的丢失，那么您将不得不开始介绍tcp已经具备的可靠性技术类型。而且，在没有进行大量工作的情况下，您可能会发现，您已经开始将这些元素构建到用户空间解决方案中，并且解决了所有固有的速度问题。

— 安德鲁·埃奇科姆
source
4
好的，我会解决这个问题。我对各种可靠的UDP协议的利弊更感兴趣，而不是对“使用TCP”响应的兴趣；）
— Len Holgate
9
@Andrew-在两种情况下击败TCP非常容易：（1）您的应用程序对可靠性的要求比“所有数据，始终井井有条，没有重复，没有过多的排队”。或（2）您正在使用多播。可靠的UDP在多播环境中非常普遍。
— 汤姆”
4
而且，在跨WAN连接使用TCP时，TCP会遭受严重破坏（长距离问题）。为什么，简单。TCP使用必须确认窗口中数据包的窗口。ACK协议由于行距导致的延迟而受到影响。Google：WAN TCP“光速”
— Ajaxx
3
@Ajaxx，您对此非常正确，但是由于上一次Internet崩溃，TCP / IP故意这样做。如果您正在执行高比特率协议而没有任何拥塞控制，那么基本上会让您感到羞耻。如果您拥有网络，那就疯狂了。
— 凯文·尼斯贝特
2
“在采样率显着高于奈奎斯特率的情况下”，根据定义，采样率始终是奈奎斯特率的两倍。
— 史蒂夫
27

那SCTP呢？这是IETF（RFC 4960）的标准协议

它具有分块功能，可以帮助提高速度。

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

更新：一篇不错的介绍性文章。

— 友善的
source
很好，我对可以在UDP之上而不是IP之上构建的事物更感兴趣，但这肯定适合解决方案领域。
— Len Holgate
SCTP具有许多出色的功能（例如多宿主），并且具有部分可靠性扩展（RFC 3758），这是一种非常灵活的选择。它包含在最新的Linux内核版本中，但是对于Windows，您将必须安装自己的SCTP堆栈。
— 安德鲁·约翰逊
6
SCTP可以通过UDP建立隧道。 tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt
— Miles，2009年
感谢Miles，这是一个有用的链接！
— Len Holgate
1
是的...但是在UDP之上而不是在与UDP相同级别上构建的某种东西可能更容易在用户空间中实现，至少在Windows上……
— Len Holgate
21

互联网- http://enet.bespin.org/

我已经使用ENET作为可靠的UDP协议，并为在其服务器中使用它的我的客户端编写了异步套接字友好版本。它工作得很好，但是我不喜欢点对点ping会增加空闲连接的开销。当您有很多连接时，定期对其进行ping操作会很忙。

ENET为您提供了发送多个“通道”数据的选项，并使发送的数据不可靠，可靠或有序。它还包括上述保持活动的对等ping。

— 伦·霍尔盖特
source
14

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

— 克里斯·马克尔
source
2
您能否详细说明您的客户及其用例，尤其是在国防领域？可能不是，但是值得一试。实际上，我已经在文件传输应用程序中向上级介绍了有关UDT的想法，但是实际上还没有解决任何问题。
— Thomas Owens
10

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

提供：

  • 确认收到的数据包
  • 窗口和拥塞控制
  • 重传丢失的数据包
  • 过度缓冲（比实时流更快）

在保持生命方面，它似乎比ENet更具可配置性，但它没有给您那么多的选择（即，所有数据都是可靠的并且已排序，而不仅仅是您决定的位）。实施起来看起来很简单。

— 伦·霍尔盖特
source
我正在查看此内容，但似乎没有很多实现。有建议吗？
— 尼古拉斯
不，对不起 我最终并没有最终使用它，而是总是从头开始做一个实现。
— 莱恩霍尔盖特
9

正如其他人指出的那样，您的问题是非常笼统的，是否某事“比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");
— 烟雾
source
正如我所说，假设TCP在规模的一端，而UDP在规模的另一端，那还有什么。
— Len Holgate
如果您想成为书呆子，讨论的大多数协议都建立在UDP之上。
— smo
TCP在一端而UDP在另一端的假设是错误的。例如，UDP没有流量控制，您可以轻易地以太快的速度发送数据包，从而导致中间的路由器丢弃所有数据包。那你怎么办？忽略丢失的数据包还是重新发送？重新发送它们，您将或多或少地重新实现TCP。可靠通信的另一种选择是SCTP。
— 号
1
快速响应并不一定等于高吞吐量。
— 马特
1
我不同意。当nagle在具有许多较小数据包的基于TCP的协议上使用时，它将把它们合并在一起并创建更多较大的数据包。它会导致发送时间稍有延迟，因此延迟可能会稍微增加。但是，闲置时吞吐量可能会降低，因为更多的数据包=更多的数据包标头=更大的开销。丢弃在局域网上的数据包通常与输入缓冲区的填充有关。如果您有许多将数据发送到同一主机的客户端，则差异可能为零。我不认为关闭和打开nagle会在实践中影响它。
— 马特
8

任何认为以上列表还不够并且想要开发自己的OWN可靠UDP的人，都应该看看Google QUIC规范，因为它涵盖了许多复杂的极端情况和潜在的拒绝服务攻击。我还没有实现它，您可能不需要或不需要它提供的所有内容，但是在着手进行新的“可靠” UDP设计之前，值得阅读该文档。

一个很好的起跳点QUIC是在这里，在在Chromium网志。

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

— 伦·霍尔盖特
source
4

如果您遇到TCP连接可能太慢而UDP'连接'可能太不可靠的情况，该怎么使用？有各种各样的标准可靠的UDP协议，您对它们有什么经验？

句子中的关键字是“潜在”。我认为您确实需要向自己证明，如果您需要协议的可靠性，那么TCP实在太慢了。

如果要从UDP中获得可靠性，则基本上是要在UDP之上重新实现TCP的某些功能，这可能会使事情比起初仅使用TCP慢。

— 26日17
source
是的，Andrew Edgecombe说了很多，但是，正如我说的那样，我对WHAT替代方案的利弊感兴趣。如果没有该替代方案及其优缺点的清单，那么很难决定什么是最好的。
— Len Holgate
给定已知的可靠性功能，有时可以手动调整UDP流，使其在OS中超越TCP流。难得。
— 约书亚
1
@ 26 of 17，我同意Len Holgate，在某些情况下，TCP的速度将比可靠的UDP慢。像高BDP网络一样，假设您从中国到纽约有1 Gbps的互联网连接，我相信TCP几乎可以使用全部1 Gbps的速度。对于地球上的大多数连接而言，TCP更好，但对于具有高带宽延迟乘积的网络而言，TCP则更好。
— nullptr 2014年
2

您是否考虑过压缩数据？

如上所述，我们缺乏有关您问题的确切性质的信息，但是压缩数据进行传输可能会有所帮助。

— 友善的
source
1
尤其是在现代压缩库中。有些跟记忆一样快。例如lz4。
— 马特
-3

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

— 库山辛格
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.