因此，我认为实时更新/通信的定义是当一个用户所做的更新在完成后立即转发给订阅该对象的其他用户。
但这不是瞬时的（数据需要有限的时间才能传播）。所以我想这意味着很短的时间。
如果您每 5 秒使用一次 ajax 轮询，那么用户 A 看到用户 B 所做的事情所用的时间是：5+t1+t2（数据（http 请求）从用户 B 的 PC 到服务器所用的时间。t2 是数据从服务器传输到用户 A 的 PC 所需的时间）。
t1+t2 是不能从图片中取出的最小延迟（确保套接字减少了这个时间，但这些因素仍然存在，无论多么小）。因此，对于套接字，您可以延迟 t1+t2+d。d 是服务器注意到内部发生的事件并传播它所花费的时间（取决于 CPU 能力） 我的问题是：是否有任何既定的基准/标准来定义 d 应该有多小才能使通信成为实时。
或者实时只是我们每天抛出的一个通用术语？这纯粹是出于好奇，而不是任何应用程序。我只是好奇是否有任何既定的实时数据标准。
“是否有任何既定的基准/标准来定义实时通信的 d 应该有多小？”
你的问题是有效的。应用程序始终由特征延迟时间定义t。在不同的上下文中，“实时”相对于t.
我想说的是，在涉及 Web 和人类用户的应用程序上下文中定义实时事件处理的公认“标准”是（多个）用户应该能够与应用程序交互而不会“感觉到”阻碍延迟。应用程序必须“感觉反应灵敏”。在数字上，这可能意味着请求和响应（通用术语）之间的总延迟时间不应高于约 100 毫秒。人类对现实世界事件的响应时间就是这个数量级。需要极快反应时间的在线游戏绝对可以玩，总延迟（往返）时间在 10 到 60 毫秒之间。
在其他情况下，例如在实验室或工业中控制机器，实时事件处理有时意味着保证在毫秒、微秒甚至更快的时间内处理事件。这是一个完全不同的情况。
回到 Web 应用程序，我认为现代实时 Web 服务具有以下一个或多个特征：
我希望这可以笼统地回答您的问题。如果您想更具体地了解某些内容，请随时发表评论。