kernel.org борется с ИИ-ботами: 6 млн запросов в сутки

2026-08-31 183 комментарии
На git.kernel.org сбор данных для обучения моделей идёт волнами с миллионов домашних и мобильных адресов: около 6 млн обращений в сутки приходится на страницы отдельных коммитов, а 14–16 из 90 процессорных ядер постоянно превращают историю Git в HTML. На людей остаётся около 2% трафика

На git.kernel.org приходит около 6 млн запросов в сутки к страницам отдельных коммитов, и почти весь поток создают боты, собирающие данные для обучения языковых моделей. Из 90 процессорных ядер, распределённых по пяти площадкам, 14–16 постоянно заняты только преобразованием истории Git в HTML для таких сборщиков. Проверка Anubis отсекает две трети обращений, но оставшаяся треть решает предложенную задачу и доходит до основного сайта. По оценке инфраструктурной команды, на долю обычных посетителей приходится порядка 2% всего трафика площадки, а данные, за которыми охотятся боты, и без того лежат в открытом доступе.

Кто такие ИИ-боты и зачем им коммиты ядра

Сбором текстов для обучения моделей занимаются программы, которые переходят по ссылкам и сохраняют содержимое страниц. Внешне они ведут себя как обычный посетитель: тот же протокол, те же запросы, тот же браузерный заголовок User-Agent. Разница в цели. Поисковый робот строит индекс, чтобы вернуть человека на сайт, а сборщик обучающих данных забирает текст один раз и ничего взамен не отдаёт – ни ссылок, ни посетителей.

ИИ-бот (AI crawler) – программа, которая автоматически обходит веб-страницы и сохраняет их текст в корпус для обучения языковой модели. От поискового робота отличается назначением собранного материала, а часто и тем, что не соблюдает ограничения из файла robots.txt.

История разработки ядра Linux ценна для такой задачи по двум причинам. Она целиком открыта – от репозиториев до архивов почтовых рассылок. И она датирована: коммиты, сделанные до появления генеративных моделей, гарантированно написаны людьми. Обучение модели на текстах, порождённых другой моделью, ухудшает результат, поэтому проверяемо «человеческие» корпуса ценятся особенно высоко. Масштаб явления виден и по сторонней статистике: Cloudflare, через инфраструктуру которой проходит около пятой части мирового трафика, связывала рост глобального трафика в 2025 году в том числе с активностью подобных сборщиков.

kernel.org как точка распространения исходного кода

Сайт kernel.org работает с 2002 года и принадлежит некоммерческой организации The Linux Kernel Organization, зарегистрированной в Калифорнии; техническое, финансовое и кадровое обеспечение берёт на себя Linux Foundation. Здесь лежат репозитории, которыми пользуются авторы ядра и сопровождающие дистрибутивов, архивы почтовых рассылок и зеркала смежных проектов. Отсюда же скачивают исходный код все, кому нужна конкретная версия ядра.

kernel.org – официальная площадка распространения исходного кода ядра Linux и связанной инфраструктуры разработки. Раздел git.kernel.org даёт доступ к репозиториям через веб-интерфейс cgit: можно открыть отдельный коммит, различия между версиями или готовый патч.

Копия репозитория забирается одной командой, авторизация для этого не нужна:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

После клонирования вся история находится на локальной машине, и дальше с ней можно работать без единого обращения к серверу. Именно этот путь и предполагался как основной.

Шесть миллионов запросов в сутки и 14 занятых ядер

В записи от инфраструктурная команда kernel.org впервые привела измеренные показатели. Ежедневно git.kernel.org получает примерно 6 млн запросов к страницам произвольных коммитов. Две трети из них, 66%, отбивает проверка Anubis на входе. Оставшиеся 33% решают предложенную задачу и попадают на сайт – ради страниц с историей правок кто-то готов тратить заметные вычислительные ресурсы. Отделить здесь бота от человека по одному запросу нельзя, но обращение к старому коммиту в заброшенном ответвлении на работу живого разработчика не похоже.

Отсюда и оценка структуры трафика: при щедрых допущениях на обычных посетителей приходится около 2%, остальное – автоматический сбор. В пересчёте на оборудование это 14–16 из 90 ядер на пяти географически разнесённых узлах, в среднем пятая часть всей мощности площадки. Нагрузка идёт волнами, так что ровной линией на графике она не выглядит.

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

– Константин Рябицев, директор по ИТ-инфраструктуре проектов, Linux Foundation

Почему постраничный сбор дороже одного клонирования

Репозиторий linux.git насчитывает около 1,48 млн коммитов, и на git.kernel.org размещено примерно 922 его ответвления (fork). Для сервера это почти бесплатно: объекты в ответвлениях те же самые, хранилище общее. Для сборщика картина обратная. Каждое ответвление выглядит как отдельный набор адресов, и одни и те же 1,48 млн коммитов выкачиваются сотнями копий.

