Кратко

  • IMP был не примитивным IP-маршрутизатором и не пассивным каналом. BBN поставила ARPA специализированный пакетно-коммутационный субстрат с разбиением и сборкой сообщений, проверками, трассировкой, логическими связями и механизмами ограничения потока. Но уже первые RFC показывали: часть состояния, согласования и проверки всё равно должна была жить в хостах.
  • Главный архитектурный урок возник не из отрицания инфраструктуры, а из обнаружения её границ. Пока NCP мог предполагать одну надёжную ARPANET, существенную часть коммуникационной ответственности можно было возложить на сеть. Когда потребовалось связать независимые пакетные сети, это предположение перестало масштабироваться: межсетевой слой пришлось сделать более общим и менее осведомлённым о приложениях, а восстановление после потерь и окончательную проверку корректности — вернуть к концам.

Сеть как разделение труда

В сентябре 1969 года инженер, подключавший компьютер к первому IMP в UCLA, сталкивался не с философским вопросом о том, должна ли сеть быть «умной» или «глупой». Перед ним стояла гораздо более прозаичная граница: вот машина BBN, поставленная по контракту ARPA, вот определённый ею интерфейс, а вот ваш хост, ваше программное обеспечение и проблемы, которые никто за вас не решил.

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

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

RFC 1 зафиксировал это разделение удивительно откровенно. Программное обеспечение ARPA Network существовало частично в IMP, частично в хостах. BBN определяла программную сторону IMP, тогда как группы хостов должны были договориться о программном обеспечении, необходимом самим компьютерам. Это был одновременно технический и организационный контракт границы: один подрядчик мог сделать одинаковый коммутационный слой, но не мог тем же актом написать и навязать всю коммуникационную логику всем подключаемым системам.

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

Выделенная подсеть из IMP решал эту проблему. ARPA могла закупить общий транспортный механизм, а BBN — поставить его в виде реальной системы, где одна инженерная команда контролировала аппаратную платформу, сетевое программное обеспечение и интерфейс к хостам. Хостовым командам больше не требовалось договариваться о внутренностях коммутационной сети. Им требовалось договориться о том, как использовать предоставляемый ею сервис.

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

Что именно находилось внутри IMP

Ранний IMP был функционально насыщенной машиной. RFC 1 описывал сообщения длиной до 8 080 бит. Перед передачей по сети они разбивались на пакеты не более 1 010 бит. Система использовала 24-битную циклическую проверку; пакеты пересылались между IMP, а на стороне назначения IMP снова собирал их в сообщение перед передачей хосту.

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

К этому добавлялись логические связи между хостами, средства трассировки и механизм Request for Next Message — RFNM. RFNM позволял регулировать выдачу сообщений со стороны источника: новый объём передачи не должен был бесконечно поступать в систему без обратного сигнала, свидетельствующего о продвижении предыдущего сообщения. Это было не позднейшее универсальное управление перегрузкой в смысле TCP, а конкретный механизм ARPANET, встроенный в тогдашнюю архитектуру обслуживания сообщений.

Трассировка тоже была не декоративной функцией. Когда распределённая система строится из новых линий, новых интерфейсов, разных хостов и совершенно нового программного обеспечения, способность увидеть путь и локализовать неисправность имеет прямую операционную ценность. То же видно в более поздних свидетельствах Фрэнка Харта: надёжность IMP была не лозунгом, а набором инженерных решений — возможностью отладки, перезагрузки, восстановления и перекоммутации линий.

Контракт ARPA с BBN поэтому нельзя свести к передаче философской «власти над сетью». Он покупал вполне конкретную способность. BBN должна была превратить Honeywell 516 в работающий сетевой узел, поставить его по графику, обеспечить программное обеспечение и довести систему до состояния, когда удалённые исследовательские центры смогут действительно обмениваться трафиком.

Здесь полезно различать четыре вида власти, которые исторические пересказы часто смешивают.

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

Второй — исполнительная власть реализации. BBN владела реальным кодом и инженерной компетенцией внутри поставляемого IMP. Пока сеть работала на этой реализации, её решения имели прямые эксплуатационные последствия.

