Кратко

  • Перемещение переменных заголовков в конец пакета канального уровня облегчало выравнивание данных по страницам памяти, но заставляло ждать полного приёма перед обработкой этих заголовков.
  • Выигрыш зависел от архитектуры получателя. Формат не менял смысл потока TCP и не обещал отсутствие копирования на любом оборудовании.
  • Для применения требовалось подтверждение поддержки обоими участниками канала. RFC 1122 предписывал отключать возможность по умолчанию, если нет динамического согласования для каждого адресата.

Раннее решение тоже было ресурсом

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

RFC 893, опубликованный в апреле 1984 года, признавал задержку распознавания типа обоснованным возражением против trailer-инкапсуляции. Авторы отвечали, что в рассматриваемом ими случае DMA весь пакет и так сначала поступал в память, а обработка начиналась позднее.

Это ответ для определённого пути приёма, а не закон для всех контроллеров с DMA. В другой реализации возможность раннего анализа могла иметь собственную ценность. Поэтому обсуждение нельзя свести к лозунгу о том, что меньше копий всегда означает лучший сетевой формат.

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

Копирование после передачи

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

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

Переменные заголовки мешают такому размещению. Префикс канального уровня может быть фиксированным, но длина следующих за ним заголовков IP, TCP или других протоколов меняется. В результате начало полезных данных смещается. Копия ради нового выравнивания может поглотить ожидаемую экономию.

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

Документ описывал формат, применявшийся тогда в 4.2BSD UNIX и других системах. Он был информационным и прямо не объявлялся официальным протоколом ARPA Internet. Упомянутый пример VAX с 512 байтами данных относится к исторической архитектуре, а не устанавливает размеры страниц современных машин.

Хвост не был вторым пакетом

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

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

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

Это отличалось от базового варианта IP поверх Ethernet, описанного в RFC 894 в том же апреле 1984 года. Там данные IP непосредственно следуют за заголовком IP. Умение принимать такую форму не даёт автоматически умения найти заголовок в хвосте другой формы.

Перестановка не увеличивает и допустимую ёмкость кадра. Техническая поправка 570, имеющая статус Verified, исправляет в RFC 894 слово «минимальный» на «максимальный» применительно к 1500 байтам. Дополнение до минимальной длины данных Ethernet, в свою очередь, не входит в общую длину IP. Границы страницы, заполнение и предел канала относятся к разным ограничениям.

Четыре условия и одна потерянная возможность

RFC 893 ставил экономию в зависимость от нескольких предпосылок. Получатель должен быть способен и согласен работать с форматом. Затраты на выравнивание не должны превосходить сбережённую работу. Перенесённые заголовки должны быть сравнительно малы, а устранённое копирование — достаточно дорого, чтобы оправдать усложнение программы.

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

К этому добавлялось ожидание полного пакета. Реализация, умеющая рано отвергать ненужное или выбирать буфер по заголовку, могла лишиться преимущества. Аргумент о DMA из исторического текста объяснял, почему авторы считали цену приемлемой в своём случае, но не устранял различия между получателями.

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

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

Согласие было частью совместимости

RFC 894 разрешал использовать trailers между согласными системами на одной Ethernet. Ни один узел не был обязан реализовать этот вариант. Отправителю требовалось положительное знание о том, что адресат умеет его интерпретировать.

В описаниях 1984 года выбор 4.2BSD делался при загрузке для интерфейса в целом: использовать такой формат либо не отправлять его через этот интерфейс. Участники общей среды должны были подходящим образом сотрудничать. Согласование с отдельными соседями через расширение ARP упоминалось как рассматриваемое или ожидаемое улучшение.

В октябре 1989 года RFC 1122, раздел 2.3.1, задавал более точную границу. Возможность оставалась необязательной, но поддержка обоими участниками канального обмена — хостом или шлюзом — должна была быть проверена. Без динамического согласования по адресатам конфигурация по умолчанию должна была отключать trailers.

Эти документы показывают переход в описанных правилах от общей предпосылки к знанию об отдельном партнёре. Они не устанавливают дату первой поставки для всех реализаций и не доказывают, что все версии BSD до 1989 года работали одинаково.

Что ARP выяснял, а чего не выяснял

RFC 826 описывает сопоставление протокольного адреса с аппаратным адресом на выбранном канале. Сначала определяется следующий переход и подходящий канал. Успешное разрешение адреса само по себе не сертифицирует все дополнительные способы оформления пакетов.

У ARP также нужно различать внешний тип Ethernet, обозначающий перенос ARP, поле протокола внутри сообщения и код операции запроса или ответа. Смешение этих значений приводит к неверному представлению о согласовании.

В варианте RFC 1122 обычный обмен IP ARP завершался обычным образом. Желающая принимать trailers сторона посылала дополнительный ответ Trailer ARP. Он использовал обычную структуру ответа, но обозначал trailer-протокол внутри ARP. Это не замена базового IP-ответа и не требование сначала отправить специальный запрос для trailers.

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

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

Область действия оставалась локальной. RFC 1009, опубликованный в июне 1987 года, объясняет, что шлюз при proxy ARP может отвечать адресом своего интерфейса за достижимый адрес вне канала. Поэтому известный канальный партнёр может отличаться от конечного адресата. Его способность нельзя приписывать всему маршруту.

Почему не на каждый ответ нужен ещё один

Дополнительное объявление могло породить нежелательную последовательность. Некорректно работающий узел способен ответить на Trailer ARP обычным IP ARP-ответом. Если другая сторона на каждый такой ответ снова объявляет способность принимать trailers, сообщения могут поддерживать друг друга.

RFC 1122 ограничивал этот случай наличием незавершённого запроса. Дополнительный ответ после IP-ответа допустим, когда тот действительно разрешает ожидавшийся запрос: аппаратный адрес до обработки ещё не был известен. Объявление вместе с обычным ответом на полученный запрос — отдельная разрешённая ветвь.

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

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

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