Разбираем три расследования — пропавшую запись в базе, три процента сообщений, терявшихся только на чистой машине, и гонки в биллинге, которые видит одна поддержка. У всех трёх разные предметные области и одна общая методика поиска невоспроизводимых багов.

Отсутствие закономерности само по себе является находкой: если сбой не привязан ни к шарду, ни к клиенту, ни к времени суток, это указывает на гонку, а не на данные.

Когда воспроизвести дефект синтетически нельзя, остаётся пассивная телеметрия в продакшене и последовательное отсечение гипотез данными.

Счётчики на каждом слое находят виновника быстрее логов: разрыв между двумя соседними числами прямо называет слой, в котором теряются сообщения.

Вежливый тест, который шлёт запрос и ждёт ответа, скрывает целый класс ошибок пакетирования. Пачечный тест их обнажает.

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

Случай первый: запись, которой не могло не быть

Управляющий слой Tailscale разбит на шарды, у каждого своя база SQLite, и обращается к ней ровно один процесс. Такой однописательный режим — именно то, для чего SQLite и предназначен, что делает дальнейшее особенно неприятным.

Резервное копирование снимало полную копию базы каждые несколько минут и складывало файл в объектное хранилище. Работало это без единого происшествия с начала 2023 года, пока конвейер, читавший резервные копии, не сообщил об ошибке. Проверка встроенной командой контроля целостности подтвердила худшее: база повреждена.

Первый случай сочли единичным. Базу починили, причину не нашли. Потом это повторилось. И ещё раз. Всего до устранения первопричины набралось 19 отдельных инцидентов за полгода, и каждый означал простой: процесс на шарде останавливался, пока базу чинили или восстанавливали. На ранних инцидентах простой превышал час, и всё это время у клиентов на шарде не работали консоль администратора и API.

Почему он не поддавался обычным приёмам

Дефект сопротивлялся всем стандартным подходам сразу:

• Не на что было списать: низкоуровневый код работы с базой никто не трогал годами, а внимательное чтение ничего не дало.
• Не нашлось общих факторов. Повреждения не привязывались ни к конкретному шарду, ни к клиенту, ни к функции продукта, ни ко времени суток, ни к уровню нагрузки.
• Он не воспроизводился синтетически. Надёжного триггера не было, поэтому оставалось только развернуть пассивную телеметрию в боевой среде и ждать следующего случая.

Расписания у инцидентов тоже не было: они случались то через часы, то через недели. Между октябрём и декабрём наступила шестинедельная тишина, после которой повреждения вернулись.

Команда сделала два шага, которые и составляют суть этой истории. Купила контракт поддержки у разработчиков SQLite, получив прямой доступ к людям, написавшим саму базу. И методично составила список гипотез, отсекая их данными, а не рассуждениями. В списке были сломанные блокировки при закрытии файла, неверная работа с памятью, принадлежащей базе, и обращение из нескольких потоков при отключённой потокобезопасности. Каждый инцидент приносил данные, каждая гипотеза отпадала по очереди.

Улика: транзакция, которой не стало

Пока первопричину искали, платформу надо было держать живой. Команда автоматизировала жёсткую остановку при обнаружении повреждения, поставила монитор, непрерывно проверявший целостность резервных копий, и переписала инструкции по восстановлению. Время восстановления упало ниже часа.

А затем построила конвейер журналирования транзакций. Идея простая: писать каждый изменяющий базу запрос в отдельный журнал. Поскольку писатель один, а транзакции сериализуемы, история изменений линейна и детерминирована, и её можно проиграть поверх последней заведомо целой копии, обойдя повреждённые страницы. Приём годится там, где порядок фиксаций известен: при единственном писателе он получается сам собой. Наивный журнал запросов на многописательной базе этого не даёт, потому что конкурентные транзакции переплетаются и без явного порядка фиксаций проигрывание не восстановит то же состояние.

Конвейер сработал и выдал улику. В двух инцидентах журналы не проигрывались чисто: данные, записанные и зафиксированные одной транзакцией, оказывались необъяснимо невидимы для последующих. Запись исчезла бесследно и без единой ошибки.

Этого не может быть. В сериализуемой однописательной базе зафиксированная запись не может пропасть. Значит, виноват слой с достаточной конкурентностью, чтобы такое спрятать, а такой слой ровно один — контрольные точки.

Шестнадцатилетняя гонка

SQLite с журналом предзаписи работает с двумя файлами. База — это набор страниц; при изменении данных новые страницы пишутся не в основной файл, а сначала в журнал. Позже контрольная точка переносит их в базу. Обычно момент переноса SQLite выбирает сам, но Tailscale управляла контрольными точками вручную, чтобы снимать быстрые согласованные копии. Именно этот нестандартный, хотя и полностью документированный выбор и вывел их на дефект.

Метрики во время инцидентов показывали, что SQLite сообщает о переносе большего числа страниц, чем в журнале вообще было. Разработчики базы как раз готовили инструмент для этого слоя: обёртку над виртуальной файловой системой, которая пишет дополнительные трассировочные журналы. Обёртку развернули в продакшене, и ждать пришлось недолго.

Журналы показали редкую гонку данных (race condition) между контрольной точкой и пишущей транзакцией. Если запись происходит в определённый момент работы контрольной точки, та сбивается: считает часть страниц перенесёнными в основной файл, хотя перенос не состоялся. Данные теряются навсегда, а страницы, которые на них ссылаются, например индексные, записываются как ни в чём не бывало. Файл становится структурно повреждённым, что проверка целостности всё это время и фиксировала.

Дефекту дали имя по сбросу журнала предзаписи и оценили его возраст минимум в шестнадцать лет. Он прожил так долго именно из-за редкости, это классический heisenbug: чтобы поймать его в тестовой среде, разработчикам пришлось дописать код, вызывающий гонку намеренно.

Ложная тревога, чуть не сорвавшая исправление

Исправление вышло в версии 3.52.0, и Tailscale раскатывала его осторожно, начав с нескольких канареечных шардов. После общей раскатки монитор резервных копий немедленно покраснел, сообщив о повреждении в тринадцати базах.

Настоящего повреждения не было. В ту же версию попала оптимизация, слегка изменившая округление при переводе текста в число с плавающей точкой, а Tailscale хранила метки времени высокой точности текстом и превращала их в числа в вычисляемом столбце. Индекс по вычисляемому выражению перестал соответствовать новому результату вычисления, и проверка целостности честно назвала это повреждением. Канареечные шарды дефект пропустили просто потому, что на них не оказалось меток времени, попадающих под изменённое округление.

Разбирали это с трёх сторон сразу. Разработчики SQLite отозвали версию целиком и выпустили 3.51.3, содержавшую только исправление гонки. Tailscale перешла на хранение меток времени целыми секундами, поскольку перевод текста в целое число однозначен. А в 3.53.0 появилось автоматическое восстановление таких индексов, чтобы проблема не возникала впредь.

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

Как доказали, что дефект действительно исправлен

Самая дисциплинированная часть расследования пришлась на финал. Отсутствие повреждений доказательством не считалось: команда уже пережила шесть недель обманчивой тишины. Поэтому драйвер базы пропатчили так, чтобы он выдавал предупреждение всякий раз, когда пишущая транзакция и сброс журнала пересекаются во времени.

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

Случай второй: три процента, терявшиеся только на чистой машине

Второй сюжет проще по масштабу и полезнее в быту. Сервис представлял собой небольшой пересыльщик TCP: принять соединение, читать текстовые строки, передавать дальше. На тестовом стенде входило 97 004 строки, а выходило 94 183. Ни ошибок, ни исключений, просто пропавшие сообщения.

На ноутбуке автора всё воспроизводилось идеально: сто тысяч строк на входе, сто тысяч на выходе. Это расхождение и было первой уликой — тест проверял не то, что делает продакшен.

Сменить машину раньше, чем код

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

Считать, а не логировать

Дальше нужен был не ещё один прогон, а способ понять, на каком слое теряются сообщения. Логи рассказывают истории, счётчики складываются. Автор расставил счётчик на каждом слое: клиент считает отправленные строки, сервер считает разобранные переводы строки, сервер считает отправленные ответы, клиент считает полученные ответы. Один прогон, четыре числа, и разрыв между соседними прямо называет виновный слой.

Сервер разобрал всё до последней строки, а ответов отправил меньше, чем разобрал. Это отпечаток пальца конкретного дефекта, и дальше оставалось найти его в коде ответа.

read() ничего не обещает про сообщения

Виновником оказалась одна строка: сервер отправлял по одному ответу на каждое чтение, а не на каждую разобранную строку.

TCP — это поток байтов, а не очередь сообщений. Вызов чтения не имеет понятия о том, что такое одно сообщение в вашем протоколе. Ядро вправе слить десяток сообщений в один сегмент, и одно чтение заберёт все десять, а ответ уйдёт один.

Вежливый локальный тест отправлял сообщение, дожидался подтверждения и отправлял следующее. Одно сообщение на сегмент — дефект спал. Нагрузка на стенде шла пачками, тысячами сообщений в секунду, ядро их группировало, одно чтение проглатывало сотню строк.

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

Вывод автора расследования:
Локальный тест это не нагрузочный тест, ноутбук это не сервер, а одно чтение из сокета это не одно сообщение.

Третий сюжет: гонки, которые видит только поддержка

Третий сюжет про биллинг кредитов на бессерверном Postgres, где транзакции по условиям задачи были недоступны. Автор наткнулся на четыре гонки, разберём две самые показательные. Все они, по его собственной формулировке, относятся к тому сорту дефектов, которые не показываются в тестах и показываются в почте поддержки.

Классический двойной расход

Наивная версия, которую пишут первой:

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

Инвариант переезжает в условие запроса

Общее решение — сделать проверку и запись одним оператором, перенеся условие корректности в WHERE:

Одиночный UPDATE в Postgres атомарен. Не хватило баланса — условие не совпало, вернулось ноль строк, и вы точно знаете, что списание не произошло. Транзакция для этого не нужна вовсе. Приём обобщается: перенесите инвариант в условие выборки, и запись просто не случится, когда инвариант нарушен.

Вебхук, доставленный дважды

Платёжные провайдеры повторяют доставку уведомлений при таймаутах, пятисотках и сетевых сбоях, а иногда дублируют событие и в штатном режиме. Если обработчик начисляет кредиты, доставка «хотя бы один раз» означает начисление хотя бы один раз.

Обычное решение с таблицей обработанных событий требует транзакции, а её нет: падение между двумя операторами либо начислит дважды при повторе, либо потеряет начисление совсем. Рабочий вариант в один оператор использует изменяющее данные обобщённое табличное выражение, где вставка в журнал операций работает воротами: не прошла вставка, значит, не выполнилось и обновление баланса.

Деталь, которую стоит забрать отдельно: уникальный индекс под эту схему должен быть частичным. Начисления от администратора приходят с произвольным идентификатором из скрипта, и глобальный уникальный индекс рисковал бы столкнуть их друг с другом или с идентификатором операции другого типа. Приветственные начисления идут вообще без идентификатора, и с ними коллизии не будет в любом случае: Postgres не считает два пустых значения равными. Ограничение индекса двумя типами операций от платёжного провайдера держит проверку уникальности ровно там, где она нужна.

Что из этого складывается

Первые два расследования дают общую методику поиска, и она изложена ниже. Третий случай стоит особняком: это не детектив, а набор приёмов, которые убирают целый класс гонок ещё на этапе проектирования, до того как искать станет нечего.

Что забрать с собой

Общего у трёх расследований больше, чем различий. Во всех трёх случаях проверка была написана в форме, которая не воспроизводит реальность: последовательный запрос вместо пачки, одиночный вызов вместо конкуренции, одна машина вместо двух. И во всех трёх дефект спокойно проходил через тесты, а в случае с SQLite прожил так шестнадцать лет.

Соседний сюжет про то, как тесты перестают отражать реальность, разбирали в материале о том, почему статичные моки убивают тестирование.

Полезнее всего здесь дешёвые привычки. Счётчик на границе каждого слоя ставится за час. Пачечный клиент пишется за вечер. Датчик, доказывающий исправление положительным сигналом, добавляется одной строкой в драйвер. Всё это стоит несопоставимо меньше, чем полгода расследования.

Три постмортема, на которых строится разбор: разбор Tailscale о поиске шестнадцатилетнего бага в SQLite, ретроспектива потери трёх процентов сообщений и четыре гонки в биллинге на бессерверном Postgres.

Возьмите самый подозрительный сервис и запустите по нему пачечный тест вместо последовательного. Это самый дешёвый способ узнать, какой из ваших дефектов сейчас спит.

На практике это netcat для интернета: на одной машине запускаете tailcat в режиме ожидания и получаете одноразовый адрес-токен, на другой вызываете tailcat с этим адресом, и между ними появляется шифрованный двунаправленный канал. Сверху можно пустить SSH, передачу файлов или проброс порта. Для разового доступа к машине за NAT это заменяет и промежуточный сервер, и регистрацию в чужом сервисе.

• tailcat — CLI и Go-пакет github.com/tailscale/tailcat под лицензией BSD-3-Clause.
• Использует WireGuard, NAT traversal и DERP-релеи Tailscale, но не control plane: аккаунты, вход и tailnet не нужны; IP-адреса внутри туннеля есть, но пользователю их знать не требуется.
• Адрес машины — её публичный ключ с информацией о DERP-сервере для первого контакта, закодированный в строку с префиксом tc.
• Сценарии: SSH на машину за NAT, передача файлов, временный доступ; есть экспериментальная браузерная демонстрация на WebAssembly.
• Прототип под названием derpcat написан в сентябре 2023 года; обещаний стабильности API и CLI у проекта нет.

Как соединение работает без сервера-посредника

В обычном Tailscale центральный сервер (control plane) раздаёт машинам ключи друг друга и координаты, по которым их искать. В tailcat этого посредника нет: всё, что нужно для соединения, упаковано в сам адрес. По описанию в блоге, это публичный ключ WireGuard плюс сведения о том, через какой DERP-релей к машине можно достучаться, если прямой путь через NAT не найдётся; строка начинается с tc и кодирует эти данные в base64. Получатель адреса знает и кому доверять, и где искать.

No accounts, login flow, tailnets, or IP addresses.

Дальше работает тот же механизм, что и в Tailscale: машины пытаются пробить NAT и соединиться напрямую, а если не выходит, трафик идёт через DERP-релей, зашифрованный концами так, что релей содержимого не видит. Релеи Tailscale публичные, и их можно заменить своим. Ни root, ни TUN-интерфейс, ни права администратора не нужны: tailcat работает в пространстве пользователя как обычная программа.

Чем это отличается от ngrok, SSH-туннелей и самого Tailscale

От ngrok и подобных сервисов tailcat отличается тем, что не выставляет ничего в публичный интернет: соединение получит только тот, у кого есть адрес, а адрес — это ключ. От SSH-прыжков через промежуточный сервер — тем, что промежуточный сервер не нужен вообще: DERP лишь помогает найти друг друга и при необходимости ретранслирует уже зашифрованные байты. От Tailscale — отсутствием всей управляющей части: нет списка устройств, ACL, MagicDNS, нет и постоянной сети, каждое соединение живёт само по себе.

Отсюда и границы применимости. tailcat хорош для разового доступа: подключиться к ноутбуку коллеги, забрать большой файл с домашней машины из офиса, дать подрядчику временный вход на стенд. Для постоянной сети между десятками серверов с правами доступа он не замена Tailscale или WireGuard-конфигу, и авторы этого не обещают: README прямо предупреждает, что инструмент бесплатный, но стабильность API и CLI не гарантируется.

Как попробовать

• Установка при наличии Go: go install github.com/tailscale/tailcat/cmd/tailcat@latest; готовые бинарники смотрите в релизах репозитория.
• На принимающей стороне запустите tailcat в режиме прослушивания и скопируйте выданный адрес; на второй машине передайте этот адрес как аргумент.
• Поверх канала поднимайте SSH или пробрасывайте порт; для передачи файлов подойдёт обычное перенаправление stdin и stdout, как с netcat.
• Для закрытого контура поднимите собственный DERP-сервер: код релея открыт в репозитории Tailscale.
• Браузерная демонстрация на WebAssembly лежит на GitHub Pages проекта и показывает, что канал можно открыть даже из вкладки.
• Публичные DERP-релеи даны без SLA, с ограничением частоты запросов и лишь в нескольких регионах; для рабочих сценариев поднимите свой релей.

Контекст

Первый прототип под именем derpcat Фицпатрик написал в сентябре 2023 года, публично проект показали после конференции TailscaleUp в августе 2026-го. Мотив компании понятен: чем больше людей знакомы с её сетевым стеком, тем проще им потом прийти за полноценным продуктом. Для разработчика это честная сделка: рабочий инструмент под BSD-лицензией без обязательств, но и без гарантий, что завтра его интерфейс не изменится.

Источники: tailcat: Tailscale without Tailscale (блог Tailscale), Репозиторий tailscale/tailcat

Изображение на обложке: Tailscale

Подтверждённый вектор атаки не требовал взлома серверов Softaculous: она прошла на уровне маршрутизации интернета и сработала потому, что клиент обновлений Virtualizor не проверял криптографическую подпись пакета, ему хватало валидного TLS. Если у вас стоит Virtualizor, а его используют многие хостинги, включая российские, компания просит проверить сервер по опубликованному индикатору, даже если обновление вручную вы не запускали.

• Окно инцидента около 33 часов: с 28 августа 20:57 UTC до 30 августа 06:10 UTC; активный перехват шёл двумя волнами общей длиной около 22 часов с перерывами, маршрут постоянно менялся.
• Поддельный маршрут /24 был специфичнее легитимного /16 Hetzner; все 368 peers RIPE RIS видели его хотя бы в один момент за окно инцидента; медианное число перенаправленных peers во время активной волны — 266 (около 72%).
• Через перехваченный трафик атакующий прошёл проверку Let's Encrypt и получил технически валидный сертификат для доменов Virtualizor.
• Вредоносное обновление подтверждено для Virtualizor; для других продуктов Softaculous таких пакетов не подтверждено. Индикатор компрометации: служба java-jre-update.service; выпущена версия 3.2.9.9 с инструментом устранения последствий и cleaning script, подпись пакетов обещана.
• Клиент обновлений не проверял подпись пакета; компания не может составить полный список затронутых серверов.

Как работает угон маршрута

BGP — протокол, по которому сети-операторы сообщают друг другу, через кого достижимы те или иные диапазоны IP-адресов. Доверие в нём во многом строится на честном слове: если кто-то объявляет, что диапазон живёт у него, соседи обычно верят. А если объявленный диапазон меньше (специфичнее) настоящего, маршрутизаторы предпочитают именно его. Так и произошло: Hetzner (AS24940) легитимно объявляет 162.55.0.0/16, атакующий объявил внутри него 162.55.80.0/24, и более точный маршрут победил.

В объявлении фигурировали AS62390 (NexonHost) и AS6204 (Zet.net), а в конце пути был оставлен Hetzner как видимый источник, чтобы подмена выглядела правдоподобно. По публичным данным RIPE RIS все 368 peers видели маршрут хотя бы в один момент за окно инцидента, а медианное число перенаправленных peers во время активной волны составляло 266. Перехват шёл двумя волнами общей продолжительностью около 22 часов с паузой примерно в 11 часов между ними, и для отдельных сетей он был прерывистым: маршрут то появлялся, то исчезал.

Почему сертификат оказался настоящим

Let's Encrypt подтверждает владение доменом, обращаясь к нему по HTTP. Если в этот момент трафик к домену идёт на сервер атакующего, проверка проходит, и сертификат выдаётся ему. Именно это и случилось: компания пишет, что злоумышленник получил «технически действительный TLS-сертификат для наших доменов» (перевод редакции). Браузеры и клиенты обновлений видели зелёный замок и доверяли ответам подменённого сервера.

The attacker obtained a technically valid TLS certificate for our domains.

Дальше сработало самое слабое звено: клиент обновлений Virtualizor доверял серверу по TLS и не проверял подпись самого пакета. Правильная схема, при которой пакет подписан офлайн-ключом разработчика и проверяется на сервере клиента, не спасла бы от перехвата трафика, но сделала бы подмену пакета невозможной. Компания обещала внедрить подпись для всех пакетов; срок и реализацию она не назвала.

Кого это задело

По словам компании, вредоносный пакет получила «горстка серверов», а не вся база пользователей Virtualizor. При этом Softaculous прямо признаёт: «Мы не можем составить окончательный список затронутых серверов» (перевод редакции), потому что подмена происходила на сетевом уровне и следов на стороне компании не оставила. Для Softaculous, Webuzo и других продуктов вредоносных пакетов не подтверждено, но те же адреса использовались и для их обновлений. Индикатор компрометации, который называет компания, — служба java-jre-update.service в системе. Softaculous выпустила Virtualizor 3.2.9.9 с инструментом устранения последствий и отдельный cleaning script, но просит при обнаружении индикатора не удалять службу самостоятельно, а связаться с поддержкой.

Что делать администратору

• Если у вас Virtualizor: обновитесь до 3.2.9.9, поищите службу java-jre-update.service и при её наличии свяжитесь с поддержкой Softaculous, как просит компания; проверять стоит, даже если обновления вы не запускали, автообновление могло сработать само.
• Сверьте по логам, не обращался ли сервер к 162.55.80.0/24 между 28 августа 20:57 UTC и 30 августа 06:10 UTC.
• Смените учётные данные панели, API-ключи и пароли, которые могли пройти через клиентскую зону или биллинг в этот период.
• Для собственных систем обновлений: подписывайте пакеты отдельным ключом и проверяйте подпись на клиенте; TLS защищает канал, но не содержимое.
• Если управляете своей сетью: включите RPKI Origin Validation и задайте свои ROA с точной длиной префикса. Оговорка: атакующий оставил Hetzner видимым origin, и без строгого maxLength в ROA такой маршрут ROV не отбросит.

Что дальше

Компания продолжает расследование; индикатор компрометации, версия 3.2.9.9 и cleaning script уже опубликованы. Открытых вопросов два: почему сети-транзиты пропустили объявление чужого /24 без проверки и когда и как будет внедрена обещанная подпись пакетов. Пока её нет, любой повторный угон маршрута снова превратится в атаку на цепочку поставок.

Источник: Security incident: BGP hijacking (Virtualizor)

Изображение на обложке: скриншот bgp.tools

• Новая спецификация MCP 2026-07-28 делает протокол stateless: сессии и handshake больше не нужны.
• Клиент передаёт свою идентификацию и возможности в поле _meta каждого JSON-RPC-запроса.
• Балансировщик может использовать обычный round-robin, ориентируясь на заголовки Mcp-Method и Mcp-Name.
• Roots, Sampling и Logging объявлены устаревшими с минимальным окном поддержки 12 месяцев.
• Финальная спецификация ожидается 28 июля 2026 года после 10-недельного окна валидации SDK.

Model Context Protocol (MCP) — открытый протокол для подключения ИИ-агентов к внешним инструментам и данным. С момента передачи Anthropic в Linux Foundation в декабре 2025-го им управляет Agentic AI Foundation, а число production-серверов уже исчисляется сотнями тысяч. До сих пор MCP работал по модели чата: сначала handshake, потом сервер выдавал идентификатор сессии, который клиент возвращал с каждым запросом.

В релиз-кандидате эта модель заменена на stateless. Клиент кладёт имя, версию и capabilities в поле _meta прямо в тело запроса. Балансировщик читает HTTP-заголовки Mcp-Method и Mcp-Name (SEP-2243) и направляет запрос на любой свободный инстанс — общее хранилище сессий больше не требуется. Если серверу нужен ввод посреди вызова, он возвращает InputRequiredResult, а клиент переотправляет запрос с inputResponses и requestState.

Вместе с ядром обновляются и расширения. Появляется MCP Apps — серверный интерактивный UI в sandboxed iframe с заранее декларируемыми шаблонами. Переработано API долгих задач: вместо tasks/list приходят tasks/get, tasks/update и tasks/cancel. Также шесть SEPов ужесточают авторизацию по OAuth/OIDC, включая проверку issuer по RFC 9207.

Часто задаваемые вопросы

Выводы

Новая спецификация — признак того, что MCP вырос из протокола для локальных подключений в полноценную enterprise-инфраструктуру. Переход к statelessness решает главную операционную проблему масштабирования, но добавляет работы тем, кто уже внедрил stateful-реализации. Главное — помнить, что релиз пока кандидат: production-серверы продолжают работать на спецификации 2025-11-25.

Источник: awesomeagents.ai.

Сервис Images, написанный на Rust и работающий в Workers, запущен на каждой машине в edge-сети Cloudflare. Чтобы обрабатывать клиентские соединения, мы используем hyper — открытую HTTP-библиотеку для Rust.

В прошлом году мы представили Images binding — он позволяет создавать кастомные программные сценарии обработки удалённых изображений в Workers. В конце 2025 года мы перестроили binding, чтобы сделать связь между Workers runtime и сервисом Images более прямой и локальной.

Вскоре после выкатки мы получили сообщения о том, что запросы на трансформацию из binding падают — но только иногда и только для больших изображений. Ещё страннее было то, что ответы на эти запросы возвращали статус 200, и в логах не было никаких ошибок. Данные изображения просто обрывались: ответ, который должен был весить два мегабайта, мог прийти всего в несколько сотен килобайт.

Мы потратили шесть недель на охоту за почти невидимым багом — состоянием гонки, которое проявлялось только при определённых условиях, — в библиотеке hyper, который влиял на то, как Images binding возвращает обработанные изображения клиенту. В итоге исправление заняло четыре строки кода.

Cloudflare Images binding перешёл на прямое локальное соединение через Unix-сокеты в декабре 2025 года.

После выкатки большие изображения стали иногда возвращаться обрезанными: HTTP 200, но тело ответа короче Content-Length.

Причина — состояние гонки в hyper: цикл poll_loop отбрасывал результат poll_flush, даже если тот возвращал Poll::Pending.

Баг существовал в hyper 0.14.x, 1.7 и 1.8; прежний посредник FL читал данные достаточно быстро, чтобы он не проявлялся.

Исправление заняло четыре строки кода: flush теперь выполняется перед shutdown.

Прыжки, передачи и hyper

Когда разработчики создают приложения на Cloudflare, они собирают full-stack приложения из набора платформенных сервисов, доступных Workers через bindings. Bindings предоставляют прямые API к ресурсам Developer Platform: вычислениям, хранилищам, ИИ-инференсу и обработке медиа.

Images binding отделяет оптимизацию изображений от доставки: вы можете транскодировать, компоновать или изменять изображения, не возвращая результат в виде HTTP-ответа. Также он позволяет применять параметры оптимизации в любом порядке, а не в фиксированной последовательности, которую навязывает URL-интерфейс. Вот пример: воркер передаёт данные изображения напрямую в Images API, объединяет операции в цепочку и получает обработанный результат в виде потока:

На высоком уровне так выглядит движение данных через наши сервисы:

Труба на схеме обозначает сокетное соединение между посредником и Images, через которое данные передаются от одного процесса к другому через буфер ядра.

Binding взаимодействует с Images через сокетное соединение, управляемое Workers runtime. Сокет — это канал связи между двумя процессами. У каждого конца сокета есть буферы, управляемые ядром операционной системы; эти буферы — временные области, где данные остаются после записи одной стороной, но до чтения другой.

Hyper управляет соединением на стороне сервиса Images: читает входящие запросы из сокета и пишет ответы обратно в него.

Когда запрос использует Images binding, сервис Images читает входные данные, выполняет запрошенные операции оптимизации и кодирует результат. Затем он передаёт всё закодированное изображение hyper как один непрерывный блок в памяти.

Hyper записывает эти данные ответа в свой внутренний буфер. На этом моменте hyper считает кодирование завершённым, потому что у него есть все байты, которые нужно отправить. Следующий шаг — сбросить внутренний буфер в исходящий буфер сокета, переместив данные от сервиса Images к посреднику на другом конце.

Если читатель на другом конце быстрый, hyper может сбросить всё за один проход — в исходящем буфере будет место, потому что читатель потребляет данные по мере поступления. Как только все данные отправлены, hyper вызывает shutdown на сокете, сигнализируя, что соединение завершено и больше данных записано не будет. Но если читатель медленнее (хотя бы на несколько миллисекунд), исходящий буфер заполняется, и hyper должен ждать, пока появится место, чтобы продолжить запись.

Локальное соединение

Весь входящий трафик в сети Cloudflare проходит через FL — внутренний сервис-посредник, который включает функции безопасности и производительности и маршрутизирует запросы к нужному бэкенду. Когда мы только запустили binding, данные изображений шли из Workers runtime через FL в сервис Images.

Этот путь хорошо подходил для первого релиза и повторял архитектуру URL-интерфейса. Но со временем связь с FL стала ограничением: любое изменение binding приходилось согласовывать с циклом релизов FL.

В декабре 2025 года команда Images заменила FL новым посредником — внутренним worker binding, который работает на той же машине. В исходной архитектуре данные шли через FL по сетевым сокетам; этот путь нёс накладные расходы полного конвейера обработки FL, такие как DNS-lookup'ы и маршрутизация.

Внутренний binding заменил их на Unix-сокеты, чтобы напрямую соединить сервисы на одной машине, минуя FL и накладные расходы сетевого стека. Это ускорило путь запроса к Images и дало команде независимый контроль над релизами binding.

В течение нескольких дней после выкатки мы получили первый отчёт от клиента.

200 OK (не OK)

Первый признак проблемы пришёл от клиента с нестандартной конфигурацией: два уровня обработки изображений, где один pipeline был вложен в другой.

Сначала их воркер с помощью Images binding компоновал несколько больших исходных изображений из R2 — JPEG-фон и PNG-оверлеи — в один объединённый JPEG. Затем результат дополнительно сжимался, транскодировался и изменялся размер через URL-интерфейс.

Баг возникал на обратном пути внутреннего pipeline, где ответ обрезался до того, как достигал внешнего.

Внутренний pipeline (transformation binding) отвечал за компоновку. Внешний pipeline (transformation URL) отвечал за оптимизации доставки: масштабирование и конвертацию формата. Такая многоуровневая схема означала, что когда внутренний pipeline молча возвращал обрезанный ответ, видимая ошибка появлялась на уровень выше:

Внешний pipeline получал от внутреннего HTTP 200 с заголовком Content-Length, который обещал несколько мегабайт. Фактическое тело было лишь частью от этого: в одном запросе из ожидаемых 3,3 МБ пришло всего около 200 КБ. Ошибка всплывала во внешнем pipeline, но обрезка могла произойти в binding, посреднике, сервисе Images или где-то между ними.

Когда браузер получает обрезанное изображение, результат виден невооружённым глазом. В зависимости от формата изображение либо отрисовывается частично (например, с отсутствующей или серой нижней частью), либо полностью не декодируется и отображается как битое.

Отладка вслепую

Отсюда мы двигались вглубь по пути запроса, проверяя каждый уровень, чтобы локализовать место обрезки. Некоторые усилия зашли в тупик; другие оставили зацепки, которые сузили поиск:

• Сборка репродукции. Мы собрали воркер, повторяющий вложенную схему клиента, и постепенно убирали уровни, пока не смогли воспроизвести баг только с binding. Небольшой скрипт отправлял запросы пачками. На одном из первых прогонов 19 из 25 запросов упали. Объём данных, которые всё-таки приходили, — примерно 200 КБ — настораживающе близко к размеру сокетного буфера в продакшене. Это подтвердило, что проблема не связана с конфигурацией клиента, и дало надёжный способ воспроизводить баг по запросу.
• Проверка таймаутов. Сначала мы подозревали, что обрезка связана с поведением таймаутов (то есть соединение закрывалось по истечении лимита времени). Эта теория не подтвердилась: обрезка не коррелировала с длительностью запроса.
• Обновление версии hyper. Когда баг впервые зарепортили, мы использовали 0.14.x, а последняя версия hyper была около 1.8.x. Мы протестировали версии 0.14, 1.7 и 1.8 — на случай, если самый очевидный ответ окажется правильным (и самым простым). Но баг проявлялся в каждой версии, значит, upstream-исправления не было.
• Локальное воспроизведение. Мы запускали интеграционные тесты на macOS и Debian-виртуалке. Даже под значительной нагрузкой локальные запросы никогда не падали. Прямые curl-запросы к сокету binding и повтор отловленных запросов всегда работали. Баг проявлялся только на полном продакшен-пути при реальной конкурентности и реальном клиенте Workers runtime на другом конце сокета. Это натолкнуло нас на подозрение, что виноват сам runtime.
• Исключение Workers runtime. Мы изучили HTTP-клиент, который Workers runtime использует для связи с Images через сокет binding. Ни на одной из сторон соединения в трассировках не было системных вызовов, указывающих на неожиданное закрытие или преждевременное завершение. Клиент вёл себя корректно, и несколько других сервисов использовали того же клиента без проблем.
• Распределённая трассировка. Изучив сквозные трассировки запросов, мы подтвердили, что обрезанное тело уже присутствовало до того, как достигало внешнего уровня трансформации в схеме клиента. Это сузило проблему до внутреннего pipeline — пути binding через сервис Images.
• Инструментирование посредника. Мы добавили инструментирование в посредник, чтобы измерять размеры тел перед пересылкой ответа. Тела уже были обрезаны к моменту выхода из сервиса Images, так что посредник был исключён.
• Углублённая трассировка внутри Images. На уровне сервиса запрос обрабатывался, изображение корректно кодировалось, и ответ отправлялся с HTTP 200.

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

Зерно истины

Инструменты отладки на уровне приложения показывали лишь то, что система считала, что делает. Но по мнению системы всё было в порядке: трассировка утверждала, что ответ отправлен; логи не сообщали об ошибках; сервис Images возвращал 200 на каждый запрос.

Чтобы увидеть, что система делала на самом деле, мы подключили strace к сервису Images. strace записывает системные вызовы, которые процесс делает ядру; это позволило показать, какие именно байты были записаны, когда вызывался shutdown и посылал ли клиент сигнал завершения.

Настройка трассировки была деликатной. strace работает, перехватывая системные вызовы по мере их выполнения, что добавляет небольшие накладные расходы по времени к каждому вызову. Фильтрация узкого набора системных вызовов держала эти накладные расходы минимальными. Однако расширение фильтра замедляло процесс ровно настолько, чтобы сдвинуть тайминг между flush и проверкой shutdown — и баг полностью исчезал. Одно это уже подкрепляло теорию о тайминг-зависимости проблемы.

Используя воркер-репродукцию, мы спровоцировали баг и сравнили вывод системных вызовов между успешными и упавшими запросами.

При успешном запросе ответ пишется кусками по мере освобождения сокетного буфера, а shutdown вызывается только после отправки всех данных. Например, это может выглядеть так:

Когда мы воспроизвели баг, упавший запрос выглядел так:

Здесь есть только одна запись — лишь заголовки и крошечная часть тела — перед немедленным вызовом shutdown. Из ответа в 14,9 МБ было отправлено около 219 КБ. Оставшиеся ~14,8 МБ данных изображения никогда не покидали внутренний буфер hyper, и не было никакого сигнала завершения от клиента между записью и shutdown. Вместо этого сервис Images преждевременно закрывал соединение самостоятельно, искренне полагая, что работа завершена.

Упавшие запросы подтвердили, что баг — состояние гонки, которое срабатывало непостоянно. Успех или провал зависели от того, перекрывались ли операции flush и shutdown, и это менялось от запроса к запросу. Когда буфер был полон в тот самый момент, когда hyper решил, что соединение завершено, данные терялись.

Когда читатель потребляет медленнее, чем hyper пишет, исходящий буфер заполняется. Если hyper закрывает соединение до того, как буфер опустеет, то лишь часть ответа попадает к посреднику; эти неполные данные пересылаются обратно в Workers runtime и клиенту.

Перестройка в декабре не ввела этот баг — он существовал в hyper годами в нескольких мажорных версиях. Но новый посредник изменил того, кто читал ответ на другом конце сокета. Наша рабочая теория: прежний посредник FL потреблял данные достаточно быстро, чтобы сокетный буфер редко заполнялся во время ответа. Новый читатель работал в темпе, который иногда позволял буферу заполняться при больших ответах.

Этих нескольких миллисекунд обратного давления, внесённых улучшением, которое ускорило всё остальное, хватило, чтобы выявить изъян, который скрывался на виду.

Внутри цикла dispatch

Жизненный цикл HTTP/1-соединения в hyper управляется конечным автоматом в файле под названием dispatch.rs. Он выполняет цикл, который читает запросы, пишет ответы, сбрасывает буфер записи в сокет и решает, когда закрываться. В упрощённом виде:

Точнее, именно let _ перед poll_flush — это место, где живёт баг.

В Rust let _ = expr отбрасывает результат выражения, включая Poll::Pending — сигнал о том, что flush ещё не завершён. В буфере flush может остаться несколько мегабайт, но цикл об этом никогда не узнаёт.

Когда запрос падает, последовательность событий выглядит так:

1. Сервис Images завершает кодирование изображения и передаёт весь ответ hyper как один блок в памяти.
2. Hyper записывает блок во внутренний буфер и помечает состояние записи как Writing::Closed. С точки зрения кодирования работа сделана — кодировать больше нечего.
3. Hyper вызывает poll_flush, чтобы перенести буферизованные данные в сокет. В нашем примере сокет принял около 219 КБ. Оставшиеся ~14,8 МБ остаются в буфере hyper. Сокет полон, поэтому ядро возвращает Poll::Pending.
4. poll_loop отбрасывает Poll::Pending с помощью let _.
5. Он проверяет wants_read_again(). Полный запрос уже получен, поэтому возвращается false.
6. poll_loop возвращает Poll::Ready(Ok(())), сигнализируя, что цикл завершён, хотя flush ещё не сделан.
7. Срабатывает poll_shutdown(). Выполняется системный вызов SHUT_WR.
8. Клиент получает 219 КБ и EOF (end-of-file), указывающий, что соединение закрыто, хотя он ожидает 14,9 МБ.

На втором шаге hyper помечает операцию записи как завершённую, как только тело ответа оказывается в буфере (то есть когда кодирование закончено), а не когда данные фактически сброшены. В большинстве случаев flush завершается за один проход, и это различие незаметно. В редких случаях, когда сокетный буфер полон, flush приходится ждать — но hyper не ждёт. Байты всё ещё сидят в буфере hyper, ожидая сброса в сокет. Hyper при этом закрывает соединение с этими данными всё ещё в буфере.

Это также объясняет, почему curl никогда не воспроизводил баг. Curl читает данные так быстро, как они приходят: сокетный буфер никогда не заполняется, flush всегда завершается мгновенно, и отброшенное возвращаемое значение безобидно. Продакшен-путь с читателем, который иногда паузил на несколько миллисекунд, был единственной конфигурацией, где буфер заполнялся в нужный момент.

Не забывайте сбрасывать буфер

После недель расследования само исправление было концептуально простым. Hyper должен был проверять, завершён ли flush, прежде чем двигаться дальше.

Наш reproduction-воркер подтвердил, что баг существует, но не мог объяснить, почему падает конкретный запрос. Прежде чем писать исправление, нам нужен был тест, который мог бы спровоцировать точные сокетные условия внутри hyper.

Мы знали условия, вызывающие баг: сокет, который принимает один кусок данных, а затем блокируется. Для контролируемого сценария мы построили обёртку вокруг TCP-потока, имитирующую полный сокетный буфер. Обёртка принимала 8 КБ при первой записи, а затем возвращала Poll::Pending на каждой последующей записи, имитируя читателя, который перестал опустошать буфер.

