Кратко

  • RFC 3568 — Informational-обзор 2003 года о механизмах, известных или применявшихся к декабрю 2000-го: DNS-, транспортная и прикладная маршрутизация запросов видят разные личности и части запроса.
  • «Лучший суррогат» — временный вывод конкретного наблюдателя из набора кандидатов, направленных и стареющих метрик и версии политики. Его надо довести квитанциями до фактической доставки и результата приложения.

Активное зондирование выглядит объективно: отправить ICMP или HTTP-запрос, измерить ответ, ранжировать кандидатов. Но оно происходит периодически, а не непрерывно. NAT и firewall могут блокировать probes. IDS может поднять тревогу. Отсутствие ответа смешивает политику безопасности, недоступность цели и состояние пути.

RFC 3568 полезен именно этим отказом от магии метрик. Документ опубликован в июле 2003 года как Informational и описывает отраслевые приемы, известные или использовавшиеся до конца 2000 года. Это не стандарт и не свидетельство современного развертывания.

До измерения DNS уже заменил клиента

Специализированный DNS может менять A, NS или CNAME по правилам и метрикам. Но запрос обычно не несет адрес клиента. Селектор видит DNS площадки клиента, а при рекурсии — другой сервер, действующий от его имени.

RTT до такого адреса характеризует путь к видимому resolver. Он не характеризует каждого клиента за ним. Общий resolver раздает одну адресную группу в течение TTL, поэтому flash crowd может сконцентрироваться на одном суррогате.

Короткий TTL ускоряет реакцию, но увеличивает число запросов; реализации не всегда его соблюдают. Ответ может оставаться действующим после устаревания измерений. Квитанция должна разделять клиента, локальный DNS и видимый рекурсор, а также связывать ответ со временем измерения, кандидатами, политикой, областью cache и сроком.

Дополнительный DNS — дополнительная власть

NS и CNAME распределяют выбор между несколькими серверами. NS ограничен структурой имени, добавляет задержку, может вызвать исключительные timeout и позволяет последнему DNS влиять на TTL процесса. CNAME переводит разрешение в новый домен и требует дополнительного обращения.

Финальный адрес не объясняет цепочку. Для каждого шага нужны вход, кандидаты, правило, выход и срок действия. Иначе распределенное решение остается без ответственных.

Anycast доставляет запрос ближайшему по маршрутизации DNS-селектору относительно resolver. Это выбор места принятия решения, а не доказательство лучшей доставки. Маршрутизация обычно не учитывает нагрузку сервера; routing-nearest не гарантирует минимальный delay и не описывает клиента.

Транспорт видит адрес, но делит путь

Первый пакет открывает IP клиента, порт и L4-протокол. Транспортный слой может уточнить грубый DNS-выбор. Способ передачи сессии RFC оставляет за рамками, поэтому запись «selected» не заменяет прием.

Прямой поток к новому суррогату может продолжать идти через первоначальный узел. Более крупный обратный поток может возвращаться напрямую. У выбора, запроса и ответа появляются разные маршруты.

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

Приложение видит объект ценой вмешательства

На прикладном уровне доступны URL, заголовки, cookies, язык и user-agent. Можно вернуть 302, перехватить и splice соединение или переписать встроенные URL.

Redirect добавляет круг и завершается только последующим запросом клиента. In-path элемент добавляет parsing и состояние в тракт. URL rewriting оставляет первый запрос на origin и сохраняет решение внутри страницы. Кэшированная страница может позже указывать на недоступный или уже плохой суррогат, поэтому срок решения должен быть коротким и явным.

TLS проводит границу полномочий. Без завершения TLS сеть контента не видит полный URL. Получение контекста означает ответственность за сертификат, ключи и доступ к содержанию. Более точный выбор одновременно расширяет власть селектора.

Метрики не взаимозаменяемы

RFC перечисляет RTT, hops, BGP, нагрузку и наличие контента. В DNS-сценарии близость обычно измеряется до локального resolver. Некоторые значения односторонние, тогда как пути асимметричны.

HTTP-probe суррогата не дает надежной реальной нагрузки; старая обратная связь может быть неточной. Агент на узле сообщает больше, но его личность, область и время также нужны. RFC отдельно предупреждает: BGP AS_PATH может быть бессмысленным как хорошая метрика выбора.

Каждое наблюдение должно хранить источник, цель, метод, направление, время, сырое значение и семантику отказа. Политика хранит версию, жесткие ограничения, веса и tie-break. Только так результат можно воспроизвести.

Граф квитанций

Сначала фиксируются видимый субъект, запрос, рекурсивная цепь, cache, кандидаты и наличие объекта. Затем метрики и policy связываются с выбором и сроком. После этого записываются DNS-ответ, redirect, rewrite, interception или handoff и владелец TLS-терминации.

Последние звенья — прием запроса суррогатом, его нагрузка в момент обслуживания, реальный путь, статус и объем, retry и результат приложения. DNS-ответ не равен соединению. Redirect не равен следованию. Переписанный URL не равен доставке. Выбор не равен приему.

Граница доказательств

Статья не называет CDN, оператора, resolver, клиента, origin, суррогат, поставщика, сессию, инцидент или измеренный выигрыш. RFC 3568 — исторический Informational-обзор.

RFC 3466 дает модель эпохи, RFC 3238 — границы посредников. RFC 2782, RFC 1546, RFC 1034, RFC 1035 и RFC 2181 дают DNS-контекст; RFC 3272, RFC 2386 и RFC 3221 — routing-контекст. RFC 7336 и RFC 8008 относятся к более позднему CDNI и не переносятся назад.

Эссе Heng Lu о Running-Code Primacy и Minimum Initial Specification — раскрытые редакционные линзы. Они поддерживают проверку работающей доставки и малую общую границу, но не доказывают намерение авторов RFC или результат эксплуатации.

Ограниченный вывод: probe измеряет взаимодействие с политикой и сетью одновременно. «Лучший» становится проверяемым лишь после указания наблюдателя, направления, свежести, кандидатов и подтвержденного результата.

Sources