Сразу хочу обозначить рамки — я фронтенд-разработчик и не настраиваю BGP, не поднимаю маршрутизаторы и не работаю у интернет-провайдера (хотя было дело).

Но ограничения IP-адресов так или иначе влияют на мою работу, на архитектуру продуктов, в частности, на UX, антифрод, аналитику и т.п.

Мы привыкли считать, что IP-адреса — это где-то внизу, на сетевом уровне, и к разработчику они не имеют отношения.

На практике именно дефицит IPv4 сформировал тот интернет, в котором мы сейчас живём: интернет с NAT, серыми IP, сложным WebRTC, странными rate-limit и иллюзией, что IP можно использовать, как идентификатор пользователя.

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

Вы когда-нибудь задавались вопросами: почему P2P на самом деле не совсем P2P, почему один IP — это не единственный пользователь, и почему IPv6 вроде бы существует, но в обыденность так и не вошёл? Давайте порассуждаем.

Почему IPv4 вообще закончился

IPv4 использует 32-битные адреса — те самые привычные 192.168.0.1. Это даёт 2³² возможных адреса, то есть примерно 4,3 миллиарда. 4,3 миллиарда IP-адресов на население планеты в почти 8 млрд. Понимаете, да, несостыковочку?

Вот пара ссылок для общей картины: официальная спецификация IPv4 и APNIC IPv4 Address Exhaustion.

Экскурс в историю

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

Проектируя IPv4, не планировали миллиарды смартфонов, облака с тысячами виртуальных машин, контейнеры, которые живут минуты, CDN, прокси и вот это вот всё безобразие.

Интернет рог гораздо быстрее, чем предполагали при проектировании IPv4. И очень быстро выяснилось, что 4,3 миллиарда — это не на века, а предел, в который мы упрёмся.

И здесь можно сказать, как психолог по отношениям: «понимаете, IPv4 неплохой, он просто не подходит вам сейчас. Он родом из мира, где адрес — это редкий ресурс, а не расходник. А мы живём в мире потребления».

Также роль сыграло, как адреса раздавались в начале. Крупные компании и университеты получали целые /8-сети, адреса выделялись щедро, без мысли о будущем дефиците; перераспределение долгое время никого не волновало.

В итоге, когда интернет стал массовым, IPv4 уже был архитектурно ограничен. Адреса закончились не внезапно — мы просто доехали до потолка, который когда-то казался недостижимым. Но интернет не умер – он адаптировался. И решения, позволившие ему жить в условиях дефицита IPv4, во многом определили архитектуру современного веба.

Что сделали, когда адреса кончились

Когда стало понятно, что IPv4-адресов больше не хватает, интернет не перешёл на новый протокол мгновенно и централизованно. Вместо этого появился NAT — Network Address Translation.

Немного поясню, минутка справочной информации. NAT — это когда один интернет‑адрес делится между всеми вашими устройствами. Например, у вас дома один публичный IP от провайдера, а в интернете живут компьютер, ноутбук, телефон, Алиса (и вы). NAT в роутере делает так, что все они могут пользоваться интернетом одновременно, подменяя адреса и порты на лету, чтобы ответы с сайтов приходили каждому устройству правильно.

И да, это не эволюция интернета. Это аварийное решение — костыль.

Идея проста: внутри сети устройства используют приватные адреса, наружу выходит один белый IP, маршрутизатор подменяет адреса и порты.

Это позволило подключить к интернету миллиарды устройств, отложить конец IPv4 на десятилетия, сделать дефицит адресов не слишком заметным.

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

Потеря end-to-end интернета

Изначально интернет проектировался как end-to-end сеть: одно устройство может напрямую обратиться к другому, зная его адрес. А NAT эту модель сломал.

Теперь входящие соединения невозможны «по умолчанию», соединение почти всегда инициируется клиентом, маршрутизатору нужно помнить и понимать, кто и куда ходит.

И кажется, что для фронтенд-разработчика это выглядит как «ну и что?». А на практике — это причина огромного количества костылей.

Как дефицит IPv4 влияет на фронтенд и продукты

О дефиците IPv4 часто говорят как о сетевой проблеме. На практике это часто и продуктовая, и UX-проблема, которая постоянно всплывает в разработке, но под разными «соусами».

