SMPP или HTTP API к SMSC: какой протокол нужен вашей платформе?

Подключая платформу обмена сообщениями к внешнему миру, вы на деле выбираете, как она будет взаимодействовать с операторами, и широко распространены два варианта. Первый вариант: SMPP, бинарный телеком-протокол, который уже несколько десятилетий передаёт SMS от приложений к людям (A2P). Второй: HTTP API, та же модель «запрос и ответ», на которой работает остальной веб. Это не столько конкуренты, сколько инструменты для разных задач, и честный вывод, к которому ведёт это руководство, таков: всё, что можно назвать серьёзной платформой, в итоге поддерживает оба протокола. Ниже разберём, что на самом деле их различает и почему.

Что такое SMPP и почему операторы до сих пор на нём работают

SMPP (Short Message Peer-to-Peer) представляет собой бинарный протокол, который работает поверх долгоживущего TCP-соединения, по соглашению на порту 2775. Вместо того чтобы открывать новое соединение для каждого сообщения, как это делает веб-запрос, SMPP-клиент устанавливает постоянную сессию, которая называется bind, в одном из трёх режимов: transmitter (только отправка), receiver (только приём) или transceiver (и то и другое в одном соединении). После установки bind клиент передаёт поток компактных бинарных пакетов, которые называются PDU: submit_sm для отправки сообщения, deliver_sm для приёма сообщения или отчёта о доставке, enquire_link как heartbeat для поддержания сессии.

Операторы и крупные агрегаторы до сих пор выбирают его как стандарт из-за эффективности на больших объёмах. Постоянный bind избавляет от накладных расходов на установку соединения для каждого сообщения, а SMPP поддерживает окно (windowing): отправитель может передать несколько сообщений, не дожидаясь подтверждений, поэтому один исправный bind выдерживает от сотен до нескольких тысяч сообщений в секунду. Кроме того, протокол создан специально для этой области: в нём есть встроенные поля для имени отправителя, кодировки данных, срока действия, отложенной доставки и флагов запроса отчёта о доставке (registered delivery). Когда трафик измеряется миллионами сообщений в сутки, такая плотность и такой контроль перестают быть роскошью: от них зависит, понадобится вам один сервер или десять.

Платой за эти возможности становится сложность. SMPP хранит состояние (stateful), поэтому вам приходится управлять bind-сессиями, переподключаться при обрывах, отвечать на heartbeat, соблюдать размер окна и сопоставлять асинхронные отчёты с сообщениями по идентификатору. Кроме того, протоколу обычно нужна стабильная привязка к IP-адресам, поэтому bind с операторами часто работают через белый список IP-адресов или небольшой VPN, а не через открытый интернет.

Где уместны HTTP API к SMSC

HTTP API построен на противоположном компромиссе. Вы отправляете один запрос на сообщение (или на небольшой пакет) на URL, получаете один ответ в формате JSON или формы, и никакую сессию поддерживать не нужно. Аутентификация выполняется токеном или ключом в заголовке, отчёты о доставке приходят как webhook-вызовы на URL, который размещаете вы, и всё это проходит через обычные файрволы и балансировщики нагрузки без особой настройки. Для разработчика подключение HTTP-поставщика занимает полдня, а подключение SMPP-стека превращается в отдельный проект.

Именно из-за этой простоты HTTP-поставщиков стало так много. Очень многие региональные провайдеры, агрегаторы WhatsApp и RCS, а также новые игроки рынка CPaaS предлагают в первую очередь HTTP, а SMPP только по запросу или не предлагают вовсе. Для малых и средних объёмов или для страны, куда вы отправляете трафик через одного профильного поставщика, HTTP-маршрут не компромисс, а разумный выбор. Накладные расходы на сообщение выше, а предельная пропускная способность ниже, чем у хорошо настроенного bind по SMPP, но масштабируется HTTP обычным способом, горизонтально, за счёт увеличения числа параллельных запросов, и для большинства реселлеров этот предел намного выше их реального трафика.

Честно говоря, ограничение здесь в контроле и единообразии. Каждый HTTP-поставщик придумывает собственные названия полей, собственный способ передачи Unicode и длинных сообщений и собственный формат callback для DLR. Подключив пять HTTP-поставщиков, вы фактически интегрируете пять немного разных продуктов.

Реальные различия: пропускная способность, DLR и кодировка

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

Пропускная способность и управление потоком. Пропускную способность SMPP определяют размер окна и задержка на полный цикл запроса и ответа: при окне, скажем, в 10 неподтверждённых PDU и быстром канале один bind пропускает большой объём трафика, а операторы следят за договорной скоростью, которую нельзя превышать, иначе они начинают ограничивать ваш трафик (throttling). Пропускную способность HTTP определяют число параллельных запросов и лимит поставщика (rate limit), который обычно выражается в запросах в секунду. Практический вывод: SMPP выигрывает при небольшом числе хорошо управляемых постоянных соединений, а HTTP при пуле воркеров, которые выполняют параллельные вызовы. Соответственно различается и устройство очереди и воркеров в вашей платформе.

