Должно ли мое устройство IoT опрашивать по HTTP или прослушивать по TCP?

Итак, с какой частотой опрос HTTP создает больше накладных расходов, чем просто постоянное поддержание TCP-соединения открытым? 5 с? 3 секунды? 1с?

Ничего не нужно делать, чтобы оставить TCP-соединение открытым. Единственное, что вам может понадобиться, это использовать TCP keep-alive (который не имеет ничего общего с HTTP keep-alive!), если вы хотите, чтобы соединение оставалось бездействующим (т. е. без отправки данных) в течение длительного времени.

с HTTP ваши накладные расходы уже начинаются с первого запроса, поскольку ваши данные должны быть инкапсулированы в HTTP-сообщение. Эти накладные расходы могут быть сравнительно небольшими, если сообщение большое, или легко могут быть намного больше, чем само сообщение для небольших сообщений. Кроме того, HTTP-сервер закрывает TCP-соединение после некоторого времени простоя, поэтому вам может потребоваться повторно установить TCP-соединение для следующего обмена данными, что опять-таки связано с накладными расходами и задержкой.

Преимущество HTTP заключается в том, что он проходит через большинство брандмауэров и прокси-серверов, а у простого TCP нет. Вы также получаете бесплатное шифрование с HTTPS, то есть существуют установленные стандарты для прямого зашифрованного соединения и для туннелирования через прокси.

WebSockets — это нечто среднее: вы делаете HTTP-запрос, а затем обновляете HTTP до WebSocket. Таким образом, начальные накладные расходы такие же большие, как и для HTTP, но для следующих сообщений накладные расходы не намного выше, чем для TCP. И вы также можете использовать WebSockets с HTTPS (т.е. wss:// вместо ws://). Он проходит через большинство простых брандмауэров и прокси-серверов, но у брандмауэров с более глубокими проверками могут возникнуть проблемы с ним.

Настройка прослушивателя TCP будет проблемой, если ваше устройство IoT находится за каким-либо маршрутизатором NAT, то есть обычная настройка внутри частных сетей или сетей SoHo. Чтобы получить доступ к устройству, необходимо открыть туннель на маршрутизаторе извне в сеть либо путем администрирования маршрутизатора вручную, либо с помощью UPnP (который часто отключается из соображений безопасности). Таким образом, вы создадите слишком много проблем для обычного пользователя.

Это означает, что наименьшее количество проблем для клиента, вероятно, связано с HTTP-опросом. Но это также тот, у которого самые высокие накладные расходы. По-прежнему в основном совместимы WebSockets, у которых меньше накладных расходов и больше проблем, но еще меньше накладных расходов можно достичь с помощью простого TCP на сервер. Вместо этого прослушиватель TCP вызовет слишком много проблем.

Что касается ресурсов на стороне сервера: каждый HTTP-запрос на опрос может использовать новое TCP-соединение, но вы также можете повторно использовать существующее. В этом случае вы можете выбирать между большими накладными расходами и задержкой на стороне клиента (новое TCP-соединение для каждого запроса), для которой требуется мало ресурсов на стороне сервера, и меньшими накладными расходами и задержкой на стороне клиента, для которой требуется больше ресурсов на стороне сервера (несколько HTTP-запросы на TCP-соединение). С WebSockets и простым TCP-соединением вам всегда нужно больше ресурсов на стороне сервера, если только ваш клиент не будет автоматически восстанавливать соединение при потере соединения.

В наши дни вы должны использовать специальный протокол связи IOT через TLS 2.0 для безопасных легких соединений. Например, AWS использует MQTT http://mqtt.org/, а Azure использует AMQP https://www.amqp.org/

Идея состоит в том, что вы получаете брокера, к которому можно безопасно подключиться, а затем используете протокол обмена сообщениями с темой для маршрутизации сообщений на соответствующие устройства. Кроме того, IBM уже давно использует MQTT, и теперь маршрутизаторы обычно поставляются с открытым портом 8883, который представляет собой MQTT через TLS.

Удачи!

Просто используйте SignalR для подключения клиента и сервера. Это обеспечивает минимальную задержку без опроса. API очень прост в использовании.

Физически это работает через веб-сокеты, которые масштабируются до большого количества одновременных подключений. Если вам не нужно более 100 КБ на сервер Windows, это не будет проблемой.