Rate limit и антифрод по IP

IP-адрес до сих пор любят использовать как простой идентификатор для rate limit, антифрода, защиты от ботов. Проблема в том, что IP давно уже больше не описывает пользователя. И в итоге кто-то ловит CAPTCHA за соседа, кто-то получает бан без причины, а кто-то спокойно обходит ограничения.

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

WebRTC, P2P и магия STUN/TURN

Когда говорят P2P, часто подразумевают прямое соединение между двумя клиентами. На практике почти всегда это выглядит так попытка пробиться через NAT, STUN для определения внешнего адреса, TURN как запасной вариант с проксированием трафика через сервер. Получается, прямое P2P-соединение возможно, но только если повезёт, а если нет — всё идёт через инфраструктуру. С точки зрения фронтенда это означает сложную логику соединения, непредсказуемое качество, расходы на серверы, которые вроде бы не нужны. И тут снова поход к психологу и ответ: «Это не потому, что WebRTC плохой, а потому, что интернет перестал быть прозрачной сетью между узлами».

Аналитика, география и серые IP

IP-адрес часто используют для определения страны и региона, анализа, персонализации. Но в реальности мобильные сети используют CGNAT, при котором провайдер выдаёт один внешний IP, грубо говоря на дом, на район или на организацию, корпоративные сети маскируют трафик, а VPN и прокси — уже норма, а не исключение. В итоге география может быть неточной, один IP может внезапно сменить страну, данные в аналитике выглядят странно, но формально корректно. Фронтенд и продукт вынуждены либо игнорировать эти сигналы, либо усложнять логику, либо мириться с погрешностями. И снова — проблема не в инструментах, а в том, что IP перестал быть стабильной характеристикой пользователя.

Локальная разработка vs реальный интернет

Одна из самых коварных ловушек – это локальная разработка и тестирование. На локальной машине всё в одной сети, минимум, NAT, всё предсказуемо. В реальности у пользователя домашний роутер, корпоративный прокси, мобильная сеть, двойной NAT – и всё не предсказуемо, как погода в Таиланде. Поэтому WebRTC работает, но это не точно, сокеты отваливаются, соединения ведут себя иначе, чем в dev-среде.

Отсюда классика: «У меня работает, а у пользователя — нет».

Это не баг фронтенда, а фича. Столкновение локальной модели с реальной сетью. Это жизнь, сынок!

Как итог

Дефицит IPv4 изменил архитектуру интернета, переложил сложность на приложения, заставил разработчиков решать задачи, которые раньше решались самой сетью. И пока мы живём в мире NAT и серых IP, фронтенд и продукты будут продолжать сталкиваться с этими ограничениями — даже если в коде нет ни строчки, связанной с сетями напрямую. Именно здесь на сцену выходит младший брат IPv6. И казалось бы: «Поднять щиты за короля!» Но, как обычно, всё оказалось не так просто.

IPv6: решение или новый компромисс

Когда говорят про IPv6, его часто подают как «правильную версию интернета», до которой мы когда-нибудь обязательно дойдём. Формально, да. Практически – всё, как всегда, сложнее. IPv6, действительно, решает ряд фундаментальных проблем IPv4. Но одновременно приносит новые компромиссы, с которыми разработчикам тоже приходится жить.

Младший брат порешал следующие вопросы:

1. Адреса больше не в дефиците

IPv6 — это 128 бит. Адресов настолько много, что их, как м мобильных приложений сегодня не сосчитать. И да, отлично: каждому устройству можно выдать публичный адрес, больше не нужно прятать клиентов за NAT, исчезает необходимость ужимать сеть. С архитектурной точки зрения это возвращение к простоте.

2. Возвращение end-to-end интернета

Во вселенной IPv6-устройство снова может принимать входящие соединения, быть полноценным узлом сети, общаться напрямую с другим устройством.

Здесь и P2P становится проще, и WebRTC реже падает в TURN, и исчезает часть сетевой магии. Да, IPv6 не гарантирует E2E автоматически, но он перестаёт мешать ему на уровне протокола. Тем не менее, полный E2E не всегда гарантирован: провайдеры с NAT64/DNS64 или корпоративные политики безопасности могут всё ещё блокировать прямые входящие соединения, так что «приложения» должны учитывать и эти нюансы.

