Кратко

  • RFC 872 оспаривал представление, будто TCP по своей природе не подходит быстрой локальной сети с небольшим числом ошибок. Требования приложения к доставке данных оставались главным вопросом.
  • Padlipsky допускал UDP и прямое использование локальной среды для подходящих задач, но учитывал расходы на второй стек рядом с протоколами связи между сетями.

Кабель короткий, и TCP в такой комнате кажется гостем, приехавшим на пять минут с дорожным сундуком. Michael A. Padlipsky заглянул внутрь этого сундука в RFC 872, опубликованной в сентябре 1982 года. Опасение, что TCP чересчур тяжёл для локальной сети, росло по мере пересказа. Автор сравнил его с выдуманным зверем: люди идут по следам, которые оставили сами, и пугаются их всё сильнее. Настоящие компьютеры продолжали обмениваться данными. Их работа требовала более точного вопроса.

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

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

Отдельную роль играл IP. Padlipsky объяснял, что IP определяет, находится ли адресат на ближайшей сети или пакет нужно отправить через шлюз. Он учитывает различия в допустимом размере пакетов и помечает, какому протоколу выше следует отдать данные на приёмной стороне. Это самостоятельная часть системы, поэтому ею могут пользоваться протоколы между хостами помимо TCP. Для машины, которая связывалась и с соседями, и с узлами за несколькими сетями, локальный участок был только первым отрезком маршрута. Широкая первая улица не отменяла поворотов дальше.

Другие способы оставались возможными. Приложение для передачи речи пакетами могло предпочесть быструю услугу без гарантий TCP; Padlipsky упоминал UDP. Программа, специально рассчитанная на местную сеть, могла обращаться к её возможностям напрямую. Но если для локального обмена требовался отдельный полный набор протоколов, а для дальнего — TCP/IP, одни и те же хосты получали две программы обслуживания. Их надо было разрабатывать, проверять и исправлять. Воображаемая тяжесть TCP превращалась в вполне реальную работу для людей, которым доставался второй стек.

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

В тексте перечислялись уже работавшие реализации TCP/IP и приложения для передачи данных. Padlipsky при этом требовал тщательно измерять их поведение в локальной сети. Специальный местный путь мог оправдать себя для конкретной задачи после честного сравнения одинаковых услуг. В цену входила и последующая поддержка. Рекламная скорость среды не заменяла опыт с полноценной работающей системой.

RFC 872 сохранила практичный спор 1982 года. Нужны ли программе порядок, надёжность и регулирование потока? Должен ли компьютер связываться с узлами за пределами локальной сети? Где испытание обнаружило ограничение — в кабеле, программе или работе хоста? При таких вопросах монстру становится тесно.