TCP 与可靠 UDP
我正在编写一个应用程序，其中客户端将通过无线链路将数据上传到服务器。
连接应该非常可靠。链接预计会多次中断，并且会有很多客户端连接到服务器。
我很困惑是使用 TCP 还是可靠的 UDP。
请分享您的想法。
谢谢。
I am writing an application where the client side will be uploading data to the server through a wireless link.
The connection should be very reliable.The link is expected to break many times and there will be many clients connected to the server.
I am confused whether to use TCP or reliable UDP.
Please share your thoughts.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当然，RUDP 不是一个正式的标准，并且不知道您是否会找到可以使用的现有实现。如果要在从头开始和重新建立 TCP 连接之间做出选择，我选择了 TCP。
RUDP is not, of course, a formal standard, and there's no telling if you will find existing implementations you can use. Given a choice between rolling this from scratch and just re-making TCP connections, I'd chose TCP.
为了安全起见，我会选择 TCP，因为它是一个可靠的标准协议。 RUDP 的缺点是不是一个既定标准（尽管在一些 IETF 讨论中已经提到过）。
祝你的项目好运！
To be safe, I would go with TCP just because it's a reliable, standard protocol. RUDP has the disadvantage of not being an established standard (although it's been mentioned in several IETF discussions).
Good luck with your project!
您的 TCP 和 RUDP 链接很可能都会被您的环境破坏，因此您使用 RUDP 的事实不太可能对此有所帮助；有时可能没有数据报可以通过...
您真正需要确保的是a）您可以处理连接的客户端数量，b）您的应用程序协议可以在您失去连接时相当快地检测到使用客户端（或服务器）和 c) 您可以处理客户端所需的重新连接和交叉连接会话状态的维护。
只要您处理 b) 和 c)，连接是否不断断开并不重要。确保你设计的应用程序协议能够在短时间内完成任务；因此，如果您要上传文件，请确保发送的是小块，并且应用程序协议可以恢复中途中断的传输；您不希望 2GB 传输完成 99% 后就失去连接并必须重新开始。
为此，您的服务器需要某种客户端会话状态缓存，您可以在连接本身的生命周期之外保留客户端连接的逻辑状态。从一开始就预期给定会话包含多个单独的连接。会话状态可能应该有某种超时，因此如果客户端长时间离开，它不会继续消耗服务器上的资源，但说实话，这可能只是在之后将状态保存到磁盘的情况一会儿。
总之，我认为传输方式的选择并不重要，我至少会选择 TCP。真正重要的是能够在服务器上管理客户端的会话状态并处理客户端定期连接和断开连接的事实。
It's likely that both your TCP and RUDP links would be broken by your environment, so the fact that you're using RUDP is unlikely to help there; there will likely be times when no datagrams can get through...
What you actually need to make sure of is that a) you can handle the number of connected clients, b) your application protocol can detect reasonably quickly when you've lost connectivity with a client (or server) and c) you can handle the required reconnection and maintenance of cross connection session state for clients.
As long as you deal with b) and c) it doesn't really matter if the connection keeps being broken. Make sure you design your application protocol so that you can get things done in short batches; so if you're uploading files, make sure that you're sending small blocks and that the application protocol can resume a transfer that was broken half way through; you don't want to get 99% of the way through a 2gb transfer and lose the connection and have to start again.
For this to work your server needs some kind of client session state cache where you can keep the logical state of a client's connection beyond the life of the connection itself. Design from the start to expect a given session to include multiple separate connections. The session state should possibly have some kind of timeout so if the client goes away for along time it doesn't continue to consume resources on the server but, to be honest, it may simply be a case of saving the state off to disk after a while.
In summary, I don't think the choice of transport matters and I'd go with TCP at least to start with. What will really matter is being able to manage your client's session state on the server and deal with the fact that clients will connect and disconnect regularly.
如果您不确定，您很可能应该使用 TCP。一方面，它肯定会成为任何支持 IP 的网络堆栈的一部分。 “可靠的 UDP”很少得到开箱即用的支持，因此您需要为客户进行一些额外的支持工作。
If you aren't sure, odds are that you should use TCP. For one thing, it's certain to be part of the network stack for anything supporting IP. "Reliable UDP" is rarely supported out of the box, so you'll have some extra support work for your clients.