IPv4 та IPv6 в IP API

IPv4 та IPv6 в IP API. Практична стаття для діагностики мережі та правильного тлумачення результату. Один технічний сигнал не описує весь ланцюжок, тому рівні з’єднання варто перевіряти послідовно.

Як має поводитися API-клієнт

IPv4 та IPv6 в IP API стосується контракту між client і API. Клієнт має розрізняти success, validation error, authentication failure, rate limit і temporary server error. JSON чи XML не змінює HTTP semantics, а IPv4/IPv6 слід зберігати повністю без припущення про довжину IPv4.

Помилки, limits і повтори

Перевіряйте Content-Type, status code, documented fields і quota. HTTP 429 обробляйте окремо, поважайте Retry-After, використовуйте bounded exponential backoff та jitter. Для retry враховуйте idempotency. Логуйте request ID, status і latency, але не API secrets.

Контрольний сценарій

Контрольний сценарій: протестуйте success response, invalid input, authentication failure, rate limit і temporary server error окремо. Переконайтеся, що client не повторює безкінечно non-idempotent request і правильно читає Retry-After. Для IP fields додайте fixtures з IPv4 та повною IPv6-адресою, щоб serialization, validation і database schema не обрізали значення.

Конкретні приклади та значення

Використовуйте ці значення як орієнтири під час читання документації та результатів перевірки: IPv4 literal; IPv6 literal; dual stack; normalization; CIDR/prefix; do not truncate IPv6.

Do not store an IP API field in a schema sized only for dotted IPv4. Preserve canonical IPv6 text or a suitable binary representation, accept compressed forms on input, and test loopback, mapped or dual-stack cases according to the API contract.

Типові причини та помилки

Поширена помилка — вважати один успішний тест доказом справності всього ланцюжка. Доступна IP-адреса не гарантує роботу DNS, відкритий порт не підтверджує правильний протокол застосунку, а високий результат speedtest не виключає затримку, втрати чи перевантаження Wi-Fi. NAT, CGNAT, firewall, CDN, Anycast і кеші також змінюють картину та мають враховуватися залежно від завдання.

Чого результат не доводить

Технічний результат має межі. Він зазвичай не встановлює особу користувача, власника пристрою або єдину причину збою без додаткових даних. Геолокація IP приблизна, реєстраційні дані можуть бути приховані, а маршрути змінюються. Безпеку також не можна зводити до одного прапорця, адреси чи статусу. Висновок має відповідати саме тій властивості, яку було виміряно.

Покрокова діагностика

Почніть із відтворюваного симптому, потім перевірте локальну конфігурацію, адресацію та DNS. Після цього переходьте до маршруту, портів і прикладного протоколу. Зробіть одну зміну, повторіть вимірювання та порівняйте. Такий порядок зменшує кількість хибних висновків і формує конкретні дані для адміністратора або провайдера. Після усунення проблеми повторіть початковий тест, щоб підтвердити зміну саме потрібного симптому.