严重的高性能服务器的 Tcp 可靠性与 Udp 负担 [英] Tcp Reliability versus Udp Burdens for serious, high-performance server
问题描述
速度、优化和可扩展性是 Udp 和 Tcp 协议之间的典型比较.Tcp 吹捧可靠性，但缺点是有一点额外开销，但速度非常好.一旦实例化了 Tcp 套接字，保持套接字打开需要 一些 开销.但是与经常描述的 Udp 的负担相比，哪个协议实际上有更多的开销?我还听说 Tcp 存在可伸缩性问题……但 Internet(网页/服务器)在 Tcp 上运行 - 那么 Tcp 抑制可伸缩性的原因是什么?
Speed, optimization, and scalability are the typical comparisons between the Udp and Tcp protocols. Tcp touts reliability with the disadvantage of a little extra overhead, but speed is good to excellent. Once a Tcp socket is instanced, keeping the socket open requires some overhead. But compared to the oft described burdens of Udp, which protocol actually has more overhead?. I've also heard that there are scalability issues with Tcp...yet the Internet (Web pages/servers) runs on Tcp - so what is it about Tcp that inhibits scalability?
好的...所以 Udp 不需要保持连接打开的开销.但是，它需要您编写额外的方法来确保所有数据包都到达那里，希望按照您希望接收的顺序.如果没有完整收到一个数据包，那么您必须告诉客户端或服务器重新发送.您还必须为部分数据包保留某种消息集合，重建部分消息，并在最终处理消息之前检查完整的消息.更不用说消息的第二部分是否永远不会发送，您必须说重新发送整个内容，或者重新发送我们丢失的部分，或者其他什么.
Okay...so Udp doesn't require that overhead of keeping a connection open. But, it requires that you write extra methods to ensure all of the packet gets there, hopefully in the order that you want it received. If a packet isn't received in full, then you have to tell the client or server to resend. And you also have to keep some sort of message collection for partial packets, rebuild the partial messages, and check for a complete message before the message can finally be processed. Not to mention if the second part of a message never makes it, you have to either say resend the entire thing, or resend the part we are missing, or whatever.
基本上，我的问题是:
- 为什么我会选择 Udp 而不是 Tcp 作为一个严肃的高性能服务器，并增加了消息的开销"检查和手动 ACK 与连续流的开销"?
- 如果 Tcp 对《魔兽世界》之类的游戏来说已经足够好了，为什么 Tcp 没有被更广泛地接受为用于游戏服务器的协议?
注意:我不反对为服务器实施 Udp 选项.我们在 .Net 3.5 框架上使用 C#.所以我也会对处理 Udp 负担的最佳实践感兴趣.我也在 socket 级别使用异步方法，而不是使用 TcpListener、TcpClient 等.
Note: I am not opposed to implementing Udp options for a server. We are using C# on .Net 3.5 framework. So I would also be interested in the best practices for dealing with Udp burdens. I am also using the asynchronous methods at the socket level rather than using TcpListener, TcpClient, etc. etc.
推荐答案
好吧，我建议多读一些.有很多地方可以查看 TCP 与 UDP 的优缺点，反之亦然，这里有一些:
Well, I would recommend reading up some more. There are plenty places to look at the pro's and con's of TCP vs. UDP and vice versa, here are a few:
但是，此链接可能是您最感兴趣的，因为它直接与网络游戏编程有关:
However, this link may interest you the most, as it is directly about networked game programming:
如果我要引用一些小事:
If I were to quote something small:
那么这个决定似乎很明确，TCP 做我们想做的一切，它的超级好用，而 UDP 是一个巨大的屁股疼，我们必须编码一切都是我们自己从头开始.所以显然我们只是使用 TCP 对吧?
The decision seems pretty clear then, TCP does everything we want and its super easy to use, while UDP is a huge pain in the ass and we have to code everything ourselves from scratch. So obviously we just use TCP right?
错了.
使用 TCP 是最糟糕的开发时可能犯的错误网络游戏！要理解为什么，你需要查看 TCP 实际在做什么上面的 IP 让一切看起来如此简单！
Using TCP is the worst possible mistake you can make when developing a networked game! To understand why, you need to see what TCP is actually doing above IP to make everything look so simple!
不过，我仍然建议您自行研究此事，并最终确定哪种协议适合您的需求.话虽这么说，但似乎大多数游戏都使用 UDP 传输数据.任何持续更新整个状态的东西都不需要保证数据包传递的开销.
I still recommend doing your own research on the matter though, and make sure which of the protocols suits your needs at the end of the day. This being said, it does seem to be the case that majority of games use UDP for their data. Anything that updates the entire state continuously does not need the overhead of guaranteed packet delivery.
这篇关于严重的高性能服务器的 Tcp 可靠性与 Udp 负担的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
