--- title: "SMS API или SMPP: какой способ подключения выбрать?" description: "Сравнение SMS API и SMPP: сессии и bind, windowing, пропускная способность, отчёты о доставке, кодировка, TLS, сложность эксплуатации и миграция." canonical: "https://omnichannels.ai/ru/blog/sms-api-vs-smpp/" language: "ru" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "integration" primaryQuery: "sms api vs smpp" keywords: ["SMS API или SMPP", "SMPP или HTTP API", "REST API для SMS", "SMPP bind transceiver", "SMPP windowing", "SMPP deliver_sm отчёт о доставке", "SMPP через TLS", "переход с HTTP API на SMPP"] published: "2026-10-10" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 12 answer: "Используйте REST SMS API для трафика приложений: OTP-кодов, уведомлений и оповещений, а также когда вам нужны WhatsApp, RCS или другие каналы. Это HTTPS без сохранения состояния, его легко защитить и быстро подключить. Используйте SMPP, если вы отправляете большие и стабильные объёмы SMS, уже работаете с SMPP-клиентами или перепродаёте SMS: постоянная bind-сессия с windowing держит в обработке много сообщений одновременно. Многие компании используют оба варианта в одном аккаунте." takeaways: ["REST SMS API отправляет каждое сообщение отдельным независимым HTTPS-запросом, а SMPP держит долгоживущую сессию, называемую bind, и обменивается по ней бинарными PDU.", "Пропускная способность SMPP зависит от windowing: клиент, который ждёт submit_sm_resp перед отправкой каждого следующего сообщения, впустую тратит большую часть соединения.", "Статусы доставки в REST приходят на ваш вебхук, а отчёты о доставке в SMPP приходят как PDU deliver_sm в той же сессии, и каждый из них нужно подтверждать.", "В SMPP v3.4 нет встроенного шифрования, поэтому рабочие bind-сессии нужно запускать поверх TLS и только с IP-адресов из белого списка.", "SMPP передаёт только SMS, поэтому гибридная схема, где REST обслуживает мультиканальный трафик, а SMPP — массовые SMS, часто остаётся рабочим решением на долгий срок."] faq: - q: "SMPP быстрее, чем SMS API?" a: "SMPP может обеспечить более высокую пропускную способность: одна постоянная сессия передаёт много сообщений одновременно, и для каждого не нужен новый HTTP-запрос. Для одного OTP-кода разница вряд ли заметна, потому что основное время занимает доставка оператором. Пропускная способность обоих интерфейсов определяется лимитами вашего аккаунта, поэтому уточняйте у провайдера документированные лимиты и не считайте, что SMPP всегда быстрее." - q: "Можно ли отправлять сообщения WhatsApp по SMPP?" a: "Нет. SMPP — протокол для SMS и связанных служб коротких сообщений. WhatsApp, RCS, Messenger, Instagram, email и push работают через HTTP API. Если вам нужно несколько каналов, используйте для них REST API, а SMPP добавляйте только для SMS больших объёмов, если он вам нужен." - q: "Что такое SMPP bind?" a: "Bind — это аутентифицированная SMPP-сессия между вашим клиентом (ESME) и SMSC провайдера. Вы открываете TCP- или TLS-соединение и отправляете bind_transmitter, bind_receiver или bind_transceiver со своими system_id и паролем. Bind типа transceiver и отправляет сообщения, и принимает отчёты о доставке в одной сессии — это обычный выбор." - q: "SMPP безопасен?" a: "Сам SMPP v3.4 не шифрует трафик, а учётные данные передаются в запросе bind. Запускайте рабочие bind-сессии поверх TLS, ограничьте подключения зарегистрированными IP-адресами, храните system_id и пароль как секреты и меняйте их при утечке. Обычного SMPP через публичный интернет следует избегать." - q: "Чем отчёты о доставке в SMPP отличаются от REST?" a: "В SMPP отчёт приходит как PDU deliver_sm с текстом вида stat:DELIVRD, и ваш клиент должен ответить deliver_sm_resp. В REST провайдер отправляет на ваш вебхук JSON-событие с нормализованным статусом, например DELIVERED или FAILED. Оба способа асинхронные: принятая к отправке заявка никогда не доказывает доставку." - q: "Сколько времени занимает переход с SMS API на SMPP?" a: "Если использовать зрелую SMPP-библиотеку, код — не самая долгая часть. Дольше идёт подключение: согласование пропускной способности и числа bind-сессий, регистрация исходных IP-адресов, тестирование отчётов и кодировки. Заложите период параллельной работы, когда на SMPP идёт небольшая доля трафика, прежде чем переносить весь объём." sources: - title: "Short Message Peer to Peer Protocol Specification v3.4 (SMPP.org)" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" - title: "SMPP.org: Short Message Peer-to-Peer protocol resources" url: "https://smpp.org/" - title: "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3" url: "https://www.rfc-editor.org/rfc/rfc8446" - title: "RFC 9110: HTTP Semantics" url: "https://www.rfc-editor.org/rfc/rfc9110" - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)" url: "https://www.3gpp.org/dynareport?code=23040" --- # SMS API или SMPP: какой способ подключения выбрать? Canonical: https://omnichannels.ai/ru/blog/sms-api-vs-smpp/ Language: ru Publisher: OmniChannels.ai by BroadNet Technologies Это руководство для инженеров и технических руководителей, которые решают, как подключиться к SMS-провайдеру: через HTTP/REST SMS API, через SMPP или обоими способами. Здесь объясняется, чем эти два подхода отличаются на уровне протокола и в эксплуатации, чтобы вы могли выбрать подходящий интерфейс для каждого вида трафика и спланировать миграцию, если первый выбор перестанет вас устраивать. Более широкий обзор схем интеграции, включая вебхуки и идемпотентность, смотрите в нашем [руководстве по интеграции API для отправки сообщений](/ru/blog/messaging-api-integration-guide/). ## Чем SMS API отличается от SMPP? REST SMS API отправляет каждое сообщение отдельным HTTPS-запросом и возвращает ID сообщения. SMPP (Short Message Peer-to-Peer) держит одну долгоживущую аутентифицированную сессию и обменивается по ней бинарными сообщениями, которые называются PDU, в обоих направлениях. REST оптимизирован для простоты, SMPP — для стабильных больших объёмов SMS. | | REST SMS API | SMPP v3.4 | |---|---|---| | Транспорт | HTTPS-запрос и ответ | Постоянная TCP-сессия, в рабочей среде внутри TLS | | Состояние | Без сохранения состояния; каждый запрос самостоятелен | bind с сохранением состояния, порядковыми номерами и keep-alive | | Аутентификация | Bearer-токен в заголовке | `system_id` и пароль в bind плюс белый список IP-адресов | | Каналы | SMS и, с мультиканальным API, WhatsApp, RCS и другие | Только SMS | | Модель пропускной способности | Запросы в секунду плюс эндпоинты для массовой отправки | Сообщения в секунду на один bind, много сообщений одновременно благодаря windowing | | Отчёты о доставке | JSON-вебхук с нормализованными статусами | PDU `deliver_sm` в сессии, текстовый формат отчёта | | Кодировка | Поле вроде `messageType` (`TEXT` или `UNICODE`) | `data_coding` (0 для GSM-7, 8 для UCS-2), UDH для длинных сообщений | | Инструменты | Любой HTTP-клиент, SDK, OpenAPI | Клиентская библиотека SMPP | | Эксплуатационные затраты | Низкие | Умеренные: соединения, переподключение, окна, отчёты | | Лучше всего подходит для | Приложений, OTP, уведомлений, мультиканального трафика | Агрегаторов, реселлеров, отправителей с большими объёмами и опытом работы с SMPP | ## Как работает REST SMS API? Вы отправляете HTTPS-запрос `POST` с токеном и телом в формате JSON, а провайдер отвечает ID сообщения. Каждый запрос независим, поэтому отправлять можно с любого сервера, из функции или контейнера, не управляя соединением. Типичная отправка через наш API выглядит так: ```bash curl -X POST https://api.broadnet.me/sms/sendSms \ -H "Authorization: Bearer $BROADNET_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "senderId": "OmniDemo", "destinationNumber": "971500000000", "message": "Your OmniDemo code is 482913", "messageType": "TEXT" }' ``` В ответ приходит `200 OK` с ID сообщения в виде обычного текста. Итоговый статус позже приходит на ваш вебхук как SUBMITTED, SENT, DELIVERED, FAILED или REJECTED. Названия полей и параметры описаны в [справочнике по SMS API](/ru/developers/sms/). Сильные стороны REST: - **Привычные инструменты**: любой язык, любой HTTP-клиент, стандартные коды состояния по RFC 9110. - **Простая защита**: TLS везде и токен в заголовке `Authorization`. - **Массовая отправка без соединений**: загрузите файл с получателями одним запросом, не открывая сессию. - **Один API для многих каналов**: по той же схеме отправляются шаблоны WhatsApp и карточки RCS. Ограничения REST: каждое сообщение или пакет требует HTTP-обращения, а лимит запросов в секунду вы встретите раньше любого лимита оператора. Для большинства трафика приложений это не имеет значения. ## Как работает SMPP? SMPP — бинарный протокол, описанный в спецификации SMPP v3.4. Её опубликовал SMPP Developers Forum (позже SMS Forum), и эта версия по-прежнему наиболее распространена. Ваша система, называемая ESME (External Short Message Entity), подключается к SMSC (Short Message Service Centre, центру коротких сообщений) провайдера и открывает сессию, которая называется bind. ### Типы bind - **Transmitter (TX)** через `bind_transmitter`: только отправка сообщений. - **Receiver (RX)** через `bind_receiver`: только приём отчётов о доставке и входящих сообщений. - **Transceiver (TRX)** через `bind_transceiver`: и то и другое в одной сессии. Это обычный выбор. ### Жизненный цикл сессии 1. Откройте TLS-соединение с хостом и портом, которые указал провайдер. 2. Отправьте `bind_transceiver` со своими `system_id` и паролем и дождитесь ответа с `command_status` 0. 3. Отправляйте сообщения через `submit_sm`. Каждый `submit_sm_resp` возвращает `message_id`. 4. Принимайте отчёты о доставке (DLR) как `deliver_sm` и отвечайте на каждый через `deliver_sm_resp`. 5. В простое периодически отправляйте `enquire_link`, чтобы обе стороны знали, что сессия жива. 6. Закройте сессию через `unbind` и дождитесь `unbind_resp`. Каждый PDU несёт порядковый номер, а ответы возвращают тот же номер: так вы сопоставляете `submit_sm_resp` с отправленным сообщением. Каждый шаг с нашими настройками описан в [документации по SMPP](/ru/developers/smpp/). ## Что такое windowing в SMPP и почему это важно? Windowing означает, что вы отправляете несколько PDU `submit_sm`, не дожидаясь ответов. Количество PDU без подтверждения, которое разрешено держать в обработке, и есть окно. Именно поэтому SMPP выдерживает более высокую пропускную способность, чем HTTP с одним запросом за раз. При окне, равном 1, клиент отправляет одно сообщение, ждёт полный цикл ответа, затем отправляет следующее. Пропускная способность ограничена задержкой сети, а не согласованной скоростью. При большем окне соединение остаётся занятым, пока приходят ответы. Практические правила: - **Используйте размер окна, согласованный с провайдером**, и не превышайте его: лишние PDU могут быть отклонены. - **Соблюдайте согласованную скорость на один bind.** Если вы получили `ESME_RTHROTTLED`, снизьте темп и повторите попытку с нарастающей паузой (backoff). - **Отслеживайте неподтверждённые порядковые номера**, чтобы после разрыва соединения не потерять информацию о том, какие сообщения приняты. - **Масштабируйтесь числом bind-сессий** в пределах согласованного для вашего аккаунта количества, а не всё большим окном. Лимиты по умолчанию для нашего REST API и SMPP-сессий перечислены в разделе [ошибки и лимиты](/ru/developers/errors-and-limits/); лимиты вашего аккаунта подтверждаются при подключении доступа. ## Чем отличаются отчёты о доставке? В REST провайдер отправляет JSON-событие на ваш [вебхук](/ru/developers/webhooks/). В SMPP отчёт приходит как PDU `deliver_sm` в сессии, с установленным битом отчёта в `esm_class`. Оба способа асинхронные: ни `200 OK`, ни `submit_sm_resp` не означают, что сообщение получено на устройстве. Спецификация SMPP v3.4 приводит формат текста отчёта как пример, а точный формат оставляет на усмотрение поставщика SMSC, но большинство провайдеров ему следуют: ```text id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code ``` Если ваши системы работают с обоими интерфейсами, приведите состояния SMPP к одной модели статусов. Типичное соответствие: | SMPP `stat` | Значение | Нормализованный статус | |---|---|---| | `ACCEPTD` | Принято, промежуточный статус | SENT | | `DELIVRD` | Доставлено на устройство | DELIVERED | | `UNDELIV` | Недоставляемо | FAILED | | `EXPIRED` | Истёк срок действия | FAILED | | `REJECTD` | Отклонено, например из-за заблокированного отправителя | REJECTED | | `DELETED` | Удалено до доставки | FAILED | | `UNKNOWN` | Нет информации о состоянии | Оставить последний известный статус | Две практические разницы важнее формата: - **Подтверждение.** SMPP-клиент должен отвечать на каждый `deliver_sm`. Неподтверждённые отчёты отправляются повторно и могут замедлять bind. Обработчик вебхука по той же причине должен быстро отвечать кодом `2xx`. - **Восстановление.** Если SMPP-клиент отключён, отчёты ждут следующего bind или могут истечь в очереди провайдера. В REST провайдер может предлагать повторную отправку отчётов за период. Уточните, как это работает в каждом случае. Подробнее о значении каждого статуса читайте в материале [статусы доставки сообщений: что они означают](/ru/blog/message-delivery-status-explained/). ## Как обрабатывается кодировка? В обоих интерфейсах нужно выбирать между GSM-7 и Unicode, и оба делят длинные сообщения на части. Различие в том, кто выполняет эту работу. - **REST:** вы задаёте в поле вроде `messageType` значение `TEXT` или `UNICODE`, а платформа сама делит длинные сообщения на части. В нашем API есть также `POST /sms/identify`, чтобы заранее посчитать символы и сегменты. - **SMPP:** вы задаёте `data_coding` (0 для алфавита GSM-7 по умолчанию, 8 для UCS-2) и сами кодируете байты. Для длинных сообщений нужно либо добавить User Data Header к каждой части и установить `esm_class` в 0x40, либо передать весь текст в поле `message_payload`, если ваш провайдер это включил. По 3GPP TS 23.040 одно SMS содержит 140 октетов: 160 символов GSM-7 или 70 символов UCS-2, а при добавлении заголовка — 153 или 67 на часть. Одна арабская буква или эмодзи превращает всё сообщение в Unicode. Ошибки кодировки — самый частый дефект SMPP-интеграции, поэтому тестируйте с арабским текстом, эмодзи и длинными сообщениями. См. наше [руководство по ограничениям на длину SMS](/ru/blog/sms-character-limits-unicode-arabic/). ## Как сравниваются модели безопасности? REST опирается на TLS и bearer-токен в каждом запросе. В SMPP v3.4 нет собственного шифрования, а учётные данные передаются в bind, поэтому защита зависит от транспорта и сетевых средств контроля вокруг него. Для SMPP: - **Используйте TLS** (TLS 1.3 описан в RFC 8446) или частный канал; никогда не используйте обычный SMPP через публичный интернет. - **Зарегистрируйте исходные IP-адреса**, чтобы подключаться к bind могли только ваши серверы. - **Храните `system_id` и пароль как секреты**, отдельно для каждой среды, и меняйте их при утечке. - **Отслеживайте неудачные bind**: они могут говорить об ошибке в настройках или о неправомерном использовании учётных данных. Для REST: - **Храните токен только на серверах**, никогда в мобильных приложениях или коде браузера. - **Избегайте устаревших HTTP-интерфейсов**, которые передают имя пользователя и пароль в URL: там они попадают в логи. - **Защищайте вебхук** с помощью HTTPS, непредсказуемого пути и строгой проверки тела запроса. ## Во что обходится эксплуатация каждого варианта? REST почти не добавляет эксплуатационной нагрузки: запросы либо проходят, либо возвращают ошибку, после которой их можно повторить. SMPP добавляет долго работающий компонент, который нужно мониторить и поддерживать. SMPP-клиенту необходимо: 1. управление соединением с переподключением по схеме backoff с jitter, а не в жёстком цикле; 2. keep-alive и обнаружение «тихих» полуоткрытых соединений; 3. контроль окна и скорости для каждого bind; 4. отслеживание порядковых номеров и сверка после разрывов; 5. подтверждение и хранение отчётов; 6. логика кодировки и склейки длинных сообщений; 7. мониторинг состояния bind, пропускной способности, ошибок ограничения скорости и задержки отчётов. Зрелые библиотеки с открытым кодом берут на себя протокол, но ваша команда всё равно отвечает за поведение вокруг них, в том числе в ночное окно технических работ у провайдера в 3 часа ночи. ## Когда что использовать? Используйте REST, если у вас нет явной причины добавлять SMPP. ### Выбирайте REST SMS API, когда - вы отправляете OTP, оповещения, уведомления или рассылки из приложений; - вам нужны WhatsApp, RCS или другие каналы наряду с SMS; - ваша платформа работает на бессерверных функциях или недолгоживущих контейнерах; - у вашей команды нет опыта работы с SMPP и нет необходимости его осваивать. ### Выбирайте SMPP, когда - вы отправляете большие и стабильные объёмы SMS и упёрлись в лимиты REST; - вы уже используете SMPP-шлюз или платформу для обмена сообщениями; - вы агрегатор, оператор или реселлер и подключаете SMS-трафик собственных клиентов; - вам нужен один и тот же протокол для нескольких вышестоящих провайдеров. ## Как выглядит гибридная схема? Многие компании используют оба интерфейса в одном аккаунте: REST для мультиканального трафика и трафика приложений, SMPP для массовых SMS. Главная ловушка — получить две разные модели доставки. - **Распределяйте трафик по сценариям**, а не случайно: например, OTP и WhatsApp через REST, массовые SMS с выписками через SMPP. - **Нормализуйте статусы** из вебхуков и `deliver_sm` в одну таблицу с ключом по ID сообщения. - **Применяйте единые правила для имён отправителей (Sender ID)** в обоих интерфейсах, поскольку регистрация действует независимо от того, каким интерфейсом вы пользуетесь. - **Ведите общую отчётность**, чтобы кампания, разделённая между двумя интерфейсами, показывала один результат. ## Как перейти с SMS API на SMPP? Переходите постепенно, оставив работающими оба интерфейса, и измеряйте результат, прежде чем переносить объём. 1. **Подтвердите необходимость**: задокументируйте объём или пропускную способность, которых REST не обеспечивает. 2. **Запросите подключение**: сообщите страны назначения, имена отправителей, ожидаемую пиковую пропускную способность и исходные IP-адреса. 3. **Выберите зрелую клиентскую библиотеку** для вашего стека и оберните её собственным интерфейсом отправки. 4. **Сначала реализуйте обработку отчётов** и приведите их к той же модели статусов, что и у вебхуков. 5. **Проверьте кодировку**: GSM-7, арабский текст, эмодзи и многосегментные сообщения на реальных устройствах. 6. **Проверьте сбои**: оборвите соединение посреди отправки, спровоцируйте ограничение скорости и проверьте сверку. 7. **Запустите параллельно**: перенесите на SMPP небольшую долю одного вида трафика и сравните доставку и отчёты. 8. **Переносите объём поэтапно**, сохраняя REST как резервный путь. Ниже пример конфигурации bind. Хост, порт и лимиты — условные значения; реальные значения вы получите вместе с выданными учётными данными. ```text host: port: bind type: transceiver system_id: password: system_type: (empty unless told otherwise) interface_version: 0x34 source_addr_ton/npi: 5 / 0 (alphanumeric sender ID) dest_addr_ton/npi: 1 / 1 (international number) registered_delivery: 1 (request delivery receipts) data_coding: 0 (GSM-7) or 8 (UCS-2) enquire_link: every 30 seconds while idle window: as agreed for your account ``` ## Пример из практики: региональный ритейлер добавляет SMPP для выписок «Souq Rafiq» (условный пример) — интернет-магазин в ОАЭ, Египте и Иордании. Он отправляет OTP и уведомления о заказах через REST API, а шаблоны WhatsApp — через тот же API. Ежемесячные выписки по счёту, которые уходят по SMS всей клиентской базе, выросли настолько, что REST-задача занимает больше времени, чем устраивает бизнес. - **Решение:** OTP, уведомления о заказах и WhatsApp остаются на REST. Ежемесячные SMS с выписками переносятся на SMPP-bind типа transceiver. - **Подключение:** команда регистрирует два исходных IP-адреса, подтверждает имена отправителей по странам и согласовывает пропускную способность и число bind-сессий. - **Разработка:** небольшой SMPP-сервис использует библиотеку с открытым кодом, записывает отчёты в ту же таблицу статусов, что и вебхук, и предоставляет тот же внутренний интерфейс отправки, что и REST-путь. - **Тестирование:** выписки на арабском подтверждены как UCS-2 с корректной склейкой на нескольких устройствах. - **Запуск:** первой переходит одна страна. После сравнения доставки и времени получения отчётов с базовыми показателями REST остальные страны следуют за ней, а REST остаётся резервным путём. ## Частые ошибки - **Выбор SMPP ради престижа.** Если REST справляется с вашим объёмом, SMPP лишь добавляет работы. - **Окно, равное 1**, и последующие претензии к провайдеру из-за низкой пропускной способности. - **Отсутствие подтверждения `deliver_sm`**, из-за чего отчёты отправляются повторно и включается ограничение скорости. - **Переподключение в жёстком цикле** после разрыва, что может выглядеть как атака. - **Смешивание `short_message` и `message_payload`** в одном PDU, что приводит к ошибкам длины. - **Обычный SMPP через интернет**, из-за чего раскрываются учётные данные и содержимое сообщений. - **Две модели статусов** в гибридной схеме, из-за чего отчёты расходятся. - **Ограничения:** в этом руководстве описана распространённая практика. Размеры окон, скорость, TLS-порты и детали отчётов зависят от провайдера и аккаунта; подтверждайте их при подключении. ## Как помогает OmniChannels.ai OmniChannels.ai предлагает оба варианта. REST API по адресу `https://api.broadnet.me` использует Bearer-токен и охватывает SMS наряду с WhatsApp, RCS, Messenger, Instagram, Telegram, Email и Push, а статусы доставки приходят на ваш вебхук в едином формате. Для SMS больших объёмов SMPP 3.4 bind-сессии по TLS подключаются на уровне аккаунта, с исходными IP-адресами из белого списка, и используют те же SMS-маршруты через прямое подключение BroadNet к операторам. Реселлеры и оптовые партнёры могут получить выделенные bind-сессии. Начните с [документации по SMPP](/ru/developers/smpp/) или [быстрого старта](/ru/developers/quickstart/), либо откройте [обзор для разработчиков](/ru/developers/).