如果您的TCP连接可能太慢并且UDP"连接"可能太不可靠,您使用什么？有各种标准的可靠UDP协议,你有什么经验吗？
请在每个回复中讨论一个协议,如果其他人已经提到您使用的协议,则考虑将其投票并使用评论进行详细说明(如果需要).
我对这里的各种选项感兴趣,其中TCP位于规模的一端而UDP位于另一端.提供了各种可靠的UDP选项,每个选项都带有TCP到UDP的一些元素.
我知道TCP通常是正确的选择,但是有一个备选列表通常可以帮助我们得出结论.像UDP,RUDP等基于UDP构建的东西各有利弊,你使用它们,你的经历是什么？
为了避免疑问,没有更多的信息,这是一个假设的问题,我希望这个问题会引出一个回复列表,详细说明需要做出决定的人可以使用的各种选项和备选方案.
怎么样SCTP.它是IETF的标准协议(RFC 4960)
它具有分块功能,可以帮助提高速度.
更新:TCP和SCTP之间的比较表明,除非可以使用两个接口,否则性能是可比较的.
更新:一篇很好的介绍性文章.
如果没有关于问题领域的一些额外信息,很难回答这个问题.例如,您使用的数据量是多少？多常？数据的性质是什么？(例如,它是唯一的,一个是关闭数据吗？还是一个样本数据流？等等)你在开发什么平台？(例如,桌面/服务器/嵌入式)要确定"太慢"的含义,您使用的网络介质是什么？
但在(非常!)一般术语中,我认为你必须非常努力地尝试使用tcp来提高速度,除非你可以对你试图发送的数据做出一些严格的假设.
例如,如果您尝试发送的数据是这样的,您可以容忍丢失单个数据包(例如,采样率比信号带宽高很多倍的定期采样数据)那么您可能通过确保您可以检测到数据损坏(例如,通过使用好的crc)来牺牲一些传输可靠性
但是如果你不能容忍丢失单个数据包,那么你将不得不开始介绍tcp已经拥有的可靠性技术类型.并且,如果不进行合理的工作量,您可能会发现您已经开始将这些元素构建到用户空间解决方案中,并且具有所有固有的速度问题.
ENET - http://enet.bespin.org/
我已经使用ENET作为可靠的UDP协议,并为我的客户在其服务器中使用它编写了一个异步套接字友好版本.它运行得很好,但我不喜欢对等ping增加空闲连接的开销; 当你有很多连接时,定期ping所有连接是很繁忙的工作.
ENET为您提供了发送多个"通道"数据和发送的数据不可靠,可靠或有序的选项.它还包括前面提到的点对点ping,它起着保持活力的作用.
我们有一些使用UDT(基于UDP的数据传输)的国防工业客户(请参阅http://udt.sourceforge.net/)并对此非常满意.我看到它也有一个友好的BSD许可证.
RUDP - 可靠的用户数据报协议
这提供:
确认收到的数据包
窗口和拥塞控制
丢失数据包的重传
过度缓冲(比实时流更快)
关于保持alive然后ENet似乎稍微可配置,但是它没有给你那么多的选项(即所有数据都是可靠的并且不仅仅是你决定的比特序列).实施起来看起来相当简单.
正如其他人所指出的那样,你的问题非常笼统,而且某些东西是否比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");
任何决定上面的列表不够并且他们想要开发他们的OWN可靠UDP的人肯定应该看看Google QUIC规范,因为这涵盖了许多复杂的角落案例和潜在的拒绝服务攻击.我还没有玩过这个的实现,你可能不想要或者不需要它提供的所有东西,但是在开始一个新的"可靠的"UDP设计之前,这个文件非常值得一读.
在Chromium博客上,QUIC的一个很好的起点就在这里.
可以在此处找到当前的QUIC设计文档.
京公网安备 11010802040832号 | 京ICP备19059560号-6 