Интернет вещей (IoT): что это и как он устроен

В компьютерную сеть объединяются не только компьютеры. Смартфоны, планшеты, смарт-телевизоры, роботы-пылесосы, лампы, счетчики и датчики тоже подключаются к сети и обмениваются данными. Поэтому в школьном тесте «выберите все верные утверждения» верны два: «компьютерная сеть может объединять различные устройства: смартфоны, планшеты, умный дом, роботов-пылесосов» и «компьютерные сети предоставляют возможность для быстрого поиска информации». Неверны тоже два: сети не замедляют, а ускоряют обмен информацией, и объединяются в них не только компьютеры.

Интернет вещей (Internet of Things, IoT) — это сеть физических устройств со встроенной электроникой (датчиками, исполнительными механизмами, микроконтроллером и модулем связи), которые без участия человека передают данные и получают команды через сеть. Ниже разберем, из чего состоит такая система, какими протоколами «вещи» общаются, чем IoT отличается от IIoT и где в нем главные риски.

Мини-словарь: что с чем не путать

Упрощенно: M2M — про связь машин между собой, IoT — про то, что таких устройств много, они подключены к общей инфраструктуре (обычно интернету и облаку) и их данные используются приложениями. Граница размыта, и в текстах термины часто смешивают.

Как устроена IoT-система

Типичную архитектуру удобно описывать слоями. Это учебная схема: в реальных проектах слои могут объединяться (например, умная лампа с Wi-Fi подключается к облаку напрямую, без шлюза).

Пройдем путь одного показания. Датчик на кухне измерил 31 °C. Микроконтроллер упаковал значение в сообщение и отправил по Wi-Fi на брокер. Правило на платформе увидело превышение порога и отправило команду «включить» кондиционеру. Параллельно значение попало в хранилище, и в приложении обновился график.

Не все решения принимаются в облаке. Если реакция нужна за миллисекунды или связь ненадежна, логику переносят ближе к устройству — на шлюз или в сам микроконтроллер. Это называют граничными вычислениями (edge computing).

Протоколы: как «вещи» передают данные

Протоколы связи (Wi-Fi, Zigbee, LoRaWAN) отвечают за то, как биты доходят до соседнего узла. Протоколы прикладного уровня отвечают за то, в каком виде устройство и сервер обмениваются сообщениями. Для IoT чаще всего упоминают два.

Выбор зависит от задачи. Если устройства держат постоянное соединение и шлют показания на сервер — обычно берут MQTT. Если устройство спит на батарейке в сети с потерями, а к нему обращаются как к ресурсу по адресу — смотрят на CoAP. HTTP тоже используется, особенно когда устройство мощное и отправляет данные редко.

MQTT на практике: топики и подписки

В MQTT устройство публикует сообщение в топик — строку с уровнями через /, например home/kitchen/temperature. Подписчик указывает фильтр, где можно использовать два подстановочных знака: + заменяет ровно один уровень, # — любое число уровней до конца и ставится только последним. Брокер сам решает, кому доставить сообщение.

Ниже — модель этого правила сопоставления на Python без сторонних библиотек. Настоящий брокер (например, Mosquitto) делает это внутри, но логика та же.

def topic_matches(topic_filter: str, topic: str) -> bool:
    """Проверяет, подходит ли топик под фильтр подписки MQTT (+ и #)."""
    f_levels = topic_filter.split("/")
    t_levels = topic.split("/")
    # Топики на $ (например, $SYS) не ловятся фильтрами, начинающимися с + или #
    if topic.startswith("$") and f_levels[0] in ("+", "#"):
        return False
    for i, f in enumerate(f_levels):
        if f == "#":
            return i == len(f_levels) - 1  # # допустим только последним уровнем
        if i >= len(t_levels):
            return False
        if f != "+" and f != t_levels[i]:
            return False
    return len(f_levels) == len(t_levels)


messages = [
    "home/kitchen/temperature",
    "home/kitchen/humidity",
    "home/bedroom/temperature",
    "home/bedroom/lamp/set",
    "$SYS/broker/uptime",
]
filters = ["home/+/temperature", "home/kitchen/#", "#"]

for flt in filters:
    got = [m for m in messages if topic_matches(flt, m)]
    print(f"{flt:20} -> {got}")

Вывод в Python 3.14:

home/+/temperature   -> ['home/kitchen/temperature', 'home/bedroom/temperature']
home/kitchen/#       -> ['home/kitchen/temperature', 'home/kitchen/humidity']
#                    -> ['home/kitchen/temperature', 'home/kitchen/humidity', 'home/bedroom/temperature', 'home/bedroom/lamp/set']

Что здесь видно. Фильтр home/+/temperature собирает температуру из всех комнат, но не влажность. Фильтр home/kitchen/# берет все с кухни. Даже # не получает служебный топик $SYS/broker/uptime: такие топики брокер отдает только по явной подписке на $SYS/....

