Кратко

  • Окно LZS размером 2 048 байт сбрасывалось перед каждой датаграммой у отправителя и перед каждым распаковыванием у получателя.
  • Обязательный flush не оставлял данные следующему пакету, а конечный маркер отделял код от заполнения; это не было доказательством доставки, целостности или авторства.
  • Около 90 байт и таблица Calgary Corpus были ограниченными измерениями, а не универсальным порогом или обещанием производительности.

Один пропуск не должен был разрушить словарь

LZS заменяет повторившиеся последовательности ссылками на скользящее окно. В надёжном потоке длинная память полезна. IP не обещает ни порядок, ни отсутствие потерь. Если второй пакет ссылается на словарь из первого, исчезновение первого делает второй неразрешимым, хотя его байты доставлены без ошибки.

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

Цена проявлялась на коротких пакетах и повторяющихся заголовках. Но профиль выбрал понятный радиус отказа. RFC 1967 и RFC 1974 показывают, что PPP-профили LZS могли управлять историями и восстановлением иначе. Название алгоритма не определяет срок жизни состояния.

Flush не был квитанцией доставки

Потоковый кодировщик способен удержать часть выхода в ожидании следующих байтов. RFC 2395 требовала flush при каждой передаче сжатой датаграммы: весь нынешний вход обязан оказаться в нынешнем выходе.

Это закрывало границу кодировщика, но не сети. Flush не доказывал прибытие, принятие, успешное распаковывание или работу приложения.

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

Согласованная трансформация могла не появиться в пакете

IPCOMP_LZS служил идентификатором в ISAKMP и при ручной настройке. Однако общая норма IPComp применялась к каждой датаграмме: если сжатый payload вместе с заголовком не меньше оригинала, отправляется оригинал без IPComp-заголовка.

RFC 3173 сохранила это правило, сменив RFC 2393. Поэтому отсутствие протокола 108 не доказывает провал согласования, а присутствие не доказывает успешное распаковывание. Ассоциация, выбор, формат и результат требуют разных свидетельств.

Сам LZS не содержал адаптивного теста сжимаемости. Реализация могла локально отказаться от бесполезных попыток, но это политика, а не общее поведение алгоритма.

У числа 90 был конкретный корпус

Неформальные опыты на Calgary Corpus указали на возможное расширение ниже примерно 90 байт. В приложении коэффициент рос с 1,18 при 64 байтах до 2,14 при 16 384. Большая датаграмма давала заново очищенному окну больше повторов и уменьшала долю постоянных затрат.

Но корпус не представлял зашифрованные данные, уже сжатые изображения или весь современный трафик. RFC 2394 описывала DEFLATE в своём контексте, RFC 3051 позже обсуждала сброс другого словаря, а RFC 3819 предупреждала о слабой пользе повторного сжатия шифротекста и уже сжатых данных. Девяносто байт — повод измерять, не поле протокола.

У внедрения была и лицензионная поверхность

Документ сообщал, что в 1998 году Hi/fn владела патентами LZS, и описывал варианты лицензирования. Это влияло на внедрение, не меняя формат. Запись историческая: она не доказывает сегодняшнего владельца, действительность, цену или доступность прав.

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

Забвение было формой устойчивости

RFC 2395 не потребовала от IP стать надёжным потоком ради лучшего коэффициента. Она подчинила память компрессора границе датаграммы.

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

Источники