Третий — авторитет интерфейса. Чтобы хост вошёл в сеть, он должен был корректно взаимодействовать с IMP. Здесь спецификация BBN и фактически поставленная машина устанавливали жёсткие условия совместимости.

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

Источники хорошо подтверждают первые три формы. Четвёртую они не подтверждают.

Хост как продолжение сетевого механизма

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

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

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

RFC 7 показывает практический масштаб этой работы на границе Host–IMP: мультиплексирование, буферизация, обработка интерфейса и управление обменом требовали хостового программного обеспечения. Даже если сеть надёжно переносила свои собственные сообщения, подключённый компьютер всё ещё должен был знать, как организовать данные, как связать сетевое событие с локальным процессом, как распределить буферы и как реагировать на состояние интерфейса.

Это критический момент. Граница ответственности не была стеной. Она была договором взаимодействия.

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

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

Почему такой дизайн всё же был разумным

Поздний Интернет сделал общий межсетевой слой гораздо скромнее, чем IMP-сеть ARPANET. Из этого иногда выводят неверную мораль: будто ранние инженеры просто разместили функции не там, а более поздние архитекторы исправили ошибку, «выкинув интеллект на края».

История сложнее.

В 1969 году IMP решал проблему одной конкретной пакетной сети. ARPA не начинала с задачи объединить любое число независимо спроектированных сетей. Ей требовалось связать вычислительные центры через общий коммуникационный субстрат. В этом контексте централизация некоторых сетевых функций имела очевидные преимущества.

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

Реально работающая система делала архитектурную границу материальной. Пока Honeywell 516 не был превращён в IMP, пока интерфейс не был подключён и пока хостовые команды не написали свой код, схемы оставались схемами. Этот факт не приписывает участникам 1969 года позднюю доктрину; он лишь показывает, как поставленная реализация превращала распределение обязанностей в эксплуатационную реальность.

Но работающий код придавал авторитет функции, а не безграничной организации.

Если BBN контролировала программное обеспечение IMP, это давало ей вес там, где поведение IMP определяло совместимость. Если UCLA, SRI или другой сайт писал хостовый код, решения этого сайта имели вес внутри хоста. Общее взаимодействие возникало в точке, где эти две области должны были совпасть.

Именно это различие между реальной инженерной зависимостью и абстрактной институциональной властью важно сохранить.

График поставки как источник фактической власти

Стив Крокер позже вспоминал, что первый IMP ожидался в UCLA в сентябре 1969 года и что хостовые команды должны были подготовить собственные интерфейсы и программное обеспечение к моменту его появления.

Такой график — недооценённый источник архитектурной дисциплины.

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

В этом смысле BBN обладала не только контрактной властью, но и властью поставленного интерфейса. Хост, который не говорил с реальным IMP, не был подключён к реальной ARPANET.

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

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

Невидимый предел надёжной сети

Пока существовала одна ARPANET, NCP мог опираться на сильное предположение: сеть под ним предоставляет надёжный коммуникационный сервис и адресует конечный пункт через IMP.

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

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

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

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

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

Вместо вопроса «как сделать одну сеть надёжной для её хостов?» появился другой: «какой минимум должны понимать все сети и промежуточные узлы, чтобы конечные системы могли общаться через инфраструктуры, внутренности которых не обязаны совпадать?»

Ответ на этот вопрос и сформировал архитектуру межсетевого взаимодействия.

Открытая архитектура: независимость как техническое требование

В изложении истории архитектуры Интернета открытая архитектура опиралась на несколько связанных правил.

Каждая сеть должна была оставаться самостоятельной. Её не требовалось внутренне перестраивать ради подключения к другим сетям.

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

Если требовалась повторная передача, инициировать её должен был источник.

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

Это было качественное изменение границы ответственности.

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

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

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

Возврат повторной передачи к источнику

Перенос восстановления к источнику особенно хорошо показывает разницу между ARPANET и межсетевым взаимодействием.

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

Источник и получатель расположены иначе. Именно они участвуют в полном цикле коммуникации.

Ранний Internet Transmission Control Program, документированный в RFC 675 в декабре 1974 года, принадлежит уже этому новому этапу. Его нельзя проецировать назад на IMP 1969 года как будто ARPANET с самого начала строилась по поздней Internet-архитектуре.

