信号R开销

Question

我有一个客户端，它通过定期（每 4 秒）发送它的新位置来更新它在服务器上的位置。我还有一个客户端，它通过定期轮询服务器（每 5 秒）并获取最新位置来跟踪以前的手机。

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

谢谢你， 赖安

Answer 1

HTTP 通信胜利

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

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

请求大小赢

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

编程模型胜

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