实时聊天推荐引擎的 TCP 与 UDP？答案

【问题标题】：TCP vs UDP for real-time chat recommendation-engine?实时聊天推荐引擎的 TCP 与 UDP？
【发布时间】：2016-07-12 07:45:18
【问题描述】：

我正在构建一个聊天应用程序，其中用户的每次击键都会发送到服务器。在服务器端，基于 nlp 的推荐引擎根据当时键入的消息的上下文生成推荐。

对于大规模部署，TCP 和 UDP 之间的连接类型更可取。 UDP 速度快但不可靠，而可靠的 TCP 实时速度可能很慢。例如：用户输入“嘿，让我们看”字样并快速清除文本框，清除文本框后不应生成电影推荐。

如果服务器有推荐，应该保证将推荐返回给客户端。

目的是获得低延迟的实时推荐。哪种类型更可取？

【问题讨论】：

在与人类打字员/阅读者交互时，延迟的差异是一个有争议的问题。

标签： networking tcp udp real-time recommendation-engine

【解决方案1】：

如果一次发送的数据大小小于单个帧的最大负载，则 TCP 和 UDP 几乎相同。

在这种情况下，UDP 在实时行为方面会更加“可靠”，因为数据的处理方式更多地掌握在您手中。当然，缺点是您必须自己处理某些 TCP 将免费提供给您的东西。

另一方面，使用 TCP 时，协议栈的 TCP 层可能会弄乱您的实时要求，而您甚至没有机会对此做任何事情。有没有想过重传（大约 +200 毫秒的传输时间）、nagle 算法（小数据包延迟最多 200 毫秒）、延迟的 TCP ACK（可能会导致某些堆栈上的重传）？如果您有严格的实时要求，还有更多库存可供您使用。

我正在做一个项目，该项目有 20 毫秒的时间范围，并在这段时间内使用 TCP 传输大量数据。尽管我们有星型架构和实时操作系统，但要让这个工作可靠是地狱般的（很多影响是由于我们使用的以太网芯片之一 smsc91c111）。

结论是没有“最好的方法”来做这样的事情，因为 UDP 和 TCP 都不是实时协议。但由于在它们之间切换相当容易，我建议简单地对其进行测试并选择最有效的协议。

【讨论】：

没有用户会注意到聊天应用程序中有 20 毫秒的延迟。
@RonMaupin 是的，但 200 毫秒是显而易见的。 20ms 只是一个例子，聊天应用程序不会像我在项目中那样有严格的实时要求。
实时 VoIP 在超过 250 毫秒之前都可以。我只是看不到有人可以输入消息，等待回复，并注意到网络将回复延迟了 200 毫秒，而对方阅读然后输入单个字母所需的时间要长得多。跨度>
@RonMaupin 这也是真的。这一切都取决于在问题的上下文中不清楚的要求，即优先选择哪种协议。问题是“用户的每次击键都会发送到服务器”......如果你按下一个键并且你的键在 200 毫秒后出现，那肯定是显而易见的。我们也不知道最终应用程序的架构或数据流将如何。我要说的是，TCP 有很多很好的特性，但在实时行为方面不一定是首选或至少需要仔细考虑。
那是真的，如果在发送下一个按键之前必须确认每个按键，但这不太可能； TCP 不需要一对一的 ACK。更有可能的是，VoIP 可以容忍这种延迟的原因是第一个键可以延迟 200 毫秒发送，而下一个键在第一个键击到达之前发送。击键到达的时间与键入它们所需的时间相同，但有一个初始延迟。单独发送的击键显示在另一端，击键之间的延迟与类型所用的延迟相同。