Tcp/ip

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

Протоколы ARPANET, как и современные Интернет-протоколы, были упорядочены в слои. Протоколы верхних слоёв работали поверх протоколов нижних слоёв. Сегодня стек TCP/IP имеет пять слоёв (физический, канальный, сетевой, транспортный и прикладной), но у ARPANET было всего три слоя (или четыре, смотря как считать).

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

Краткая историческая справка

ARPANET финансировался федеральным правительством США, и в частности Управлением перспективных исследовательских проектов (Advanced Research Projects Agency, ARPA), подчинённым Министерству обороны (отсюда и название ARPANET). Правительство США не создавало сеть самостоятельно; вместо этого оно отдало работу на аутсорс бостонской консалтинговой фирме Bolt, Beranek and Newman, более известной как BBN.

BBN, в свою очередь, взяла на себя бОльшую часть задач по реализации сети, но не весь проект целиком. BBN занималась проектированием и поддержкой машины, называемой Interface Message Processor (IMP). IMP представлял собой модернизированный микрокомпьютер Honeywell, каждый из таких компьютеров отправлялся в те учреждения по всей стране, которые должны были подключаться к ARPANET. IMP использовался в качестве шлюза в ARPANET для четырёх хостов в каждой из точек. BBN контролировала выполняемое на компьютерах IMP ПО, передающее пакеты от одного IMP к другому IMP, однако фирма не имела непосредственного контроля над машинами, подключавшимися к IMP и становившимися истинными хостами ARPANET.

Машины-хосты контролировались учёными-компьютерщиками, которые были конечными пользователями сети. Эти учёные в местах использования хостов по всей стране отвечали за написание программного обеспечения, которое бы позволило хостам общаться друг с другом. IMP предоставляли хостам возможность передавать сообщения друг другу, но это не было особо полезно, если бы хосты не согласовали используемый для сообщений формат. Для решения этой проблемы была собрана разношёрстная команда, в основном состоящая из аспирантов различных учебных заведений, где находились хосты. Эта команда самостоятельно организовала Network Working Group, занимавшуюся созданием спецификаций протоколов для использования компьютерами-хостами.

То есть если представить единичное успешное сетевое взаимодействие через ARPANET (допустим, отправку электронного письма), то за некоторые части её реализации, обеспечивающие успешное взаимодействие, отвечал один коллектив людей (BBN), а за другие части отвечал другой коллектив (Network Working Group и инженеры в каждой из точек размещения хостов). Такое организационное и логистическое стечение обстоятельств, вероятно, сыграло важную роль в выборе слоистой архитектуры протоколов ARPANET, что, в свою очередь, повлияло на реализацию TCP/IP в виде слоёв.

Итак, вернёмся к протоколам

Иерархия протокола ARPANET.

Слои протокола были упорядочены в иерархию. В самом низу находился уровень 0 (level 0). Это слой, который в каком-то смысле не считается, потому что в ARPANET его целиком контролировала фирма BBN, а значит, нужда в стандартном протоколе отсутствовала. Level 0 управлял тем, как данные передаются между IMP. У BBN были внутренние правила о том, как IMP должны это делать; для всех, кто не работал в BBN, подсеть IMP оставалась чёрным ящиком, просто передающим любые отправленные ему данные. То есть level 0 был слоем без настоящего протокола, не являлся публично открытым и общепринятым перечнем правил и его существование могло полностью игнорироваться программами, работающими на хостах ARPANET. Грубо говоря, он обрабатывал всё, что сегодня относится к физическому, канальному и сетевому слоям стека TCP/IP, и даже выполнял довольно большую часть функций транспортного слоя, но к этому мы вернёмся в конце поста.

Слой level 1 устанавливал интерфейс между хостами ARPANET и IMP, к которым они были подключены. Можно сказать, что это был API для чёрного ящика level 0, созданного BBN. В то время его также называли IMP-Host Protocol. Этот протокол нужно было написать и опубликовать, потому что при первоначальной подготовке ARPANET каждое учреждение с хостами должно было писать собственное ПО, обеспечивающее интерфейс с IMP. Они бы не знали, как это сделать, без помощи BBN.

Спецификация IMP-Host Protocol была записана BBN в длинном документе под названием BBN
Report 1822. В процессе эволюции ARPANET было выпущено много новых версий документа; в посте я приблизительно опишу то, как работала изначальная версия IMP-Host Protocol. Согласно правилам BBN, хосты могли передавать компьютерам IMP сообщения длиной не более 8095 бит, и каждое сообщение содержало leader (заголовок), в котором указывался номер хоста-получателя, а также нечто под названием link number (номер канала). IMP считывал номер хоста-получателя и послушно переправлял сообщение в сеть. При получении сообщений от удалённого хоста принимающий IMP заменял номер хоста-получателя на номер хоста-отправителя, а потом передавал его на локальный хост. Между самими IMP передавались не сами сообщения IMP разбивали сообщения на мелкие пакеты для передачи по сети, однако эта особенность была сокрыта от хостов.


Формат заголовка сообщений, передаваемых между хостом и IMP, каким он был в 1969 году. Схема из BBN Report 1763.

Номер канала, который мог быть любым числом от 0 до 255, выполнял две задачи. Он использовался протоколами более высокого уровня для установки нескольких каналов связи между любыми двумя хостами в сети, потому что в текущий момент времени с хостом-получателем вполне могло общаться несколько локальных пользователей. (Другими словами, номера каналов позволяли мультиплексировать связь между хостами.) Однако также он использовался в слое level 1 для управления объёмом трафика, который можно передавать между хостами, это было необходимо для того, чтобы быстрые компьютеры не перегружали сообщениями медленные. В изначальном проекте IMP-Host Protocol ограничивал каждый хост, позволяя одновременно передавать по одному каналу всего одно сообщение. После того, как хост передал сообщение по каналу удалённому хосту, ему нужно было ждать от удалённого IMP специальное сообщение под названием RFNM (Request for Next Message), прежде чем отправлять следующее сообщение по тому же каналу. Следующие версии этой системы, созданные для повышения пропускной способности, позволяли хосту одновременно передавать другому хосту по одному каналу до восьми сообщений.

