Кратко

  • RFC 2391 поместила пул за виртуальным адресом: LSNAT выбирал сервер для новой сессии и фиксировал параметры трансляции всех её следующих пакетов.
  • Круговой выбор, число сессий, трафик, веса, стоимость маршрута и проверка живости были приближениями для решения, а не доказательством прикладной мощности.
  • Исключение мёртвого узла останавливало новые назначения, но не спасало прежние: выбор, устойчивое соответствие, переключение и результат оставались разными свидетельствами.

Видимый адрес и невидимый диспетчер

Клиент видел один сервисный адрес. Оператор видел несколько машин, которые можно добавлять, заменять и выводить из эксплуатации. RFC 2391 соединила эти картины, не требуя менять программы на концах.

Механизм объединил NAT из RFC 1631 с алгоритмом распределения. При начале сессии LSNAT выбирал участника пула и перенаправлял пакет. Виртуальный адрес мог означать один сервер или множество; распределение можно было ограничить отдельными службами.

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

Это не повторение anycast из RFC 1546. В anycast одна служебная адресация может маршрутизироваться к разным экземплярам. В RFC 2391 посредник запоминал решение. Собственный вопрос документа — как сохранённая связь начинает управлять всей сессией.

Решение для первого пакета стало правилом для остальных

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

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

Запросы и ответы должны были проходить через тот же LSNAT. Асимметричный ответ обошёл бы нужную трансляцию. Другой транслятор без таблицы не знал бы выбранный узел и портовое соответствие.

Ограничение сформулировано прямо: назначенную хосту сессию нельзя передвинуть до её окончания. Алгоритм распределял новые начала. Он не переносил состояние транспорта, прикладной контекст или незавершённую операцию.

Нагрузка имела несколько несовместимых заменителей

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

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

Пакеты и байты отражали трафик, видимый LSNAT. RFC называла это приближением системной нагрузки. Малое сообщение может запустить дорогой расчёт; крупная передача может дешёво выйти из кэша.

Веса позволяли оператору оценить стоимость типов сессий и относительную мощность серверов. Предположения становились явными и настраиваемыми, но не превращались в текущие измерения.

Серверы могли активно сообщать свободные ресурсы. Такой сигнал возникал ближе к источнику, зато появлялись время измерения, задержка доставки, единая семантика и устаревание. RFC признавала: точно знать неиспользованную мощность удалённой системы в реальном времени трудно.

Селектор обладал моделью, достаточной для следующего выбора. Он не обладал объективной истиной о мощности и не выдавал гарантию результата.

Маршрут отвечал на другой вопрос

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

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

Здесь проходит граница с материалом о RFC 2386. Там карта QoS-ресурсов не равна допуску, резервированию и доставке. В RFC 2391 частичный сигнал использовался для собственного механизма — создания привязки, которую потом нельзя переместить.

Полная цепочка выглядела так: виртуальный адрес, состав пула, сигнал нагрузки или пути, правило выбора, привязка, двусторонняя трансляция, ответ сервера, прикладной результат. Раннее звено не могло подписать квитанцию за позднее.

Мёртвый узел убирали только из будущего

Назначать новые сессии молчащему серверу означало создавать чёрную дыру. RFC 2391 предложила эвристики: периодический ping или наблюдение, отвечает ли узел датаграммами после нового назначения. Если ответа несколько секунд нет, сервер можно объявить мёртвым и прекратить новые назначения.

Возврат тоже был экспериментом. После паузы серверу снова давали новые сессии и смотрели на время ответа. «Жив» означало временный локальный вывод по выбранному сигналу и порогу.

Ответ ping не доказывал готовность приложения и его зависимостей. Отсутствие ответа не указывало однозначно на хост, путь, процесс или запрос. Политике приходилось действовать, не преувеличивая доказательство.

Из двух утверждений RFC следует важный вывод. Детектор прекращает новые назначения. Уже назначенная сессия не может сменить хост до конца. Значит, правило предотвращает следующий неудачный выбор, но не мигрирует существующие разговоры.

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

RFC 3022 позже показала ту же зависимость при отказе NAT: перевод потока на другой транслятор мог разрушить его, если устройства не делились конфигурацией и состоянием. RFC 3234 отделила failover с копией состояния от restart. Запасное устройство не равно подготовленному продолжению.

Конец разговора тоже приходилось угадывать

Привязки нужно освобождать. TCP даёт FIN и RST, но перезапуск узла или потеря пакета может скрыть завершение. У UDP нет общего сигнала конца. Законная пауза и исчезнувший собеседник выглядят одинаково.

Тайм-аут превращал молчание в решение. Слишком короткий удалял живое соответствие. Слишком длинный удерживал мёртвые записи и занимал порты. RFC 2663 позже пояснила, что сессия глазами NAT может не совпадать с сессией приложения и что долгий простой нельзя в общем случае отличить от исчезновения.

RFC 4787 установила минимумы и рекомендации для UDP-отображений, одновременно зафиксировав большое разнообразие таймеров и способов обновления. Общие границы улучшали совместимость, но не раскрывали смысл тишины.

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

LS-NAPT обменял свободу размещения на дополнительную зависимость

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

Цена состояла в большем числе преобразований и большей сложности. Описанная схема ограничивалась TCP и UDP. Доступное пространство клиентских портов задавало потолок одновременных сессий. Ограничение места превратилось в ограничения таблицы, портов и обработки.

Такова исходная сделка NAT. RFC 1631 подчёркивала внедрение без изменения хостов, но отмечала потерю сквозного смысла IP-адреса и рост сетевого состояния. LSNAT использовал именно это свойство, чтобы скрыть выбор сервера.

RFC 7098 позже назвала удержание сессии на одном сервере persistence. Термин объясняет таблицу RFC 2391. Он же напоминает границу: сохранить выбор не значит уметь заменить его без потери разговора.

Один адрес, восемь разных свидетельств

Виртуальный адрес доказывал вход. Конфигурация — кандидатов. Метрика — ограниченное наблюдение. Политика — правило. Привязка — сделанный выбор. Трансляция — работающий путь. Ответ сервера — часть исполнения. Только прикладной результат закрывал намерение пользователя.

У каждого слоя свой владелец. Оператор управляет пулом. Селектор истолковывает сигналы. LSNAT хранит соответствие. Сервер знает реальные ресурсы. Концы наблюдают эффект. Ни один не может честно расписаться за всех.

Заметки Heng Lu отделяют спецификацию и реестр от живой реальности: минимальная общая основа должна оставить будущие решения локальными, а доказательство приходит от работающей реализации и наблюдаемого принятия. RFC 2391 следует этой дисциплине, даже создавая очень простую поверхность для клиента.

Свободный сервер действительно существовал. Но для уже связанной сессии он не был продолжением. Распределение сделало взаимозаменяемыми новые входы, а не их историю.

Источники