ukip протокол что это
Протокол QUIC: переход Web от TCP к UDP
Протокол QUIC (название расшифровывается как Quick UDP Internet Connections) — совершенно новый способ передачи информации в интернете, построенный поверх протокола UDP, вместо общепринятого ранее использования TCP. Некоторые люди называют его (в шутку) TCP/2. Переход к UDP — наиболее интересная и мощная особенность протокола, из которой следуют некоторые другие особенности.
Сегодняшний Web построен на протоколе TCP, который был выбран за его надёжность и гарантированность доставки пакетов. Для открытия TCP-соединения используется так называемое «трёхкратное рукопожатие». Это означает дополнительные циклы отправки-приёма сообщений для каждого нового соединения, что увеличивает задержки.
Если вы захотите установить защищённое TLS-соединение, придётся переслать ещё больше пакетов.
Некоторые инновации, вроде TCP Fast Open, улучшат некоторые аспекты ситуации, но эта технология пока не очень широко распространена.
Протокол UDP, с другой стороны, построен на идее «отправить пакет и забыть о нём». Сообщение, отправленное по UDP, будет доставлено получателю (не гарантированно, с некоторой вероятностью успеха). Яркое преимущество здесь в меньшем времени установки соединения, такой же яркий недостаток — негарантированность доставки или порядка прихода пакетов получателю. Это означает, что для обеспечения надёжности придётся построить некоторый механизм поверх UDP, который гарантирует доставку пакетов.
И здесь на сцену выходит QUIC от Google.
Протокол QUIC может открыть соединение и согласовать все параметры TLS (HTTPs) за 1 или 2 пакета (1 или 2 — зависит от того, открывается ли соединение к новому серверу или к уже знакомому).
Это невероятно ускоряет открытие соединения и начало загрузки данных.
Зачем нужен QUIC?
Планы команды разработчиков протокола QUIC выглядят очень амбициозно: протокол попытается совместить скорость UDP с надёжностью TCP.
Вот что об этом пишет Википедия:
Улучшение протокола TCP является долговременной целью для Google, а протокол QUIC создан как эквивалент независимого TCP-соединения, но с уменьшенными задержками и улучшенной в духе SPDY поддержкой мультиплексирования. Если QUIC покажет свою эффективность, то эти возможности могут войти в следующую версию протоколов TCP и TLS (разработка которых занимает больше времени).
В этой цитате есть важный момент: если QUIC докажет свою эффективность, то есть шанс, что опробованные в нём идеи станут частью следующей версии TCP.
Протокол TCP достаточно сильно формализован. Его реализации есть в ядрах Windows и Linux, в каждой мобильной OS, да и во многих более простых устройствах. Улучшение TCP является непростым делом, поскольку все эти реализации должны его поддерживать.
UDP же является относительно простым протоколом. Значительно быстрее разработать новый протокол поверх UDP чтобы иметь возможность проверить теоретические идеи, работу в перегруженных сетях, обработку заблокированных потерянным пакетом потоков и т.д. Как только эти моменты будут прояснены — можно будет начинать работу по переносу лучших частей QUIC в следующую версию TCP.
Где же сегодня место QUIC?
Если вы посмотрите на уровни, составляющие современное HTTPs-соединение, то увидите, что QUIC заменяет собой весь TLS-стек и часть HTTP/2.
Да, протокол QUIC реализует собственный крипто-слой, что позволяет избежать использования TLS 1.2.
Поверх QUIC работает небольшая прослойка HTTP/2 API, используемая для общения с удалёнными серверами. Она меньше полной реализации HTTP/2, поскольку мультиплексирование и установка соединения уже реализованы в QUIC. Остаётся лишь реализация протокола HTTP.
Блокировка начала очереди (Head-of-line blocking)
Протоколы SPDY и HTTP/2 используют одно TCP-соединение с сервером вместо отдельных соединений для каждой страницы. Это единое соединение может быть использовано для независимых запросов и получения отдельных ресурсов.
Поскольку весь обмен данными теперь построен на одном TCP-соединении, мы автоматически получаем один недостаток: блокировку начала очереди (Head-of-line blocking). В протоколе TCP требуется, чтобы пакеты приходили (точнее обрабатывались) в правильном порядке. Если пакет потерялся на пути к\от сервера — он должен быть отослан повторно. TCP-соединение в это время должно ожидать (блокироваться) и лишь после повторного получения потерянного пакета продолжается обработка всех пакетов в очереди — только так можно соблюсти условие корректного порядка обработки пакетов.
Протокол QUIC решает эту проблему фундаментально — отказом от протокола TCP в пользу UDP, который не требует соблюдения порядка обработки принимаемых пакетов. И, хотя потери пакетов, конечно, всё так же возможны, это будет влиять только на обработку тех ресурсов (индивидуальных HTML\CSS\JS-файлов), к которым относится потерянный пакет.
QUIC очень элегантно комбинирует лучшие части SPDY\HTTP2 (мультиплексирование) с неблокируемым транспортным протоколом.
Почему уменьшить количество пересылаемых пакетов так важно
Если у вас быстрое Интернет-соединение, то задержки передачи пакетов между вашим компьютером и удалённым сервером составляют около 10-50 мс. Каждый пересылаемый от вас по сети пакет будет получен сервером через этот промежуток времени. Для такого порядка величин преимущества QUIC могут быть не очень понятны. Но стоит нам рассмотреть вопрос обмена данными с сервером на другом континенте или использования мобильных сетей — и вот у нас уже появляются задержки порядка 100-150 мс.
В итоге на мобильном устройстве, при доступе к находящемуся далеко серверу, разница между 4 пакетами TCP+TLS и одним пакетом QUIC может составить около 300 мс, что уже является существенной величиной, наблюдаемой невооруженным глазом.
Превентивная коррекция ошибок
Изящной фичей протокола QUIC является превентивная коррекция ошибок (Forward Error Correction, FEC). Каждый пересылаемый пакет содержит в себе некоторое количество данных других пакетов, что позволяет реконструировать любой потерянный пакет по данным в его соседях, без необходимости запрашивать переотправку потерянного пакета и дожидаться его содержимого. Это, по сути, реализация RAID 5 на сетевом уровне.
Но вы уже и сами видите недостаток этого решения: каждый пакет становится немного больше. Текущая реализация устанавливает этот оверхед равным 10%, т.е. сделав каждый пересылаемый пакет на 10% больше мы тем самым получаем возможность восстановления данных без перезапроса в случае, если будет теряться не более каждого десятого пакета.
Эта избыточность — плата пропускной способностью сети за уменьшение задержек (что выглядит логично, ведь скорости соединения и пропускная способность каналов непрерывно растут, а вот тот факт, что передача данных на другой конец планеты занимает сотню миллисекунд — навряд ли удастся как-то изменить без фундаментального переворота в физике).
Возобновление сессии и параллельные загрузки
Ещё одной интересной особенностью использования протокола UDP является то, что вы больше не привязаны к IP сервера. В протоколе TCP соединение определяется четырьмя параметрам: IP-адресами сервера и клиента, портами сервера и клиента. В Linux вы можете увидеть эти параметры для каждого установленного соединения с помощью комманды netstat:
Если любой из этих четырёх параметров потребуется изменить — нам потребуется открывать новое TCP-соединение. Вот почему трудно поддерживать стабильную связь на мобильных устройствах при переключении между WiFi и 3G/LTE.
В QUIC, с его использованием UDP, данного набора параметров больше нет. QUIC вводит понятие идентификатора соединения, называемого Connection UUID. Появляется возможность перейти с WiFi на LTE с сохранением Connection UUID, таким образом избежав затрат на пересоздание соединения. Похожим образом работает Mosh Shell, сохраняя SSH-соединение активным при смене IP-адреса.
Также данный подход открывает двери возможности использования нескольких источников для запроса контента. Если Connection UUID может быть использовано для перехода от WiFi к мобильной сети, то мы можем, теоретически, использовать и их обе одновременно для получения данных параллельно. Больше каналов связи — больше пропускная способность.
Практические реализации QUIC
Браузер Chrome имеет экспериментальную поддержку QUIC с 2014-го года. Если вы хотите потестировать QUIC, то можете включить его поддержку в Chrome и попробовать поработать с сервисами Google, которые его поддерживают. Это сильное преимущество Google — возможность использовать комбинацию своего браузера и своих же веб-ресурсов. Включив QUIC в самом популяром в мире браузере (Chrome) и высоконагруженных сайтах (Youtube.com, Google.com), они смогут получить большую, наглядную статистику использования протокола, что позволит выявить все существенные проблемы практического использования QUIC.
Есть плагин для Chrome, который показывает в виде иконки поддержку сервером протоколов HTTP/2 и QUIC.
Вы также можете увидеть открытые QUIC-соединения открыв вкладку chrome://net-internals/#quic прямо сейчас (обратите внимание в таблице на параметр Connection UUID, упомянутый ранее)
Вы можете пойти ещё дальше и посмотреть все открытые соединения и все переданные по ним пакеты: chrome://net-internals/#events&q=type:QUIC_SESSION%20is:active.
Как при этом всём работают файрволы?
Если вы — сисадмин или сетевой инженер, то, возможно, слегка дёрнулись, когда услышали о том, что QUIC использует UDP вместо TCP. Да, наверное, у вас есть на то свои причины. Возможно у вас (как, например, и у нас в компании), настройки доступа к веб-серверу выглядят как-то так:
Самое главное здесь, конечно же, столбик протокола, в котором явно написано «TCP». Подобные настройки используются тысячами веб-серверов по всему миру, поскольку они разумны. 80 и 443 порты, только TCP — и больше ничего на продакшн-вебсервере разрешено быть не должно. Никакого UDP.
Ну, если мы хотим использовать QUIC, придётся добавить и разрешение UDP-соединений на 443-ий порт. В больших энтерпрайз-сетях это может быть проблемой. Как показывает статистика Google, UDP кое-где блокируется:
Эти цифры были получены в ходе недавнего исследования в Швеции. Отметим несколько ключевых моментов:
Использование QUIC на серверной стороне
На данный момент QUIC поддерживается вебсервером Caddy (с версии 0.9). И клиентская, и серверная реализация QUIC ещё на стадии экспериментальной поддержки, так что будьте осторожны с практическим применением QUIC. Поскольку ни у кого по-умолчанию не включен QUIC, то, вероятно, будет безопасным включить его на своём сервере и экспериментировать со своим браузером (Обновление: с версии 52 QUIC включён по-умолчанию в Chrome).
Производительность QUIC
В 2015-ом году Google опубликовала некоторые результаты замеров производительности QUIC.
Как и ожидалось, QUIC затмевает классический TCP на плохих каналах связи, давая выигрыш в полсекунды на загрузке стартовой страницы www.google.com на 1% наиболее медленных соединений. Этот выигрыш ещё более заметен на видеосервисах вроде YouTube. Пользователи на 30% меньше жаловались на задержки из-за буферизации при просмотре видео при использовании QUIC.
Статистика Youtube особенно интересна. Если улучшения подобного масштаба действительно возможны, то мы увидим очень быструю адаптацию QUIC как-минимум в сфере видеосервисов вроде Vimeo, а также на рынке «видео для взрослых».
Выводы
Лично я нахожу протокол QUIC совершенно очаровательным! Огромный объём работы, проделанный его разработчиками, не пропал даром — один лишь факт того, что уже сегодня крупнейшие сайты в Интернете поддерживают QUIC, немного ошеломляет. Я жду не дождусь финальной спецификации QUIC, ну и дальнейшей её реализации всеми браузерами и веб-серверами.
Комментарий к статье от Jim Roskind, одного из разработчиков QUIC
Я потратил много лет на исследования, дизайн и разработку реализации протокола QUIC, и хотел бы добавить к статье кое-какие свои мысли. В тексте был верно подмечен момент о вероятной недоступности протокола QUIC у некоторых пользователей из-за строгих корпоративных политик в отношении протокола UDP. Это и было причиной того, что мы получили среднюю доступность протокола на уровне в 93%.
Если мы вернёмся немного в прошлое, то увидим что ещё совсем недавно корпоративные системы часто запрещали даже исходящий трафик к 80-му порту, с аргументацией «это уменьшит количество времени, которое работники тратят на серфинг в ущерб работе». Позже, как вы знаете, преимущества доступа к веб-сайтам (в том числе в производственных целях) вынудило большинство корпораций пересмотреть свои правила, разрешив выход в интернет с рабочего места рядового сотрудника. Я ожидаю чего-то аналогичного и с протоколом QUIC: как-только станет понятно, что с новым протоколом связь может быть быстрее, задачи выполняются оперативнее — он пробьёт себе путь и в энтерпрайз.
Я рассчитываю, что QUIC массово заместит собой TCP, и это даже помимо того, что он подарит следующей версии TCP ряд своих идей. Дело в том, что TCP реализуется в ядрах операционных систем, в железе, а значит адаптация к новой версии может занять 5-15 лет, в то время как внедрить QUIC поверх общедоступного и всеми поддерживаемого UDP можно в отдельно взятом продукте\сервисе буквально за несколько недель или месяцев.
Глоссарий
ICAP-сервер
Сервер, реализующий ICAP-протокол. Этот протокол позволяет фильтровать и изменять данные HTTP-запросов и HTTP-ответов. Например, производить антивирусную проверку данных, блокировать спам, запрещать доступ к персональным ресурсам. В качестве ICAP-клиента обычно выступает прокси-сервер, который взаимодействует с ICAP-сервером по ICAP-протоколу. Kaspersky Web Traffic Security получает данные с прокси-сервера организации, выступая в роли ICAP-сервера.
Kaspersky Private Security Network
Решение, позволяющее пользователям антивирусных программ «Лаборатории Касперского» получать доступ к данным Kaspersky Security Network, не отправляя информацию на серверы Kaspersky Security Network «Лаборатории Касперского» со своей стороны.
Kaspersky Security Network (KSN)
Инфраструктура облачных служб, предоставляющая доступ к оперативной базе знаний «Лаборатории Касперского» о репутации файлов, веб-ресурсов и программного обеспечения. Использование данных Kaspersky Security Network обеспечивает более высокую скорость реакции программ «Лаборатории Касперского» на угрозы, повышает эффективность работы некоторых компонентов защиты, а также снижает вероятность ложных срабатываний.
Kerberos-аутентификация
Механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, позволяющий передавать данные через незащищенные сети. Механизм основан на использовании билета (ticket), который выдается пользователю доверенным центром аутентификации.
Keytab-файл
Файл, содержащий пары уникальных имен (principals) для клиентов, которым разрешается Kerberos-аутентификация, и зашифрованные ключи, полученные из пароля Kerberos. Keytab-файлы используются в удаленных системах, поддерживающих Kerberos, для аутентификации пользователей без ввода пароля.
Lightweight Directory Access Protocol – облегченный клиент-серверный протокол доступа к службам каталогов.
MIB (Management Information Base)
Виртуальная база данных, используемая для управления объектами, которые передаются по протоколу SNMP.
NTLM-аутентификация
Механизм аутентификации, основанный на проверке подлинности запроса сервера и ответа клиента. Для шифрования запроса и ответа используются хеши пароля пользователя, которые передаются по сети. При захвате сетевого трафика злоумышленники могут получить доступ к хешам пароля, что делает этот механизм менее надежным, чем Kerberos-аутентификация.
PTR-запись
DNS-запись, связывающая IP-адрес компьютера с его доменным именем.
Replay cache
Кеш, используемый в технологии Kerberos для хранения записей о запросах пользователей на аутентификацию. Этот механизм помогает защитить инфраструктуру от атак повторного воспроизведения. Во время таких атак злоумышленники записывают трафик пользователя, чтобы воспроизвести ранее отправленные им сообщения и успешно пройти аутентификацию на прокси-сервере. При использовании replay cache сервер аутентификации обнаруживает дубликат запроса и отправляет в ответ сообщение об ошибке.
SELinux (Security-Enhanced Linux)
Система контроля доступа процессов к ресурсам операционной системы, основанная на применении политик безопасности.
SNI (Server Name Indication)
Расширение протокола TLS, передающее имя веб-сайта, с которым требуется установить соединение. SNI необходим в случаях, когда несколько сервисов, работающих по протоколу HTTPS, расположены на одном физическом сервере и используют один IP-адрес, но при этом у каждого сервиса есть свой сертификат безопасности.
SNMP-агент
Программный модуль сетевого управления Kaspersky Web Traffic Security, отслеживает информацию о работе программы.
SNMP-ловушка
Уведомление о событиях работы программы, отправляемое SNMP-агентом.
Squid
Программный пакет, выполняющий функцию кеширующего прокси-сервера для протоколов HTTP(S) и FTP. Сервис Squid использует списки контроля доступа для распределения доступа к ресурсам.
SRV-запись
Стандарт в DNS, определяющий местоположение, то есть имя хоста и номер порта серверов для определенных служб.
SSL Bumping
Режим работы сервиса Squid, используемый для перехвата содержимого зашифрованных HTTPS-сеансов.
Syslog
Стандарт отправки и записи сообщений о происходящих в системе событиях, используемый на платформах UNIX™ и GNU/Linux.
TLS-шифрование
Шифрование соединения между двумя серверами, обеспечивающее защищенную передачу данных между серверами сети Интернет.
Базовая аутентификация
Механизм аутентификации, при котором имя пользователя и пароль передаются для проверки на сервер в незашифрованном виде.
Вирус
Программа, которая заражает другие программы – добавляет в них свой код, чтобы получить управление при запуске зараженных файлов. Это простое определение дает возможность выявить основное действие, выполняемое вирусом – заражение.
Вредоносные ссылки
Веб-адреса, которые ведут на вредоносные ресурсы, то есть ресурсы, занимающиеся распространением вредоносного программного обеспечения.
Имя субъекта-службы (SPN)
Уникальный идентификатор службы в сети для проверки подлинности по протоколу Kerberos.
Источник обновлений
Ресурс, содержащий обновления антивирусных баз программы Kaspersky Web Traffic Security. Источником обновлений антивирусных баз могут служить серверы обновлений «Лаборатории Касперского», а также HTTP-, FTP-сервер, локальная или сетевая папка.
Кластер
Группа серверов с установленной программой Kaspersky Web Traffic Security, объединенных для централизованного управления через веб-интерфейс программы.
Нормализация
Процесс, в результате которого текстовое представление адреса веб-ресурса изменяется по определенными правилами (например, исключение из текстового представления адреса веб-ресурса имени пользователя, пароля и порта соединения, понижение верхнего регистра символов адреса веб-ресурса до нижнего регистра).
Отпечаток сертификата
Информация, по которой можно проверить подлинность сертификата сервера. Отпечаток создается путем применения криптографической хеш-функции к содержанию сертификата сервера.
Подчиненный узел
Компонент программы, который проверяет сетевой трафик пользователей согласно правилам обработки трафика. Подчиненный узел получает заданные администратором параметры от Управляющего узла.
Правило доступа
Список разрешений и запретов доступа пользователей к указанным веб-ресурсам и направлению трафика.
Правило защиты
Список проверок трафика на вирусы, фишинг, некоторые легальные программы, которые могут быть использованы злоумышленниками, и другие программы, представляющие угрозу, проводимых при выполнении заданных условий.
Вид интернет-мошенничества, целью которого является получение неправомерного доступа к конфиденциальным данным пользователей.
Программа, которая заражает другие программы – добавляет в них свой код, чтобы получить управление при запуске зараженных файлов. Это простое определение дает возможность выявить основное действие, выполняемое вирусом – заражение.
Правило обработки трафика
Набор действий, которые программа выполняет над веб-ресурсом, удовлетворяющим заданным условиям.
Правило обхода
Набор критериев фильтрации трафика, согласно которым пользователям разрешается или запрещается доступ к веб-ресурсам без выполнения проверок по правилам доступа и правилам защиты.
Рабочая область
Набор параметров и прав доступа, применимых к выделенной группе пользователей.
Репутационная фильтрация
Облачная служба, использующая технологии определения репутации сообщений. Информация о появлении новых видов спама в облачной службе появляется раньше, чем в базах модуля Анти-Спам, что дает возможность повысить скорость и точность обнаружения признаков спама в сообщении.
Сервис nginx
Программное обеспечение для UNIX-систем, используемое в качестве HTTP-сервера или почтового прокси-сервера.
Серийный номер лицензии
Уникальное сочетание букв и цифр, использующееся для однозначной идентификации приобретателя лицензии на программу.
Служба каталогов
Программный комплекс, позволяющий хранить в одном месте информацию о сетевых ресурсах (например, о пользователях) и обеспечивающий централизованное управление ими.
Схема расположения графиков
Трассировка
Запись отладочной информации о работе программы.
Управляющий узел
Компонент программы, который позволяет администратору управлять параметрами программы через веб-интерфейс. Управляющий сервер следит за состоянием обрабатывающих серверов, передает им заданные параметры и установленные лицензионные ключи.
Фишинг
Вид интернет-мошенничества, целью которого является получение неправомерного доступа к конфиденциальным данным пользователей.
Эвристический анализ
Технология обнаружения угроз, которые невозможно определить с помощью текущей версии баз программ «Лаборатории Касперского». Позволяет находить файлы, которые могут содержать неизвестный вирус или новую модификацию известного вируса.
Обзор сетевых протоколов и протоколов обмена сообщениями для IoT
Привет, хабровчане! Первый в России онлайн-курс IoT-разработчик стартует в OTUS уже в октябре. Прямо сейчас открыт набор на курс, в связи с чем мы продолжаем делиться с вами полезными материалами.
Интернет вещей (IoT, Internet of Things) будет построен на базе существующей сетевой инфраструктуры, технологий и протоколов, используемых в настоящее время в домах/офисах и в Интернете, и предложит много другого.
Цель данного руководства — дать краткий обзор сетевых и прикладных протоколов для IoT.
Примечание. У вас должны быть знания основ сетевых технологий.
IoT-сети
IoT будет работать в существующих TCP/IP-сетях.
TCP/IP использует четырехуровневую модель с определенными протоколами на каждом уровне. См. understanding the TCP/IP 4 layer model (разбираемся с четырехуровневой моделью TCP/IP).
На диаграмме ниже показано сравнение протоколов, используемых в настоящее время, и тех что, скорее всего, будут использоваться для IoT.
Примечания к диаграмме:
Размер шрифта отображает степень популярности протокола. Например, слева IPv4 больше, так как он гораздо популярнее в современном Интернете. Однако справа он меньше, поскольку ожидается, что IPv6 будет более популярным в IoT.
Показаны не все протоколы.
Больше всего изменений на канальном (уровни 1 и 2) и прикладном уровнях (уровень 4).
Сетевой и транспортный уровни, скорее всего, останутся неизменными.
Протоколы канального уровня
На канальном уровне (Data Link) вам нужно соединить устройства между собой. Они могут находиться как недалеко, например, в локальных сетях (local networks) так и на большом расстоянии друг от друга: в городских (metropolitan area networks) и глобальных сетях (wide area networks).
В настоящее время на этом уровне в домашних и офисных сетях (LAN) используются Ethernet и Wi-Fi, а в мобильных (WAN) — 3G / 4G. Однако многие IoT-устройства маломощные, например, датчики, и питаются только от батарей. В этих случаях Ethernet не подходит, но можно использовать low powered Wi-Fi и low powered Bluetooth.
Хотя для подключения этих устройств по-прежнему будут использоваться существующие беспроводные технологии (Wi-Fi, Bluetooth, 3G / 4G), стоит также обратить внимание на новые технологии, специально разработанные для IoT-приложений, популярность которых, по всей вероятности, будет расти.
BLE – Bluetooth Low Energy
LoRaWAN – Long Range WAN
Более подробно они описаны в статье An overview of IOT wireless technologies (обзор беспроводных технологий IoT).
Сетевой уровень
На сетевом уровне (Networking) в долгосрочной перспективе будет доминировать протокол IPv6. Маловероятно, что будет использоваться IPv4, но он может играть определенную роль на начальных этапах. Большинство IoT-устройств для дома, например, умные лампочки, в настоящее время используют IPv4.
Транспортный уровень
На транспортном уровне (Transport) в Интернете и вебе доминирует TCP. Он используется как в HTTP, так и во многих других популярных протоколах Интернета (SMTP, POP3, IMAP4 и т. д.).
MQTT, который, как я ожидаю, станет одним из основных протоколов прикладного уровня для обмена сообщениями, в настоящее время использует TCP.
Прикладной уровень и протоколы обмена сообщениями
Важные характеристики для протоколов IoT:
Скорость — количество передаваемых данных в секунду.
Задержка — время, необходимое для передачи сообщения.
Наличие программных средств.
В настоящее время на этом уровне активно используются два основных протокола: HTTP и MQTT.
HTTP, вероятно, самый известный протокол этого уровня, лежащий в основе веба (WWW). Он по прежнему будет иметь важное значение для IoT, поскольку используется для REST API — основного механизма взаимодействия веб-приложений и сервисов. Однако, из-за высоких накладных расходов, HTTP вряд ли станет основным протоколом IoT, хотя все равно будет широко использоваться в Интернете.
MQTT (Message Queuing Telemetry Transport) стал основным протоколом обмена сообщениями в IoT, благодаря своей легкости и простоте в использовании. См. статью Introduction to MQTT for beginners (Введение в MQTT для начинающих).
Сравнение HTTP и MQTT для IoT
MQTT быстро становится стандартом де-факто для IoT-приложений. Это происходит из-за его легкости и скорости по сравнению с HTTP и того, что он является протоколом «один ко многим», а не «один к одному» (HTTP).
Многие современные веб-приложения, с радостью использовали бы MQTT вместо HTTP, если бы он был доступен на момент их разработки.
Хороший пример — отправка информации множеству клиентов, например, о прибытии и отправлении поездов / автобусов / самолетов. В этом сценарии протокол «один-к-одному», такой как HTTP, имеет большие накладные расходы и создает большую нагрузку на веб-серверы. Масштабирование этих веб-серверов может быть затруднено. С MQTT клиенты подключаются к брокеру, которые легко можно добавлять для балансировки нагрузки. Смотрите об этом туториал с видео Republish HTML Data Over MQTT (Flight Arrivals Example) и статью MQTT vs HTTP for IOT.
Другие протоколы обмена сообщениями
HTTP не был разработан для IoT-приложений, но, как уже упоминалось, он будет широко использоваться в течение какого-то времени благодаря его широкому использованию в API.
Почти все платформы IoT поддерживают как HTTP, так и MQTT.
Однако есть и другие протоколы, которые стоит рассмотреть.
MQTT — (Message Queuing Telemetry Transport). Использует TCP/IP. Для модели «издатель-подписчик» требуется брокер сообщений.
AMQP — (Advanced Message Queuing Protocol). Использует TCP/IP. Модели «издатель-подписчик» и «точка-точка».
COAP — (Constrained Application Protocol). Использует UDP. Разработан специально для IoT, использует модель запроса-ответа как в HTTP. RFC 7252.
DDS — (Data Distribution Service)
В этой статье рассматриваются основные протоколы и их применения. Вывод этой статьи заключается в том, что IoT будет использовать набор протоколов, в зависимости от их предполагаемого применения.
Однако, если оглянуться назад, в первые годы существования Интернета протокол HTTP, впоследствии ставший доминирующим, был всего лишь одним из множества протоколов.
Несмотря на то что HTTP не был изначально задуман для передачи файлов и электронной почты, сегодня он используется и для того и для другого.
Я ожидаю, что в IoT с протоколами обмена сообщениями произойдет то же самое: большинство сервисов будут использовать один преобладающий протокол.
Ниже приведены графики Google Trends, показывающие, как изменялась популярность MQTT, COAP и AMQP за последние несколько лет.
Обзор Google Trends
Поддержка протоколов по платформам
AWS — MQTT, HTTPS, MQTT over websockets
IBM Bluemix – MQTT,HTTPS,MQTT
Резюме
Больше всего изменений на канальном (уровни 1 и 2) и прикладном уровнях (уровень 4).
Сетевой и транспортный уровни, скорее всего, останутся неизменными.
На прикладном уровне компоненты IoT будут использовать протоколы обмена сообщениями. Хотя мы все еще находимся на раннем этапе развития IoT, вполне вероятно, что выделится один или, возможно, два протокола обмена сообщениями.
За последние несколько лет MQTT стал самым популярным, и именно на нем я сейчас фокусируюсь на этом сайте.
HTTP также по-прежнему будет использоваться, так как он уже хорошо встроен в существующие IoT-платформы.
На этом все. Приглашаем вас записаться на бесплатный демо урок по теме «Чат-бот для быстрых команд устройству».