Самое интересное начинается в слое level 2, потому что этот и последующий слои BBN и Министерство обороны отдали на откуп учёными и Network Working Group, позволив изобретать их самостоятельно. Слой level 2 представлял собой Host-Host Protocol, черновик которого изначально был выпущен в RFC 9, а первая его официальная спецификация появилась в RFC 54. Более удобочитаемое объяснение Host-Host Protocol представлено в ARPANET Protocol Handbook.

Host-Host Protocol управлял тем, как хосты создавали соединения друг с другом и управляли ими. Соединение это односторонняя линия передачи данных между сокетом записи одного хоста и сокетом считывания другого. Концепция сокетов (socket) была добавлена поверх имевшей ограничения системы каналов level 1 (не забывайте, что номер канала иметь только 256 значений), чтобы предоставить программам возможность адресации определённого процесса, работающего на удалённом хосте. Сокеты считывания имели нечётные номера; функция сокета (считывание или запись) назывались его гендером. В протоколе не было номеров портов, как в TCP. Соединения можно было открывать, манипулировать ими и закрывать их при помощи специально отформатированных контрольных сообщений Host-Host, передаваемых между хостами по каналу 0, зарезервированному для этой цели. После того, как был произведён обмен сообщениями по каналу 0 для установки соединения, дальнейшие сообщения с данными можно было передавать по каналу с другим номером, выбранным получателем.

Контрольные сообщения Host-Host идентифицировались трёхбуквенной мнемоникой. Соединение устанавливалось, когда два хоста обменивались сообщением STR (sender-to-receiver) и соответствующим сообщением RTS (receiver-to-sender) эти контрольные сообщения назывались сообщениями Request for Connection (запроса на подключение). Соединения можно было закрывать контрольным сообщением CLS (close). Существовали и другие контрольные сообщения, менявшие частоту передачи сообщений с данными от отправителя к получателю, что опять-таки нужно было для того, чтобы быстрые хосты не перегружали медленные. Управление потоками, реализованное в протоколе level 1, очевидно, было недостаточным для level 2; я подозреваю, что так получилось из-за того, что получение RFNM от удалённого IMP гарантировало только то, что удалённый IMP передал сообщение на хост-получатель, а не то, что хост полностью его обработал. Также существовали контрольные сообщения INR (interrupt-by-receiver) и INS (interrupt-by-sender), которые в основном использовались протоколами более высокого уровня.

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

Один протокол с этого уровня не походил на остальные, это Initial Connection Protocol (ICP). ICP считался протоколом level 3, но на самом деле был протоколом level 2.5, поскольку от него зависели другие протоколы level 3. ICP был необходим потому, что соединения, обеспечиваемые Host-Host Protocol на level 2, были только односторонними, однако большинству приложений для выполнения каких-то интересных задач требовалось двустороннее (т.е. полнодуплексное) соединение. ICP задавал двухэтапный процесс, при котором запущенный на одном хосте клиент подключался к долговременно работающим процессом-сервером на другом хосте. Первый этап заключался в установке одностороннего подключения от сервера к клиенту при помощи известного номера сокета процесса-сервера. После установки соединения сервер отправлял по нему клиенту новый номер сокета. Затем установленное соединение прекращалось и открывалось два новых соединения, одно для считывания, использующее переданный номер сокета, другое для записи, использующее тот же переданный номер плюс один. Этот небольшой танец был необходимой прелюдией для большинства действий, например, он был первым этапом установки соединения Telnet.

На этом наш подъём по иерархии протоколов ARPANET завершён. Вы могли ожидать, что рано или поздно я упомяну Network Control Protocol. Прежде чем я приступил к исследованиям для подготовки к этому посту, я считал, что ARPANET управлялся протоколом под названием NCP. Этой аббревиатурой иногда обозначали протоколы ARPANET в целом. Вероятно, именно поэтому у меня появилась такая мысль. Например, в RFC 801 говорится о переходе ARPANET с NCP на TCP, и это заставляет думать, что NCP это протокол ARPANET, эквивалентный TCP. Но Network Control Protocol для ARPANET никогда не существовало (хоть так и считает Encyclopedia Britannica), и я подозреваю, что люди ошибочно расшифровывали NCP как Network Control Protocol, но на самом деле это означало Network Control Program. Программа Network Control Program была программой уровня ядра, работающей на каждом хосте, отвечающем за управление сетевыми коммуникациями. Она была эквивалентом стека TCP/IP в современных операционных системах. Аббревиатура NCP, используемая в RFC 801, это псевдоним, а не протокол.

Сравнение с TCP/IP

Позже все протоколы ARPANET были вытеснены протоколами TCP/IP (за исключением Telnet и FTP, которые легко адаптировали для работы поверх TCP). Все протоколы ARPANET основывались на предположении о том, что сеть создавалась и управлялась одной организацией (BBN), а стек протоколов TCP/IP проектировался под Интер-нет, сеть сетей, где всё будет более гибким и ненадёжным. Это привело к появлению одних из наиболее очевидных отличий между современными протоколами и протоколами ARPANET, а именно к тому, как сегодня мы разделяем сетевой и транспортный слои. В ARPANET функции транспортного протокола частично выполняли IMP, а позже за них стали отвечать исключительно хосты в конечных точках сети.

