最低延迟的小数据互联网传输协议？时间：2019-03-17 标签：c#
我正在做一个互联网游戏项目，其中涉及在两台普通家用电脑之间通过互联网不断发送小规模数据（1K 到 50K 之间）。我关心的关键是延迟。
据我所知，TCP、UDP是流行的。 TCP 可靠，但比 UDP 慢，而 UDP 不安全，我必须实现自己的故障处理代码。
我只是想知道是否有其他协议可以遵循在两台普通家用电脑之间发送/接收小数据？
就普通家用电脑而言，我假设它们具有普通宽带（512kbps - 2Mkbps）并且遍布世界各地（可能在美国和日本之间）。
另一个大问题是：
如果我从一台电脑（在英国）ping 另一台电脑（在日本），我会得到 300 毫秒的延迟。是否有可能找到一种协议或使用 TCP/UDP 在低于 300 毫秒延迟的情况下发送/接收 1KB 数据？或者 ping 应该是了解两个端点之间最低延迟的最快方法？
谢谢
I am doing a Internet Gaming project which involving keeping sending small size of data (between 1K to 50K) over the Internet between two normal home PCs. The key I care about is the latency.
I understand TCP, UDP are the popular ones. TCP is reliable but slower than UDP while UDP is not safe and I have to implement my own fault-handling codes.
I am just wondering are there any other protocols I can follow to send/receive small data between two normal home PCs?
by the term of normal home PCs, I assume that they have normal broadband (512kbps - 2Mkbps) and all around the world (maybe between US and Japan).
Another BIG question is that:
If I ping from one pc (in UK) to another (in Japan), I get 300ms latency. Is that possible to find one protocol or use TCP/UDP to send/receive 1KB data below this 300ms latency?? or ping should be the fastest way to know the lowest latency between two end points??
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
TCP 标头为 32 字节，而 UDP 标头只有 16 字节。此外，由于UDP缺乏流量控制，因此永远不会出现客户端要求服务器放慢速度的情况。 UDP 几乎肯定是最快的。 ICMP 数据包的标头为 20 字节，可能比 UDP 稍慢。
我的官方建议是使用 UDP，在接收端进行一些“丢包”检测。这就是所有 Quake 游戏和所有 Half-Life/Source 游戏的工作原理。
就英国和日本之间的 ping 而言，对于所使用的任何协议，延迟几乎相同。其中大部分是由光速和边缘路由器的拥塞程度决定的。
A TCP header is 32 bytes, while a UDP header is only 16 bytes. In addition, since UDP lacks flow control there will never be a case where the client asks the server to slow down. UDP is almost definitely going to be the fastest. An ICMP packet has a header that is 20 bytes, and is probably going to be slightly slower than UDP.
My official recommendation is to use UDP, with some "dropped packet" detection at the receiving end. This is how all of the Quake games and all of the Half-Life/Source games work.
On the topic of pinging between UK and Japan, the latency is going to be near identical for any protocol used. Most of that is dictated by the speed of light and the congestion of the edge-routers.
您永远不会因延迟而击败 ping 命令，因为它们使用 ICMP，这大约是最轻量级的选项。
通常，对于游戏情况，使用 UDP，主要是因为涉及速度。有了良好的宽带连接，TCP 应该没问题，并且会让生活变得更轻松，因为您可以保证 UDP 无法提供的传输。
话虽如此，对于游戏来说，1K，尤其是 50K，是一个非常大的数据量，特别是如果需要连续发送的话。如果您要发送那么多数据，请预期并计划延迟 - 通常这意味着预测网络上会发生什么，并在数据通过时进行补偿，而不是等待数据到达。
You will never beat ping commands for latency, since they use ICMP, which is about the most lightweight option out there.
Typically, for gaming situations, UDP is used, primarily because of the speed involved. With a good broadband connection, TCP should be fine, and will make life easier since you have guarantees about delivery that are otherwise missing from UDP.
That being said, for gaming purposes, 1K, and especially 50K, is a very large amount of data, especially if this needs to be sent continuously. If you're sending that much data, expect and plan for the latency - often this means anticipating what will happen across the wire, and compensating when the data comes through, instead of waiting on the data to arrive.
如果您想通过 Internet 进行通信，您就被迫使用 IP 系列协议。这并不妨碍您在 IP 之上创建自己的协议，但当然，它在延迟方面不会更快。您所能做的就是实施压缩，以最大限度地减少通过线路发送的有效负载。
If you want to communicate over the Internet you are forced to use IP family of protocols. That doesn't prevent you from creating your own protocol on top of IP, but it won't be faster in terms of latency, of course. All you can do is implement compression in order to minimize payload sent over the wire.