sockets - 是否有用于实时通信(websocket或ajax轮询等)的基准？

Question

因此，我认为实时更新/通信的定义是，一个用户所做的更新在完成后立即转发给订阅该对象的其他用户。

但这不是瞬时的(数据需要有限的时间才能传输)。所以我想那意味着很短的时间。

如果您每5秒使用ajax轮询，则用户A看到用户B所做的事情所花费的时间为:5 + t1 + t2(数据(http请求)从用户B的PC到达服务器所花费的时间。t2为数据从服务器到达用户A的PC所需的时间)。

t1 + t2是无法从图片中提取的最小延迟(确保套接字减少了此时间，但是这些因素仍然存在，无论它是多少)。
因此，在使用套接字的情况下，可能会有t1 + t2 + d的延迟。 d是服务器注意到事件在内部发生并进行传播所花费的时间(取决于CPU能力)
我的问题是:是否有任何确定的基准/标准来定义实时通信应具有的d小。

还是实时只是我们每天都会使用的一个通用术语？
这完全出于好奇而不是任何应用。我很好奇，是否有针对实时数据的既定标准。

Answer 1

"is there any established benchmark/standard that defines how small d should be for the communication to be realtime?"

您的问题是有效的。应用程序始终由特征等待时间 t定义。在不同的上下文中，就 t而言，“实时”可能具有完全不同的含义。

我会说，在涉及Web和人类用户的应用程序上下文中定义实时事件处理的公认“标准”是(多个)用户应该能够与应用程序交互，而不会“感觉到”延迟。应用程序必须“感到响应”。从数量上讲，这可能意味着请求和响应之间的总体延迟时间(一般术语)应不大于约100毫秒。人类对现实世界事件的响应时间在这个数量级上。要求极快 react 时间的在线游戏绝对可以在10到60毫秒之间的总延迟(往返)时间上玩。

在其他情况下，例如在实验室中或用于控制行业中的机器，实时事件处理有时意味着 保证事件处理在几毫秒，几微秒甚至更快的时间内进行。这是完全不同的情况。

回到Web应用程序，我认为现代实时Web服务显示以下一个或多个特征:

用户界面的响应速度非常快，部分通过本地执行来实现，例如JavaScript。在用户端(例如，浏览器)中运行的代码与远程Web应用程序之间的最终通信是异步执行的(对用户隐藏)。

后端实现基于有效的事件处理技术，而不是定期轮询。

在用户和后端之间使用持久的TCP/IP连接，以消除由于连接打开/关闭而引起的延迟和开销(例如WebSocket发挥作用的位置)

我希望这可以概括地回答您的问题。如果您想了解更具体的信息，请随时发表评论。