tanenbaum_seti_all.pages (525408), страница 17
Текст из файла (страница 17)
Он описывает параметры и ожидаемый результат. Он также ничего не сообщает о внутреннем устройстве уровня. Наконец, разноранговые протоколы, применяемые в уровне, являются внутРенним делом самого уровня. для выполнения поставленной ему задачи (то есть предоставления сервиса) он может использовать любые протоколы. Кроме того, уровень может менять протоколы, не затрагивая работу приложений более высоких уровней. Эти идеи очень хорошо соответствуют современным идеям объектно-ориентированного программирования. Уровень может быть представлен в виде объекта„ обладающего набором методов (операций), к которым может обращаться внешвин процесс.
Семантика этих методов определяет набор служб, предоставляемых объектом. Параметры и результаты методов образуют интерфейс объекта. ВнутРеннее устройство объекта можно сравнить с протоколом уровня. За пределами объекта оно никого не интересует и никому не видно. Изначально в модели ТСР/1Р не было четкого разделения между службами, интерфейсом и протоколом, хотя и производились попытки изменить это, чтобы 70 Глава П Введение сделать ее более похожей на модель 051. Так, например, единственными настоящими сервисами, предоставляемыми межсетевым уровнем, являются БЕН1) 1Р РАСКЕТ (послать 1Р-пакет) и ВЕСЕ1ЧЕ 1Р РАСКЕТ (получнть 1Р-пакет).
В результате в модели ОБ1 протоколы скрыты лучше, чем в модели ТСР/! Р, и при изменении технологии они могут быть относительно легко заменены. Возможность проводить подобные изменения — одна из главных целей многоуровневых протоколов, Эталонная модель ОЯ была разработана прежде, чем были изобретены протоколы для нее. Такая последовательность событий означает, что эта модель не была настроена на какой-то конкретный набор протоколов, что сделало ее универсальной.
Обратной стороной такого порядка действий было то, что у разработчиков было мало опыта в данной области н не было четкого представления о том, какие функции должен выполнять каждый уровень. Например, уровень передачи данных изначально работал только в сетях с передачей от узла к узлу. С появлением широковещательных сетей в модель потребовалось ввести новый подуровень. Когда же на базе модели ОБ1 начали строить реальные сети с использованием существующих протоколов, обнаружилось, что они не соответствуют требуемым спецификациям служб.
Поэтому в модель пришлось добавить подуровни для устранения несоответствия. Наконец, изначально ожидалось, что в каждой стране будет одна сеть, управляемая правительством и использующая протоколы ОБ1, поэтому никто и не думал об объединении различных сетей. В действительности все оказалось не так. С моделью ТСР/1Р было все наоборот; сначала появились протоколы, а уже затем была создана модель, описывающая существующие протоколы.
Таким образом, не было проблемы с соответствием протоколов модели. Они ей соответствовали прекрасно. Единственной проблемой было то, что модель не соответствовала никаким другим стекам протоколов. В результате она не использовалась для описания каких-нибудь других сетей, отличных от ТСР/1Р. Если взглянуть на эти две модели поближе, то прежде всего обратит на себя внимание различие в количестве уровней: в модели 031 семь уровней, в модели ТСР/1Р— четыре. В обеих моделях имеются межсетевой, транспортный и прикладной уровни, а остальные уровни различные.
Еще одно различие между моделями лежит в сфере возможности использования связи на основе соединений и связи без установления соединения. Модель 031 на сетевом уровне поддерживает оба типа связи, а па транспортном уровне — только связь на основе соединений (поскольку транспортные службы являются видимыми для пользователя). В модели ТСР/1Р на сетевом уровне есть только один режим связи (без установления соединения), но па транспортном уровне он поддерживает оба режима, предоставляя пользователям выбор. Этот выбор особенно важен для простых протоколов «запрос — ответ».
Критика модели и протоколов ОЗ! Ни описанные ранее модели (031 и ТСР/1Р), нн нх протоколы не являются совершенными. Довольно много критики было высказано по поводу обеих моделей. Эталонные модели 71 Некоторые критические замечания мы рассмотрим в данном и в следующем разделах, Сначала проанализируем модель 031, а затем ТСР/1Р.
я то время, когда вышло второе (английское. — Примеч. ред.) издание этой книги (1989), многим экспертам в данной области казалось, что модель ОЯ! и ее протоколы завоюют весь мир и вытеснят все остальное. Этого не случилось. Почемуг Может быть, полезно оглянуться и учесть некоторые из уроков этой истории, Основных причин неудачи модели 081 было четыре: + несвоевременность; + неудачная технология; + неудачная реализация; + неудачная политика.
Несвоевременность Прежде всего рассмотрим причину номер один: несвоевременность. Для успеха стандарта чрезвычайно важно, в какое время он устанавливается. У Дэвида Кларка (ВачЫ С1агк) из М.1.Т. есть теория стандартов, которую он называет апокалипсисом двух слонов (рис. 1.19). Время Рис. 1.19. Апокалипсисдвух слонов На этом рисунке изображена активность, сопровождающая любую новую разработку, Открытие новой темы вначале вызывает всплеск исследовательской активности в виде дискуссий, статей и собраний. Через некоторое время наступает сиад активности, эту тему открывают для себя корпорации, и в результате в нее инвестируются миллиарды долларов.
Существенным является то, что стандарты пишутся именно в период межлу двумя кслонами». Если их создавать слишком рано, прежде чем закончатся исследования, предмет может оказаться еще слишком мало изучен и понят, что повлечет принятие плохих стандартов. Если создавать их слишком поздно, комцаиии могут успеть вложить деньги в несколько отличные от стандартов технологии, так что принятые стандарты могут оказаться проипюрированнымн. Если интервал между двумя пиками активности будет слишком коротким (а все стре- 72 Глава 1. Введвние ся делать деньги как можно быстрее), разработчики стандар е успеть их выработать. Теперь становится ясно, почему стандартные протоколы 091 потерпели неудачу, К моменту их появления среди исследовательских университетов уже получили широкое распространение конкурируюгдие с ними протоколы ТСР/1Р.
И хотя волна инвестиций еще не обрушилась на данную область, рынок университетов был достаточно широк для того, чтобы многие разработчики стали осторожно предлагать продукты, поддерживающие протоколы ТСР/1Р. Когда же появился 081, разработчики не захотели поддерживать второй стек протоколов; таким образом, начальных предложений не было. Каждая компания выжидала, пока первым начнет кто-пибудь другой, поэтому 031 так никто и не стал поддерживать. Плохая технология Второй причиной, по которой модель 081 не была реализована, оказалось несовершенство как самой модели, так и ее протоколов. Выбор семиуровневой структуры стал больше политическим решением, чем техническим. В результате два уровня (сеансовый и уровень представления) почти пусты, тогда как два других (сетевой и передачи данных) перегружены.
Эталонная модель 081 вместе с соответствующими определениями служб и протоколами оказалась невероятно сложной. Если сложить в стопку распечатку официального описания стандартов, получится кипа бумаги высотой в один метр. Модель тяжело реализуема и неэффективна в работе. В этом контексте вспоминается шутка Пола Мокапетриса (Рап! Мое!сарегг!з), процитированная в издании Козе, 1993. Вопрос. Что получится, если скрестить гангстера с международным стандартом? Ответ. Человек, делаклций вам предложения, которые вы не способны понять. Еще одна проблема, помимо невозможности понять стандарты 081, заключалась в том, что некоторые функции, такие как адресация, управление потоком и обработка ошибок, повторялись снова и снова в каждом уровне.
Так, например, в книге Яа!!гег и др. (1984) указывается, что для того, чтобы контроль за ошибками был эффективным, оц должен осуществляться на самом верхнем уровне, поэтому повторение его снова и снова на каждом уровне часто оказывается излишним и неэффективным. Неудачная реализация Учитывая огромную сложность модели и протоколов, громоздкость и медлительность первых реализаций не стали неожиданностью. Неудачу потерпели все, кто попытался реализовать эту модель.
Поэтому вскоре понятие «051» стало ассоциироваться с плохим качеством. И хотя со временем продукты улучшились, ассоциации остались. Первые реализации ТСР/1Р, основанные на Вегк1еу ПХ!Х, напротив, были достаточно хороши (не говоря уже о том, что они были открытыми). Они довольно быстро вошли в употребление, что привело к появлению большого сооб- Эталонные модели 73 щества пользователей. Это вызвало исправления и улучшения реализации, в результате чего сообщество пользователей еще выросло. В данном случае обратная связь явно была положительной. Неудачная политика Из-за особенностей первоначальной реализации многие, особенно в университетских кругах, считали ТСР/1Р частью системы 111ч1Х.
А к системе БМ1Х в университетских кругах в 80-е годы испытывали чувства, средние между родительскими (в те времена некорректно по отношени1о к правам мужского населения называемые материнскими) и чувствами к яблочному пирогу. С другой стороны, 081 считался детищем европейских телекоммуникационных министерств, Европейского сообщества и (позднее) правительства СШ1. Все это было лишь отчасти верным, однако сама мысль о группе правительственных чиновников, пытшощихся протолкнуть неудачный в техническом отношении стандарт в глотки бедных исследователей и программистов, прокладывавших компьютерные сети в траншеях, не способствовала продвижению этой модели.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