Хронология здесь имеет значение именно потому, что менялась задача.

IMP был ответом на вопрос о построении работающей пакетной сети.

Межсетевое взаимодействие отвечало на вопрос о соединении работающих пакетных сетей.

Позднейший принцип сквозной проверки дал более общую формулу для проверки того, куда следует помещать функцию.

Сквозная проверка как тест полноты

Аргумент Saltzer, Reed и Clark часто упрощают до лозунга «всё на края». В действительности он тоньше и полезнее.

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

Он всё ещё может помогать.

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

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

Различие между полной корректностью и локальным улучшением производительности или надёжности — возможно, самый важный урок всей этой истории.

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

Принцип сквозной проверки показывает, как это различие превратить в критерий проектирования.

Вопрос не в том, «разрешена» ли функция в сети. Вопрос в том, способна ли сеть закончить эту функцию без знания, существующего только на концах.

Если способна — общий слой может быть правильным местом.

Если не способна, сетевой механизм может оставаться полезной оптимизацией, но конечная система всё равно должна проверить результат.

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

Тонкое ядро — не пустое ядро

Это различие особенно важно сейчас, потому что выражение «тонкое ядро» слишком легко становится идеологическим.

Реальная сеть не может быть пустой.

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

Урок IMP поэтому не состоит в том, чтобы лишить инфраструктуру функций.

Он состоит в том, чтобы различать три категории.

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

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

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

Именно между второй и третьей категорией сегодня чаще всего размывается граница.

Когда полезный посредник становится обязательной точкой политики

Современная инфраструктура постоянно соблазняется возможностью «помочь ещё немного».

Если промежуточный сервис уже видит трафик, почему не дать ему хранить пользовательскую идентичность?

Если он уже фильтрует атаки, почему не перенести в него больше логики авторизации?

Если он уже оптимизирует доставку, почему не сделать его источником прикладного состояния?

Если он уже служит общей точкой управления, почему не поручить ему определять, какие участники или какие действия считаются допустимыми?

Каждое отдельное расширение может быть рациональным.

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

Это тот момент, где историческая граница IMP приобретает современное значение.

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

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

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

Это не историческое утверждение о намерениях инженеров ARPANET. Это современная аналитическая линза.

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

Интерфейс как предел легитимной стандартизации

Интерфейс Host–IMP даёт полезную модель ответа.

Интерфейс мог быть строгим. Иначе хост и IMP не смогли бы взаимодействовать.

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

Хорошо определённая граница даёт двум сторонам возможность развиваться независимо, пока сохраняется совместимость в точке контакта.

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

Поэтому один из сильнейших практических уроков ранней ARPANET состоит не в количестве функций внутри IMP, а в самом факте видимой границы.

Общий механизм был толстым по некоторым современным меркам. Но его зона ответственности была описываема.

Хостовые группы знали, что должны сделать сами.

Закупка не равна конституции

Контрактная история BBN требует особенно осторожного вывода.

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

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

Но фактический стандарт и постоянный мандат — разные вещи.

Источники позволяют утверждать, что BBN выиграла контракт на IMP, построила и обслуживала соответствующий субстрат и тем самым получила исполнительный авторитет над реально работающей сетевой частью ARPANET.

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

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

Источники не позволяют утверждать, что контракт создал для BBN право определять архитектуру всех последующих независимых сетей.

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

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

Что ARPANET не доказывает

Из этой истории нельзя делать несколько популярных, но слабых выводов.

Нельзя говорить, что IMP был просто современным маршрутизатором, родившимся раньше IP. У него была другая архитектурная среда и другой сервис.

Нельзя утверждать, что ARPANET уже реализовала зрелый принцип сквозной проверки. IMP выполнял значительную работу по надёжности и управлению передачей.

Нельзя приписывать изобретение пакетной коммутации одной BBN. История шире и включает идеи и работу Дональда Дэвиса, Пола Бэрана, Леонарда Клейнрока, Ларри Робертса, команд ARPA и других участников. Но эта статья исследует не спор о первенстве, а эксплуатационную границу IMP и хостов.

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

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

Граница, которая оказалась важнее устройства

