500 Тбит/с: Как мы построили сеть, которая выдерживает самые мощные атаки в интернете

^{Глобальная сеть и магистральные каналы Cloudflare в 2026 году.}

Сеть Cloudflare недавно достигла важной вехи: мы преодолели рубеж в 500 терабит в секунду (Тбит/с) внешней пропускной способности.

Когда мы говорим 500 Тбит/с, мы имеем в виду суммарную выделенную внешнюю пропускную способность соединений: сумму всех портов, обращенных к провайдеру транзита, партнеру по частному пирингу, точке обмена интернет-трафиком или порту Cloudflare Network Interconnect (CNI) во всех 330+ городах. Это не пиковый трафик. В любой конкретный день наша пиковая загрузка составляет лишь часть от этого числа. (Остальное — наш бюджет для отражения DDoS-атак.)

Мы прошли долгий путь с момента старта. В 2010 году мы запустились из маленького офиса над салоном маникюра в Пало-Альто, с одним провайдером транзита и обратным прокси, который можно было настроить, изменив два NS-сервера.

Нашим первым провайдером транзита была компания nLayer Communications, сеть, которую большинство сейчас знает как GTT. nLayer предоставила нам первую пропускную способность и первый практический опыт компании в пиринговых отношениях и тонком балансе между стоимостью и производительностью.

С этого момента мы росли город за городом: Чикаго, Ашберн, Сан-Хосе, Амстердам, Токио. Каждый новый центр обработки данных означал переговоры по контрактам на колокацию, прокладку оптоволокна, установку серверов в стойки и налаживание пиринга через точки обмена интернет-трафиком. Интернет, конечно, на самом деле не «облако». Это совокупность конкретных комнат, заполненных кабелями, и мы потратили годы на то, чтобы изучить нюансы каждой из них.

Не в каждом городе развертывание проходило гладко: приходилось сталкиваться с отсутствующим оборудованием, забастовками на таможне и даже зубной нитью. В течение одного месяца 2018 года мы открыли точки присутствия в 31 городе за 24 дня: от Катманду и Багдада до Рейкьявика и Кишинёва. Когда мы открыли наш 127-й ЦОД в Макао, мы защищали 7 миллионов интернет-ресурсов. Сегодня, имея ЦОДы в 330+ городах, мы защищаем более 20% веба.

По мере роста нашего присутствия клиенты стали просить не только кэширования веб-сайтов. Им нужно было защищать сотрудников, заменять устаревшие каналы Multiprotocol Label Switching (MPLS) и обеспечивать безопасность целых корпоративных сетей. Вместо традиционных аппаратных решений мы создали системы для установления безопасных туннелей к частным подсетям и анонсирования корпоративного IP-пространства напрямую с нашей глобальной сети через BGP.

Масштабы угроз росли параллельно. В 2025 году мы отразили DDoS-атаку мощностью 31,4 Тбит/с, длившуюся 35 секунд. Её источником был ботнет Aisuru-Kimwolf, включавший множество зараженных Android TV. Это была одна из более чем 5000 атак, которые мы заблокировали в тот день. Ни один инженер не был вызван по пейджеру.

Десять лет назад для отражения атаки такого масштаба потребовались бы ресурсы государства-нации. Сегодня наша сеть справляется с этим за секунды без вмешательства человека. Именно этого требует работа в масштабе 500 Тбит/с: размещение интеллекта на каждом сервере нашей сети, чтобы сеть могла защищаться сама.

Вот что на самом деле происходит, когда атака достигает нашей сети. Пакеты поступают на сетевую интерфейсную карту (NIC) и немедленно попадают в цепочку программ eXpress Data Path (XDP), управляемую xdpd и работающую в режиме драйвера. Среди первых программ в этой цепочке — l4drop, которая проверяет каждый пакет на соответствие правилам фильтрации в extended Berkeley Packet Filter (eBPF). Эти правила генерируются dosd, нашим демоном защиты от отказа в обслуживании, который работает на каждом сервере нашего парка. Каждый экземпляр dosd берёт выборку входящего трафика, строит таблицу наиболее активных источников, которые он видит, и транслирует эту таблицу каждому другому экземпляру в дата-центре. В результате формируется единое для всего дата-центра представление о трафике, и поскольку каждый сервер работает с одними и теми же данными, они принимают одинаковое решение о фильтрации.

Когда dosd обнаруживает шаблон атаки, результирующее правило применяется локально через l4drop и распространяется глобально через Quicksilver, наше распределённое хранилище «ключ-значение» (KV), достигая каждого сервера в каждом центре обработки данных за секунды. Только пройдя проверку l4drop, пакеты попадают в Unimog, наш балансировщик нагрузки уровня 4 (L4), который распределяет их между работоспособными серверами в дата-центре. Для клиентов Magic Transit, которые маршрутизируют трафик корпоративной сети через наш край сети, flowtrackd добавляет дополнительный уровень stateful-инспекции TCP, отслеживая состояние соединений и отбрасывая пакеты, не принадлежащие легитимным потокам.

