Как TCP/IP превзошёл стандарты Open Systems Interconnection, став протоколом для глобальных компьютерных сетей.
Если бы всё пошло по плану, Интернет который мы знаем никогда бы не возник. Этот план, разработанный 35 лет назад, предполагал создание целостного набора стандартов для компьютерных сетей Open Systems Interconnection, OSI.
Его создатели были обособленной группой представителей компьютерной индустрии из Соединённого Королевства, Франции и Соединённых Штатов Америки. Они представляли себе законченную, открытую и многослойную систему, которая позволила бы пользователям по всему миру легко обмениваться данными и тем самым открыть новые возможности для развития сотрудничества и коммерции.
Фото: INRIA
Просто подключите: Исследователь Юбер Зиммерман (Hubert Zimmerman) [слева — прим. автора] рассказывает о компьютерных сетях представителям французской власти на встрече в 1974 году. Зиммерман впоследствии будет играть ключевую роль в развитии стандартов OSI.
В то время, их видение представлялось единственно правильным. Тысячи инженеров и законодателей по всему миру оказались вовлечены в процесс становления стандартов OSI. Скоро у них была поддержка всех заинтересованных сторон: производителей компьютеров, телефонных компаний, регуляторов, национальных правительств, агентств по международным стандартам, академических исследователей, даже министерства обороны США [U.S. Department of Defence]. К середине 1980-х мировое признание OSI было очевидно.
Однако, к началу 1990-х проект практически заглох, столкнувшись с дешёвой и гибкой, хоть и менее полной, альтернативой: стеком Интернет состоявшим из Transmission Control Protocol и Internet Protocol. Когда позиции OSI ослабли, один из ведущих сторонников Интернета, Эйнар Стефруд (Einar Stefferud), с удовлетворением произнёс: «OSI это красивая мечта, а TCP/IP — уже реальность!» («OSI is a beautiful dream, and TCP/IP is living it!»).
Фото: INRIA
1961: Пол Баран (Paul Baran) в Rand Corp. начинает разработку своей концепции «коммутации блоков сообщений» как способа передачи данных по компьютерным сетям.
Что же случилось с «красивой мечтой»? В то время как триумфальная история Интернета хорошо задокументирована его создателями и историками с ними работавшими, OSI был позабыт всеми, за исключением лишь горстки ветеранов войны стандартов Internet-OSI. Чтобы понять причину, нам нужно окунуться в раннюю историю компьютерных сетей, время, когда досадные проблемы цифрового единства и глобальной связности будоражили умы учёных-информатиков, инженеров из телекоммуникационных компаний, законотворцев и правление корпораций. А чтобы лучше понять эту историю, вам придётся на время откинуть всё то, что вы уже знаете об Интернете. Попробуйте представить, если можете, что Интернет никогда не существовал.
История начинается в 1960-х. Воздвигается Берлинская Стена. Движение за свободу слова (Free Speech Movement) расцветает в Беркли. Солдаты США сражаются во Вьетнаме. А системы взаимосвязи цифровых компьютеров находятся ещё в младенчестве и подвергаются интенсивным широкопрофильным исследованиям, с десятками (а скоро — сотнями) людей в академических кругах, промышленности и правительстве занятых в крупных исследовательских проектах.
1965: Дональд В. Дэвис (Donald W. Davies), работая независимо от Барана, разрабатывает свою сеть с «коммутацией пакетов» (packet-switching).
Наиболее многообещающие из всех исследовательских проектов включали новый подход к передаче данных, называемый коммутацией пакетов. Изобретённый независимо Полом Бараном (Paul Baran) в Rand Corp. в Соединённых Штатах и Дональдом Дэвисом (Donald Davies) в Национальной Физической Лаборатории в Англии, способ коммутации пакетов предусматривал разбиение сообщений на отдельные блоки, или пакеты, которые могли быть маршрутизированы независимо по множеству доступных сетевых каналов. Компьютер на принимающей стороне собирал бы пакеты обратно в изначальную форму. Баран и Дэвис оба верили, что коммутация пакетов может быть более надёжной и эффективной, чем коммутация каналов, старая технология, используемая в телефонных системах, требующая выделенного канала для каждого подключения.
Исследователи, финансируемые Агентством по передовым исследованиям (Advanced Research Projects Agency, ARPA) министерства обороны США, создали первую сеть с коммутацией пакетов, названную ARPANET, в 1969 году. Вскоре другие организации, в частности компьютерный гигант IBM и ряд телефонных монополистов в Европе, начали вынашивать амбициозные планы по созданию сетей с коммутацией пакетов. Рассматривая возможность цифрового единства между компьютерами и связью, эти компании всё же больше заботились об удержании уровня доходов, получаемых от их существующего бизнеса. В результате, IBM и телефонные монополии предпочитали чтобы коммутация пакетов полагалась на «виртуальные цепи» (“virtual circuits”) — конструкция, копирующая технические и организационные методы систем с коммутацией каналов.
1969: ARPANET, первая сеть с коммутацией пакетов, создана в Соединённых Штатах.
1970: Оценочная прибыль на рынке компьютерных сетей США: US $46 миллионов.
1971: Во Франции запущен проект сети с коммутацией пакетов Cyclades.
При таком числе идей от заинтересованных сторон, все сходились на необходимости для коммутации пакетов некоторой формы международной стандартизации. Первые попытки начались в 1972 году, когда была сформирована Международная Рабочая Группа по Сетям (International Network Working Group, INWG). Винт Серф (Vint Cerf) был её первым председателем; другими активными участниками были Алекс МакКинзи (Alex McKenzie) в Соединённых Штатах, Дональд Дэвис и Роджер Сканлбёри (Roger Scantlebury) в Англии, а также Луи Пузан (Luis Pouzin) и Юбер Зиммерманн (Hubert Zimmermann) во Франции.
Задачей INWG было продвижение идеи коммутации пакетов на основе «датаграм», разработанной Пузаном. Как он мне объяснил во время нашей встречи в Париже в 2012 году, «Суть датаграм в отсутствии соединения. Это означает, что не создаётся никаких взаимоотношений между отправителем и получателем. Они независимы друг от друга, как фотоны». Это было радикальным предложением, в особенности при сравнении с виртуальными соединениями, предпочитаемыми IBM и телеком-инженерами.
INWG регулярно собиралась и обменивалась техническими статьями с целью приведения разработок в соответствие с идеей датаграм, в особенности транспортного протокола — ключевого механизма обмена пакетами между сетями различных типов. После нескольких лет дебатов и дискуссий, группа, наконец, достигла соглашения в 1975 году, и Серф с Пузаном отправили документацию по своему протоколу в международную организацию по надзору за телекоммуникационными стандартами, Международный Консультативный Комитет Телеграфии и Телефонии (International Telegraph and Telephone Consultative Commitee, известный по своему французскому акрониму, CCITT).
1972: собирается International Network Working Group (INWG) для разработки международного стандарта сетей с коммутацией пакетов, включая [слева направо — прим.автора] Луи Пузана, Винта Серфа, Алекса МакКинзи, Юбера Зиммермана и Дональда Дэвиса.
Комитет, в котором преобладали телеком-инженеры, отверг предложение INWG как слишком рискованное и не обкатанное. Серф с коллегами были очень разочарованы. Пузан, лидер Cyclades, французского исследовательского проекта по пакетным сетям, саркастически заметил, что CCITT «не против коммутации пакетов, если она выглядит также как коммутация каналов». И когда Пузан на конференциях жаловался на тактику «заламывания рук» со стороны «государственных монополий», все понимали, что он говорит о французском регуляторе [CCITT]. Французским бюрократам не нравилась искренность их соотечественника, что привело к постепенному истощению государственного финансирования Cyclades с 1975 по 1978 годы, после чего Пузан покинул проект.
1974: Винт Серф и Роберт Кан (Robert Kahn) публикуют статью “A Protocol for Packet Network Intercommunication,” [Протокол для взаимодействия пакетных сетей — прим. переводчика] в журнале IEEE Transactions on Communications.
Со своей стороны, Серф был настолько обескуражен этим опытом создания международных стандартов, что к концу 1975 года он покинул пост председателя INWG. Он также покинул кафедру в Стэнфорде и принял предложение Роберта Кана работать в ARPA. Серф и Кан уже успели развить разработку Пузана и опубликовали детали своей "программы управления передачей" годом ранее в IEEE Transactions on Communications. Эта разработка стала техническим фундаментом «Интернета», термина который позже был принят для обозначения сети сетей, использовавшей стек TCP/IP ARPA. В последующие годы эти двое руководили разработкой протоколов Интернета в подконтрольной им среде: небольшом сообществе подрядчиков ARPA.
Уход Серфа ознаменовал перелом в INWG. В то время как Серф и подрядчики ARPA в итоге формировали костяк Интернет в восьмидесятые, многие из оставшихся ветеранов INWG перегруппировались и присоединились к международному альянсу, который формировался под знаменем OSI, и два этих лагеря стали враждовать.
OSI был разработан комитетом, но одного этого факта недостаточно, чтобы похоронить проект — в конце концов, многие успешные стандарты начинают подобным образом. Однако это важно для понимания того, что произошло дальше.
В 1977 году, представители британской компьютерной промышленности предложили создание нового комитета по стандартам, посвящённого сетям с коммутацией пакетов, в рамках Международной Организации по Стандартизации (International Organization for Standardization, ISO), независимой негосударственной ассоциации созданной после Второй Мировой Войны. В отличии от CCITT, ISO не занималась исключительно телекоммуникациями: широта охвата тем включала технический комитет TC1 занятый стандартами на резьбу шурупов и TC17, работавший со сталью. Также, в отличии от CCITT, ISO уже имела в своём составе комитеты по компьютерным стандартам и могла быть более восприимчива к идеям датаграм без соединений.
Британское предложение, получившее поддержку представителей из США и Франции, призывало к созданию «сетевых стандартов необходимых для открытого взаимодействия». Эти стандарты, по мнению британцев, могли бы предложить альтернативу «замкнутым 'закрытым' системам» традиционных компьютеров, разработанных «без учёта возможности их совместной работы». Концепция открытого взаимодействия была как стратегической, так и технической, и говорила об их желании создать конкуренцию лидерам рынка, конкретно IBM и телекоммуникационным монополиям.
Многоуровневый подход: Референсная модель OSI (слева) разделяет связь между компьютерами на семь уровней, от физики на первом до приложений на седьмом. Хоть и менее строго, подход TCP/IP также может быть представлен в виде уровней, как показано справа.
Как и ожидалось, ISO согласилась с предложением британцев и назначила эксперта по базам данных из США Чарльза Бакмэна (Charles Bachman) главой комитета. Весьма уважаемый в околокомпьютерных кругах, Бакмэн получил четырьмя годами ранее престижную Премию Тьюринга за свою работу над системой управления базами данных Integrated Data Store.
Когда я брал интервью у Бакмэна в 2011 году, он описал то «архитектурное видение», которое он привнёс в OSI, то видение было вдохновлено его работой с базами данных вообще и архитектурой IBM Systems Network Architecture в частности. Он начал с определения референсной модели, которая разделяла различные задачи связи между компьютерами на множество уровней. На пример, физическая среда передачи (такая как медные кабели) попадает в первый уровень, транспортные протоколы для перемещения данных попадают в четвёртый уровень, а приложения (такие как электронная почта и передача файлов) находятся на седьмом уровне. После утверждения архитектуры на основе уровней, можно было приступать к разработке конкретных протоколов.
1974: IBM запускает сеть с коммутацией пакетов названную Systems Network Architecture.
1975: INWG направляет предложение в CCITT, комитет его отвергает. Серф покидает свой пост в INWG.
1976: CCITT публикует Рекомендацию X.25, стандарт пакетной коммутации, использующий «виртуальные цепи».
Разработка Бакмэна в значительной мере отличалась от Systems Network Architecture: тогда как IBM создавала архитектуру терминал-компьютер, Бакмэн соединял равноправные компьютеры. Этот подход сделал проект весьма привлекательным для таких компаний как General Motors, ведущего сторонника OSI в восьмидесятые годы. GM имела десятки заводов и сотни поставщиков, использующих смесь малосовместимых программных и аппаратных систем. Схема Бакмэна позволила бы объединить компьютеры и сети различных проприетарных типов — если они следовали стандартам OSI.
Многоуровневая референсная модель OSI давала также и важную организационную возможность: модульность. То есть деление на уровни позволило разделить работу над протоколами между комитетами. Явно, модель Бакмэна была лишь началом. Чтобы стать международным стандартом, каждое предложение должно было пройти через четыре стадии, начиная с рабочего черновика, далее черновика предлагаемого международного стандарта, потом черновика международного стандарта и, наконец, международного стандарта. Создание консенсуса вокруг референсной модели OSI и связанных с ней стандартов потребовало экстраординарного числа пленарных заседаний и собраний комитетов.
Первое пленарное заседание OSI продлилось три дня, с 28 февраля по 2 марта 1978 года. Собралось множество делегатов из десяти стран и наблюдатели из четырёх международных организаций. У всех участвовавших были свои рыночные интересы и готовые наработки. При этом, у делегатов из одной страны могли быть совершенно разные цели. Многие из собравшихся были ветеранами INWG, сохранившими осторожный оптимизм в отношении возможности вырвать будущее сетей из лап IBM и телекоммуникационных монополий, которые, вполне очевидно, планировали доминировать на новом рынке.
1977: Комитет ISO по взаимодействию открытых систем Open Systems Interconnection сформирован во главе с Чарльзом Бакмэном [слева]; среди других активных участников Юбер Зиммерман [по центру] и Джон Дэй (John Day) [справа].
1980: Министерство обороны США публикует «Стандарты Интернет Протокола и Протокола Управления Передачей» (“Standards for the Internet Protocol and Transmission Control Protocol”).
Одновременно, представители IBM, возглавляемые Джозефом Де Блэзи (Joseph De Blasi), весьма способным директором по стандартам в компании, мастерски направляли дискуссию, удерживая развитие OSI в рамках деловых интересов IBM. Информатик Джон Дэй, разрабатывавший протоколы для ARPANET, был ключевым членом делегации США. В своей книге 2008 года Паттерны в Архитектуре Сетей (Patterns in Network Architecture, изд. Prentice Hall), Дэй вспоминает, что представители IBM со знанием дела вмешивались в споры между делегатами «боровшимися за кусок пирога… IBM вертела ими как хотела. Это было завораживающее зрелище».
Несмотря на палки, вставляемые в колёса, лидерство Бакмэна двигало OSI по рискованному пути от замысла к реальности. Бакмэн и Юбер Зиммерман (ветеран Cyclades и INWG) добились альянса с телекоммуникационными инженерами из CCITT. Но это партнёрство с трудом преодолевало фундаментальную несовместимость их взглядов. Зиммерман и его коллеги от информатики, вдохновлённые конструкцией датаграм Пузана, боролись за протоколы без установления соединения, тогда как профессионалы от телекоммуникаций настаивали на виртуальных цепях. Вместо разрешения спора, они согласились включить оба варианта в рамках OSI, тем самым увеличивая его размеры и сложность.
Этот непростой альянс информатиков и связистов опубликовал международный стандарт на референсную модель OSI в 1984 году. Вскоре последовали отдельные стандарты OSI на транспортные протоколы, электронную почту, электронные справочники, управление сетью и многие другие функции. OSI начинал проявлять признаки своей неотвратимости. Ведущие компьютерные компании, такие как Digital Equipment Corp., Honeywell, и IBM, были к тому времени очень заинтересованы в OSI, наравне с Европейски Экономическим Сообществом (European Economic Community), правительствами стран Европы, Северной Америки и Азии.
Даже правительство США — ведущий спонсор протоколов Интернета, несовместимых с OSI — присоединилось к популярному проекту. Министерство обороны официально приняло заключение из рекомендаций Национального Исследовательского Совета (National Research Council) 1985 года о переходе от TCP/IP к OSI. Одновременно, министерство по торговле (Department of Commerce) издало в 1988 году мандат, предписывающий использование стандартов OSI на всех компьютерах, закупаемых правительством США после августа 1990 года.
Хотя такие указы и выглядят как работа передёргивающих бюрократов, следует вспомнить что в восьмидесятых годах Интернет был всего лишь исследовательской сетью: сеть быстро росла, но её администраторы не допускали коммерческий трафик или сторонних провайдеров на финансируемую правительством магистраль вплоть до 1992 года. Для компаний и других крупных организаций, желавших обмениваться данными между различными типами компьютеров или сетей, OSI оставался единственным вариантом.
January 1983: Требование министерства обороны США (U.S. Department of Defense) использовать TCP/IP в ARPANET отмечает “Рождение Интернета.”
May 1983: ISO публикует международный стандарт «ISO 7498: Базовая Референсная Модель Взаимосвязи Открытых Систем» (The Basic Reference Model for Open Systems Interconnection).
1985: Национальный Исследовательский Совет США (U.S. National Research Council) рекомендует мин.обороны постепенную миграцию от TCP/IP к OSI.
1988: Доход на рынке компьютерной связи США: 4.9 миллиарда долларов.
На этом, конечно, история не заканчивается. К концу восьмидесятых годов, негодование по поводу медленного развития OSI достигло критической отметки. В ходе собрания в Европе в 1989 году, защитник OSI Браэн Капентер (Brian Carpenter) выступил с речью озаглавленной «OSI уже опоздал?» («Is OSI Too Late»). Тот раз, как он вспоминает в своих недавних мемуарах, «был единственным случаем в моей жизни» когда он удостоился «стоячей овации на технической конференции». Двумя годами позже, французский эксперт по сетям и бывший член INWG, Пузан, в эссе озаглавленном «Десять лет OSI — Зрелость или Младенчество?» («Ten Years of OSI—Maturity or Infancy?») обозначил растущую неопределённость: «Правительственные и корпоративные нормативы постоянно рекомендуют OSI в качестве основного решения. Однако, гораздо проще и быстрее внедрить однородную сеть на базе проприетарных архитектур или объединить разнородные системы используя продукты на базе TCP». Даже для сторонников OSI, Интернет выглядел всё более привлекательно.
Ощущение обречённости усугублялось, прогресс замедлился и в середине девяностых, красивая мечта OSI наконец закончилась. Фатальным недостатком процесса, как бы иронично это не звучало, была приверженность к открытости. Формальные правила международной стандартизации давали любой заинтересованной стороне право участвовать в разработке, что приводило к общей напряжённости, несовместимости взглядов и давало путь подрывной деятельности.
Первый председатель OSI, Бакмэн, ожидал этих проблем с самого начала. В своей речи на конференции в 1978 году, он выказал обеспокоенность шансами OSI на успех: "[Стоящая перед нами] организационная задача велика. Технические проблемы больше, чем что-либо ранее известное в информационных системах. А политические проблемы заставят попотеть самого хитроумного государственного деятеля. Можете ли вы себе представить попытку привести в обозримом будущем к соглашению представителей десятка ведущих конкурирующих компьютерных корпораций, и десятка телефонных компаний, и PTT [государтсвенные телекоммуникационные монополии — прим.автора], и технических экспертов из десяти различных государств?"
1988: U.S. Department of Commerce предписывает правительственным организациям закупать только соответствующие OSI продукты.
1989: В то время как OSI начинает разваливаться, информатик Браэн Капентер выступает с речью «OSI уже опоздал?» завершающейся овацией.
1991: Тим Бёнес-Ли объявляет о публичном выпуске приложения WorldWideWeb.
1992: U.S. National Science Foundation пересматривает политику в отношении допуска коммерческого трафика в Интернете.
Несмотря на усилия Бакмэна и других людей, груз организационных проблем не спадал. Сотни инженеров присутствовали на встречах различных комитетов и рабочих групп OSI, а бюрократические процедуры, используемые для структурирования дискуссии, не давали быстро создавать стандарты. Спорили обо всём: даже о тривиальных нюансах языка (например, о разнице между оборотами «вы подчинитесь» и «вам следует подчиниться»). Гораздо более сложные вопросы разделяли экспертов от информатики и телекоммуникаций, чьи технические и бизнес-планы конфликтовали. Таким образом, открытость и модульность — ключевые принципы координации проекта — стали причиной краха OSI.
В тоже время, Интернет процветал. При достаточном финансировании со стороны правительства США, Серф и Кан со своими коллегами были защищены от сил международной политики и экономики. ARPA и Агентство по связи для обороны (Defence Communications Agency) ускорили внедрение Интернета в начале восьмидесятых годов, финансируя учёных для внедрения протоколов Интернет в популярных операционных системах, таких как вариант Unix от Университета Калифорнии, Беркли. Тогда, первого января 1983 года, ARPA прекратила поддержку межузлового протокола ARPANET, тем самым вынудив подрядчиков использовать TCP/IP, если они желали оставаться на связи; этот день известен как "день рождения Интернета".
Фото: Джон Дэй (John Day)
Что в имени?: В ходе заседания в июле 1986 годе в Newport, R.I., представители из Франции, Германии, Соединённого Королевства и США рассматривали вопрос работы референсной модели OSI с критическими функциями именования и адресации в сети.
Таким образом, пока многие пользователи ещё ждали, что OSI станет решением для глобального объединения сетей, всё большее число людей начинало использовать TCP/IP как практичное, пусть и временное, средство сетевого взаимодействия.
Инженеры, которые присоединялись к Интернет-сообществу в 1980-е часто не понимали OSI, высмеивая её ошибочную монструозность созданную ничего не смыслящими европейскими бюрократами. Инженер Маршал Роуз (Marshall Rose) писал в своём учебнике 1990 года, что «Сообщество Интернета очень старается игнорировать сообщество OSI. Вообще говоря, технологии OSI уродливы в сравнении с технологиями Интернет.»
К сожалению, негативный настрой Интернет-сообщества также приводил к отвержению хороших технических идей OSI. Классическим примером является «дворцовый переворот» в 1992 году. Хотя они и были далеки от уровня формальности той бюрократии, что создавала OSI, Интернет регулировали Совет по делам Интернета (Internet Activities Board) и Инженерный совет Интернета (Internet Engineering Task Force, IETF), которые отвечали за управление развитием стандартов. Именно такая работа проходила в 1992 году в Кэмбридже. Несколько лидеров, занятых пересмотром маршрутизации и ограничений адресации, не предусмотренных ранее при разработке TCP и IP, рекомендовали сообществу если не внедрить, то хотя бы рассмотреть некоторые технические протоколы, разработанные в рамках OSI. Сотни присутствовавших Интернет-инженеров рьяно выразили свой протест, а затем изгнали лидеров за такую ересь.
1992: В ходе «дворцового переворота, Интернет-инженеры отвергли ISO ConnectionLess Network Protocol, предложенный в качестве альтернативы IP версии 4.
1996: Интернет-сообщество разрабатывает IP версии 6.
2013: По IPv6 передаётся примерно 1 процент глобального Интернет трафика.
Хотя Серф и Кан не разрабатывали TCP/IP для применения в бизнесе, десятилетия государственной поддержки их исследований создали важное коммерческое преимущество: протоколы Интернет могли применяться бесплатно. Для сравнения, чтобы использовать стандарты OSI, компании, разрабатывавшие и продававшие сетевое оборудование, должны были приобретать у соответствующей группы ISO бумажные копии, по одной копии за раз. Марк Левийон (Mark Levilion), инженер французского подразделения IBM, в 2012 году сказал мне в ходе интервью об отходе индустрии от OSI к TCP/IP следующее: „С одной стороны, есть что-то что бесплатно, доступно и его нужно просто загрузить. А с другой, гораздо более проработанный проект, гораздо более завершённый, более сложный, но дорогой. Будучи директором по ИТ, что бы вы выбрали?“
К середине девяностых, Интернет стал стандартом де-факто для глобальной компьютерной сети. Поступив жестоко с создателями OSI, приверженцы Интернета перехватили идею „открытости“ и объявили её своей. Сегодня, они то и дело выступают за свободу „открытого Интернета“ от авторитарных правительств, регулирования и монополистов.
В свете успеха гибкого подхода Интернета, OSI часто описывают как негативный пример бюрократизированной „предупредительной стандартизации“ на незрелом переменчивом рынке. Акцент на недостатках, однако, упускает многие успехи, сделанные OSI: фокусирование внимания на последних достижениях техники сделало её источником ценного опыта (включая решение ряда серьёзных проблем) для поколения сетевых инженеров, которые позднее основали свои компании, были советниками при правительствах и преподавали в университетах по всему миру.
За гранью этих упрощённых понятий „успеха“ и „неудач“, история OSI содержит важные уроки, который следует усвоить инженерам, регуляторам и пользователям Интернета. Возможно, важнейшим из этих уроков является противоречивость понятия „открытости“. OSI выявила глубокое несоответствие между идеалистическими представлениями об открытости и политико-экономическими реалиями мировой сетевой индустрии. И крах OSI наступил потому, что не удалось примирить разнородные желания всех заинтересованных сторон. Что, в таком случае, это означает для жизнеспособности открытого Интернета?
Хотите узнать больше?
Эта статья является логическим продолжением статьи “‘Rough Consensus and Running Code’ and the Internet-OSI Standards War” 2006 года того же автора, опубликованной в IEEE Annals of the History of Computing. Атор подробнее рассматривает эти и другие темы в своей книге Open Standards and the Digital Age: History, Ideology, and Networks (Cambridge University Press, 2014).
В работе Джанет Эбэйт (Janet Abbate) Inventing the Internet (MIT Press, 1999) даётся прекрасное расмотрение событий, приведших Интернет к тому виду, который мы имеем сейчас.
Статья “INWG and the Conception of the Internet: An Eyewitness Account” Алекса МакКинзи, опубликованная в январском выпуске IEEE Annals of the History of Computing 2011 года, основана на документах сохранённых МакКинзи после его работы в International Networking Working Group, которые сейчас находятся в архиве института Чарльза Бэбиджа Университета Минесоты (Минеаполис).
Онлайн-книга Entrepreneurial Capitalism and Innovation: A History of Computer Communications, 1968–1988 Джеймса Пелки (James Pelkey) основана на интервью и документах, собранных им в конце 1980-х и начале девяностых, времени когда казалось, что OSI будет доминировать в будущих сетях. Проект Пелки также описан в блоге Музея Истории Компьютеров в посте посвящённом сорокалетию Ethernet.
Комментарии (32)
AndyGrom
30.04.2015 18:54Забавная статья. Насколько я понял, OSI, кроме модели, которая описана в учебниках, ещё и разрабатывала непосредственно реализации протоколов для каждого уровня. Т.е. от деятельности OSI осталась только модель, а уже конкретные протоколы Интернета были предложены DARPA.
От статьи остаётся ощущение, что OSI провалилась полностью и покрыта забвением, и у меня вопрос:
Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов), а HTTP просто объединил в себе три последних прикладных уровня.
Картинка для напоминания…
Sing
30.04.2015 19:35> Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Умоляю, не придумывайте свои названия для TCP/IP. Вместо HTTP может быть хотя бы HTTPS или вообще FTP, а вместо Ethernet — Wi-Fi или LTE. Но ведь это не другой стек. На вопрос я ответил выше — не то что укладываются, это, по-сути, одно и то же, только в название вошли два самых популярных протокола — TCP и IP. Хотя вместо TCP может быть UDP, а вместо IP — IPSec или ICMP.
> Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов)
100-BASE-T (Fast Ethernet) и им подобные не являются протоколами, это стандарты и, по сути, являются дополнением к самому Ethernet, у которого структура кадра, алгоритм работы и т.д. остаются одними и теми же. Но да, стандарты-то разные, так что тут много спекуляций и нет единого решения. Как правило, людям проще понимать и запоминать, если включать физический уровень.
> а HTTP просто объединил в себе три последних прикладных уровня.
А тут тоже можно подискутировать. Например, сказать, что TLS (и ранее SSL) — это и сеансовый уровень (учитывая, что между узлами устанавливается связь, для которой выделяется сеансовый ключ), и также уровень представления, т.к. он шифрует данные (меняет представление), не меняя самих данных.stepik777
30.04.2015 21:44Умоляю, не придумывайте свои названия для TCP/IP. Вместо HTTP может быть хотя бы HTTPS или вообще FTP, а вместо Ethernet — Wi-Fi или LTE.
Ну а вместо TCP может быть UDP. Так что TCP/IP тоже не очень правильное название.Sing
30.04.2015 22:53Да, я об этом написал. Название — не очень правильное, но оно исторически такое, и в стандартах, и в «быту». А так, там больше сотни протоколов, но новые названия для стека точно ни к чему.
askbow Автор
30.04.2015 20:56От OSI осталась не только модель (которая в учебниках и ГОСТ), но и как минимум протокол маршрутизации IS-IS.
Конкретные протоколы Интернета созданы, всё-таки, участниками IETF, DARPA — это больше источник (распределитель) финансирования. Подробнее о том что, в каком порядке и кто предложил или разработал можно посмотреть, например, в книге Where wizards stay up late (не смог сходу найти ничего лучше чем amazon).
Конечно, при желании вы можете многое уложить в модель. Но это постфактум. Однако, стек TCP/IP не разрабатывался в рамках модели OSI. Он разрабатывался другими инженерами, в другой организации, для несколько другой сети. То как он нарисован напротив модели OSI на иллюстрации — это, скорее, условность. Возможно — даже подгон желаемого к действительному (или наоборот). Такой подгон делают, отчасти, что бы хоть как-то обосновать присутствие модели OSI в учебнике (и после этого, обычно, на оставшиеся 800 страниц учебника про неё забывают), отчасти потому что, как верно замечает выше amarao, в ней всё по полочкам и с моделью OSI удобнее рисовать графики и таблички.Sing
30.04.2015 23:23+2> Такой подгон делают, отчасти, что бы хоть как-то обосновать присутствие модели OSI в учебнике (и после этого, обычно, на оставшиеся 800 страниц учебника про неё забывают)
Такие понятия как L2 и L3 коммутаторы без моодели OSI бессмысленны. Без модели сложно объяснить, почему коммутатор не может быть шлюзом. Почему можно поменять TCP на UDP и всё будет работать, а почему нельзя поменять TCP на… HTTP или IP, например? Для чего нужна MAC адресация, если есть IP? И как вообще обмениваться данными с двухадресным устройством?
А ещё есть не-TCP/IP передача данных. Например, в промышленной автоматизации с кучей своих шин, а ещё ISDN, Dial-Up и множество разных и интересных вещей.askbow Автор
01.05.2015 10:02+1L3 коммутатор в IP — это просто маршрутизатор. Само понятие «L3 коммутатор» отделили от маршрутизаторов, скорее, по маркетинговым соображениям.
В модели TCP/IP L2 коммутаторы Ethernet (которые просто эмулируют общую шину) не являются необходимостью.
Про это редко говорят в учебниках, из-за OSI-мышления, но вы можете поменять TCP на UDP и [почти] всё будет работать. Вы также можете прилепить HTTP сразу поверх IP, если ваши оконечные узлы (а также любые устройства на пути трафика из числа нарушающих принцип end-to-end, например NAT) будут это поддерживать. Често, просто напишите соответствующий код. Оно [наверняка] не будет ни с чем больше совместимо (потому что редко кто так поступает), но вы, однако, можете это сделать. Вы можете настекировать двадцать разных заголовков друг на друга, если это поможет вашим данным передаваться лучше.
МАС адресация на нужна. Всё равно многие соединения — это точка-точка. МАС адреса были нужны во времена общей шины Ethernet (и, кажется, кольца TokenRing), чтобы станция на шине могла определить, следует ли ей принять и обработать фрейм с провода. Это атавизм от которого не могут отказаться по неким соображениям, например обратной совместимости. Вот, наверное, для этой совместимости в Ethernet и сохраняют МАС-адреса.
А как сейчас обмениваются данными с двухадресным устройством? Или я не понял вопрос, или возьмите в пример IPv6, где у каждого устройства на каждом интерфейсе может спокойно быть по несколько адресов.
Не TCP/IP передача данных — отдельный вопрос. Там, в промышленной автоматизации, тоже у каждого инженера своя голова и каждый, в первую очередь, проектировал как было нужно для его станка/установки. Некоторые могли отталкиваться от модели OSI, другие нет.
В дайлапе, ведь, поверх физики (которая, между делом, где-то по середине может пересекать ISDN-сеть) работает, скажем, PPP. А для доступа в Интернет по дайлапу, поверх PPP пускают IP.
Интересных вещей много, да. Сети вообще очень разнообразны. Не от хорошей жизни, полагаю. «Если бы всё пошло по плану» — всё было бы OSI. Однако от разнообразия мы рано или поздно придём к общему знаменателю. Наверное это будет IP.Sing
04.05.2015 21:42> L3 коммутатор в IP — это просто маршрутизатор. Само понятие «L3 коммутатор» отделили от маршрутизаторов, скорее, по маркетинговым соображениям.
Эээ, нет. L3 коммутатор — это-таки коммутатор, при том что он может иметь функции третьего уровня (при этом быть дешевле маршрутизатора, в чём его плюс). Да, он может поддерживать все протоколы третьего уровня, включая маршрутизирующие, но главное отличие коммутаторов и маршрутизаторов — свой IP и MAC для КАЖДОГО порта у L3 коммутаторов не сохраняется. Например, многие домашние «роутеры» (у которых всего 1 WAN порт, а все остальные — LAN + Wi-Fi) — это как раз-таки не маршрутизаторы, а коммутаторы третьего уровня, именно что по маркетинговым соображениям названные маршрутизаторами.
> В модели TCP/IP L2 коммутаторы Ethernet (которые просто эмулируют общую шину) не являются необходимостью.
В Ethernet общей шины нет уже 35 лет, так что про эмуляцию шины я не понял. И я как бы говорил об объяснении L2 коммутаторов через модель OSI, а не TCP/IP.
>Про это редко говорят в учебниках, из-за OSI-мышления, но вы можете поменять TCP на UDP и [почти] всё будет работать. Вы также можете прилепить HTTP сразу поверх IP, если ваши оконечные узлы (а также любые устройства на пути трафика из числа нарушающих принцип end-to-end, например NAT) будут это поддерживать. Често, просто напишите соответствующий код. Оно [наверняка] не будет ни с чем больше совместимо (потому что редко кто так поступает), но вы, однако, можете это сделать. Вы можете настекировать двадцать разных заголовков друг на друга, если это поможет вашим данным передаваться лучше.
Про TCP и UDP я точно также написал выше. С остальным согласен, даже дополню: можно вообще обойтись и без HTTP, и без IP, и без Ethernet, а просто написать низкоуровневый код для сетевой карты и отправлять свои биты, свои заголовки и вообще всё своё. Но никто этого не делает, конечно же: зачем, если всё это уже сделано до нас?
> МАС адресация на нужна. Всё равно многие соединения — это точка-точка. МАС адреса были нужны во времена общей шины Ethernet (и, кажется, кольца TokenRing), чтобы станция на шине могла определить, следует ли ей принять и обработать фрейм с провода. Это атавизм от которого не могут отказаться по неким соображениям, например обратной совместимости. Вот, наверное, для этой совместимости в Ethernet и сохраняют МАС-адреса.
MAC адресация не нужна в идеальном мире. Как и IPv4, например. В существующем — нужна, без этого сети не смогут работать. Самое главное применение MAC адресов на данный момент — поиск IP адреса: не нужно угадывать подсеть и адрес устройства, можно найти его по LLDP. Сильно помогает при первоначальной настройке множества узлов (когда IP один на всех, или его вообще нет) и при техобслуживании. Когда-нибудь уйдёт IPv4, скорее всего уйдёт и Ethernet вместе с MAC-ами, будет один большой IPv6 над всеми, кто знает. Но это будет не скоро, по многим причинам.
> А как сейчас обмениваются данными с двухадресным устройством? Или я не понял вопрос, или возьмите в пример IPv6, где у каждого устройства на каждом интерфейсе может спокойно быть по несколько адресов.
Вопрос был риторический. Но если вы студент или школьник, без понимания разноуровневых протоколов, сложно объяснить, как общаться между узлами. Инкапсуляция, вот это всё.
> Не TCP/IP передача данных — отдельный вопрос. Там, в промышленной автоматизации, тоже у каждого инженера своя голова и каждый, в первую очередь, проектировал как было нужно для его станка/установки. Некоторые могли отталкиваться от модели OSI, другие нет.
В промышленной автоматизации всё движется в сторону TCP/IP. Даже не движется, а уже давно используется. Однако, те самые шины должны быть внедрены в общую систему. Которую, вероятно, делают уже другие инженеры.
> Однако от разнообразия мы рано или поздно придём к общему знаменателю. Наверное это будет IP.
Скорее всего. Однако, сам IP не так-то просто модифицировать и изменить. Об IPv6 уже сто-о-о-олько лет мечтают все сетевики, хостеры, вебмастера и прочие, а вот всё никак.JDima
05.05.2015 18:19+1>L3 коммутатор — это-таки коммутатор, при том что он может иметь функции третьего уровня (при этом быть дешевле маршрутизатора, в чём его плюс).
Грань между этими устройствами давно размыта. И уж говорить, что L3 свитч дешевле роутера, очень странно. L3 свитч всегда дороже программного роутера. С хардварными роутерами он вообще брат-близнец по архитектуре, различия маркетинговые. Любой нормальный роутер тоже может коммутировать.
>главное отличие коммутаторов и маршрутизаторов — свой IP и MAC для КАЖДОГО порта у L3 коммутаторов не сохраняется
Серьезно? Взять например цискины каталисты (свитчи), от какого-нибудь 3560 до 6500. При желании можно каждому физическому порту назначить свои IP и MAC. Получается, это уже роутеры? А можно на четырех портах железки включить роутинг, а остальные в один VLAN засунуть. А еще могу взять полноценный программный роутер, скажем, 2901, и настроить бриджинг с STP между его двумя портами, получу двухпортовый свитч.
>Например, многие домашние «роутеры» (у которых всего 1 WAN порт, а все остальные — LAN + Wi-Fi) — это как раз-таки не маршрутизаторы, а коммутаторы третьего уровня, именно что по маркетинговым соображениям названные маршрутизаторами.
Неверно. Домашние роутеры — это на самом деле связка из двух устройств. Представьте себе блок-схему "----(роутер)----(свитч)====(компы)". Те «роутер» и «свитч» внутри устройства физически разделены. Разве что интерфейс управления общий. С таким же успехом можно взять отдельно двухпортовый роутер и отдельно пятипортовый свитч, соединив их проводком и смотав скотчем.
>Самое главное применение MAC адресов на данный момент — поиск IP адреса: не нужно угадывать подсеть и адрес устройства, можно найти его по LLDP.
Можно развернуть мысль? LLDP — management plane. Есть костыли, запрягающие его под control plane, но это экзотика.
В целом, если вся сеть L3, потребность в ARP отпадает. Можно было бы вообще всегда слать все пакеты на ffff.ffff.ffff. Все равно устройство по ту сторону патч-корда будет маршрутизировать либо декапсулировать пакет и передавать его приложению. Это в случае ethernet.
>Об IPv6 уже сто-о-о-олько лет мечтают все сетевики, хостеры, вебмастера и прочие, а вот всё никак.
О нем мечтают по той же причине, по которой владелей погибающей кобылы мечтает о новой кобыле. Ехать-то надо. Все преимущества IPv6 за исключением адресного пространства не стоят того, чтобы идти на такой геморрой.Sing
05.05.2015 20:59> И уж говорить, что L3 свитч дешевле роутера, очень странно. L3 свитч всегда дороже программного роутера. С хардварными роутерами он вообще брат-близнец по архитектуре, различия маркетинговые. Любой нормальный роутер тоже может коммутировать.
Роутер может коммутировать, свитч — не может маршрутизировать на всех портах и не может делать свою подсеть на каждый порт. Причём тут программные роутеры?
> Серьезно? Взять например цискины каталисты (свитчи), от какого-нибудь 3560 до 6500. При желании можно каждому физическому порту назначить свои IP и MAC.
Да? Я не силён в Cisco, прошу привести мануал. Поискал сам, нашел только IP для всего коммутатора: www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swipaddr.htmlJDima
05.05.2015 22:19>Роутер может коммутировать, свитч — не может маршрутизировать на всех портах и не может делать свою подсеть на каждый порт.
Да? У меня множество свитчей, способных маршрутизировать на каждом порту. Своя сеть, свой мак, да. Еще ACL'ей навешать, QoSов и тому подобного.
>Я не силён в Cisco, прошу привести мануал.
Это относится не только к цискам, но и ко всем худо-бедно приличным L3 свитчам, где «L3» не просто для галочки.
Команда «no switchport» превращает порт в маршрутизируемый, ее и надо искать. Дальше, конечно, есть нюансы в зависимости от платформы. Например, на 6500 с супами 32/720 нельзя иметь суммарно более 4096 (или около того) VLANов и маршрутизируемых портов. Если у железки всего десятки VLAN'ов (а не тысячи), то все ее порты (сотни) могут роутить. Ограничение идет от того, что каждому маршрутизируемому интерфейсу (физический порт, саб, int vlan — неважно) железка втихую от администратора назначает свой внутренний номер VLAN'а, и использовать этот номер под другие задачи нельзя. У 2T с этим получше, там одно с другим не смешано, вроде 16к бридж-групп с допустимым пересечением номеров VLAN'ов.
>В смысле физически разделены? Это вполне себе одночиповые (SoC) устройства.
Свитчит на таких железках всегда ASIC. Роутингом обычно занимается general purpose CPU (в хомячковых устройствах как правило на ARM).
В том медиатеке «integrated 6-port Ethernet switch (MT7530) with five 10/100 PHYs». Ну да, получается, что тот свитч (ASIC) засунули в один корпус с ЦП, не знал, что так делают. Только это все равно физически разные устройства, хоть и размещенные под боком друг у друга. Вынесли бы из корпуса на шину PCI-E, ничего бы не изменилось кроме, может, стоимости (два чипа дороже чуть более толстого одного).
>Я не понял, что нужно разворачивать в мысли про поиск устройства протоколом поиска устройств (Link Layer Discovery Protocol).
Но это не для передачи данных. Просто для того, чтобы посмотреть, что находится за тем портом. С тем же успехом можно взять mac-arp-rdns (если надо). Причем тут поиск IP адреса не очень понял.
Или речь и идет сугубо про менеджмент? Но какой смысл делать это руками, если оно часто требуется? Скрипт, выполняющий две команды, пишется минут за 10 от силы, и готовых решений полно. Для клиентских подключений есть классная таблица dhcp snooping, в которой сразу порт, мак и IP, и они долго не експайрятся.
>И в коммутаторах, да…
Учитывая, что без поллитры не отличишь взрослый коммутатор от взрослого маршрутизатора — конечно. Ну да, есть тонкие нюансы — у роутеров обычно будет более гибкий QoS, шире выбор интерфейсов, меньше их число и т.д… Но эти отличия слишком мелочны, чтобы разделять устройства по разным классам. И внутри одного класса будет полно различий. Свитч 6500/sup2T против свитча 3750 — небо и земля по возможностям. Так что сейчас позиционирование серьезных железок скорее маркетинговое. Слабо по картинкам и списку фич определить, кто из следующих роутер, а кто — свитч? Nexus 7000, ASR 9000, Catalyst 6500, Catalyst 7600. Смотрим только крупные шасси, для (не)наглядности.
>Тут даже спорить нет смысла, т.к. всегда эта тема — сплошная спекуляция.
Те моменты, которые я затрагиваю, совершенно объективны.Sing
05.05.2015 23:55Да, про Cisco с их изменением портов не знал, спасибо. Хоть и там, как вы и пишете, есть ограничения.
> Но это не для передачи данных. Просто для того, чтобы посмотреть, что находится за тем портом. С тем же успехом можно взять mac-arp-rdns (если надо). Причем тут поиск IP адреса не очень понял.
Или речь и идет сугубо про менеджмент? Но какой смысл делать это руками, если оно часто требуется? Скрипт, выполняющий две команды, пишется минут за 10 от силы, и готовых решений полно. Для клиентских подключений есть классная таблица dhcp snooping, в которой сразу порт, мак и IP, и они долго не експайрятся.
Я про то, что если у нас есть устройство. Любое, об IP которого мы ничего не знаем и у которого нет консольного порта, а нам очень хочется к нему подключиться. И DHCP у него выключен. Куда тут без LLDP?
> Ну да, есть тонкие нюансы — у роутеров обычно будет более гибкий QoS, шире выбор интерфейсов, меньше их число и т.д… Но эти отличия слишком мелочны, чтобы разделять устройства по разным классам. И внутри одного класса будет полно различий. Свитч 6500/sup2T против свитча 3750 — небо и земля по возможностям.
Я понял в чём дело. Вы говорите языком ISP, с Cisco-размерами и прочими вещами, я же — нет. В таких игрушках, конечно, границы уже стираются. В не-ISP мире они ещё живы, тем не менее.JDima
06.05.2015 08:42>Да, про Cisco с их изменением портов не знал
Причем тут Cisco? Это просто близкий мне пример. Любое оборудование худо-бедно приличных вендоров может так же, со своими нюансами.
>Хоть и там, как вы и пишете, есть ограничения.
У серьезных хардварных роутеров ограничений тоже мама не горюй, если сравнивать с программными. В самых неожиданных местах.
>Я про то, что если у нас есть устройство. Любое, об IP которого мы ничего не знаем и у которого нет консольного порта, а нам очень хочется к нему подключиться. И DHCP у него выключен. Куда тут без LLDP?
Известно только что оно подключено к такому-то порту, что у него включен LLDP и что оно своё (на него можно зайти)? Религия запрещает посмотреть по порту мак, из arp таблицы вытащить IP адрес и собственно зайти на него? Либо, что более правильно, просто заглянуть в документацию или дескрипшн порта и узнать, что там? LLDP лишь немного экономит время, никакого «куда тут без» нет.
>Вы говорите языком ISP
Я не имею никакого отношения к ISP. Причем тут провайдеры?
>В не-ISP мире они ещё живы, тем не менее.
Конечно. И — о ужас — там иногда тоже используют нормальное оборудование. Смысл зацикливаться на SOHO решениях?
Sing
05.05.2015 21:27Случайно нажал Написать у предыдущего комментария.
> Неверно. Домашние роутеры — это на самом деле связка из двух устройств. Представьте себе блок-схему "----(роутер)----(свитч)====(компы)". Те «роутер» и «свитч» внутри устройства физически разделены. Разве что интерфейс управления общий. С таким же успехом можно взять отдельно двухпортовый роутер и отдельно пятипортовый свитч, соединив их проводком и смотав скотчем.
В смысле физически разделены? Это вполне себе одночиповые (SoC) устройства. Ну вот возьмём MediaTek с их чипами: wikidevi.com/wiki/MediaTek_MT7620 Это тоже два устройства?
> Можно развернуть мысль? LLDP — management plane. Есть костыли, запрягающие его под control plane, но это экзотика.
Какой ещё management и control? Управлять через протокол поиска? Я не понял, что нужно разворачивать в мысли про поиск устройства протоколом поиска устройств (Link Layer Discovery Protocol).
> В целом, если вся сеть L3, потребность в ARP отпадает.
И в коммутаторах, да…
> Все преимущества IPv6 за исключением адресного пространства не стоят того, чтобы идти на такой геморрой.
Тут даже спорить нет смысла, т.к. всегда эта тема — сплошная спекуляция.
Busla
30.04.2015 21:26> Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?
Совокупность протоколов — это «семейство» (suite). Стеком обычно именуют реализацию. Все укладывания TCP/IP в модель OSI — это просто идеи создания универсального сетевого стека (API) внутри ОС.
Модель OSI разрабатывалась, когда TCP/IP уже существовала. Во-первых, они пытались устранить «фундаментальный недостаток», т.е. реализовать несколько иные принципы. Во-вторых, чисто «политически» как бы это выглядело: описали существующее, добавили несколько фич и назвали своим стандартом?
stepik777
30.04.2015 21:58+1Один из недостатков модели OSI, в том, что она предлагает реализовывать шифрование на довольно высоких уровнях, в то время как оно должно быть расположено настолько низко, насколько возможно, т.е. ниже транспортного уровня, как в IPsec.
JDima
02.05.2015 00:26+1Когда вы аутентифицировались на geektimes, было кратковременно задействовано «L6» шифрование. HTTPS.
IPSec — на самом деле адское нагромождение костылей, плохо дружащее с другими костылями (NAT, любой stateful анализ) и требующее для этого отдельных костылей. Если есть просто два устройства, которые вдруг захотели зашифровать трафик между собой — наиболее логично шифровать именно на «L6», поблизости от приложения. Если какое-то промежуточное устройство начинает шифровать транзитный трафик (создает туннель) — да, тут надо надо бы пониже.
amarao
Подводя итоги:
Модель OSI писалась телекомщиками (телефонистами) и бюрократами и в полной мере учитывала интересы операторов телефонной связи и бюрократов.
Модель TCP/IP писалась бородатыми хакерами для себя и в полной мере учитывала интересы пользователей сети и разработчиков ПО для работы с сетью.
В модели OSI было очень комфортно ходить по уровням, раскладывать по красивым графикам и табличкам, где всё гладенько и ровно, а так же очень удобно пускать голосовой трафик. Интересы программистов при этом никого не волновали, а пользователи, которым этим было бы удобно пользоваться должны были ощущать удобство при использовании телефонной связи.
А бородатые хакеры хотели быстро и офигенно. С плохо выраженными уровнями (ARP/IP), с начхательством на стандарты для того, что ещё не существует (всякие «presentation level»). И оно получилось достаточно простым, чтобы его можно было реализовать в любой ОС без команды с waterfall на десять лет, достаточно эффективно, чтобы пролазить через любой канал связи и при этом работать не смотря на его качество, и достаточно понятно, чтобы любой начинающий за неделю полностью осваивался с терминологией и объектами.
Очевидно, OSI умерла. Настолько умерла, что сейчас даже связисты уже переходят на пакетную коммутацию.
ha7y
Ох, надо было сразу отмотать на этот комментарий! Спасибо!
Sing
Хм. OSI умерла? Скорее, она даже не рождалась. Однако, именно её идеи и легли всюду, куда только можно, а её модель используется для взаимопонимания и поныне.
Как -то не сильно отличаются бородатые хакеры от бюрократов, учитывая, что модели отличаются только тем, что прикладной уровень поглотил представления и сеансовый (так как все три описывают программные вещи), а насчёт того, различаются ли в TCP/IP физический и канальный уровни, ходят споры ( en.wikipedia.org/wiki/Internet_protocol_suite#Layer_names_and_number_of_layers_in_the_literature ). С одной стороны, сложно представить разные физические уровни для Wi-Fi, а с другой — Ethernet соединения могут быть и по меди, и по оптике, и с разной скоростью.
> С плохо выраженными уровнями (ARP/IP),
Эм. А чем они плохо выражены?
> стандарты для того, что ещё не существует (всякие «presentation level»).
По-сути, идея была в том, что одно и то же можно передавать разными способами (например, через XML, JSON). По замыслу, здесь должна была бы происходить сериализация.
amarao
arp — датаграмма или фрейм?
Sing
По сути, датаграмма и фрейм — это одно и то же, только у разных уровней. Transmisson unit мне больше нравится, того самого бюрократизма меньше.
А если по определению RFC 1594:
Datagram — A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network.
То точно фрейм, т.к. не выполняется «carrying sufficient information to be routed from the source to the destination computer» — адрес неизвестен, он широковещательный. Да и к «entity of data» и «self-contained» можно придраться.
amarao
Ответы на arp не широковещательные и в общем случае могут быть отмаршрутизированы (но зачем?)
С другой стороны: бродкастная датаграмма — это не датаграмма?
Sing
> Ответы на arp не широковещательные и в общем случае могут быть отмаршрутизированы (но зачем?)
Это не стандартное поведение. RFC 826 чётко указывает:
Send the packet to the (new) target hardware address on the same hardware on which the request was received.
> С другой стороны: бродкастная датаграмма — это не датаграмма?
Интересное словосочетание — «бродкастная датаграмма». То есть, кому-то может понадобиться отсылать данные сразу всем? Широковещание пока ещё используется (хоть это и плохая практика) для поиска: в ARP — для поиска MAC по IP, в DHCP — для поиска сервера. Корректно ли говорить что передаются данные? Я думаю, нет.
splav_asv
А что же тогда передается?
Sing
Техническая информация. С одной стороны, да, это тоже данные, хоть и бесполезные для человека — они только помогают передавать полезную нагрузку, которую и принято называть данными.
amarao
А что такого странного в бродкастном UDP? Любой протокол может включать в себя бродкасты, и виндовая сетка отличный тому пример. DHCP всего лишь один из примеров, причём довольно специфичный (т.к. там есть ip 0.0.0.0), но есть бродкасты с юникастного адреса — и это вполне себе часть IP протокола.
lubezniy
Рассыльщики спама давно об этом мечтают.
stardust_kid
У нее родился внук по имени XHTML2
amarao
Ага, ага.
JC_Piligrim
Пожалуй, вывод можно ещё более сократить до старого, как мир: «Будь проще — и к тебе люди потянутся». :)
amarao
KISS и т.д.
Проблема же в другом — как сделать так, чтобы получившееся было при этом универсальным, высокофункциональным и при этом очень простым.
Очень, очень сложно придумать такое. Задним числом очевидно, а когда думаешь о проблеме в будущем времени, не имея примеров удачного решения той же проблемы, свалиться в «OSI-style» проще, чем кажется. Потому что с точки зрения grand design OSI проще, чем TCP/IP. Её проще объяснять и сформулировать.