Short Polling, Long Polling и WebSocket: какой подход выбрать для SCADA-систем
Когда диспетчерская система должна отображать актуальные показания датчиков, состояния агрегатов и технологические теги, вопрос доставки данных становится одним из ключевых. Недостаточно просто получить значение - важно сделать это с минимальной задержкой, без лишней нагрузки на сервер и чрезмерного сетевого трафика.
В веб-разработке для таких задач обычно применяют три механизма: short polling, long polling и WebSocket. Первый предполагает регулярные запросы клиента, второй удерживает HTTP-соединение до появления новых данных, а третий создаёт постоянный двунаправленный канал. Однако SCADA-среда заметно отличается от обычного сайта: здесь данные поступают непрерывно, а десятки или сотни рабочих мест одновременно наблюдают за одними и теми же технологическими параметрами.
Именно поэтому результаты, привычные для интернет-приложений, не всегда можно напрямую переносить на промышленную автоматизацию. В рамках эксперимента сравнивалась SCADA система мониторинга в реальном времени при количестве клиентов от одного до тысячи. Оценивались загрузка CPU и памяти, объём трафика, задержка доставки тегов и поведение TCP-соединений.
Архитектура тестового стенда
Стенд разделили на две физически независимые части. На хостовой машине работал OpenPLC Runtime, который имитировал программируемый логический контроллер и предоставлял данные через Modbus TCP. Там же запускался генератор нагрузки - консольная программа, воспроизводившая поведение операторских рабочих мест.
Виртуальная машина выполняла роль диспетчерского сервера. На ней в Docker разворачивалось приложение на ASP.NET Core. Сервер подключался к эмулированному ПЛК как Modbus TCP-клиент, получал значения регистров и передавал их клиентам через разные транспортные механизмы.
Сетевая карта виртуальной машины работала в режиме моста. Благодаря этому сервер выглядел как самостоятельный узел локальной сети, а трафик можно было отдельно перехватывать на физическом интерфейсе хоста с помощью tshark. В результате удалось разделить два потока: обмен между диспетчерским сервером и контроллером, а также соединения между сервером и виртуальными клиентами.
Фоновая служба опрашивала контроллер каждые 100 мс. Новые значения помещались в кольцевой буфер на 200 записей, после чего публиковалось событие об изменении. На это событие подписывались все три обработчика доставки.
Для эксперимента использовались следующие конечные точки:
- `/api/shortPolling` - немедленно возвращает текущее состояние;
- `/api/longPolling?lastSequence` - либо отдаёт накопленные данные, либо удерживает запрос до появления обновления;
- `/api/ws` - устанавливает постоянное WebSocket-соединение и отправляет новые значения подписчикам.
Клиенты short polling обращались к серверу каждые 100 мс. Long polling после получения ответа сразу открывал следующий запрос. WebSocket-клиент устанавливал одно соединение и продолжал прослушивать его до завершения теста.
Условия измерений
Число параллельных клиентов последовательно увеличивали: 1, 10, 30, 50, 100, 500 и 1000. Каждый прогон продолжался 30 секунд, а каждую конфигурацию запускали пять раз. После этого вычислялись средние показатели.
Из сетевых дампов извлекались задержка доставки, размер полезной нагрузки, объём служебных данных и число TCP-соединений. В сообщение сервер добавлял собственную временную метку. Задержка определялась как разница между моментом поступления пакета и этой меткой. Чтобы исключить влияние рассинхронизации часов между хостовой и виртуальной системами, результаты нормировались относительно минимального значения внутри каждого теста.
Такая методика позволяет оценивать не только скорость передачи, но и то, насколько эффективно работает система диспетчеризации и мониторинга оборудования при росте числа операторов.
Short polling: простота против лишних запросов
Short polling проще всего реализовать и отлаживать. Клиент регулярно отправляет HTTP-запрос, а сервер сразу возвращает актуальное состояние. Такой подход хорошо подходит для редких обновлений или небольшого числа подключений.
Однако в рассматриваемом сценарии частота опроса совпадала с периодом обновления данных - 100 мс. Если значение не изменилось, сервер всё равно формировал ответ, а клиент всё равно создавал запрос. При увеличении числа рабочих мест количество HTTP-операций росло линейно.
Основной недостаток short polling - значительная доля пустых обращений. Даже при наличии keep-alive серверу приходится обрабатывать заголовки, маршрутизацию, авторизацию и формирование ответа. Поэтому при сотнях клиентов увеличиваются нагрузка на CPU и объём сетевого "мусора".
Long polling: меньше пустых ответов
Long polling устраняет часть недостатков короткого опроса. Если новых данных нет, сервер не отвечает немедленно, а удерживает соединение. Как только появляется очередное изменение, клиент получает результат и сразу создаёт следующий запрос.
При регулярном потоке технологических данных этот механизм существенно снижает количество пустых ответов. Но полностью проблему он не решает: каждое обновление всё равно заканчивается закрытием одного HTTP-запроса и открытием другого. При тысяче клиентов серверу приходится постоянно управлять большим числом циклов ожидания и повторных обращений.
Дополнительную сложность создают тайм-ауты, разрывы соединений, прокси и балансировщики. Для промышленной системы необходимо корректно обрабатывать повторное подключение и передавать параметр `lastSequence`, чтобы клиент не пропустил изменения во время кратковременного сбоя.
Более подробный разбор различий между подходами, включая особенности нагрузки и анализа трафика, представлен в материале о сравнении short polling, long polling и WebSocket в SCADA-системах.
WebSocket: постоянный канал для потоковых данных
WebSocket создаёт одно длительное соединение, по которому сервер может передавать значения сразу после их появления. Это наиболее естественная модель для диспетчерского уровня: контроллер обновил тег - сервер отправил новое значение всем подписанным клиентам.
У WebSocket практически отсутствуют повторяющиеся HTTP-заголовки и постоянные циклы создания запросов. При большом числе подключений это уменьшает сетевые накладные расходы и снижает нагрузку на процессор. Серверу также проще реализовать широковещательную рассылку: одно событие об изменении обрабатывается, после чего отправляется группе активных подписчиков.
При этом WebSocket требует более продуманной серверной архитектуры. Нужно контролировать список подключений, удалять неактивные клиенты, поддерживать повторное соединение, учитывать обратное давление и ограничивать объём очередей. Если один клиент временно не успевает принимать сообщения, его задержка не должна блокировать остальных операторов.
Что важно учитывать в реальном проекте
Выбор транспорта зависит не только от средней задержки. Для SCADA необходимо учитывать надёжность доставки, восстановление после сетевого сбоя, требования к журналированию и безопасность. WebSocket удобен для оперативного отображения, но критически важные команды управления не следует строить исключительно на механизме широковещательной рассылки.
Практичным решением может стать комбинированная схема. Телеметрия передаётся через WebSocket, исторические данные запрашиваются обычным HTTP API, а после восстановления соединения клиент получает пропущенный диапазон по номеру последовательности. Такой подход объединяет низкую задержку и возможность надёжного восстановления состояния.
При проектировании следует заранее определить частоту изменения тегов. Нет смысла отправлять операторскому интерфейсу каждое промежуточное значение, если экран обновляется десять раз в секунду. Для медленных параметров можно применять агрегацию, дедупликацию и передачу только изменившихся тегов. Это уменьшает нагрузку даже при использовании эффективного протокола.
Если требуется разработка SCADA системы под ключ, транспорт передачи данных нужно выбирать на этапе проектирования общей архитектуры, а не добавлять после создания интерфейса. В расчёт должны входить количество тегов, частота их обновления, число операторов, резервирование серверов и сценарии потери связи.
Итог
Short polling остаётся самым простым вариантом, но при большом количестве клиентов создаёт много повторяющихся запросов и лишнего трафика. Long polling заметно сокращает число пустых ответов, однако сохраняет зависимость от постоянного открытия новых HTTP-запросов. WebSocket лучше всего соответствует непрерывной передаче телеметрии и масштабированию на большое число операторских мест.
Для небольшой системы с редкими обновлениями может быть достаточно short polling. Long polling подходит как промежуточное решение, когда постоянные соединения использовать сложно. Но для полноценного мониторинга с частыми изменениями тегов оптимальным выбором обычно становится WebSocket - при условии, что в приложении реализованы контроль подключений, восстановление связи и защита от перегрузки. Именно такой подход чаще всего оказывается наиболее эффективным для SCADA система мониторинга в реальном времени.
