Защита оператора считает не запросы, а попытки ОТКРЫТЬ соединение. Прежний код
собирал HTTP-клиент заново на каждое сообщение: рассылка на тысячу номеров
открывала тысячу соединений подряд и выглядела для их защиты как атака, после
чего адрес уходил в чёрный список на часы. Замеры 05-07.08.2026, заявка
RUMAAS-73856: из шести одинаковых запросов проходили один-два, остальные
молча дропались, пауза пять минут доступ не возвращала.
Что сделано:
- общий обработчик curl на объект — шесть запросов идут по ОДНОМУ соединению
вместо шести. Замерено вживую на безобидном узле: начиная со второго запроса
установка соединения и согласование шифрования равны нулю, время запроса
втрое меньше — 0,13 с против 0,41 с;
- предохранитель SmsConnectionBreaker: пять обрывов подряд — и канал молчит
десять минут, в сеть не выходя вовсе. Это лечит главное: раньше каждая
неудачная попытка сыпала семь безответных стуков и сама продлевала
блокировку. Считаются ТОЛЬКО обрывы связи; прикладной отказ вроде
отсутствия имени отправителя предохранитель не трогает — сеть-то жива;
- ожидание соединения 3 с вместо прежних десяти, чтобы не копить оборванные
попытки, и своё имя клиента LiderraSms/1.0 вместо безымянного робота.
Подменяется обработчик, а НЕ клиент целиком: подмена клиента отключила бы
подделку сети в тестах, и они пошли бы в настоящий интернет. Записано
комментарием в коде.
Поведение отправки не меняется. Мост SMS_MTS_CONNECT_TO не тронут, заявка
RUMAAS-73856 остаётся открытой.
Проверено: 500 тестов канала зелёные, статанализ ноль замечаний, оформление
чистое. Новый сторож перед починкой был красным.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Дмитрий
fb40aaf7c0