timer - 信号R开销

Question

我有一个客户端，它通过定期(每 4 秒)发送它的新位置来更新它在服务器上的位置。我还有一个客户端，它通过定期向服务器(每 5 秒)花粉并获取最新位置来跟踪以前的移动设备。

这种通信应该通过 SignalR(用于发送最新位置)还是使用计时器进行？我这么说是因为 SignalR 有一些开销会产生更大的请求大小，这可能非常昂贵。

谢谢，
瑞安

Answer 1

HTTP 通信胜利

现在，根据我对您描述的理解，您正在执行多个更新 POST，然后监听器正在使用轮询 GET 请求。这些具有带有 header 的单独 HTTP 请求的开销，如果不使用保持连接或超过保持连接超时，则 [重新] 建立 TCP 连接。

使用 SignalR，您将能够至少改善事物的轮询 GET 方面，因为 SignalR 可以使用长轮询，这将通过单个 HTTP GET 请求汇集多个响应，并以“实时”而不是总是进行有一个艰难的 4 秒延迟时间。从那里开始，您可以根据客户端和服务器功能，通过服务器发送事件 (SSE) 到成熟的 Web 套接字。这些方法中的任何一种都应该比您当前描述的实现更有效。

请求大小获胜

每个 SignalR 消息周围只有一个小的“信封”。与 HTTP header 相比，您的浏览器客户端现在肯定必须在每次更新 POST 和轮询 GET 时发送，我认为 SignalR 将轻松获胜。显然，在任何一种情况下，消息的有效负载都是相同的 JSON，所以这是一个问题。

编程模型获胜

最重要的是，我认为，使用 SignalR 为您提供了一个编程模型，该模型将您从最终使用的确切底层技术中抽象出来，并为您提供一致的实时通信 API，而不必最终担心中断到断开连接的请求/响应模型。