Кратко

  • RFC 3153 позволял приёмнику PPP предложить в одном направлении приём мультиплексированных кадров. Успешный обмен PPPMuxCP разрешал передатчику использовать формат, но не обязывал его отправить хотя бы один такой кадр.
  • Согласованный PID по умолчанию задавал правило восстановления опущенного идентификатора протокола. Он не доказывал, что передатчик сбросил PFF, удалил поле или сэкономил байт.
  • Реальная польза зависела от отправленных подкадров, состава трафика, времени в очереди, MRU и ограничений размера, ошибок и порядка слоёв. Возможность, использование на линии, восстановление пакета и результат приложения требуют отдельных квитанций.

Договор касался конвертов, а не содержимого

У маленьких пакетов служебное обрамление может занимать непропорционально большую долю. PPP в HDLC-подобном кадрировании окружает каждый пакет материалом канального уровня, полем протокола и контрольной последовательностью кадра. Некоторые поля можно отдельно согласовать для удаления или сжатия, однако каждый самостоятельно инкапсулированный пакет всё равно платит свою цену. При переносе PPP через туннель вроде L2TP повторяющиеся накладные расходы могут стать ещё заметнее.

Предложение RFC 3153 было прямым: поместить несколько PPP-пакетов в один внешний PPP-кадр. Компактный разделитель перед каждым подкадром сообщает, присутствует ли идентификатор протокола и сколько байтов относится к этому подкадру. Один внешний кадр способен нести данные, которые иначе потребовали бы нескольких полных оболочек.

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

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

Приёмник предложил язык, а передатчик выбирал, говорить ли на нём

PPPMuxCP служит протоколом управления этой возможностью. На фазе протоколов сетевого управления приёмник может объявить, что будет принимать мультиплексированные PPP-кадры. Без такого предложения партнёр не вправе передавать их. Готовность к приёму согласуется независимо в каждом направлении, поэтому успех для одной стороны ничего не говорит об обратном пути.

Главное ограничение состоит в другом: успешное согласование не принуждает к передаче. RFC отдельно говорит, что после согласования PPPMuxCP партнёр не обязан отправлять мультиплексированные кадры. Передатчик может сам выбирать, какие PPP-кадры объединять, а подходящие пакеты вправе посылать отдельно.

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

Надёжный аудит сохраняет направление. Он фиксирует, кто предложил приём, какие Configure-сообщения были подтверждены, когда состояние стало пригодным для работы и появились ли затем в этом направлении кадры со значением протокола PPP Multiplexed Frame. Разрешение плоскости управления и действие плоскости данных — связанные свидетельства, но не синонимы.

PID по умолчанию ничего не экономил, пока бит действительно не был сброшен

Каждое согласование PPPMuxCP включает идентификатор протокола по умолчанию. Приёмник предлагает значение, которое он подставит, если первый подкадр не содержит собственного поля протокола. Когда первый пакет использует этот протокол, передатчик может сбросить Protocol Field Flag, PFF, и опустить один или два байта с учётом обычного сжатия поля протокола PPP.

Ключевое слово здесь — «может». Передатчик не обязан удалять поле даже тогда, когда значение по умолчанию это допускает. Согласие о числе создаёт правило реконструкции; оно не доказывает, что PFF был равен нулю, поле отсутствовало, а ожидаемая экономия состоялась.

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

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

Поле длины превращало эффективность в ограниченное локальное решение

Разделитель содержит также LXT и LEN. LXT выбирает одно- или двухбайтовое поле длины, а остальные биты описывают размер подкадра. Пример передатчика в RFC 3153 использует настраиваемую максимальную длину подкадра MAX_SF_LEN и не принимает кандидатов крупнее этого предела. Он также останавливается до того, как полный агрегат превысит MRU, согласованный через LCP.

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

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

MRU — жёсткий потолок, а не рекомендация оптимального размера. MAX_SF_LEN — условие допуска, а не измеренный оптимум. Таймер — локальная политика, а не часть предложения приёмника. Для каждого из этих фактов нужна своя квитанция.

Демультиплексор должен был восстановить пакеты, не меняя их порядок

Получив внешний кадр со значением протокола 0x0059, декодер проходит подкадры по порядку. Он читает длину, получает или восстанавливает идентификатор протокола и передаёт восстановленный пакет обычной обработке PPP. Если длина требует больше данных, чем осталось, последний подкадр отбрасывается; ошибочное значение могло возникнуть в нём самом либо раньше по ходу разбора.

Формат нельзя вкладывать сам в себя. Кадры LCP нельзя помещать внутрь мультиплексированных кадров. А смешивание отдельных и мультиплексированных пакетов не даёт права менять последовательность: RFC говорит, что ни передатчик, ни приёмник не должны переупорядочивать пакеты из-за выбранного контейнера.

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

Само восстановление ещё не является доставкой приложению. Декодер способен выдать синтаксически корректный PPP-пакет, который следующий слой отбросит, задержит или преобразует. Канальную квитанцию надо соединить с нижестоящим наблюдением, а не объявлять результатом из конца в конец.

Порядок слоёв был частью протокола, а не примечанием реализации

PPPMux не существовал изолированно. При использовании Multilink PPP возможность согласуется для всего пучка, а не отдельно на каждом входящем в него канале. При передаче мультиплексирование выполняется до инкапсуляции Multilink, поэтому заголовок MP располагается снаружи PPPMux. Сам кадр Multilink нельзя включать как мультиплексированный подкадр.

Управление сжатием и шифрованием добавляет ещё одно правило порядка. PPP-мультиплексирование работает после CCP или ECP уровня пучка, но до MP и любого CCP или ECP отдельного канала. Реализация, неспособная расположить PPPMux выше поканального варианта, должна отклонить такой протокол отдельного канала после согласования мультиплексирования.

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

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

«Нет дополнительных соображений безопасности» не было свойством безопасности

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

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

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

Разрешение было общим минимумом; польза оставалась локальной и измеримой

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

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

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

Долгосрочный урок не в том, что мультиплексирование всегда побеждает. Протокол может сделать оптимизацию возможной, не утверждая, что она уже произошла. RFC 3153 дал приёмнику способ сказать: «Я это понимаю». Ответы «Использовали ли вы это?» и «Помогло ли это?» он оставил передатчику и свидетельствам.

Источники