Чому навантажувальне тестування через мобільні IP критично
Традиційні навантажувальні тести запускаються з дата‑центрів із швидким і стабільним каналом. Але більшість користувачів працюють через мобільні мережі, де затримки, втрати пакетів і NAT змінюють поведінку системи.
Типові показники:
- Дата‑центр: 5–20 мс latency
- 4G: 40–80 мс
- 3G: 100–300 мс
- Втрати пакетів: 1–5%
- CGNAT: сотні клієнтів за одним IP
Чому тести з дата‑центру спотворюють результат
- стабільний TCP
- відсутність CGNAT
- немає carrier‑level обмежень
- немає нестабільних RRC‑станів
- мінімальна затримка
Мобільний NAT і CGNAT
Оператори мобільного зв’язку об’єднують тисячі абонентів за одним IP. Це впливає на антифрод і rate limiting.
Архітектура запиту
- Клієнт
- Мобільна мережа
- NAT/CGNAT
- CDN
- WAF
- Балансувальник
- API
Практика k6 та JMeter
- підключення проксі
- обмеження RPS на IP
- облік ротації IP
- логування помилок
- retry‑логіка
Ідемпотентність
Повторні запити можуть створювати дублікати операцій. Використовуються idempotency key та серверна дедуплікація.
Кейс фінтех‑сервісу
Проблеми checkout API проявилися лише в мобільних мережах через високу затримку та обмеження на рівні CDN.
Коли мобільне тестування не потрібне
- B2B SaaS для десктопу
- внутрішні системи
- сервіси без мобільного трафіку
Що тестувати в staging
- таймаути
- повторні спроби
- rate limiting
- роботу кешів
- стійкість API