3. Меньше костылей на уровне продукта

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

Но проблемы всё же остаются.

И вот здесь начинается реальность.

1. Мир двух протоколов

Мы живём не в мире IPv6, а в мире IPv4 + IPv6 одновременно.

Соответственно, две модели адресации, двойные конфигурации, баги, которые проявляются только в одном из протоколов. Для разработчика это:
- Ой, что-то сломалось!
- А только по IPv6 или наоборот?

2. Безопасность никуда не делась

Есть миф, что IPv6 более безопасен, но на практике публичные адреса означают «добро пожаловать, заходите, кто хочет», firewall становится обязательным, ошибки конфигурации становятся заметнее. IPv6 не решает проблемы безопасности. Он просто делает их более явными.

3. Временные адреса и приватность

Чтобы избежать трекинга, IPv6 использует временные адреса, частую смену идентификаторов. С точки зрения приватности это плюс. С точки зрения продуктов и аналитики — новая головная боль. IP снова нельзя использовать как стабильный идентификатор, но уже по другой причине.

4. Инфраструктура и инерция

IPv6 требует поддержки со стороны провайдеров, обновления оборудования, переосмысления сетевых правил. А самое главное — мотивации. Потому что пока IPv4 работает, переход на IPv6 выглядит как инвестиция без мгновенной отдачи. Это как первое правило программиста: работает – не трогай!

Почему IPv6 всё ещё не везде?

С технической точки зрения IPv6 готов уже давно. Причины, по которым он до сих пор не стал повсеместным стандартом, почти не связаны с технологиями.

Прежде всего это экономика.

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

Инерция

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

«И так сойдёт»

Самый сильный аргумент против любых изменений. Да, не идеально, да, с потерями, но достаточно хорошо, чтобы бизнес не чувствовал боли прямо сейчас. И пока боль не станет критичной, массовый переход будет идти медленно и фрагментировано.

Нашёл вот такую информацию о статистике внедрения IPv6 — может быть, будет интересной:
https://www.ris.ripe.net/peerlist/all.shtml

Что с этим делать разработчику

Фронтенд-разработчик не может ускорить переход на IPv6. Поэтому – смириться и учитывать реальность.

Практические выводы

1. Не гоняйтесь за IP как за пользователем. IP — это уже давно не паспорт пользователя.

В мобильных сетях он меняется довольно часто. В корпоративных сетях за одним IP может прятаться целый офис. Стоит рассмотреть другие идентификаторы — аккаунты, токены, cookie. IP стоит использовать как подсказку, а не как закон.

2. NAT — это норма, а не баг.
В реальном мире почти все пользователи сидят за NAT: дома, в офисе, в мобильной сети. Если вы делаете WebRTC, сокеты или P2P, забудьте про идеальную сеть. Сразу планируйте STUN/TURN, fallback и проверку соединений через разные сети.

3. Тестируйте в реальной жизни, а не только на localhost.
На локальной машине всё предсказуемо, но у пользователя есть домашний роутер, мобильная сеть, VPN, корпоративный прокси. То, что работает у вас, может падать у кого-то через два города и три сети. Нужно проверять приложение в мобильной сети, через VPN, с двойным NAT. Иначе баги ловить будете уже на проде.

4. Сети влияют на UX — и это не всегда баг.
Не всё, что ломается — это ваша ошибка. WebRTC падает через двойной NAT — это не баг, а его фича. Rate-limit срабатывает на соседа? Это CGNAT решил, что он тоже ваш клиент. Не забывайте проектировать UX с пониманием сетевых ограничений. Бывает, что фраза «не работает» — просто реальность сети.

Заключение

В итоге, как фронтенд-разработчик, вы не управляете интернетом, но интернет управляет вами. Дефицит IPv4 и мир NAT/серых IP сделали нас мастерами костылей и обходных путей, а IPv6 хоть и решает некоторые проблемы, но не является панацеей.

Сети влияют на UX — и это нормально. Иногда то, что не работает, — это просто «путь самурая». А наша задача — сделать жизнь пользователя максимально предсказуемой и приятной, даже когда сеть играет не по правилам.