Кратко

  • Флаг SO в RFC 916 означал нагрузку ровно в один октет. Поле LENGTH уже не должно было повторять длину, поэтому в нём размещался сам символ, защищённый контрольной суммой заголовка.
  • В SYN та же позиция объявляла Maximum Data Length приёмника, в обычном пакете считала последующие данные, а при SO становилась данными. Право на толкование давали проверенные флаги и допустимое состояние соединения.
  • По одному биту для номера последовательности и подтверждения хватало лишь потому, что в каждом направлении ожидал ответа не более чем один пакет. Ограничение состояния одновременно ограничивало пропускную способность.

RFC 916, опубликованный в октябре 1984 года, предложил Reliable Asynchronous Transfer Protocol — RATP. Его обычной средой мыслилась полнодуплексная линия точка-точка, чаще всего асинхронная RS-232, между небольшими компьютерами, модемами или устройствами, принимающими команды. Нынешняя карточка RFC Editor относит документ к Historic. Это современный архивный статус, а не статистика прежнего внедрения.

Приоритеты были названы прямо: сначала надёжность, затем простота реализации. Динамическое окно и несколько одновременно неподтверждённых пакетов исключили. Если удалённая сторона закрывала соединение, ещё не отправленные данные из очереди отбрасывались; по словам документа, это устраняло два состояния. RATP не пытался быть полным TCP для маленького провода. Он сужал задачу, чтобы сузить автомат.

Сначала нужно было найти достоверное начало

Обычный заголовок RATP занимал четыре октета: шестнадцатеричный лидер синхронизации 01, управление, длину данных и контрольную сумму заголовка. RS-232 обрамлял отдельные октеты, но не целые пакеты. Помеха могла добавить данные или случайно воспроизвести 01.

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

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

Третий октет имел три разных назначения

В пакете SYN третья позиция была Maximum Data Length, MDL. Отправитель SYN сообщал, сколько данных он готов принять в одном входящем пакете. При трёхстороннем открытии каждое окончание соединения объявляло собственный предел.

После установления соединения, если SYN, RST и FIN отсутствовали, позиция называлась LENGTH. При снятом SO она показывала число последующих октетов от нуля до MDL партнёра. При установленном SO она переставала быть числом и содержала единственный октет данных.

Значение не объясняло себя. Число 65 могло быть приёмным пределом, длиной последующих 65 октетов или одним символом. Требовалось найти синхронизацию, проверить управление, позицию и сумму, а затем убедиться, что сочетание флагов допустимо в текущем состоянии. Лишь эта последовательность давала однозначный смысл.

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

Сторона могла объявить MDL нулём, если не желала получать данные, разрешая односторонний режим. Для обмена обе стороны не могли выбрать ноль. Протокол задавал форму и последствие, но не назначал устройству его вместимость.

Один символ раньше требовал семи октетов

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

Флаг SO, Single Octet, описывал точно этот случай. Когда SO стоял, а SYN, RST и FIN были сняты, длина один уже была известна. RFC 916 помещал символ в освободившееся LENGTH, не передавал отдельную часть данных и её сумму, а защищал символ суммой заголовка. Документ назвал сокращение с семи октетов до четырёх повышением эффективности на 40 процентов.

Это не было универсальным сжатием. Три октета исчезли, потому что другие инварианты уже исполняли их работу: флаг задавал длину, фиксированная позиция несла данные, сумма заголовка ограниченно обнаруживала повреждение. Два символа под это правило не подпадали, подтверждение и состояние соединения не исчезали.

Одного бита хватало, пока не возникал второй вопрос

Поля SN и AN имели ширину по одному биту. Причина заключалась не в общей достаточности двух номеров, а в правиле RATP: в заданном направлении отправлялся или подтверждался не более чем один требующий ответа пакет.

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

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

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

Конечный размер выбирал приёмник

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

Практический предел мог быть меньше. На него влияли ОС, драйвер, память, скорость и символы внешнего управления потоком. Если длинные серии часто вызывали такую вставку на заданной скорости, RFC 916 советовал объявлять меньший максимум, чтобы хотя бы часть пакетов проходила без вмешательства.

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

Пакет мог закончиться раньше записи

Объект верхнего уровня мог превосходить MDL и разбиваться. Флаг EOR сообщал, что в данном RATP-пакете заканчивается верхняя запись; устанавливать его должна была верхняя сторона интерфейса. Полностью полученный и подтверждённый пакет мог оставаться фрагментом незавершённого объекта.

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

Позднейшая RFC 1055 задокументировала иной компромисс SLIP: разделители и экранирование IP-дейтаграмм, но без поля типа, общего максимума базового соглашения и коррекции ошибок на линии. RFC 1661 и RFC 1662 позже описали PPP с мультиплексированием, LCP, согласуемыми пределами, флаговым кадрированием, прозрачностью и FCS. Это сопоставление, не доказанная родословная.

Современной для RATP точкой сравнения была RFC 793, на которую RFC 916 ссылался при отказе от динамического окна. TCP обслуживал более широкий надёжный поток через взаимосвязанные сети. RATP объединял пакетный и надёжный соединительный уровень на одной линии точка-точка. Сходные слова не давали одинаковых границ доказательств.

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