ольшинство интеграций корпоративных систем обмена сообщениями начинаются с одного технического вопроса: REST API или SMPP? Неправильный ответ не катастрофичен — оба протокола могут работать — но правильный ответ экономит месяцы времени на интеграцию, иногда порядки стоимости эксплуатации и устраняет едва заметные проблемы с задержкой, которые проявляются только под нагрузкой. Вот подробная версия обсуждения принятия решения: для чего на самом деле оптимизирован каждый протокол, четыре параметра, которые должны определять выбор, и аргументы в пользу использования обоих протоколов в одной корпоративной среде.
Два протокола, два разных центра проектирования
REST SMS API — это безсостоятельный HTTPS-интерфейс. Вы отправляете JSON-данные методом POST на URL, сервер возвращает код состояния, и соединение может быть закрыто. Аутентификация осуществляется с помощью токена носителя или подписанного запроса; данные передаются в формате JSON; подтверждения приходят через веб-хуки, размещенные клиентом. Это язык проектирования, на котором уже говорят современные разработчики приложений — запрос, ответ, повторная попытка при ошибке 5xx, посмотрите на заголовки.
SMPP 3.4 (/answers/what-is-smpp) — это протокол с сохранением состояния, работающий через постоянный TCP-сокет. Клиент устанавливает соединение один раз, указывая идентификатор системы, пароль, тип системы, диапазон адресов и тип привязки (передатчик, приемник, приемопередатчик). Сообщения передаются в виде PDU (submit_sm для отправки, deliver_sm для входящих и DLR) в обоих направлениях через один и тот же сокет, идентифицируемые порядковыми номерами. Keepalive (enquire_link) поддерживают сессию; оконная обработка управляет параллельным доступом. Сессия может оставаться активной в течение нескольких дней.
Это архитектурное различие — кратковременный HTTP без сохранения состояния против долговременного TCP с сохранением состояния — определяет все практические компромиссы, описанные ниже.
Четыре измерения, которые это определяют
1. Пропускная способность и задержка
HTTPS выполняет рукопожатие TCP плюс рукопожатие TLS при каждом соединении, если клиент не использует пулы и повторное использование соединений в агрессивном режиме. Даже при агрессивном использовании пулов накладные расходы на каждое сообщение существенны при высокой TPS, даже несмотря на то, что BroadNet не устанавливает фиксированных лимитов скорости на аккаунт для REST (см. лимиты API). SMPP выполняет рукопожатие ровно один раз за привязку, а затем передает PDU без затрат на соединение для каждого сообщения; поддержание сотен или нескольких тысяч TPS при одной привязке является обычным делом, ограниченным согласованным размером окна и целевым SMSC, а не процессом установления соединения. Для трафика, критичного к задержке, SMPP также исключает рукопожатие TLS из критического пути: OTP, отправленный через «горячую» привязку SMPP, может оказаться на SMSC целевого оператора менее чем за 50 мс; тот же OTP, отправленный по HTTPS, проходит рукопожатие каждый раз, если соединение не используется повторно, что часто некорректно обрабатывается кодом приложения.
2. Накладные на доставку
В протоколе SMPP уведомления о доставке поступают в виде PDU deliver_sm в том же канале связи, в режиме реального времени. Приложение считывает их из сокета; общедоступная инфраструктура не требуется. В протоколе HTTPS DLR представляют собой обратные вызовы веб-перехватчика, которые клиент должен получить на общедоступной, высокодоступной конечной точке HTTPS, а затем сопоставить с отправленными сообщениями. Эта конечная точка представляет собой реальное операционное обязательство: управление сертификатами, обработка повторных попыток при временной недоступности, защита от атак повторного воспроизведения (проверка каждого обратного вызова: подпись HMAC с общим секретом и меткой времени, если ваш провайдер подписывает обратные вызовы, или список разрешенных IP-адресов, если нет — см. Подписание DLR HMAC-SHA256) и идемпотентная обработка, поскольку провайдеры будут доставлять веб-перехватчик более одного раза при повторной попытке.
3. Рабочая поверхность
Интеграция REST — это то, что бэкенд-разработчик выпускает за один день и в значительной степени забывает. Библиотека HTTP-клиента обрабатывает повторные попытки, фреймворк — конечную точку веб-перехватчика, а мониторинг осуществляется с помощью того, что уже есть в приложении. Интеграция SMPP — это инфраструктура: клиент должен обрабатывать жизненный цикл привязки (привязка, повторная привязка при разрыве соединения, экспоненциальная задержка, отсутствие переадресации на неработающий SMSC), регулярно отправлять запросы на поддержание соединения с обнаружением таймаута, отслеживать порядковый номер для корреляции PDU, управлять окном для исходящих запросов submit_sm, корректно отключаться при завершении работы и, в идеале, обеспечивать многоканальное переключение при сбое для высокой доступности. Это постоянная ответственность инженера, а не разовая интеграция. Многим командам, которые соответствуют техническим критериям для SMPP, лучше подходит HTTPS просто потому, что они не хотят постоянно иметь в своем арсенале сервисов стек телекоммуникационных протоколов.
4. Эргономика разработчика и идемпотентность
Многие современные REST API включают заголовки с ключом идемпотентности, стандартизированную пагинацию, клиенты с типизацией OpenAPI на всех основных языках программирования, документацию по подписанным веб-хукам, песочницы и панели управления для разработчиков. В протоколе SMPP ничего этого нет — это бинарная спецификация 1990-х годов с более богатой телекоммуникационной семантикой, но более упрощенным интерфейсом для разработчиков. Идемпотентность в SMPP существует только как определяемая клиентом конвенция (обычно это уникальная ссылка на сообщение в пользовательских данных); защита от повторного воспроизведения — задача приложения; песочницы должны создаваться провайдером, а не поставляться вместе с протоколом. Впрочем, и не каждый REST-провайдер предлагает всё перечисленное: REST API BroadNet не принимает ключ идемпотентности — безопасные повторы опираются на возвращаемый идентификатор сообщения и проверку статуса перед повторной отправкой (см. идемпотентность и безопасные повторы), — а тестовый доступ работает через продуктивный API с тестовыми учётными данными, а не в отдельной песочнице.
Простая матрица принятия решений
| Если ваша ситуация такова… | Используйте это |
|---|---|
| Трафик объемом менее нескольких сотен сообщений в секунду, рабочая нагрузка, адаптированная под конкретное приложение, небольшая команда | REST API |
| Стабильно несколько сотен сообщений в секунду или потребность в постоянных bind-сессиях; смешанный, транзакционный и пакетный. | SMPP 3.4 (или оба) |
| Критически важная с точки зрения задержки ОПТ при любом объеме | SMPP для OTP; REST для всего остального. |
| Вы являетесь агрегатором маршрутизации для нижестоящих клиентов. | СМПП, период |
| У вас уже есть инфраструктура SMS, построенная на протоколе SMPP. | Сохраните SMPP; не переходите на другую платформу без веских причин. |
| Вам нужно быстрое получение первого сообщения, но у вас нет оперативной группы. | REST API |
| Вам необходима надежная защита веб-хуков с подписанными коллбэками | REST API; проверяйте обратные вызовы при получении (HMAC, если провайдер их подписывает, или список разрешенных IP-адресов) |
| Необходимо поддерживать постоянный двусторонний диалог. | SMPP, привязка приемопередатчика |
Когда запускать оба варианта?
Решение не всегда сводится к выбору «или/или». Распространенная корпоративная модель: SMPP для критически важных по объему и задержке рабочих нагрузок (OTP, массовые рассылки, маркетинговые всплески), REST для всего остального (внутренние инструменты с небольшим объемом данных, оперативные оповещения, интеграция с SaaS-продуктами, уже поддерживающими HTTP). Стоимость сообщения одинакова в правильно спроектированной сети провайдера, поэтому использование обоих протоколов не ухудшает экономику предприятия — а предоставление разработчикам возможности использовать REST для небольших задач, за которые они отвечают, в то время как операционный отдел использует SMPP для крупных задач, учитывает командную структуру большинства предприятий.
Команды попадают в ловушку: REST в масштабе SMPP.
Наиболее распространенная ошибка — выбор REST из-за простоты использования, а затем масштабирование нагрузки сверх возможностей REST. Симптомы проявляются постепенно: постепенно увеличивается задержка p95, периодически возникают таймауты во время пиков трафика, исчерпывается пул исходящих соединений приложения, а повторные попытки лавинообразно приводят к дублированию отправок. Решение не в том, чтобы «сильнее оптимизировать HTTP-клиент» — как только вы стабильно отправляете несколько сотен сообщений в секунду, правильным решением будет миграция высоконагруженного пути на SMPP и сохранение REST для всего остального. Миграцию следует проводить до того, как нагрузка сделает это срочным, а не во время сбоя.
Ловушка с другой стороны: SMPP без его использования.
Ошибка, подобная зеркальному отображению, заключается в выборе SMPP для обеспечения высокой пропускной способности и последующей небрежной эксплуатации — однократное подключение, отсутствие логики повторного подключения, отсутствие мониторинга поддержания соединения, отсутствие многорегионального переключения при сбое. Первый перезапуск SMSC, первый сбой в сети, первое окно технического обслуживания провайдера приводят к незаметному сбою, потому что подключение прервалось, и никто не следит за ситуацией. SMPP вознаграждает операционную дисциплину; без нее REST значительно безопаснее.
Безопасность и современная аутентификация
Интеграция REST должна осуществляться с использованием токенов bearer или учетных данных клиента OAuth2 с ротацией токенов, передачей данных по протоколу TLS 1.3 и проверкой обратных вызовов веб-хуков для входящих DLR (подпись HMAC с общим секретом, если провайдер подписывает обратные вызовы, или список разрешенных IP-адресов). Протокол SMPP должен работать по протоколу TLS 1.3 (/answers/tls-1-3-in-messaging) — использование SMPP в открытом текстовом формате в общедоступном интернете неприемлемо для любой современной реализации A2P, независимо от того, что допускает спецификация, — с регулярной ротацией идентификатора системы и пароля, а также включением IP-адреса источника в список разрешенных адресов у провайдера. Ни один из протоколов не освобождает клиента от соблюдения базовых требований безопасности; оба могут работать в соответствии с корпоративными стандартами.
BroadNet предоставляет одинаковые возможности маршрутизации, механизм доставки и соответствие идентификатору отправителя как для SMS API, так и для SMPP 3.4 — выбор протокола меняет форму интеграции, а не качество сообщений. Для REST-пути доступны тестовые учётные данные для продакшн-эндпоинта, официальный TypeScript SDK и спецификация OpenAPI 3.1; для бинарного пути — учетные данные SMPP с конечными точками TLS 1.3 и резервированием в двух регионах.
Как принять решение на практике, ответив на три вопроса.
- Каков реалистичный пиковый показатель TPS для рабочей нагрузки в течение следующих 24 месяцев, а не комфортный средний показатель? REST достаточно справляется с трафиком, формируемым приложением (BroadNet не устанавливает фиксированных лимитов скорости на аккаунт); планируйте SMPP, если вы стабильно отправляете несколько сотен сообщений в секунду или вам нужны постоянные bind-сессии; вблизи этой границы необходимо определить критичность задержки и готовность команды к операциям с постоянным протоколом.
- Хочет ли ваша команда использовать постоянный TCP-клиент с сохранением состояния, жизненным циклом привязки, механизмом поддержания соединения и логикой переподключения? Честный ответ «нет» вполне допустим и указывает на REST.
- Есть ли одна критически важная с точки зрения задержки рабочая нагрузка (OTP, оповещения в реальном времени) и множество второстепенных? Двухпротокольная схема подходит — SMPP для критически важных задач, REST для остальных.
Конкретный пример — типичный профиль финтех-компании.
Рассмотрим региональную финтех-компанию с тремя типами обмена сообщениями: одноразовые пароли (OTP) для входа в систему и подтверждения транзакций (большой объем, критичная задержка, транзакционный характер), входящие и исходящие сообщения в службу поддержки клиентов (малый объем, диалоговый характер, двусторонний обмен) и маркетинговые кампании (периодические всплески, пакетная обработка). Прагматичная архитектура: привязка SMPP-трансивера для OTP (один основной трансивер, один резервный трансивер в другом регионе, автоматическое переключение при сбое); REST API для службы поддержки клиентов (сервис на основе веб-хуков упрощает входящие сообщения); SMPP-передатчик для маркетинговых кампаний, когда они происходят (всплески — это именно тот случай, когда стоимость рукопожатия за каждое сообщение в REST становится существенной). Три шаблона интеграции, два протокола, все у одного провайдера — и одинаковая цена за единицу на разумной сети провайдера. Команда владеет одним постоянным стеком (SMPP-клиентом) и повторно использует стандартный HTTP для всего остального.
Миграционный путь между двумя
Команды, которые начинают с REST и перерастают его, не нуждаются в миграции всего проекта в рамках одного проекта. Распространенный путь: внедрение SMPP для той рабочей нагрузки, которая в нем больше всего нуждается (обычно это OTP), проверка жизненного цикла привязки и логики переподключения в среде с низкими рисками, параллельное использование SMPP и REST в течение одного-двух месяцев с мониторингом качества доставки и задержки в обоих протоколах, а затем миграция дополнительных рабочих нагрузок на SMPP по мере роста уверенности команды в протоколе. Обратный путь (от SMPP к REST) встречается реже и почти всегда является признаком того, что команда хочет отказаться от оперативного управления телекоммуникационными протоколами в пользу простоты HTTP — это также допустимый выбор, также осуществимый для каждой рабочей нагрузки отдельно.
Рекомендуемая литература
- Почему сообщения OTP не доставляются и как исправить проблемы с доставкой
- Как выбрать поставщика корпоративных систем обмена сообщениями
- Прямые маршруты против серых маршрутов в A2P SMS
- Глоссарий — REST против SMPP, что такое SMPP, что такое SMS API
- Страницы продукта — SMS API и документация для разработчиков
Полное сравнение по пунктам — в материале SMPP или HTTP (REST) API для SMS.