Атака мощностью 31,4 Тбит/с, которую мы отразили, следовала именно по этому пути. Никакой трафик не отправлялся в централизованный центр очистки. Никакого вмешательства человека не было. Каждый сервер в целевых дата-центрах независимо распознал атаку и начал отбрасывать вредоносные пакеты на скорости линии, прежде чем эти пакеты потребили хоть один цикл ЦПУ на обработку приложениями. Программное обеспечение — это только половина истории: ничто из этого не работает, если изначально нет портов, способных поглотить трафик.

Запуск кода на каждом сервере нашей сети стал естественным следствием контроля над всем стеком. Если мы уже запускали программы eBPF на каждой машине для отбрасывания атакующего трафика, то мы могли бы запускать там и код клиентских приложений. Это понимание привело к созданию Workers, а позже KV и Durable Objects.

Наша платформа для разработчиков работает в каждом городе, где мы присутствуем, а не в нескольких облачных регионах. В 2025 году мы добавили Containers в Workers, чтобы более тяжелые рабочие нагрузки тоже могли выполняться на границе сети. Изоляты V8 и пользовательские слои файловой системы минимизируют время холодного старта. Ваш код выполняется там, где находятся ваши пользователи, на тех же серверах, которые отбрасывают атакующий трафик на скорости линии через l4drop. Атакующий трафик отбрасывается до того, как достигнет сетевого стека. Ваше приложение никогда его не видит.

Мы были одними из первых, кто внедрил IPv6 и Инфраструктуру открытых ключей ресурсов (RPKI). Взломы BGP вызывают реальные простои и утечки безопасности. RPKI позволяет нам отбрасывать недействительные маршруты от пиров, гарантируя, что трафик идет туда, куда должен. Мы подписываем Authorization of Route Origins (ROA) для наших префиксов и применяем Route Origin Validation на входящих соединениях. Мы отвергаем маршруты, невалидные с точки зрения RPKI, даже когда это иногда нарушает доступность к сетям с неправильно настроенными ROA.

Следующим шагом является Autonomous System Provider Authorization (ASPA). RPKI проверяет, кому принадлежит префикс. ASPA проверяет путь, который он проделал, чтобы попасть сюда. RPKI — это проверка паспорта в пункте назначения, подтверждающая права владельца, тогда как ASPA — это проверка бортового манифеста: она проверяет каждую сеть, через которую прошел трафик. Утечка маршрута подобна пассажиру, который сел на борт не в том городе; RPKI её не заметит, а ASPA — заметит.

Текущий уровень внедрения ASPA в экосистеме напоминает RPKI в 2015 году. Мы были одной из первых сетей, развернувших RPKI в масштабе, и сегодня 867 000 префиксов в глобальной таблице маршрутизации имеют валидные сертификаты RPKI, по сравнению с почти нулевым показателем десять лет назад. В нашем масштабе протоколы, которые мы выбираем, имеют реальные последствия для всего Интернета. Мы выступаем за их раннее внедрение, потому что ожидание означает больше взломов и больше утечек в промежутке.

ИИ изменил значение присутствия в вебе. В течение большей части истории Интернета трафик генерировался людьми, которые кликали по ссылкам в браузерах. Сегодня ИИ-краулеры, конвейеры обучения моделей и автономные агенты уже составляют более 4% всех HTML-запросов в нашей сети, что сопоставимо с Googlebot. «Пользовательский» краулинг, когда ИИ посещает страницу, потому что человек задал ему вопрос, вырос более чем в 15 раз только в 2025 году.

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

Например, на уровне TLS легитимный браузер представляет ClientHello с предсказуемым набором шифр-наборов, расширений и порядком, соответствующим заявленному User-Agent. Краулер, подделывающий этот User-Agent, но использующий упрощенную TLS-библиотеку, представит другой отпечаток, и это несоответствие — один из сигналов, которые наши системы используют для классификации запроса до того, как он достигнет источника.

То, что началось над маникюрным салоном в Пало-Альто, сегодня превратилось в сеть мощностью 500 Тбит/с, охватывающую более 330 городов в 125+ странах, где каждый сервер работает на нашей платформе для разработчиков и с нашими сервисами безопасности, а не просто кэширует данные. Это шестнадцать лет кумулятивного эффекта от архитектурных решений, и мы благодарны за это более чем 13 000 сетям и партнерам, которые взаимодействуют с нами. Мы еще не закончили.