Кратко

  • RFC 875 различил Internet-шлюз, сохраняющий общий IP-дейтаграммный объект, и шлюз-переводчик, которому приходилось сопоставлять несовместимые адреса, подтверждения, управление потоком и прикладные функции.
  • Завершая соединение с обеих сторон и храня соответствие между ними, посредник становился точкой сингулярности: отказоустойчивость, восстановление и каждое изменение протоколов требовали отдельного механизма.

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

В сентябре 1982 года M. A. Padlipsky опубликовал RFC 875 Gateways, Architectures, and Heffalumps. Документ не был стандартом реализации и не подсчитывал работающие системы перевода. Это была критика архитектурной метафоры: шлюз между двумя несовместимыми наборами протоколов нельзя считать просто более сложной разновидностью обычного Internet-шлюза.

Тонкий общий слой отделял адаптацию от перевода смысла

RFC 791 определил IP для взаимодействия пакетных сетей. Internet-адрес и фрагментация позволяли дейтаграмме проходить через сети с разным размером пакета и локальным оформлением. Надёжность, порядок и управление потоком от конца до конца IP намеренно не обещал.

Такое ограничение создавало ясную ответственность. Шлюз снимал локальный кадр, выбирал следующий переход по Internet-адресу и помещал тот же IP-дейтаграммный объект в оформление другой сети. Ему не требовалось изображать конечные точки TCP. RFC 791 прямо допускал отсутствие протоколов верхнего уровня в шлюзе.

RFC 793 разместил соединение, последовательность, повторную передачу, окна и срочные указания в TCP на узлах. Сетевой и транспортный уровни давали разные гарантии; участники могли установить, кому принадлежит каждая из них.

RFC 875 не отрицал разнородность. IP как раз соединял разнородные локальные сети. Критика отделяла различия под общим узким слоем от несовместимости выше него. Локальное оформление можно заменить, сохранив общий дейтаграммный объект. Гарантия, отсутствующая в одном протоколе, не возникает при переименовании поля.

В адресе NCP не было места для чужой сети

Интерфейс NCP указывал узел внутри адресного пространства ARPANET. IP-адрес включал сеть и узел. На обычной стороне NCP, следовательно, не было измерения, в котором пользователь мог выразить «этот узел в другой сети».

Переводчик мог найти свободные биты, изменить начальный обмен или поместить Internet-адрес в данные приложения. Все эти варианты меняли среду NCP, которую предполагалось оставить неизменной. Трудность состояла не в форме числа, а в области действия, которой не было в исходном контракте.

RFC 875 описал более явный выход. Посредник становился узлом, завершал первое соединение, спрашивал пользователя о внешнем назначении и открывал второе. Padlipsky назвал его «Janus Host». Для Telnet такой механизм мог быть полезен, однако это был видимый relay, а не прозрачное продолжение одного соединения.

RFC 801 показал подобную границу в плане перехода NCP/TCP. Пользователь Telnet входил в специальную учётную запись relay-узла и запускал вторую сессию. FTP перемещал файл дважды — к посреднику и от него. Для почты существовал отдельный способ. Каждое приложение открыто обслуживало две части пути вместо универсального перевода стеков.

Буфер не превращал локальный сигнал в сквозной факт

В NCP сигнал Ready for Next Message приходил от IMP назначения. При наличии переводчика им мог оказаться IMP рядом с переводчиком, а не конечный узел в чужой среде. Сигнал подтверждал событие у ближайшей границы.

Шлюз мог задержать ответ и накопить данные. Затем требовалось решить, какое событие на другой стороне разрешает продолжение: принятие локальной сетью, получение транспортом или чтение приложением? Если другой стек не сообщал нужный факт, объём буфера не мог его создать.

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

Срочные механизмы могли обращаться к разным исполнителям

NCP имел команду прерывания на управляющей линии. TCP предлагал Urgent внутри соединения, Telnet — Interrupt Process, другие семейства — ускоренные данные. Похожие названия не гарантировали одинакового адресата действия.

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

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

Padlipsky привёл ограниченный пример терминального шлюза University College London между ARPANET Telnet и X.25/X.28/X.29. По сообщению RFC 875 данные проходили, но из опций переносилось только эхо. Это не полная проверка системы. Пример устанавливает более узкое различие: перенос символов не доказывает сохранение словаря опций, управляющего их поведением.

Второй аппарат не знал частный разговор первого

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

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

Зависимость росла и при обновлениях. Перевод A–B не решал A–C. Изменение адресации, опции или приложения на одной стороне требовало проверки каждой связанной пары. Удобная граница постепенно принимала на себя циклы выпуска и неоднозначности обеих архитектур.

Более поздний IP-маршрутизатор тоже выполнял много адаптации

RFC 1009 позднее определил Internet-шлюз как маршрутизатор уровня IP. Он обрабатывал кадры, MTU, локальное отображение адресов, локальные сигналы потока и ошибок, буферы и выбор следующего перехода. Узкий контракт не означал простое устройство.

Между адаптациями сохранялась IP-дейтаграмма. Маршрутизатор не обещал воспроизводить подтверждение удалённого приложения или превращать команду одному интерпретатору в прерывание другого процесса. Общий объект имел чёткую границу.

Позднейшие посредники повторили вопрос в других условиях

RFC 2775 отметил, что трансляция адресов нарушает сквозную прозрачность адресов. Приложения, переносящие адреса внутри данных, требуют прикладных шлюзов или proxy; новое приложение может потребовать нового знания в посреднике.

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

RFC 4966 перевёл NAT-PT в Historic по конкретным причинам: встроенные адреса, расхождения IPv4/IPv6, состояние фрагментов, время жизни сопоставлений, масштаб DNS-ALG и концентрация отказа или атаки. Это не доказательство невозможности всякого перевода и не утверждение прямого происхождения от RFC 875. Документ вновь показывает, почему «изменить пакеты» недостаточно как спецификация.

Недостающий смысл должен иметь видимого автора

Каждую стрелку через посредника полезно заменить четырьмя вопросами: какое утверждение вошло, какое вышло, кто объявил их соответствующими и какое доказательство сохранится при отказе.

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

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

Источники