Однако самым интересным в протоколах ARPANET мне кажется то, что большой объём функций транспортного слоя, присутствующий сегодня TCP, прошёл этап незрелой юности ARPANET. Я не специалист по сетям, поэтому мне пришлось достать свой учебник по сетям из колледжа (Куросе и Росс, на помощь!), и в нём нашлось достаточно неплохое краткое описание того, за что в целом отвечает транспортный слой. Протокол транспортного слоя минимально должен выполнять следующие задачи. Сегмент здесь, по сути, является термином, аналогичным сообщению в ARPANET:

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

Кроме того, транспортный слой, как и TCP, может обеспечивать надёжную передачу данных, то есть:

• Сегменты доставляются по порядку
• Потерянные сегменты отсутствуют
• Сегменты не доставляются так быстро, что отбрасываются получателем (управление потоками)

Похоже, в ARPANET существовала некоторая запутанность в способе реализации мультиплексирования и демультиплексирования для обмена данными процессов BBN реализовала для этого номер канала на уровне IMP-Host, но оказалось, что всё равно поверх него требуются номера сокетов на уровне Host-Host. Поэтому номер канала использовался только для управления потоками на уровне IMP-Host, но BBN, похоже в дальнейшем отказалась от этой схемы в пользу управления потоками между уникальными парами хостов, то есть изначально номер канала был перегруженным элементом, а позже, по сути, стал рудиментарным. Сегодня TCP использует вместо них номера портов, выполняя управление потоками отдельно для каждого TCP-соединения. Мультиплексирование и демультиплексирование уровня процесс-процесс происходит целиком внутри TCP и не утекает на нижний слой, как это было в ARPANET.

К тому же, в свете того, как Куросе и Росс развивают идеи, лежащие в основе TCP, любопытно было увидеть, что ARPANET начинались с того, что авторы учебника назвали бы реализацией надёжной передачи данных на уровне IMP-Host при помощи строгого подхода остановиться и ждать. Принцип остановиться и ждать заключается в том, что после передачи сегмента узел отказывается передавать любые другие сегменты, пока не получит подтверждение получения последнего переданного сегмента. Это простое решение, но оно означает, что в любой момент времени по сети передаётся только один сегмент, из-за чего протокол оказывается очень медленным. Именно поэтому Куросе и Росс назвали подход остановиться и ждать просто переходным этапом на пути к полнофункциональному протоколу транспортного слоя. В ARPANET какое-то время использовался подход остановиться и ждать, поскольку на уровне IMP-Host перед отправкой дальнейших сообщений нужно было получить Request for Next Message в ответ на каждое исходящее сообщение. Но надо отдать должное BBN, поначалу она считала, что это будет необходимо для обеспечения управления потоками между хостами, поэтому замедление было намеренным. Как я говорил выше, требование RFNM позже было смягчено ради повышения скорости, а IMP начали прикреплять к сообщениям порядковые номера и отслеживать окна передаваемых сообщений примерно так же, как сегодня это делается в реализациях TCP.

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

<< До этого: Эра фрагментации, часть 4: анархисты

В 1990-м Джон Куотерман, консультант по сетевым технологиям и эксперт в области UNIX, опубликовал всеобъемлющий обзор состояния компьютерных сетей на тот момент. В небольшом разделе, посвящённом будущему вычислительных систем, он предсказал появление единой глобальной сети для электронной почты, конференций, передачи файлов, удалённого входа в систему так же, как сегодня существует всемирная телефонная сеть и всемирная почта. Однако особой роли интернету он не придал. Он предположил, что эта всемирная сеть скорее всего, будет управляться правительственными службами связи, кроме США, где ею будут управлять региональные подразделения Bell Operating Companies и операторы междугородней связи.

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

Передача эстафеты

Первое критически важное событие, приведшее к появлению современного интернета, произошло в начале 1980-х, когда Агентство оборонных коммуникаций (Defense Communication Agency, DCA) [ныне DISA] решило разбить ARPANET на две части. DCA взяло на себя контроль над сетью в 1975 году. К тому времени было ясно, что для отдела технологий обработки информации (IPTO) ARPA организации, занимающейся исследованием теоретических идей не было никакого смысла участвовать в развитии сети, использовавшейся не для исследования коммуникаций, а для повседневного общения. ARPA неудачно попыталась спихнуть контроль над сетью частной компании AT&T. DCA, отвечающее за военные системы связи, казалась наилучшим вторым вариантом.

В первые несколько лет новой ситуации ARPANET процветала в режиме благостного игнорирования. Однако к началу 1980-х стареющая инфраструктура коммуникаций министерства обороны отчаянно нуждалась в обновлении. Проект предполагаемой замены, AUTODIN II, подрядчиком которого DCA выбрало компанию Western Union, судя по всему, проваливался. Тогда главы DCA назначили полковника Хайди Хайдена ответственным за выбор альтернативы. Он предложил использовать в качестве основы для новой сети передачи оборонных данных технологию коммутации пакетов, которая уже была в распоряжении DCA в виде ARPANET.

