Кратко

  • RFC 1055 определяет SLIP как узкое соглашение о кадрировании IP-датаграмм на последовательной линии: END завершает кадр, а ESC не даёт двум значениям данных притвориться структурой.
  • END перед следующим пакетом создаёт на чистой линии пустой отброшенный кадр, но после помехи отделяет неопределённый остаток буфера от нового датаграмма.
  • Найти границу, установить целостность байтов и выровнять декодер, зависящий от предшествующего состояния, — разные задачи. RFC 1144 и RFC 1662 помогают не смешивать их.

Формат, который не изображал полноту

Сильная сторона RFC 1055 — его прямота. Документ 1988 года называет Serial Line IP фактическим соглашением для точечных последовательных TCP/IP-соединений, но не Internet Standard. Ещё важнее формула: SLIP — это лишь протокол кадрирования пакетов; он задаёт последовательность символов, обрамляющую IP-пакеты на последовательной линии, и ничего больше.

Это «ничего больше» — не извинение, а граница обязанностей. SLIP не сообщает адреса, не имеет поля типа пакета, не обнаруживает и не исправляет ошибки, не сжимает данные. Адреса IP два конца должны знать иным способом. Линия не может различать TCP/IP и другой протокол по полю SLIP, поскольку такого поля нет. А набор байтов между разделителями не становится целым только потому, что разделитель был замечен.

Задним числом легко назвать SLIP недоделанным PPP. Но тогда исчезает точный исторический выбор. На медленной линии двум реализациям требовалось минимальное общее правило: где в непрерывном потоке заканчивается один IP-датаграмм. Ещё требовалось не дать двум значениям полезной нагрузки выглядеть как ответ на этот вопрос. Никакой власти над адресацией, достоверностью среды или смыслом пакета из этого не следовало.

Для этой работы RFC 1055 резервирует END — восьмеричное 0300, десятичное 192 — и ESC — восьмеричное 0333, десятичное 219. Если в данных встречается END, отправитель посылает ESC и 0334; если ESC — ESC и 0335. После защищённых таким образом байтов он посылает END. Получатель в рамках грамматики SLIP обращает два преобразования и считает END концом кадра.

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

Завершить ещё раз, прежде чем начать

Предложение Phil Karn делает эту малую грамматику особенно выразительной. RFC 1055 советует начинать пакет также с END, чтобы вымыть из приёмника ошибочные байты, которые могли накопиться из-за шума на линии.

На спокойной линии это выглядит как сознательная избыточность. END, закрывший предшествующий пакет, стоит рядом с END, предваряющим новый. Документ не скрывает цену: возникает пустой или плохой IP-пакет, который будет отброшен; приведённая функция приёма сразу игнорирует END, если до него не было данных. Пустой кадр — не замаскированная ошибка, а видимая плата за чистую точку отсчёта.

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

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

Пример кода в RFC 1055 остаётся в этих пределах. Он возвращает пакет, только если END приходит после хотя бы одного байта данных; пустые случаи от двух END он пропускает. После ESC он восстанавливает END или ESC лишь при одном из двух ожидаемых продолжений. Иное продолжение названо нарушением протокола, а байт сохраняется как есть. Перед нами не общий судья валидности, а маленький читатель границы и двух защищённых значений.

Граница кадра не возвращает память

RFC 1144 о сжатии заголовков TCP/IP для медленных последовательных линий показывает, почему этого разграничения нельзя избегать. В его схеме IP-пакет проходит через compressor, а затем через framer. Компрессор хранит для соединений на последовательной линии предыдущие заголовки; сжатый пакет может нести изменения относительно этой памяти.

Следовательно, получатель способен корректно выделить байтовую последовательность по END и всё же не иметь двух существенных вещей: доказательства, что последовательность не повреждена, и предшествующего состояния, которое предполагает отправитель. RFC 1144 относит обнаружение ошибок к уровню framing и говорит, что decompressor должен получить сигнал об ошибке, чтобы отбросить плохой пакет и не распространить ошибку состояния. Начальный END SLIP такого сигнала не даёт. Для этого он и не предназначался.

Нужно отдельно спрашивать: где начинается и кончается кадр? Целы ли байты в нём? Совместима ли история состояния у потребителя, который зависит от прошлого? Разделитель отвечает только на первый вопрос. Checksum или FCS могут участвовать во втором. Сброс или явная синхронизация контекста нужны для третьего. Общее слово «восстановление» не заменяет ни одного из этих свидетельств.

RFC 1662 даёт позднее, но строго ограниченное сравнение. HDLC-подобное кадрирование PPP задаёт Flag Sequence для начала или конца, прозрачность октетов, FCS и обработку недопустимых кадров. Оно также предупреждает: сэкономить октет, используя закрывающий флаг как открывающий следующий, можно ценой надёжности после простоя; без нового открывающего флага шумовые символы могут присоединиться к следующему кадру. PPP не является приговором SLIP. Это более широкий договор, где граница, проверка и отбрасывание названы раздельно.

Полномочие маркера должно закончиться на его границе

Notes 64 и 65 Heng Lu дают подходящую дисциплину чтения: сначала определить наименьшую детерминированную функцию, которую работающий код способен проверить локально, и не раздувать её до общей власти. END в SLIP может завершить старое накопление и начать новое чтение. ESC может защитить два значения. Ни один из них не способен засвидетельствовать последующее содержимое или вернуть состояние иной подсистемы.

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

Источники и границы доказательств

Закрытый набор источников — RFC 1055, RFC 1144 и RFC 1662. Он подтверждает грамматику END/ESC, смысл начального END, явно отсутствующие возможности SLIP, разделение compressor/framer и ограниченное сопоставление с PPP. Он не подтверждает всеобщее использование SLIP, поведение современных устройств, измеренную частоту шума, результат безопасности или применение RFC 1144 на каждой линии SLIP.