Тест отправлял 500 КБ ответа через этот ограниченный сокет и проверял, вызывает ли hyper shutdown, пока в буфере остаётся 492 КБ. Без исправления — вызывал. С исправлением — ждал.

Сначала мы применили исправление в цикле dispatch hyper. Вместо отбрасывания результата poll_flush мы проверяли, завершён ли flush на самом деле:

Если flush не завершён, цикл возвращает Poll::Pending асинхронному runtime. Runtime ждёт, пока сокет не станет доступен для записи, а затем будит задачу, чтобы продолжить flush. Соединение закрывается только после того, как все данные отправлены.

Когда мы выкатили это исправление, мы увидели, что записан каждый байт, а shutdown вызывался только после того, как буфер действительно опустел. Клиент, который сделал первый репорт, тоже подтвердил, что проблема исчезла.

Хотя первоначальное решение работало, цикл dispatch был неправильным местом для исправления. Ранний возврат Poll::Pending мог замедлять другие операции на том же соединении, уменьшая частоту опроса чтения и вызывая нежелательное обратное давление. Также это корректно не обрабатывает keepalive-соединения, где одно соединение обрабатывает несколько запросов подряд — они должны оставаться пригодными к использованию, даже пока предыдущий ответ всё ещё сбрасывается. Ни одна из этих проблем не затрагивала наш сервис (где keepalive отключён), но обе могли повлиять на других пользователей hyper, если бы исправление было предложено upstream.

Мы проследили жизненный цикл соединения hyper и нашли более точечный подход. Вместо изменения поведения цикла dispatch мы применили исправление в том месте, где shutdown вызывается на самом деле. Перед закрытием сокета hyper должен сначала сбросить оставшиеся данные в буфере:

Это оставляет цикл dispatch без изменений. Flush добавляется только в тот точный момент, где иначе произошла бы потеря данных — непосредственно перед shutdown.

Что осталось с нами

Ни один из инструментов на уровне приложения не выдавал ошибок, падений или полезных записей в логе. Наблюдаемость на уровне приложения может иметь слепое пятно для багов, которые живут ниже её уровня осознанности.

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

Прорыв случился благодаря инструментарию уровня ядра — strace, единственному слою, который фиксирует, что на самом деле происходило на сокете. Базовый баг жил в нескольких миллисекундах между частичным flush и преждевременным shutdown — окне, которое открылось только после того, как мы ускорили систему.

Мы влили исправление и детерминированный тест в hyperium/hyper через PR #4018. Оно появится в будущем релизе hyper, гарантируя, что любой сервис, использующий HTTP/1-реализацию hyper, не потеряет данные ответа из-за того же состояния гонки.

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

Изначально Images binding покрывал только трансформации удалённых изображений. В начале этого месяца мы объявили, что Images binding теперь поддерживает операции для hosted-изображений, давая разработчикам единый способ строить медиа-насыщенные приложения на Cloudflare.

Подробнее о том, как работает binding, — в нашей документации.

Agent2Agent — это протокол, управляемый Linux Foundation (изначально представленный Google), который позволяет агентам на разных фреймворках и языках находить друг друга, делегировать задачи и обмениваться результатами. Для Java-экосистемы выпуск SDK версии 1.0.0 означает переход от экспериментальных сборок к инструменту, готовому к промышленной эксплуатации.

Релиз 1.0.0 появился на прошлой неделе, как сообщает InfoQ в очередном выпуске Java News Roundup. В него вошли исправления ошибок, обновление зависимостей и несколько новых возможностей: интеграционный тестовый набор на базе Quarkus для проверки совместимости разных SDK, а также расширение интерфейса A2AHttpResponse и класса A2AClientHTTPError для доступа к HTTP-заголовкам ответов.

• A2A Java SDK 1.0.0 вышел в GA — первая стабильная версия для Java.
• Реализует протокол Agent2Agent для взаимодействия ИИ-агентов.
• Появился интеграционный тестовый набор на базе Quarkus.
• Доступен в Maven Central: org.a2aproject.sdk.
• Параллельно вышел A2A Jakarta 1.0.0.CR1 для Jakarta EE серверов.

Что вошло в релиз A2A Java SDK 1.0.0

• Новый интеграционный тестовый набор (ITK) на базе Quarkus для проверки кросс-SDK совместимости.
• Возможность получать HTTP-заголовки ответов через интерфейс A2AHttpResponse и класс A2AClientHTTPError.
• Исправления ошибок и обновление зависимостей.
• Готовность к использованию в production вместе с A2A Protocol Specification 1.0.

I am pleased to announce the release of A2A Java SDK 1.0.0.Final — our first GA release. The A2A Java SDK is the official Java implementation of the Agent2Agent (A2A) Protocol, an open standard that enables AI agents to communicate and collaborate regardless of underlying framework, language, or vendor.

Параллельно команда выпустила первый релиз-кандидат A2A Jakarta 1.0.0.CR1. Эта интеграция помогает запускать A2A-агентов внутри Jakarta EE серверов, таких как WildFly. В CR1 переименованы пакеты и артефакты, обновлён набор TCK для работы с A2A Java SDK 1.0.0 и настроен запуск CI на Windows.

Зачем это Java-разработчикам

SDK позволяет строить агентные приложения на Java без привязки к Python-стеку. Агенты могут общаться с агентами на Google ADK, LangGraph, CrewAI и других фреймворках через единый протокол. Это особенно важно для команд, где основная инфраструктура уже написана на Java. Рядом с A2A развивается протокол MCP: если MCP соединяет агента с инструментами, то A2A — агента с агентом.

A2A Java SDK 1.0.0 делает Java полноценной платформой для агентных приложений: теперь можно подключить SDK из Maven Central и начать строить агентов, которые работают в одной экосистеме с Python- и TypeScript-решениями.

Источник: InfoQ — Java News Roundup: A2A Java SDK 1.0, Jakarta EE 12, JNoSQL, GraalVM, Micrometer, OpenXava, Gradle.

Что такое протокол передачи данных

Под протоколом передачи данных здесь понимается формат пакетов (кадров), которые строятся поверх физического уровня. Физический уровень — это уже выбранный интерфейс: RS-232, RS-485, инфракрасный канал, радиомодуль или оптоволокно. От него мы получаем две базовые операции: отправить один байт и принять один байт. Всё остальное — наша задача.

Данные передаются пакетами — кадрами. Хороший кадр позволяет приёмнику понять: где начало сообщения, кому оно адресовано, сколько в нём полезных данных и не повредились ли они по дороге.

Кадр состоит из заголовка, адресов, типа данных, длины, полезной нагрузки, контрольной суммы и концевика.

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

Парсинг удобно реализовывать конечным автоматом: каждый принятый байт переводит машину в новое состояние.

На хосте данные почти всегда буферизуются; на простых МК часто выгоднее передавать напрямую, чтобы сэкономить ОЗУ.

Структура кадра: из чего собирать пакет

Надёжный протокол обычно включает семь логических полей. Не все обязательны — выбор зависит от задачи.

Заголовок и концевик

Заголовок (frame header) и концевик (frame tail) отмечают границы кадра. Главное требование — минимизировать вероятность случайного совпадения этих байтов в потоке данных. Есть два подхода:

• Подбор характерных байтов. Если данные предсказуемы (например, только ASCII-текст), можно выбрать заголовок из диапазона непечатаемых символов.
• Увеличение длины. Для случайных данных лучше сделать заголовок многобайтовым — например, 0x55 0xAA 0x7E. Вероятность случайного совпадения трёх конкретных байтов подряд падает экспоненциально. Даже если совпадение произойдёт, его отловит контрольная сумма.

Адресация

Адрес назначения нужен в системах типа «один к многим» — например, когда один хост управляет несколькими датчиками по общей шине RS-485. В сложных сетях добавляют ещё и адрес источника, чтобы получатель знал, от кого пришёл пакет.

Тип, длина и данные

Тип данных (data type) говорит, что дальше идёт команда или полезная нагрузка. Длина (data length) указывает число значащих байтов в блоке данных. Вместе они образуют «тело» кадра — ту часть, которую мы действительно хотим доставить.

Контрольная сумма

Контрольная сумма проверяет целостность кадра. Простейший вариант — арифметическая сумма всех байтов тела. Для более серьёзной защиты применяют CRC (циклический избыточный код): он ловит пакетные ошибки и перестановки битов, которые простая сумма пропустит. Выбор алгоритма — компромисс между скоростью вычисления на МК и требуемой надёжностью.

Передача: хост и микроконтроллер

На физическом уровне отправка сводится к посылке байтов один за другим. Но способ организации этой посылки сильно влияет на производительность.

Передача с микроконтроллера

На простых контроллерах вроде семейства 8051 часто используют прямую передачу: процессор загружает байт в буфер UART и ждёт флага готовности. Плюс — данные моментально оказываются на линии. Минус — процессор занят на всё время отправки.

Альтернатива — передача по прерыванию: байты складываются в кольцевой буфер, а прерывание UART отправляет их фоном. Экономит процессорное время, но требует ОЗУ под буфер. На 8051 с его скудной памятью прямая передача часто выигрывает.

Передача с хоста

На ПК данные почти всегда буферизуются операционной системой. Программист работает с тремя уровнями абстракции:

1. Контролы ОС. В Windows — компоненты вроде MSComm (устаревший 32-bit ActiveX, не рекомендуется для новых проектов). Просто, но нужно следить за блокировками при приёме и многопоточностью.
2. Системные API. В Windows и Linux последовательный порт — это файл. Открываем через CreateFile или open(), но перед чтением и записью требуется настройка параметров порта (в Linux — termios со скоростью, чётностью и размером слова).
3. Класс-обёртка. Например, CSerialPort для Windows: он инкапсулирует инициализацию, поток приёма и отправку. После открытия порта вызов WriteToPort отправляет массив байтов, а внутренний поток следит за входящими данными и шлёт сообщения родительскому окну.

Приём и парсинг на конечном автомате

Приём данных на стороне микроконтроллера тоже бывает двух видов: опрос (поллинг) и прерывание. Опрос проще, но отнимает процессорное время. Прерывание эффективнее: байт пришёл — сработала процедура обработки прерывания (ISR, Interrupt Service Routine), процессор отвлёкся на доли миллисекунды и вернулся к задаче.

Где размещать парсер протокола? Если протокол простой, его можно держать прямо в обработчике прерывания: приняли корректный кадр — установили флаг, основной цикл реагирует. Для сложных протоколов лучше писать байты в буфер и разбирать их в главном цикле. Гибридный подход тоже возможен: в прерывании ищем только «команду подключения», а остальное парсим фоном.

Пример: разбор кадра по состояниям

Рассмотрим конкретный формат кадра:

Парсер реализуем через переменную state_machine. Каждое состояние соответствует ожидаемому байту. Если пришёл не тот байт — автомат сбрасывается в ноль. Это защищает от «залипания» в промежуточном состоянии при обрыве связи или помехах.

Совет по стабильности:
Сброс автомата при несовпадении заголовка, адресов, длины, checksum или концевика — ключевая техника. Без неё при обрыве кадра парсер застрянет в промежуточном состоянии, и следующие кадры будут отвергнуты.

Приём на стороне хоста

На ПК приём организуется проще: операционная система уже буферизует входящие байты. Для неблокирующего чтения запускают отдельный поток, который ждёт данных из порта и передаёт их в основной процесс через сообщения или обратный вызов. Класс CSerialPort, например, отправляет родительскому окну сообщение WM_COMM_RXCHAR с каждым новым байтом. Обработчик этого сообщения просто вызывает тот же парсер, что и на микроконтроллере.

Таким образом, логика разбора протокола единая для обеих сторон. Различается только способ доставки байтов в парсер: прерывание ISR на МК и поток ОС на хосте.

Выводы

Проектирование протокола связи для микроконтроллера — это не ракетостроение, но требует дисциплины. Хороший кадр защищает границы (заголовок + концевик), адресует получателя, указывает длину и проверяет целостность. Парсинг на конечном автомате делает код предсказуемым и устойчивым к сбоям.

Главный принцип — сбрасывать автомат при любом нарушении ожидаемого шаблона. Это предотвращает «залипание» и позволяет системе быстро восстановиться после помехи. На основе этой базы можно наращивать надёжность: добавлять повторные передачи, порядковые номера, шифрование — в зависимости от требований проекта.

Хороший протокол — это не тот, который передаёт быстрее всех, а тот, который не ломается при помехах.

Источник: оригинальная статья Leo Liu — Microcontroller Communication Protocol Design (DEV Community).

В IPv6 каждый сетевой интерфейс получает link-local адрес из диапазона fe80::/10 (первые 10 бит фиксированы, остальное — адрес интерфейса). Если у машины два интерфейса — например, Ethernet и Wi-Fi — оба будут в одном и том же префиксе. Вопрос: как операционная система понимает, к какому именно интерфейсу адресовать пакет? Ответ — зоны (scopes).

В IPv6 зона интерфейса записывается через %: fe80::4%eth0. Это нужно, чтобы различать link-local адреса на разных сетевых интерфейсах.

В URL зона попадает внутрь квадратных скобок: [fe80::4%eth0]:80. Но символ % в URL — это начало percent-encoding, поэтому парсер ломается.

Решение — экранировать % как %25: [fe80::4%25eth0]:80. Это поведение зафиксировано в RFC 6874.

Проблема затрагивает не только Go, но и nginx, Python requests и браузеры. Поддержка зон в HTTP-клиентах остаётся фрагментарной.

Как зоны работают в IPv6

Зона (или scope ID) — это механизм, позволяющий ядру отличать адреса из пересекающихся диапазонов. Для link-local адресов fe80::/10 он критичен: без него роутинговая таблица не поймёт, через какой интерфейс отправлять трафик.

Формат зоны зависит от ОС. В Linux это имя интерфейса — eth0, wlan0, ens192. В Windows — числовой идентификатор интерфейса. Полный адрес выглядит так:

Квадратные скобки отделяют хост от порта — иначе двоеточия IPv6-адреса спутаются с разделителем порта.

Конфликт зон и URL

Теперь вставим этот адрес в URL. На первый взгляд всё просто:

Но попробуем распарсить его в Go:

Получаем ошибку:

Что произошло? В URL любой символ, не входящий в разрешённый набор, должен быть percent-encoded. Пробел превращается в %20, кириллица — в последовательности вроде %D0%90. Парсер видит %e и пытается декодировать его как hex-последовательность. et — не валидный байт, поэтому URL отклоняется.

Почему Go падает и как это чинить

С точки зрения стандарта Go ведёт себя корректно. RFC 3986 определяет URL-грамматику, а RFC 6874 специально дополняет её для IPv6-зон: символ % перед zone ID должен быть сам закодирован как %25.

Правильный URL выглядит так:

Проверяем в Go:

Вывод:

Go корректно декодирует %25 обратно в % при извлечении хоста. То есть библиотека поддерживает RFC 6874, но требует от вызывающего кода заранее закодировать зону.

RFC 6874: это не баг, а фича

В RFC 6874 формально описан синтаксис IPv6-адресов с зонами в литералах URL. Ключевой фрагмент:

То есть зона записывается не как %eth0, а как %25eth0. Это выглядит ужасно с точки зрения пользовательского опыта, но таково решение стандартизации: совместимость с существующей URL-грамматикой важнее эргономики.

Наша индустрия меня удивляет. Стандарт говорит: чтобы записать обычный символ процента в адресе, нужно его самого закодировать процентами. Это ужасно, но, похоже, это граничный случай, который касается не только Go.

И действительно, та же проблема есть и в других инструментах:

• nginx — тикет #623, созданный более десяти лет назад; проблема отсутствия поддержки link-local адресов с зонами до сих пор актуальна.
• Python requests — issue #6808: даже при ручном кодировании % как %25 библиотека некорректно обрабатывает IPv6-зоны в URL, потому что urllib3 декодирует %25 обратно в %.
• Браузеры — draft Schinazi объясняет, почему зоны ломают концепцию origin, и рекомендует использовать mDNS вместо прямого указания link-local адресов в URI.

Что делать разработчику

Если ваше Go-приложение работает с локальными IPv6-адресами — например, подключается к сервисам в Docker-сети, IoT-устройствам или внутренним API через link-local — учитывайте следующее:

1. Перед передачей IPv6-адреса с зоной в url.Parse всегда экранируйте % как %25.
2. Используйте net.JoinHostPort для сборки host:port — он корректно оборачивает IPv6 в скобки, но не кодирует зону. Дополнительное кодирование остаётся на вас.
3. Если адрес приходит от пользователя, валидируйте его до парсинга: зона должна содержать только допустимые символы (имя интерфейса в Linux, числовой ID в Windows).
4. Тестируйте на реальных интерфейсах с разными зонами, чтобы убедиться, что кодирование работает корректно в вашей среде.

На заметку:
Если вы пишете HTTP-клиент для embedded-устройств или промышленных контроллеров, которые общаются через link-local IPv6, ручное кодирование зоны — не костыль, а необходимость. Большинство библиотек не делают этого автоматически.

FAQ

Выводы

IPv6-зоны — редкий, но живучий граничный случай. Если вы пишете сетевой код на Go, который должен работать в гетерогенных средах — Docker, Kubernetes, embedded-системы, промышленные сети — знайте, что fe80::1%eth0 в URL превращается в fe80::1%25eth0. Это не баг парсера, а требование стандарта RFC 6874.

Инкапсулируйте кодирование зоны во вспомогательную функцию и всегда прогоняйте IPv6-адреса через неё перед сборкой URL. Экономия пяти минут сейчас обернётся часом отладки в продакшене, когда сервис внезапно не сможет достучаться до соседнего контейнера по link-local.

Источники:
• Xe Iaso — IPv6 zones in Go URLs
• RFC 6874 — Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
• draft-schinazi-httpbis-link-local-uri-bcp-03 — IPv6 Link-Local URIs

HTTP/2 Bomb — это комбинация двух техник отказа в обслуживании, известных свыше десяти лет: HPACK bomb (класс атаки; известный частный случай — CVE-2016-6581 в библиотеке Python HPACK) и удержания соединений в стиле Slowloris в реализации HTTP/2 Apache (CVE-2016-8740, CVE-2016-1546). Первая заставляет сервер резервировать память под динамические таблицы сжатых заголовков, вторая не даёт соединениям закрыться.

Codex от OpenAI объединил HPACK-бомбу и Slowloris в единую атаку HTTP/2 Bomb.

Уязвимы стандартные конфигурации nginx, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora.

По данным сканирования Shodan, более 880 тысяч сайтов на HTTP/2 могут быть под угрозой.

nginx исправлен в версии 1.29.8, Apache — в mod_http2 v2.0.41 (CVE-2026-49975), Envoy выпустил исправление.

Для Microsoft IIS и Cloudflare Pingora официального исправления пока нет; рекомендуется ограничить число заголовков в запросе или отключить HTTP/2.

Атаку выявила команда Calif во главе с исследователем Quang Luong. Они использовали Codex для анализа исходного кода: агент заметил, что две известные DoS-техники можно объединить, и помог построить рабочий эксплойт. По словам Luong, домашний компьютер на канале 100 Мбит/с способен сделать уязвимый сервер недоступным за несколько секунд. Против Apache httpd и Envoy один клиент тратит 20 секунд, чтобы занять 32 ГБ памяти сервера.

Как работает HTTP/2 Bomb

HTTP/2 сжимает заголовки алгоритмом HPACK и хранит их в динамических таблицах. Атака отправляет тысячи мелких заголовков, чтобы заставить сервер резервировать память под каждую запись таблицы — даже если сами заголовки почти пустые. Одновременно соединения удерживаются открытыми по принципу Slowloris, и сервер не может освободить выделенную память.

Кто уже выпустил исправления от HTTP/2 Bomb

• nginx — версия 1.29.8, директива max_headers из freenginx.
• Apache httpd — mod_http2 v2.0.41, CVE-2026-49975.
• Envoy — выпущено исправление, исследователи проверяют его эффективность.
• Microsoft IIS и Cloudflare Pingora — исправлений пока нет. Cloudflare оспаривает наличие уязвимости в Pingora, но заявляет, что её архитектура и DDoS-защита справляются с атакой автоматически.

Как защититься от HTTP/2 Bomb

Пока Microsoft и Cloudflare не выпустили обновления, Calif рекомендует либо отключить HTTP/2, либо ограничить максимальное количество заголовков, которые клиент может отправить в одном запросе.

Выводы

Обе половины атаки были известны десять лет. Codex проанализировал исходный код, обнаружил, что две техники можно объединить, и построил комбинированную атаку. Комбинация очевидна, когда ты её видишь, но, насколько нам известно, никто из людей не собирал её против этих серверов.

Технический разбор и PoC-скрипты опубликованы в блоге Calif и на GitHub. Дополнительные детали — в материале The Register.

Если ваш сервер использует HTTP/2 — проверьте защиту от HTTP/2 Bomb: обновите ПО и ограничьте заголовки прямо сейчас.

Если вы разрабатываете встраиваемые системы или хотите войти в IoT, этот материал — практическое руководство по созданию BLE-периферии с нуля. Мы разберём, как устроен стек, как настроить окружение и как написать код, который управляет железом со смартфона.

Что такое Zephyr OS и зачем она для BLE

Zephyr OS — открытая операционная система реального времени под управлением Linux Foundation. Лицензия Apache 2.0, поддержка более 600 плат на ARM, RISC-V, x86 и других архитектурах. Главное для нас: внутри неё живёт полноценный BLE-стек, прошедший официальную сертификацию Bluetooth SIG. Рекомендуем также обзор «Первый RISC-V RVA23 чип входит в mainline Linux».

Zephyr OS включает сертифицированный BLE-стек с открытым кодом — от приложения до радиоконтроллера.

GAP управляет обнаружением и соединениями, GATT — структурой данных (сервисы и характеристики).

Для старта понадобятся плата nRF52840 DK (~40 USD) и смартфон с приложением nRF Connect.

Прошивка собирается через west — единый инструмент для клонирования, сборки и прошивки.

Оптимизация энергопотребления: интервал advertising, peripheral latency, System OFF и отключение неиспользуемых периферий.

Это означает, что вы работаете не с хобби-реализацией, а со стеком, который прошёл conformance-тестирование. От прикладного кода до радиорегистров — всё открыто. Никаких бинарных блобов. Nordic Semiconductor, чьи чипы доминируют на рынке BLE, построила свой nRF Connect SDK поверх Zephyr. Когда инженеры Nordic пишут прошивку, они используют Zephyr.

Стек поддерживает Bluetooth 5.x (2M PHY, Coded PHY для дальней связи, Extended Advertising), Bluetooth Mesh, LE Audio с кодеком LC3, Direction Finding и все стандартные профили. Если вы делаете BLE-продукт в 2025–2026 годах — Zephyr входит в тройку лучших платформ.

Как работает BLE: два слоя, которые нужно знать

Прежде чем писать код, нужна ментальная модель. BLE — это не «классический» Bluetooth для аудио. Он создан для коротких, редких сеансов связи: датчик проснулся, отправил 20 байт, уснул. Такое устройство может работать от таблеточной батарейки годами.

Разработчик взаимодействует с двумя слоями:

• GAP (Generic Access Profile) — отвечает за обнаружение и соединения. Периферия широковещательно рассылает пакеты (advertising), а central (обычно телефон) их слушает и инициирует подключение.
• GATT (Generic Attribute Profile) — отвечает за обмен данными после соединения. Данные организованы в иерархии: устройство предоставляет сервисы, внутри которых находятся характеристики — единицы данных со свойствами Read, Write, Notify, Indicate.

Каждый сервис и характеристика идентифицируются UUID. Стандартные (от Bluetooth SIG) — 16-битные, пользовательские — 128-битные. Хорошо спроектированный набор сервисов — это API вашего устройства.

Ключевые выводы

Настройка окружения

Для работы понадобится Linux (Ubuntu 22.04+), macOS или Windows с WSL2. Идеальная плата для старта — Nordic nRF52840 DK. Она недорогая, широко доступна и имеет встроенный отладчик J-Link. А ещё посмотрите, как создать самодельные устройства на Raspberry Pi, ESP32 и Node-RED.

Установка зависимостей

На Ubuntu устанавливаем toolchain и утилиты:

Устанавливаем west — CLI для управления многорепозиторным workspace:

Инициализируем workspace и скачиваем модули (HAL-ы, криптобиблиотеки, Bluetooth controller):

Устанавливаем Python-зависимости и SDK с кросс-компиляторами:

Добавляем в ~/.bashrc:

Первое приложение: простой beacon

Начнём с минимального примера: устройство, которое только объявляет о себе по радио и не принимает соединений. Это база для iBeacon, Eddystone и отслеживание активов.

Создаём структуру проекта:

Файл CMakeLists.txt:

Конфигурация prj.conf:

Код src/main.c:

Что происходит: bt_enable(NULL) инициализирует стек синхронно. bt_le_adv_start с параметром BT_LE_ADV_NCONN запускает неконнективный advertising. Массив ad содержит флаги (general discoverable, no BR/EDR) и имя устройства.

Собираем и прошиваем:

Открываем nRF Connect на смартфоне, сканируем и видим «MyBeacon» в списке устройств. Прошивка работает.

Кастомный сервис: управляем LED со смартфона

Beacon полезен, но скучен. Настоящая магия начинается, когда телефон подключается к устройству и управляет им. Сделаем сервис, который позволяет включать LED на плате и читать состояние кнопки.

Конфигурация prj.conf:

Основной код. Здесь определяем пользовательские 128-битные UUID для сервиса и двух характеристик:

Ключевые моменты: BT_GATT_SERVICE_DEFINE собирает GATT базу данных на этапе компиляции. Характеристика LED доступна для чтения и записи, а кнопка — только для чтения. UUID сервиса вынесен в scan response, чтобы не перегружать 31-байтовый advertising-пакет.

После прошивки подключаемся через nRF Connect, находим кастомный сервис (UUID начинается с 00001234), записываем 0x01 в LED-характеристику — светодиод загорается. Только что вы управляли железом со смартфона по Bluetooth.

Notifications: отправляем данные без запроса

Чтение и запись — это pull-модель. Но датчики обычно работают по push: термометр сам шлёт температуру, пульсомер — BPM. В BLE для этого есть notifications.

Чтобы добавить notification в характеристику, нужно:

1. Указать свойство BT_GATT_CHRC_NOTIFY в характеристике.
2. Добавить CCCD (Client Characteristic Configuration Descriptor) через BT_GATT_CCC — телефон пишет в него 0x0001, чтобы включить уведомления.
3. Вызвать bt_gatt_notify при изменении данных.

Типовой паттерн — периодическая отправка через delayable work item:

Work item выполняется в системном потоке, а не в контексте прерывания, поэтому вызовы Bluetooth API безопасны.

Полный sensor node в одном файле

Соберём всё вместе: датчик температуры (симулированный), который читается по запросу и пушится через notifications с настраиваемым интервалом. Добавим обработку соединений и LED-индикацию статуса.

Здесь важны две детали. Во-первых, температура хранится в формате fixed-point (сотые доли градуса в int16_t) — это позволяет избежать дорогих операций с плавающей точкой на микроконтроллерах без FPU. Во-вторых, проверка в функции записи: если телефон шлёт некорректный интервал, стек возвращает ошибку BT_ATT_ERR_VALUE_NOT_ALLOWED.

При разрыве соединения обработчики отменяют work item, гасят LED и перезапускают advertising — устройство снова доступно для обнаружения.

Безопасность: pairing и шифрование

В рабочей среде BLE без защиты — это устройство, которое любой прохожий может переключить или прочитать. Pairing создаёт зашифрованный канал и, опционально, аутентифицирует стороны.

Методы pairing в BLE:

• Just Works — шифрование без аутентификации. Защищает от пассивного прослушивания, но не от MITM.
• Passkey Entry — пользователь вводит 6-значный код. Аутентификация есть.
• Numeric Comparison — оба устройства показывают число, пользователь подтверждает совпадение.
• Out of Band (OOB) — обмен ключами через внешний канал, например NFC.

Включаем SMP (Security Manager Protocol) и persistent storage для bonding:

Данные сопряжения (ключи, обменянные при pairing) сохраняются во флеш-памяти и переживают перезагрузку. Без этого пользователю придётся проходить pairing после каждого включения устройства — ужасный пользовательский опыт.

Чтобы требовать шифрования для чтения характеристики, меняем permission:

BT_GATT_PERM_READ_ENCRYPT означает, что чтение возможно только по зашифрованному соединению. Если телефон пытается прочитать без pairing, стек автоматически инициирует процедуру сопряжения.

Роль central: сканируем и подключаемся

Все примеры выше — периферия (peripheral): устройство, которое рассылает advertising и ждёт подключения. Другая сторона — central: шлюз, хаб, сборщик данных. Для полной картины нужно понимать обе роли.

Конфигурация central:

Запуск сканирования и подключение к первому найденному устройству с RSSI выше -70 dBm:

После подключения выполняется обнаружение сервисов через bt_gatt_discover, затем — чтение характеристик и подписка на notifications через bt_gatt_subscribe.

Оптимизация: MTU, PHY и энергопотребление

По умолчанию BLE ATT MTU — 23 байта. Минус 3 байта заголовка ATT, получаем 20 байт полезной нагрузки на операцию. Для передачи прошивки или больших буферов этого мало.

Включаем MTU 247 байт и Data Length Extension:

Zephyr автоматически инициирует MTU exchange при соединении. С 247-байтным MTU, интервалом 7,5 мс и 2M PHY пропускная способность достигает ~800–1000 кбит/с на практике.

Выбор PHY — ещё один рычаг:

• 1M PHY — дефолт, стандартная дальность и скорость.
• 2M PHY (Bluetooth 5.0) — удваивает скорость, сокращает время работы радио и экономит энергию. Дальность чуть меньше.
• Coded PHY — увеличивает дальность в 2–4 раза за счёт помехоустойчивого кодирования, но скорость падает до 125 кбит/с.

Энергосбережение — ключ к автономным устройствам. Главные приёмы:

1. Увеличить advertising interval: 1000 мс потребляет в 5 раз меньше, чем 200 мс.
2. Использовать peripheral latency: пропускать connection events, когда нечего передавать.
3. Включить System OFF: ток nRF52840 падает с ~3 мА до ~1,5 мкА.
4. Отключить неиспользуемые периферии в devicetree overlay — UART, SPI, I2C жрут ток даже в простое.

Цель для BLE-датчика — средний ток в единицы микроампер. При таком потреблении таблеточная батарейка CR2032 (225 мА·ч) проработает годы.

Что ещё умеет стек: Mesh, DFU и LE Audio

Помимо классической point-to-point связи, Zephyr поддерживает три продвинутые технологии:

Bluetooth Mesh

Bluetooth Mesh — многие-ко-многим сеть поверх BLE. Узлы пересылают сообщения друг другу, расширяя радиус действия за пределы одного соединения. Используется в умных домах и офисах: десятки лампочек, выключателей и датчиков общаются без единого центрального хаба.

DFU over BLE

DFU over BLE — обновление прошивки по воздуху. Интеграция с MCUboot даёт два слота: активный и резервный. Новая прошивка загружается через BLE SMP сервис, устройство перезагружается, MCUboot проверяет подпись и, в случае неудачи, автоматически откатывается к предыдущей версии.

LE Audio

LE Audio — новый аудиостандарт на базе BLE. Кодек LC3 даёт более высокое качество, чем классический SBC, при вдвое меньшем битрейте. Режим BIS (broadcast) позволяет одному источнику транслировать звук на неограниченное число приёмников — технология, лежащая в основе Auracast.

Отладка: что делать, когда не работает

BLE сложно отлаживать, потому что радио невидимо. Начинайте с логов:

Это выдаст подробную трассировку каждой HCI-команды, advertising event и GATT-операции. Вывод идёт в UART — не оставляйте UART включённым в рабочей среде, он жрёт ток.

Интерактивный Zephyr shell позволяет вручную запускать bt advertise on, bt gatt discover и bt gatt read через последовательный порт. Это бесценно для быстрой проверки гипотез без перепрошивки.

Для анализа радиоэфира используйте nRF Sniffer для Bluetooth LE — прошивка для nRF52840 DK, которая вместе с Wireshark показывает каждый пакет в эфире: advertising PDU, connection events, pairing exchange. Это окончательный инструмент, когда подозреваете проблему на уровне протокола.

Часто задаваемые вопросы

Выводы

Zephyr OS превращает разработку BLE-устройств из работы с чёрными ящиками в инженерную дисциплину. Полный открытый стек, сертификация Bluetooth SIG, поддержка 600+ плат и активное сообщество делают его одной из сильнейших платформ для IoT.

Мы прошли путь от простого beacon до полноценного sensor node с notifications, управлением соединениями и проверкой входных данных. Этих паттернов — advertising, GATT-обработчики, CCCD, подсчёт ссылок на соединение — достаточно, чтобы построить практически любое BLE-периферийное устройство.

Следующий шаг — взять реальное железо, реальный датчик и собрать устройство, которое решает вашу задачу. Термометр для теплицы, беспроводная кнопка для умного дома, трекер для велосипеда — всё это становится доступным после освоения базовых паттернов.

Главный способ понять BLE — не читать спецификацию, а заставить мигать LED со смартфона. Когда это получится, остальное пойдёт быстро.

Источники:

How to Build Bluetooth Applications with Zephyr OS: A Handbook for Devs — freeCodeCamp.

Zephyr Bluetooth Stack Documentation — официальная документация.

Bluetooth SIG Specifications — спецификации протоколов и профилей.

• Wake-on-LAN — сетевой протокол для удалённого включения компьютера через Magic Packet.
• Magic Packet: 6 байт 0xFF + MAC-адрес, повторённый 16 раз.
• Пакет отправляется по UDP на широковещательный адрес 255.255.255.255, де-факто стандарт — порт 9.
• Ограничения: только в пределах одной сети или VLAN, только по Ethernet, нет подтверждения доставки.
• Реализуем собственный WOL-инструмент на Go с нуля.

Что такое Wake-on-LAN

Wake-on-LAN (WOL) — протокол канального уровня, который будит компьютер или сервер, когда сетевой интерфейс получает специальный Magic Packet. Сетевая карта с активированной функцией WOL постоянно прослушивает широковещательный трафик даже когда компьютер выключен, но подключён к сети. При обнаружении Magic Packet она посылает сигнал на BIOS, и система загружается.

Для работы WOL необходимо, во-первых, включить поддержку в BIOS или UEFI (обычно называется Wake-on-LAN или Power On by PCI-E); во-вторых, активировать её в операционной системе для нужного сетевого адаптера. На Linux это делается одной командой:

Здесь g — режим MagicPacket. Проверить текущее состояние — ethtool eth0 | grep Wake. На Windows нужную опцию ищите в «Свойства сетевого адаптера → Управление электропитанием → Разрешить этому устройству выводить компьютер из ждущего режима».

Как устроен Magic Packet

Magic Packet — бинарный фрейм с жёстко заданной структурой. Сначала идёт синхропоследовательность: 6 байт 0xFF. Эти байты сигнализируют сетевой карте о начале нового фрейма.

Сразу после синхропоследовательности — MAC-адрес целевой машины, повторённый 16 раз без пробелов и разделителей. Именно по нему сетевая карта понимает, что пакет адресован ей. В итоге Magic Packet занимает 102 байта: 6 байт синхропоследовательности плюс 6 байт MAC × 16 повторений.

Пример реального Magic Packet с MAC-адресом 12:34:56:78:9a:bc, захваченного в Wireshark:

Некоторые реализации WOL поддерживают опциональный пароль в конце пакета — для защиты от несанкционированного включения. Механизм SecureOn использует 6 байт, AMD-спецификация допускает 4 байта. Однако не каждый BIOS поддерживает эту функцию.

Как отправить Magic Packet

Magic Packet может быть передан поверх любого сетевого протокола — сетевой карте достаточно найти нужную последовательность байт в полученном фрейме. На практике пакет отправляют как UDP-датаграмму на широковещательный адрес.

Для IPv4 используется широковещательный адрес 255.255.255.255 — он охватывает всю локальную сеть или сегмент. IPv6 вместо broadcast использует multicast. Де-факто стандарт для порта назначения — 9 (Discard Protocol), реже используют 7 или 0.

Ограничения Wake-on-LAN

Прежде чем настраивать WOL в продакшне, важно понять его ограничения:

• Только одна сеть или VLAN. Magic Packet не маршрутизируется — получить его может лишь устройство в той же локальной сети или VLAN, что и отправитель. Для удалённого включения через интернет нужен промежуточный узел в этой сети: VPN, Raspberry Pi или роутер с поддержкой WOL.
• Нужен MAC-адрес. WOL работает на канальном уровне, поэтому нельзя разбудить компьютер, зная только его IP-адрес.
• Только проводной Ethernet. Большинство Wi-Fi-адаптеров не поддерживают WOL. Исключение — устройства с поддержкой стандарта WoWLAN (Wake on Wireless LAN), но на практике их мало, и настройка требует совместимого драйвера.
• Нет подтверждения доставки. UDP — протокол без установления соединения, поэтому после отправки Magic Packet невозможно узнать, получил ли его компьютер и включился ли он.
• Зависимость от BIOS. Некоторые материнские платы пробуждаются только из состояний S3 или S4, но не из полного выключения S5. Проверяйте документацию к платформе.

Реализация на Go

Напишем собственный WOL-инструмент на Go — одна из немногих задач, где стандартной библиотеки хватает полностью. Если хочется погрузиться в Go глубже, у нас есть обзор Golang-фреймворков 2026 года. Нам понадобятся две функции: CreateMagicPacket для формирования пакета и SendMagicPacket для его отправки.

CreateMagicPacket: формируем пакет

Функция принимает MAC-адрес строкой и возвращает готовый байтовый срез или ошибку. Первым делом проверяем валидность MAC-адреса с помощью регулярного выражения:

После валидации убираем разделители из MAC-адреса, затем повторяем его 16 раз:

Объединяем синхропоследовательность с повторённым MAC-адресом и декодируем hex-строку в байтовый срез:

SendMagicPacket: отправляем пакет

Функция принимает Magic Packet ([]byte), IP-адрес назначения и порт. Сначала проверяем валидность IP через стандартную функцию net.ParseIP — в отличие от regex, она корректно обрабатывает и IPv4, и IPv6:

Открываем UDP-соединение через net.Dial. WOL не требует установления соединения — UDP идеально подходит: быстро, без handshake. Ключевое слово defer гарантирует закрытие соединения по завершении функции:

Отправляем Magic Packet в сеть через conn.Write. Если функция возвращает nil — пакет ушёл в сеть. Получил ли его компьютер и включился ли — WOL не сообщает, это ограничение протокола:

Полный рабочий код обеих функций и готовую утилиту командной строки можно найти на GitHub: xaner4/Gowakeup. Типичный вызов после сборки — ./gowakeup -mac AA:BB:CC:DD:EE:FF.

Выводы

Wake-on-LAN — простой и элегантный протокол канального уровня. Всего 102 байта — и компьютер включается по сети без дополнительной инфраструктуры. Ограничения (только Ethernet, только локальная сеть, нет подтверждения) — следствие намеренной простоты протокола: он работает даже тогда, когда ОС не загружена. В отличие от устаревших сетевых стеков, которые ядро Linux постепенно отбрасывает, WOL остаётся в строю уже третье десятилетие.