Однако с передачей военных данных по ARPANET существовала очевидная проблема сеть изобиловала длинноволосыми учёными, иные из которых активно выступали против компьютерной безопасности или секретности к примеру, Ричард Столлман со своими сотоварищами-хакерами из лаборатории искусственного интеллекта MIT. Хайден предложил разделить сеть на две части. Он решил оставить учёных-исследователей с финансированием от ARPA на ARPANET, а компьютеры, работающие на оборонных предприятиях, выделить в новую сеть под названием MILNET. У подобного митоза было два важных последствия. Во-первых, раздел военной и не военной частей сети стал первым шагом к передаче интернета под гражданское, а впоследствии и под частное управление. Во-вторых, это стало доказательством жизнеспособности плодотворной технологии интернета протоколов TCP/IP, впервые придуманных лет за пять до этого. DCA было нужно, чтобы все узлы ARPANET перешли со старых протоколов на поддержку TCP/IP к началу 1983-го. На тот момент немногие сети использовали TCP/IP, но после этот процесс объединил две сети прото-интернета, что позволило трафику сообщений при необходимости связывать исследовательские и военные предприятия. Чтобы гарантировать долгосрочность протокола TCP/IP в военных сетях, Хайден основал фонд объёмом в $20 млн для поддержки компьютерных производителей, которые будут писать ПО для реализации TCP/IP в своих системах.

Первый шаг в постепенной передаче интернета от военного к частному контролю также даёт нам неплохую возможность попрощаться с ARPA и IPTO. Его финансирование и влияние, шедшие под управлением Джозефа Карла Робнетта Ликлайдера, Айвена Сазерленда и Роберта Тейлора, напрямую и опосредованно привело к появлению всех ранних разработок в области интерактивных вычислений и компьютерных сетей. Однако создав стандарт TCP/IP в середине 1970-х, оно последний раз сыграло ключевую роль в истории компьютеров.

Следующим важным вычислительным проектом, организованным DARPA, станет конкурс автономных средств передвижения 2004-2005 годов. Самым знаменитым проектом до этого будет стратегическая компьютерная инициатива на основе ИИ 1980-х годов на миллиард долларов, которая породит несколько полезных военных приложений, но практически никак не повлияет на гражданское общество.

Решающим катализатором в потере влияния организации стала война во Вьетнаме. Большинство учёных-исследователей считали, что борются за правое дело и защищают демократию, когда исследования эпохи Холодной войны финансировали военные. Однако те, кто вырос в 1950-е и 1960-е года потеряли веру в военных и их цели после того, как последние увязли в болоте Вьетнамской войны. Среди первых был и сам Тейлор, ушедший из IPTO в 1969, унося свои идеи и связи в Xerox PARC. Контролируемый демократами Конгресс, обеспокоенный разрушительным влиянием военных денег на базовые научные исследования, принял поправки, согласно которым деньги на оборону необходимо было тратить исключительно на военные исследования. ARPA отразило это изменение в культуре финансирования в 1972 году, переименовавшись в DARPA управление перспективных исследовательских проектов Министерства обороны США.

Поэтому эстафета перешла к гражданскому национальному научному фонду (NSF). К 1980-му году с бюджетом в $20 млн, NSF отвечал за финансирование примерно половины федеральных компьютерных исследовательских программ в США. И большая часть этих средств вскоре будет направлена на новую национальную компьютерную сеть NSFNET.

NSFNET

В начале 1980-х Ларри Смарр, физик из Иллинойского университета, посетил Институт им. Макса Планка в Мюнхене, где работал суперкомпьютер Крей, к которому был разрешён доступ европейским исследователям. Раздосадованный отсутствием схожих ресурсов для учёных США, он предложил, чтобы NSF профинансировал создание нескольких суперкомпьютерных центров по всей стране. Организация ответила на притязания Смарра и других исследователей со схожими жалобами, создав в 1984 году отдел по передовым научным вычислениям, что привело к финансированию пяти подобных центров с пятилетним бюджетом в $42 млн. Они протянулись от Корнеллского университета на северо-востоке страны до Сан-Диего на юго-западе. Находившийся между ними университет штата Иллинойс, где работал Смарр, получил собственный центр, национальный центр суперкомпьютерных приложений, NCSA.

Однако возможности центров по улучшению доступа к вычислительным мощностям были ограничены. Использовать их компьютеры пользователям, не живущим поблизости от одного из пяти центров, было бы затруднительно, и потребовало бы финансирования научных командировок длиной в семестр или в лето. Поэтому NSF решил построить ещё и компьютерную сеть. История повторялась Тейлор продвигал создание ARPANET в конце 1960-х именно для того, чтобы дать исследовательскому сообществу доступ к мощным вычислительным ресурсам. NSF обеспечит опорный хребет, который объединит ключевые суперкомпьютерные центры, протянется по всему континенту, а потом подсоединит к себе региональные сетки, дающие доступ к этим центрам другим университетам и научным лабораториям. NSF воспользуется преимуществами интернет-протоколов, которые продвигал Хайден, передав ответственность за создание местных сетей локальным научным сообществам.

Изначально NSF передал задачи по созданию и поддержке сети NCSA из Иллинойского университета как источнику первоначального предложения создания национальной суперкомпьютерной программы. В свою очередь NCSA взял в аренду те же самые линии связи на 56 кбит/с, что ARPANET использовала с 1969 года, и запустила сеть в 1986 году. Однако эти линии быстро забились трафиком (подробности этого процесса можно найти в работе Дэвида Миллса "Опорная сеть NSFNET"). И снова повторилась история ARPANET быстро стало очевидно, что основной задачей сети должен быть не доступ учёных к компьютерным мощностям, а обмен сообщениями между людьми, имевшими к ней доступ. Можно простить авторов ARPANET за то, что они не знали, что подобное может произойти но как могла повториться та же ошибка почти через двадцать лет? Одно из возможных объяснений состоит в том, что гораздо легче оправдать семизначный грант на использование вычислительных мощностей, стоимость которых составляет восьмизначные суммы, чем оправдать трату таких сумм на вроде бы такие несерьёзные цели, как возможность обмениваться электронными письмами. Нельзя сказать, что NSF сознательно вводил кого-то в заблуждение. Но как антропный принцип утверждает, что физические константы Вселенной такие, какие они есть, потому, что иначе нас бы просто не было, и мы не могли бы их наблюдать, так и мне не пришлось бы писать о компьютерной сети с государственным финансированием, если бы не было подобных, несколько фиктивных оправданий её существованию.

