Кратко

  • План RIPEstat на третий квартал 2026 года называет Routing History следующей важной визуализацией для перестройки и связывает работу с долгосрочной поддержкой и включением Content Security Policy.
  • Публичная Data API остаётся единственным источником данных для UI, но мягкий предел строк, порог peers, первый переход, нормализация видимости, временное окно и неизвестное состояние влияют на вывод читателя.
  • Компактная запись о паритетности должна привязать обе версии к фиксированным ответам, раскрыть параметры и намеренные различия, проверить граничные случаи и сохранить цепочку исправления и отключения.

История, которая начинается с десятого peer

Представим, что объявление prefix сначала видно девяти полным peers RIS, а затем одиннадцати. С порогом по умолчанию, равным десяти, линия начнётся со второго периода. При более низком пороге появится и первый. Никакого противоречия в наблюдениях нет, но два экрана сообщат разные даты «начала» маршрута.

Это не обвинение в существующей ошибке. Это пример решения, которое стоит сделать проверяемым при следующей миграции RIPEstat. В плане на третий квартал 2026 года Routing History назван следующей визуализацией для обновления и инструментом высокой ценности для внутренних и внешних пользователей. RIPE NCC собирается переводить старые визуализации на новые технологии и обновлённый дизайн ради долгосрочной поддержки и включения Content Security Policy, CSP. Статус задачи — «в работе».

Сильнейший аргумент в пользу замены относится к обычной инженерной ответственности. Старый frontend может показывать корректные данные и одновременно мешать строгой политике браузера из-за прежних способов загружать scripts, styles или внешние ресурсы. CSP Level 3 от W3C определяет механизм управления ресурсами, которые страница может получать или выполнять, и другими решениями безопасности. Режим report-only позволяет наблюдать нарушения до применения ограничений. Удаление препятствий для этой защиты не доказывает атаку; это нормальное обслуживание.

Паритетность также не означает копирование каждого pixel. Доступная цветовая схема, логичная навигация с клавиатуры и хороший мобильный обзор обоснованно меняют вид. Архив планов RIPEstat показывает, что команда уже завершала функциональный паритет старого и нового UI, внедряла автоматические тесты, осторожно разворачивала обновления widget и следила за влиянием переноса обработки данных RIS. Исследованные источники не позволяют утверждать, что внутренних проверок нет.

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

API задаёт опору, а не окончательную трактовку

В документации RIPEstat границы ролей проведены ясно. Обзор Data API называет её публичным интерфейсом и единственным источником для widgets и UI. Страница Что такое RIPEstat отделяет API, которая поставляет данные и отвечает на запросы, от UI, который показывает способы визуализации.

Ответ API подходит для сравнения версий, но не рисует себя сам. Текущая версия 2.3 endpoint Routing History использует данные route collectors RIS и группирует периоды объявлений по origin и prefix. Параметры способны изменить видимый результат.

max_rows — мягкий предел с исходным значением 3000. После его достижения возвращаются все записанные маршруты уже включённого origin, но новые origins больше не добавляются. Значит, стабильная сортировка и уведомление об усечении влияют на смысл. include_first_hop добавляет ASN первого перехода и может разделить одну серию origin на несколько. normalise_visibility рассчитывает долю полных RIS peers, видевших маршрут. min_peers по умолчанию равен десяти и отсекает локальные или маловидимые объявления ниже порога. starttime и endtime ограничивают период, а при отсутствии конечного времени окно движется вместе с последними доступными BGP-данными.

Есть особое значение: нормализованная видимость может быть -1, если данные peers отсутствуют или ненадёжны. Это не ноль. Точка на нулевой линии утверждала бы измеренное отсутствие. Молчаливый пропуск мог бы создать видимость непрерывности. Соединение соседних участков придумало бы наблюдение. Дизайн разрешено менять, но границу между «неизвестно» и «ноль» менять нельзя.

Область наблюдения должна сопровождать график. Routing History указывает на RIS collectors. Документация Routing Status говорит о состоянии, наблюдаемом RIS, и предупреждает, что у AS могут быть соседи, которых эти collectors не видят. График — ценное публичное свидетельство из определённой системы наблюдения, а не полный обзор Интернета.

Время создаёт ещё одну ложную разницу. RIPEstat пишет, что актуальность зависит от частоты сбора, обновления хранилища, задержки обработки, сбоев и cache. Два live-экрана, открытые в разные моменты, могут получить разные backend-состояния. Для смыслового сравнения нужен сохранённый ответ с временем, hash и фиксированным окном. Live-тесты по-прежнему нужны для доступности и свежести, но это другой тест.

Минимальный проверяемый документ

Не нужна новая комиссия и не нужны две UI навсегда. При запуске достаточно опубликовать версионную запись для небольшого набора репрезентативных fixtures.

Для каждого случая она перечисляет старый и новый build, версию endpoint и методологии, ресурс, границы UTC, часовой пояс показа, заданные параметры, фактически применённые defaults, время и hash фиксированного ответа. Затем описывает правила группировки, сортировки, усечения и отображения пропусков.

Набор должен включать неудобные случаи: prefix с одним origin, multi-origin, ответ у мягкого предела, интервалы по обе стороны порога peers, включённый first hop, ненадёжные сведения о peers, открытый последний интервал, работу с клавиатуры и узкий экран. Цель — не равенство pixels, а проверка того, исчезает ли существенный факт, меняет ли группу или временную границу.

Ожидаемые различия надо назвать. Доступная палитра не является регрессией. Перестроенная легенда может уменьшить ошибки. Переход на UTC может улучшить сопоставимость, если tooltip и export используют тот же стандарт. Зафиксированная причина не позволит будущему разработчику вернуть старое ограничение под видом соответствия.

Записи нужны владелец, нерешённые исключения, дата проверки, ссылки на исправления и замены, а также правило выключения. Старую UI не следует хранить из-за косметических расхождений. Её можно отключить, когда различия, меняющие решения, закрыты или явно приняты, доступные сценарии прошли и новая картина воспроизводится из сохранённого запроса.

Чего источники не устанавливают

Материалы не доказывают, что нынешний Routing History ошибочен, что новая версия уже запущена или провалилась, что CSP меняет маршруты, что есть эксплуатируемая уязвимость или что RIPE NCC потерял данные. Квартальный план не является отчётом о внедрении, а открытая документация API не описывает все внутренние тесты.

Рекомендация направлена в будущее. Она сохраняет различие между наблюдением RIS, публичным контрактом API и решением конкретного UI-build о том, что показать. Тогда защита браузера может усиливаться без требования верить в сохранность смысла на слово.

Источники