Для малого бизнеса Беларуси выбор между «голым» SMPP и HTTP API зависит от объёма отправки, требований к контролю доставки и готовности заниматься технической интеграцией. HTTP API проще запустить, когда SMS отправляются из сайта или CRM небольшими партиями. SMPP оправдан, когда нужен постоянный поток сообщений, несколько соединений, управление скоростью и подробный контроль статусов. Ниже разберём различия, критерии выбора и порядок подключения, чтобы оценить задачу до разговора с провайдером.
Чем SMPP отличается от HTTP API?
HTTP API обычно работает как веб-запрос: приложение передаёт текст, номер и дополнительные параметры, а сервис возвращает ответ о принятии запроса. Такой способ понятен разработчику, который уже работает с REST, JSON и веб-сервисами. Для разовой отправки уведомления после заказа достаточно вызвать один метод API и обработать ответ.
SMPP устанавливает постоянное соединение между приложением и SMS-шлюзом. Программа подключается с учётными данными, отправляет команды протокола и получает ответы по тому же соединению. Для этого нужно учитывать bind, sequence number, скорость передачи, повторные подключения, тайм-ауты и входящие delivery receipts, или DLR.
Разница заметна в контроле. HTTP API скрывает часть работы внутри сервиса, а SMPP даёт разработчику больше параметров: количество соединений, режим отправки, обработку ответов и маршрутизацию трафика. Цена такой свободы — отдельная настройка приложения и постоянный мониторинг соединения.
| Критерий | HTTP API | SMPP |
|---|---|---|
| Старт интеграции | Обычно проще для небольшого проекта | Требует понимания протокола и состояний соединения |
| Тип соединения | Отдельные HTTP-запросы | Постоянная сессия с SMS-шлюзом |
| Контроль нагрузки | Часто задаётся параметрами API или ограничениями сервиса | Настраивается через окна сообщений, соединения и лимиты |
| Статусы доставки | Зависят от формата API и реализации провайдера | Передаются через DLR при поддержке со стороны шлюза |
| Массовая отправка | Подходит при корректной очереди запросов | Удобна для постоянного высокообъёмного трафика |
| Поддержка | Меньше протокольных деталей на стороне бизнеса | Нужно обслуживать соединение и разбирать ответы SMPP |
Таблица показывает принцип, а не универсальное правило. Один и тот же бизнес может оставить HTTP API для редких административных уведомлений, а поток заказов перевести на SMPP. При выборе смотрите на архитектуру приложения, а не только на название протокола.
Когда малому бизнесу достаточно HTTP API?
HTTP API разумно выбрать, если SMS уходят из одного приложения и отправка начинается после конкретного события: оформления заказа, изменения статуса или запроса кода. В этом сценарии важны короткая интеграция и понятная обработка ошибок. Приложение формирует запрос, записывает идентификатор сообщения и передаёт его в очередь.
Такой вариант подходит и для небольшого интернет-магазина, если количество сообщений меняется в течение дня и нет задачи управлять несколькими SMPP-сессиями. Но даже при API не стоит отправлять SMS прямо из пользовательского HTTP-запроса. Если внешний сервис временно не отвечает, страница заказа зависнет или клиент увидит ошибку, хотя сам заказ уже создан.
Надёжнее разделить процесс на этапы: бизнес-система создаёт событие, очередь сохраняет задание, отдельный обработчик отправляет SMS, а журнал фиксирует ответ шлюза. Для каждой попытки сохраняйте время, номер сообщения, код ответа и причину повторной отправки. Это пригодится при разборе пропущенного уведомления.
Если проект уже работает через HTTP API, переход на SMPP не обязательно делать одномоментно. Практический план миграции с сохранением очереди и контроля отправки разобран в материале о миграции с HTTP API на SMPP без потери SMS.
Когда SMPP оправдан для бизнеса в Беларуси?
SMPP выбирают, когда SMS становятся постоянной частью внутренней системы: сайт создаёт поток уведомлений, CRM запускает сообщения по событиям, а несколько сервисов используют один шлюз. Постоянная сессия уменьшает число служебных HTTP-запросов и позволяет приложению работать с очередью сообщений напрямую через протокол.
До подключения нужно определить предполагаемый поток и ограничения. Под «объёмом» стоит понимать не только количество SMS за месяц, но и пиковую скорость: сколько сообщений приложение отправляет за секунду или минуту. Если утром одновременно формируются заказы, рассылка и напоминания, именно пик создаёт нагрузку на соединение.
У SMPP есть параметр window size, который ограничивает число неподтверждённых операций. При слишком большом окне приложение начнёт получать ошибки перегрузки или будет сложнее сопоставлять ответы с исходными сообщениями. При слишком маленьком окне канал будет простаивать. Значение подбирают тестом, учитывая лимит провайдера и скорость обработки ответов.
Для постоянного соединения нужен контроль состояния канала. Команда Enquire Link помогает проверить, что соединение доступно, а таймеры позволяют вовремя закрыть зависшую сессию и подключиться заново. Настройку этого механизма можно сверить с отдельным руководством об Enquire Link на SMPP-шлюзе.
Какие параметры проверить у SMPP-шлюза?
До разработки запросите техническое описание подключения. В нём должны быть указаны версия SMPP, адрес и порт, тип bind, логин, пароль, разрешённый source address, лимиты скорости и правила работы с DLR. Если провайдер сообщает только адрес и пароль, этого недостаточно для предсказуемой интеграции.
Отдельно уточните кодировку. В SMPP не используется UTF-8 как универсальная кодировка текста. Для кириллицы применяют DCS 0x08, для латинского текста часто используют DCS 0x03 в соответствии со спецификациями SMPP и 3GPP TS 23.038 (документация МТС для бизнеса). Неправильный DCS приводит к кракозябрам, ошибочной длине сообщения или неожиданному разбиению текста.
Протестируйте минимум четыре варианта: короткое сообщение на латинице, кириллический текст, сообщение на границе допустимой длины и длинный текст с несколькими сегментами. Проверяйте не только отображение на телефоне, но и значение esm_class, data_coding, registered_delivery и идентификатор сообщения в ответе submit_sm_resp.
DLR нужен для понимания дальнейшего состояния SMS. Ответ шлюза о принятии submit_sm означает, что сообщение принято на обработку, но не подтверждает доставку абоненту. Для анализа проверьте формат delivery receipt, соответствие message_id и итоговый статус. Мониторинг через DLR описан в материале о контроле сбоев доставки SMPP.
Как сравнить варианты до подключения?
Составьте короткую техническую таблицу по своему проекту. Запишите источник сообщений, пиковую скорость, нужный sender ID, языки текста, количество систем-отправителей, требования к DLR и допустимую задержку повторной попытки. Такой список помогает отличить реальную потребность в SMPP от желания выбрать более сложный протокол «на будущее».
Если SMS отправляет один сайт и очередь небольшая, начните с HTTP API, но сохраните в программе отдельный слой отправки. Тогда транспорт можно заменить без переписывания логики заказов. Если сообщений много, источников несколько, а статусы должны поступать в собственную систему, проектируйте SMPP-соединение сразу.
Уточните, как провайдер обрабатывает временные ошибки, повторные bind-запросы, дубликаты и недоступность маршрута. Попросите тестовые параметры и проверьте их в отдельном окружении. Рабочие логины лучше не использовать для первых экспериментов: ошибка в цикле отправки создаёт поток сообщений, который сложно остановить вручную.
Типичные ошибки при выборе и настройке
- Сравнивать SMPP и HTTP API только по числу методов, не учитывая очередь, пиковую скорость и DLR.
- Передавать кириллицу с неверным data_coding и проверять результат только на одном коротком сообщении.
- Считать ответ submit_sm_resp подтверждением доставки абоненту.
- Запускать постоянное SMPP-соединение без Enquire Link, тайм-аутов и повторного подключения.
- Не сохранять message_id, из-за чего невозможно связать DLR с исходной SMS.
- Отправлять длинный текст без теста сегментации и последующего объединения частей на телефоне.
3 шага, которые можно сделать на этой неделе:
- Опишите поток SMS: какие события создают сообщения, сколько их бывает в обычный и пиковый период, какие статусы нужны бизнесу.
- Проверьте у провайдера версию SMPP, DCS для кириллицы и латиницы, лимит скорости, формат DLR и правила восстановления соединения.
- Проведите тест в отдельном окружении: отправьте короткие и длинные сообщения, отключите соединение, восстановите его и сверьте каждый DLR с исходным message_id.