Убедив себя в том, что сама по себе сеть обладает, по меньшей мере, такой же ценностью, как и суперкомпьютеры, оправдывающие её существование, NSF обратился к сторонней помощи, чтобы обновить костяк сети, проведя линии с пропускной способностью T1 (1,5 Мбит/с). Стандарт Т1 был основан компанией AT&T в 1960-х, и должен был обслуживать до 24 телефонных звонков, каждый из которых кодировался в цифровой поток 64 кбит/с.

Контракт выиграла Merit Network, Inc. в партнёрстве с MCI и IBM, и за первые пять лет получила от NSF грант на $58 млн для строительства и поддержки сети. MCI обеспечивала инфраструктуру связи, IBM вычислительные мощности и ПО для роутеров. Некоммерческая компания Merit, управлявшая компьютерной сетью, связывавшей между собой кампусы Мичиганского университета, принесла с собой опыт поддержки научной компьютерной сети, и придала всему партнёрству университетский дух, благодаря чему его легче воспринимали NSF и учёные, использовавшие NSFNET. Тем не менее, передача обслуживания от NCSA к Merit была очевидным первым шагом на пути к приватизации.

Изначально MERIT расшифровывалась как Michigan Educational Research Information Triad [мичиганская образовательная триада исследования информации]. Штат Мичиган добавил $5 млн от себя, чтобы помочь домашней сети на Т1 разрастись.



Через магистраль Merit шёл трафик более десяти региональных сетей, от нью-йоркской исследовательской и образовательной сети NYSERNet, связанной в Итаке с Корнеллским университетом, до калифорнийской федеративной исследовательской и образовательной сети CERFNet, подключённой в Сан-Диего. Каждая из этих региональных сетей связывалась с бесчисленным количеством местных кампусных сеток, поскольку в лабораториях колледжей и офисах преподавателей работали сотни машин под управлением Unix. Такая федеральная сеть сетей стала затравочным кристаллом современного интернета. ARPANET связывала между собой только исследователей в области информатики с хорошим финансированием, работавших в элитных научных заведениях. А к 1990-му году почти любой студент университета или преподаватель уже мог выходить в онлайн. Перекидывая пакеты от узла к узлу через местный Ethernet, потом дальше в региональную сеть, потом через большие расстояния со скоростью света по магистрали NSFNET они могли обмениваться емейлами или чинно беседовать в Usenet с коллегами с других концов страны.

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

Взлёт

За весь этот период количество компьютеров, подключённых к NSFNET и связанным с ней сетями а всё это мы теперь уже можем называть интернетом росло каждый год примерно в два раза. 28 000 в декабре 1987, 56,000 в октябре 1988, 159 000 в октябре 1989, и так далее. Такая тенденция продолжалась вплоть до середины 1990-х, а потом рост немного замедлился. Как, интересно, учитывая эту тенденцию, Куотерман мог не заметить, что интернету суждено править миром? Если недавняя эпидемия нас чему и научила, так это тому, что человеку очень сложно представить себе экспоненциальный рост, поскольку он не соответствует ничему, с чем мы сталкиваемся в повседневной жизни.

Конечно же, название и концепция интернета появилась ещё до NSFNET. Интернет протокол придумали в 1974, и ещё до NSFNET существовали сети, общавшиеся по IP. Мы уже упоминали ARPANET и MILNET. Однако мне не удалось найти никаких упоминаний интернета единой, простирающейся на весь мир сети сетей до появления трёхъярусной NSFNET.

Количество сеток внутри интернета росло с похожей скоростью от 170 в июле 1988 года до 3500 осенью 1991. Поскольку научное сообщество не знает границ, многие из них находились за рубежом, начиная со связей с Францией и Канадой, налаженных в 1988-м. К 1995 году в интернет можно было выйти почти из 100 стран, от Алжира до Вьетнама. И хотя количество машин и сетей подсчитать гораздо легче, чем количество реальных пользователей, по разумным оценкам к концу 1994 их было 10-20 млн. В отсутствии подробных данных о том, кто, зачем и в какое время использовал интернет, довольно трудно аргументировано подтвердить то или иное историческое е объяснение такого невероятного роста. Небольшая коллекция историй и анекдотов вряд ли может объяснить, как с января 1991 по январь 1992 года к интернету подключилось 350 000 компьютеров, а за следующий год 600 000, а за следующий ещё 1,1 млн.

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

Сначала пришли учёные. NSF намеренно распространяла вычисления по как можно большему количеству университетов. После этого каждый учёный хотел присоединиться к проекту, потому, что все остальные были уже там. Если до вас могли не дойти емейлы, если вы могли не увидеть и не поучаствовать в самых последних обсуждениях на Usenet, вы рисковали пропустить анонс важной конференции, шанс найти наставника, не заметить передовое исследование до его публикации, и так далее. Ощущая принуждение к присоединению к научным беседам в онлайне, университеты быстро подключались к региональным сеткам, которые могли подсоединить их к магистрали NSFNET. К примеру, NEARNET, покрывавшая шесть штатов региона Новая Англия, к началу 1990-х приобрела более 200 участников.

