# Размер окна SMPP: почему скорость вашего соединения ниже той, за которую вы платите

> Оператор согласовывает 100 сообщений в секунду, соединение доставляет двенадцать, и все винят сеть. В девяти случаях из десяти причина кроется в окне, оставленном в настройках по умолчанию. Вот что на самом деле делает оконная обработка в сессии SMPP и как её настроить по размеру.

- Канонический URL: https://www.broadnet.me/ru/blog/smpp-window-size-throughput-tuning-2026
- Язык: ru
- Последнее обновление: 2026-10-20
- Издатель: BroadNet (https://www.broadnet.me)

- Опубликовано: 2026-09-10
- Автор: BroadNet Engineering

Постоянная закономерность: предприятие запрашивает 100 SMS в секунду, направляет свое приложение на точку привязки и измеряет двенадцать. Пропускная способность в порядке. SMSC в порядке. Никого не ограничили. Трафик просто ползет, и первое, что приходит в голову, — это всегда винить маршрут. Но почти никогда дело не в маршруте. Дело в окне.

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

## Что на самом деле представляет собой это окно

«Окно» — это количество PDU, которые вы могли отправить, но еще не получили подтверждения, в рамках одной операции привязки в любой момент времени. Отправьте submit_sm, и SMSC ответит submit_sm_resp — но SMPP никогда не требовал от вас ожидания этого ответа перед отправкой следующего сообщения. «Окно» — это то, насколько далеко вперед вам разрешено двигаться.

При окне в 1 сообщение отправляется, вы ждете, получаете, отправляете снова. Ваша пропускная способность теперь ограничена временем кругового пути, а не чем-либо, о чем вы договорились в коммерческом плане. При времени кругового пути в 40 мс это 25 сообщений в секунду — независимо от того, что указано в вашем контракте. При окне в 10 сообщений у вас одновременно обрабатывается десять сообщений, и по одному и тому же каналу передается примерно в десять раз больше трафика по одному и тому же соединению.

> Размер окна — это самый важный фактор, определяющий пропускную способность, которую вы получаете от привязки, и именно этот параметр чаще всего оставляют по умолчанию в библиотеке, что незаметно ограничивает интеграцию значительно ниже согласованной скорости.

## Почему так много библиотек по умолчанию используют один из вариантов?

Значение окна, равное 1, является безопасным значением по умолчанию для автора библиотеки. Оно не требует состояния корреляции, учета тайм-аутов и переупорядочивания: каждый запрос имеет ровно один ожидающий ответ, поэтому неопытный клиент может рассматривать SMPP как запрос/ответ и никогда не заметить разницы. Это работает, это легко понять, и это медленно. Многие клиентские библиотеки SMPP поставляются именно с таким значением, и оно никогда не пересматривается, потому что ничего не кажется сломанным — сообщения приходят, просто не быстро.

## Порядковые номера — это то, что делает возможным создание окна.

Каждый блок данных SMPP содержит в своем 16-октетном заголовке номер sequence_number. Когда одновременно обрабатывается несколько запросов, этот номер является единственным, что связывает каждый запрос submit_sm_resp с запросом submit_sm, который его вызвал. Не гарантируется, что ответы придут в порядке отправки запросов, поэтому клиент, работающий с окном размером больше 1, должен хранить карту незавершенных порядковых номеров и сопоставлять их по мере поступления.

Два правила имеют значение. Никогда не используйте повторно порядковый номер, пока он еще находится в процессе передачи — задержка ответа на повторно использованный номер будет приписана неправильному сообщению. И всегда устанавливайте тайм-аут для записей: если ответ так и не приходит, слот должен быть освобожден, иначе эффективное окно сократится до нуля за время сеанса, что приводит к раздражающему эффекту быстрого начала соединения и его ослабления в течение нескольких часов.

Вы можете наблюдать за этим пошагово в нашем [симулятор сеанса SMPP](https://www.broadnet.me/tools/smpp-simulator) — там отображается sequence_number в заголовке каждого PDU, а также то, какой ответ соответствует какому запросу.

## Размер окна и количество кадров в секунду (TPS) — это разные пределы.

Эти понятия постоянно путают. TPS — это ограничение скорости, устанавливаемое оператором: количество отправленных данных в секунду, измеренное за определенный промежуток времени. Окно SMPP — это ограничение параллельного доступа, которое вы настраиваете: количество PDU, находящихся в обработке в данный момент времени. Они взаимодействуют, но это не одно и то же число.

Зависимость примерно следующая: достижимое количество транзакций в секунду (TPS) ≈ окно ÷ время кругового пути. Окно размером 10 с временем кругового пути 50 мс дает около 200 TPS. Если оператор ограничивает вас 100 TPS, вы достигнете лимита и получите ESME_RTHROTTLED на избыточном трафике. Если оператор разрешает 500 TPS, а ваше окно равно 10, вы никогда не увидите 500 TPS, независимо от объема трафика, который вы предоставляете — вы ограничены параллелизмом, а не скоростью передачи данных.

| Окно | Поездка туда и обратно | Потолок | Симптом |
|---|---|---|---|
| 1 | 40 мс | ~25 Т/с | Договорная ставка так и не была достигнута; связь, похоже, неактивна. |
| 10 | 40 мс | ~250 тонн в секунду | Подходит для большинства корпоративных отправителей |
| 50 | 40 мс | ~1250 тонн в секунду | Только если оператор дал на это согласие; в противном случае ожидайте снижения скорости. |
| 10 | 250 мс | ~40 тонн в секунду | Ограничение по времени задержки — поднимите окно или подойдите ближе. |

## Правильное прочтение ESME_RTHROTTLED

ESME_RTHROTTLED (0x00000058) означает, что вы превысили согласованную скорость отправки. Это не отклонение сообщения и не ошибка маршрутизации. Правильный ответ — отступить и повторить попытку отправки сообщения; обработка сообщения как постоянного приводит к незаметному отбрасыванию трафика, который оператор принял бы чуть позже.

Это также сигнал о том, что ваше окно теперь слишком велико для поддерживаемой вами скорости. Если увеличение окна привело к ограничению пропускной способности, а не к её снижению, то ограничение переместилось с параллельного выполнения на контрактное, и следующий разговор будет касаться коммерческих, а не технических аспектов.

## enquire_link: другая причина связывания умирает

Соединение, которое ничего не отправляет, выглядит идентично соединению, TCP-соединение которого молча разорвалось — тайм-ауты NAT и брандмауэры с отслеживанием состояния разрывают неактивные сессии, не сообщая об этом ни одной из сторон. Сообщения enquire_link каждые 30–60 секунд подтверждают, что сокет по-прежнему пригоден для использования в обоих направлениях. Если вы пропустите ожидаемое оператором окно, сообщение SMSC приведет к разрыву соединения, обычно в самый неподходящий момент.

Отправьте enquire_link по тому же адресу, по которому вы отправляете запрос, оперативно ответьте на собственный enquire_link объекта SMSC и рассматривайте пропущенный ответ как незавершенную сессию: unbind, переподключитесь, возобновите соединение. Клиент, который продолжает отправлять запросы в полуоткрытый сокет, создает классическую ситуацию, когда все выглядит исправным, но ничего не доставляется.

## Как правильно подобрать размер окна на практике

1. Измерьте время передачи данных в обе стороны на том устройстве, которое вы фактически используете, а не на своем ноутбуке. Отправьте одно сообщение с окном размером 1 и временем от submit_sm до submit_sm_resp.
2. Разделите оговоренное количество сообщений в секунду (TPS) на количество сообщений в секунду, разрешенное для одного цикла передачи. Полученное частное — это ваш минимально допустимый временной интервал.
3. Добавьте запас по времени — округлите в большую сторону, затем добавьте примерно 50% — потому что время кругового пути не является постоянным, и окно, размер которого точно соответствует среднему значению, будет работать хуже на медианном уровне.
4. Повышайте уровень постепенно, а не одним резким скачком, и следите за появлением ESME_RTHROTTLED. Первое устойчивое снижение мощности покажет, где на самом деле находится предел возможностей оператора.
5. Уточните значение у оператора. Некоторые SMSC устанавливают максимальное окно для привязки и будут молча ставить в очередь или отбрасывать запросы, превышающие это ограничение.
6. Только после этого следует рассмотреть возможность второй привязки. Множественные привязки увеличивают параллелизм, но также увеличивают количество способов, которыми сессия может завершиться неудачей.

## Когда большее количество привязок превосходит большее окно возможностей

Существует предел тому, что может передавать одно TCP-соединение. При наличии нескольких сотен незавершенных PDU (блоков данных) сбои становятся неприятными: проблема с одним сокетом приводит к потере всего трафика, становится заметной блокировка в начале очереди, а восстановление после разрыва означает повторное воспроизведение большого набора передаваемых данных. Большинство операторов предпочтут несколько умеренных сбоев одному огромному, и большинство из них, если их спросят, скажут, какой формат они предпочитают.

Разделение по классам трафика, а не произвольное. Хранение критически важных по времени одноразовых паролей отдельно от массовой рассылки маркетинговых сообщений означает, что маркетинговая кампания не сможет задержать отправку кода авторизации — это решение, касающееся пропускной способности, которое на самом деле является решением, касающимся продукта.

## Контрольный список, прежде чем обвинять маршрут.

- Что представляет собой настроенное окно, и кто-нибудь настроил его намеренно?
- Истечет ли срок действия незаполненных порядковых номеров, после чего они будут освобождены?
- Выполняется ли операция enquire_link с интервалом, ожидаемым оператором?
- Повторная отправка ответов ESME_RTHROTTLED осуществляется с задержкой, или же они считаются неудачными?
- Соответствует ли измеренное время в обоих направлениях вашим предположениям при определении размера окна?
- Подтверждаются ли отчёты о доставке (deliver_sm) оперативно — поток неподтвержденных отчётов также может привести к зависанию сессии?

## Часто задаваемые вопросы

### Какой размер окна SMPP считается оптимальным?

Универсального значения не существует, поскольку правильное значение зависит от времени кругового пути и оговоренной ставки. Практической отправной точкой для корпоративного трафика является значение 10, затем его следует увеличивать до тех пор, пока вы либо не достигнете оговоренного количества транзакций в секунду (TPS), либо не начнете видеть ESME_RTHROTTLED. Размер значения, равный оговоренному TPS × времени кругового пути, плюс примерно 50% запаса, позволяет добиться большинства интеграций с первого раза.

### Увеличит ли больший размер окна мою пропускную способность без ограничений?

Нет. Как только размер окна станет достаточно большим, чтобы достичь лимита скорости, установленного оператором, дальнейшее увеличение приведет к появлению сообщений ESME_RTHROTTLED, а не к увеличению количества сообщений. Окно устраняет узкое место в параллельном выполнении; оно не может повысить коммерческий лимит.

### Почему пропускная способность снижается в течение нескольких часов, а не сразу?

Это классический симптом наличия незавершенных запросов с порядковыми номерами, которые никогда не истекают по таймауту. Каждый потерянный ответ навсегда занимает слот окна, поэтому эффективное окно уменьшается в течение сеанса, пока привязка не начнет вести себя так, как если бы окно было равно 1. Освобождение слотов по истечении таймаута решает эту проблему.

### Является ли ESME_RTHROTTLED окончательной неисправностью?

Нет, и если рассматривать это как потерю трафика, это означает, что вы превысили согласованную скорость в данный момент. Отступите, повторите попытку отправки того же сообщения, и если ограничение скорости сохраняется, уменьшите временной интервал или пересмотрите скорость.

### Как часто мне следует отправлять enquire_link?

Обычно интервал составляет от 30 до 60 секунд, и точное значение должно соответствовать ожиданиям оператора. Цель состоит в том, чтобы подтвердить, что потенциально неактивная TCP-сессия всё ещё активна в обоих направлениях, прежде чем NAT или брандмауэр незаметно её отбросят.

### Мне использовать одну большую перевязку или несколько меньших?

Как правило, несколько умеренных переключений лучше, чем одно очень большое, поскольку сбой сокета в этом случае обходится вам лишь в часть, а не во всю пропускную способность. Разделение трафика по классам — критически важные по времени пароли отдельно от массовых запросов — позволяет избежать задержки кода авторизации из-за маркетинговой кампании.

### Влияет ли этот временной промежуток также на получение отчётов о доставке?

Да, и в обратном направлении. SMSC отправляет вам подтверждения deliver_sm, и если ваше приложение медленно возвращает deliver_sm_resp, поток подтверждений затягивается. При привязке трансивера эта перегрузка может повлиять на всю сессию, поэтому подтверждайте подтверждения оперативно, даже если вы обрабатываете их асинхронно.

### Где я могу наблюдать такое поведение, не подключаясь к реальному SMSC?

Наш [симулятор сеанса SMPP](https://www.broadnet.me/tools/smpp-simulator) обрабатывает полную сессию SMPP 3.4 в браузере — привязка, отправка, асинхронное подтверждение доставки, enquire_link и unbind — и отображает поля каждого PDU, сопоставленные с фактическими октетами в сети. Ничего не устанавливается и ничего не отправляется.

## Краткая версия

Если соединение работает неэффективно, проверьте окно перед проверкой сети. SMPP по своей природе асинхронен, и большинство интеграций по ошибке запускают его синхронно. Задайте размер окна, исходя из измеренного времени кругового пути и согласованной скорости, засеките время выполнения порядковых номеров, обеспечьте корректную работу enquire_link и повторите попытку ESME_RTHROTTLED с задержкой. Эта последовательность решает подавляющее большинство проблем с пропускной способностью без вмешательства в маршрут.