Почему нагрузочное тестирование через мобильные IP критично
Классическое нагрузочное тестирование выполняется из дата-центров с быстрыми и стабильными каналами. Однако реальные пользователи подключаются через мобильные сети, где задержки, потери пакетов и NAT существенно влияют на поведение приложений.
Типичные сетевые показатели:
- Дата-центр: 5–20 мс latency
- 4G: 40–80 мс
- 3G: 100–300 мс
- Потери пакетов в мобильных сетях: 1–5%
- CGNAT: сотни и тысячи клиентов за одним IP
Почему тесты из дата-центра «лгут»
Нагрузка из дата-центра не отражает реальную картину, потому что:
- стабильный TCP без обрывов
- нет CGNAT
- нет carrier‑level rate limiting
- нет переходов RRC‑состояний в 4G/5G
- минимальная задержка
Мобильный NAT и CGNAT
Мобильные операторы используют CGNAT, объединяя тысячи абонентов за одним публичным IP. Это влияет на безопасность и доступность:
- антифрод может блокировать легальных пользователей
- rate limiting применяется к группе клиентов
- сложно различать реальные сессии
Архитектура пути запроса
Типичный путь запроса:
- Клиент
- Мобильная сеть
- NAT/CGNAT
- CDN
- WAF
- Балансировщик
- API
Практика использования k6 и JMeter
При работе через мобильные прокси необходимо:
- настраивать прокси в инструменте
- ограничивать RPS на один IP
- учитывать ротацию IP
- логировать TCP reset и таймауты
- настраивать retry‑логику
Идемпотентность и повторные запросы
В мобильных сетях пользователи часто повторяют действия из‑за задержек. Без идемпотентности возможны дубли платежей. Решение — idempotency key и серверная дедупликация.
Кейс финтех‑проекта
Финансовый сервис обнаружил таймауты checkout API только при тестировании через мобильные сети. Причиной оказалась комбинация высокой задержки и строгого rate limiting на уровне CDN.
Когда мобильное тестирование не требуется
- B2B‑системы с десктоп‑аудиторией
- внутренние админ‑панели
- сервисы без мобильного трафика
Что тестировать в staging
- таймауты
- retry‑поведение
- rate limiting
- работу CDN и edge‑кэша
- устойчивость API