Одновременно доступ начал просачиваться от преподавателей и аспирантов в гораздо более многочисленное сообщество студентов. К 1993 году примерно 70% первокурсников Гарварда завели себе электронные адреса. К тому времени интернет в Гарварде физически дошёл до всех уголков и связанных с ним институтов. Университет пошёл на значительные расходы для того, чтобы провести Ethernet не просто в каждое здание учебного заведения, но и во все студенческие общежития. Наверняка оставалось совсем немного времени до того момента, когда кто-нибудь из студентов первым ввалился в свою комнату после бурной ночи, упал в кресло и с трудом настучал электронное сообщение, об отправке которого пожалел на следующее утро будь то признание в любви или яростная отповедь врагу.

На следующей волне, около 1990 года, начали прибывать коммерческие пользователи. В тот год был зарегистрирован 1151 домен .com. Первыми из коммерческих участников стали исследовательские департаменты технологических компаний (Bell Labs, Xerox, IBM и т.д.). Они, по сути, использовали сеть в научных целях. Бизнес-общение их руководителей шло по другим сетям. Однако к 1994 году существовало уже более 60 000 имён в домене .com, и зарабатывание денег на интернете началось по-настоящему.

К концу 1980-х компьютеры начали становиться частью повседневной рабочей и домашней жизни граждан США, и важность цифрового присутствия для любого серьёзного бизнеса стала очевидной. Емейл предлагал способ простого и чрезвычайно быстрого обмена сообщениями с коллегами, клиентами и поставщиками. Списки рассылки и Usenet предлагали как новые способы быть в курсе событий в профессиональном сообществе, так и новые формы очень дешёвой рекламы для широкого спектра пользователей. Через интернет можно было получить доступ к огромному разнообразию бесплатных баз данных юридическим, медицинским, финансовым и политическим. Устраивавшиеся на работу вчерашние студенты, жившие в подключённых общежитиях, полюбили интернет так же, как и их работодатели. Он предлагал доступ к куда как большему набору пользователей, чем любой из отдельных коммерческих сервисов (и снова закон Меткалфа). После оплаты месячного доступа к интернету, практически всё остальное вы могли получить бесплатно, в отличие от значительной стоимости оплаты за использованные часы или за отправленные сообщения, которую просили CompuServe и прочие подобные сервисы. Среди ранних участников рынка интернета были компании, рассылавшие программы по почте например, The Corner Store из Литчфилда, Коннектикут, рекламировавшаяся в группах Usenet, и The Online Bookstore, магазин электронных книг, основанный бывшим редактором издательства Little, Brown and Company, и более чем на десять лет опередивший Kindle.

И потом пришла третья волна роста, принесшая обычных потребителей, начавших в больших количествах выходить в интернет в середине 1990-х. К этому времени закон Меткалфа уже работал на высшей передаче. Всё чаще быть в онлайне означало быть в интернете. Потребители не могли позволить себе протянуть домой выделенные линии класса Т1, поэтому почти всегда выходили в интернет посредством диалап-модема. Мы уже сталкивались с частью этой истории, когда коммерческие BBS постепенно превращались в провайдеров интернета. Это изменение пошло на пользу как пользователям (чей цифровой бассейн внезапно вырос до океана), так и самим BBS, перешедших на гораздо более простой бизнес посредника между телефонной системой и выездом на магистраль интернета пропускной способностью в Т1, без необходимости поддерживать собственные услуги.

Более крупные онлайн-сервисы развивались по той же схеме. К 1993 году все сервисы национального масштаба в США Prodigy, CompuServe, GEnie и молодая компания America Online (AOL) предлагали пользователям, которых в сумме насчитывалось 3,5 млн, возможность отправлять емейл на интернет-адреса. И только отстающий Delphi (с 100 000 подписчиков) предлагал полноценный выход в интернет. Однако в последовавшие несколько лет ценность доступа к интернету, продолжавшему расти с экспоненциальной скоростью, быстро перевесила доступ к собственным форумам, играм, магазинам и другому контенту самих коммерческих сервисов. 1996-й стал переломным годом к октябрю 73% пользователей, выходивших в онлайн, пользовались WWW, по сравнению с 21% за год до этого. Был придумал новый термин портал, описывающий рудиментарные остатки от услуг, предоставлявшихся AOL, Prodigy и остальными компаниями, которым люди платили деньги только за то, чтобы получить доступ в интернет.

Секретный ингредиент

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

Конечно, правительственные субсидии сыграли свою роль. Кроме финансирования магистральных линий связи, когда NSF решил всерьёз вложиться в развитие сети независимо от своей программы развития суперкомпьютеров, он не мелочился. Концептуальные лидеры программы NSFNET, Стив Вулф и Джейн Кавинес, решили строить не просто сеть суперкомпьютеров, но новую информационную инфраструктуру для американских колледжей и университетов. Поэтому они учредили программу Connections [связи], бравшую на себя часть расходов на подключение университетов к сети в обмен на то, что те обеспечат как можно большему количеству людей доступ к сети на своих кампусах. Это ускорило распространение интернета как прямо, так и косвенно. Косвенно поскольку многие из региональных сеток породили коммерческие предприятия, использовавшие ту же самую инфраструктуру, построенную на субсидии, чтобы продавать коммерческим организациям доступ в интернет.

Но и у Minitel были субсидии. Однако более всего интернет отличался своей многослойной децентрализованной структурой и свойственной ему гибкостью. IP позволял сетям с совершенно различными физическими свойствами работать с одной и той же системой адресов, а TCP обеспечивал доставку пакетов до получателя. И всё. Простота основной схемы работы сети позволяла надстраивать над ней практически любые приложения. Что важно, любой пользователь мог внести вклад в виде новой функциональности, если у него получалось убедить других пользоваться его программой. К примеру, передача файлов по протоколу FTP была одним из наиболее популярных способов использования интернета в ранние годы, однако найти сервера, предлагавшие интересующие вас файлы, кроме как через сарафанное радио было невозможно. Поэтому предприимчивые пользователи создавали различные протоколы для каталогизации и ведения списков FTP-серверов например, Gopher, Archie и Veronica.

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

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

