--- title: "Как отправлять миллионы SMS в сутки: руководство" description: "Миллионы SMS в сутки: расчёт TPS, SMPP-бинды и окно, очереди и троттлинг, обработка DLR, Sender ID, тихие часы и KPI для мониторинга массовой SMS-рассылки." canonical: "https://omnichannels.ai/ru/blog/high-volume-sms-sending-guide/" language: "ru" updated: "2026-11-02" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "sms" primaryQuery: "массовая sms-рассылка большой объём" keywords: ["массовая SMS-рассылка", "отправка миллионов SMS", "пропускная способность SMS TPS", "размер окна SMPP", "SMPP бинды", "очереди и ограничение скорости SMS", "обработка DLR отчётов о доставке"] published: "2026-11-02" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 11 answer: "Чтобы отправлять миллионы SMS в сутки, рассчитывайте пропускную способность по пику, а не по среднесуточному значению: разделите число сегментов на секунды окна отправки, добавьте запас на OTP-трафик и задайте окно SMPP не меньше TPS, умноженного на время кругового обмена. Используйте несколько биндов, очереди по операторам и ограничитель скорости с паузами при троттлинге, обрабатывайте отчёты о доставке отдельно и разделяйте OTP и рекламный трафик." takeaways: ["Десять миллионов сообщений в сутки дают в среднем всего около 116 в секунду, но акция, сжатая в четырёхчасовое окно, требует около 694 в секунду, а каждый дополнительный сегмент умножает эту цифру.", "Спецификация SMPP позволяет отправителю отправлять много запросов, не дожидаясь ответов; число неподтверждённых запросов определяет реализация, поэтому окно нужно согласовать и настроить. Хорошее начальное правило: окно не меньше TPS, умноженного на время кругового обмена в секундах.", "Троттлинг (ESME_RTHROTTLED, 0x58) и переполнение очереди (ESME_RMSGQFUL, 0x14) — сигналы замедлиться и повторить с нарастающей паузой, а не отправлять сразу заново.", "Отчёты о доставке — второй поток большого объёма: планируйте для них потребителей, хранилище и сверку так же тщательно, как для отправки.", "Мощность согласуется на уровне аккаунта и маршрута с вашим провайдером; запросите пиковые значения в письменном виде и проверьте их до запуска."] faq: - q: "Сколько SMS в секунду нужно, чтобы отправить миллион сообщений?" a: "Разделите число сегментов на секунды в окне отправки. Миллион односегментных сообщений за час требует около 278 в секунду, за четыре часа — около 69, а если растянуть на целые сутки — около 12. Многосегментные сообщения на большинстве платформ считаются по сегментам, поэтому двухсегментное сообщение удваивает нужную скорость." - q: "Что такое размер окна SMPP и как его задать?" a: "Окно — это число запросов submit_sm, которые могут быть неподтверждёнными: отправленными, но без ответа. Спецификация SMPP допускает асинхронные запросы, но оставляет лимит на усмотрение реализации. Практическое правило: окно не меньше целевого TPS, умноженного на время кругового обмена в секундах; увеличивайте его только до лимита, согласованного с провайдером, потому что превышение вызывает троттлинг." - q: "Сколько SMPP-биндов нужно для большого объёма?" a: "Это зависит от пиковой скорости, лимита на бинд, согласованного с провайдером, и требований к резервированию. Разделите пиковый TPS на согласованную скорость на бинд, округлите вверх и добавьте минимум один запасной, чтобы обрыв соединения не остановил отправку. OTP-трафик держите на отдельных биндах или аккаунтах. Бинды выделяются на аккаунт." - q: "Что делать при получении ESME_RTHROTTLED?" a: "Замедлиться. Спецификация определяет ESME_RTHROTTLED (0x58) как превышение отправителем допустимых лимитов сообщений. Приостановите или сократите отправку, повторите отклонённые сообщения с экспоненциальной паузой и случайным разбросом (jitter) и никогда не повторяйте в плотном цикле: так троттлинг только затягивается. Если это происходит регулярно, ваше окно или скорость выше согласованного лимита." - q: "Как обрабатывать миллионы отчётов о доставке?" a: "Немедленно подтверждайте каждый deliver_sm ответом deliver_sm_resp, ставьте отчёт в очередь и обрабатывайте асинхронно, сохраняя в хранилище по идентификатору сообщения. Делайте обработку идемпотентной, потому что отчёты могут повторяться. Запускайте потребителей отчётов отдельно от пути отправки и следите за их отставанием." - q: "Можно ли отправлять рекламные SMS ночью?" a: "Во многих странах нельзя. ОАЭ запрещают рекламные тексты с 21:00 до 07:00, Саудовская Аравия — с 22:00 до 09:00, а в Рамадан с 01:00 до 12:00. Планируйте рекламу по местному времени каждого получателя, а OTP и уведомления отправляйте отдельно, так как они не рекламные." sources: - title: "SMPP Protocol Specification v3.4, SMPP Developers Forum" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)" url: "https://www.3gpp.org/dynareport?code=23040" - title: "TDRA spam policy, UAE" url: "https://tdra.gov.ae/-/media/About/regulations-and-ruling/EN/cellular-phone-spam-regulatory-policy-English.ashx" - title: "CST Regulations for Curbing SPAM Messages and Calls, Saudi Arabia" url: "https://www.cst.gov.sa/en/regulations-and-licenses/regulations/Document-522" --- # Как отправлять миллионы SMS в сутки: руководство Canonical: https://omnichannels.ai/ru/blog/high-volume-sms-sending-guide/ Language: ru Publisher: OmniChannels.ai by BroadNet Technologies Это руководство для инженеров, руководителей по операциям в сфере сообщений и закупщиков, которые отправляют или собираются отправлять от одного до десяти миллионов SMS в сутки. Здесь показано, как перевести суточный объём в целевую пропускную способность, как настроить SMPP-бинды и окна, как строить очереди и ограничивать скорость, как обрабатывать отчёты о доставке в масштабе и что подготовить по странам. Цифры в примерах — условные плановые значения, а не утверждения о мощности какого-либо провайдера. ## Сколько SMS в секунду нужно для миллионов в сутки? Нужно число сегментов, делённое на секунды в окне, в котором вы реально можете отправлять. Пропускная способность, измеряемая в TPS (сообщений или сегментов в секунду), — это пиковое значение, а не суточное среднее. См. [пропускная способность (TPS)](/ru/glossary/throughput-tps/). Сначала посчитайте среднее, затем пик для реального окна отправки: | Сообщений в сутки | Среднее в секунду за 24 ч | Если отправить за 4 часа | Если отправить за 2 часа | |---|---|---|---| | 1 000 000 | 11,6 | 69,4 | 138,9 | | 5 000 000 | 57,9 | 347,2 | 694,4 | | 10 000 000 | 115,7 | 694,4 | 1 388,9 | Таблицу меняют два множителя: - **Сегменты.** Сообщение длиннее одного сегмента отправляется несколькими частями, и большинство платформ считает каждую часть. 10 миллионов сообщений в среднем по 1,5 сегмента — это 15 миллионов отправок. Контролируйте это с помощью материалов про [лимиты символов SMS](/ru/blog/sms-character-limits-unicode-arabic/) и [счётчика символов](/ru/tools/sms-character-counter/). Для русского текста это особенно важно: кириллица — это Unicode, и в одном сегменте помещается 70 символов вместо 160. - **Запас.** Добавьте трафик, не входящий в кампанию, например OTP, и запас на повторы и медленных операторов. Тридцать процентов — распространённая плановая надбавка, а не правило. ## Как планировать пропускную способность по самому загруженному часу, а не по среднему? Планируйте по часу или окну с наибольшим трафиком, потому что именно тогда растут очереди и появляется троттлинг. Используйте формулу: **Нужный TPS = (сегменты кампании ÷ секунды окна + пиковый TPS OTP и уведомлений) × (1 + запас).** ### Пример: региональный ритейлер Условный ритейлер отправляет 6 миллионов рекламных сообщений в сутки клиентам в странах Персидского залива, в среднем по 1,4 сегмента. Он хочет закончить отправку за четыре часа внутри разрешённого дневного окна. - Сегменты: 6 000 000 × 1,4 = 8 400 000. - Окно: 4 часа = 14 400 секунд, то есть 8 400 000 ÷ 14 400 = 583 в секунду. - Пиковый трафик OTP и уведомлений во время кампании: 40 в секунду (собственное измерение). - Запас: 30 процентов. - Нужно: (583 + 40) × 1,3 ≈ 810 в секунду. Эту цифру ритейлер просит провайдера подтвердить по каждому маршруту в письменном виде до запуска. Это входное значение для планирования; оно ничего не говорит о том, что способна выдержать какая-либо платформа. ## Что такое SMPP-бинд и сколько их нужно? SMPP-бинд — это долгоживущая TCP-сессия между вашей системой и SMSC провайдера, аутентифицируемая учётными данными и разрешённым IP-адресом. SMPP (Short Message Peer-to-Peer) — телеком-протокол обмена SMS, рассчитанный на устойчивый объём. См. [SMPP-бинд](/ru/glossary/smpp-bind/) и [SMPP и REST API](/ru/blog/sms-api-vs-smpp/). Бывает три типа бинда: transmitter (только отправка), receiver (только отчёты и входящие) и transceiver (и то и другое в одной сессии). Большинство отправителей используют transceiver. Сколько биндов нужно: 1. Возьмите нужный пиковый TPS. 2. Разделите на скорость на бинд, которую провайдер согласует для вашего аккаунта. 3. Округлите вверх и добавьте минимум один запасной бинд, чтобы обрыв соединения не остановил отправку. 4. OTP-трафик разместите на отдельных биндах или аккаунте. Бинды выделяются на аккаунт, поэтому запросите количество, скорость на бинд и разрешённые исходные IP-адреса. Подключение описывают страница [SMPP-шлюза](/ru/channels/sms/smpp-gateway/) и [документация SMPP для разработчиков](/developers/smpp/). ## Как работает окно SMPP? Окно — это число запросов submit_sm, которые могут быть неподтверждёнными одновременно. SMPP асинхронен: по спецификации отправитель может отправлять несколько запросов, не дожидаясь ответов, а sequence_number в каждом PDU позволяет сопоставить ответ с запросом. Максимальное число неподтверждённых операций спецификация не определяет; его задаёт реализация с каждой стороны. Правило, следующее из арифметики очередей: **Окно ≥ целевой TPS × время кругового обмена (секунды).** | Целевой TPS | Круговой обмен 50 мс | Круговой обмен 150 мс | Круговой обмен 300 мс | |---|---|---|---| | 100 | 5 | 15 | 30 | | 400 | 20 | 60 | 120 | | 810 | 41 | 122 | 243 | Окно 1 означает, что отправитель ждёт каждый ответ, а это ограничивает пропускную способность единицей, делённой на время кругового обмена. Увеличение окна помогает, пока вы не достигнете скорости, разрешённой провайдером; сверх неё вы только вызываете троттлинг. Рассматривайте это число как значение, которое нужно согласовать с провайдером и проверить, а не максимизировать. При нескольких биндах делите TPS между ними: четыре бинда при общих 810 TPS несут примерно по 203. ## Как строить очереди и ограничивать скорость в масштабе? Поставьте между приложением и SMPP-соединением надёжную очередь и разбирайте её ограничителем скорости, который можно менять во время работы. Очередь поглощает всплески, ограничитель удерживает согласованную скорость. - **Token bucket на каждый бинд и маршрут.** Пополняйте с согласованной скоростью TPS; на каждый submit_sm берите токен, считая каждый сегмент. - **Одна очередь на приоритет.** Сначала OTP и уведомления, затем транзакционные, затем рекламные. - **Пауза при ошибках.** При ESME_RTHROTTLED (0x58) или ESME_RMSGQFUL (0x14) остановитесь, затем повторяйте с экспоненциальной паузой и jitter. Не отправляйте повторно в плотном цикле. - **Переподключайтесь с паузой** после разрыва и отслеживайте неподтверждённые порядковые номера, чтобы сверить, что было принято. - **Поддерживайте сессии.** Спецификация определяет таймер enquire_link для проверки, что у партнёра есть активная сессия, и таймер неактивности, после которого сессию могут разорвать. Отправляйте enquire_link в простое. - **Идемпотентная отправка.** Сохраняйте собственный идентификатор сообщения до отправки, чтобы повтор не привёл к двойной отправке. ## Как маршрутизировать по операторам в масштабе? Выстраивайте очереди и ограничивайте скорость не только по биндам, но и по оператору назначения, потому что медленный оператор не должен блокировать остальных. Операторы могут ограничивать A2P-трафик по отправителю или маршруту, поэтому реальный лимит для страны может быть ниже скорости аккаунта. 1. Определите оператора для каждого номера. Помогает проверка номеров; см. [HLR-запросы](/ru/blog/hlr-lookup-number-validation/). 2. Держите очередь и ограничитель на оператора или группу маршрутов. 3. Следите за долей доставки и задержкой отчётов по операторам и замедляйте тех, кто деградирует. 4. Спросите провайдера, используются ли прямые маршруты; см. [прямые и серые маршруты](/ru/blog/grey-route-vs-direct-route-sms/). ## Как обрабатывать отчёты о доставке в масштабе? Рассматривайте отчёты о доставке как второй поток, не уступающий первому. Отчёт приходит как deliver_sm на вашем бинде, и на каждый нужно ответить deliver_sm_resp. Спецификация определяет в отчёте такие конечные и промежуточные состояния: DELIVRD, EXPIRED, DELETED, UNDELIV, ACCEPTD, UNKNOWN и REJECTD. См. [отчёты о доставке](/ru/glossary/delivery-receipt/) и [статусы доставки сообщений](/ru/blog/message-delivery-status-explained/). Надёжная схема: 1. **Подтверждайте быстро.** Отвечайте deliver_sm_resp, как только отчёт попал в очередь. 2. **Обрабатывайте асинхронно** воркерами, которые сопоставляют отчёт с исходным сообщением по идентификатору. 3. **Делайте обработку идемпотентной.** Отчёты могут повторяться, а доставка не по порядку возможна. 4. **Учитывайте сегменты.** В зависимости от маршрута вы можете получать отчёт на каждую часть или на сообщение; проверьте это. 5. **Задайте тайм-аут** для сообщений, которые так и не получили конечный статус, и помечайте их неизвестными. 6. **Держите потребителей отчётов вне пути отправки,** чтобы отставание не замедляло отправку. ## Что нужно зарегистрировать по странам до отправки? Правила Sender ID различаются по странам, а в некоторых странах незарегистрированных отправителей блокируют или заменяют. Примеры: в ОАЭ и Саудовской Аравии нужна регистрация у операторов, Индия требует регистрации на DLT заголовка и каждого шаблона, а США вместо буквенных отправителей используют 10DLC или toll-free. Сроки составляют от нескольких рабочих дней до примерно месяца на рынках, которые мы отслеживаем. Начинайте регистрации в первую очередь: они на критическом пути запуска. Изучите [правила SMS-маркетинга по странам](/ru/blog/sms-marketing-rules-by-country/), [проверку Sender ID](/ru/tools/sender-id-checker/) и [руководство по Sender ID для ОАЭ и Саудовской Аравии](/ru/blog/sms-sender-id-registration-uae-saudi/). Мы вместе с вами готовим и подаём заявки на регистрацию через наш [сервис регистрации](/ru/services/registrations/); решения об одобрении остаются за регуляторами и операторами. ## Как соблюдать тихие часы при больших объёмах? Планируйте рекламу по местному времени каждого получателя и правилам страны, а нерекламный трафик в это ограничение не включайте. Некоторые рынки публикуют окна: ОАЭ запрещают рекламные тексты с 21:00 до 07:00, а Саудовская Аравия — с 22:00 до 09:00 и с 01:00 до 12:00 в Рамадан. См. [тихие часы](/ru/glossary/quiet-hours/). - Сгруппируйте список по странам и часовым поясам до постановки в очередь. - Выпускайте каждую группу в свою очередь, когда открывается её окно. - Останавливайте рекламные очереди в конце окна и переносите остаток на следующий день. - Спланируйте последовательность с помощью [планировщика времени отправки](/ru/tools/send-time-planner/). Узкое окно повышает нужный TPS, поэтому учитывайте его в формуле планирования. ## Зачем разделять OTP и рекламный трафик? OTP и уведомления критичны по времени, а рекламные кампании массовые; если они делят очередь или бинд, кампания может задержать код входа. Используйте отдельные бинды или аккаунты, отдельные Sender ID там, где этого требуют правила, отдельные очереди со строгим приоритетом и отдельный мониторинг. OTP не рекламные, поэтому тихие часы на них не распространяются. Защищайте и OTP-маршруты от злоупотреблений: см. [защита от SMS-пампинга](/ru/blog/sms-pumping-fraud-prevention/) и [руководство по OTP](/ru/blog/otp-authentication-messages-guide/). ## Какие KPI мониторить? Следите за состоянием отправки, возрастом очереди, итогами отчётов и задержкой отчётов с разбивкой по странам и операторам. Настройте оповещения по отклонению от вашей базовой линии. | KPI | Формула | О чём говорит | |---|---|---| | Доля успешной отправки | Принятые submit_sm_resp ÷ отправленные submit_sm | Состояние бинда и аккаунта | | Доля троттлинга | Ответы ESME_RTHROTTLED ÷ отправленные submit_sm | Слишком высокая скорость или окно | | Возраст очереди (p95) | Время от постановки в очередь до отправки | Нехватка мощности | | Доля доставленных | DELIVRD ÷ сообщения с конечным статусом | Качество маршрута и контента | | Доля неудачных и истёкших | (UNDELIV + EXPIRED + REJECTD) ÷ конечные статусы | Валидность номеров, Sender ID, фильтрация | | Задержка отчёта (медиана и p95) | Время отчёта − время отправки | Медлительность оператора | | Покрытие отчётами | Конечные статусы ÷ отправленные сообщения | Потерянные отчёты | | Доля отказов | Ответы STOP ÷ доставленные рекламные сообщения | Соответствие аудитории и контента | О диагностике читайте в материале [как повысить доставляемость SMS](/ru/blog/sms-not-delivered-improve-delivery-rate/). ## Каков чек-лист запуска многомиллионной отправки? 1. Нужный пиковый TPS рассчитан по сегментам, окну и нагрузке OTP. 2. Скорость на бинд, число биндов, окно и исходные IP письменно подтверждены провайдером. 3. Sender ID зарегистрированы для каждой страны, с шаблонами там, где это требуется. 4. Нагрузочный тест на доле объёма, затем наращивание шагами; не начинайте с максимума. 5. Очереди, ограничитель, паузы и идемпотентность проверены, включая принудительный разрыв соединения. 6. Конвейер отчётов проверен при полном объёме отчётов. 7. Планирование по тихим часам проверено по каждой стране. 8. OTP-трафик отделён и мониторится. 9. Дашборды и оповещения работают, дежурный назначен. 10. Есть кнопка остановки, мгновенно прекращающая рекламные очереди. ## Чем помогает OmniChannels.ai BroadNet доставляет SMS по прямым подключениям к операторам и поддерживает SMPP 3.4 по TLS с биндами на аккаунт, а также REST API, массовую отправку, двусторонние SMS, Unicode и арабский, HLR-запросы и отчёты о доставке. Мощность рассчитывается на аккаунт и маршрут: сообщите нам направления, пиковый объём, окна отправки и Sender ID, и мы согласуем с вами пропускную способность, бинды и регистрации. Наша команда готовит регистрации Sender ID. [Свяжитесь с отделом продаж](/ru/contact/) и приложите план по объёмам или изучите [оптовую программу](/ru/partners/wholesale/).