Если смотреть на историю ARPANET только как на последовательность машин и дат, IMP остаётся одной ступенью в развитии сетевого оборудования.

Если смотреть на неё как на распределение ответственности, картина становится интереснее.

ARPA отделила коммуникационную подсеть от хостов.

BBN реализовала богатый набор общих сетевых функций.

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

Ранние RFC показали, что даже сильная сетевая надёжность не устраняет необходимость сотрудничества хостов.

NCP смог воспользоваться предположением о единой надёжной сети, пока существовал внутри этой среды.

Когда сеть стала сетью сетей, предположение перестало быть универсальным.

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

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

Отсюда следует и ограниченный институциональный вывод.

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

Оно не обязано автоматически распространяться на всё, что подключено к нему.

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

В 1969 году эта граница проходила через кабель между хостом и IMP.

Позднее Интернету пришлось провести её заново — уже между независимыми сетями и конечными системами.

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

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

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

Архитектурные тексты о межсетевом взаимодействии и сквозной проверке помогают объяснить последующую переразметку ответственности, но не должны проецироваться назад как доктрина всех участников 1969 года. Вывод о границе институциональной власти является аналитическим выводом из функций, интерфейсов, закупки и фактической реализации, а не цитатой из исторического «конституционного» документа.

  1. RFC 1 — раннее прямое свидетельство разделения ответственности между программным обеспечением IMP и хостов; также описание размеров сообщений и пакетов, проверок, трассировки, логических связей, RFNM и необходимости сотрудничества хостов. https://www.rfc-editor.org/rfc/rfc1.html

  2. RFC 2 — свидетельство хостового состояния связей, проверок, подтверждений и обработки статуса сети и удалённого хоста. https://www.rfc-editor.org/rfc/rfc2.html

  3. RFC 7 — описание обязанностей хоста у границы Host–IMP, включая мультиплексирование, буферизацию и обработку интерфейса. https://www.rfc-editor.org/rfc/rfc7.html

  4. RFC 528 — более позднее свидетельство сохранения проверок в программном обеспечении IMP и постоянной операционной важности надёжности сети. https://www.rfc-editor.org/rfc/rfc528.html

  5. RFC 1000 — ретроспектива Стива Крокера о работе хостовых команд, Интерфейс Host–IMP и графике поставки первого IMP в UCLA в сентябре 1969 года. https://www.rfc-editor.org/rfc/rfc1000.html

  6. Материалы Computer History Museum о контракте BBN 1968 года и превращении Honeywell 516 в IMP. https://archive.computerhistory.org/resources/access/text/2012/11/102706168-05-01-acc.pdf

  7. Устная история Фрэнка Харта о проектных приоритетах IMP, включая надёжность, отладку, перезагрузку и перекоммутацию линий. https://archive.computerhistory.org/resources/access/text/2017/11/102702222-05-01-acc.pdf

  8. История архитектуры Интернета Internet Society — источник для предположения NCP о надёжности ARPANET, принципов открытой архитектуры, простых шлюзов и повторной передачи от источника. https://www.internetsociety.org/internet/history-internet/brief-history-internet/

  9. Материал Internet Society о связанных сетях — источник для перехода от одной ARPANET к межсетевому взаимодействию нескольких пакетных сетей. https://www.internetsociety.org/internet/history-internet/brief-history-internet-related-networks/

  10. RFC 675 — ранняя спецификация Internet Transmission Control Program, относящаяся уже к этапу межсетевого взаимодействия. https://datatracker.ietf.org/doc/html/rfc675

  11. Ретроспективный анализ архитектуры протоколов DARPA Internet Дэвида Кларка — источник для логики дейтаграммной модели обслуживания и приоритетов живучести. https://groups.csail.mit.edu/ana/People/DDC/ebook-arch-V1.pdf

  12. Saltzer, Reed и Clark, End-to-End Arguments in System Design — источник для теста размещения функций и различия между полной корректностью и полезной нижнеуровневой оптимизацией. https://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

  13. RFC 3439 — позднейшая формулировка принципов простоты, минимализма IP и осторожности к лишнему состоянию и сложности в общем сетевом слое. https://www.rfc-editor.org/rfc/rfc3439.html