Типичная ошибка — поставить # в середину фильтра.

print(topic_matches("home/#/temperature", "home/kitchen/temperature"))  # False
print(topic_matches("home/+/temperature", "home/kitchen/temperature"))  # True

Наша функция возвращает False, а настоящий брокер такой фильтр вообще отклонит как некорректный. Исправление — заменить # на +, если нужен ровно один уровень. Еще одна тонкость: home/kitchen/# совпадает и с самим home/kitchen (функция вернет True), это прописано в спецификации.

Безопасность IoT: где главные риски

Устройств много, они годами работают без присмотра, у них слабое железо и редкие обновления. Поэтому IoT — частая цель атак. Известный пример — ботнет Mirai (2016): он заражал камеры и роутеры, перебирая заводские логины и пароли, и использовал их для DDoS-атак.

Базовые требования к IoT-системе:

• Никаких общих заводских паролей. У каждого устройства — свои учетные данные или клиентский сертификат.
• Шифрование канала. MQTT — через TLS (порт 8883), CoAP — через DTLS. При этом нужно проверять сертификат сервера: шифрование без проверки не защищает от подмены брокера.
• Права на топики (ACL). Устройство публикует только в свою ветку и не может отправлять команды чужим устройствам.
• Подписанные обновления прошивки. Устройство принимает только прошивку, подписанную производителем, иначе канал обновления становится каналом заражения.
• Сегментация сети. Умные устройства — в отдельной сети или VLAN, без прямого доступа к рабочим компьютерам.

Как ACL выглядит в логике брокера, можно показать на той же функции:

ACL = {
    "sensor-kitchen": ["home/kitchen/#"],
    "lamp-bedroom": ["home/bedroom/lamp/state"],
}

def can_publish(client_id: str, topic: str) -> bool:
    return any(topic_matches(f, topic) for f in ACL.get(client_id, []))

print(can_publish("sensor-kitchen", "home/kitchen/temperature"))  # True
print(can_publish("sensor-kitchen", "home/bedroom/lamp/set"))     # False
print(can_publish("unknown-device", "home/kitchen/temperature"))  # False

Датчик кухни может писать показания, но не может включить лампу в спальне, а неизвестный клиент не может ничего. Это учебная модель: в реальном брокере ACL задается его конфигурацией или плагином авторизации и работает только вместе с аутентификацией клиента. Сам по себе список прав не спасает, если логин и пароль устройства утекли.

IoT и IIoT: в чем разница

Для умного дома важен стандарт Matter: его развивает альянс CSA, чтобы устройства разных производителей работали в одной системе. Это ответ на давнюю проблему несовместимости экосистем.

Где применяется интернет вещей

• Дом: освещение, розетки, замки, датчики протечки и дыма, роботы-пылесосы, голосовые колонки как центр управления.
• Здоровье: фитнес-браслеты и часы, домашние медицинские приборы, передающие показатели врачу.
• Город и ЖКХ: счетчики с удаленной передачей показаний, управление уличным освещением, датчики заполненности контейнеров.
• Промышленность: предиктивное обслуживание оборудования по вибрации и температуре, контроль микроклимата на складе.
• Логистика и транспорт: трекеры грузов, телематика автопарка, датчики температуры в рефрижераторах.
• Сельское хозяйство: датчики влажности почвы и автоматический полив.

Эффект во всех случаях зависит от того, что делают с данными. Датчик сам по себе ничего не экономит: польза появляется, когда есть правило, аналитика или человек, который реагирует на сигнал.

Выводы

• В сеть объединяются не только компьютеры: смартфоны, телевизоры, пылесосы, датчики и счетчики тоже сетевые устройства, и это основа интернета вещей.
• IoT-система состоит из слоев: устройства, связь, шлюз или edge, платформа, приложения; в простых решениях слои могут совмещаться.
• MQTT (публикация — подписка через брокер, TCP) и CoAP (запрос — ответ, UDP) — два самых распространенных прикладных протокола IoT.
• IIoT отличается от бытового IoT ценой ошибки, сроком службы и протоколами.
• Главные риски — заводские пароли, незашифрованные каналы, широкие права устройств и неподписанные обновления.

Где применяется / связь с практикой

FAQ

Является ли смартфон устройством интернета вещей?
Смартфон — сетевое устройство, но обычно его относят не к «вещам», а к интерфейсу управления ими. Он часто выступает шлюзом: например, связывается с браслетом по Bluetooth и передает данные в облако.

Нужен ли интернет для работы IoT-устройств?
Не всегда. Многие системы работают в локальной сети через хаб или шлюз, а интернет нужен только для удаленного доступа и облачных функций. При отключении интернета часть сценариев умного дома продолжает работать, если логика выполняется локально.

Какой язык программирования нужен для IoT?
Для прошивок микроконтроллеров чаще всего используют C и C++, иногда MicroPython. Для серверной части и аналитики — Python, Go, Java и другие языки бэкенда.