Естественно, наиболее ярким примером многослойной структуры и децентрализации стал всемирный веб. Два десятилетия системы от компьютеров с разделением времени 1960-х до сервисов подобных CompuServe и Minitel вращались около небольшого набора основных услуг обмена информацией емейла, форумов и чатов. Веб стал чем-то принципиально новым. Ранние годы веба, когда он полностью состоял из уникальных страниц, сделанных вручную, ничем не напоминают его сегодняшнее состояние. Однако прыжки от ссылке к ссылки уже тогда обладали странной притягательностью, и давали предприятиям возможность обеспечивать чрезвычайно дёшевую рекламу и службу поддержки пользователей. Никто из архитекторов интернета не планировал появление веба. Он стал плодом творчества Тима Бернерса-Ли, британского инженера европейского центра ядерных исследований (ЦЕРН), создавшего его в 1990-м году с целью удобного распространения информации между исследователями лаборатории. Однако же он с лёгкостью жил на базе TCP/IP и использовал систему доменных имён, созданную для других целей, для повсеместно распространившихся URL. Любой человек с доступом к интернету мог сделать сайт, и к середине 90-х казалось, что все так и сделали мэрии городов, местные газеты, малые предприятия и любители всех мастей.

Приватизация

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

Что ещё почитать

• Janet Abatte, Inventing the Internet (1999)
• Karen D. Fraser NSFNET: A Partnership for High-Speed Networking, Final Report (1996)
• John S. Quarterman, The Matrix (1990)
• Peter H. Salus, Casting the Net (1995)

Мы решили совершить еще один вояж в прошлое сетевых технологий. На сей раз мы поговорим о Chaosnet, специфическом сетевом протоколе, который использовался в 1970-х годах в Lisp-машинах. Исходным материалом для статьи послужила заметка на TwoBitHistory, которую мы расширили и дополнили собственными находками и иллюстрациями.

Если с помощью dig отправить к DNS запрос о каком-то сайте, например, it-grad.ru, мы получим примерно такой ответ:

$ dig it-grad.ru

В строке Answer Section содержится информация о записи типа A.

Приглядимся к полю IN. Возможно, кто-то думает, будто IN это такой предлог: it-grad.ru IN (внутри) A и имеет IP-адрес 212.116.122.3. На самом же деле IN значит Internet. Это класс записи.

Возникает закономерный вопрос: а какие, собственно, еще варианты здесь могут быть? Как можно получить доступ к хосту, который находится не в Интернете? Может показаться, что IN это вообще единственное значение, которое имеет смысл в современном мире. К тому же, если пробить тот же it-grad.ru и явно указать, что вы хотите получить запись с классом, отличным от IN, DNS-сервер вернет ошибку. Давайте сделаем еще один запрос и посмотрим, к чему приведет явное указание класса. Например, HS (Hesoid). Сервер вернет статус SERVFAIL.

$ dig -c HS it-grad.ru

Классы, отличные от IN, практически не используются в современном мире. Но это вовсе не означает, что их нет: например, существуют HS или CH. HS зарезервирован для использования в информационной службе Hesoid, названной в честь древнегреческого поэта. А вот класс CH зарезервирован под нужды героя статьи, Chaosnet. На текущий момент он представляет разве что историческую, мемориальную ценность.


Остальные классы DNS

Сегодня мир принадлежит TCP/IP. Этот протокол (вместе с UDP) управляет подавляющим числом сетевых подключений. Но, как видите, кое-где еще остались следы другой, давно исчезнувшей системы, и это по-своему замечательно. Что такое Chaosnet? Каким он был и кем использовался? Почему он канул в Лету? Давайте разберемся.

Всё началось в MIT

Chaosnet был создан сотрудниками лаборатории по изучению искусственного интеллекта MIT в 1970-х. Он был сопутствующим продуктом проекта машины, которая могла бы работать на языке программирования Lisp более эффективно, чем компьютеры общего назначения.

Lisp это детище профессора MIT и лауреата премии Тьюринга 1971 года Джона Маккарти. Он является основоположником функционального программирования и автором термина (порицаемого в некоторых кругах) искусственный интеллект.


Джон Маккарти собственной персоной

Самой ранней версией Lisp принято считать интерпретатор 1958 года для IBM 704. Фактически, это один из старейших актуальных языков программирования наряду с Фортраном.

Первое публичное упоминание о Lisp (версия 1) датируется 1960-м годом. А к 1962-му была готова продвинутая и усовершенствованная версия 1.5. Lisp включал в себя массу инструментов и функций, которые присутствуют в подавляющем большинстве современных языков программирования.

Это был первый язык, в котором была реализована система сборки мусора и автоматическое управление памятью. Он получил огромную популярность и любовь среди программистов, работавших над ИИ. Вот только один из известных примеров: SHRDLU, программа Терри Винограда, которая позволяла обращаться к компьютеру на естественном языке и заставлять его решать простые логические задачи. Была написана на DEC PDP-6 с использованием языков Lisp и Micro Planner.


Пример, иллюстрирующий SHRDLU

Единственной проблемой Lisp была его скорость. Простейшие операции занимали вдвое больше времени, чем в других языках, поскольку переменные проходили двойную проверку: и в процессе выполнения, и на этапе компиляции. Сборщик мусора работал более секунды на тогдашнем IBM 7090, находившемся в распоряжении MIT. Проблема производительности стояла чрезвычайно остро: ИИ-программисты строили системы, взаимодействовавшие с пользователем в реальном времени.

