asp.net - 我的物联网设备应该使用HTTP轮询还是使用TCP监听？

Question

我正在使用.NET Micro Framework和ASP.NET WebAPI(可能在Azure中)创建IoT设备+服务器系统。

物联网设备需要能够经常更新服务器的统计信息，同时还能够偶尔接收来自服务器的传入命令，这些命令会改变其行为。从这个意义上讲，设备需要同时充当客户端和服务器本身。

我担心的是在设备的安全性和服务器上的负载之间获得最佳平衡。此外，在需要发出命令的服务器与执行该命令的设备之间必须有相对较低的延迟时间。几秒钟的时间。

如我所见，我的选择是:

连接到Internet时，设备会建立与服务器的持久TCP连接，然后将其用于轮询和接收命令。

设备在端口(例如HttpListener)上监听传入命令，同时通过频繁的HTTP请求更新服务器。

设备仅通过HTTP请求轮询服务器。服务器使用响应来给设备命令。

第二个选项似乎最不安全，因为该设备将具有开放的传入端口。第一个选项看起来最难以可靠实现，因为它需要底层套接字编程。第三个选项似乎简单且安全，但是由于延迟要求，设备将需要每隔几秒钟轮询一次。这会影响系统的可伸缩性。

那么，HTTP轮询比仅仅保持TCP连接保持打开状态会产生更多的开销吗？ 5秒？ 3秒？ 1秒？还是我夸大了在ASP.NET中保持TCP连接打开的开销？还是有一种完全不同的方法可以实现？

谢谢。

Answer 1

So at what frequency does HTTP polling create more overhead than just constantly keeping a TCP connection open? 5s? 3s? 1s?

没有任何事情可以保持TCP连接打开。您唯一需要做的就是使用TCP保持 Activity 状态(与HTTP保持 Activity 状态无关!)，以防长时间保持连接空闲(即无数据要发送)。

使用HTTP，您的开销已经从第一个请求开始，因为您的数据需要封装到HTTP消息中。如果消息很大，则开销可能相当小，或者对于小消息，它可能容易大于消息本身。同样，HTTP服务器在闲置一段时间后会关闭TCP连接，因此您可能需要为下一次数据交换重新建立TCP连接，这又会增加开销和延迟。

HTTP的优势是可以通过大多数防火墙和代理，而普通TCP则不能。您还可以通过HTTPS免费获得加密，即已经建立了直接加密连接和通过代理进行隧道传输的标准。

WebSockets介于两者之间:您执行HTTP请求，然后将HTTP升级到WebSocket。因此，初始开销与HTTP一样大，但是对于接下来的消息，开销并不比TCP高那么多。您还可以使用HTTPS(即wss://而不是ws://)来实现WebSockets。它可以通过大多数简单的防火墙和代理服务器，但是更深层次的检查防火墙可能仍存在问题。

如果您将IoT设备放在某个NAT路由器后面，即在专用或SoHo网络中进行常规设置，则设置TCP监听器将是一个问题。要到达设备，可能需要通过手动管理路由器或使用UPnP(出于安全原因通常将其关闭)从外部打开路由器在网络中的隧道。因此，您将为普通用户带来太多问题。

这意味着对客户影响最小的问题可能是HTTP轮询。但这也是开销最高的那个。 WebSocket仍然是最兼容的，它具有较少的开销和更多的问题，但是通过服务器的简单TCP可以达到更少的开销。相反，TCP监听器会造成太多麻烦。

至于服务器端的资源:每个HTTP轮询请求可能使用新的TCP连接，但是您也可以重用现有的TCP连接。在这种情况下，您可以在服务器端需要较少资源的客户端(每个请求都需要新的TCP连接)的更多开销和延迟之间进行选择，而在客户端需要更多资源的服务器端(多个请求)可以减少开销和延迟。每个TCP连接的HTTP请求)。使用WebSocket和纯TCP连接，您总是需要更多的服务器端资源，除非您的客户端在失去连接时会自动重新建立连接。