Кратко

  • RFC 3074 позволяла сотрудничающим DHCP-серверам самостоятельно принимать одинаковое решение по идентификатору клиента и заранее настроенной карте из 256 бакетов.
  • Хеш распределял право ответить, а не измеренную работу. Пустой бакет мог означать молчание; отсроченный ответ не доказывал выдачу аренды.

Распределение ответов — не измеритель нагрузки

DHCP-широковещание может одновременно достичь нескольких серверов. RFC 3074 в 2001 году предложила сократить дублирующие ответы без изменений на клиентах: каждый сервер вычисляет один и тот же хеш для транзакции обслуживания и отвечает, только если результат входит в его Hash Bucket Assignment (HBA).

Если есть опция Client Identifier, используется она. Иначе входом служат длина аппаратного адреса и сам адрес клиента, но не более первых 16 байтов. Хеш Пирсона отображает вход в одно из 256 значений. Битовая карта длиной 32 октета назначает бакеты серверу; BOOTP-ретранслятор может сопоставить диапазоны с идентификаторами серверов и выборочно пересылать запросы.

Так первоначальная настройка заменила постоянные переговоры. Сначала алгоритм задумывался как оптимизация проекта DHCP Failover, который тогда ещё разрабатывался; позже его расширили на сотрудничающие серверы и BOOTP-ретрансляторы. Обещанная экономия была конкретной: не обмениваться сообщениями на каждый запрос и не менять поведение клиентов.

Но заданный процент не был показателем загрузки процессора, давления на пул адресов, времени ответа или успешных выдач. RFC предупреждает: в короткие периоды фактическая доля может отличаться от цели, а с ростом числа запросов приближаться к настройке. Речь идёт о распределении клиентских транзакций во времени, а не о равной стоимости каждой транзакции или одинаковом объёме работы серверов.

Бакет без владельца мог означать тишину

Главная граница — в битовой карте, а не в формуле. RFC 3074 говорит, что транзакция с неназначенным значением может быть полностью проигнорирована; в некоторых сценариях это может быть желаемым поведением. Значит, молчание могло быть следствием политики конфигурации, а не только потерей пакета.

Необязательный параметр Delayed Service позволял серверу, который обычно не обслуживал этот запрос, ответить после ожидания. Это обход через таймер, но не текущий кворум и не доказательство отказа назначенного сервера. RFC также оставляет реализациям вопрос, как поступить, если выбранный сервер недоступен или у него нет подходящих адресов.

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

Datatracker по-прежнему указывает RFC 3074 как Proposed Standard IETF. Это статус документа, а не свидетельство современного внедрения. RFC 8156, опубликованная в 2017 году, определяет DHCPv6 failover и передачу аренд после отказа сервера или разделения сети. Это ограниченное сравнение, а не доказательство обновления или развёртывания RFC 3074.

Более поздняя заметка Хенга Лу о «слоях реальности» здесь служит лишь редакционной оптикой, а не источником сведений о DHCP: написанное правило, настройку оператора, наблюдаемое исполнение и результат клиента следует рассматривать отдельно. Исторический вклад RFC 3074 точен: она сделала право ответа вычислимым, но не сделала успех услуги самодоказывающимся.

Источники