速度,优化和可扩展性是Udp和Tcp协议之间的典型比较.Tcp吹嘘可靠性有一点额外开销的缺点,但速度很好,非常好.一旦Tcp套接字被实例化,保持套接字打开需要一些开销.但与Udp所描述的负担相比,哪种协议实际上有更多的开销？我也听说过Tcp存在可扩展性问题......但是互联网(网页/服务器)在Tcp上运行 - 那么Tcp是什么阻碍了可扩展性呢？
好的...所以Udp不需要保持连接打开的开销.但是,它要求您编写额外的方法以确保所有数据包都到达那里,希望按照您希望它接收的顺序.如果未完整收到数据包,则必须告知客户端或服务器重新发送.此外,您还必须为部分数据包保留某种消息收集,重建部分消息,并在最终处理消息之前检查完整的消息.更不用说如果消息的第二部分永远不会成功,你必须要么重新发送整个内容,要么重新发送我们缺少的部分,或者其他什么.
基本上,我的问题是:
为什么我会选择Udp over Tcp作为一个严肃的高性能服务器,增加了消息检查和手动ACK的"开销"与连续流的"开销"？
如果Tcp对于魔兽世界来说足够好,为什么Tcp不被广泛接受作为游戏服务器使用的协议？
注意:我不反对为服务器实现Udp选项.我们在.Net 3.5框架上使用C#.所以我也对处理Udp 负担的最佳实践感兴趣.我也在套接字级别使用异步方法,而不是使用TcpListener,TcpClient等.
好吧,我建议再读一些.有很多地方可以查看TCP与UDP的专业版和内容,反之亦然,这里有几个:
使用TCP over UDP的优点是什么？
我应该何时使用UDP而不是TCP？
TCP和UDP
UDP over TCP有哪些优点？
但是,这个链接可能对您最感兴趣,因为它直接与网络游戏编程有关:
游戏上的灯光 - UDP与TCP
如果我引用一些小的东西:
这个决定似乎很清楚,TCP做了我们想要的一切,而且它非常容易使用,而UDP是一个巨大的痛苦,我们必须自己从头开始编码.显然我们只是使用TCP吗？
错误.
使用TCP是开发网络游戏时可能犯的最大错误!要了解原因,您需要了解TCP在IP之上的实际操作,以使一切看起来如此简单!
我仍然建议您自己研究这个问题,并确保哪些协议在一天结束时符合您的需求.话虽如此,似乎大多数游戏都使用UDP作为数据.任何不断更新整个状态的东西都不需要保证数据包传输的开销.
首先,我将从Unix网络编程部分22.4"何时使用UDP而不是TCP"中解释史蒂文斯:
他基本上说了以下几点:
UDP是广播/多播的唯一选择 - 因此您必须在那里使用它.
UDP 可用于简单的请求/回复应用程序.但你必须添加自己的错误检测意味着至少ack,超时和重新传输.
UDP 不应该用于批量数据传输(文件传输),因为您必须在TCP中构建所有功能以使其正常工作.
UDP 应该用于实时数据,其中交付速度是最重要的,并且一些数据丢失不是诸如实时传感器数据,实时多媒体流,实时股票报价等的问题.
第一个问题的答案非常依赖于您对"高性能"的定义.如果您主要担心的是低延迟,即尽可能快地到达UDP的单个数据包/请求将是最佳选择.这有两个主要原因.假设数据包/请求相互独立,而不是使用TCP会引入一个称为行头阻塞的问题.
假设您发送两个独立的数据包/请求.首先是A然后B.由于TCP是基于流的,如果A在网络中丢失并需要重新传输,那么即使B已经成功到达,也不能通过堆栈将其传送到应用程序,直到A到达,引入不必要的延迟.不仅如此,但是在A到达之前,堆栈不能确认B,这可能导致B也被重传,从而导致不必要的网络拥塞.
解决此问题的一种方法是为每个请求使用单独的连接,但这也会引入延迟和生成系统资源.UDP绕过所有这些问题.
高性能(低延迟)服务器中的另一个问题是Nagle算法,它可以在TCP通信中增加显着的延迟.
你的第二个问题的答案是WoW可能发送数据流,而不是独立的请求/回复对.此外,通过禁用Nagle算法可以消除TCP的一些延迟.如果他们确实使用了一些请求/回复通信,他们可能只是做出了一个设计决定,即可靠性比延迟更重要.
京公网安备 11010802040832号 | 京ICP备19059560号-6 