Кратко

  • RFC 1553 позволял уменьшить 30-октетный заголовок IPX до одного–семи октетов, а совмещённый 36-октетный заголовок NCP/IPX — до одного–восьми. Пропущенные поля сохранялись в соответствующих слотах компрессора и декомпрессора.
  • Для общего IPX связка Confirmed Initial и Confirm устанавливала поколение слота до передачи зависящих от него сжатых пакетов. Узкое исключение NCP использовало последовательность и повторную передачу, чтобы обнаружить потерянный контекст без предварительного подтверждения.
  • Reject, обычная несжатая форма, распознавание перезапуска и требование явного слота после потери делали разногласие наблюдаемым. Без этих выходов короткий пакет мог бы выглядеть допустимым, пока две стороны восстанавливают из него разные заголовки.

Отказ был частью языка, а не концом разговора

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

Поэтому RFC 1553 определил Reject. Ответ сообщал компрессору, какой тип пакета или какое зависящее от типа средство декомпрессор не распознал. Важен не объём ответа, а граница полномочий: сторона не соглашалась на семантику только потому, что получила синтаксически возможные биты.

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

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

Исчезли повторы, но не сами поля

RFC 1553 вышел в декабре 1993 года как Standards Track; сейчас RFC Editor помечает его Historic. Документ назывался Compressing IPX Headers Over WAN Media, а механизм — CIPX. Эти статусы описывают место текста в истории стандартов, но сами по себе не доказывают внедрение или распространённость.

Стандарт задавал две стратегии. Общая схема для IPX могла сократить исходный заголовок длиной 30 октетов до одного–семи. Вторая обязательная схема работала с запросами и ответами NCP типов 0x2222 и 0x3333: совмещённый заголовок NCP/IPX длиной 36 октетов уменьшался до одного–восьми. Прочие типы NCP могли использовать общую компрессию IPX, но не автоматически специализированные допущения.

Слово «сократить» легко принять за уничтожение ненужного. Однако декомпрессор по-прежнему должен был передать следующему уровню полный заголовок. Поля не потеряли смысл; они перестали повторяться в каждом кадре и переехали в память двух машин.

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

После согласования CIPX даже обычный, фактически несжатый IPX-пакет нёс октет флагов CIPX. Сеанс уже находился внутри протокола с состоянием. Полная форма была предусмотренным способом продолжить или восстановить разговор, а не независимым пакетом, не связанным с его историей.

Две таблицы должны были переживать один и тот же порядок

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

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

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

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

Номер слота не был его личностью

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

RFC 1553 добавил однобайтовый ID. При назначении нового заголовка слоту ID увеличивался. Пара «слот плюс ID» обозначала поколение: не просто ячейку, а конкретную эпоху её содержимого.

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

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

Общему IPX требовалась подтверждённая отправная точка

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

Confirmed Initial переносил полный заголовок, номер слота и ID поколения. Получатель отвечал Confirm. Лишь после этого компрессор мог посылать последующие сжатые пакеты, зависящие от установленной связи. Локальная память становилась общей опорой после наблюдаемого действия стороны, которая будет по ней восстанавливать данные.

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

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

NCP получил исключение из-за наблюдаемого поведения

Для специализированных запросов и ответов NCP допускался Unconfirmed Initial. Компрессор мог отправить первоначальный полный контекст и сразу продолжить сжатую передачу, не дожидаясь Confirm. Это было не общее доверие к неподтверждённой памяти.

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

Отсюда следует ограничение на перенос решения. Ускорение принадлежало свойствам NCP, а не слову «unconfirmed». Трафик без такой же последовательности и механизма восстановления не получал тех же оснований пропустить подтверждение.

Это также разделяло источники доверия. В общем IPX им служила связка Initial/Confirm. В NCP часть обнаружения разрыва находилась в поведении протокола запрос–ответ. Журнал должен показывать, какой именно источник применялся; общий признак «контекст есть» скрывает существенную разницу.

Ещё один сэкономленный октет потребовал полной видимости потерь

Можно было убрать и номер слота. Тогда пакет означал: «используй тот же слот, что и предыдущий». При безошибочной последовательности обе стороны одинаково понимали слово «предыдущий».

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

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

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

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

Перезапуск отзывал право старой таблицы на толкование

Одна сторона могла перезапуститься, потерять таблицу и вернуться к обычному IPX. Другая сторона продолжала хранить старый CIPX-контекст. В традиционном IPX заголовок мог начинаться с checksum 0xFFFF, когда контрольная сумма не использовалась. Этот рисунок приходил туда, где партнёр ещё ожидал октет флагов.

Значение 0xFF было зарезервировано так, чтобы различить обычное начало IPX и пространство CIPX. Получившая сторона должна была распознать возврат к обычному формату и заново согласовать компрессию, а не применять таблицу из сеанса, которого у партнёра больше не существовало.

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

Reject защищал границу будущих расширений

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

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

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

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

PPP и IPX-WAN по-разному оформляли согласие

В PPP механизм договаривался через опцию IPXCP. По умолчанию компрессия была выключена. Каждая сторона запрашивала способность принимать сжатые пакеты в своём направлении, поэтому двусторонний режим требовал двух направленных запросов. Доказательство A→B не было доказательством B→A.

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

У чека переговоров поэтому две формы. Для PPP требуется сохранить направление и заявку каждой стороны. Для IPX-WAN — процесс выбора общего подмножества и симметричный предел слотов. Единственный флаг «CIPX enabled» уничтожает различие, которое определяло действительные возможности линии.

Два к одному было сценарием, а не полевым итогом

RFC приводил вероятное отношение около 2:1 на примере 26 октетов данных, 30 октетов исходного заголовка и двух октетов сжатого заголовка. Было 56, стало 28. Это корректная иллюстрация экономии при данных предположениях.

Она не была измерением развёрнутого сервиса. В ней нет распределения размеров пакетов, частоты полных Initial, Confirm, Reject и обычной формы, уровня потерь, числа отбрасываний до явного слота, затрат процессора, задержки восстановления или повторов приложения. Даже доставленный очень короткий пакет может не принести пользы, если контекст после потери нельзя безопасно применить.

Так же узко следует читать раздел безопасности. RFC говорил, что CIPX существенно не меняет базовую безопасность IPX. Это оценка границ документа 1993 года, а не современная гарантия для всех реализаций, повреждённых входов, сочетаний уровней или последующих сред.

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

Короткому заголовку нужен длинный чек

Достаточная запись начинается с владельца переговоров и направления, выбранных опций и числа слотов. Затем нужны назначивший слот компонент, ID поколения, полный Initial, обязательный Confirm или строго ограниченный NCP-механизм, а также видимость ошибок канала.

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

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

Источники