Реализация на Go показывает, как стандартная библиотека net и базовые операции со строками позволяют собрать рабочий сетевой инструмент в нескольких десятках строк. Готовый проект: github.com/xaner4/Gowakeup. Исходная статья: blog.xaner.dev.

В этой статье разберём весь путь письма — от SMTP-команд до проверки подлинности через DKIM, SPF и DMARC. Покажем на конкретном примере: Джон (john@gmail.com) отправляет письмо Кевину (kevin@yahoo.com).

— Письмо передаётся между серверами по протоколу SMTP (порт 25) через простые текстовые команды

— Почтовый сервер находит адресата через DNS-запрос MX-записи домена получателя

— Подлинность отправителя проверяется тремя механизмами: DKIM (цифровая подпись), SPF (проверка IP) и DMARC (политика при сбоях)

— Получатель забирает письма из ящика через IMAP или POP3 — это отдельные протоколы

Базовая терминология

Прежде чем разбирать процесс, познакомимся с ключевыми терминами:

• SMTP (Simple Mail Transfer Protocol) — протокол передачи почты, работающий поверх TCP. Используется для отправки и доставки писем между серверами
• Почтовый сервер (Mail Server) — серверное приложение, которое принимает, хранит, проверяет и доставляет электронные письма
• MX-запись (Mail Exchange Record) — DNS-запись, содержащая доменное имя почтового сервера для данного домена
• MTA (Mail Transfer Agent) — компонент сервера, отвечающий за передачу писем между серверами (например, с сервера Gmail на сервер Yahoo)
• DKIM (DomainKeys Identified Mail) — механизм аутентификации на основе цифровой подписи
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) — политика, определяющая действия при сбое аутентификации
• SPF (Sender Policy Framework) — метод аутентификации, проверяющий, имеет ли IP-адрес отправителя право отправлять почту от имени домена

Не страшно, если не всё понятно сразу — каждый термин подробно разобран ниже.

Общая картина: как письмо проходит путь от отправителя к получателю

Этот раздел — краткий обзор всего процесса. Детали каждого шага разобраны дальше.

Почтовый сервер — это серверное ПО, которое принимает, ставит в очередь, отправляет и получает письма. Если вы шлёте письмо с john@gmail.com на kevin@yahoo.com, сервер Gmail примет письмо и передаст его серверу Yahoo.

Допустим, есть два друга:

• Джон (john@gmail.com)
• Кевин (kevin@yahoo.com)

Почему Yahoo? Потому что получатель использует Yahoo (kevin@yahoo.com).

Дальше всё берёт на себя сервер Yahoo Mail, и письмо попадает во входящие Кевина.

Архитектурная диаграмма

Разбор по шагам

Теперь разберём каждый этап подробно. Стоит отметить, что описан наиболее распространённый сценарий работы почтовых серверов. У разных компаний реализация может отличаться, но базовая идея одна и та же.

SMTP: как письмо попадает на сервер

Simple Mail Transfer Protocol определяет, как письмо передаётся на почтовый сервер. Для передачи почты между серверами SMTP использует порт 25. Для отправки от клиента к серверу (submission) применяются порты 587 (STARTTLS) или 465 (implicit TLS). Подключиться к серверу можно через утилиту telnet. Вот что вы увидите при подключении к серверу Gmail:

После подключения мы можем отправлять серверу команды:

HELO / EHLO

Команда для приветствия — вы представляетесь почтовому серверу. В ответ сервер отправляет приветствие:

MAIL FROM

Сообщает серверу, кто отправляет письмо. Сервер отвечает 250 2.1.0 OK:

RCPT TO

Указывает, кому адресовано письмо. Сервер снова отвечает OK:

DATA

Сервер сообщает клиенту, что можно начинать передачу тела письма:

Затем отправляются данные самого письма:

Точка (.) на отдельной строке означает «конец сообщения». Сервер отвечает подтверждением (Accepted):

QUIT

Прощаемся с сервером:

Вот так письмо передаётся на почтовый сервер по протоколу SMTP. Теперь разберём, что происходит дальше.

Хранение

Письмо теперь хранится на сервере Gmail, и сервер извлекает из него метаданные: FROM, TO и другие заголовки.

Некоторые почтовые серверы хранят письма прямо в файловой системе, другие используют распределённые объектные хранилища вроде AWS S3.

Очередь

Обратите внимание: когда SMTP-сервер принял наше письмо, он ответил «queued» (поставлено в очередь), а не «sent» (отправлено). Письма поступают в огромных объёмах, и отправить их мгновенно невозможно. Поэтому почтовые серверы ставят их в очередь и отправляют по одному. В случае ошибки письмо может быть перемещено в очередь повторных попыток.

DNS и DNS-записи

Для отправки писем нужно доменное имя (часть после @ в адресе). В конечном счёте любой сервер — это IP-адрес, но запоминать IP неудобно. Для этого и существует DNS.

DNS (Domain Name System) преобразует доменные имена (например, gmail.com) в IP-адреса. Именно поэтому можно подключиться и через telnet <ДОМЕН>, и через telnet <IP>.

DNS-запись — это запись, опубликованная в системе доменных имён, содержащая данные, видимые из интернета. Запомните это — DNS-записи играют ключевую роль в аутентификации email.

MX-запись

Ранее мы говорили, что почтовые серверы передают письма друг другу через SMTP-соединение на порту 25. Но как серверы узнают, на какой IP-адрес или домен отправлять письмо?

Здесь на сцену выходит MX-запись (Mail Exchange). Каждый домен публикует MX-запись в DNS, и другие почтовые серверы запрашивают её. Проверить MX-запись любого домена можно, например, на MXToolbox.

Вот MX-записи почтовых серверов Gmail:

Аутентификация

Мы только что поставили письмо в очередь на почтовом сервере — и для этого не потребовалось никакой аутентификации. Так как же работает проверка подлинности? Здесь в игру вступают DKIM и SPF.

DKIM: цифровая подпись письма

DKIM — это механизм аутентификации на основе пары открытого и закрытого ключей. Отправляющий сервер подписывает письмо, а принимающий — проверяет подпись. В нашем случае отправитель — сервер Gmail, получатель — сервер Yahoo.

1. Письмо поступает на Gmail через SMTP
2. Gmail сохраняет его
3. Gmail вычисляет хеш заголовков и тела письма, подписывает его закрытым ключом и добавляет заголовок DKIM-Signature
4. Когда письмо доставляется на сервер-получатель, тот расшифровывает подпись открытым ключом, вычисляет хеш самостоятельно и сравнивает результаты
5. Если проверка не пройдена — письмо не доставляется

Вот как выглядит заголовок DKIM-Signature:

Но откуда получатель знает открытый ключ отправителя?

Снова на помощь приходят DNS-записи. Домен отправителя (gmail.com в нашем примере) публикует DNS-запись с открытым ключом и селектором. Селектор нужен для выбора нужного ключа, если у сервера их несколько.

Вот как выглядит DNS-запись с публичным ключом DKIM:

Таким образом, сервер Yahoo запрашивает DNS-записи для gmail.com и получает открытый ключ для проверки подписи.

SPF: проверка IP-адреса отправителя

Эта проверка происходит на стороне получателя. SPF определяет, имеет ли данный IP-адрес право отправлять почту от имени домена.

Когда Gmail передаёт письмо john@gmail.com на kevin@yahoo.com, он открывает SMTP-соединение с сервером Yahoo. В этот момент Yahoo знает, с какого IP пришло соединение (это IP сервера Gmail).

Yahoo извлекает домен отправителя (gmail.com) из заголовка MAIL FROM и запрашивает DNS-запись SPF, которая выглядит так:

В записи перечислены IP-адреса. Если IP, с которого пришло письмо, присутствует в этом списке — письмо принимается. Если нет — отклоняется или помечается как спам.

DMARC: что делать, если проверка не пройдена

DMARC — это не метод аутентификации, а политика, которая определяет, что делать, если DKIM или SPF не прошли проверку.

Проверка выполняется на сервере-получателе по тому же принципу: запрашивается DNS-запись DMARC домена отправителя, и на основе политики письмо либо отклоняется, либо помечается как спам.

Финальный этап: доставка

Если все проверки пройдены, сервер Yahoo Mail сохраняет письмо в хранилище — будь то файловая система или распределённое хранилище. Письмо попадает во входящие Кевина.

Как мы видим письма?

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

• IMAP — синхронизация почтового ящика (письма остаются на сервере)
• POP3 — загрузка писем на устройство

Эти протоколы — тема для отдельной статьи.

Перевод и адаптация статьи «How Email Actually Works» из блога Sushant Dhiman. Читайте также: DNS для начинающих, как работает интернет.

Правительство США анонсировало политику, фактически запрещающую импорт новых потребительских роутеров. Но оказывается, роутер можно собрать буквально из любого компьютера. Автор оригинальной статьи использует мини-ПК на Linux в качестве домашнего роутера уже несколько лет: ни одного серьёзного сбоя, единственная замена — дешёвый mSATA-диск.

Мини-ПК, настольный компьютер, одноплатник, стоечный сервер, старый ноутбук — подойдёт всё, что запускает Linux и имеет пару USB-портов. В этой статье разберём полную настройку на Debian: от выбора железа до правил firewall.

— Роутер — это обычный компьютер с Linux, двумя сетевыми интерфейсами и несколькими пакетами.

— Для сборки хватит мини-ПК, старого ноутбука или одноплатника с USB-Ethernet-адаптером.

— Всё ПО — hostapd, dnsmasq, bridge-utils — входит в стандартные репозитории Debian.

— Настройка занимает около часа и не требует глубоких знаний сетей.

Выбор железа

Идеальный вариант — компактный пассивно охлаждаемый мини-ПК. Однако подойдёт практически что угодно. Главное условие: два Ethernet-интерфейса. Если у устройства только один — выручит обычный USB-Ethernet-адаптер. Это чуть менее надёжно, чем встроенный порт, но для домашней сети вполне достаточно.

Пример из практики автора: мини-ПК на Celeron 3205U (два ядра, 1,5 ГГц) без проблем выдаёт 820–850 Мбит/с по кабелю и около 300 Мбит/с по Wi-Fi. Даже такой скромный процессор с запасом тянет трафик целого дома или небольшого офиса.

Для совсем экстремальных случаев: в 2016 году автор собрал роутер из ThinkPad T60 (подобранного на мусорке), ExpressCard-PCIe-моста, безымянной Ethernet-карты и свитча Cisco 2960 за $10. Выглядело как куча хлама — но работало.

Архитектура сети

После настройки интерфейсы распределяются так: eth0 — WAN (внешняя сеть, интернет), eth1 — проводная LAN, wlan0 — Wi-Fi LAN.

eth1 и wlan0 объединяются в мост br0 — проводные и беспроводные устройства оказываются в одной сети. Нужно больше портов? Просто добавьте USB-Ethernet-адаптеры и включите их в мост.

Используемое ПО: hostapd для Wi-Fi точки доступа, dnsmasq для DHCP и DNS, bridge-utils для объединения портов. Статья покрывает только IPv4 — IPv6 в домашней LAN по-прежнему создаёт больше проблем, чем решает.

Установка Debian

Установка стандартная, но стоит учесть несколько нюансов:

• В BIOS отключить PXE-загрузку по сети
• Выставить минимальную частоту процессора, но отключить power management для USB и PCI-устройств
• Включить опцию «Restore after AC Power Loss» — роутер должен запускаться сам после отключения питания
• Если устройство не стартует без монитора — вставить HDMI-заглушку (dummy dongle)
• Включить репозиторий non-free-firmware — большинство Wi-Fi-адаптеров без него не работает

После базовой установки доставьте прошивку для своего Wi-Fi-адаптера. Для Intel:

Для Realtek:

Для совсем старого железа (Atheros и подобные):

Установка пакетов

Три пакета — это всё необходимое. Итого около 250 пакетов на системе:

Переименование сетевых интерфейсов

В современном Linux интерфейсы называются по физическому расположению: например, enp0s31f6. Чтобы не запутаться, зафиксируем привычные имена eth0, eth1 через systemd.network.

Для каждого сетевого интерфейса создайте файл /etc/systemd/network/10-persistent-ethX.link (где X — номер интерфейса):

MAC-адреса своих интерфейсов узнайте командой ip link show. Создайте по одному такому файлу для каждого Ethernet-порта.

Настройка Wi-Fi через hostapd

USB-Wi-Fi-адаптер будет работать как точка доступа. Это не заменит выделенный AP-девайс по качеству сигнала, но в небольшом помещении работает вполне приемлемо. Если Wi-Fi критичен — лучше подключить к LAN-порту старый роутер в режиме точки доступа.

Создайте конфиг /etc/hostapd/hostapd.conf:

По умолчанию служба hostapd замаскирована (masked). Размаскируйте и запустите:

Настройка сетевых интерфейсов

eth0 — внешний интерфейс (WAN, получает IP по DHCP от провайдера). br0 — внутренний мост с фиксированным адресом. Обратите внимание: у LAN-интерфейса нет шлюза по умолчанию.

Файл /etc/network/interfaces:

После этого перезагрузите устройство. Если сеть не поднялась, проверьте ошибки:

При успешной настройке вывод команды должен быть таким:

IP Forwarding

Без IP forwarding роутер не будет пробрасывать пакеты между интерфейсами. Создайте файл /etc/sysctl.d/10-forward.conf:

Примените изменения:

Настройка firewall через nftables

Правила firewall и NAT управляются через nftables — современную замену iptables. Конфиг /etc/nftables.conf:

Этот конфиг делает три вещи: включает NAT (masquerade), блокирует весь входящий трафик извне и разрешает роутеру работать как DNS, DHCP и SSH-сервер для локальной сети.

Включите nftables при загрузке:

Перед изменением правил всегда проверяйте конфиг на валидность:

В отличие от устаревшего iptables, nftables позволяет перезагружать правила без разрыва соединений:

DHCP и DNS через dnsmasq

dnsmasq — компактная альтернатива паре isc-dhcp-server + bind9. Конфиг элементарный. Создайте /etc/dnsmasq.conf:

DHCP-диапазон: 192.168.1.50 — 192.168.1.250, аренда на 6 часов. Адреса 192.168.1.2 — 192.168.1.49 остаются для статических назначений.

Бонус: последовательный порт (Serial/UART)

Если на устройстве есть последовательный порт — настройте UART-консоль. В enterprise-оборудовании это стандарт, но для домашнего роутера тоже удобно: управляйте без монитора и клавиатуры через USB-UART-адаптер.

В файле /etc/default/grub добавьте или замените строки:

Активируйте getty на последовательном порту, обновите GRUB и перезагрузите:

Проверка работы

После настройки перезагрузите устройство дважды — убедитесь, что всё поднимается стабильно. Проверьте состояние firewall и счётчики трафика:

Ненулевые счётчики в цепочках forward и postrouting означают, что трафик проходит через роутер. Проверьте DHCP-аренды:

Что ещё можно добавить

Базовая конфигурация работает как полноценный домашний роутер. При желании её можно расширить:

• VLAN и сегментация сети
• VPN (удалённый доступ и site-to-site туннели)
• Динамическая маршрутизация: IGP, BGP
• IDS/IPS (обнаружение и предотвращение вторжений)
• Логирование отдельных правил и flow logs
• Проброс портов в DMZ
• IPv6
• Мониторинг в реальном времени
• Фильтрация и блокировка трафика

Важное правило: не устанавливайте много дополнительного ПО прямо на роутер. Лучше выделить отдельную машину в DMZ или VLAN и пробрасывать на неё трафик. Роутер должен оставаться простым и надёжным.

Итого

Роутер — это просто компьютер с Linux, двумя сетевыми интерфейсами и тремя пакетами. Ничего магического в потребительских роутерах нет: они тоже работают под управлением Linux (обычно урезанным), просто с удобным веб-интерфейсом поверх.

Мини-ПК на базе Celeron или Atom стоит $30–60 на вторичном рынке, потребляет 5–10 Вт и работает годами без обслуживания. Это надёжнее, гибче и дешевле большинства потребительских роутеров — а заодно отличный способ разобраться, как на самом деле работает сеть.

Базовые требования StarRocks к конфигурации серверов невысоки: даже в тестовой среде с CPU 2 ядра и 4 ГБ ОЗУ можно выполнять запросы по небольшим объемам данных.

В производственной среде или когда важна производительность, рекомендуемые аппаратные конфигурации для различных инстансов StarRocks следующие:

• FE — 8 ядер CPU, 16 ГБ ОЗУ, сетевой адаптер 10GbE (10‑гигабитный Ethernet) и выше (при невысоком уровне одновременных запросов FE можно совместно размещать с BE на одном узле).
• BE — 16 ядер CPU, 64 ГБ ОЗУ, сетевой адаптер 10GbE и выше; CPU должен поддерживать набор инструкций AVX2.
• Broker — специальных требований нет; обычно совместно размещается с BE, число Broker‑узлов соответствует числу BE.

Чтобы обеспечить высокую производительность кластера и безопасность данных, в продакшене рекомендуется использовать минимум три сервера с 16 ядрами CPU, 32 ГБ ОЗУ и 10GbE.

Предположим, что node01, node02 и node03 — сервера, удовлетворяющие требованиям. Минимальный пример архитектуры развертывания в продакшене:

• На node01 разворачивается один FE в роли Leader.
• На node02 разворачивается один FE Observer для резервирования метаданных.
• На каждом из трех узлов кластера разворачивается по одному BE, что обеспечивает хранение с тремя репликами по умолчанию в StarRocks (в тестовой среде можно использовать одну реплику).

На node01 также можно установить mysql-client. StarRocks совместим с протоколом MySQL; рекомендуется использовать mysql-client для доступа, также можно применять графические инструменты, такие как SQLyog, DBeaver, Navicat, DataGrip, подключая StarRocks как MySQL.

Особое внимание:

• На одной машине можно развернуть только один FE‑инстанс данного кластера, поскольку все FE‑инстансы в одном кластере должны иметь одинаковый http_port.
• Хотя на одной машине можно развернуть несколько BE‑инстансов на разных портах, для обеспечения трех реплик данных необходимо как минимум три машины с по одному BE‑инстансу на каждой. Это связано с тем, что стратегия балансировки реплик в StarRocks не размещает реплики одного и того же Tablet на BE с одинаковым IP.

Проверки и подготовка среды кластера

После того как вы ознакомились с аппаратными требованиями кластера StarRocks, необходимо выполнить обязательные проверки окружения серверов кластера и системную оптимизацию. Подготовку среды выполнения StarRocks условно можно разделить на две категории: «обязательная» и «оптимизационная».

Перед развертыванием кластера рекомендуется выполнить все перечисленные ниже шаги (с учетом вашей ситуации), поскольку параметры из категории «оптимизационных» также влияют на производительность StarRocks.

Обязательная подготовка

Проверка CPU

Векторизация StarRocks требует поддержки набора инструкций AVX2 на CPU, поэтому CPU на машинах с BE‑сервисом должен поддерживать AVX2. В Linux проверьте поддержку CPU следующим образом:

Наличие вывода означает поддержку AVX2 CPU. Если вывода нет, потребуется машина с поддержкой AVX2.

В некоторых случаях используется виртуальная машина с CentOS в среде Windows для тестов; тогда можно проверить поддержку набора инструкций CPU на хосте Windows с помощью CPU‑Z, AIDA64 и т. п.

Проверка операционной системы

StarRocks требует Linux CentOS версии 7 и выше (ниже показано на примере CentOS 7.6). Версия ядра рекомендуется 3.10 и выше. Просмотр информации о системе и ядре:

Настройка IP сервера

При развертывании FE или BE, чтобы избежать проблем выбора IP на серверах с несколькими сетевыми интерфейсами, используйте параметр priority_networks в конфигурации каждого инстанса для привязки IP.

Кроме того, при работе StarRocks сведения о привязанных IP инстансов кластера и др. сохраняются в локальном каталоге. Если внутренний IP узла изменится, инстансы кластера не смогут корректно работать (или потребуется сложное восстановление метаданных). Поэтому внутренний IP сервера, на котором работает StarRocks, должен быть фиксированным.

Операции по настройке фиксированного IP в системе сервера см. в Приложении 1: Настройка фиксированного IP.

Синхронизация времени в кластере

Максимально допустимое расхождение часов между серверами с FE — 5 секунд. Можно использовать протокол NTP для синхронизации времени по сети или выполнить внутреннюю синхронизацию в кластере. Подробные операции см. в Приложении 2: Синхронизация времени в кластере.

Изменение лимита на количество открытых файлов

Если лимит на количество открытых файлов слишком мал, BE‑инстанс может не запуститься. Проверьте лимит:

Если возвращаемое значение < 65535, измените /etc/security/limits.conf

Добавьте в конец файла (для всех пользователей и групп мягкий и жесткий лимиты на число открытых файлов — 65535):

После изменения необходимо разорвать и заново установить удаленное подключение (например, Xshell), чтобы изменения вступили в силу, либо временно задать лимит повторно:

Подтвердите применение:

Проверка часового пояса

Чтобы избежать смещения времени при импорте данных с метками времени, установите системный часовой пояс Asia/Shanghai. Просмотр часового пояса:

Если часовой пояс отличается от Asia/Shanghai, выполните:

Настройка брандмауэра

Чтобы обеспечить нормальное взаимодействие между узлами кластера, в зависимости от ситуации выберите одно из двух: отключить внутренний брандмауэр или открыть в нем порты, необходимые для работы инстансов кластера. Ниже представлены два варианта (a или b):

a) Отключить службу firewalld (брандмауэр)

Проверьте, что служба отключена:

Отключите автозапуск:

b) Открыть порты во внутреннем сегменте брандмауэра

Инстансы StarRocks по умолчанию используют порты: 8000, 8030, 8040, 8060, 9010, 9020, 9030, 9050, 9060. Если эти порты не конфликтуют с другими сервисами на сервере, обычно не рекомендуется их изменять.

Например, для FE при необходимости изменения портов до развертывания можно отредактировать файл конфигурации

Открытие стандартных портов в службе firewalld (брандмауэр):

Просмотр открытых портов:

Обратите внимание: перечисленные выше порты относятся к внутренним (для взаимодействия внутри кластера), а не к портам, открытым для доступа из внешней сети. В производственной среде для внешнего доступа обычно достаточно открыть два порта:

• FE http_port: по умолчанию 8030
• FE query_port: по умолчанию 9030

Подробное описание портов см. в Приложении 3: Порты StarRocks.

Установка JDK

StarRocks зависит от среды JDK 1.8+. Можно использовать Oracle JDK 1.8+ или OpenJDK 8+ (ниже показан пример с OpenJDK 1.8.0_41):

Инструкции по установке OpenJDK 8 см. в Приложении 4: Установка OpenJDK.

Установка mysql-client

StarRocks использует протокол MySQL для взаимодействия; пользователи могут подключаться к кластеру StarRocks через клиент MySQL (mysql-client). Выбирая версию mysql-client, используйте версию новее 5.1, поскольку версии до 5.1 не поддерживают имена пользователей длиннее 16 символов (ниже показан пример mysql-client‑5.7.35).

Для удобства развертывания и эксплуатации кластера обычно рекомендуется установить mysql-client на одном из серверов кластера. Разумеется, можно не устанавливать mysql-client, а получить доступ к StarRocks с помощью внешних графических инструментов, таких как SQLyog, DBeaver, Navicat и др.

Инструкции по установке mysql-client‑5.7.35 см. в Приложении 5: Установка mysql-client‑5.7.35.

Оптимизационная подготовка

Отключение SELinux

Если в вашей продакшен‑среде уже применены меры безопасности (например, VPN, jump‑host, bastion и т. п.), рекомендуется отключить SELinux. Проверьте состояние:

Чтобы избежать перезагрузки, можно сначала временно отключить, затем — отключить навсегда.

Временное отключение:

Постоянное отключение:

Проверка:

означает, что отключено навсегда:

Использование overcommit

Рекомендуется включить overcommit, установив 1, что означает: ядро разрешает выделять всю физическую память независимо от текущего состояния памяти.

Настройка выше сбрасывается после перезагрузки системы; для постоянного применения выполните:

Не использовать область подкачки (swap)

Это устраняет влияние перехода в область подкачки на производительность. Чтобы избежать перезагрузки, можно сначала временно, затем — постоянно.

Проверка текущего значения:

Временная настройка:

Постоянная настройка:

Отключение прозрачных больших страниц (Transparent Huge Pages, THP)

Проверьте настройки и состояние THP:

Вывод [always] означает, что THP включены; [never]— что THP отключены; [madvise]— что THP используются только для VMA с флагом MADV_HUGEPAGE.

Временное отключение:

Постоянное отключение (добавьте команды временного отключения в /etc/rc.d/rc.localи назначьте права на исполнение):

Проверка:

Настройки очереди буферов TCP‑подключений

1. tcp_abort_on_overflow:

2. somaxconn:

Эти настройки сбрасываются после перезагрузки; чтобы применялись постоянно, добавьте их в /etc/rc.d/rc.local:

Повторная проверка:

Настройка максимального числа пользовательских процессов

Временная установка:

Постоянная установка:

Добавьте в конец файла и сохраните:

Настройки для высокой конкурентности

Если в кластере высокая конкурентность нагрузки, рекомендуется добавить следующие настройки:

Чтобы эти настройки применялись постоянно, добавьте их в /etc/rc.d/rc.local , как указано выше.

Приложение 1: Настройка фиксированного IP на сервере

Обычно инженеры эксплуатации предоставляют серверы уже с привязанным IP. Для удобства локального тестирования ниже приведен пример привязки IP в виртуальной машине.

Перед настройкой IP обратите внимание, в каком режиме настроен сетевой адаптер ВМ: «bridged» или «NAT». Упрощенно: в режиме bridged систему ВМ могут видеть другие машины в той же локальной сети; в режиме NAT — только хост‑машина, где установлена ВМ. Поэтому при настройке IP учитывайте различия в шлюзе.

Например, для одиночного развертывания на сервере starrocks текущий шлюз —192.168.110.1 .Нужно привязать IP:192.168.110.98. Действия:

Измененные или добавленные параметры:

После изменений перезапустите сетевой сервис:

Просмотр IP:

Или (в минимальной установке

по умолчанию отсутствует):

Приложение 2: Синхронизация времени в кластере

Распространены два способа: синхронизация через интернет и внутренняя синхронизация в кластере. В продакшене достаточно выбрать один из них.

Синхронизация через интернет (под root)

В среде с доступом во внешнюю сеть можно установить NTP‑службу, чтобы каждая машина в кластере синхронизировалась с интернет‑временем.

(1) Установка пакета NTP:

(2) Выполнение синхронизации:

(3) Добавление cron‑задания:

Добавьте строку:

(означает автоматическую синхронизацию каждые 2 часа; формат: минута, час, день, месяц, день недели)

(4) Перезагрузка службы crond:

Внутренняя синхронизация в кластере (под root)

В внутренней сети можно выбрать одну машину в кластере в качестве сервера времени, а остальные машины периодически синхронизировать с ней. При таком подходе время в кластере может не совпадать с эталоном, но внутри кластера будет согласованным.

(1) Настройки на всех узлах

Проверьте, установлен ли ntp (если нет, установите:yum install -y ntp):

Проверьте статус ntpd:

Если статус не dead, остановите службу и отключите автозапуск:

(2) Настройка сервера времени

1. Выберите сервер времени, например node01, и отредактируйте конфигурацию NTP:

Изменения:

a) Разрешение для подсети (пример для диапазона 192.168.1.0–192.168.1.255):

Строку

раскомментируйте и укажите свою подсеть:

b) Отключение интернет‑источников времени (кластер в локальной сети):

Закомментируйте строки:

c) Добавление локального источника (при потере сети узел сможет служить сервером времени):

1. Измените файл /etc/sysconfig/ntpd:

Добавьте (синхронизировать аппаратное время с системным):

1. Запустите службу ntpd:

1. Включите автозапуск ntpd:

(3) Настройка остальных машин

Для всех узлов, кроме сервера времени, создайте cron‑задачу:

1. Настройте синхронизацию с сервером времени каждые 10 минут:

1. Добавьте задание:

1. Перезагрузите службу crond:

1. Тест (необязательно)

Измените время на любом узле, не являющемся сервером времени, и проверьте синхронизацию.

Например, на node02:

Подождите 10 минут (или временно измените интервал в cron на 1 минуту) и проверьте время:

Приложении 3: Порты StarRocks

Приложение 4: Установка OpenJDK

Способ 1: онлайн‑установка через yum

Проверьте, есть ли в системе среда Java:

При минимальной установке Java отсутствует. Если в текущей системе CentOS 7 есть пакеты OpenJDK и среди них присутствует java-1.8.0-openjdk-devel, значит, установлен Java 8 JDK, и можно сразу найти путь установки OpenJDK и настроить переменные окружения. Если openjdk-devel отсутствует, значит установлен только JRE. Например (пакеты, связанные с OpenJDK):

Официальная документация OpenJDK:

The java-1.8.0-openjdk package contains just the Java Runtime Environment. If you want to develop Java programs then install the java-1.8.0-openjdk-devel package.

Установка/обновление OpenJDK через yum:

Поиск пути установки OpenJDK:

Настройка переменных окружения (рекомендуемый способ): создайте файл/etc/profile.d/my_env.sh:

Добавьте переменные:

Сохраните и обновите окружение (или перезапустите окно Xshell):

Способ 2: офлайн‑установка

Если у кластера нет доступа во внешнюю сеть, используйте двоичный пакет OpenJDK для офлайн‑развертывания. Заранее скачайте OpenJDK 1.8.0_41‑b04.

Проверьте, установлен ли JRE, и при наличии удалите его.

Проверка:

Примеры выводов для наличия JRE см. выше.

Удаление предустановленного JRE:

Загрузите

в каталог /opt/software:

Распакуйте:

Переместите распакованный каталог в /usr/java/:

Настройка переменных окружения (рекомендуемый способ): создайте файл /etc/profile.d/my_env.sh:

Добавьте переменные:

Сохраните и обновите окружение (или перезапустите окно Xshell):

Приложение 5: Установка mysql-client‑5.7.35

Проверьте наличие mariadb:

Если установлен, удалите в соответствии с выводом:

Для mysql-client требуются три RPM‑пакета (адрес загрузки укажите по корпоративным источникам). Загрузите пакеты в каталог /opt/software:

Между тремя RPM есть зависимости; порядок установки:

1. mysql-community-common-5.7.35-1.el7.x86_64.rpm
2. mysql-community-libs-5.7.35-1.el7.x86_64.rpm
3. mysql-community-client-5.7.35-1.el7.x86_64.rpm

Установка:

В качестве примера используем сервер «starrocks (192.168.110.98)». После выполнения шагов из главы «Глава 1.2: Развертывание StarRocks — подготовка среды» приступаем к развертыванию одноузловой конфигурации.

Для удобства демонстрации подключаемся к серверу пользователем root через XShell. Архитектура одноузловой конфигурации:

Дизайн каталогов развертывания и данных (дальнейшие шаги строго следуют этому плану):

1. Получение бинарного пакета

Бинарные пакеты StarRocks доступны на официальном сайте.

В примере используем пакет StarRocks-1.19.2.tar.gz и загружаем его в каталог /opt/software:

2. Распаковка пакета

Структура распакованного пакета и краткие пояснения приведены в Приложении 1 (дерево каталогов пакета развертывания StarRocks).

3. Подготовка и размещение файлов развертывания

4. Развертывание экземпляра FE

Изменение конфигурации FE

Конфигурация по умолчанию обычно достаточна для запуска кластера; начинающим пользователям не рекомендуется менять много параметров. В тестовой среде для FE обратите внимание на три момента:

• Порты по умолчанию — чтобы исключить конфликты (обычно менять не требуется).
• Привязка IP-адреса — чтобы при наличии нескольких интерфейсов сервис корректно выбирал нужный адрес. Если не знакомы с нотацией CIDR, можно указать полный IP-адрес (алиасы не поддерживаются), например: priority_networks = 192.168.110.98, что эквивалентно priority_networks = 192.168.110.98/32.
• Каталог метаданных — по умолчанию fe/meta. Рекомендуется создать отдельный каталог и указать его в конфигурации.

Создадим каталог метаданных:

