Коротко: Интернет проектировался открытым — любой мог запустить сервис без разрешений, устройства общались напрямую. Сегодня трафик идёт через несколько крупных платформ, которые контролируют данные и доступ. Статья о том, как это произошло, почему это проблема, и что можно сделать, чтобы вернуть контроль.
Вступление
Интернет задумывался как сеть сетей — система с простой серединой и свободными краями. Главный принцип: любой участник может запустить сервис, добавить протокол или узел, не спрашивая разрешения. Архитекторы делали ставку на нейтральность инфраструктуры и богатство экспериментов. Протоколы проектировались под долговечность, расширяемость и отказоустойчивость даже в условиях разрушенной инфраструктуры.
Сегодня эти идеи работают лишь частично. Трафик идёт через несколько глобальных облаков и CDN (сеть серверов для быстрой доставки), которые оптимизируют доставку, но одновременно становятся точками контроля. Бизнес-модели, заточенные под сбор данных о поведении пользователей, меняют баланс интересов: из инструмента коммуникации интернет превращается в пространство коммерческого влияния. Платформы создают «высокие стены» вокруг своих экосистем, усложняя переход между сервисами.
Изменения затронули не только технику, но и культуру: появились новые модели регулирования, монетизации и алгоритмической модерации, которые определяют, кто получает видимость, а кто оказывается на периферии. Это поднимает вопросы: можно ли вернуть открытую архитектуру, какие элементы прежней культуры стоит сохранить, и где остаётся потенциал для переосмысления сетевых принципов?
Оригинальный замысел: принципы, а не платформы
Технический каркас проектировали как интероперабельную систему (способность разных систем работать вместе по общим стандартам) — разные устройства и сети должны понимать друг друга без специальных договорённостей.
В 1963-м Дж. Ликлайдер представил «межгалактическую сеть» — совокупность компьютеров, делящих своё время между многими пользователями одновременно (таймшеринг — технология разделения времени). Терминалы на краях были полноправными участниками, а не просто потребителями. Это была не «суперкомпания», а общее пространство связи и идей.
В 1974-м Керф и Кан описали межсетевой протокол: пакеты данных должны доходить сквозь разные сети, а надёжность и упорядочивание обеспечиваются на концах, а не в середине. Это и есть дух «сеть сетей» — простое ядро, умные края.
В 1984-м Салтцер, Рид и Кларк формализовали это как «концевой принцип» (архитектурная идея: сеть должна быть простой и только передавать данные, а всю сложную логику делают устройства на концах): сложные функции должны жить на устройствах пользователей (на «концах»), иначе мы усложняем сеть посередине и всё равно не получаем гарантий. Практическое следствие — простая, быстрая сеть-транспорт и богатая логика в приложениях.
Параллельно Тим Бернерс-Ли предложил Всемирную паутину — систему связанных документов поверх существующей сети. Не портал и не платформа, а минимальный набор открытых стандартов, доступных всем.
Ключевая идея — гипертекст (текст со ссылками на другие документы). Вы кликаете на ссылку и переходите на другую страницу. Простота и открытость стандартов позволили любому создать сайт и связать его с остальным интернетом.
Поведенческую норму выразил «закон Постела»: будь строг к тому, что посылаешь, и терпим к тому, что принимаешь. Это инженерная этика, делающая интернет устойчивым к несовершенствам реального мира — даже если кто-то отправил данные не по стандарту, постарайся их понять.
Культурная рамка была столь же амбициозна. Барлоу в 1996 году сформулировал киберпространство как самоуправляемую среду без государственного контроля. Менее поэтичный, но более точный взгляд у Лессига: «код — это закон» — архитектура сети сама регулирует поведение. Спор идёт не об анархии, а о том, как проектировать архитектуру так, чтобы она защищала свободу, приватность и конкуренцию.
«Паутина задумывалась как децентрализованное пространство. Я всегда представлял информационное пространство, в котором все имеют непосредственный доступ.» — Тим Бернерс-Ли
Ключевые переломные моменты
1989 — Тим Бернерс-Ли создаёт World Wide Web. Открытая паутина, доступная всем.
2004 — Запуск Facebook. Начало эры платформ и закрытых экосистем.
2007 — Выход iPhone. Мобильный интернет приложений вместо открытого веба.
2011 — Исчерпание адресов IPv4. Массовое внедрение NAT, конец эры «каждому устройству — свой адрес».
2016 — Скандал Cambridge Analytica. Общество осознаёт масштаб сбора данных платформами.
2021 — Падение CDN-провайдера Fastly. Час простоя «положил» половину популярных сайтов. Хрупкость централизации стала очевидной.
Что получилось на уровне протоколов
Первый крупный излом — исчерпание адресов IPv4 (старая версия интернет-протокола с 4 млрд адресов) и массовое внедрение NAT (технология трансляции адресов). У IPv4 было около 4 миллиардов уникальных адресов, но их быстро не хватило. Решение: десятки устройств дома или в офисе теперь «прячутся» за одним общим адресом в интернете.
Это принципиально изменило архитектуру. «Концы» уже не могут напрямую соединяться друг с другом (если оба за NAT) — у каждого есть только внутренний адрес, невидимый из глобальной сети. Прямое соединение между двумя компьютерами стало невозможным без сложных трюков: проброса портов, внешних серверов-посредников (STUN/TURN) и прокси-сервисов.
P2P (прямое соединение устройств без посредников, как в торрентах) стал трудным из-за NAT.
Да, NAT спас интернет от коллапса адресов. Но за это заплатили: исчезла простота «интернета участников». Раньше можно было легко поднять сервер дома. Теперь для этого нужны специальные настройки, туннели или зависимость от платформенных посредников.
Второй — шифрование стало стандартом. Это огромный плюс: конфиденциальность трафика благодаря TLS (протокол шифрования) и массовому переходу на HTTPS (защищённая версия HTTP). Бесплатные сертификаты от Let’s Encrypt (бесплатный центр сертификации) сделали шифрование доступным для всех. Но есть цена: сеть стала «непрозрачной» — диагностика и безопасность теперь на стороне приложений, а не в самой сети.
Третий — переизобретение транспорта. Новый протокол QUIC (современный протокол, встроенный в браузеры) встроили прямо в браузеры, обойдя устаревшие промежуточные устройства (файрволы, прокси). Это ускорило работу, но ещё сильнее закрепило идею: транспорт контролируется приложением и CDN, а не открытой сетью.
Четвёртый — приватность DNS. Технологии DoH и DoT (зашифрованные запросы к DNS) зашифровали запросы к DNS (система доменных имён, превращающая google.com в IP-адрес), чтобы провайдер не видел, какие сайты вы открываете. Но это централизовало DNS у нескольких крупных компаний (Google, Cloudflare), если браузер выбирает их по умолчанию. Опять компромисс: меньше слежки от провайдера, больше зависимости от крупных игроков.
Пятый — хрупкость глобальной маршрутизации. Протокол BGP (протокол маршрутизации между провайдерами), управляющий маршрутами в интернете, до сих пор основан на доверии между провайдерами. В 2008-м пакистанский провайдер случайно «угнал» трафик YouTube на весь мир. Защита RPKI (криптографическая защита маршрутов) внедряется медленно и не везде.
Итог: концевой принцип сохранился в теории, но на практике края «прикручены» к крупным провайдерам облаков, DNS-сервисам и платформам доставки. Свободное участие «на равных» стало исключением, а не нормой.
Что получилось в культуре и экономике
Культура «сам себе веб-мастер» уступила место лентам и алгоритмам. Раньше люди вели свои сайты и ссылались друг на друга. Теперь публикуют внутри платформ (Facebook, Instagram, TikTok) и конкурируют за внимание. Модель сменилась: не «свой дом в сети», а «аренда места в чужой экосистеме».
Переход к монетизации данных закрепил это институционально. Шошанна Зубофф назвала это «капитализм наблюдения» (бизнес-модель, где главный продукт — данные о поведении пользователей): каждое действие пользователя собирается и превращается в продукт для рынка рекламы и предсказаний. Сервисы проектируются так, чтобы извлекать данные и влиять на поведение, а не чтобы давать пользователю автономию.
«Если вы не платите за продукт, значит продукт — это вы.» — Народная мудрость интернета
Юридическая сцена пошла зигзагами. Идеал сетевой нейтральности (принцип, по которому провайдер одинаково пропускает весь трафик) то вводили, то отменяли на уровне стран и регионов. Спор о том, кто может «привилегировать» одни сервисы перед другими, стал спором о конкуренции, свободе выражения и власти над инфраструктурой.
Коммуникация фрагментировалась. Частные чаты, видеозвонки и «сторис» вытеснили веб-страницу как главную единицу публикации. Ваша идентичность теперь привязана к аккаунту на платформе, а не к собственному домену. Видимость контента определяют непрозрачные алгоритмы рекомендаций и модерации. Формально базовые свободы сети живы: можно публиковать, ссылаться, запускать свой сервис. Но практически это требует всё больше знаний и обхода препятствий, которые создают платформы.
Диагностика: где сломано на уровне первых принципов
«Архитектура — это политика.» — Лоуренс Лессиг, автор концепции «Код — это закон»
Первое — сломан прямой путь данных между устройствами.
Раньше соединение шло напрямую. Теперь данные проходят через слои обработки:
- NAT переписывает адреса и порты на лету
- CGN у провайдера (NAT на стороне провайдера, когда несколько домов делят один внешний адрес) добавляет ещё один уровень трансляции
- Прокси фильтруют, собирают статистику, вводят ограничения
К чему это приводит? Усложнена отладка — задержки зависят от скрытых механизмов. Запуск своего сервиса требует согласования с оператором. Разработчики тратят время на обход препятствий вместо создания нового. Видеозвонки и онлайн-игры страдают от обрывов соединений.
Второе — доверие сконцентрировалось у нескольких игроков.
Базовые операции зависят от ограниченного круга компаний: подтверждение подлинности сайтов, DNS, CDN, проверка обновлений.
Проблема в точках концентрации. Сбой в одном месте роняет огромные куски интернета. Эти точки становятся мишенями для атак и давления. Малые игроки вынуждены подстраиваться под правила крупных.
Пример: в 2021 году падение CDN-провайдера Fastly «положило» Amazon, Reddit, CNN, GitHub и десятки других сайтов по всему миру на час.
Третье — «код как закон» пишется под максимизацию внимания и прибыли.
Архитектура сервисов подчинена метрикам бизнеса: алгоритмы показывают не то, что вам нужно, а то, что удержит дольше. Рекомендации оптимизированы под «вовлечённость». Приватность по умолчанию открыта. Экспорт данных усложнён.
Это не злой умысел, а инерция бизнес-модели. Но результат один: архитектура реализует стратегию платформы, а не интересы пользователя. Даже разработчики, желающие иного, следуют метрикам «времени на сайте» и «глубины прокрутки». Сам код воплощает капитализацию внимания.
Четвёртое — маршрутизация держится на доверии, а не на защите.
Протокол BGP позволяет операторам менять маршруты трафика, но не требует доказательств прав. Отсюда случайные перехваты: YouTube в 2008, AWS в 2018.
RPKI (система защиты) внедряется медленно — операторы боятся сбоев. Экономических стимулов нет: убытки от чужих ошибок не персонализированы. Устойчивость держится на профессиональной этике, а не на автоматических гарантиях.
Что можно сделать на практике
Для обычных пользователей
Три базовых принципа для сохранения контроля:
1. Владейте своим присутствием
Используйте собственный домен для email и сайта (даже простого). Регулярно экспортируйте данные из соцсетей. Сохраняйте важные контакты вне одной платформы.
2. Выбирайте открытые сервисы
Предпочитайте сервисы с возможностью экспорта данных. Используйте RSS (технология подписки на обновления сайтов) для чтения вместо зависимости от алгоритмов. Поддерживайте федеративные платформы (независимые серверы, общающиеся по открытым протоколам): Mastodon вместо Twitter, Matrix вместо WhatsApp.
3. Защищайте приватность
Используйте DNS-серверы, не принадлежащие провайдеру (Quad9, NextDNS). Проверяйте настройки приватности в соцсетях — по умолчанию они открыты. Тестируйте: сможете ли восстановить доступ к данным, если платформа заблокирует аккаунт?
Для технических специалистов
Адресуемость и транспорт
Внедряйте IPv6 (новая версия интернет-протокола с огромным количеством адресов) для восстановления прямой адресуемости без NAT. Настраивайте собственные анонсы префиксов (если управляете ASN). Автоматизируйте инфраструктуру через Ansible или Terraform.
DNS и сертификация
Разворачивайте собственные DNS-резолверы с DNSSEC (криптографическая защита DNS). Автоматизируйте выпуск TLS-сертификатов (Let’s Encrypt + ACME — протокол автоматического получения SSL-сертификатов). Контролируйте домены и SPF/DKIM-записи для email. Храните корневые доступы отдельно от основной инфраструктуры.
Федеративные приложения
Интегрируйте федеративные протоколы: Matrix для чатов, ActivityPub для публикаций, Mastodon для соцсетей. Закладывайте сценарии резервного копирования с первого дня. Используйте статические сайты с версионированием и экспортом на несколько хостингов.
Безопасность и аудит
Настраивайте мониторинг логов с автоудалением чувствительных данных. Для провайдеров: запрашивайте поддержку RPKI и отчёты о валидации маршрутов. Распределяйте ключевые материалы географически, проводите квартальные аудиты доступов.
Культурно и организационно
Возвращение к открытой сетевой культуре:
Для личного использования
Стройте цифровую идентичность вне одной платформы — свой домен, личный архив. Используйте RSS для чтения вместо алгоритмов. Поддерживайте блоги вне агрегаторов. Сохраняйте контакты локально.
Для команд и сообществ
Формируйте традицию открытого документа — репозитории знаний, доступные всем. Выбирайте инструменты с экспортом. Тестируйте: можете ли сменить платформу без потери истории? Создавайте перекрёстные ссылки между независимыми сайтами.
Для оценки продукта
Смотрите не только на метрики вовлечённости, но и на простоту миграции. Насколько легко отделить данные от платформы? Можно ли развернуть аналог самостоятельно?
Регуляторно
Нейтральность и переносимость должны быть техническим требованием, а не декларацией.
Что требовать от платформ
Документированный API для доступа к данным. Экспорт без потерь структуры. Оповещение об изменениях протоколов заранее. Открытые процедуры аудита и миграции. Публикация схем хранения и журналов операций.
API (Application Programming Interface) — набор правил для обмена данными между программами. Через API вы можете выгрузить свои данные из платформы.
Что запрещать
Искусственное затруднение доступа к собственным данным. Навязывание закрытых форматов, затрудняющих переносимость. Блокировку интеграций со сторонними сервисами.
Только так «код как закон» работает в интересах пользователя.
Что происходит сейчас: движения за открытый интернет
Несмотря на централизацию, появились альтернативные движения и технологии:
IndieWeb
Движение за возвращение личных сайтов и контроля над своим контентом. Основная идея: ваш сайт — ваш дом в интернете. Вы публикуете на своём домене, а в соцсетях только репостите.
Принципы: владей своими данными, публикуй на своём, используй открытые форматы (Microformats, WebMention).
«Ваш контент — ваша собственность. Сайты могут исчезнуть, но если у вас собственный домен, вы сохраняете контроль.» — Принцип IndieWeb
Сайт: indieweb.org
Fediverse (Федивселенная)
Федерация социальных сетей, где независимые серверы общаются между собой по открытым протоколам (как email):
- Mastodon — альтернатива Twitter (микроблоги)
- Pixelfed — альтернатива Instagram (фото)
- PeerTube — альтернатива YouTube (видео)
- Lemmy — альтернатива Reddit (форумы)
Вы регистрируетесь на одном сервере, но можете подписаться на пользователей с любых других серверов. Если сервер вам не нравится — переезжаете, сохранив подписчиков.
Протокол: ActivityPub (стандарт для федеративных соцсетей). Сайт: fediverse.party
Solid
Проект Тима Бернерса-Ли по разделению данных и приложений. Ваши данные хранятся в личном «поде» (pod — хранилище, которым вы владеете), которым вы владеете. Приложения запрашивают доступ к вашим данным, но не владеют ими.
Идея: вы можете сменить приложение для соцсети, но ваши данные, друзья и история остаются с вами.
Сайт: solidproject.org
IPFS
InterPlanetary File System — распределённая файловая система, альтернатива централизованному хостингу. Файлы хранятся на множестве узлов, обращение к ним по содержимому (hash), а не по месту хранения.
Преимущества: файлы не исчезают, если один сервер упал. Недостатки: пока сложно для массового использования.
Сайт: ipfs.tech
Коротко о сценариях
Сценарий 1: Статус-кво
Если ничего не менять, консолидация продолжится. Традиционные сетевые уровни растворятся внутри закрытых экосистем. Контроль и аудит останутся только у владельцев приложений. Пользователь будет зависеть от технической монополии нескольких компаний.
Последствия: управление трафиком, ключами, обновлениями станет непрозрачным. Сбои обнаружатся только когда повлияют на пользователей. Альтернативные технологии станут «экзотикой» для специалистов. Разногласия будут решаться через закрытые бизнес-соглашения, а не открытые стандарты.
Сценарий 2: Пересборка
Альтернатива — системная работа по восстановлению контроля пользователей.
Технически: поддержка независимой маршрутизации (RPKI, BGP-безопасность). Развитие федеративных протоколов и открытых стеков. Прозрачное протоколирование и публикация журналов. Технические аудиты как часть жизненного цикла сервисов.
Результат: сеть снова становится многообразной и подвижной. Среда для новых игроков и федеративных сервисов. Экспериментальные модели управления идентичностью. Публичная оценка надёжности компонентов.
Главное: восстановление права пользователя самостоятельно определять схему коммуникации, расположение данных и возможность миграции между сервисами без потерь.
Заключение
Интернет не «сломался» — он эволюционировал через серию компромиссов. Классические принципы (распределённость, простые протоколы, доверие к участникам) остались идеалами. На практике систему адаптировали под новые задачи и ограничения:
- Сначала внедрили NAT ради удобства
- Потом появились облака и платформы ради централизации контроля
- Затем «код как закон» встроили в инфраструктуру
Что дальше?
Восстановление требует большего, чем возврат назад. Нужны работающие модели, где техническая автономия сочетается с ответственностью. Где распределённые решения включают механизмы эскалации и оспаривания. Где есть методы обнаружения злоупотреблений без разрушения связей.
Что делать?
На техническом уровне — создавать инструменты, снижающие барьер для самостоятельного контроля. На культурном — формировать культуру осознанного владения инфраструктурой и данными. На институциональном — развивать стандарты самоконтроля и аудита для операторов и платформ.
Цель: чтобы автономия, совместимость и подотчётность вновь стали нормой, а не исключением.
Исторические источники и базовые принципы см. у Ликлайдера, Керфа и Кана, Салтцера–Рида–Кларка, Бернерса-Ли, Постела, а также в работах Барлоу и Лессига; современную динамику шифрования и маршрутизации — по RFC и кейсам операторов.