Отчёты о доставке. Именно здесь ломаются наивные интеграции. В SMPP DLR не является ответом на ваш submit: он приходит позже, без запроса, в виде deliver_sm на ваш bind, и вы должны сопоставить его с исходным сообщением по идентификатору, который оператор присвоил при отправке. Если вы не слушаете bind или теряете его, отчёты пропадают. В HTTP DLR представляет собой callback, который поставщик отправляет методом POST на ваш webhook, а значит, ваш эндпоинт должен быть доступен, идемпотентен (поставщики повторяют запросы) и способен сопоставлять отчёты по вашему собственному идентификатору. Понятие одно и то же (доставлено, не доставлено, истёк срок, отклонено, неизвестно), но механизмы надёжного получения совершенно разные.

Кодировка символов. Здесь SMS не прощает ошибок. Алфавит GSM 03.38 позволяет уместить 160 символов в одно 7-битное сообщение; стоит выйти за его пределы (эмодзи, многие символы с диакритикой или нелатинские символы), и сообщение переключается на UCS-2, где в одну часть помещается всего 70 символов. Более длинный текст делится на сегменты, которые склеиваются с помощью заголовка пользовательских данных (user data header), и каждый сегмент тарифицируется. SMPP даёт прямой доступ к этому механизму через поле data_coding и ожидает, что вы зададите его правильно. HTTP-поставщики обычно стараются скрыть его за абстракцией, но делают это непоследовательно, и поставщик, который молча переводит Unicode-сообщение в упрощённую кодировку или неверно считает сегменты, незаметно будет стоить вам денег или испортит текст. Какой бы протокол вы ни использовали, ваша платформа должна обрабатывать кодировку осознанно, а не надеяться, что поставщик всё сделает правильно.

Почему серьёзная платформа поддерживает оба протокола

Если свести эти различия вместе, вывод очевиден. Лучшим маршрутом в одну страну может оказаться bind по SMPP с национальным оператором, единственным маршрутом в другую может быть профильный HTTP-поставщик, а резервным маршрутом (failover) для обеих может стать третий поставщик на том протоколе, который он предлагает. Если ваша платформа поддерживает только один протокол, выбор маршрутов сокращается вдвое, а переговоры с поставщиками зависят от технического ограничения, а не от цены и качества доставки.

Поэтому зрелый шлюз использует SMPP-стек и HTTP-клиент параллельно и, как правило, предоставляет оба варианта своим клиентам: SMPP-сервер, к которому подключаются технически подготовленные клиенты, и HTTP API для всех остальных. Настоящая ценность платформы не в каком-то одном протоколе, а в уровне над ними (движок маршрутизации, биллинг, нормализация отчётов о доставке), благодаря которому выбор протокола незаметен для того, кто отправляет сообщение. Именно поэтому в Smppcube, платформе на собственном сервере, есть и SMPP-сервер операторского класса, и HTTP API: так движением трафика управляет оператор, а не протокол. Если вы решаете, стоит ли эксплуатировать такой стек самостоятельно, практическая сторона описана в руководстве по SMS-шлюзу на собственном сервере.

Один универсальный адаптер для HTTP-поставщиков (как это работает на практике)

Ловушку HTTP-поставщиков (каждый из них чуть-чуть отличается от остальных) можно обойти, и решение представляет собой паттерн, в котором стоит разобраться до покупки или разработки. Вместо того чтобы писать отдельный код под каждого поставщика и разбрасывать его по всей кодовой базе, вы определяете один внутренний интерфейс, единый нормализованный формат для операций «отправить сообщение» и «получен отчёт о доставке», а затем пишете для каждого поставщика тонкий адаптер, который переводит особенности поставщика в этот внутренний формат и обратно.

Каждый адаптер отвечает ровно за различия: как этот поставщик выполняет аутентификацию, как у него называются поля получателя и текста, как он требует помечать Unicode и как разобрать его собственный формат callback для DLR и привести его к общему набору статусов платформы. Всё, что находится выше (очередь, маршрутизатор, биллинг, отчёты), работает только с внутренним интерфейсом и не знает и не должно знать, какой поставщик за ним стоит. Подключение нового HTTP-поставщика сводится к настройке и небольшому адаптеру, а не к переделке системы, и поставщики голосовой связи через API, если вы добавите их позже, подключаются точно так же. Так платформа остаётся открытой для десятков региональных поставщиков и не рушится под грузом их несовместимостей. Именно такую архитектуру уже должен реализовывать шлюз на собственном сервере, чтобы при добавлении маршрута вам никогда не приходилось трогать код протокола.

Что выбрать?

Если вы реселлер, подключаете первого поставщика и он предлагает HTTP, начните с него: такая интеграция быстрее, её легко тестировать, и её достаточно, чтобы проверить ваш бизнес на практике. Добавляйте SMPP, когда объём трафика, отношения с оператором или технически подготовленный клиент, который хочет подключаться к вам по bind, оправдывают дополнительную инфраструктуру. Если вы агрегатор или оператор с серьёзными объёмами и прямыми договорами с операторами, SMPP для вас не опция, а язык, на котором говорят ваши поставщики.

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