Дальше вступает в игру устройство cgit. Один и тот же коммит отдаётся в виде страницы, патча, простого текста, а сравнить между собой можно произвольную пару коммитов. Комбинаторика превращает это в миллиарды формально допустимых адресов на одно ответвление, и каждый такой адрес требует вычислений на стороне сервера. Пока по сети ходили люди и роботы, уважающие robots.txt, схема работала. Сейчас она обходится в постоянно занятые процессорные ядра, хотя те же данные отдаются одним клонированием и без всякой отрисовки.

Почему блокировка по IP и по ASN перестала помогать

Сначала помогал разбор журналов и fail2ban: боты сами называли себя в поле User-Agent. Когда они начали маскироваться под обычные браузеры, счёт пошёл на адреса, а затем на целые автономные системы – запрос из облачной сети, перебирающий коммиты восьмилетней давности, вряд ли исходит от человека с браузером. Ценой редких ложных срабатываний способ работал.

Затем трафик пришёл с миллионов домашних и мобильных адресов. Один такой адрес делает четыре-пять запросов и больше не появляется, а к моменту, когда его вычислили, он уже не нужен. Блокировать бессмысленно: правила брандмауэра растут, толку нет. Волна обращений накрывает площадку, доводит её до отказа и смещается к следующей цели, чтобы вернуться позже.

Прокси на домашних адресах (residential proxy) – сервис, который пропускает чужой трафик через подключения обычных пользователей. Для принимающей стороны запрос выглядит как обращение из жилого дома или с мобильного телефона, поэтому фильтрация по репутации адреса не срабатывает.

Источник такой мощности – встроенные в приложения библиотеки, зарабатывающие на перепродаже канала. По итогам проверки 6038 приложений для телевизоров LG и Samsung компания Spur Intelligence сообщила , что 2058 из них содержат такие библиотеки: заставка с аквариумом или часы продолжают пропускать чужие запросы даже после закрытия приложения. Похожим образом пополняются и криминальные прокси-сети – недавно описанный ботнет для сетевого оборудования превращал заражённые устройства в скрытые узлы SOCKS5.

Anubis: сложность 5 и боты, которые её решают

Около года назад перед сайтами kernel.org поставили Anubis – прокси-фильтр с открытым исходным кодом, который перед выдачей страницы заставляет браузер подобрать строку с нужным числом нулей в начале SHA-256-суммы. Расчёт стоит посетителю доли секунды, а массовому обходу миллионов адресов – вполне ощутимых денег.

Доказательство работы (proof-of-work) – способ подтвердить, что клиент потратил вычислительные ресурсы: сервер задаёт условие, подобрать ответ можно только перебором, а проверка занимает микросекунды. Экономика запроса смещается в сторону обороняющейся стороны.

Первые месяцы фильтр отрабатывал полностью: поток от сборщиков практически исчез. Через несколько месяцев сложность 4 перестала быть препятствием, и порог подняли до 5. Для человека с телефоном это несколько секунд ожидания и заметно тёплый корпус, зато затишье продлилось ещё пару месяцев. Сложность 5 стоит на git.kernel.org и сейчас – и треть запросов доходит до сайта. Другие площадки пробуют иные подходы: Cloudflare, например, уводит неопознанных ботов в лабиринт из сгенерированных страниц вместо прямой блокировки.

Что отключат для анонимного доступа

Ответ на нагрузку выбран прямой: сократить число адресов, которые вообще можно обойти, и закрыть дорогие операции для неавторизованных посетителей. Часть привычных возможностей веб-интерфейса при этом пропадёт, о чём предупреждают заранее. Открытость данных не меняется: репозитории и переписка разработчиков остаются доступны для скачивания всем желающим, просто получить их станет чуть менее удобно.

Сборщики, при всей прожорливости, площадку не роняют – git.kernel.org отвечает быстро. К отказам приводит другое, например одновременное клонирование stable.git с ограниченной глубиной истории (shallow clone) с двух десятков узлов чьей-нибудь системы непрерывной интеграции. Для регулярных задач такого рода инфраструктурная команда рекомендует поднимать собственное зеркало.

Заключение

История kernel.org показывает, во что обходится открытость, когда её потребляют машины: пятая часть мощности уходит на выдачу того, что и так лежит в открытом доступе, причём самым расточительным способом из возможных. Проверки с доказательством работы дают отсрочку, но не решение – экономика сбора данных пока перевешивает стоимость их обхода. Тем, кто регулярно работает с репозиториями ядра, стоит перейти на клонирование и локальное зеркало: веб-интерфейс будет беднеть, а ограничения для анонимных обращений – расти.

© .
Комментарии и отзывы

Нашли ошибку?

Новое на сайте