В конце 1970-х было решено построить специальный компьютер для Lisp с учетом всех особенностей языка. У компьютера должно было быть больше памяти и компактный набор инструкций, подходящих для Lisp. Предполагалось, что для проверки типов будет использоваться самостоятельная электрическая цепь, и это многократно ускорит работу кода. Еще одна особенность Lisp-машин состояла в том, что ни о каком разделении процессорного времени и речи быть не могло: амбициозные программы задействовали все ресурсы компьютера без остатка. Каждому пользователю приписывался отдельный центральный процессор. Вот как сотрудники Lisp Machine Group описывали перспективы работы с таким компьютером:

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

Разумеется, понятие персональный компьютер в отношении Lisp-машин употребляется в несколько ином значении, чем мы привыкли теперь.


Лисп-машина


Промо-фотография терминала

Предполагалось, что пользователи будут работать не непосредственно с компьютером, а со специальными терминалами. Каждый пользователь получит выделенные мощности, а сам компьютер будет находиться в машинном зале, чтобы не докучать всему офису звуками вычислений. Процессоры будут иметь доступ к файловой системе и к периферийным устройствам, таким как принтеры, через высокоскоростную локальную сеть с полностью распределенным управлением. Так и появился Chaosnet. Его создатели Томас Найт (биография на русском языке) и Джек Холлоуэй.

Chaosnet одновременно являлся и железным стандартом, и программным протоколом. В части оборудования этот стандарт был похож на Ethernet, а программный протокол в конечном итоге и работал по Ethernet. Но в отличие от TCP/IP, предполагалось управление исключительно локальными сетями. Один из сотрудников MIT Artificial Intelligence Lab рассказывал, что при разработке Chaosnet основное внимание было уделено написанию протокола, который в пределах небольшой сети показывал бы лучшие результаты, чем его конкуренты.

Скорость была крайне важна, поскольку Chaosnet был промежуточным звеном между процессором Lisp и файловой системой. Сетевые задержки сказались бы на скорости выполнения базовых операций. Для обеспечения максимального быстродействия за основу была взята (а в дальнейшем доработана) Network Control Program, применявшаяся тогда в Arpanet. Chaosnet, как и современный TCP/IP, использовал пакетные подтверждения сообщений, что позволило сократить общее количество пересылаемых пакетов на 30-50%.

Chaosnet также мог обойтись без алгоритмов маршрутизации, поскольку большинство хостов в сети Lisp-машин были связаны одним коротким проводом (CATV, коаксиальный кабель). Дэвид Мун, участник Lisp Machine Group писал, что схема маршрутизации Chaosnet основана на предположении, что сеть достаточно проста и в ней существует всего несколько коротких путей. Сложные схемы здесь не нужны. В результате управляющая программа Chaosnet весила вдвое меньше, чем Network Control Program для Arpanet.

Протокол Chaosnet имел и другие особенности. Так, длина адреса составляла всего 16 бит, что вдвое меньше длины адреса IPv4. Вполне разумный подход, учитывая, что Chaosnet предназначался только для локальных сетей. Первые 8 бит указывали на подсеть, вторые на конкретный хост.

Также Chaosnet не использовал номера портов. Вместо этого процесс, который хотел подключиться к другому процессу на другом компьютере, осуществлял запрос, в котором указывалось контактное имя цели. Зачастую название конкретной службы. Например, один хост мог попытаться подключиться к другому хосту, используя контактное имя TELNET. Это весьма похоже на TCP: например, к порту 80 можно обратиться по имени HTTP.

DNS-класс CH, Chaosnet, был добавлен в DNS в 1986 году. Он заменил другой класс, CSNET (Computer Science Network). Теперь уже сложно выяснить, почему именно Chaosnet получил свое место в DNS. Существовали и другие семейства протоколов, которые почему-то не были в неё добавлены. Например, Пол Мокапетрис (Paul Mockapetris), один из главных архитекторов DNS, писал, что изначально предполагалось включить в систему доменных имен класс сетевого протокола Xerox. Но по неизвестным причинам этого не произошло. А Chaosnet, возможно, был добавлен только потому, что большая часть работы над Arpanet и Интернетом производилась в BBN Technologies. Сотрудники этой компании были тесно связаны с MIT и, вероятно, многое слышали о Chaosnet.

Поначалу Lisp-машины имели коммерческий успех и продавались Symbolics и Lisp Machines Inc. Но с течением времени надобность в них отпала. Их вытеснили микрокомпьютеры, которым по силам было работать с Lisp, но уже без специальных схем. Затем на сцену вышел TCP/IP, в котором были исправлены недоработки Arpanet, и Chaosnet потерял актуальность.

Призрак прошлого

К сожалению, информации о Chaosnet сейчас не так уж и много. RFC 675, который, по сути, является первой версией TCP/IP, был опубликован в 1974 году. Chaosnet же появился на год позже. TCP/IP в конце концов завоевал мир, а Chaosnet развития не получил. Есть вероятность, что какие-то практики Chaosnet оказали влияние на разработку TCP/IP, но никаких подтверждающих или опровергающих это фактов нет. Интересный факт: в первоначальной версии Манифеста GNU упоминается поддержка протокола Chaosnet.

Различные имплементации Chaosnet и интересные ссылки:

• Cisco;
• драйвер для Linux;
• короткий материал об использовании отголосков Chaosnet для хакерских нужд.

Единственным заметным следом Chaosnet в мировой паутине является класс CH DNS. Это не более, чем призрак альтернативного сетевого протокола в мире победившего TCP/IP. Забавный артефакт цифровой археологии. Но он является живым напоминание о том, что интернет не появился в одночасье, а TCP/IP не единственный способ соединять компьютеры между собой.

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