Внесем изменения по привязке IP-адреса и каталогу метаданных (строки с #— комментарии):

Сохраните конфигурацию.

Запуск FE

Примечание: скрипт остановки FE —

(запуск:

FE написан на Java. Проверьте процессы командой jps: если виден процессStarRocksFe, значит FE запущен.

При нештатном состоянии изучите журналы (логи) в каталоге FE; основной журнал — fe.log, журналы аудита запросов — fe.audit.log. Так как это первый запуск, если операции выполняются подозрительно долго, можно очистить каталог метаданных FE и повторить процедуру.

Доступ к FE

Подключимся к FE с помощью клиента MySQL (mysql-client). Порт для запросов FE по умолчанию — 9030; встроенный пользователь root, пароль по умолчанию пустой:

Проверка состояния FE

Если клиент MySQL успешно подключился к FE, это означает, что FE работает. Выполним проверку:

Если Alive = true, узел FE работает нормально.

Добавление экземпляров в кластер

Добавим BE и Broker в кластер. Строгой очередности между «запуском сервиса» и «добавлением сервиса в кластер» нет. Однако если запустить сервис заранее, до добавления экземпляра в кластер BE может писать предупреждения в журнал (например: Fail to get master client from cache). Поэтому удобно сначала полностью подготовить FE, затем добавить остальные экземпляры SQL-командами через клиент MySQL, и после этого по очереди развернуть и запустить их.

• Добавление BE (используется heartbeat_service_port BE, по умолчанию 9050):

• Добавление Broker: зададим имя, например hdfs_broker (используется broker_ipc_port, по умолчанию 8000):

Если при добавлении экземпляра допущена ошибка, можно удалить его и добавить снова.

• Удаление BE из кластера. Так как в примере только один экземпляр BE, можно удалить его «рисковой» командой dropp (специально двукратная «p»):

• Удаление Broker:

Завершим сеанс:

Развертывание экземпляра BE

Изменение конфигурации BE

В тестовой среде для BE обратите внимание на три момента:

• Порты по умолчанию — чтобы исключить конфликты (обычно менять не требуется).
• Привязка IP-адреса — чтобы при наличии нескольких интерфейсов сервис корректно выбирал нужный адрес (если не знакомы с CIDR, укажите полный IP-адрес).
• Каталог хранения данных — по умолчанию be/storage. Рекомендуется создать отдельный каталог и указать его в конфигурации.

Создадим каталог хранения данных:

Изменим конфигурацию (строки с # — комментарии):

Сохраните конфигурацию.

Запуск BE

Примечание: скрипт остановки BE — stop_be.sh (запуск: ./stop_be.sh).

BE написан на C++. Проверьте процессы с помощью ps: если виден процесс starrocks_be, значит BE запущен.

Проверка состояния BE

Снова подключимся к кластеру через клиент MySQL:

Проверим состояние BE:

Если Alive = true, BE работает нормально. Так как это первый запуск, при сложностях с быстрой диагностикой можно очистить каталог данных /opt/storage и перезапустить сервис.

Завершим сеанс:

Развертывание Broker

После развертывания FE и BE основные сервисы StarRocks готовы. Broker — промежуточный сервис интеграции StarRocks с внешними системами HDFS/объектным хранилищем. Если интеграция не нужна, Broker можно не развертывать. Broker является процессом без сохранения состояния (stateless) и может свободно запускаться и останавливаться без влияния на кластер.

Конфигурация Broker

Конфигурацию Broker обычно менять не требуется. В отличие от FE и BE, у Broker нет и не нужен параметр priority_networks. Сервис Broker по умолчанию привязан к адресу 0.0.0.0. При выполнении команды ADD BROKER (см. раздел 4.5) достаточно указать корректный IP-адрес узла Broker.

Запуск Broker

Примечание: скрипт остановки Broker — stop_broker.sh (запуск: ./stop_broker.sh).

Проверьте процессы Java: если виден BrokerBootstrap, значит Broker запущен.

Журналы Broker — в файле apache_hdfs_broker.log. При нештатном состоянии изучите их для диагностики.V

Проверка состояния Broker

Подключимся к кластеру через клиент MySQL:

Проверим состояние Broker:

Если Alive = true, Broker работает нормально.

Простой пример использования

Смена пароля пользователя root

Например, установим пароль root:

Создание базы и таблицы

Число реплик в StarRocks не может превышать число узлов BE. Так как в примере только один узел BE, при создании таблиц обязательно указывайте одну реплику.

Создадим базу данных:

Создадим таблицу customer без секционирования, распределенную по хэшу c_custkey на 10 бакетов, с одной репликой:

Вставка тестовых данных

Простой запрос

Использование графических инструментов

StarRocks совместим с протоколом MySQL. При подключении через графические инструменты его можно рассматривать как прямое подключение к MySQL. Например, в SQLyog укажите IP сервера, имя пользователя, пароль и порт (порт для запросов FE по умолчанию — 9030) — после чего подключайтесь.

Развертывание в Docker

Если у единственного сервера достаточно ресурсов (оперативная память, дисковое пространство и т. п.), можно развернуть несколько экземпляров FE/BE на одном узле с использованием Docker. Однако из-за конкуренции за ресурсы такой подход по-прежнему не рекомендуется для продуктивной среды.

Кроме запуска StarRocks в Docker-контейнерах, можно сохранить контейнер, подготовленный на шаге «Глава 1.2: подготовка среды», как образ и использовать его для ускоренного масштабирования кластера.

Контейнеризованное развертывание и эксплуатация в этой главе не рассматриваются. Отдельная документация опишет «развертывание в один клик» одноузлового StarRocks на базе Docker.

Приложение 1: дерево каталогов пакета развертывания StarRocks (частично)

RTMP — это протокол потоковой передачи данных, первоначально разработанный компанией Macromedia (позже приобретенной Adobe) для передачи аудио, видео и данных через Интернет. RTMP значительно вышел за рамки своего первоначального назначения (для Flash) и стал основой современной инфраструктуры потоковой передачи данных.

Краткая история создания RTMP протокола

RTMP появился в начале 2000-х годов. Однако протокол был проприетарным и закрытым, пока американский разработчик стриминговых решений Red5 не провел обратную разработку RTMP и не создал версию с открытым исходным кодом, демократизировав доступ к профессиональной технологии потоковой передачи.

На сегодняшний день в России RUTUBE и VK используют RTMP для получения видео прямых эфиров: на RUTUBE стрим запускается через OBS с указанием RTMP-адреса и ключа. В VK в публичном API доступен метод 'video.startStreaming', который возвращает RTMP-адрес и ключ потока для запуска трансляций в сообществах и на страницах.

Ключевые вехи:

2002: Macromedia представляет RTMP для приложений Flash.

2005: Adobe приобретает Macromedia и RTMP.

2005: Red5 релизит open-source медиа сервер.

2012: Adobe прекращает разработку Flash.

Как работает стриминг с RTMP сервером?

RTMP работает на архитектуре клиент-сервер, где программное обеспечение для потоковой передачи (например, OBS Studio) подключается к серверу RTMP для доставки контента в реальном времени. Протокол использует TCP для надежной передачи данных и обычно работает на порту 1935.

Вот основной рабочий процесс:

1. Запуск потока: кодировщик устанавливает соединение с сервером RTMP.
2. Процесс установления соединения: клиент и сервер обмениваются информацией для установления сеанса.
3. Стриминг данных: аудио, видео и метаданные отправляются в виде фрагментов в режиме реального времени.
4. Распределение: сервер обрабатывает и распределяет поток среди зрителей.

Ключевые компоненты потоковой передачи RTMP

• RTMP сервер: основная инфраструктура, которая принимает, обрабатывает и распределяет потоки.
• Кодировщик: программное обеспечение или оборудование, которое захватывает и сжимает аудио/видео для передачи. Популярные варианты включают OBS Studio, Wirecast и FFmpeg.
• Плеер: клиентское приложение, которое принимает и отображает содержимое потока.
• Интеграция с CDN: сети доставки контента работают с серверами RTMP для глобального распределения потоков с оптимальной производительностью.

Плюсы и минусы использования RTMP

Преимущества RTMP

1. Универсальная совместимость: поддерживается практически всеми платформами потоковой передачи.
2. Надёжность: передача на основе TCP обеспечивает целостность данных.
3. Зрелая экосистема: обширный набор инструментов и документация.
4. Низкая сложность: простая реализация и отладка.
5. Совместимость с брандмауэрами: хорошо работает в корпоративных сетях.

Ограничения, которые следует учитывать

1. Репутация задержки: часто RTMP сервер некорректно настроен, и контент передается с задержкой.
2. Оптимизация для мобильных устройств: менее оптимален для мобильного стриминга по сравнению с более новыми протоколами.
3. Поддержка браузеров: требует Flash или специальных проигрывателей для воспроизведения в веб-браузере.

Альтернативы RTMP протоколу в 2025

Отличия между RTMP и RTSP

RTMP и RTSP — это протоколы с низкой задержкой, но, как правило, они используются в совершенно разных случаях. RTMP популярен для прямых трансляций на таких платформах, как YouTube, а RTSP — стандарт для IP-камер и трансляций с дронов. RTSP использует RTP (Real-Time Protocol), что делает его более похожим на WebRTC в плане транспорта.

Еще одно ключевое отличие — поддержка кодеков: RTMP ограничен H.264, а RTSP поддерживает несколько кодеков, включая H.265. RTSP идеально подходит для прямых рабочих процессов между устройствами, а RTMP предлагает более широкую поддержку CDN и облачной трансляции.

Отличия между RTMP и протоколами на основе WebRTC

WHIP (WebRTC-HTTP Ingestion Protocol) представляет собой будущее потоковой передачи с ультранизкой задержкой. В отличие от TCP-основы RTMP, WHIP использует WebRTC для доставки с задержкой менее секунды.

Крупные платформы такие как Twitch и OBS Studio уже поддерживают WHIP.

Отличия между RTMP и SRT

SRT обеспечивает повышенную надежность в сложных сетевых условиях, что делает его идеальным для рабочих процессов, где качество не может быть поставлено под угрозу.

Отличия между RTMP и HLS

RTMP в основном используется для ввода, а HLS — исключительно для вывода (воспроизведения).

HLS редко используется для ввода, он предназначен для доставки. HLS сегментирует потоки на фрагменты и использует плейлисты, что приводит к высокой задержке, но обеспечивает массовую масштабируемость через CDN.

RTMP, напротив, предлагает более низкую задержку, но больше не поддерживается большинством CDN. Когда-то он использовался как для ввода, так и для воспроизведения в эпоху Flash, но эта роль перешла к WebRTC для доставки в реальном времени. Сегодня RTMP остается доминирующим протоколом для ввода, а HLS обеспечивает крупномасштабное воспроизведение по запросу.

Отличия между RTMP и RTMPS

RTMPS — это просто безопасная версия RTMP, использующая SSL/TLS для шифрования потока. Буква «S» означает «безопасный», что делает его вариантом RTMP с дополнительной защитой конфиденциальных данных. Оба протокола имеют одинаковую задержку и надежность. RTMPS часто требуется платформам, таким как Facebook* Live, для обеспечения безопасной передачи данных. Его настройка включает в себя HTTPS и использование действительных сертификатов. Если ваш поток содержит личную или конфиденциальную информацию, RTMPS — лучший выбор.

*Запрещён в РФ

Надеюсь, что вам была полезна эта статья. Если я что-то упустила, то напишите, пожалуйста, в комментарии.

Я изучила свыше 70 программ и отобрала 33 курса. В начале списка — десять самых сильных, затем тринадцать для углубления знаний в смежных направлениях и десять бесплатных вариантов. Для некоторых добавила действующие скидки и бонусы.

ТОП-10 лучших курсов для сетевых инженеров в 2026 году

1. Сетевой инженер от Нетологии — обучение с практикой и карьерной поддержкой.

2. Профессия Сетевой инженер от GeekBrains — тренинг с командными проектами и обратной связью экспертов.

3. Network Engineer. Professional от OTUS — подготовка для специалистов с опытом, с проектами и изучением кейсов.

4. Кибербезопасность и сетевые технологии от Компьютерной академии TOP — обучение построению и защите инфраструктуры с международной сертификацией.

5. Специализация Network Engineer от OTUS — двухступенчатая углубленная подготовка с практикой и проектами.

6. Сетевой инженер на базе решений компании Cisco Systems от Специалист.ру — экспресс-курс с интенсивной практикой на оборудовании Cisco.

7. Сетевой инженер от Учебного центра доп. образования ЭКОДПО — мини-тренинг по настройке экосистем и автоматизации.

8. Сетевой инженер от НЦПО — дистанционное образование с проверкой домашних заданий и госдипломом.

9. Сетевой инженер от АПОК — краткий курс без лишней теории, с содержанием, соответствующим требованиям индустрии.

10. Сетевой инженер от МИПК — переподготовка с акцентом на корпоративные сети и администрирование.

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

Онлайн-курсы для сетевого инженера с нуля

1. Сетевой инженер | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

Онлайн-курс для сетевого инженера с трудоустройством. Разработан архитектором O2XYGEN Data Center при поддержке инженеров Yandex Cloud. Подготовка сочетает теорию и задачи, приближенные к рабочим условиям: настройка оборудования, проектирование корпоративных экосистем. В процессе — 32 лабораторных задания и два крупных проекта. По ходу учебы студенты получают фидбэк от экспертов и обсуждают сложные моменты на вебинарах.

• Стоимость: от 3 366 руб./мес. в рассрочку на 2 года.
• Длительность: 13 месяцев.
• Формат обучения: вебинары, видеолекции, экспертные консультации, лабораторные и курсовые задания.
• Документ об образовании: свидетельство и диплом о профпереподготовке.

Кому подойдет: начинающим IT-специалистам, администраторам, разработчикам, техническим сотрудникам.

Преимущества:

• Практика на задачах, применимых в работе;
• Записи уроков доступны 3 года;
• Наставничество инженеров из отрасли;
• Гибкий график с возможностью паузы;
• Карьерное консультирование и подготовка к будущим собеседованиям;
• Материалы представлены в мобильной утилите;
• Бесплатный доступ к инструментам для выполнения практики.

Недостатки:

• Жесткое расписание вебинаров;
• Наличие устаревших материалов в отдельных темах.

Программа обучения:

• Коммутация, динамическая маршрутизация;
• Сетевая безопасность и QoS;
• Проектирование корпоративной сети;
• Учет трафика, аутентификация и авторизация;
• Инструменты эксплуатации, IP-телефония.

Ознакомиться с полной программой >>>

2. Профессия Сетевой инженер | GeekBrains

Курс по сетевым технологиям создан при участии специалистов из DevOps, администрирования, защиты информации и разработки. Много внимания уделено автоматизации процессов и специфике обслуживания оборудования. Материал подается через видеоуроки и самостоятельные задания в профессиональной среде, с регулярной обратной связью и живыми сессиями с экспертами. В конце тренинга формируется дипломный проект. Карьерная команда помогает подготовиться к собеседованиям и представить свои навыки работодателям.

• Стоимость: от 4 370 руб./мес. с разделением на 3 года.
• Длительность: до 12 месяцев.
• Формат обучения: онлайн, задания, командные проекты, вебинары, консультации.
• Документ об образовании: сертификат.

Кому подойдет: тем, кто планирует связать карьеру с сетями и управлением IT-инфраструктурой.

Преимущества:

• Преподаватели с опытом в индустрии;
• Наставничество и карьерная поддержка;
• Выбор и смена специализации после основного блока;
• Свыше 50 заданий;
• Практика на реальных инструментах;
• Доступ к интернет-библиотеке и другим интенсивам;
• Живые обсуждения с экспертами.

Недостатки:

• Теории может не хватить без самостоятельного поиска информации;
• Карьерное сопровождение не гарантирует трудоустройства.

Программа обучения:

• Знакомство с кодингом;
• Контроль версий;
• Языки разработки;
• Сетевые технологии;
• Маршрутизация;
• Дополнительный видеомодуль по математике и информатике.

Ознакомиться с полной программой >>>

3. Network Engineer. Professional | OTUS

Дистанционный курс ведут практикующие инженеры ЦОД и сертифицированные специалисты Cisco. Материал адресован тем, кто уже работает с сетями и хочет уверенно проектировать, защищать и поддерживать инфраструктуру уровня предприятия. Каждая тема подкрепляется практикой: лабораторными заданиями, проектом и фидбэком от преподавателей. Студенты получают прямую поддержку экспертов и общение в активном сообществе.

• Стоимость: от 8 500 руб./мес.
• Длительность: 7 месяцев.
• Формат обучения: онлайн, вебинары, проект.
• Документ об образовании: удостоверение.

Кому подойдет: специалистам по маршрутизации и системным администраторам.

Преимущества:

• Инструкторы с практическим опытом из крупных компаний;
• Инфраструктура для практики от Yandex Cloud;
• Проектные задания с реальными сценариями;
• Разбор реальных ситуаций и итоговый проект;
• Размещение резюме в базе OTUS и участие в карьерных мероприятиях;
• Поддержка сообщества.

Недостатки:

• Требуются исходные знания по сетям.

Программа обучения:

• Архитектура и коммутация;
• OSPF, IS-IS, EIGRP;
• BGP и оптимизация маршрутизации;
• Безопасность инфраструктуры.

Ознакомиться с полной программой >>>

4. Кибербезопасность и сетевые технологии | Компьютерная академия TOP

Этот расширенный курс открывает путь к IT без опыта. Он помогает освоить построение и защиту систем, работу с современными инструментами DevOps. Преподаватели-практики сопровождают задания, дают советы и разбирают ошибки. Учеба в малых группах позволяет получать фидбэк на каждом этапе.

• Стоимость: от 7 830 руб./мес.
• Длительность: 2,5 года.
• Формат обучения: онлайн с практическими заданиями и проектной работой.
• Документ об образовании: гос. диплом о профпереподготовке, международный диплом от Академии.

Кому подойдет: тем, кто хочет строить карьеру в IT с нуля.

Преимущества:

• Практические задачи, близкие к реальным;
• Постоянная поддержка опытных специалистов;
• Сертификация международного уровня;
• Образование доступно с 13 лет;
• Сотрудничество с IT-компаниями.

Недостатки:

• Длительный срок прохождения.

Программа обучения:

• Проектирование и диагностика кабельных систем;
• Алгоритмы и структуры данных;
• Маршрутизация в IP-сетях;
• Процедурный и системный кодинг;
• Администрирование Windows и Linux;
• Аппаратное обеспечение;
• CCNA;
• Облачные технологии.

Ознакомиться с полной программой >>>

5. Специализация Network Engineer | OTUS

Курс от специалистов Cisco и инженеров ЦОД Т-Банка, Ozon Tech и Nokia. Обучение построено на двух ступенях: первая дает базовые навыки работы с оборудованием и протоколами, вторая развивает их до уровня Middle, включая настройку BGP, VPN и автоматизацию. Студенты научатся проектировать и документировать сети и устранять неисправности. Каждое домашнее задание сопровождается подробным разбором, а финальный проект позволяет подтвердить квалификацию и оформить диплом.

• Стоимость: от 14 750 руб./мес.
• Длительность: 12 месяцев.
• Формат обучения: два онлайн-вебинара в неделю.
• Документ об образовании: сертификат и диплом.

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

Преимущества:

• Спикеры со стажем в крупных компаниях;
• Двухуровневая система, где каждая ступень открывает новые компетенции;
• Проекты для закрепления навыков;
• Работа с профессиональными инструментами и симуляторами;
• Поддержка и разбор заданий в Telegram-чате и на групповых сессиях;
• Возможность улучшить резюме и выложить его в специальную базу платформы;
• Шанс попасть на собеседование у организаций-партнеров.

Недостатки:

• Рассрочка дороже, чем у конкурентов.

Программа обучения:

• Корпоративные сети, безопасность, автоматизация;
• Построение локальных экосистем и протокол BGP;
• Виртуализация;
• Настройка защищенных каналов;
• Проектные модули обеих ступеней;
• Бонус: основы Linux, команды, процессы.

Ознакомиться с полной программой >>>

6. Сетевой инженер на базе решений компании Cisco Systems | Специалист.ру

Экспресс-курс для тех, кто хочет уверенно работать с сетями компаний разного масштаба. Лекции ведет практик с семилетним опытом и десятками реализованных проектов в сфере интернет-инфраструктуры. Эксперт показывает, как анализировать и настраивать инфраструктуру, предотвращать сбои и повышать устойчивость систем. Задания выполняются на оборудовании Cisco. Тренинг готовит реальной работе в роли инженера или аналитика.

• Стоимость: от 3 788 руб./мес.
• Длительность: 48 академ. часов. + 162 академ. часа самостоятельной подготовки.
• Формат обучения: онлайн.
• Документ об образовании: международный сертификат, удостоверение.

Кому подойдет: администраторам и инженерам.

Преимущества:

• Практика на оборудовании Cisco;
• Продуманное комплексное наполнение;
• Подготовка к экзамену CCNA 200-301;
• Комплексный подход: от основ до автоматизации;
• Множество графиков прохождения на выбор;
• Автор программы — действующий эксперт;
• Возможность индивидуального образования.

Недостатки:

• Нет рассрочки, только кредит;
• Не предусмотрена помощь в трудоустройстве.

Программа обучения:

• Архитектура, протоколы, сетевые уровни;
• VLAN, Inter-VLAN Routing, STP, DHCP;
• Мониторинг, виртуализация, автоматизация.

Ознакомиться с полной программой >>>

7. Сетевой инженер | Учебный центр доп. образования ЭКОДПО

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

• Стоимость: от 29 980 руб.
• Длительность: от 1,5 месяца.
• Формат обучения: дистанционно.
• Документ об образовании: диплом.

Кому подойдет: для начинающих или желающих сменить карьерный вектор.

Преимущества:

• Доступ к учебной информации без ограничений по времени;
• Три тарифа с индивидуальным треком;
• Поддерживают актуальные требования ИТ-индустрии;
• Сопровождение от специалистов на протяжении курса;
• Бесплатная доставка документов.

Недостатки:

• Отсутствие проверки практических заданий;
• Прохождение в самостоятельном темпе.

Программа обучения:

• Linux для начала работы;
• Коммутация;
• Диагностика и устранение ошибок;
• Python для автоматизации;
• WAN и масштабируемые сети.

Ознакомиться с полной программой >>>

8. Сетевой инженер | НЦПО

Курс разработан для тех, кто хочет углубиться в интернет-технологии или сменить профессию. Материал подготовлен практикующими инженерами, что отражается в структуре вебинаров. Формат построен так, чтобы теория сочеталась с задачами, приближенными к наиболее частым ситуациям.

• Стоимость: от 1 200 руб./мес.
• Длительность: от 250 до 1 600 академ. часов.
• Формат обучения: дистанционно.
• Документ об образовании: диплом.

Кому подойдет: тем, кто планирует расширять компетенции в администрировании и проектировании.

Преимущества:

• Личный кабинет с лекциями и заданиями;
• Проверка ДЗ в удобном режиме;
• Высылают методические материалы;
• Заключают с абитуриентом официальный договор;
• Доставка диплома по всей стране без доплат.

Недостатки:

• Отсутствие живых встреч с преподавателями.

Программа обучения:

• Проектирование инфраструктуры;
• Протоколы маршрутизации и коммутации;
• IPv6: адресация, переход с IPv4, защита.

Ознакомиться с полной программой >>>

9. Сетевой инженер | АПОК

Курс ориентирован на тех, кто хочет получить квалификацию и подтвердить ее дипломом. Академия предлагает три формата прохождения, позволяя выбрать темп, комфортный лично для участника. Обучение строится на практико-ориентированных дисциплинах, исключая отвлекающие темы. Содержание контролируется методистами, чтобы соответствовать требованиям отрасли. Каждый этап прохождения отражает практические сценарии, с которыми сталкиваются специалисты в сетевой сфере.

• Стоимость: от 2 498 руб./мес.
• Длительность: от 1 месяца.
• Формат обучения: дистанционный, текстовые материалы и тестирование.
• Документ об образовании: диплом.

Кому подойдет: смежным специалистам из ИТ.

Преимущества:

• Информация без лишних блоков;
• Три учебных плана, чтобы выбрать оптимальный путь;
• Контент под актуальные стандарты;
• Настройка содержания программы в премиум-тарифе;
• Оперативная поддержка для студентов;
• Дают официальный документ;
• Быстрая доставка оригиналов дипломов.

Недостатки:

• Нет практики;
• Самостоятельное прохождение, без наставничества.

Программа обучения:

• Поиск и устранение ошибок;
• Linux;
• Архитектура и масштабирование;
• Python для инженера;
• Автоматизация инфраструктуры;
• Устранение неисправностей;
• Сетевые устройства.

Ознакомиться с полной программой >>>

10. Сетевой инженер | МИПК

Курс с упором на переподготовку для людей с профильным образованием. Формирует навыки работы с локальными и корпоративными сетями, конфигурирования серверов и администрирования инфраструктуры. Персональный консультант поможет определить текущую степень подготовки и выбрать подходящую специализацию. Дополнительно дают бонусные материалы для самостоятельного закрепления навыков и расширения базы.

• Стоимость: предоставляется по запросу.
• Длительность: от 72 до 512 часов.
• Формат обучения: дистанционно.
• Документ об образовании: диплом либо удостоверение.

Кому подойдет: техническим специалистам со средним или высшим образованием.

Преимущества:

• Документы госстандарта;
• Разная длительность тренингов;
• Подбор специальности с учетом уровня подготовки;
• Обновляемое содержание дисциплин;
• Свободный выбор времени для прохождения лекций;
• Материалы подготовлены экспертами;
• Поддержка опытных методистов.

Недостатки:

• Информация о стоимости только по запросу;
• Нет варианта без профильного образования.

Программа обучения:

• Построение и оптимизация инфраструктуры;
• Серверные решения и администрирование;
• Алгоритмы работы локальных систем и варианты их обустройства;
• Управление сетевой инфраструктурой.

Ознакомиться с полной программой >>>

Дополнительные курсы по сетевым технологиям

В этом разделе отобраны еще 13 образовательных решений для обучения на сетевого инженера.

• Инженер систем сервисов и сетей Linux, IP-телефонии и унифицированных коммуникаций от Специалист.ру — тренинг сочетает теорию с практикой: после каждого блока слушатели выполняют задания под руководством наставников. В итоге выпускники умеют запускать сервисы, настраивать IP-телефонию и интегрировать системы связи с корпоративными серверами.
• Системный администратор от Яндекс.Практикума — за полгода научат администрированию Линукса и азам DevOps. Подготовка охватывает инфраструктуру, базы данных, контейнеризацию и мониторинг, а также темы по системному инжинирингу и архитектуре информационных систем. Выполняя практические задачи и проекты, студенты соберут портфолио из 12 работ.
• Полный курс по сетевым технологиям от Merion Academy — погружает в IT с нуля и сразу переключает на реальные задачи инженеров. Учащиеся настраивают маршрутизаторы, создают виртуальные сети и решают проблемы в эмуляторе от Cisco. У выпускников остаются актуальные навыки и поддержка кураторов.
• Networks. Сетевые технологии от Rebrain — практикум помогает освоить компьютерные сети с нуля и довести навыки до уровня проектирования сложных инфраструктур. Слушатели учатся настраивать протоколы, обеспечивать защиту, а также автоматизировать управление и интегрировать его в CI/CD. По итогам можно уверенно создавать и поддерживать надежные решения для бизнеса любого масштаба.
• Онлайн-курс по сетевым технологиям Huawei от Merion Academy — занятия строятся вокруг практики в симуляторе eNSP: от настройки VLAN и защиты сети от петель до работы с OSPF и BGP. Участники будут фильтровать трафик, динамически распределять IP-адреса и повышать устойчивость инфраструктуры.
• Инженерные сети и системы от Профессионального стандарта — дает знания по проектированию, монтажу и обслуживанию инженерных сетей и систем. Слушатели изучают технические стандарты, правовые основы работы и учатся проводить ремонт и сертификацию объектов.
• Мини-курс по протоколу BGP от Merion Academy — знакомят с принципами маршрутизации и работы протокола BGP. Объясняют, как настраивать фильтрацию трафика, управлять приоритетами маршрутов и проверять видимость префиксов по всему миру. Разбирают классические и современные модели, включая Application Centric Infrastructure.
• Атаки на сетевую инфраструктуру от CyberEd — за 1,5 месяца участники разбирают реальные сценарии атак на корпоративные сети и учатся находить уязвимости в Линуксе и Windows. Осваивают методы внутреннего пентеста, анализ трафика, техники обхода защиты и атаки на Kerberos и NTLM. Финалом становится практическая отработка полного цикла компрометации инфраструктуры.
• Курс MTCNA: MikroTik Certified Network Associate от Эврики — покажут, как работать с оборудованием. В лекциях все: от первого подключения и базовой настройки до защиты трафика, управления сервисами и создания туннелей. Подходит тем, кто хочет разбираться в сетях на профессиональном уровне.
• Локальные сети от CyberEd — спикеры объяснят устройство инфраструктуры, научат проектировать их архитектуру и защищать от атак. Студенты освоят настройку маршрутизации, NAT, попрактикуют сегментирование. Получат опыт моделирования экосистем и работы с реальными уязвимостями.
• Основы сетевых технологий от Cisco — работа на реальном оборудовании: от создания домашней или офисной сети до настройки безопасности и устранения неполадок. Слушатели знакомятся с IP-адресацией, протоколами TCP/IP, взаимодействием устройств в сети. Практика проходит на оборудовании Cisco и в симуляторе Packet Tracer.
• Системный инженер от ИПАП — сочетает работу с серверами и современными технологиями. Абитуриенты изучат Python для автоматизации задач и освоят мониторинг инфраструктуры через Zabbix. Учеба построена на практических примерах.
• Сетевой инженер от Academy IT DMS — превращают сухую теорию в живую практику: настраивают коммутаторы и маршрутизаторы, строят защищенные корпоративные сети. Выпускники быстро находят и устраняют неполадки, управляют доступом через PKI и прогнозируют работу сети с помощью виртуализации.

Бесплатные курсы для сетевых инженеров

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

1. Погружение в сетевую безопасность — Яндекс.Практикум

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

Главное о курсе:

• Развертывание межсетевого экрана следующего поколения;
• Подходит для практикующих специалистов;
• Интерактивные задания и наглядные примеры вместо сухой теории;
• Постоянная поддержка экспертов и общение с коллегами;
• Материалы открыты в любое время и навсегда.

2. Основы компьютерных сетей. Диагностика и устранение основных проблем — GeekBrains

Вебинар раскрывает, как компьютеры и устройства общаются друг с другом в сети и почему иногда возникают сбои. Участники узнают, как устроены протоколы, как адресуются данные и как быстро находить и исправлять проблемы.

Главное о курсе:

• Ясное и доступное объяснение сложных вещей;
• Насыщенный вебинар для начинающих;
• Разбор моделей сетей и частых проблем трансляции данных;
• Прокачивает навыки выявления и устранения сбоев.

3. Сетевой инженер — ответы на ключевые вопросы — NetSkills. Видеоуроки. Cisco, zabbix, linux

Автор видео описывает реальный путь сетевого инженера — от первых шагов до перспектив роста. Разбирает, какие навыки и сертификаты реально ценят на рынке и где можно найти работу с достойной оплатой.

Главное о курсе:

• Профориентация через реальные примеры;
• Раскрывает востребованные навыки и сертификаты;
• Структура по таймкодам для быстрого поиска информации;
• Делится практическими советами для старта в профессии.

4. Сетевой инженер — ИНТУИТ

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

Главное о курсе:

• Лекции с наглядными скриншотами;
• Разбор протоколов, файловых ресурсов и прав доступа;
• Примеры на Windows 2000/2003;
• Удаленный доступ и MMC.

5. Введение в компьютерные сети — Andrey Sozykin

Видеотренинг знакомит с устройством инфраструктуры и протоколов так, чтобы можно было самостоятельно разбираться в статьях и книгах по теме. Лекции сочетаются с практикой: анализ трафика через Wireshark, тестирование соединений с помощью Postman и утилит командной строки.

Главное о курсе:

• Создан для начинающих;
• Охватывает классификации, технологии и стандарты;
• Объясняет модель OSI, стеки протоколов и уровни;
• Полные расшифровки теоретических видео и практических занятий.

6. Подборка интересных моментов из курса «Сетевой инженер» — Академия IT DMS

Комплекс видеоуроков погружает в работу с корпоративными сетями так, будто показывают закулисье инфраструктуры. Здесь разбирают реальные сценарии: от защиты сети и настройки VLAN до динамической маршрутизации.

Главное о курсе:

• Глубокий разбор реальных сетевых задач;
• Полные уроки с наглядными схемами и кодами;
• Объяснение протоколов и способов защиты;
• Управление VLAN и сегментация.

7. Школа системного администратора — курсы-по-ит.рф

Интенсив открывает мир ИТ через короткие видеоролики, где теория переплетается с наглядными схемами и практическими примерами. Материал помогает увидеть, как техника оживает в руках администратора, и освоить базовые технологии без лишней воды.

Главное о курсе:

• Рассчитан на новичков без опыта;
• Короткие уроки, наполненные конкретикой;
• Плавный переход от основ к тонкостям настройки;
• Разбор доменов в действии.

8. Основы сетевых технологий и криптографической защиты — Stepik

Тренинг раскрывает, как устроены сети и как защитить данные от разных угроз. Учащиеся осваивают адресацию, настройку локальной сети и методы кодирования информации, включая популярные криптосистемы.

Главное о курсе:

• Чистая теория, без тестов и практики;
• Лаконичные объяснения, никаких сложных формулировок;
• Основы криптографии, включая RSA и Эль-Гамаль;
• Проверка идентификаторов и организация обмена данными.

9. Архитектура современных компьютерных сетей — курсы-по-ит.рф

В серии компактных видеоуроков сети раскрываются от самой математики и физики до современных стандартов. Каждое занятие показывает, как теория реализуется на практике, так что сложные темы становятся понятными без лишнего времени и усилий. Материал помогает упорядочить знания и взглянуть на технологии свежим взглядом.

Главное о курсе:

• Детальный разбор протоколов и моделей передачи данных;
• Короткие уроки, которые реально осилить за раз;
• Полезно как новичкам, так и тем, кто хочет актуализировать знания;
• Современные стандарты и технологии поданы наглядно.

10. Сетевые и распределенные системы: немного о сложном и важном — Stepik

Автор помогает понять, как компьютеры обмениваются данными и как работает сетевое и системное ПО. Студенты смогут моделировать сети, отслеживать передачу пакетов и использовать инструменты для анализа и визуализации.

Главное о курсе:

• Тесты помогают закреплять и проверять знания;
• Прочная теоретическая база для дальнейшей работы;
• Сбор и визуализация с помощью Prometheus и Grafana;
• Применение языка Go и контейнеров Docker для распределенных систем.

Полезные ресурсы

Книги

• Python для сетевых инженеров — Н. Самойленко. Объясняет основы Питона через практику с оборудованием, предлагая примеры на Cisco и задания для автоматизации реальных задач. Читатель получает понятные инструменты для написания скриптов, работы с файлами, регулярными выражениями, а также старт для самостоятельного углубления в Python.
• Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов — Олифер В.Г., Олифер Н.А. Издание отражает современные достижения технологий: от терабитных скоростей и гибких оптических сетей до виртуализации функций и облачных сервисов. Оно помогает понять устройство локальных и глобальных экосистем, особенности их управления и актуальные вопросы безопасности.

Образовательные проекты и статьи

• Материалы по сетям — блог OTUS. Школа собрала подборку статей от практикующих специалистов, которая будет полезна и новичкам, и действующим инженерам. Тексты открыты для изучения в удобном темпе, без ограничений по доступу.
• Единый учебный портал — TS Solution. Платформа предлагает видеокурсы и методические материалы по ИТ и ИБ, включая бесплатные уроки для практикующих инженеров. На портале можно изучить рекомендованный план образования, получить теорию и пройти специализированные бесплатные интенсивы.
• Статьи про сети для самых маленьких — блог linkmeup. Площадка представляет сборник статей о интернет-технологиях, от базовых понятий до продвинутых тем. Материалы написаны простым языком, с реальными примерами, что облегчает понимание и практическое применение знаний.

Вопрос — ответ

Кто такой сетевой инженер и чем он занимается?

Если говорить просто, сетевой инженер — это человек, который строит и поддерживает компьютерные сети, чтобы все запускалось без сбоев. Он может работать как с маленькими офисными экосистемами, так и с огромными корпоративными инфраструктурами, где соединены сотни офисов и дата-центров.

Его главная цель — сделать так, чтобы устройства обменивались информацией быстро и безопасно. Для этого он настраивает маршрутизаторы, прокси, коммутаторы и разные системы контроля трафика и безопасности. Кроме того, такой специалист постоянно следит за нагрузкой, выявляет узкие места и устраняет тормоза, которые мешают работе пользователей или сервисов.

Он участвует в выборе оборудования и технологий, чтобы сеть оставалась надежной и могла расти вместе с компанией. И еще одна важная часть работы — продумывать резервные схемы и план восстановления на случай сбоев, чтобы система не «падала» и данные оставались целыми.

Чем сетевой инженер отличается от системного администратора?

Сисадмин следит за тем, чтобы компьютеры, серверы и программы работали без сбоев. Он устанавливает нужное ПО, настраивает учетные записи и почту, а еще проверяет стабильность всех систем. Если что-то идет не так, приходится быстро находить решение и устранять проблему.

Инженер занимается связью между устройствами и сетями. Он следит, чтобы соединение не «падало», данные оставались защищенными, а каналы связи работали стабильно. По сути, если с системой что-то не так, именно он берется за решение.

Иногда их обязанности пересекаются. Сисадмин может настраивать офисное оборудование, а инженер подключать серверные VLAN или настраивать фаерволы. В целом же администратор больше работает с серверами и софтом, а инженер — с сетью и ее безопасностью.

Какие навыки нужны сетевому инженеру?

Сначала имеет смысл разобраться с основами: TCP/IP, DHCP, DNS. Практика с реальным оборудованием пригодится, ведь часто приходится настраивать маршрутизаторы, точки подключения и коммутаторы. Полезно вникнуть в азы интернет-безопасности: как быстро ограничить доступ, подготовить фаервол или VPN, обезопасить информацию.

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

Какие технологии и протоколы изучать в первую очередь?

Первыми лучше освоить базу — IP‑адресацию и маршрутизацию. Сначала IPv4, потом IPv6, понять, как маршрутизаторы формируют маршруты. Хорошо сразу познакомиться с VLAN, чтобы разделять сеть, VPN — чтобы соединять офисы безопасно, и SNMP для мониторинга оборудования.

Не лишним будет разобраться с Wi‑Fi: как настроить покрытие, учесть безопасность. И базовые вещи по защите информации тоже нужны — доступ к сетям, шифрование, обнаружение подозрительной активности, резервные копии. Эти знания реально помогают дальше разбираться в сложных сетевых задачах и не теряться, когда начинаешь работать с инфраструктурой на практике.

Какие сертификаты востребованы в этой области?

Сертификаты реально помогают выделиться и показать, что человек умеет работать с сетями на практике. Особо выделяются Cisco CCNA и CCNP — они покрывают все, от базовой маршрутизации до настройки безопасности. Если работаете с Juniper, JNCIA будет большим плюсом, а CompTIA Network+ помогает держать общий уровень знаний.

Для карьерного роста наличие сертификатов заметно ускоряет процесс: чаще допускают к более сложным проектам и повышают. Иногда работодатели даже предпочитают, когда у сотрудника несколько разных сертификатов — это говорит, что он знаком с разными технологиями и оборудованием.

Можно ли стать сетевым инженером без технического образования?

Если хочется работать с IT и сетями, сначала придется разобраться, как устроены компьютеры, сети и серверы. Без практики особо ничего не закрепится — пробуйте на оборудовании или хотя бы в симуляторах.

Часто в эту сферу приходят из администрирования, техподдержки или тестирования железа. Самообразование реально работает: курсы, книги, лабораторные задания, реальные проекты — все идет в копилку опыта. Портфолио проектов зачастую ценят больше, чем диплом, если опыта достаточно.

Сколько времени занимает подготовка к профессии?

Если заниматься регулярно, базовые навыки реально освоить за полгода–год — пробовать технологии, настраивать оборудование, решать задачи на практике. Но чтобы спокойно работать с реальными сетями, опыта нужно гораздо больше, годы, и придется подтягивать смежные темы. Настоящее понимание маршрутизации, протоколов, безопасности и облачных решений приходит постепенно. Даже профессионалы постоянно учатся, осваивая новые инструменты по мере их появления.

Насколько востребованы сетевые инженеры?

Спрос на таких специалистов реально высокий. Везде, где есть IT‑инфраструктура — от ЦОДов до крупных корпораций и телекомов — нужны люди, которые умеют держать сеть в устойчивом состоянии. С облачными сервисами, виртуализацией и постоянными угрозами безопасности без таких сотрудников бизнес просто бы не справлялся. Хорошо прокачанные профи могут спокойно работать удаленно для компаний по всему миру, а в городах с развитой IT-сферой всегда есть интересные проекты.

Какие перспективы карьерного роста у сетевого инженера?

Сетевой инженер может идти разными путями. Кто-то сосредотачивается на проектировании сложных инфраструктур, кто-то работает с защитой данных. Есть направление DevNet, где сети автоматизируются и программируются. Опытные специалисты часто переходят к управлению IT-инфраструктурой и ведут команду.

Карьерный рост зависит от того, как навыки используются на практике и какие технологии освоены. Практика и сертификаты открывают доступ к крупным проектам и руководящим позициям.

Какие смежные области полезно изучать?

Если работать с сетями всерьез, то без базовых знаний в области безопасности никуда. Плюс сейчас почти везде используется виртуализация и облака — AWS, Azure, Google Cloud, так что с ними тоже придется подружиться. Чтобы не тратить кучу времени на рутину, удобно автоматизировать задачи скриптами: Python или Ansible отлично подходят. Linux и работа в консоли — это вообще ежедневный инструмент, без него сложно администрировать сервера или сетевые устройства.

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

Сетевой инженер — это не просто работа с железом и настройками. Тут и инфраструктура, и безопасность, и куча мелких деталей, где без внимательности никуда. Вроде звучит сложно, но зато открывает дорогу в IT и дает навыки, которые реально ценятся.

Учиться можно онлайн: сначала теория, а потом сразу практика. Где-то попробуете инструменты, где-то разберете задачу и поймете, что без ошибок не обойтись. Зато именно так все лучше усваивается. На что смотреть при выборе обучения? Ну, хотя бы на проекты, обратную связь экспертов и то, насколько материал свежий.

В подборке собраны разные варианты курсов сетевого инженера — с их помощью можно шаг за шагом войти в профессию. А если вы уже пробовали подобные тренинги, расскажите, как все прошло. Может, у вас есть свой проверенный курс?

Блокировка популярного «интернет-спидометра» оставила миллионы пользователей в растерянности. Как теперь проверить, действительно ли провайдер недодаёт обещанные 100 Мбит/с? Или выявить скрытые проблемы с пингом? К счастью, Speedtest — не единственный скоростемер интернета. Существуют проверенные альтернативы, которые работают в России прямо сейчас, дают точные данные и при этом не требуют ухищрений с обходом блокировок.

В этом материале — только реальные инструменты, протестированные нами в августе 2025 года. Разберём, как устроены замеры скорости и почему цифры в разных сервисах отличаются; что делать, если результаты тестов вызывают сомнения и как получить максимально точные результаты.

Что такое скорость интернета и на что она влияет

Скорость интернета — не абстракция, а набор конкретных метрик:

• Download (загрузка): сколько данных в секунду вы получаете — важно для стриминга, загрузки файлов.
• Upload (отдача): скорость отправки данных — критична для видеозвонков или загрузки фото в облако.
• Ping (задержка): время отклика сервера в миллисекундах — ниже 20 мс. Идеально для геймеров.
• Jitter (джиттер): колебания пинга — если выше 30 мс, голос в Zoom начнёт «рваться».
• Packet Loss (потери пакетов): даже 2% способны разрушить стабильность соединения.

Как работают измерители? Сервисы отправляют тестовые пакеты данных на ближайший сервер и анализируют время передачи, объём успешно переданных данных и стабильность соединения.

Альтернативы, которые работают в 2025 году

Сегодня в Рунете доступны проверенные сервисы, прошедшие испытание временем и блокировками. Они сочетают точность замеров с прозрачностью методологии, а главное — работают без обхода блокировок. Мы отобрали семь ключевых платформ, охватывающих все сценарии: от быстрой проверки на смартфоне до глубокого анализа для инженеров.

Яндекс.Интернетометр: минимум действий, максимум ясности

Когда нужен мгновенный замер без настроек — это идеальный выбор. Сервис запускается в два клика и за 15–20 секунд выдаёт ключевые показатели. Помимо скорости загрузки (Download) и отдачи (Upload), он показывает детали вашего подключения: точный IP-адрес, географический регион, разрешение экрана и даже версию браузера. Это удобно для быстрой диагностики: например, если сайт грузится медленно, сравните ваши данные с показателями на другом устройстве, подключенном к той же сети.

Главные преимущества:

• точность измерений;
• автоматический выбор ближайшего сервера Яндекса (что снижает погрешность);
• возможность поделиться скриншотом результата в один клик;
• полное отсутствие рекламы и минимальная нагрузка на систему.

Но есть и минусы. Сервис не измеряет критически важные для геймеров и VoIP-звонков метрики — ping (задержку) и jitter (джиттер — неравномерность задержек между пакетами данных, что влияет на качество связи). Нет и истории замеров: нельзя сравнить сегодняшнюю скорость с прошлогодней. Это плата за простоту.

Для кого: идеален для рядовых юзеров сети, техподдержки и ситуаций, когда нужно за 30 секунд доказать: «Да, интернет сегодня действительно тормозит». Если же вам нужны технические детали — смотрите в сторону Линкметра или Cloudflare Speed Test.

Линкметр: эталон для профессионалов

Это не просто сервис, а метрологический инструмент, созданный на базе аппаратно-программного комплекса «Вектор-2019». Его ключевая особенность — внесение в госреестр средств измерений СИ РФ (ФГИС АРШИН №79185-20). Это означает юридическую силу результатов: показатели Линкметра принимают Роскомнадзор, суды и провайдеры при разрешении споров о качестве связи.

Что делает его незаменимым для специалистов:

• Тестирует не только скорость (Download/Upload), но и параметры, критичные для стабильности — потерю пакетов (Packet Loss), задержки (Ping, Jitter), временные отклонения вплоть до микросекунд.
• Режим «Длительного мониторинга» (до 24 часов) выявляет периодические «проседания» скорости — например, когда интернет замедляется каждый вечер из-за перегруженности сети.
• Экспорт в PDF/XLS с печатью штампов времени — готовый отчёт для аудита.

Интерфейс — функциональный, но без излишеств. Графики в реальном времени показывают малейшие колебания. Серверы в России (Москва, Санкт-Петербург, Краснодар, Воронеж и т.д.) позволяют тестировать задержки внутри страны. Для новичков это может выглядеть сложным, но для сетевого инженера такой детализации не хватает в других сервисах.

Главные ограничения:

• нет мобильных приложений: только веб-версия;
• минималистичный дизайн может отпугнуть неподготовленных пользователей.

Когда он необходим:

• при проверке SLA-договора с провайдером;
• для поиска скрытых проблем сети (например, периодических потерь пакетов);
• если нужны юридически значимые доказательства некачественной связи.

Профессиональный лайфхак: используйте Линкметр вместе с Wireshark (анализатором сетевого трафика) — это даст полную картину поведения сети.

Cloudflare Speed Test: технически продвинутый

Этот сервис — не просто измеритель скорости, а диагностический инструмент для сетевых инженеров. Он анализирует три критичных параметра одновременно:

• пропускную способность (Download/Upload);
• джиттер;
• потери пакетов..

Ключевое преимущество — интерактивные графики в реальном времени. Вы видите не просто цифры, а динамику соединения: как ведёт себя канал при пиковых нагрузках, есть ли микроразрывы, насколько стабильна линия. Это незаменимо для диагностики «плавающих» проблем, когда интернет работает с перебоями.

Для профессионалов:

• ручной выбор сервера из 300+ точек Cloudflare — можно проверить связь с конкретным регионом (например, Франкфурт для AWS или Сингапур для азиатских сервисов);
• подробная статистика — от времени загрузки DNS до уровня загруженности канала;
• экспорт в JSON — данные готовы для анализа в Zabbix или Grafana.

Недостаток периодические блокировки в РФ.

Практическое применение:

1. Оптимизация VoIP — если jitter > 30 мс, голос в Zoom будет прерываться.
2. Диагностика потерь пакетов — 2% уже влияют на возможность участвовать в игре.
3. Сравнение CDN — тест до разных серверов покажет, где маршрутизация эффективнее.

Для кого: системные администраторы, DevOps-инженеры, геймеры на профессиональном уровне.

nPerf: комплексный тест для стримеров, киноманов и не только

Если вам нужен инструмент, который не просто измеряет скорость, но и предсказывает качество стриминга на RuTube или Twitch — nPerf станет идеальным способом проверки интернета.

Этот сервис, доступный в РФ в 2025 году, сочетает простоту запуска с глубиной анализа. Главное преимущество — симуляция реальных сценариев: вместо абстрактных цифр вы видите, как поведёт себя ваше соединение при просмотре 4K-видео или запуске прямой трансляции.

Почему стримеры выбирают nPerf? Автоматический тест стриминга — ключевая фишка. При запуске проверки nPerf эмулирует:

• загрузку видео с битрейтом до 50 Мбит/с;
• параллельную работу мессенджеров (Zoom, WhatsApp);
• фоновую передачу файлов через облачные хранилища.

Результат — оценка качества связи по 100-балльной шкале. Например, 85+ баллов гарантируют плавный стрим без буферизации, а 60–70 предупредят о рисках при трансляции в Full HD.

Детализация без сложностей:

• графики в реальном времени показывают стабильность скорости;
• ручной выбор сервера (включая российские локации Москвы и Санкт-Петербурга);
• история тестов с сравнением результатов за неделю или месяц.

Ограничения, которые стоит учесть

• Перегруженные серверы: бесплатные точки тестирования иногда не справляются с нагрузкой. Если скорость скачет — переключитесь на сервер в Финляндии или Германиию
• Реклама в веб-версии: мобильное приложение (Android/iOS) чище, но требует установки.

Профессиональный лайфхак: активируйте опцию «Режим инженера» в настройках.

Это покажет потерю пакетов (Packet Loss). колебания пинга (Jitter), загрузку процессора во время теста — полезно для диагностики «тормозов» на слабых устройствах.

Когда nPerf незаменим:

• перед запуском стрима — если оценка выше 80 баллов, смело включайте трансляцию в 1080p;
• при выборе провайдера — сравните результаты в разное время суток;
• для диагностики Wi-Fi — запустите тест в разных комнатах. График стабильности выявит «мёртвые зоны».

Важно: nPerf сохраняет данные на европейских серверах. Если нужен аналог с хранением в РФ — используйте другие площадки.

SpeedOf.Me: браузерный тест с детализацией для аналитиков

Этот сервис — идеальный компромисс между простотой браузерного теста и глубиной профессионального инструмента. Работая на чистом HTML5 без Flash или Java, он запустится даже на старом ноутбуке с Windows XP или бюджетном Chromebook.

Главная фишка — динамические графики в реальном времени: во время замера вы видите, как ведёт себя ваше соединение. Резкий скачок вверх? Плавное снижение? Или «пила» из-за помех? Это сразу видно на диаграмме.

Ключевые преимущества для повседневного использования:

• не требует установки плагинов — всё работает прямо в браузере за три клика;
• адаптивный дизайн корректно отображается на любом смартфоне — от iPhone SE до Samsung Galaxy Fold;
• автоматическое сохранение истории тестов — сравните сегодняшние показатели с результатами недельной давности одним нажатием;
• выявляет кратковременные «просадки» скорости — например, если Wi-Fi роутер перегревается или сосед включает микроволновку.

Как это помогает профессионалам:

• Веб-разработчикам — проверяют, как их сайт будет грузиться на медленных каналах.
• Аналитикам трафика — сопоставляют скорость с пиковыми нагрузками на сервер.

Единственный существенный недостаток: система сама выбирает оптимальный сервер. Вы не можете принудительно указать Москву для проверки локального CDN или Лондон для теста международного канала. Это ограничивает использование для географического анализа.

Практический совет: запускайте тест одновременно на ноутбуке (по Wi-Fi) и смартфоне (через 4G). Сравнение графиков покажет, где узкое место — в домашней сети или на мобильном операторе.

Для кого: идеален для фрилансеров, создающих сайты; маркетологов, анализирующих поведение пользователей; ИТ-специалистов, которые хотят быстро проверить канал без сложных инструментов.

Orb: ваш персональный инженер по качеству связи

Этот инструмент — наследник DNA Speedtest от команды разработчиков оригинального Ookla. Он создан для тех, кому недостаточно разовых замеров. Orb превращает ваш ПК (Windows, macOS, Linux) или сервер (Docker) в стационарный измерительный пункт, отслеживающий качество связи 24/7.

В отличие от браузерных сервисов, он оценивает сеть по пяти параметрам: пропускная способность, задержки, джиттер, потери пакетов, стабильность — и выводит единый балл от 0 до 100.

Как это помогает на практике:

• кроссплатформенность — идентичные тесты на ноутбуке, домашнем ПК и сервере в дата-центре;
• привязка к реальным приложениям — Orb симулирует нагрузку Zoom (VoIP), YouTube (видео), Dropbox (файлы) и показывает, как ваша сеть поведёт себя в рабочих сценариях;
• локальный контроль — можно развернуть тестовый сервер в офисе или облаке (AWS/Azure), чтобы проверять каналы без выхода в интернет.

Для глубокой аналитики:

• графики за час/день/неделю — видите, что скорость падает каждый день в 18:00 из-за нагрузки на сеть провайдера;
• уведомления в Telegram — если балл качества падает ниже 80, вы узнаете об этом первым;
• отчёты в PDF с метками времени — доказательная база для провайдера.

Что может отпугнуть новичков:

• требует установки ПО — нет веб-версии для быстрой проверки;
• интерфейс исключительно на английском — базовые термины вроде «jitter» (неравномерность задержек) или «packet loss» (потеря пакетов) нужно знать;
• настройка приватного сервера потребует навыков работы с Docker или Linux.

Идеальные сценарии использования:

1. удалённая работа — если вы подключаетесь к корпоративной сети из дома, Orb выявит проблемы до того, как начнёт «лагать» RDP;
2. DevOps-мониторинг — интеграция с Zabbix/Grafana для сбора метрик сети между серверами;
3. тестирование Wi-Fi-сетей — сравнение качества связи в разных точках офиса.

Профессиональный совет: Запустите Orb на Raspberry Pi (маломощном и дешёвом устройстве) в режиме 24/7 — это даст полную картину стабильности вашего канала. Непрерывный мониторинг выявляет скрытые проблемы, которые разовые тесты не фиксируют.

Запуск Orb на Raspberry Pi позволяет:

• обнаружить периодические сбои — например, падение скорости каждый вечер при нагрузке на сеть провайдера или кратковременные обрывы из-за перегрева роутера;
• собрать юридически значимые доказательства для провайдера — например, если 30% времени скорость ниже 50% от заявленной по договору.

Для кого: IT-специалисты, работающие из дома; администраторы распределённых команд; инженеры, оптимизирующие гибридную инфраструктуру.

ПроСеть: мобильный инспектор от РКН

Приложение разработано Центром мониторинга сетей связи при поддержке Минцифры. Это не просто измеритель, а диагностический комбайн: проверяет доступность сайтов Рунета, трассирует маршруты данных, анализирует Wi-Fi (сигнал, загруженность каналов). Удобен для жалоб провайдеру — результаты невозможно оспорить, так как серверы контролирует РКН.

Плюсы:

• интеграция с системой подачи жалоб в РКН;
• показывает реальные проблемы: например, если видеохостинг тормозит из-за перегруженности канала;
• нет рекламы, интерфейс на русском.

Минусы:

• только Android (для iOS версии нет);
• в тестах на устройствах с Wi-Fi 5 пинг иногда скачет до 100 мс — не подходит для киберспорта.

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

Как получить точные результаты: преодолеваем помехи

Почему 90% пользователей видят заниженные цифры? Неправильная подготовка искажает данные сильнее, чем реальные проблемы провайдера. Фоновые процессы, Wi-Fi-помехи или перегруженный сервер — всё это создаёт «шум». Чтобы измерения отражали истинные возможности канала, нужен системный подход.

Пять фундаментальных правил, проверенных на практике:

• закройте фоновые приложения — особенно торренты, облачные хранилища (Dropbox, Яндекс.Диск) и стриминговые сервисы (Twitch, YouTube);
• используйте проводное подключение — Ethernet-кабель CAT 5e/6 устраняет погрешность Wi-Fi, достигающую 30% из-за стен и помех;
• выберите географически близкий сервер — если сервис позволяет ручной выбор (как в Линкметре или Cloudflare);
• проведите серию замеров — 3-5 тестов в разное время суток (утро/вечер/ночь) с интервалом в два часа;
• отключите прокси — шифрование снижает скорость на 10-40%, а маршрутизация через сторонние серверы искажает ping.

Как это работает? Представьте: вы проверяете скорость Wi-Fi с открытым uTorrent. Показатель Download — 35 Мбит/с. После кабельного подключения и закрытия торрента тот же сервис показывает 95 Мбит/с. Разница в 171% — это не волшебство, а устранение помех. Для профессиональных задач (SLA-тесты, жалобы провайдеру) используйте Линкметр: его эталонные алгоритмы компенсируют даже кратковременные помехи.

Важно: ни один сервис не даст точных данных при перегруженной сети. Если сосед качает 4К-фильмы, а вы играете в Counter-Strike — результаты будут некорректны в любой системе.

Что выбрать? Краткий гид

Почему цифры на разных сервисах отличаются?

Разброс показателей на разных площадках действительно имеет место. Например, при одновременном тесте download (загрузка): от 89 до 332 Мбит/с;, а ping (задержка): от 0 до 241 мс.

Причины:

• расположение сервера — тест для Москвы покажет одну скорость, для Нью-Йорка — другую;
• методология замера — одни сервисы используют многопоточные подключения (для выполнения параллельных процессов), другие — нет;
• нагрузка на сервер — публичные сервисы в час пик тормозят.

Совет: для объективной картины выбирайте сервер вашего провайдера. Например, у «Ростелекома» есть QMS (qms.rt.ru), но он иногда занижает показатели на 10-20%.

Итоги

Запрет Speedtest — не катастрофа. Для большинства подойдут Яндекс.Интернетометр (простота) или Линкметр (точность). Мобильным пользователям — ПроСеть. Главное — понимать, какие метрики вам нужны, и как их интерпретировать.

Проверьте сами: все сервисы из статьи доступны в РФ на август 2025. Если заметили блокировку — пишите в комментарии, обновим список!

P.S. Для самых требовательных: если нужно измерить скорость «как в реальной жизни», качайте торрент с тысячей сидов — это эталон, с которым не поспорит ни один сервис.

Что такое почтовые протоколы и почему они определяют всё

Почтовый протокол — это набор правил, по которым устройства и программы обмениваются email-сообщениями. Он определяет, как письмо отправляется, передается, хранится и извлекается. Именно эти протоколы лежат в основе любой почтовой инфраструктуры — от личных ящиков до корпоративных систем.

Существуют как открытые, так и закрытые (проприетарные) протоколы. Открытые стандарты доступны всему рынку, закрытые принадлежат отдельным компаниям (например, Microsoft). Большинство современных почтовых систем до сих пор работает на открытых протоколах, разработанных в XX веке:

• SMTP (1982 год, RFC 821) — используется для отправки писем с почтового клиента на сервер и между серверами, но не предназначен для получения писем пользователем.
• IMAP (первая версия — 1986 год, RFC 1064; текущая версия IMAP4 — RFC 3501, 2003) — используется для доступа к письмам на сервере без их загрузки, с возможностью синхронизации между устройствами. Например, что прочитано на одном устройстве, будет отмечено прочитанным и на другом.
• WebDAV / CalDAV / CardDAV (с конца 1990-х) — для управления файлами на сервере, работы с календарями, адресными книгами и контактами.

Из проприетарных — MAPI от Microsoft (в начале 1990-х годов) обеспечивает тесную интеграцию почты, календарей, контактов и задач между клиентом (Outlook) и сервером (Microsoft Exchange).

Эти протоколы универсальны и поддерживаются большинством почтовых клиентов. Но их возраст — главная проблема.

Технологии 80-х против задач 2020-х

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

• Ограничения на размер сообщений. SMTP технически не предназначен для передачи больших файлов: вложения кодируются и увеличиваются в объёме, а большинство серверов ограничивают размер письма 25 МБ. Видео, презентации и таблицы нередко «не проходят».
• Медленная доставка. В классических протоколах нет push-механизма — клиенты запрашивают почту вручную или по таймеру. На мобильных устройствах это особенно заметно — письма приходят с задержкой.
• Нет встроенного шифрования. SMTP и IMAP изначально не защищены. Шифрование реализуется через внешние надстройки (например, STARTTLS), и далеко не все системы его поддерживают по умолчанию.
• Разрозненность функций. Почта, календарь и контакты работают по разным протоколам: SMTP, IMAP, CalDAV, CardDAV. Это требует сложной настройки и дает нестабильный результат — особенно в гибридных или распределенных средах.
• Нет централизованного управления. В открытых протоколах нельзя массово настраивать клиентские приложения, удалять учетные записи с устройств или управлять профилями пользователей. Это затрудняет администрирование и снижает безопасность.
• Уязвимость к атакам. IMAP и SMTP в открытых конфигурациях — популярная мишень. Почта давно стала основным каналом проникновения. По данным BI.ZONE CESP, в 2024 году число вредоносных вложений в корпоративной почте выросло на 250%, а фишинговых ссылок — на 25%.

Такие изъяны особенно критичны для корпоративных почтовых систем, где требуется высокая функциональность, масштабируемость, надёжность и защита данных.

Открытый протокол 2TMTP

Чтобы почта соответствовала современным требованиям, нужен принципиально новый протокол — не «костыль» над старым, а полноценная замена. Мы в «МБК Лаб» разрабатываем такой стандарт — 2TMTP.

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

Что умеет 2TMTP:

• Передача любых типов данных без ограничений по объему: письма, файлы, календари, задачи, контакты.
• Встроенное сквозное шифрование — по умолчанию, без внешних решений.
• Push-доставка и подтверждение прочтения — как в мессенджерах.
• Автонастройка клиента и автоудаление профиля — удобно для MDM и гостевого доступа.
• Централизованное управление профилями: настройка прав, политик, внешнего вида клиента с серверной стороны.
• Работа между серверами — не только клиент-сервер, как у SMTP, но и сервер-сервер с полной синхронизацией.
• Поддержка fallback-режимов. Если одно из устройств не поддерживает 2TMTP, можно откатиться на SMTP или IMAP. Протокол встроен в стандарт ESMTP CAPABILITY и активируется при обоюдной поддержке.

Чем 2TMTP отличается от MAPI

MAPI — это ближайший аналог 2TMTP по функциональности, но он полностью закрыт. Протокол используется только в экосистеме Microsoft (Outlook + Exchange), и сторонние разработчики не могут интегрировать его в свои решения. Кроме того, в отличие от MAPI, который ограничен клиент-серверным взаимодействием, 2TMTP также поддерживает полноценное межсерверное общение. В результате 2TMTP не имеет лимита на размер передаваемого сообщения, в то время как почта Microsoft ограничена 25 МБ, поскольку для передачи данных между серверами переходит на стандартный SMTP.

2TMTP — открытый. Любая российская или зарубежная компания сможет встроить его в свою почтовую систему или клиент и получить техническую поддержку. Это делает его универсальной платформой для почтовой инфраструктуры в России, странах ЕАЭС, БРИКС.

Когда будет доступен новый протокол

На данный момент разработка стандарта 2TMTP полностью завершена. Тем не менее, для его официального внедрения потребуется время на юридические процедуры и регистрацию. Мы ожидаем завершить эти этапы до конца 2025 года — в начале 2026 года протокол станет доступен для широкого использования.

Каждый разработчик почтового сервиса сможет интегрировать 2TMTP и получить техническую поддержку от нашей команды.

А что со старым добрым SMTP

SMTP работает на миллиардах устройств в мире. Совершенно очевидно, что ещё много десятков лет, он сохранит свою работоспособность. Естественно, расширяя функциональность, мы обязаны предусмотреть совместимость. Поэтому 2TMTP распространяется в двух форматах:

1. Самостоятельный протокол;
2. Расширения протокола SMTP. Дело в том, что в начале сессии eSMTP оба хоста «знакомятся», обмениваясь методами, которые могут применить на одной и другой стороне. Если найдено пересечение, то можно продолжить взаимный диалог. Если оба хоста заявили о поддержке 2TMTP, то оба переходят на взаимодействие по предложенному протоколу.

Таким образом достигается расширенная функциональность. Тем же, кто этого не умеет, придётся довольствоваться архаичными свойствами.

В сети ресторанов быстрого питания тысячи касс, киосков и систем учёта. Если сеть «падает» — заказы не принимаются, клиенты уходят, а бизнес теряет деньги. Раньше в сети быстрого питания сбои устраняли вручную, а ИТ-окружение работы нового объекта предприятия инсталлировалось и настраивалось неделями. Это и неудивительно, поскольку каждый объект был особенной «снежинкой» со своими нюансами в настройках. В декабре 2024 года компания внедрила SD-WAN Reasonance от бренда Manticore — это не только сократило время установки и простои сети, но и снизило расходы на IT-инфраструктуру на 20%.

Какие стояли задачи

В холдинге — главном франчайзи KFC/Rostic’s — 600 ресторанов, и у каждого объекта свое сетевое оборудование, провайдеры и настройки для касс, ПК, менеджеров и IoT-устройств. Инженеры тратили часы на поиски источников сбоев, обновление систем и настройку безопасности. Каждое развертывание требовало ручной работы, занимало недели и увеличивало издержки. Администрирование происходило на уровне отдельных устройств, поэтому проводить диагностику и устранять неполадки было сложнее. Компании нужен был инструмент, который позволил бы:

• Быстро развертывать новые сервисы, например, развернуть в бизнес-подразделении сервис диджитал-киоска за два дня
• Обеспечить предсказуемость и надежности сети
• Автоматизировать управление сетевым оборудованием
• Сократить затраты на телеком и IT-услуги

Технология SD-WAN позволяет централизованно управлять сетями и сетевыми политиками в филиалах, а также облачными сервисами и ЦОДами. От традиционных MPLS-сетей и VPN она отличаются гибкостью в выборе каналов (MPLS, широкополосный доступ, LTE, 5G), оптимизацией трафика и автоматическим распределением нагрузки на сети, низкими затратами, повышенной безопасностью благодаря встроенным механизмами шифрования и быстрым развертыванием.

Внедрение и результаты

В декабре 2024 года Manticore завершила развертывание своей системы в сети ресторанов быстрого питания. Во время внедрения бизнес-процессы продолжали работать, а управляемость сети повысилась, поскольку теперь появилась возможность управлять не отдельными устройствами и каналами, а сервисами и локациями через единый интерфейс. Теперь сетевая инфраструктура нового ресторана подключается за 10 минут вместо нескольких дней, поэтому инженерам не нужно постоянно выезжать на место. За это отвечает Zero Touch Provisioning (ZTP), которая исключает ручную настройку.

Всего проект охватил 600 филиалов — 400 действующих и 200 новых. Reasonance помогла автоматизировать управление IT-инфраструктурой и стандартизировать настройки оборудования без потери качества обслуживания. Плюс повысилась безопасность всех систем при аутентификации на оборудовании, поскольку у сотрудников появился единый контроль доступа.

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

Как результат — компания сократила расходы на телеком и IT-услуги более чем на 20%, а время технического аудита — с 60 до 5 дней. Платформа поддерживает мультивендорность и интегрируется с оборудованием Cisco, Fortinet, Mikrotik, Qtech без замены железа. Это позволило внедрить SD-WAN без дополнительных затрат на обновление инфраструктуры.

Более того, сеть ресторанов смогла ускорить процесс диагностики и восстановления критичных приложений — теперь системы в реальном времени отслеживают работу сети и мгновенно реагируют на неполадки, переключая трафик на резервные каналы, а также динамически распределяют нагрузку сети. Снизилась и нагрузка на IT-отдел на 50%, поскольку специалистам не нужно вручную мониторить все системы и устранять баги.

Сейчас компания управляет более 2000 единицами сетевого оборудования с помощью единых стандартов, а распространение конфигураций на новые филиалы происходит автоматически. В планах сети — открыть еще 100 ресторанов в следующем году. Благодаря SD-WAN Reasonance развертывание новых точек займёт не недели, а дни.

Внедрять Reasonance может средний и крупный бизнес практически во всех сферах — от розничной торговли и логистики до медицины и финтеха. В любом случае развертывание пройдет практически бесшовно, а эксперты компании будут оказывать всю необходимую техническую поддержку даже после продажи продукта.

Реклама. Рекламодатель: ООО «НПП Бизнес Связь Холдинг» ИНН 7703050752, erid: 2W5zFHd5zAL

Самый простой пример: сайт использует API для получения данных о погоде из Яндекс.Погоды или другой сайт использует API для обработки платежей через онлайн-банкинг.

В этой статье разберёмся, что такое API и как он работает на практике, как запустить первые интеграции и научиться разбираться в документации.

Основы работы с API

Если объяснять простыми словами, то работа с API похожа на процесс заказа в ресторане: вы делаете заказ (запрос), а затем получаете ваш заказ от официанта (ответ). В контексте API заказ — это HTTP-запрос, который содержит свои инструкции и данные в нужном формате:

Основные HTTP-запросы:

• GET для запроса данных;
• POST для отправки новых данных на сервер;
• PUT для обновления уже занесённых данных;
• DELETE для удаления данных.

Форматы данных, используемые в API:

• JSON — упрощённый и более компактный формат выдачи информации;
• XML — более сложный формат по сравнению с JSON.

После отправки запроса вы получите ответ в формате JSON или XML. Что хорошо: ответ API будет содержать не только запрашиваемые данные, но и информацию об ошибках в формировании запросов.

Кстати, есть ещё формат данных — YAML. Он более ёмкий по сравнению с JSON и уж тем более по сравнению с XML.

Пример кода в JSON:

XML:

и YAML:

Основные виды API

Первое, что важно знать: что такое архитектурный стиль в программировании. Архитектурный стиль — это список всех компонентов кода, типов соединений между всеми частями и условий их соединения. Иными словами, это информация о том, как использовать конкретный фрагмент кода.

REST

Архитектурный стиль, который использует обычные HTTP-методы для обмена данными. RESTful-сервисы много где используются в кодинге: всё просто, гибко и понятно. RESTful-сервисы хороши ещё и тем, что с помощью них можно работать и с JSON, и с XML. А это означает, что они особенно популярны у разработчиков.

SOAP

Протокол для обмена сообщениями между двумя сервисами. SOAP подчиняется строгим стандартам W3C и работает только с XML, а точнее с SOAP XML. Более надёжный и безопасный вид API, особенно для выполнении сложных программных транзакций, но требует больше времени и усилий за счёт того, что SOAP XML-ответы нужно правильно обрабатывать и анализировать.

GraphQL

Язык запросов от Нельзябука, альтернатива REST. GraphQL хорош тем, что он даёт возможность точечно запрашивать данные из API, увеличивает результативность запросов за счёт возможности извлечения только тех данных, которые действительно нужны. Плюс можно добавлять дополнительные поля в GraphQL без изменения серверной части.

WebSocket

Протокол бесперебойной отправки и получения сообщений между клиентом и сервером через одно соединение TCP. WebSocket можно пользоваться для работы чатов, игр и веб-сервисов, где важно отправлять сообщения и получать ответы в настоящем времени.

REST использует API для простых веб-приложений, SOAP — для сложных решений (особенно корпоративных), GraphQL хорош гибкостью получения данных, а WebSocket подойдёт для сервисов, где нужно в режиме реального времени обрабатывать запросы.

Принципы работы API

Как уже говорилось выше, API работает как посредник между сервисом и клиентом, позволяя им обмениваться необходимыми данными. API упрощает интеграцию сервисов и систем с помощью стандартизированного подхода к «общению» сервиса и клиента.

Как устроен запрос и ответ

Основные HTTP методы, которые используются для отправки запросов к API:

• GET используется для получения информации из базы данных сервера. Для открытия страницы сайта в браузере нужно получить все данные сайта и преобразовать их в «готовый» вид — по такому же принципу работает GET.
• POST для отправки новых данных на сервер. Например, несколько новых пользователей зарегистрировалось на сайте — POST автоматически отправляет все данные о новом реге на сервер.
• PUT для обновления уже занесённых данных. Например, пользователь уже был зарегистрирован на сайте, но решил сменить ник и заодно обновить аватарку. С помощью PUT все данные отправляются на сервер.
• DELETE для удаления данных. Та же аналогия: пользователь удалил информацию из раздела «Любимые фильмы» — эти данные стираются и с сервера.

Форматы данных

Форматов данных существует много. Два самых популярных формата — это JSON и XML.

JSON — более легковесный формат. Он проще для чтения и понимания человеком и понятнее для обработки машиной. Именно поэтому он и популярен.

XML — более сложный формат с большим количеством тегов. Используется в «формализованных» системах, в том числе и в корпоративных.

Как начать работать с API?

Первый шаг — подключиться к платформе, которая предоставляет API, и получить API-ключ. Этот ключ будет идентификатором вашей учетной записи и даст серверу доступ к запрашиваемой вами информации.

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

Для работы с API можно использовать разные специализированные инструменты, например, Postman и curl, которые автоматизируют процесс отправки запросов и получения ответов — при этом код писать не нужно.

Postman — это программа для тестирования API. Postman поддерживает разные форматы данных и методы HTTP. С помощью Postman можно настраивать параметры аутентификации и просматривать все полученные ответы.

Как работать с Postman:

• Откройте приложение Postman;
• Создайте новый запрос;
• Введите URL-адрес API;
• Укажите метод запроса;
• Добавьте API-ключ в заголовке запроса;
• Нажмите «Send» для отправки запроса.

curl — это командная строка для передачи данных, которая использует различные сетевые протоколы и пользуются API. Curl особенно часто используют для автоматизации задач или при работе с Linux.

Интеграция API в коде

После того, как тестирование запросов прошло успешно, можно переходить к интеграции API. Вот два примера интеграции — для Python и JavaScript.

Python:

JavaScript:

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

Практическое использование API

В этой части рассмотрим применение API на практике на примере запроса данных о погоде из публичного API и узнаем, как работать с токенами и авторизацией OAuth 2.0.

Пример запроса данных из публичного API

Возьмём пример запроса данных о погоде через OpenWeatherMap, сервис о погоде.

Шаги запроса:

• Регистрация на сайте OpenWeatherMap и получение API-ключа. Например, чтобы получить данные о текущей погоде в Москве, нужно составить запрос следующего вида: http://api.openweathermap.org/data/2.5/weather?q=Moscow&appid=ВАШ_API_КЛЮЧ

• Используя Python и библиотеку requests, можно отправить запрос следующим образом:

• Ответ от сервера приходит в формате JSON.

Частичный пример ответа:

Работа с токенами и OAuth 2.0

OAuth 2.0 — протокол авторизации, который даёт сторонним приложениям ограниченный доступ к данным пользователя без передачи пароля.

Как работать с OAuth 2.0:

• Создайте учетную запись разработчика;
• Зарегистрируйте ваше приложение на платформе, которая поддерживает OAuth 2.0;
• Предоставьте доступ к вашему приложению;
• После авторизации ваш сервер получает временный код, который затем обменивается на токен доступа:

Используя полученный токен доступа, ваше приложение может делать запросы к защищённым ресурсам пользователя.

Советы и лучшие практики

Чтение документации API

Знакомство с документацией API — это первый шаг в работе с API. Документация содержит все важные сведения о ресурсах, запросах и параметрах.

Прежде чем уходить в детали, важно понять общие принципы работы конкретного выбранного API — какие ресурсы вообще есть, какая у них иерархия и какие методы используются для обмена сообщениями.

В правильно оформленной документации всегда можно найти примеры запросов и ответов. Так вы сможете лучше понять основы работы с API и на базе шаблонов разработать собственные решения.

A FAQ поможет быстро решить типичные «стартовые» проблемы.

Обработка ошибок и исключений

Ошибки — основа работы с любым приложением, база. Если правильно обрабатывать ошибки, то вы как разработчик сможете лучше понимать, что происходит и на каком этапе, по какой причине была допущена ошибка.

Несколько советов по обработке ошибок и исключений:

• Проверка кодов состояния HTTP. Ошибка 200 или 404 — это и есть коды состояния HTTP. С помощью них можно быстрее понять, где именно затаилась проблема.
• Try-catch блоки. При работе с Python или JavaScript важно использовать try-catch блоки для поиска и устранения ошибок выполнения.
• Логирование ошибок и исключений с указанием времени их возникновения и деталей запроса поможет в анализе проблем.

Оптимизация запросов для минимизации нагрузки

Оптимизация запросов сильно снижает нагрузку на серверы и повышает производительность приложения. Базовые советы:

• Использовать кэширование ответов от серверов по максимуму — так вы избежите повторных реквестов к одному и тому же ресурсу и сократите время ожидания ответа.
• По возможности объединять несколько запросов в один для уменьшения количества сетевых обращений.
• Запрашивать только те данные, которые нужны в данный момент времени с помощью фильтрации.

Работа с API требует особой внимательности, терпеливости и понимания основ взаимодействия систем. Читайте документацию, изучайте FAQ, вовремя обрабатывайте ошибки, оптимизируйте запросы, выбирайте подходящий вид API и наиболее понятный для вас формат данных — так вы создадите приложение с высокой производительностью. И не забывайте всегда самосовершенствоваться.

Протоколы позволяют устройствам успешно связываться друг с другом и обмениваться данными независимо от различий в архитектуре и дизайне.

Узнаем, какие сетевые протоколы используются сейчас и какие применялись ранее, чем стандарт HTTP/1.1 отличается от более поздних версий, как внедряются протоколы нового поколения и каковы их перспективы.

HTTP/1.1: Первый стандарт

Основа цифрового мира — информация. Протоколы HTTP делают ее доступной для пользователя. Речь идет о правилах передачи гипертекста, на которых основана работа веб-ресурсов. Протокол HTTP регламентирует взаимодействие браузеров с серверами при загрузке страниц, картинок, видео и прочих данных.

За время существования интернета сетевые протоколы существенно изменились. Произошла эволюция, которая сделала загрузку страниц быстрее, а передачу данных — более надежной.

Ранняя история

Развитие протоколов началось не с HTTP/1.1, а с более ранних версий. Стоит кратко рассмотреть первые шаги на этом пути, прежде чем говорить о технологиях, которыми мы пользуемся сегодня. Выясним, какие основные сетевые протоколы существовали и как они развивались.

Еще в 1991 году, когда создавалась концепция современного интернета, разработчики задумались над эффективной системой передачи файлов. Модели сетевых протоколов в то время уже существовали, дело было за продуктом прикладного уровня.

Первым протоколом стал HTTP/0.9, который использовал сетевую модель управления передачей TCP в качестве транспортного слоя. HTTP/0.9 был задействован только в передаче гипертекста — это единственная концепция представления данных, которая существовала на тот момент.

Простой однострочный протокол HTTP/0.9 был максимально простым в плане реализации и мог работать из командной строки. Принципы, по которым работал этот инструмент, используются по сей день.

Однако уже через несколько лет после запуска HTTP/0.9 перестал удовлетворять потребности пользователей. Кроме гипертекстовых документов, требовался показ изображений и воспроизведение звуковых файлов, с чем протокол явно не справлялся. Не было также возможности использовать прокси-серверы для увеличения трафика.

Указанные выше проблемы были частично исправлены в HTTP/1.0, реализованном в 1995 году после первой всемирной конференции World Wide Web. Рабочая группа, созданная по итогам встречи разработчиков и представителей ИТ-индустрии, занялась вопросами развития сетевых протоколов. Сайты MTV, Amazon, Microsoft и других крупных компаний к тому времени уже были запущены и нуждались в развитии инфраструктуры.

Ресурсы работали через HTTP/1.0 поверх TCP, при этом новый протокол был ориентирован на графические браузеры. Для передачи метаданных клиент и сервер использовали заголовки, задающие тип передаваемых данных. Таким образом, по протоколу, кроме гипертекста, можно было передавать графические, аудио и другие файлы. Инструмент поддерживал кэширование, аутентификацию, передачу через прокси типа SQUID и шлюзы.

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

Запуск HTTP/1.1

К концу прошлого века программисты приступили к поиску альтернатив. Перед ними стояли вполне конкретные задачи:

• сократить избыток TCP-соединений;
• повысить эффективность и скорость передачи данных;
• увеличить возможности кэширования;
• сократить использование IP-адресов;
• стандартизировать методы доставки веб-приложений;
• установить контроль над расширениями к протоколу;
• обеспечить совместимость веб-приложений.

Все эти проблемы были в той или иной степени решены в 1999 году с выходом HTTP/1.1. Это стандарт сейчас известен всем разработчикам и частично продолжает использоваться. Текстовый протокол с расширенной семантикой предыдущих версий работал поверх TCP с помощью опционального слоя шифрования SSL/TLS.

Алгоритм работы HTTP/1.1 следующий:

1. Клиент (компонент, отправляющий запрос) устанавливает соединение через TCP и согласует SSL/TLS-связи.
2. Сервер получает от клиента строку с методом, маршрутом к документу и версией протокола.
3. Далее клиент отправляет заголовки в нужном формате, уведомляет при необходимости о поддержке стабильных подключений и может попросить сервер не прекращать соединение после завершения запроса.
4. Сервер в ответ отправляет версию протокола, часть строки со статус-кодом, по возможности тело ответа.
5. Если обе стороны поддерживают постоянные подключения, соединение TCP не закрывается, что решает проблему избыточного использования этой сетевой модели.

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

Еще одной сложностью было отсутствие полноценной поддержки параллелизма. Передача многих файлов одновременно требовала привлечения дополнительных ресурсов.

Разработчики обращали внимание на блокировку Head-of-Line (начала очереди). Такая ситуация возникает, когда один объект с низкой скоростью задерживает весь поток. Аналогия с кассой супермаркета, когда покупатели с единичными покупками ждут, пока рассчитается один клиент с огромной тележкой товаров, в полной мере отражает суть проблемы.

Расширения, которые использовались для обхода блокировок и задержек, не были эффективными в достаточной степени. Поэтому уже с середины 2000-х шла работа над альтернативными решениями

HTTP/2: Большой шаг вперед

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

Возникла настоятельная потребность в новых протоколах. В начале 2010 разработчики Google создали экспериментальное решение SPDY — альтернативный вариант для обмена данными. Протокол повышал скорость отклика и решал проблему удвоения данных. Именно он стал основой для HTTP/2.

Характеристики и преимущества протокола HTTP/2

Ключевое отличие от предшественников в том, что HTTP/2 — бинарный протокол, а не текстовый, то есть применяет двоичный формат для передачи данных. Поскольку информацию не нужно трансформировать в текст, радикально увеличивается скорость взаимодействия клиента и сервера, упрощается загрузка файлов любого типа, в том числе аудио и видео.

Официальный стандарт HTTP/2 был представлен в 2015 году, а к 2022 на нем уже работала почти половина всех сайтов. Ресурсы с высокой посещаемостью почти в полном составе перешли на этот протокол с целью экономии средств на передаче данных.

Относительно быстрое внедрение нового стандарта объясняется просто — при использовании HTTP/2 не нужно вносить изменения в код сайтов и веб-приложений. Нужен только современный сервер, который взаимодействует с актуальной версией браузера. В процессе обновления сетевых ресурсов и хранилищ использование протокола реализуется естественным образом.

Вот основные плюсы HTTP/2:

• HTTP/2 — мультиплексированный протокол, поэтому параллельные запросы могут исполняться через одно и то же соединение. Это отменяет блокировки начала очереди Head-of-Line — не нужно дожидаться прохождения предыдущего запроса перед отправкой следующего.
• Сжатие заголовков, которые часто совпадают в разных запросах, устраняет дублирование и экономит трафик — лишние данные не передаются, только нужные.
• Функция Server Push. Эта технология прогнозирования списка ресурсов, которые могут понадобиться клиенту в ближайшее время, и их предварительное продвижение.
• Безопасность данных. Протокол не требует обязательного шифрования HTTPS, но большинство браузеров делают это автоматически, что повышает уровень безопасности при обмене данными.
• Установка приоритетов. Сторона клиента может указывать приоритет запроса, на что сервер отвечает соответственно — отправляя в первую очередь более важные ресурсы.

Версия HTTP/2 ускоряет загрузку страниц, позволяет отправлять множество запросов одномоментно через одно соединение, снижает затраты ресурсов, делает более эффективным и приятным серфинг в сети. Загрузка сайтов становится быстрой даже на мобильных гаджетах с нестабильным интернетом.

Поддержка и перспективы

Внедрение протокола второго поколения пошло на пользу и разработчикам. Теперь создание и реализация веб-проектов стали более простыми процедурами. В свою очередь улучшение пользовательского опыта и SEO — это рост монетизации ресурсов и увеличение коммерческой отдачи от проектов.

Специалисты отмечают, что преимущества HTTP/2 для поисковой оптимизации связано с техническими особенностями протокола. Быстродействие сайта входит в число важных факторов ранжирования. Медленный ресурс вряд ли понравится клиентам. Практика показывает, что внедрение нового протокола повышает скорость загрузки на 50-80%. Посетители имеют меньше проблем при навигации и использовании интерактивных функций.

Чтобы перейти на HTTP/2, требуется поддержка со стороны клиента и браузера. Почти все современные браузеры в актуальных версиях созданы с автоматической поддержкой стандарта. Постепенно обновляется ПО серверов и сетей доставки. Издержки и затраты времени на обновление невелики в сравнении с плюсами, которые дает скорость и производительность HTTP/2.

HTTP/3: Протокол нового поколения

Разработка нового протокола началась еще в 2018 году. При этом экспериментальный стандарт QUIC, на котором основан HTTP/3, компания Google создала еще в 2012. Именно благодаря транспортному протоколу QUIC технология нового поколения получила свои преимущества и уникальные качества.

HTTP/3 — улучшенная версия предыдущих стандартов, которая со временем заменит их благодаря еще более высокой скорости и надежности. Поскольку HTTP/2 использует TCP, это накладывает определенные ограничения на быстроту передачи данных.

Транспортный протокол QUIC — это разработка на базе UDP (User Datagram Protocol), которая оперирует собственными, принципиально иными механизмами управления данными, контроля и исправления ошибок.

Основные преимущества протокола нового поколения:

• Ускоренное соединение. QUIC использует взаимный обмен приветствиями (handshake) уменьшенной длины в сравнении с TCP, поэтому передача данных начинается быстрее.
• Уменьшение задержки. Транспортный протокол оптимизирован для работы в условиях нестабильного интернета — это положительно влияет на пользовательский опыт.
• Высокая пропускная способность. QUIC более эффективно использует возможности сети, даже если происходят потери пакетов.
• Повышенная безопасность. Используется шифрование TLS 1.3, что делает передачу данных более безопасной.
• Повышение качества веб-ресурсов. Внедрение протоколов выводит разработку онлайн-сервисов на новый уровень. Быстрая загрузка, беспроблемная передача звука и видео — все это ускоряет создание новых проектов и повышает их эффективность.

Хотя HTTP/2 позволяет загружать за раз сразу несколько ресурсов, его модель TCP не особенно подходит для мультиплексирования. Причина в том, что при провале одного запроса, браузеру приходится вместе с ним повторять и остальные. В HTTP/3 эта проблема решается более рационально — повторяется только проблемный запрос, что существенно не влияет на скорость соединения.

Зачем нужен HTTP/3, если есть протокол второго поколения? Эксперты говорят, что необходимость в новом стандарте, основанном на транспортном протоколе QUIC, назрела практически сразу после повсеместного распространения интернета. TCP изначально работал на максимуме продуктивности, поэтому имел существенные ограничения.

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

Реализация и поддержка HTTP/3

В 2024 году протокол HTTP/3 поддерживают многие популярные браузеры. В Chrome стандарт используется в большинстве подключений к серверам. Подключение через HTTP/3 применяют также Firefox, Safari, Microsoft Edge и другие браузеры.

В настоящий момент этот протокол поддерживают миллионы самых популярных онлайн-ресурсов, и это количество постоянно растет. Кроме компании Google, которая принимала активное участие в разработке нового стандарта, протокол использует, например, платформа CloudFlare — ее опции без использования серверов совместимы с HTTP/3. Активные пользователи протокола — компании Akamai, Fastly, Amazon и многие другие.

Существенным преимуществом HTTP/3 для последующего распространения выступает его полная зашифрованность. Посредники (прокси) в сети не замечают и не интерпретируют его работу, как случае с TCP, поэтому новые версии протокола и новые фичи будут работать корректно на любых устройствах сразу после их обновления.

Итоги — будущее сетевых протоколов

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

Потребуется также оптимизация для IoT — интернета вещей. Таких устройств становится все больше, растет и необходимость в эффективных протоколах для них. В этом направлении разработка стандартов ведется особенно интенсивными темпами.

Становится все более актуальным применение искусственного интеллекта в совершенствовании сетевых протоколов. Машинное обучение и ИИ могут быть использованы для оптимизации различных уровней сетевого взаимодействия для повышения производительности и безопасности.

Что такое модель OSI: основные принципы

Модель OSI (Open Systems Interconnection) представляет собой структурированный подход к организации работы сетевых протоколов и устройств. Разработанная Международной организацией по стандартизации (ISO), эта модель определяет семь уровней взаимодействия, каждый из которых выполняет определенные функции. Вот как выглядят эти семь уровней:

Уровни модели OSI и их функции

Уровень 1: Физический уровень (Physical Layer)

Физический уровень обеспечивает физическую передачу данных по среде связи. Он определяет характеристики кабелей, разъемов, протоколов передачи и другие аспекты физической связи. Этот уровень отвечает за преобразование данных в сигналы, которые могут передаваться по физической среде. Примеры: Ethernet-кабели для проводной передачи данных, оптоволокно для передачи данных по световым сигналам, USB для подключения устройств к компьютеру.

Уровень 2: Канальный уровень (Data Link Layer)

На канальном уровне происходит передача данных между соседними устройствами в сети. Он отвечает за создание фреймов, адресацию устройств, контроль доступа к среде и обнаружение ошибок. Этот уровень гарантирует, что данные успешно доставлены между устройствами в одной сети. Примеры: Ethernet для проводной сетевой передачи данных, Wi-Fi для беспроводной передачи данных.

Уровень 3: Сетевой уровень (Network Layer)

Сетевой уровень занимается маршрутизацией данных в сети. Он определяет оптимальный путь для передачи данных между различными сетями и устройствами. Здесь также осуществляется управление потоком данных и контроль ошибок в пределах сети. Примеры протоколов: IP (Internet Protocol) для маршрутизации данных между сетями, ICMP (Internet Control Message Protocol) для передачи сообщений об ошибках и управления сетью.

Уровень 4: Транспортный уровень (Transport Layer)

Транспортный уровень обеспечивает надежную доставку данных от одного узла до другого. Он отвечает за разделение данных на пакеты, контроль ошибок, управление потоком данных и обеспечение доставки в правильной последовательности. На этом уровне протоколы обеспечивают механизмы для установки, поддержания и завершения соединений. Примеры протоколов: TCP (Transmission Control Protocol) для надежной доставки данных в правильной последовательности и контроля ошибок, UDP (User Datagram Protocol) для передачи данных БЕЗ гарантии доставки.

Уровень 5: Сеансовый уровень (Session Layer)

На сеансовом уровне устанавливаются, поддерживаются и завершаются сеансы связи между приложениями. Этот уровень контролирует взаимодействие и синхронизацию между приложениями, предоставляя средства для управления сеансами. Он также отвечает за управление диалогами и обеспечивает восстановление связи при сбоях. Примеры: NetBIOS для управления сеансами в Windows сетях, SSH для безопасного удаленного доступа.

Уровень 6: Представительский уровень (Presentation Layer)

Представительский уровень занимается преобразованием данных в удобный для обмена формат. Он обеспечивает сжатие данных, кодирование, декодирование и шифрование. Это позволяет обеспечить совместимость между различными форматами данных, так как приложения могут использовать различные форматы для представления информации. Примеры: JPEG для сжатия изображений, MPEG для сжатия видео, а также технологии для защиты данных SSL (Secure Sockets Layer) и TLS (Transport Layer Security).

Уровень 7: Прикладной уровень (Application Layer)

На прикладном уровне происходит взаимодействие пользовательских приложений с сетевыми службами. Этот уровень предоставляет интерфейс для приложений, что позволяет программам обмениваться данными через сеть. Здесь работают протоколы, позволяющие обмениваться данными между программами и пользователями. Примеры протоколов: HTTP для передачи веб-страниц, SMTP для отправки электронной почты.

Применение модели OSI в современных сетях

Модель OSI служит основой для понимания взаимодействия устройств в компьютерных сетях. Сетевые инженеры используют эту модель для разработки, настройки и поддержки сложных сетевых инфраструктур. Она помогает им лучше понимать принципы работы различных протоколов и их влияние на производительность и безопасность сетей.

Заключение

Модель OSI остается неотъемлемой частью мира компьютерных сетей. Её понимание позволяет сетевым специалистам строить эффективные и надежные сети, а также успешно диагностировать и решать проблемы в сетевых инфраструктурах. Надеюсь, что данная статья помогла вам лучше разобраться в этой важной теме.

Основная задача популярной технологии WebRTC — передавать потоковые данные (иными словами, звонить) от одного браузера или приложения к другому по принципу «точка-точка».

Рынок этой технологии растёт на 35,3% в год и по прогнозу за десять лет может вырасти в 20 раз. WebRTC работает почти во всех известных браузерах, поэтому изначально разработчики планировали использовать эту технологию вместо SIP-телефонии. Такое решение сделало бы работу с виртуальной АТС проще и легче. Из-за отличий между системами заменить SIP-телефонию не получилось.

Отличия между WebRTC и SIP-телефонией

Для простых пользователей:

• Стандарт WebRTC работает почти во всех браузерах, и даже документация есть.
• Софтфоны нужно отдельно загружать на ПК, так как это программное обеспечение.

Для технического инженера или сисадмина:

• Все программное обеспечение компании должно поддерживать стандарт WebRTC. А еще — телефонный оператор и виртуальная АТС. Только у четырёх телефонных операторов есть возможность использовать эту систему в браузерах.
• SIP-протокол — это стандарт, который поддерживают все ПО и аппаратура.

Может ли WebRTC заменить SIP-софтфон

Да, но не во всём. WebRTC-телефоны по некоторым параметрам превосходят SIP.

Работают через браузер без отдельной установки. Для звонка нужно открыть ссылку и войти в свой аккаунт на платформе, где совершается разговор. Телефон загрузится и можно общаться — это доступно пользователям любых ПК

Однако для колл-центров этот факт не так важен. Операторы нечасто меняют ПК, поэтому возможность запуска программы без установки для них не такой уж очевидный плюс. К тому же современные софтфоны загружаются примерно за минуту, когда пользователь делает настройку рабочего пространства, и весят не более 20 МБ (гораздо меньше, чем Skype и Microsoft Office).

WebRTC не нужно настраивать в браузере. Как только будет открыта страница с телефоном, нужно дать разрешение на доступ к микрофону. Но в каждом профессиональном софтфоне есть удалённая настройка. Специалист колл-сервиса заходит в софтфон, авторизуется, и все нужные настройки уже в приложении. Ни операторы, ни сисадмины сами не вводят настройки. Можно сразу звонить в настроенном приложении.

Плюсы SIP-телефонов перед WebRTC

Технически WebRTC не работает на маломощных ПК или возможны утечки памяти. Через два часа активной работы телефон увеличится в два раза и система может тормозить.

Не в каждом колл-центре или у удалённых работников есть ПК с требованиями, которых достаточно для использования WebRTC. Это отдельная тема для обсуждений. Расширить ОЗУ на устаревших ПК не получится. А при заполнении памяти оператор и клиент плохо слышат друг друга, постоянно требуется перезагрузка программы. Есть два выхода: замена устройств на более современные и использование программы, которая меньше весит.

К примеру, Softphone.Pro займёт всего 100 МБ и не увеличивается в объёме. Эта программа может легко работать даже на маломощных ПК, которыми пользуются удалёнщики.

На WebRTC-телефоне не поддерживается работа одновременно с разными SIP-аккаунтами. А есть центры звонков, для которых это принципиально важно. Например, когда сервис относится к нескольким офисам одной компании в разных точках страны. У каждого города — свой аккаунт. Поэтому оператору нужно не только видеть, откуда поступает исходящий звонок, но и самому делать вызовы с номера конкретного города (заказчику из Твери — с тверского).

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

В WebRTC не работают многие стандартные функции телефонов. Например, невозможно удерживать и переводить вызовы, создавать конференции. SIP-софтфоны не имеют таких сложностей. У них есть всё опции для работы с облачными АТС, специальным ПО для колл-центров. Перечислим некоторые из них:

• Быстрые переключения звонков.
• Условный автоматический ответ.
• Удержание и снятие вызова.
• Создание конференции максимум из шести абонентов.
• Включение аудиосообщений.
• Запись звонков.
• Открытие статусов сотрудников.
• Параллельное включение двух линий звонка.

WebRTC для кого

В WebRTC нет опций, необходимых для всех колл-центров. Например, оптимизации расписания операторов, записи с экранов или съемки с камеры.

WebRTC-телефония не всегда решает главные задачи:

• Не интегрируется с основными гарнитурами и приложениями. Следовательно, нет звонков в одно нажатие, нет всплывающих карточек
• Нет стереозаписи менеджера и клиента в разных каналах, а значит, невозможно распознавать речь.

WebRTC-телефония больше подходит для отдельных сотрудников компаний, которые редко совершают звонки. Чаще всего это руководители и бухгалтеры. А вот менеджерам колл-центров больше подходят сервисы с SIP-телефонией, особенно если речь идёт про API. Так легче переварить большой объём трафика и гибко выстроить сценарии.

Они могут легко интегрироваться с другими программами, записывать экран ПК, отслеживать работу операторов, поддерживают профессиональные гарнитуры и могут работать сразу с нескольких аккаунтов.

Гибкость и свобода

SIP обладает большей гибкостью на уровне протокола, а WebRTC — на уровне приложений. С большей гибкостью у вас есть больше свободы для инноваций, но, к сожалению, и больше проблем с совместимостью. SIP, например, позволяет использовать описание сеанса без SDP, применять медиатранспорт на основе RTP, SRTP или ZRTP. О них подробнее можете почитать здесь.

WebRTC предписывает множество таких элементов в протоколе, например, работу с SDP, SRTP, ICE и так далее. В будущем, если придумают медиатранспорт получше, спецификацию придётся изменить.

Благодаря вот той же гибкости SIP люди создали сотни различных реализаций, используя один и тот же базовый протокол. WebRTC не в силах помочь реализовать нетривиальный медиаканал, вроде многоадресной рассылки на уровне приложения или LAN по локальной сети, или позволить веб-приложению работать с text-to-speech.

Гибкость протокола SIP имеет свою цену — нет гарантии таких функций, как безопасность или общие кодеки в разных реализациях.

Заключение

Многие существующие приложения на основе SIP, вероятно, воспользуются WebRTC, если возникнет спрос. Точно так же новые веб-приложения, основанные исключительно на WebRTC, вероятно, будут включать SIP-шлюз для доступа к пользователям без браузера, если, опять же, будет спрос.

SIP или WebRTC сами по себе — это лишь небольшая часть головоломки. Тем не менее, WebRTC пытается заполнить пустоту, которая уже давно витает в мире SIP-связи.

Что такое NB-IoT?

Технология NB-IoT многое унаследовала от LTE, начиная с физической структуры радиосигнала и заканчивая архитектурой. При передаче сигнала LTE используется механизм разделения каналов OFDM с разнесением поднесущих на 15 кГц. В DL (Downlink, направление от БС) используется OFDMA, а в UL (Uplink, направление на БС) используется SC-FDMA.

Для достижения большой пропускной способности соты применяются высокие порядки модуляции QAM256 для DL и QAM64 для UL. Вдобавок с этой же целью применятся технологии MIMO2x2 и MIMO4x4.

Для обозначения величины падающей мощности DL, помимо значений RSSI и RSRP, используется значение падающей мощности EPRE (Energy Per Resource Element), то есть значение мощности для одного RE (Рисунок 3.1).

Радиочастоты NB-IoT и методы выделения частотного ресурса

Для NB-IoT могут использоваться практически все те же диапазоны частот, что и для 2G/3G/4G в нижних частотных диапазонах 800-1880 МГц. В Российской Федерации для NB-IoT выделены три диапазона. Это B20 (800МГц), B8(900МГц), B3(1800МГц).

Более высокочастотные диапазоны обычно не используются из-за большего затухания сигнала.

На практике применяются три режима выделения частотного ресурса для NB-IoT:

• Stand-alone;
• In-band;
• Guard-band.

Режим Stand-alone является самым эффективным для работы NB-IoT, но и самым затратным. В этом режиме под NB-IoT выделяется частотный канал шириной 200 кГц. Для этого может понадобиться от 300 до 600 кГц ценного радиочастотного спектра, чтобы обеспечить требуемые защитные интервалы. И взаимные интерференции с другими технологиями минимальны.

В режиме In-band для NB-IoT выделяются ресурсы внутри существующей LTE-несущей, но NB-IoT-несущая имеет на 6 дБ более высокую мощность по сравнению с ресурсными блоками LTE. Этот вариант хорошо подходит для экономии частотного ресурса, но при этом есть проблема взаимного влияния с LTE-сетью.

В режиме Guard-band несущая NB-IoT располагается в защитном интервале несущей LTE. Например, в полосе LTE 10 МГц ширина защитного интервала с обеих сторон несущей составляет 500 кГц. Так же, как и в режиме In-band, несущая NB-IoT имеет на 6-9дБ более высокую мощность по сравнению с ресурсными блоками LTE (Рисунок 4). Этот вариант использования позволяет одновременно сэкономить частотный ресурс и уменьшить взаимное влияние с LTE сетью, хотя при этом ухудшаются параметры внеполосных излучений для LTE.

Особенности радиосигнала NB-IoT

Самое важное в NB-IoT — возможность работы при более низких уровнях сигнала и высоком уровне шумов, а также экономия батареи. NB-IoT предназначен для передачи коротких сообщений, и от него не требуется передача аудио-видео контента, больших файлов.

Исходя из этого, на физическом уровне в сигнал NB-IoT заложены особенности, которые помогают обеспечить необходимые характеристики:

• общая полоса для NB-IoT ограничена одним ресурсным блоком шириной 180 кГц;
• радиотракт устройства NB-IoT чаще всего использует только одну антенну;
• передача и приём разнесены по времени, то есть используется полудуплексный режим;
• существует возможность передавать в направлении UL на одной поднесущей;
• используемые типы модуляции ограничены BPSK и QPSK;
• используется механизм переповторов передаваемой информации (Сoverage Enhancement).

Это позволяет:

• снизить требования к процессорной мощности хост-контроллера (некоторые разработчики предпочитают не устанавливать в устройство отдельный хост-контроллер, а используют для выполнения прикладных программ контроллер радиомодуля);
• минимизировать энергопотребление, за счёт чего увеличивается срок работы устройства без замены элемента питания;
• уменьшить габариты;
• удешевить устройство.

У NB-IoT есть существенное преимущество по сравнению с сетям 2G/3G/4G в части зоны покрытия и проникновения сигнала в труднодоступные места (например, подвалы и помещения с коммуникациями в зданиях). Оно обеспечивается более помехоустойчивыми сигналами, благодаря применению узкополосных сигналов, а также встроенным механизмом переповтора передаваемых пакетов данных.

Остальные плюсы NB-IoT по сравнению с другими технологиями передачи данных.

• Расширенная зона покрытия и глубокое проникновения сигнала в труднодоступные места (например, подвалы, колодцы, технические помещения). Преимущество обеспечивается улучшенной характеристикой сигнал/шум вследствие узкополосного сигнала, используемой модуляцией, а также функцией переповторов при передаче пакетов данных.
• Технология NB-IoT от МТС имеет выделенный ресурс сети, а значит приоритет в обслуживании не может быть отдан абонентам со смартфонами в периоды высоких нагрузок на сеть.
• Существует общемировая тенденция по сокращению ресурсов, выделяемых операторами на устаревающие технологии 2G/3G. В этой связи и с учетом долгого срока жизни устройств интернета вещей целесообразно рассматривать современные и перспективные технологии, как раз такой и является NB-IoT.
• В технологии NB-IoT реализован режим передачи данных NIDD, который на сегодня является самым эффективным и функциональным для LPWAN устройств.

Максимально достижимая скорость передачи данных

Максимально достижимую скорость передачи данных в канале NB-IoT удобно показать в зависимости от Coupling Loss – уровня полных потерь в канале связи.

Как видно из таблицы, увеличение помехоустойчивости сигнала NB-IoT обратно пропорционально скорости передаваемой информации. Поэтому максимального выигрыша можно достичь, только обмениваясь по сети пакетами данных достаточно маленького размера, которые можно передать в разумный промежуток времени. В дополнение, при разработке ПО для устройств нужно учесть, что в режиме CL2 передача даже одного пакета может занимать несколько секунд.

В 14-м релизе рекомендаций 3GPP, появился функционал extended TBS и Dual-HARQ, позволяющий увеличить скорость передачи информации до 159 кбит/с. Для реализации этого режима нужно использовать радио-модули категории NB2. При этом стоит учитывать, что преимущества NB2 по скорости реализуется только при достаточно хороших радиоусловиях, а в плохих — разница практически отсутствует.

Радиомодули новой категории NB2 также позволяют ещё более уменьшить энергопотребление и увеличить срок работы устройства без замены элемента питания за счет использования максимальной мощности передачи в 14 dBm. Для сравнения, максимальная мощность передачи предыдущей радио-модулей категории NB составляет 20, 23 dBm

Представленные цифры условны и зависят от конфигурации сети, и реальное проникновение сигнала зависит ещё и от качества и коэффициента усиления антенны устройства.

Поэтому при разработке приложений для устройств рекомендуется придерживаться определённых значений объёма и частоты передаваемых сообщений. Например, для LPWA приложений 3GPP определяет следующие модели трафика:

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

Основные критерии при выборе технологии NB-IoT для разрабатываемого устройства:

• энергоэффективность — устройство должно работать от одного комплекта батарей длительный срок, до 10 лет и более;
• надёжность передачи данных, защищЁнность канала связи;
• подключение большого числа устройств в одной локации;
• стоимость устройства;
• наличие сети доступа во всех регионах РФ;
• развитие и поддержка сети в течение долгого времени.

Выбор протоколов транспортного уровня

При выборе используемого протокола в первую очередь необходимо учитывать избыточность протокола и накладные расходы на установление и поддержание соединения:

В сетях NB-IoT рекомендуется применять следующие способы передачи данных в порядке убывания предпочтения:

• режим передачи NIDD (Non-IP data delivery);
• протокол передачи данных CoAP (стек IP/UDP);
• протоколы MQTT-SN и LWM2M 1.1 (стек IP/UDP);
• проприетарные бинарные протоколы, основанные на UDP.

Стоит отметить, что одно и то же устройство может работать как в режиме IP, так и в режиме NIDD, текущий режим работы зависит от активированного контекста (Non-IP или Ipv4/IPv6). Для работы с IP и NIDD используются различные виды тарификации: для IP пакеты, измеряемые в килобайтах, для NIDD пакеты, измеряемые в сообщениях.

Протоколы на основе UDP

Рекомендуется применение как проприетарных протоколов поверх UDP, так и специфицированных транспортных протоколов поверх UDP: CoAP, MQTT-SN, LWM2M.

Текущая практика разработки устройств показывает, что наибольшей популярностью пользуется протокол CoAP. Отчасти это обусловлено тем, что данный протокол поддерживается на уровне прошивки радиомодуля многими поставщиками. На примере этого протокола рассмотрим несколько механизмов, позволяющих реализовать функциональность для энергоэффективного устройства.

Протокол CoAP построен на основе протокола HTTP, использует те же методы (POST, GET и другие), то есть протокол позволяет публиковать данные, запрашивать данные и выполнять другие запросы.

Реализован механизм квитирования (подтверждений), для этого используется атрибут CON или NON. Также протоколом предусмотрен механизм подписки: устройство может получить уведомление об изменении какого-либо параметра на сервере, для этого используется функция observe.

Протокол реализует стандартные ответы сервера на запросы, например, ответ 2.03 Valid говорит от том, что переданные данные успешно сохранены на сервере. Всё описанное выше — только малая часть возможностей протокола CoAP, но этого вполне достаточно, чтобы развеять сомнения разработчиков относительно возможности реализовать необходимую им функциональность, в том числе гарантированную доставку данных, с использованием UDP.

Пример последовательности АТ-команд для передачи данных по протоколу CoAP модуля Quectel BC68:

Основное отличие в передаче NIDD данных от передачи данных в IP стеке заключается в том, что устройству не выделяется IP-адрес и ему не нужно знать IP-адрес и порт сервера. Радиомодуль отправляет данные в сеть без какого-то определенного адресата, а сеть, в свою очередь, передаёт данные от устройства на платформу (Application Server) по подписке.

Из-за этого устройство выполняет меньше действий, чтобы передать данные. А значит уменьшается время нахождения приёмопередатчика в активном состоянии. И меньшему расходу батареи устройства.

С точки зрения сети использование NIDD также предпочтительнее, чем IP, так как устройства NIDD более эффективно используют ресурсы сети. Уменьшение общего объёма передаваемых данных, сокращение времени нахождения радиомодуля в активном состоянии позволяет обслужить больше устройств.

Вероятность успешной доставки информации тем выше чем меньше размер пакета, что особенно ярко выражается при низком уровне сигнала и/или большой зашумлённости канала.

Дополнительные преимущества даёт наличие сетевого элемента сети оператора — SCEF. Данный сетевой элемент реализует обмен данными с устройством посредством HTTP API и системы подписок. Проще говоря, платформа (Application Server) отправляет данные на устройство и получает данные с устройства, используя HTTP POST запросы на определенный URL.

Платформе не нужно хранить IP-адрес устройства и дополнительно идентифицировать его, получая запросы с различных IP-адресов, выделяемых устройству сетью. Коммуникация упрощается за счёт использования универсального идентификатора – external ID вида @, который присваивает устройству непосредственно разработчик.

Ещё одно важное преимущество NIDD — это большая безопасность в случае доступа извне: коммуникация с устройством из интернета возможна только через специальный узел (SCEF) и вероятность взлома устройства значительно понижается.

Кроме того, SCEF предоставляет дополнительные возможности для разработчика и пользователя платформы: отправка сообщения от платформы на группу устройств, отправка сообщения от устройства на несколько платформ, гарантированная доставка сообщений, буферизация сообщений, контроль состояния устройства (доступность) и другие возможности.

Пример АТ-команд для передачи данных по NIDD модуля Quectel BC68:

Сравнивая набор АТ-команд для отправки данных в CoAP/UDP и NIDD, можно увидеть, что реализовать NIDD проще с точки зрения управления радимодулем.

Для наглядности на рисунках 4.4 и 4.5 показано различие в архитектуре передачи данных IP и Non-IP для общего случая, когда платформа расположена вне инфраструктуры оператора связи.

Исследования специалистов МТС, также показали. значения нижних предельно допустимых уровней EPRE для трёх способов передачи данных по каналу «вверх» (Таблица 4.1). Значения EPRE действительны для гарантированной отправки пакета данных объемом 250 байт.

Элементы идентификации (SIM)

SIM-элементы бывают нескольких видов. В виде привычной и знакомой всем SIM-карты: (U)SIM-карта М2М NB-IoT Trio. Это SIM-карта, совмещающая три форм-фактора 2FF-3FF-4FF, говоря проще, стандарт-микро-нано.

Рекомендуем применять в устройствах SIM элементы в форм-факторе SIM-чипа, полное название (U)SIM-чип М2М термо NB-IoT MFF2. По сравнению с SIM-картой чип обеспечивает более длительную и надёжную работу устройства за счёт устойчивости к перепадам температур, влажности, вибрациям и так далее. Воздействие суровых условий окружающей среды вместе с долгим сроком использования устройств IoT — от 10 лет — делает выбор в пользу SIM-чипа предпочтительным.

В качестве примеров устройств, работающих в сложных условиях, можно привести датчики проникновения в колодцы, контроллеры индивидуального управления уличным светом, датчики ТКО (мусора), устройства экомониторинга.

Стоит отметить, что технология eSIM (embedded SIM) реализована как в форм-факторе SIM-чипа, так и SIM-карты.

Общая информация о радиомодулях

Бывает так, что производитель устройств начинает работать с радиомодулем NB-IoT и сталкивается с недопониманием, «поведение» модуля не соответствует ожиданиям. Чаще всего это связано с тем, что разработчики не разобрались с режимами и настройками модуля по умолчанию. Ниже приведено несколько советов, что можно сделать для устранения проблем.

• Рекомендуется устанавливать в настройках конкретные частотные диапазоны (band), соответствующие сети оператора. Для сети NB-IoT МТС нужно выбирать band 3, 20, 8. Причём некоторые модули позволяют задать перечень в порядке приоритета поиска сети. Для сети МТС нужно использовать приоритет, как указано выше, то есть первый частотный диапазон в очереди на поиск сети band 3, второй band 20, третий band 8. Указанная настройка позволит ускорить поиск и регистрацию в сети при первом включении радиомодуля.
• Мы столкнулись с тем, что многие модули по умолчанию активируют режим eDRX. Это также можно проверить и деактивировать этот режим, если он не нужен. Для совмещённых модулей, работающих в двух технологиях радиодоступа NB-IoT и 2G рекомендуется настроить логику по переключению между технологиями на уровне прошивки устройства, чтобы устройство само управляло включением той или иной технологии. При этом важно помнить, что пакет трафика актуальный для NB-IoT может быть израсходован быстрее при переходе в 2G в случае, если при этом также изменяется протокол транспортного уровня, включается TCP вместо UDP или NIDD.
• Параметр APN необходимо настраивать в соответствии с инструкциями от оператора. При работе в сети NB-IoT МТС рекомендуется настраивать в модуле APN: iot для стандартного подключения, когда не используется выделенный клиентский APN. Желательно контролировать контекст, который активирует радиомодуль при включении, это может быть IPv4/IPv6 или NIDD, или оба типа одновременно. Не нужно активировать контекст IPv4/IPv6, если вы планируете работать только в NIDD, эта проверка дополнительно активирует обмен служебными данными между устройством и сетью.

В целом на уровне устройства и на уровне прошивки управляющего контроллера желательно управлять состоянием и настройками радиомодуля и использовать соответствующие АТ-команды из мануала на модуль. Если проблему не удается решить стандартными средствами, стоит обратиться к поставщику радиомодуля, он расскажет, как включить debug-порт на модуле и выполнить более глубокую диагностику проблемы.

Типичные ошибки разработчиков

Несоблюдение процедур создания/удаления сессий

• Использование процедур Attach/создания сессии (Create PDN) при каждой новой передаче данных. Это существенно влияет на энергоэффективность устройства и повышает нагрузку на радиоресурсы.
• Попытка регистрации в сети (Attach) и создания сессии (Create non-IP PDN) без предварительного создания подписки на устройство на SCEF. Это приводит к отказу в регистрации в сети МТС NB-IoT и существенно влияет на энергоэффективность устройства. Повышает нагрузку на радиоресурсы.

Список источников

1. ГОСТ Р 59026-2020 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Протокол беспроводной передачи данных на основе стандарта LTE в режиме NB-loT. Основные параметры.
2. Приказ № 113 от 29.03.2019 Министерства цифрового развития и массовых коммуникаций Российской Федерации Об утверждении Концепции построения и развития узкополосных беспроводных сетей связи «Интернета вещей» на территории Российской Федерации.
3. Приказ № 315 от 22.06.2018 О внесении изменений в Правила применения абонентских терминалов сетей подвижной радиотелефонной связи стандарта LTE и его модификации LTE-Advanced, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 06.06.2011 № 128.
4. Протокол принятых решений Государственной комиссии по радиочастотам (ГКРЧ) от 28.12.2017.
5. GSMA white paper 3GPP Low Power Wide Area Technologies.
6. ETSI TR 103 055 Electromagnetic compatibility and Radio spectrum Matters (ERM); System Reference document (Srdoc): Spectrum Requirements for Short Range Device, Metropolitan Mesh Machine Networks (M3N) and Smart Metering (SM) applications.

Принципы взаимодействия и способы передачи данных между этими компьютерами определяются сетевыми протоколами. Иными словами, сетевой протокол — это набор правил и действий, который регулирует соединение и обмен данными между двумя и более включенными в сеть устройствами.

Наиболее известные:

• HTTP (Hyper Text Transfer Protocol) — протокол передачи гипертекста, используется при пересылке веб-страниц между компьютерами;
• FTP (File Transfer Protocol) — протокол передачи файлов со специального файлового сервера на компьютер пользователя;
• POP3 (Post Office Protocol) — протокол почтового соединения получения клиентской почты. Серверы POP обрабатывают входящую почту, а протокол POP необходим для обработки запросов на получение почты от пользователей;
• SMTP (Simple Mail Transfer Protocol) — протокол, который задает набор правил для передачи электронной почты в сети. Сервер SMTP возвращает ответ при отправке;
• Telnet — протокол удаленного доступа, дает возможность пользователю работать на любой ЭВМ, находящейся с ним в одной сети.

В этой статье я расскажу про популярный в наше время протокол — WebSocket. Он используется, как правило, при разработке приложений, в которых содержимое обновляется с высокой частотой или в реальном времени.

Описание

WebSocket обеспечивает обмен данными между браузером и сервером через постоянное соединение. Это двунаправленный, полнодуплексный протокол, который используется в сценарии взаимодействия «Клиент-сервер». Он начинается с ws:// или wss:// в случае безопасного соединения.

Принцип веб-сокета — соединение между клиентом и сервером остается активным до тех пор, пока оно не будет разорвано любой из сторон.

Соединение WebSocket устанавливается посредством HTTP-запроса:

• клиент, который поддерживает веб-сокеты и хочет установить постоянное соединение, отправляет HTTP-запрос, содержащий набор необходимых заголовков (headers);
• в ответ он должен получить ответ сервера: HTTP 101 Switching Protocols. Ответ 101 указывает, что сервер переключается на протокол, запрошенный клиентом в заголовке запроса на обновление;
• клиент получает ответ сервера, и WebSocket-соединение открывается для начала обмена данными.

Особенности протокола

О плюсах WebSocket:

1. Поддерживает двусторонний обмен данными: может одновременно получать и передавать информацию.
2. Отправляет данные быстрее, чем HTTP.
3. Кроссплатформенная совместимость. Для сервера веб-сокета не имеет значения, кто выступает в качестве клиента: веб-сайт или мобильные приложение.
4. HTTP требует до 2000 байтов накладных расходов, тогда как веб-сокет — всего 2 байта.
5. Кратковременное отсутствие связи не прерывает соединение. Если интернет будет работать нестабильно, клиенту и серверу не придётся заново устанавливать WebSocket-соединения, они смогут продолжить обмениваться данными в обычном режиме, пока связь не восстановится.
6. Протокол позволяет работать в асинхронном режиме вместо привычной для веба работы «Запрос-ответ». Так, у клиента и сервера равноправные роли в процессе обмена данными, и они действуют автономно.

О минусах:

1. Высокие требования к серверному оборудованию.
2. Молчаливый отвал соединения. При отправке пакета в WebSocket вы не узнаете о том, доставлен ли он или нет, пока не пройдёт время таймаута — по умолчанию 75 секунд. Зачастую приходится вводить дополнительные механизмы общения между клиентом и сервером, чтобы быстро понять, отвечает ли клиент.
3. Смена сети клиентом. Бывают ситуации, когда клиент находится в дороге и меняется сеть, в которой находится устройство. В таких случаях сервер ничего не знает о смене адреса, если клиент не закрыл соединение при переподключении к другой сети.

Где применяется WebSocket

WebSocket может быть очень полезен для повышения скорости работы сайта. Но не стоит использовать этот протокол в случаях, когда мы хотим получать старые или неизменные данные, или необходимо загрузить данные лишь один раз. В таких кейсах стоит применить протокол HTTP.

Где используется WebSocket:

• трейдерские приложения;
• игровые приложения;
• чаты;
• социальные сети;
• управление IoT.

WebSocket подходит для этих проектов лучше всего, так как в них клиент может не выполнять на своей стороне никаких вычислений, а лишь получать\передавать данные на сервер.

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

Пример из практики

В качестве примера покажу React-component, работающий с веб-сокетом. Его суть проста — отображать текущее состояние соединения и функциональность принудительного закрытия и открытия соединения.

Сервер веб-сокета — ресурс wss://ws.kraken.com/, который с определённой периодичностью отправляет клиентам сообщение о том, что сервер работает.

Использование протокола WebSocket в React-приложении выглядит так:

Протокол WebSocket позволяет быстро и безопасно пересылать данные на любой домен, помогает увеличить скорость сайта или приложения. Он поддерживается всеми популярными браузерами: Google Chrome, Apple Safari, Mozilla Firefox, Opera и Internet Explorer, что делает его универсальным.

Сыграйте за нового сотрудника, которому предстоит запустить сайт маркетплейса и справиться с его растущей популярностью.

IoT

IoT развивается в России. У нас подготовили проект ГОСТ Р в области использования новой технологии беспроводной передачи данных. Протокол NB-Fi — технология класса LPWAN (беспроводные технологии передачи небольших по объему данных на дальние расстояния) для распределенных сетей телеметрии, межмашинного взаимодействия и интернета вещей.

Edge computing

Verizon Business заключила партнерское соглашение с Deloitte с целью стимулировать развертывание и внедрение услуг мобильных периферийных вычислений (MEC) для предприятий. Для нужд производственного сектора Verizon и Deloitte совместно разрабатывают интеллектуальное производственное решение, которое будет использовать компьютерное зрение и обнаружение на основе датчиков — в сочетании с MEC — для выявления и прогнозирования дефектов качества на сборочной линии и автоматического оповещения персонала в реальном времени.

Lumen развернул «metal-as-a-service» на своих граничных вычислительных узлах. В прошлом компания Lumen создавала для своих клиентов частные пользовательские вычислительные конфигурации bare metal. Теперь она перенесла bare metal на границу облака. С помощью службы компании могут развертывать приложения и рабочие нагрузки на границе облака через «metal-as-a-service» на платформе Lumen. Перемещение приложений и сервисов обеспечит низкую задержку, поскольку им больше не нужно возвращаться в центры обработки данных и обратно к пользователям.

Technologies

Предложена технология Wi-Fi с оптоволоконной производительностью для Industry 4.0. В рамках исследовательского проекта, опубликованного в журнале IEEE Transactions on Wireless Communications, была создана первая параметризация модели распространения сигнала миллиметрового диапазона, беспроводной технологии, способной передавать огромное количество данных в секунду в промышленной среде. По словам исследователей, эта новая модель — первый шаг к пониманию того, как этот тип сигнала ведет себя на промышленном предприятии, и может оказать значительное влияние на развитие Industry 4.0.

Verizon запустил 5G на новых рынках со своей услугой Nationwide 5G. Сервис развернут в диапазоне миллиметровых волн, где компания обеспечивает скорости, достигающие гигабит в секунду. Обратной стороной использования спектра миллиметровых волн является то, что сигналы в этом диапазоне не распространяются далеко; следовательно, доступность только на некоторых новых рынках. Как Verizon объясняет в пресс-релизе, компания использует динамическое совместное использование спектра (DSS), чтобы позволить 5G сосуществовать с LTE в той же полосе спектра. Результирующие скорости не особо впечатляют и в релизе не обсуждаются.

O2 протестировала технологию OpenRAN от Vilicom, чтобы удешевить предоставление корпоративных услуг 4G и 5G внутри помещений. В O2 заявили, что виртуализированная платформа снижает стоимость и требования к пространству для сотовых сетей внутри помещений, которые, по его мнению, станут критически важными для UK PLC после коронавируса.

Компания Colt Technology Services обновила свой сервис SD-WAN. Пакет оптимизации WAN включает в себя возможности клонирования пакетов и прямого исправления ошибок (FEC) для повышения скорости и надежности критически важных приложений в корпоративных сетях. Что касается SASE, Colt построил трехуровневую защиту для клиентов WAN, LAN и DMZ. SD-WAN 2.0 Colt также поддерживает встроенную защиту Dynamic NAT и DDoS.

Исследования, проведенные Nokia и Telefónica, показали, что сети 5G на 90 процентов более энергоэффективны, чем 4G. Исследование проводилось в течение трех месяцев и касалось энергопотребления 5G RAN (сети радиодоступа) Telefónica.

Clouds, data-centers

Google Cloud объявил, что запустил дата-центры в трех новых регионах: Германии, Саудовской Аравии и Чили. Отчасти из-за пандемии Covid-19 поставщики гипермасштабируемых облачных сервисов, такие как Amazon Web Services, Microsoft Azure и Google Cloud, продолжили в этом году добавлять больше центров обработки данных в регионах, чтобы удовлетворить спрос на перемещение рабочих нагрузок и приложений в гибридное облако в рамках цифровой трансформации бизнеса.

Bloomberg сообщил, что в Microsoft начали разрабатывать собственные процессоры для использования в облачных системах и компьютерах Surface, снижая зависимость от Intel, с использованием архитектур ARM. Основное целевое направление бизнеса, которое необходимо поддерживать — это центры обработки данных, на которых работают системы облачных вычислений Microsoft, включая Azure для бизнеса и OneDrive для потребителей

Согласно отчету, мировые расходы на оборудование и программное обеспечение центров обработки данных выросли на 2% по сравнению с прошлым годом благодаря расходам облачных провайдеров.

Последний месяц 2020 года был полон новостей о коллаборациях в части облачных сотрудничеств. В России ВТБ стал партнером «Ростелекома» по развитию облачного бизнеса. Банк вложит 35 млрд руб. в компанию «РТК-ЦОД» — облачную «дочку» «Ростелекома», получив взамен долю в ней размером 44,8%. В течение трех лет «РТК-ЦОД» может выйти на IPO.

Deutsche Telekom объявил о расширении своего стратегического партнерства с Microsoft. В соответствии с соглашением Deutsche Telekom также перейдет на Microsoft Azure в рамках своей текущей стратегии по переносу большинства внутренних ИТ-рабочих нагрузок в общедоступное облако к 2025 году.

IBM заключил сделку по покупке европейского облачного стартапа Nordcloud. Финансовые условия сделки, завершение которой планируется в первом квартале следующего года, не разглашаются.

А Amazon Web Services ухватил сразу два крупных контракта в декабре:

T-Systems и AWS объявили о многолетнем стратегическом соглашении о сотрудничестве, чтобы обеспечить более быструю миграцию приложений в облако, решения для вычислений и хранения, а также безопасность облачных решений T-Systems

Twitter выбрал Amazon Web Services для предоставления своих услуг в режиме реального времени. Twitter использует свои собственные центры обработки данных на протяжении многих лет, но многолетняя сделка дает Twitter доступ к глобальной облачной инфраструктуре AWS для выполнения SLA по качеству.

6G

Nokia возглавит исследовательский проект Европейской комиссии по 6G – Hexa-X. Проект получил финансирование в рамках программы исследований и инноваций Horizon 2020 и направлен на объединение заинтересованных сторон со всей Европы, чтобы заложить основы того, чем однажды станет 6G.

Исследования и прогнозы

В конце года все традиционно подводят итоги и дают свои прогнозы на следующий год. Иностранные и отечественны ресурсы дали свои прогнозы развития телеком и медиа индустрии на следующий год:

• Deloitte предлагает концентрироваться на потребностях клиентов за счет более тонкого подхода к взаимодействию с ними, на конвергенции и преобразовании развлекательных программ с помощью новых предложений услуг и пакетов развлечений для гибкости бизнеса и репозиционировании беспроводных сетей с помощью новых продуктов, услуг и бизнес-моделей для их монетизации.
• Российское агентство CNews Analytics провело опрос среди своих читателей. Как и в ходе прошлогоднего опроса, наибольшие надежды возлагаются на аналитику больших данных, искусственный интеллект и облачные решения. В некоторых отраслях в топ по востребованности также вошли интернет вещей, сети пятого поколения и автономные системы.
• Исследование Omdia ICT Enterprise Insights Survey предполагает, что большинство поставщиков услуг увеличат свои расходы на инструменты искусственного интеллекта в 2021 году. Более половины планируют увеличить свои расходы на системы взаимодействия с клиентами (CRM, мобильные приложения и т. д.). Архитектура на основе микросервисов является необходимым условием для большинства покупок нового программного обеспечения, как и возможность развертывания программного обеспечения в общедоступном облаке.
• Ресурс Totaltele.com видит три ключевых направления, в которых они ожидают значительного движения в 2021 году: развитие инфраструктуры, развитие промышленных сетей 5G и частных сетей, развитие Open RAN.

Пандемия сделала 2020 год годом стремления к цифровизации. Всем стало очевидно и понятно, что многие сферы жизни и деятельности уходят в онлайн, меняется клиентское поведение. Неудивительна в этом контексте статья о прогнозе роста расходов на цифровую трансформацию: ожидается, что глобальные расходы на цифровую трансформацию (DX) в период с 2020 по 2023 год составят 6,8 триллиона долларов, поскольку бизнес адаптируется к «новым нормам». Эта оценка была получена от IDC, которая заявила на этой неделе, что к 2022 году ожидается оцифровка 65% мирового ВВП.

Контент и продукты

В разных направлениях в США двигаются AT&T и Verizon в части своих взглядов на развитие контента. AT&T согласилась продать Sony свой аниме-бизнес Crunchyroll примерно за 1,2 миллиарда долларов США и, как сообщается, находится на последней стадии процесса продажи DirecTV, которая может стоить около 15 миллиардов долларов при том, что AT&T заплатила за DirecTV 49 миллиардов долларов в 2015 году.

Между тем Verizon продолжает развивать потоковое ТВ с предложением Free Discovery + Streaming. Запустив Verizon Discovery+ компания предоставит потоковые сервисы бесплатно в течение длительного периода, продолжив традицию подобных решений. Услуга будет доступна новым клиентам на сверхширокополосных мобильных устройствах Verizon 5G, домашнем Интернете 5G и Fios в течение года.

Toyota и AWS объявили о своем партнерстве для расширения платформы мобильных сервисов Toyota. Платформа представляет собой «экосистему, которая поможет инженерам Toyota разрабатывать, развертывать и управлять мобильными сервисами нового поколения на основе данных для обеспечения безопасности водителей и пассажиров, безопасности, комфорта и удобства в транспортных средствах Toyota, подключенных к облаку». Речь идет о сборе, управлении и использовании данных для помощи в проектировании и разработке автомобилей Toyota и для предложения дополнительных услуг, таких как совместное использование автомобилей и аренда с полным спектром услуг, а также уведомления о проактивном техническом обслуживании автомобилей.

BSS

Amdocs заключил соглашение с Amazon Web Services (AWS) о поставке совместных интегрированных облачных BSS операторам связи. Интеграция позволит предложить операторам доступ к портфелю цифровых услуг, которые сократят время выхода оператора на рынок. Коронавирус ускорил цифровую трансформацию компаний, процессы и приложения начали быстрее перемещаться в облака для организации удаленного доступа. Как показывает опыт первых волн, кто успевает первым, зарабатывает больше.

5G

Orange к концу 2020 года планирует обеспечить 80-процентное покрытие outdoor 5G в 160 муниципалитетах Франции. Оператор уже запустил тарифные планы, включающие трафик 5G. Тарифы начинаются с 30 евро в месяц за 70 ГБ, а за 80 евро в месяц клиенты могут получить безлимитный интернет во всех сетях, включая сети 5G.

В отчете, посвященном будущему британского телекома и подготовленном Ericsson и Qualcomm, предполагается, что 5G обеспечит экономический рост почти в 15 миллиардов фунтов стерлингов в трех ключевых отраслях: обрабатывающая промышленность, сельское хозяйство и строительство. Ставка в исследовании делается на:

• датчики, которые позволят в реальном времени отслеживать фабрики, посевы и строительные площадки;
• автономные и дистанционно управляемые автомобили;
• AR для повышения производительности и обучения;
• совместную робототехнику для ремонта и обследования строительных площадок на предмет безопасности.

Vodafone в своих отчетах подчеркивает преимущества 5G и Интернета вещей в области преобразования здравоохранения. Пока картинка, представленная в отчете, больше похожа на фантастику, но темпы развития технологий говорят, что скоро подобные кейсы будут реальностью:

• машины скорой помощи, оснащенные 5G, могут связываться с умными светофорами, чтобы обеспечить безопасное и беспрепятственное движение;
• возможность получить операцию у специалиста, независимо от того, находится ли он в той же больнице или на другом конце света (удаленная хирургия);
• дистанционные медицинские консультации (не телемедицина, а полноценное онлайн посещение профессионала).

Интересное мнение относительно конкуренции edge computing и облаков в том виде, в котором они существуют сейчас, представлено в исследовании: edge computing быстро превращается в новое облако. По данным Gartner, к 2022 году более 50% корпоративных данных будет создаваться и обрабатываться вне центра обработки данных или облака, что представляет собой серьезную проблему для гигантов облачных вычислений, таких как Amazon Web Services и Microsoft Azure, чьи сервисы не предназначены для работы в массово распределенных и удаленных периферийных средах. Сценарии использования edge computing и новые архитектурные модели на их основе развиваются очень быстро, формируя новый тренд использования сетей 5G. Есть подозрения, что Amazon и Microsoft купят успешные стартапы, развивающие edge computing, но сам факт быстрых смен технических парадигм интересный.

Сразу два оператора в ноябре продемонстрировали возможности использования 5G и AR в медиа-маркетинге: Verizon сделал музыкальное сопровождение с дополненной реальностью, а EE запустил кампанию с легендой Голливуда Кевином Бэйконом и поп-певицей Ритой Ора.

IBM запустил новую гибридную облачную платформу, которая делает ставку на 5G. IBM Cloud для операторов похожа на платформу, анонсированную VMware в сентябре. Она также нацелена на экосистему телекоммуникационных сетей 5G. По той же схеме, что и комбинированная платформа VMware, IBM Cloud for Telecommunications объединяет и переупаковывает различные технологии IBM и Red Hat.

Clouds

BT объявил о запуске нового поколения управляемых сервисов, оптимизированных для облака, с предложением, основанным на технологии VMware SD-WAN. Традиционные глобальные сети (WAN) требовали установки специального оборудования проприетарного производителя на каждом объекте заказчика. Новая управляемая услуга BT основана на стандартном оборудовании, которое способно поддерживать выбор программных сетевых решений от разных поставщиков.

Еще одна интересная новость об Orange. Французский оператор объявил о сотрудничестве с Amazon Web Services с целью ускорения перехода клиентов в облако. В июле Orange заявил о заключении стратегического партнерства с Google Cloud, чтобы вместе строить телеком ИТ-инфраструктуру и проектировать облачные сервисы. Плюс к этому Orange также поддерживает отношения с Microsoft Azure для внутреннего использования ПО Microsoft. Оператор трансформируется по полной. Используя AWS, Azure и Google Cloud, Orange выстраивает обширный, независимый от поставщика, мультиоблачный подход для удовлетворения всех потребностей клиентов на всех этапах их перевода в облако.

Возможно, Orange выстраивает свою стратегию в области облачной инфраструктуры, потому что разделяет мнение ABI Research. Отчет последних показал, что глобальный рынок облачных услуг для телекоммуникационных компаний будет стремительно расти в течение следующих пяти лет. В настоящее время мировая рыночная стоимость облачных услуг составляет около 8,7 млрд долларов, а к 2025 году эта сумма увеличится более чем в три раза и достигнет 29,3 млрд долларов. Согласно модели ABI Research, глобальный рынок облачных услуг для телекоммуникационных компаний будет относительно поровну разделен по всему миру: 10 миллиардов долларов в Северной Америке, 9 миллиардов долларов в Азиатско-Тихоокеанском регионе и 8,2 миллиарда долларов в Европе. ABI Research связывает этот быстрый рост в первую очередь с инвестициями в облачную инфраструктуру в таких областях, как VNF, MANO и CNF.

В мире

Война стандартов. На рынке промышленного IoT LoRaWAN одолевает NB-IoT.

Rakuten, разрушитель японского рынка телекома, показал неутешительные для себя итоги третьего квартала. Агрессивное увеличение Capex в Rakuten Mobile привело к тому, что группа понесла операционные убытки (и снизила стоимость акций). Операционный убыток Rakuten Mobile в размере 57,9 млрд иен свел на нет операционную прибыль, полученную по двум другим направлениям бизнеса, и привел к операционному убытку в размере 28,7 млрд иен.

Абонентская база тоже не растет огромными темпами. 1.6 миллиона клиентов – ничто на японском рынке. Даже самый маленький оператор большой тройки японского рынка имеет 23 миллиона клиентов. Частично проблема кроется в покрытии оператора. Сеть Rakuten за пределами Токио, Осаки и Нагои мала, и клиенты вынуждены использовать сети KDDI.

Интересный опыт, в котором каменный цветок пока не выходит. Хорошо, что в группе компаний Rakuten деньги есть и японский маркетплейс, пожелавший выйти на рынок телекома, пока может себе позволить работать в минус.

В той же Японии Subaru и Softbank объявили, что провели успешные испытания связи 5G для всех транспортных средств (C-V2X), в ходе которых автоматизированные автомобили выезжали на шоссе и сливались с движением. Летом на испытательном полигоне Subaru Bifuka были смоделированы два сценария: в первом было свободное движение на главном шоссе; второй имитировал пробку. Автомобиль подключался через 5G к серверу, где приложение предсказывало вероятность его столкновения с автомобилями на главной дороге. Чтобы предотвратить аварию, приложение передавало команды предупреждения и замедления, позволяя подключенному автомобилю рассчитать правильную скорость, которая позволила бы ему безопасно выехать на главную магистраль.

Пока все операторы стремятся наращивать ARPU своих клиентов с помощью дополнительных сервисов, в том числе за счет телевидения, AT&T решил продать свои медиактивы. Долги висят, а актив по какой-то причине проигрывает конкурентам на рынке видеостриминга. Тем более странно это смотрится на фоне исследования Parks, в котором говорится о том, что количество людей с двумя подписками ОТТ-видеосервисов в США растет.

В России

Бум eSim: Сбермобайл, МТС и ВТБ-Мобайл заявили в ноябре о запуске виртуальной SIM-карты.

Протоколов большое множество. Про основные из них рассказано далее.

IP — Internet Protocol

Протокол передачи, который первым объединил отдельные компьютеры в единую сеть. Самый примитивный в этом списке. Он является ненадёжным, т. е. не подтверждает доставку пакетов получателю и не контролирует целостность данных. По протоколу IP передача данных осуществляется без установки соединения.

Основная задача этого протокола — маршрутизация датаграмм, т. е. определение пути следования данных по узлам сети.

Популярная версия на текущий момент — IPv4 с 32-битными адресами. Это значит, что в интернете могут хранится 4.29 млрд адресов IPv4. Число большое, но не бесконечное. Поэтому существует версия IPv6, которая поможет решить проблему переполнения адресов, ведь уникальных IPv6 будет 2 ^ 128 адресов (число с 38 знаками).

TCP/IP — Transmission Control Protocol/Internet Protocol

Это стек протоколов TCP и IP. Первый обеспечивает и контролирует надёжную передачу данных и следит за её целостностью. Второй же отвечает за маршрутизацию для отправки данных. Протокол TCP часто используется более комплексными протоколами.

UDP — User Datagram Protocol

Протокол, обеспечивающий передачу данных без предварительного создания соединения между ними. Этот протокол является ненадёжным. В нём пакеты могут не только не дойти, но и прийти не по порядку или вовсе продублироваться.

Основное преимущество UDP протокола заключается в скорости доставки данных. Именно поэтому чувствительные к сетевым задержкам приложения часто используют этот тип передачи данных.

FTP — File Transfer Protocol

Протокол передачи файлов. Его использовали ещё в 1971 году — задолго до появления протокола IP. На текущий момент этим протоколом пользуются при удалённом доступе к хостингам. FTP является надёжным протоколом, поэтому гарантирует передачу данных.

Этот протокол работает по принципу клиент-серверной архитектуры. Пользователь проходит аутентификацию (хотя в отдельных случаях может подключаться анонимно) и получает доступ к файловой системе сервера.

DNS

Это не только система доменных имён (Domain Name System), но и протокол, без которого эта система не смогла бы работать. Он позволяет клиентским компьютерам запрашивать у DNS-сервера IP-адрес какого-либо сайта, а также помогает обмениваться базами данных между серверами DNS. В работе этого протокола также используются TCP и UDP.

HTTP — HyperText Transfer Protocol

Изначально протокол передачи HTML-документов. Сейчас же он используется для передачи произвольных данных в интернете. Он является протоколом клиент-серверного взаимодействия без сохранения промежуточного состояния. В роли клиента чаще всего выступает веб-браузер, хотя может быть и, например, поисковый робот. Для обмена информацией протокол HTTP в большинстве случаев использует TCP/IP.

HTTP имеет расширение HTTPS, которое поддерживает шифрование. Данные в нём передаются поверх криптографического протокола TLS.

NTP — Network Time Protocol

Не все протоколы передачи нужны для обмена классического вида информацией. NTP — протокол для синхронизации локальных часов устройства со временем в сети. Он использует алгоритм Марзулло. Благодаря нему протокол выбирает более точный источник времени. NTP работает поверх UDP — поэтому ему удаётся достигать большой скорости передачи данных. Протокол достаточно устойчив к изменениям задержек в сети.

Последняя версия NTPv4 способна достигать точности 10мс в интернете и до 0,2мс в локальных сетях.

SSH — Secure SHell

Протокол для удалённого управления операционной системой с использованием TCP. В SSH шифруется весь трафик, причём с возможностью выбора алгоритма шифрования. В основном это нужно для передачи паролей и другой важной информации.

Также SSH позволяет обрабатывать любые другие протоколы передачи. Это значит, что кроме удалённого управления компьютером, через протокол можно пропускать любые файлы или даже аудио/видео поток.

SSH часто применяется при работе с хостингами, когда клиент может удалённо подключиться к серверу и работать уже оттуда.

Штатную поддержку протокола в ветке 1.17 обещают обеспечить через 6−12 месяцев. Для сборки на основе версии nginx 1.16 нужен патч (есть на GitHub) и код библиотеки quiche — после этого nginx нужно пересобрать с опциями -- with-http_v3_module, --with-quiche=../quiche. Поддержка TLS должна стоять на BoringSSL, OpenSSL пока не работает.

Про сам HTTP/3 можно почитать у нас на сайте.

Один из ключевых аспектов протокола — это рукопожатие. Именно о нём мы поговорим в этой статье.

«Рукопожатие SSL/TLS» — это название этапа установки HTTPS-соединения. Большая часть работы, связанной с протоколом SSL/TLS, выполняется именно на этом этапе. В прошлом году IETF доработал TLS 1.3, полностью обновив процесс рукопожатия.
В статье будут освещены два вида рукопожатия — для протоколов TLS 1.2 и TLS 1.3, которые мы рассмотрим, начиная с абстрактного уровня и постепенно углубляясь в особенности:

• согласование криптографических протоколов;
• аутентификация с помощью SSL-сертификата;
• генерация сеансового ключа.

Как происходит TLS-рукопожатие

В HTTPS-соединении участвуют две стороны: клиент (инициатор соединения, обычно веб-браузер) и сервер. Цель рукопожатия SSL/TLS — выполнить всю криптографическую работу для установки безопасного соединения, в том числе проверить подлинность используемого SSL-сертификата и сгенерировать ключ шифрования.

Согласование шифронабора

Каждое программное обеспечение уникально. Поэтому даже самые популярные веб-браузеры имеют различную функциональность. Аналогично и на стороне сервера — Windows Server, Apache и NGINX также отличаются друг от друга. Всё становится ещё сложнее, когда вы добавляете пользовательские конфигурации.

Именно поэтому первый шаг TLS-рукопожатия — обмен информацией о своих возможностях между клиентом и сервером для дальнейшего выбора поддерживаемых криптографических функций.

Как только клиент и сервер согласовывают используемый шифронабор, сервер отправляет клиенту свой SSL-сертификат.

Аутентификация

Получив сертификат, клиент проверяет его на подлинность. Это чрезвычайно важный шаг. Чтобы соединение было безопасным, нужно не только зашифровать данные, нужно ещё убедиться, что они отправляются на правильный веб-сайт. Сертификаты SSL/TLS обеспечивают эту аутентификацию, а то, как они это делают, зависит от используемого шифронабора.

Все доверенные SSL-сертификаты выпускаются центром сертификации (ЦС). ЦС должен следовать строгим правилам выдачи и проверки сертификатов, чтобы ему доверяли. Вы можете считать ЦС кем-то вроде нотариуса — его подпись значит, что данные в сертификате реальны.

Во время аутентификационной части TLS-рукопожатия клиент выполняет несколько криптографически безопасных проверок с целью убедиться, что выданный сервером сертификат подлинный. Процесс включает в себя проверку цифровой подписи и того, выдан ли сертификат доверенным ЦС.

На этом этапе клиент косвенно проверяет, принадлежит ли серверу закрытый ключ, связанный с сертификатом.

В RSA, самой распространённой криптосистеме с открытым ключом, клиент с помощью открытого ключа шифрует случайные данные, которые будут использоваться для генерации сеансового ключа. Сервер сможет расшифровать и использовать эти данные, только если у него есть закрытый ключ, наличие которого обеспечивает подлинность стороны.

Если используется другая криптосистема, алгоритм может измениться, но проверка другой стороны на подлинность всё равно останется.

Обмен ключами

Последняя часть TLS-рукопожатия включает создание «сеансового ключа», который фактически будет использоваться для защищённой связи.

Сеансовые ключи являются «симметричными», то есть один и тот же ключ используется для шифрования и дешифрования.

Симметричное шифрование производительнее, чем асимметричное, что делает его более подходящим для отправки данных по HTTPS-соединению. Точный метод генерации ключа зависит от выбранного шифронабора, два самых распространённых из них — RSA и Диффи-Хеллман.

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

Всё SSL-рукопожатие происходит за несколько сотен миллисекунд. Это первое, что произойдёт при HTTPS-соединении, даже до загрузки веб-страницы. После SSL-рукопожатия начинается зашифрованное и аутентифицированное HTTPS-соединение, и все данные, отправляемые и получаемые клиентом и сервером, защищены.

Вплоть до TLS 1.3 каждый раз, когда вы посещали сайт, рукопожатие происходило заново. Рукопожатие TLS 1.3 поддерживает 0-RTT или нулевое время возобновления приёма-передачи, что значительно увеличивает скорость для вернувшегося посетителя.

Пошаговый процесс рукопожатия в TLS 1.2

Рассмотрим TLS-рукопожатие с использованием RSA подробнее. Использование алгоритма Диффи-Хеллмана будет описано ниже.

1. Первое сообщение называется «Client Hello». В этом сообщении перечислены возможности клиента, чтобы сервер мог выбрать шифронабор, который будет использовать для связи. Также сообщение включает в себя большое случайно выбранное простое число, называемое «случайным числом клиента».
2. Сервер вежливо отвечает сообщением «Server Hello». Там он сообщает клиенту, какие параметры соединения были выбраны, и возвращает своё случайно выбранное простое число, называемое «случайным числом сервера». Если клиент и сервер не имеют общих шифронаборов, то соединение завершается неудачно.
3. В сообщении «Certificate» сервер отправляет клиенту свою цепочку SSL-сертификатов, включающую в себя листовой и промежуточные сертификаты. Получив их, клиент выполняет несколько проверок для верификации сертификата. Клиент также должен убедиться, что сервер обладает закрытым ключом сертификата, что происходит в процессе обмена/генерации ключей.
4. Это необязательное сообщение, необходимое только для определённых методов обмена ключами (например для алгоритма Диффи-Хеллмана), которые требуют от сервера дополнительные данные.
5. Сообщение «Server Hello Done» уведомляет клиента, что сервер закончил передачу данных.
6. Затем клиент участвует в создании сеансового ключа. Особенности этого шага зависят от метода обмена ключами, который был выбран в исходных сообщениях «Hello». Так как мы рассматриваем RSA, клиент сгенерирует случайную строку байтов, называемую секретом (pre-master secret), зашифрует её с помощью открытого ключа сервера и передаст обратно.
7. Сообщение «Change Cipher Spec» позволяет другой стороне узнать, что сеансовый ключ сгенерирован и можно переключиться на зашифрованное соединение.
8. Затем отправляется сообщение «Finished», означающее, что на стороне клиента рукопожатие завершено. С этого момента соединение защищено сессионным ключом. Сообщение содержит данные (MAC), с помощью которых можно убедиться, что рукопожатие не было подделано.
9. Теперь сервер расшифровывает pre-master secret и вычисляет сеансовый ключ. Затем отправляет сообщение «Change Cipher Spec», чтобы уведомить, что он переключается на зашифрованное соединение.
10. Сервер также отправляет сообщение «Finished», используя только что сгенерированный симметричный сеансовый ключ, и проверяет контрольную сумму для проверки целостности всего рукопожатия.

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

На этом этапе могут быть отправлены первые байты веб-приложения (данные, относящиеся к фактическому сервису, — HTML, Javascript и т. д.).

Пошаговый процесс рукопожатия в TLS 1.3

Рукопожатие TLS 1.3 значительно короче, чем его предшественник.

1. Как и в случае TLS 1.2, сообщение «Client Hello» запускает рукопожатие, но на этот раз оно содержит гораздо больше информации. TLS 1.3 сократил число поддерживаемых шифров с 37 до 5. Это значит, что клиент может угадать, какое соглашение о ключах или протокол обмена будет использоваться, поэтому в дополнение к сообщению отправляет свою часть общего ключа из предполагаемого протокола.
2. Сервер ответит сообщением «Server Hello». Как и в рукопожатии 1.2, на этом этапе отправляется сертификат. Если клиент правильно угадал протокол шифрования с присоединёнными данными и сервер на него согласился, последний отправляет свою часть общего ключа, вычисляет сеансовый ключ и завершает передачу сообщением «Server Finished».
3. Теперь, когда у клиента есть вся необходимая информация, он верифицирует SSL-сертификат и использует два общих ключа для вычисления своей копии сеансового ключа. Когда это сделано, он отправляет сообщение «Client Finished».

Издержки TLS-рукопожатия

Исторически одна из претензий к SSL/TLS заключалась в том, что он перегружал серверы дополнительными издержками. Это повлияло на ныне несуществующее представление, что HTTPS медленнее, чем HTTP.

Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование — дорогие процессы.

На небольших веб-сайтах это скорее всего не приведёт к заметному замедлению работы, но для корпоративных систем, куда ежедневно приходят сотни тысяч посетителей, это может стать большой проблемой. Каждая новая версия рукопожатия существенно облегчает процесс: TLS 1.2 совершает две фазы, а TLS 1.3 укладывается всего в одну и поддерживает 0-RTT.

Улучшения рукопожатия TLS 1.3 по сравнению с TLS 1.2

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

У рукопожатия TLS 1.2 можно выделить две фазы. Иногда могут потребоваться дополнительные, но когда речь идёт о количестве, по умолчанию подразумевается оптимальный сценарий.

В отличие от 1.2, рукопожатие TLS 1.3 укладывается в одну фазу, хотя вернее будет сказать в полторы, но это всё равно значительно быстрее, чем TLS 1.2.

Сокращение шифронаборов

Никто никогда не собирался использовать 37 наборов для шифрования данных, так эволюционировал протокол. Каждый раз, когда добавлялся новый алгоритм, добавлялись новые комбинации, и вскоре IANA администрировала 37 различных шифронаборов.

Это плохо по двум причинам:

1. Такая варьируемость приводит к ошибочным конфигурациям, которые делают интернет-пользователей уязвимыми для известных эксплойтов.
2. Это сделало настройку SSL более запутанной.

IETF исключил в TLS 1.3 поддержку всех алгоритмов, кроме самых безопасных, убирая путаницу за счёт ограничения выбора. В частности, был убран выбор метода обмена ключами. Эфемерная схема Диффи-Хеллмана стала единственным способом, позволяющим клиенту отправить информацию о своём ключе вместе с «Client Hello» в первой части рукопожатия. Шифрование RSA было полностью удалено вместе со всеми другими схемами обмена статическими ключами.

При этом есть одна потенциальная ахиллесова пята в TLS 1.3.

Нулевое время возобновления приёма-передачи — 0-RTT

0-RTT — это то, к чему стремился весь технологический мир, и вот оно здесь с TLS 1.3. Как уже было упомянуто, рукопожатие TLS исторически было не быстрым, так что было важно ускорить его. 0-RTT делает это путём сохранения некоторой секретной информации о клиенте, обычно идентификатора сеанса или сеансовых тикетов, чтобы использовать их при следующем соединении.

Несмотря на все преимущества 0-RTT, он содержит пару потенциальных подводных камней. Режим делает клиентов восприимчивыми к атакам воспроизведения, когда злоумышленник, которому каким-то образом удаётся получить доступ к зашифрованному сеансу, может получить данные 0-RTT, включая первый запрос клиента, и снова отправить их на сервер.

Тем не менее, использовать эксплойт непросто. Вероятно, такой риск — небольшая цена за чрезвычайно полезную функцию.

Безопасность

С самого начала вызывало опасение количество информации, отправляемой в виде открытого текста во время рукопожатия. Очевидно, что это небезопасно, поэтому чем больше шагов рукопожатия происходит в зашифрованном виде, тем лучше.

В рукопожатии TLS 1.2 этапы согласования не были защищены, вместо этого использовалась простая MAC-функция, чтобы никто не вмешался в передачу. В этап согласования входят сообщения «Client Hello» и «Server Hello».

MAC-функция действует как индикатор, но не даёт никаких гарантий безопасности. Возможно, вы слышали об атаке, которая вынуждает стороны использовать менее безопасные протоколы и функции (downgrade attack). Если и сервер, и клиент поддерживают устаревшие шифронаборы — информацию об этом легко получить, прослушивая соединение, — злоумышленник может изменить шифрование, выбранное сервером, на более слабое. Такие атаки не опасны сами по себе, но открывают дверь для использования других известных эксплойтов тех шифронаборов, на которые был изменён выбранный изначально.

Рукопожатие TLS 1.3 использует цифровую подпись на ранних стадиях соединения, что делает его более безопасным и защищает от атак, меняющих шифронабор. Подпись также позволяет быстрее и эффективнее аутентифицировать сервер.

Теперь посмотрим, как эти обновления для рукопожатия TLS 1.3 будут реализованы во всех трёх основных функциях самого рукопожатия SSL/TLS.

Шифронаборы TLS-рукопожатия

Шифронабор — это набор алгоритмов, определяющих параметры безопасного соединения.

В начале любого соединения самое первое взаимодействие, «Client Hello», представляет собой список поддерживаемых шифронаборов. Сервер выбирает лучший, наиболее безопасный вариант, который поддерживается им и отвечает его требованиям. Вы можете посмотреть на шифронабор и выяснить все параметры рукопожатия и соединения.

Шифронаборы TLS 1.2

• TLS — протокол.
• ECDHE — алгоритм обмена ключами.
• ECDSA — алгоритм аутентификации.
• AES 128 GCM — алгоритм симметричного шифрования.
• SHA256 — алгоритм хеширования.

В приведённом выше примере используется эфемерная система Диффи-Хеллмана (DH) с эллиптической кривой для обмена ключами и алгоритм цифровой подписи эллиптической кривой для аутентификации. DH также может быть соединен с RSA (функционирующим как алгоритм цифровой подписи) для выполнения аутентификации.

Вот список наиболее широко поддерживаемых шифронаборов TLS 1.2:

Шифронаборы TLS 1.3

• TLS — протокол.
• AES 256 GCM — алгоритм аутентифицированного шифрования с присоединёнными данными (AEAD).
• SHA384 — алгоритм функции формирования хешированного ключа (HKFD).

Мы уже знаем, что будем использовать какую-то версию обмена эфемерными ключами Диффи-Хеллмана, но не знаем параметров, так что первые два алгоритма в шифронаборе TLS 1.2 больше не нужны. Эти функции всё ещё выполняются, их просто больше не нужно согласовывать во время рукопожатия.

Из приведённого выше примера видно, что используется AES (Advanced Encryption Standard) для шифрования большого объёма данных. Он работает в режиме счётчика Галуа с использованием 256-битных ключей.

Вот пять шифронаборов, которые поддерживаются в TLS 1.3:

• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_GCM_SHA256;
• TLS_AES_128_CCM_8_SHA256;
• TLS_AES_128_CCM_SHA256.

Что изменилось в TLS 1.3 по сравнению с TLS 1.2?

Важно помнить, что при создании версии 1.3 главным было повышение безопасности и производительности. Для этого в TLS 1.3 был переработан алгоритм генерация ключей и исправлены известные уязвимости.

В рукопожатии TLS 1.3 также стали лучше некоторые процессы, например аутентификация сообщений и цифровые подписи.

Наконец, в дополнение к постепенному отказу от старых алгоритмов генерации ключей или обмена ими, TLS 1.3 устраняет старые симметричные шифры. В TLS 1.3 полностью исключили блочные шифры. Единственный разрешённый в TLS 1.3 тип симметричных шифров называется шифрованием с проверкой подлинности с использованием дополнительных данных (AEAD). Он объединяет шифрование и проверку подлинности сообщений (MAC) в одну функцию.

Аутентификация в TLS-рукопожатии

Исторически двумя основными вариантами обмена ключами являются RSA и Диффи-Хеллман (DH), в наши дни DH часто ассоциируется с эллиптическими кривыми (ECDH). Несмотря на некоторые основные сходства, между этими двумя подходами к обмену ключами есть фундаментальные различия.

Иными словами, TLS-рукопожатие RSA отличается от TLS-рукопожатия ECDH.

Аутентификация в рукопожатии TLS 1.2

Как было только что сказано, дополнительная функциональность RSA для аутентификации с помощью цифровых подписей требует больших ключей, устойчивых к атакам перебором. Размер этих ключей сильно увеличивает затраты на их вычисление, шифрование и дешифрование во время рукопожатия.

С другой стороны, если Диффи-Хеллман не выполняет аутентификацию, то что он делает? Как было сказано выше, DH часто используют совместно с криптографией на основе эллиптических кривых, чтобы обеспечить аутентификацию и обмен ключами.

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

• 192 бит;
• 224 бита;
• 256 бит;
• 384 бит;
• 521 бит.

Но это не единственное различие между открытыми/закрытыми ключами ECC и ключами RSA. Они используются для двух совершенно разных целей во время рукопожатия TLS.

В RSA пара открытый/закрытый ключ используется как для проверки подлинности сервера, так и для обмена симметричным ключом сеанса. Фактически, именно успешное использование секретного ключа для расшифровки секрета (pre-master secret) аутентифицирует сервер.

С Диффи-Хеллманом пара открытый/закрытый ключ НЕ используется для обмена симметричным сеансовым ключом. Когда задействован Диффи-Хеллман, закрытый ключ фактически связан с прилагаемым алгоритмом подписи (ECDSA или RSA).

RSA-аутентификация

Процесс RSA-аутентификации связан с процессом обмена ключами. Точнее обмен ключами является частью процесса аутентификации.

Когда клиенту предоставляется SSL-сертификат сервера, он проверяет несколько показателей:

• цифровую подпись с использованием открытого ключа;
• цепочку сертификатов, чтобы убедиться, что сертификат происходит от одного из корневых сертификатов в хранилище доверенных сертификатов;
• срок действия, чтобы убедиться, что он не истёк;
• статус отзыва сертификата.

Если все эти проверки прошли, то проводится последний тест — клиент шифрует pre-master secret с помощью открытого ключа сервера и отправляет его. Любой сервер может попытаться выдать любой SSL/TLS-сертификат за свой. В конце концов, это общедоступные сертификаты. А так клиент может провести аутентификацию сервера, увидев закрытый ключ «в действии».

Таким образом, если сервер может расшифровать pre-master secret и использовать его для вычисления сессионного ключа, он получает доступ. Это подтверждает, что сервер является владельцем используемой пары из открытого и закрытого ключа.

DH-аутентификация

Когда используются Диффи-Хеллман и ECDSA/RSA, аутентификация и обмен ключами разворачиваются бок о бок. И это возвращает нас к ключам и вариантам их использования. Открытый/закрытый ключ RSA используется как для обмена ключами, так и для аутентификации. В DH + ECDSA/RSA асимметричная пара ключей используется только для этапа цифровой подписи или аутентификации.

Когда клиент получает сертификат, он всё ещё проводит стандартные проверки:

• проверяет подпись на сертификате,
• цепочку сертификатов,
• срок действия,
• статус отзыва.

Но владение закрытым ключом подтверждается по-другому. Во время обмена ключами TLS-рукопожатия (шаг 4) сервер использует свой закрытый ключ для шифрования случайного числа клиента и сервера, а также свой DH-параметр. Он действует как цифровая подпись сервера, и клиент может использовать связанный открытый ключ для проверки, что сервер является законным владельцем пары ключей.

Аутентификация в рукопожатии TLS 1.3

В TLS 1.3 аутентификация и цифровые подписи всё ещё играют важную роль, но они были исключены из шифронаборов для упрощения согласования. Они реализованы на стороне сервера и используют несколько алгоритмов, поддерживаемых сервером, из-за их безопасности и повсеместного распространения. В TLS 1.3 разрешены три основных алгоритма подписи:

• RSA (только подпись),
• алгоритм цифровой подписи эллиптической кривой (ECDSA),
• алгоритм цифровой подписи Эдвардса (EdDSA).

В отличие от рукопожатия TLS 1.2, аутентификационная часть рукопожатия TLS 1.3 не связана с самим обменом ключами. Скорее она обрабатывается параллельно с обменом ключами и аутентификацией сообщений.

Вместо запуска симметричной схемы MAC для проверки целостности рукопожатия, сервер подписывает весь хеш расшифровки, когда возвращает «Server Hello» со своей частью общего ключа.

Клиент получает всю информацию, передающуюся с «Server Hello», и выполняет стандартную серию проверок подлинности сертификата SSL/TLS. Она включает в себя проверку подписи на сертификате, а затем проверку на соответствие подписи, которая была добавлена в хеш расшифровки.

Совпадение подтверждает, что сервер владеет секретным ключом.

Обмен ключами в TLS-рукопожатии

Если выделить главную мысль этого раздела, она будет звучать так:

RSA облегчает обмен ключами, позволяя клиенту шифровать общий секрет и отправлять его на сервер, где он используется для вычисления соответствующего сеансового ключа. Обмен ключами DH на самом деле вообще не требует обмена открытым ключом, скорее обе стороны создают ключ вместе.

Если сейчас это звучит немного абстрактно, к концу этого раздела всё должно проясниться.

Обмен ключами RSA

Называть это обменом ключами RSA на самом деле неправильно. На самом деле это RSA-шифрование. RSA использует асимметричное шифрование для создания ключа сеанса. В отличие от DH, пара открытого/закрытого ключей играет большую роль.

Вот как это происходит:

1. Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
2. Клиент генерирует pre-master secret (a), а затем использует открытый ключ сервера для его шифрования и отправки на сервер.
3. Сервер расшифровывает pre-master secret с помощью соответствующего закрытого ключа. Теперь обе стороны имеют все три входных переменных и смешивают их с некоторыми псевдослучайными функциями (PRF) для создания мастер-ключа.
4. Обе стороны смешивают мастер-ключ с ещё большим количеством PRF и получают совпадающие сеансовые ключи.

Обмен ключами DH

Вот как работает ECDH:

1. Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
2. Одна сторона выбирает секретный номер, называемый pre-master secret (a), и вычисляет: xa mod y. Затем отправляет результат (A) другому участнику.
3. Другая сторона делает то же самое, выбирая свой собственный pre-master secret (b) и вычисляет xb mod y, а затем отправляет обратно своё значение (B).
4. Обе стороны заканчивают эту часть, принимая заданные значения и повторяя операцию. Один вычисляет ba mod y, другой вычисляет ab mod y.

Существует свойство показателей по модулю, которое говорит, что каждая сторона получит одно и то же значение, которое будет ключом, используемым для симметричного шифрования во время соединения.

Рукопожатие TLS 1.2 для DH

Теперь, когда мы узнали, чем DH отличается от RSA, посмотрим, как выглядит рукопожатие TLS 1.2 на основе DH.

Опять же, между этими двумя подходами существует множество сходств. Мы будем использовать ECDHE для обмена ключами и ECDSA для аутентификации.

1. Как и в случае с RSA, клиент начинает с сообщения «Client Hello», которое включает в себя список шифронаборов, а также случайное число клиента.
2. Сервер отвечает своим сообщением «Server Hello», которое включает в себя выбранный шифронабор и случайное число сервера.
3. Сервер отправляет свой SSL-сертификат. Как и при TLS-рукопожатии RSA клиент выполнит серию проверок подлинности сертификата, но, поскольку сам DH не может аутентифицировать сервер, необходим дополнительный механизм.
4. Чтобы провести аутентификацию, сервер берёт случайные числа клиента и сервера, а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH.
5. Сервер завершает эту фазу сообщением «Server Hello Done».
6. В отличие от RSA, клиенту не нужно отправлять pre-master secret на сервер с использованием асимметричного шифрования, вместо этого клиент и сервер используют параметры DH, которыми они обменялись ранее, чтобы получить pre-master secret. Затем каждый использует pre-master secret, который он только что рассчитал, для получения одинакового сеансового ключа.
7. Клиент отправляет сообщение «Change Cipher Spec», чтобы сообщить другой стороне о своём переходе на шифрование.
8. Клиент отправляет финальное сообщение «Finished», чтобы сообщить, что он завершил свою часть рукопожатия.
9. Аналогично, сервер отправляет сообщение «Change Cipher Spec».
10. Рукопожатие завершается сообщением «Finished» от сервера.

Преимущества DHE перед RSA

Существует две основные причины, по которым сообщество криптографов предпочитает использовать DHE, а не RSA: совершенная прямая секретность и известные уязвимости.

Совершенная прямая секретность

Ранее вы, возможно, задавались вопросом, что означает слово «эфемерный» в конце DHE и ECDHE. Эфемерный буквально означает «недолговечный». И это может помочь понять совершенную прямую секретность (Perfect Forward Secrecy, PFS), которая является особенностью некоторых протоколов обмена ключами. PFS гарантирует, что сессионные ключи, которыми обмениваются стороны, не могут быть скомпрометированы, даже если скомпрометирован закрытый ключ сертификата. Другими словами, он защищает предыдущие сессии от извлечения и дешифрования. PFS получила высший приоритет после обнаружения ошибки Heartbleed. Это основной компонент TLS 1.3.

Уязвимость обмена ключами RSA

Существуют уязвимости, которые могут использовать заполнение (padding), используемое во время обмена ключами в старых версиях RSA (PKCS #1 1.5). Это один из аспектов шифрования. С RSA pre-master secret должен быть зашифрован открытым ключом и расшифрован закрытым ключом. Но когда этот меньший по длине pre-master secret помещается в больший открытый ключ, он должен быть дополнен. В большинстве случаев попытавшись угадать заполнение и отправив поддельный запрос на сервер, вы ошибётесь, и он распознает несоответствие и отфильтрует его. Но есть немалая вероятность, что вы сможете отправить на сервер достаточное количество запросов, чтобы угадать правильное заполнение. Тогда сервер отправит ошибочное законченное сообщение, что, в свою очередь, сузит возможное значение pre-master secret. Это позволит злоумышленнику рассчитать и скомпрометировать ключ.

Вот почему RSA был удалён в пользу DHE в TLS 1.3.

Обмен ключами в рукопожатии TLS 1.3

В рукопожатии TLS 1.3 из-за ограниченного выбора схем обмена ключами клиент может успешно угадать схему и отправить свою часть общего ключа во время начального этапа (Client Hello) рукопожатия.

RSA была не единственной схемой обмена ключами, которая была удалена в TLS 1.3. Неэфемерные схемы Диффи-Хеллмана тоже были ликвидированы, как и перечень недостаточно безопасных параметров Диффи-Хеллмана.

Что имеется в виду под недостаточно безопасными параметрами? Не углубляясь в математику, сложность Диффи-Хеллмана и большинства криптосистем с открытым ключом — это сложность решения задач дискретного логарифма. Криптосистема должна быть достаточно сложной для вычисления, если неизвестны входные параметры (случайные числа клиента и сервера), иначе вся схема окажется бесполезной. Схемы Диффи-Хеллмана, которые не могли обеспечить достаточно большие параметры, были исключены в TLS 1.3.

1. В начале рукопожатия TLS 1.3, зная, что будет использоваться DHE-схема соглашения о ключах, клиент включает свою часть общего ключа на основе предполагаемой схемы обмена ключами в своё сообщение «Client Hello».
2. Сервер получает эту информацию и, если клиент угадал, возвращает свою часть общего ключа в «Server Hello».
3. Клиент и сервер вычисляют сеансовый ключ.

Это очень похоже на то, что происходит с DH в рукопожатии TLS 1.2, кроме того, что в TLS 1.3 обмен ключами происходит раньше.

Вместо заключения

SSL/TLS-рукопожатие — это увлекательный процесс, который имеет ключевое значение для безопасного интернета, и всё же он происходит так быстро и незаметно, что большинство людей даже никогда не задумывается об этом.

По крайней мере, пока что-то не пойдёт не так, как нужно.

Что такое SSH?

SSH — сокращение от «secure shell» (безопасная оболочка). Это протокол, который чаще всего используют для управления удалёнными компьютерами по сети.

Как устанавливается сессия SSH?

Есть несколько шагов, которые нужно пройти, чтобы начать SSH-сеанс между компьютерами.

1. Сначала нужно обеспечить безопасный способ обмена сообщениями между компьютерами, то есть настроить зашифрованный канал.
2. Далее нужно проверить целостность данных, отправляемых клиентом.
3. После этого проверяется подлинность клиента.

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

Настройка зашифрованного канала

Вся информация, отправляемая с использованием SSH, зашифрована. Обе стороны должны знать и понимать способ шифрования.

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

Один компьютер может создать ключ и отправить в виде сообщения через интернет. Но сообщение ещё не будет зашифровано, поэтому любой, кто перехватит его, сразу же сможет расшифровать все следующие сообщения.

Решение этой проблемы состоит в использовании протокола обмена ключами Диффи-Хеллмана. Оба компьютера создают свой закрытый и открытый ключ. Вместе они образуют пару ключей. Компьютеры делятся своими открытыми ключами друг с другом через интернет. Используя свой закрытый и чужой открытый ключ, стороны могут независимо сгенерировать одинаковый симметричный ключ.

Верификация

Следующий этап процесса установки сеанса SSH заключается в проверке того, что данные не были подделаны во время их передачи и что другой компьютер действительно является тем, за кого себя выдаёт.

Для верификации используют хеш-функцию. Это математическая функция, которая принимает входные данные и создаёт строку фиксированного размера.

Важной особенностью этой функции является то, что практически невозможно определить входные данные, зная лишь результат её работы.

После того как клиент и хост сгенерировали свои симметричные ключи, клиент использует хеш-функцию для генерации HMAC, что означает «код аутентификации сообщений, использующий хеширование». Клиент отправит этот HMAC на сервер для верификации.

Функция хеширования использует:

• симметричный ключ клиента,
• порядковый номер пакета,
• содержимое сообщения (зашифрованное).

Когда хост получает HMAC, он может использовать ту же самую хеш-функцию с этими тремя компонентами:

• собственный (идентичный клиентскому) симметричный ключ;
• порядковый номер пакета;
• зашифрованное сообщение.

Если сформированный хеш совпадает с HMAC, полученным от клиента, то мы можем быть уверены, что подключаемый компьютер — это компьютер с симметричным ключом, потому что только хост и клиент знают симметричный ключ, а другие компьютеры — нет.

Прелесть этого подхода в том, что мы не просто проверили личность клиента и убедились, что данные не были подделаны, но мы сделали это без передачи какой-либо секретной информации.

Аутентификация

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

Многие используют аутентификацию по паролю. Клиент отправляет хосту зашифрованное сообщение, содержащее пароль. Хост его расшифровывает и ищет пароль в базе данных, чтобы удостовериться, есть ли у клиента разрешение на доступ. Использование пароля для аутентификации допустимо, но имеет свои недостатки, так как необходимо хранить все пароли на сервере.

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

Заключение

SSH — это важный инструмент, используемый для удалённого управления другими компьютерами. Он безопасен, поскольку оба компьютера могут шифровать и дешифровать сообщения с использованием симметричных ключей.

На пути исследователя информационной безопасности часто встречаются различные сложности. В их число входят ограничения доступа к сети и необходимость оставаться незамеченным. Один из способов преодоления этих сложностей — использование ICMP-туннеля при попытке установить скрытое соединение.

В компьютерных сетях под туннелированием обычно понимается инкапсуляция одного сетевого протокола в качестве полезной нагрузки другого. Здесь можно узнать об этом больше.

ICMP (Internet Control Message Protocol) является вспомогательным протоколом стека TCP/IP и используется сетевыми устройствами для отправки сообщений об ошибках и информации о работе. Самое известное и, наверное, часто используемое ICMP-сообщение — это ping.

Смотрите также: Подборка книг по компьютерным сетям

Ping отправляется от одного узла в сети к другому. Он состоит из заголовков 2 и 3 уровней (MAC и IP-заголовки, определённые OSI-моделью) и специального ICMP-пакета. Отправляющий узел устанавливает параметры адресата, и если сообщение дойдёт до него, то он отправит его обратно:

Так выглядит IP-датаграмма ping-пакета:

ICMP-туннелирование можно выполнить, поместив в данные полезной нагрузки только то, что мы хотим отправить.

Обычно полезная нагрузка по умолчанию содержит что-нибудь вроде этой ASCII-строки  — «abcdefghijklmnopqrstuvwabcdefghi»:

Инкапсуляция HTTP-пакета в полезную нагрузку часто используется для обхода платного Wi-Fi.

Это возможно с помощью прокси-сервера, который ждёт ping-сообщения и отсылает их по мере необходимости (например, в форме HTTP):

1. ПримечаниеС помощью нужных инструментов (вроде ptunnel) инкапсулируем HTTP-пакет, который хотим отправить в Google в составе ping-пакета (внутри полезной нагрузки). Затем отправляем его по IP прокси-сервера. Этот IP не является адресом получателя HTTP-пакета; адресом получателя будет www.google.com.Так как роутеры в аэропорту обычно позволяют отправлять ICMP-трафик за пределы сети, роутер доставит ping-сообщение на прокси-сервер.Прокси-сервер получает ping-пакет и разбивает его на две части:заголовки ICMP;полезную нагрузку с исходным HTTP-сообщением.  IP-адрес отправителя HTTP-пакета, который прокси отправляет Google, должен быть IP-адресом самого прокси-сервера, а не вашего ноутбука или роутера аэропорта, поскольку Google должен ответить именно прокси, а не вам.

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

Всё это возможно благодаря тому, что ping-сообщения могут свободно выходить из локальной сети Wi-Fi в Интернет.

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

Устранение многих проблем начинается с проверки того, проходит ли информация из одной точки в другую. Задаются вопросы вроде «доступен ли вообще этот информационный маршрут?» и «активны ли сетевые компоненты и способны ли они отвечать?». Ping-сообщения могут легко ответить на эти и многие другие вопросы.

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

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

Я написал простой POC (Proof Of Concept) на Python, чтобы показать, как это работает.

Учтите, что:

• Для работы POC требуется Scapy;
• В данном POC не рассматривается обработка фрагментации. Фрагментация может произойти, например, если ответ от агента будет больше, чем позволяет размер полезной нагрузки.

POC включает в себя управляющий сервер и агент. Сервер будет посылать агенту команды через ICMP-туннель, а агент через него будет возвращать результат:

Использование выглядит как-то так:

И никогда не будет лишним посмотреть, что на самом деле происходит, с помощью Wireshark:

Как вы видите, в итоге мы имеем 2 ICMP-сообщения: одно с командой и другое с результатом.

Смотрим на ситуацию с точки зрения защиты

При написании подобных инструментов важно посмотреть на всё с точки зрения защиты и подумать, что нужно принять во внимание.

Наиболее важно помнить, что инструменты кибербезопасности не ограничиваются политиками белого списка брандмауэра. Большинство современных инструментов для защиты включают в себя различную функциональность по обнаружению аномалий. Но прежде чем заводить речь об аномалиях, нужно узнать больше о нормальном поведении субъекта.

Если говорить о ping-сообщениях в обычной сети, то их свойства примерно такие:

1. Большинство ping-сообщений отсылаются одинаковым образом — по 4 сообщения за раз.
2. Ping-сообщение имеет тип 8 (echo ping request), ping-ответ — тип 0 (echo ping reply).
3. С каждым ping-пакетом отсылаются несколько полей (при использовании Windows 8.1):id = 0x0001;seq ответа будет равно seq запроса;У полезной нагрузки останется размер (32 байта) и содержимое («abcdefghijklmnopqrstuvwabcdefghi») по умолчанию.

Учитывая всё вышеперечисленное, вам следует:

1. Написать управляющий сервер и агент таким образом, чтобы каждую минуту (например) отправлялось не больше 4 ping-сообщений. Если на отправку ваших данных требуется 15 сообщений, то весь процесс займёт 4 минуты. Да, возможно это медленно, но стоит того, чтобы остаться незамеченным.
2. Убедиться, что ping-запрос и ответ логически правильны. Если все сообщения, которые вы отправляете, будут типа 0, то будет странно увидеть много ответов, когда нет никаких запросов.
3. Обратить внимание, что размер полезной нагрузки повлияет на первый пункт (количество ping-сообщений на размер данных) и что это метаданные.
4. Подумать о содержимом полезной нагрузки  в контексте возможного наличия DPI.

DPI — глубокий анализ пакетов ( Deep Packet Inspection)

Во время обычного анализа пакетов считываются метаданные пакета (в основном заголовки). DPI же просматривает содержимое пакета. По сути, DPI анализирует полезную нагрузку и пытается понять, всё ли с ней нормально.

В нашем случае DPI с помощью отслеживания аномалий может обнаружить ICMP-туннель, просмотрев полезную нагрузку и увидев, что она отличается от ожидаемой. Таким образом, мы не сможем скрыть все параметры.

Так а зачем тогда вообще возиться с ICMP-туннелированием?

Потому что:

1. DPI встречается далеко не везде.
2. Большинство DPI-инструментов полагаются на базу с сигнатурами — если для ICMP-сообщений сигнатур нет, то и туннель обнаружить не получится.
3. Даже если в базе найдётся подходящая сигнатура, оператор сначала должен настроить её на работу в активном режиме.

Почему он может её не активировать?

• На проверку каждой сигнатуры требуются ресурсы (преимущественно процессор и время), что может замедлить сеть.
• Проверка сети может проводиться с помощью разных ping-сообщений с разным размером полезной нагрузки (например, ping -s 1234 8.8.8.8 отправит ping-сообщение с полезной нагрузкой в размере 1234 байт) для диагностики проблем, связанных с MTU. Активация подобной сигнатуры приведёт к множеству ложных срабатываний, что будет раздражать команду мониторинга и, как следствие, снизит надёжность сигнатуры.

Заключение

ICMP-туннелирование — отличный способ для незаметной отправки/получения данных. Хотя порой оно будет не так эффективно из-за различных защитных мер, зачастую вы обнаружите, что это простой и удобный способ обойти некоторые ограничения.

Если вы поняли суть ICMP-туннелирования, то вы сможете создать множество других решений вроде DNS-туннелирования, SSH-туннелирования и так далее.

Книга «Компьютерные сети» Эндрю Таненбаума и Дэвида Уэзеролла уже стала классикой в сфере сетевых технологий. В ней авторы изложили основные концепции компьютерных сетей. Темы идут последовательно, начиная от физического уровня модели сети и заканчивая прикладным уровнем и безопасностью в сетях.

В пятом издании книги рассматриваются, в частности, беспроводные сети стандарта 802.12 и 802.16, сети 3G, технология RFID, CDN (инфраструктура доставки контента), пиринговые сети, потоковое вещание, интернет-телефония и многое другое.

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

В отличие от «Компьютерных сетей» Таненбаума, в книге «Компьютерные сети. Нисходящий подход» Джеймса Куроуза и Кита Росса тема рассматривается сверху вниз в модели сетевой архитектуры, начиная от прикладного уровня и заканчивая канальным. Также в книге авторы уделили внимание сетевой безопасности, администрированию вычислительных сетей, беспроводным и мультимедийным сетевым технологиям. Отлично подойдёт новичкам.

Андрей Робачевский в своей книге рассказал о внутреннем строении Интернета, в частности, о глобальной адресации и IP, системе доменных имен (DNS) и глобальной межсетевой маршрутизации. Также в книге рассматриваются архитектурная эволюция Интернета и его будущее, основные организации, регулирующие глобальную Сеть, а также вопросы стандартизации, развития и безопасности основных систем Интернета.

Автор часто переходит с одной темы на другую и использует малоизвестные термины, поэтому книга больше подойдёт опытным специалистам по компьютерным сетям.

Опытный преподаватель Уэнделл Одом написал множество книг по компьютерным сетям от издательства Cisco Press, включая книги для подготовки к экзаменам CCNA и по технологиям Cisco QOS, а также принимал участие в написании руководства по подготовке к экзамену CCIE. С 1981 года он работал сетевым инженером, консультантом, системным инженером, инструктором и создателем курсов по компьютерным сетям. Сейчас же он занимается проектированием и разработкой средств сертификации. Его богатый опыт лёг в основу руководства для подготовки к экзамену CCNA ICND2 200-105.

Вы ознакомитесь с подробностями настройки, поиска и устранения неисправностей сети. Книга поможет правильно выстроить свой процесс обучения, устранить пробелы в знаниях компьютерных сетей и проверить себя благодаря множеству экзаменационных вопросов и практических задач.

Книга поможет разобраться с настройкой и сопровождением стека TCP/IP. Сначала рассказывается о том, зачем нужны протоколы, как они работают, как адресация и маршрутизация позволяют передавать данные по сети и как настроить интерфейс, маршрутизацию и DNS. Затем вы ознакомитесь с NFS, NIS и DHCP, научитесь настраивать Samba для работы в гетерогенной сети Unix/Windows и изучите настройку сервера Apache. Две последние главы книги посвящены безопасности сети и устранению различных проблем. В конце книги вы найдёте справочник по sendmail, gated, демону named, свободной реализации DHCP-сервера dhcpd.

Книга в двух томах «Routing TCP/IP» Дойла Кэррола — библия для всех желающих изучить протокол TCP/IP. Она больше ориентирована на практическую составляющую, поэтому хорошо подойдёт инженерам, стремящимся поскорее использовать в работе TCP/IP. С помощью книги вы узнаете «изнанку» TCP/IP, освоите настройку и устранение ошибок протокола маршрутизации BGP-4, работу с протоколами IPv4 и IPv6 и научитесь настройке и развёртыванию NAT.

Хоть книга и является официальным пособием от Cisco, материал в ней, по большей части, независим от платформы. Книга также станет хорошим помощником при подготовке к сертификационному экзамену CCIE проектировщикам сетей, системным администраторам и инженерам.

IP-маршрутизация является основой межсетевого взаимодействия, и книга «IP Routing Fundamentals» поможет начинающим инженерам с ней разобраться. В справочнике вы найдёте информацию по современным протоколам маршрутизации RIP, IGRP, EIGRP и OSPF, узнаете подробнее о классовой и бесклассовой (CIDR) IP-адресации, а также о маске подсети переменной длины (VLSM), являющейся основой бесклассовой адресации.

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

«Internetworking with TCP/IP» — это классическое пособие от Дугласа Комера по протоколам TCP/IP и межсетевому взаимодействию, пережившее уже шестое издание. Книга охватывает множество элементов, включая TCP, IPv4, IPv6, DHCP и DNS. Кроме того, в книге описаны современные тенденции развития компьютерных сетей и Интернета, включая классификацию пакетов, программно-определяемые сети (Software Defined Networking, SDN) и сетевые протоколы, используемые в Интернете вещей (Internet of Things, IoT).

В книге достаточно много теории, объяснённой академическим языком, поэтому руководство не подойдёт для введения в тему. Однако для тех, кто хочет углубиться в межсетевое взаимодействие и работу протоколов TCP/IP, эта книга-бестселлер станет хорошим подспорьем.

Официальное руководство по стеку протоколов TCP/IP от IBM «TCP/IP Tutorial and Technical Overview» подойдёт как новичкам, стремящимся изучить TCP/IP, так и уже опытным специалистам, которые хотят привести свои навыки работы с TCP/IP в соответствие с действующими стандартами.

В первой части книги рассказываются основные концепции и история стека TCP/IP и рассматриваются протоколы, входящие в TCP/IP, а также их применение. Во второй части уделено внимание базовым концепциям сетевых приложений, прикладным протоколам в рамках концепций (например FTP), а также приложениям, ставшими по факту стандартом в профессиональном сообществе. Третья часть книги посвящена новым концепциям и расширенным реализациям в архитектуре TCP/IP. В частности, в ней рассматривается постепенное объединение многих ранее разрозненных сетей и служб, использующих технологию IP, его потенциальные опасности и стандарты, используемые для обеспечения безопасности и контроля доступа к сетям и сетевым ресурсам.

Свободно распространяемая книга «Computer Networking: Principles, Protocols and Practice» Оливьера Бонавентуры (Olivier Bonaventure) служит введением в тему компьютерных сетей. Первая часть книги содержит материал по основным концепциям, включая создание и настройку сети, адресацию, общий доступ к ресурсам и безопасность. Во второй части книги отдельно рассматриваются многие основные протоколы стека TCP/IP: HTTP, TLS, RPC, TCP, UDP, SCTP, IPv6, система доменных имён (DNS) и другое. В конце книги вы найдёте справочник по различным аббревиатурам, встречающимся в стандартах.

А какими книгами по компьютерным сетям пользовались вы? Или какие книги вам рекомендовали ваши знакомые и преподаватели? Делитесь в комментариях.

Планируемые изменения

Сейчас браузер, получив файлы по FTP, открывает их, если есть такая возможность. Автор поста Майк Вест (Mike West) предлагает изменить это. Если пользователь обратится к ресурсу по FTP, браузер будет предлагать скачивание информации. При обращении к папке Chrome будет по-прежнему индексировать её, показывая содержимое.

Вест считает FTP устаревшим и небезопасным и предлагает веб-разработчикам перейти на HTTPS. В iOS удалось полностью отказаться от использования FTP, но некоторые пользователи других ОС ещё используют этот инструмент.

Среди разработчиков Chrome обсуждение отказа от FTP ведётся с 2014 года. Однако статистика показывает малое, но стабильное количество пользователей, работающих с FTP, что делает полный отказ от поддержки протокола нежелательным. Предложенные Вестом изменения могут повлиять на это число, спровоцировав нисходящий тренд. Для оставшихся верными привычке и традиции разработчики предлагают выпустить модуль к браузеру.

Поддержка FTP в других браузерах

Среди специалистов нет единого мнения о том, как работать с FTP. Вест указывает, что Safari отображает полученные по этому протоколу ресурсы, но не обрабатывает папки, а платформа Browserstack не поддерживает FTP.

Firefox в настоящее время работает с протоколом так же, как и Chrome, однако в июне 2018 года один из разработчиков, Том Шустер (Tom Schuster), заявил, что в ближайшем будущем команда планирует убрать из браузера поддержку этого инструмента.

Разработчики Chrome уже некоторое время мягко, но настойчиво подталкивают пользователей к использованию протокола HTTPS. Начиная с семидесятой версии браузера при попытке ввода личных данных на сайте, работающем не по HTTPS, в адресной строке высвечивается красная предупреждающая плашка Not secure. Впрочем, за применение HTTPS ратует не только Google. Facebook с лета 2018 года принимает переходы и вызовы функции аутентификации из Facebook JavaScript SDK только с сайтов, использующих HTTPS.

TLS 1.0 и 1.1 опирается на ненадёжные MD5 и SHA-1. На долю этих версий приходится только около 0,5 % всех HTTPS-соединений.

Когда прекратится поддержка TLS 1.0 и 1.1?

Google планирует начать отключение TLS 1.0 и 1.1 с Chrome 72, а полностью прекратить поддержку в начале 2020 года с выходом Chrome 81. Владельцы сайтов будут получать уведомления в консоли DevTools о необходимости обновления компонента. Edge и Internet Explorer 11 прекратят поддерживать устаревший протокол в первой половине 2020 года. Firefox и Safari обещают сделать это в марте того же года.

Какие меры предпринять?

Специалисты рекомендуют администраторам сайтов как можно скорее переходить на новые версии протокола. Команда разработчиков Chrome рекомендует использовать:

• TLS 1.2 и новее;
• наборы шифрования ECDHE и AEAD;
• SHA-2 в подписи сервера.

Эти меры не требуют обновления сертификата. В случае необходимости сервер может использовать как современные, так и устаревшие компоненты.

IETF утвердила версию TLS 1.3 в марте 2018 года, а в августе того же года Facebook представила для этой версии протокола open source библиотеку Fizz, которая позволяет повысить скорость и безопасность приложений.

Выбрали три конкурсные номинации и для каждой из них подготовили по три вопроса. Поехали?

Зачем менять IPv4 на что-то другое?

Потому что адресов IPv4 уже не хватает.

IP-уровень стека протоколов TCP/IP — наиболее важная часть всей архитектуры Интернета. Тем не менее вскоре после запуска IPv4 стали очевидны его ограничения в плане масштабируемости и возможностей. IPv4 для работы необходимо несколько надстроек вроде ICMP и ARP. К середине 1990-х разработали замену IPv4 — IPv6. Требований к Интернету становилось всё больше, а IPv6 отвечал им лучше, чем предыдущая версия.

Каковы самые очевидные отличия IPv4 и IPv6?

• 128 бит в IPv6-адресе представляют собой восемь 16-битных шестнадцатеричных блоков, разделённых двоеточиями. Например, 2dfc:0:0:0:0217:cbff:fe8c:0. Традиционной формой записи IPv4 адреса является запись в виде четырёх десятичных чисел (от 0 до 255), разделённых точками. Через дробь указывается длина маски подсети. Например, 192.168.0.0/16.
• В IPv4 для мультивещания зарезервирована подсеть 224.0.0.0/4. IPv6 для этой цели использует встроенное адресное пространство FF00::/8;
• IPv4 использует широковещательные адреса для передачи широковещательных пакетов, IPv6 — многоадресные группы;
• IPv4 использует 0.0.0.0 в качестве неопределённого адреса, а 127.0.0.1 для создания адреса обратной связи (loopback). В IPv6 используются :: и ::1 соответственно;
• IPv4 использует глобально уникальные публичные адреса для трафика и «частные» адреса, IPv6 — глобально уникальные юникаст-адреса и локальные адреса (FD00::/8).

Чем IPv6 лучше?

Преимущества IPv6 перед IPv4:

• Более эффективная маршрутизация без фрагментации пакетов;
• Встроенная технология Quality of Service (QoS), которая определяет чувствительные к задержке пакеты;
• Устранение NAT для расширения адресного пространства с 32 до 128 бит;
• Встроенная поддержка IPsec (использование IPsec опционально);
• Автоконфигурация адресов для упрощения администрирования сети;
• Улучшенная структура заголовка с меньшими затратами на обработку.

IPv6 более безопасен, чем IPv4?

Нет, в теории они одинаково безопасны.

После запуска IPv6 появилась встроенная возможность шифровать интернет-трафик с помощью распространённого (но не настолько, как SSL) стандарта шифрования IPSec, который не даёт прочитать содержимое трафика при его перехвате. Однако шифрование и расшифровка данных требует оборудования, которое стоит денег. К тому же IPSec можно реализовать и на IPv4, что в теории означает, что IPv4 и IPv6 одинаково безопасны.

Некоторые эксперты утверждают, что пока переход не завершён, пользователи шестой версии находятся в большей опасности, чем пользователи четвёртой. Провайдеры могут использовать IPv6-туннели для предоставления пользователям IPv4 доступа к IPv6-контенту. Злоумышленники могут использовать эти туннели для проведения своих атак.

Ещё одна потенциальная проблема связана с автоконфигурацией — новой функцией IPv6. Она позволяет устройствам самостоятельно назначать себе IP-адрес на основе MAC-адреса, что может быть использовано сторонними лицами для отслеживания определённых пользователей. Тем не менее на устройствах под управлением популярных операционных систем уже установлены расширения конфиденциальности, поэтому для большинства людей это не будет проблемой.

IPv6 быстрее IPv4?

Скорость интернета с IPv6 не будет сильно отличаться от скорости с IPv4. С одной стороны, работа IPv6 должна быть быстрее из-за более простого формата. Однако во время перехода некоторые методы вроде IPv6-туннелей будут создавать дополнительную задержку при преобразовании запросов в IPv4 и наоборот.

Так почему бы просто не перейти на IPv6?

Основная причина — стоимость. Для обновления всех серверов, маршрутизаторов и коммутаторов, которые всё это время зависели только от IPv4, требуется уйма денег и времени.

Кроме того, чтобы справиться с нехваткой адресов, провайдеры назначают пользователям динамический адрес, который может меняться при подключении к другой сети. После отключения от сети устройства освобождают свой адрес, делая его доступным для других устройств. По сути вы арендуете, но не владеете адресом. Это сильно замедляет переход с IPv4 на IPv6.

Но это не значит, что IPv6 не распространяется. Напротив, он используется параллельно с IPv4. Как сообщает Google, около 14% его пользователей используют IPv6. А по заявлениям провайдера Comcast, в Соединённых Штатах уже половина пользователей используют IPv6.

Резюмируем

Нельзя сказать, что IPv6 быстрее и безопаснее, но у него есть ряд преимуществ вроде более эффективной маршрутизации без фрагментации пакетов, встроенной поддержки IPsec и автоконфигурации адресов. А из-за ограниченности адресного пространства IPv4 переход на него неизбежен.

SNI и ESNI

Расширение протокола TLS носит название SNI и используется для размещения на одном IP-адресе нескольких HTTPS-сайтов с их сертификатами. Имя хоста открыто передаётся до процесса шифрования в сообщении ClientHello. Однако при использовании ESNI имя хоста зашифровывается в поле с помощью секрета. Клиент и сервер получат к нему доступ только в случае успешного обмена ключами. Расшифровка поля требует знания открытых и закрытых ключей обеих сторон либо согласованного в процессе установки TLS-соединения секрета.

Польза ESNI

Новое расширение не позволит сторонним лицам получить информацию о сайтах, к которым обращался пользователь. К примеру, провайдеры не смогут выборочно фильтровать трафик. Библиотеки браузеров Chromium и Firefox, а также HTTP-сервера h20 уже поддерживают начальную спецификацию расширения.

Amazon и Google уже реализовали возможность сокрытия имени хоста от лишних глаз. Однако с 27 апреля 2018 года Amazon оставила доступ к доменному фронтированию для ограниченного количества пользователей. Ранее, 13 апреля 2018 года, Google полностью отключила ту же функцию, поскольку она использовалась в устаревшем программном обеспечении.

Метод обхода

При обработке большого числа пакетов через стандартную систему сокетов операции их копирования в память проходят несколько раз. Разработчики BBC обнаружили, что фреймворк Netmap помогает передавать сразу несколько пакетов сетевой карте, сокращая число операций. В качестве сетевого адаптера в корпорации использовали Mellanox ConnectX-4 с открытым драйвером для ядра Linux, но без поддержки в Netmap.

Реализация

В BBC подготовили код для поддержки сетевых адапетров Mellanox в Netmap и добились производительности на уровне 80 Гб/с при однопоточном тестировании. Они также предложили новый драйвер mlx5 с поддержкой прямого взаимодействия c 10/25/40/50/100-гигабитными Mellanox ConnectX-4 и ConnectX-5 для включения в основной состав проекта Netmap.

Напомним, что в апреле 2018 года анонсирована стабильная версия Linux 4.16. Основные изменения коснулись драйверов, общего взаимодействия с аппаратной частью, файловой системы и работы с сетью.

Распределение утечки

Под угрозой находится такая частная информация, как патентные заявки, расчётные ведомости, налоговые декларации, списки пациентов, заявки на авторское право, результаты аудитов безопасности и исходные коды программ. Общий объём открытых данных близок к 12 000 терабайт. Главные источники утечки — файловый хостинг Amazon S3, программа для оптимальной синхронизации файлов rsync и протоколы передачи SMB и FTP.

Самое большое число открытых приватных данных обнаружилось на территории стран Евросоюза и США.

Иногда пользователи систем страдают не от собственной невнимательности. Напомним, что в конце марта 2018 года персональные данные 87 миллионов пользователей Facebook попали в третьи руки и были использованы для таргетированной политической рекламы в США.

Основные изменения

TLS 1.3 значительно увеличивает скорость загрузки веб-страниц для мобильных устройств. Это достигается путем «удаления» соединения установления сеанса.

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

Хотя Chrome, Firefox, Opera и Edge уже поддерживают TLS 1.3, по умолчанию они не работают. Исследователи Cloudflare утверждают, что только 0,6 % трафика проходит с помощью новой версии протокола.

Особенности

Новый протокол позволяет администраторам сайтов получить групповой сертификат (wildcard), с помощью которого можно разом защитить всю группу поддоменов. Это особенно актуально в условиях массового перевода стандартов безопасности в область HTTPS. Например, в браузере Firefox с декабря 2017 года все сайты на протоколе HTTP помечаются как небезопасные, а в Chrome эта функция активирована уже более года.

Для активации wildcard-сертификата необходимо установить клиентское программное обеспечение с поддержкой протокола ACMEv2. Чтобы пользоваться новыми возможностями, владельцам сертификатов, полученных с помощью ACMEv1, потребуется повторная авторизация. Подтверждение доменов, для которых запрашиваются «вайлдкарды», пока возможно только через DNS.

Несмотря на отсутствие точной даты истечения срока жизни ACMEv1, Let’s Encrypt намерен как можно скорее перевести всех пользователей на обновлённый стандарт. Это позволит приблизить воплощение главной цели организации — перевод всех веб-ресурсов на HTTPS. На момент написания новости общая доля сайтов с поддержкой шифрования составляет примерно 69 %. Чуть менее половины из них пользуются бесплатными сертификатами Let’s Encrypt.

Концепция блокчейна масштабируется и уже неотделима от экономической системы, и поэтому ей требуется общий способ передачи информации. Хотя каждая блокчейн-платформа отвечает только за внутреннюю безопасность, рано или поздно ей приходится работать с банками и другими внешними организациями. И именно для этого необходима общая инфраструктура. Например, такая, как Aion — первая сеть обмена информацией между разными блокчейн-платформами.

И что же, скоро можно будет подключаться?

К сожалению, не всё так гладко. Во-первых, необходимо убедить закрытые блокчейн-сообщества обмениваться информацией между собой, не говоря уже о передаче данных легальным коммерческим структурам или государственным органам. Во-вторых, сам принцип подразумевает использование единственного способа передачи информации, а следовательно, создание открытого для всех сетевого протокола. Блокчейн превратится в новый Интернет, активность в котором власти смогут контролировать.

Какой тогда в этом смысл?

Плюсов у глобальной блокчейн-сети больше. Например, компании смогут использовать криптовалюту для перемещения данных с целью монетизации. Генеральный директор Nuco Мэттью Споук видит Aion, как рыночную необходимость. Тот момент, когда блокчейн станет массовым и потребует наличия инфраструктуры, уже не за горами — и тогда рынку поможет Aion.

В курсе рассматриваются основы системного администрирования интернет-сервисов, обеспечения их отказоустойчивости, производительности и безопасности, а также особенности устройства ОС Linux, наиболее широко применяемой в подобных проектах.

На момент публикации записи курс еще не завершен и дополняется.

Также смотрите наши статьи, новости и видео по Linux.

В основном всё разбирается на примере практических кейсов, но для их понимания даются и необходимые теоретические знания.

Лектор — Дмитрий Молчанов. Курс записан осенью 2015 года в рамках Технопарка Mail.ru Group в МГТУ им. Н.Э. Баумана. Слайды курса доступны для скачивания.

Также смотрите наши статьи, новости и видео по Linux.

Первую версию SSH я написал весной 1995 года. В то время широко использовались протоколы telnet и FTP. И я решил создать собственный протокол, который бы заменил используемые версии. У telnet был порт 23, у FTP — 21. Порт 22 как раз не был занят, и я подумал, что такой номер добавит авторитетности моему протоколу.

Процесс распределения портов в то время был достаточно прост. Интернет-пространство было намного меньше, интернет-бум ещё только начинался. Порты распределяла Администрация адресного пространства Интернет (IANA) в лице Джона Постела и Джойса К. Рейнольдса. 10 июля 1995 года я отправил туда e-mail с описанием преимуществ своего протокола и просьбой выделить для него порт 22. И на следующий день мне пришёл ответ с официальным закреплением порта 22 за SSH. 12 июля я отправил финальную бета-версию на тестирование в Технологический университет Хельсинки, отправил уведомления в рассылку cypherpunks@toad.com и ещё нескольким людям и сообществам.

Изменения порта SSH на сервере

SSH-сервера всё ещё по умолчанию работают на порту 22. Но бывают и исключения, например, для тестирования или запуска нескольких конфигураций на одном хосте. Иногда сервер может быть запущен и без root-привилегий, тогда он запускается на непривилегированном порту (например, порт с номером от 1024). Изменить номер порта можно через команду /etc/ssh/sshd_config. Он также может быть указан в опции -p для sshd.

Вашу проблему решает ngrok — простейшая утилита для создания туннеля к localhost.

С её использованием справится даже новичок, для создания туннеля достаточно выполнить следующую команду:

… где 80 — это порт, на котором запущен ваш веб-сервер. 80 является портом по-умолчанию для многих серверов, так  что скорее всего всё заработает без изменений. В ответ получите на экран вывод следующего типа:

Где 5057493e.ngrok.io — это адрес, по которому ваш локальный сервер стал доступен в интернете.

Если ваш сервер открывается не по адресу http://localhost/, а на него через файл hosts назначен домен, например, mysite.dev, то запустить ngrok для него не сильно сложнее.

Вам поможет следующая команда:

…где 80 является портом вашего сервера, а mysite.dev доменом, по которому он отвечает.

Ngrok доступ для Linux, Mac, Windows и FreeBSD. Со всеми возможностями программы можно ознакомиться в документации.