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