МИНИСТЕРСТВО ОБРАЗОВАНИЯ РФ
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ
МОСКОВСКИЙ ИНЖЕНЕРНО-ФИЗИЧЕСКИЙ ИНСТИТУТ
Факультет Кибернетики
Кафедра № 29
Реферат по теме:
Критика эталонной модели OSI
Москва 2010
1. Сравнение эталонных моделей OSI и TCP
У моделей OSI и TCP имеется много общих черт. Обе модели основаны на концепции стека независимых протоколов. Функциональность уровней также во многом схожа. Например, в каждой модели уровни, начиная с транспортного и выше, предоставляют сквозную, не зависящую от сети транспортную службу для процессов, желающих обмениваться информацией. Эти уровни образуют поставщика транспорта. Также в каждой модели уровни выше транспортного являются прикладными потребителями транспортной службы.
Несмотря на это фундаментальное сходство, у данных моделей имеется и ряд отличий. В данном разделе мы обратим внимание на ключевые различия между этими двумя эталонными моделями. Обратите внимание, что мы сравниваем именно эталонные модели, а не соответствующие стеки протоколов. Сами протоколы будут обсуждаться несколько позднее. Книга [270] целиком посвящена сравнению моделей TCP/IP и OSI.
Для модели OSI центральными являются три концепции.
1. Службы.
2. Интерфейсы.
3. Протоколы
Вероятно, наибольшим вкладом модели OSI стало явное разделение этих трех концепций. Каждый уровень выполняет некоторые службы для расположенного выше уровня. Служба определяет, что именно делает уровень, но не то, как он это делает, и каким образом сущности, расположенные выше, получают доступ к данному уровню.
Интерфейс уровня определяет способ доступа к уровню для расположенных выше процессов. Он описывает параметры и ожидаемый результат. Он также ничего не сообщает о внутреннем устройстве уровня.
И наконец, одноранговые протоколы, применяемые в уровне, являются внутренним делом самого уровня. Для выполнения поставленной ему задачи (то есть предоставления служб) он может использовать любые протоколы. Кроме того, уровень может менять протоколы, не затрагивая работу приложений более высоких уровней.
Эти идеи очень хорошо соответствуют современным идеям объектно-ориентированного программирования. Уровень может быть представлен в виде объекта, обладающего набором методов (операций), к которым может обращаться внешний процесс. Семантика этих методов определяет набор служб, предоставляемых объектом. Параметры и результаты методов образуют интерфейс объекта.
Изначально в модели TCP/IP не было четкого разделения между службами, интерфейсом и протоколом, хотя и производились попытки изменить это, чтобы сделать ее более похожей на модель OSI. Так, например единственными настоящими службами, предоставляемыми межсетевым уровнем, являются SEND IP PACKET (послать IP-пакет) и RECEIVE IP PACKET (переслать IP-пакет).
В результате в модели OSI протоколы скрыты лучше, чем в модели TCP/IP, и при изменении технологии могут быть относительно легко заменены. Возможность производить подобные изменения является одной из главных целей многоуровневых протоколов.
Эталонная модель OSI была разработана прежде, чем были изобретены протоколы. Такая последовательность событий означает, что эта модель не была настроена на какой-нибудь определенный набор протоколов, что сделало ее универсальной. Обратной стороной такого порядка действий было то, что у разработчиков было мало опыта в данной области и не было четкого представления о том, какие функции должен выполнять каждый уровень.
Например, уровень передачи данных изначально работал только в сетях с передачей от узла к узлу. С появлением широковещательных сетей в модель потребовалось ввести новый подуровень. Когда же на базе модели OSI начали строить реальные сети с использованием существующих протоколов, было обнаружено, что они не соответствуют требуемым спецификациям служб. Поэтому в модель пришлось добавить подуровни для устранения несоответствия. Наконец, изначально ожидалось, что в каждой стране будет одна сеть, управляемая правительством и использующая протоколы OSI, поэтому никто и не думал об объединении различных сетей. В действительности оказалось все не так.
С моделью TCP/IP было все наоборот: сначала появились протоколы, а уже затем была создана модель, описывающая существующие протоколы. Таким образом, не было проблемы с соответствием протоколов модели. Они соответствовали прекрасно. Единственной проблемой было то, что модель не соответствовала никаким другим стекам протоколов. В результате она не использовалась для описания никаких других сетей, отличных от TCP/IP.
Если взглянуть на эти две модели более конкретно, прежде всего обратит на себя внимание отличие в количестве уровней: в модели OSI семь уровней, а в модели TCP/IP - четыре. В обеих моделях имеется (меж)сетевой, транспортный и прикладной уровни, а остальные уровни различные.
Еще одно различие между моделями лежит в сфере возможности использования связи на основе соединений и связи без установления соединения. Модель OSI на сетевом уровне поддерживает оба типа связи, но на транспортном уровне - только связь на основе соединений (поскольку транспортные службы являются видимыми для пользователя). В модели TCP/IP на сетевом уровне есть только один режим связи (без установления соединения), но на транспортном уровне он поддерживает оба режима, предоставляя пользователям выбор. Этот выбор особенно важен для простых протоколов запрос-ответ.
2. Критика модели и протоколов OSI
Ни описанные выше модели (OSI и TCP/IP), ни их протоколы не являются совершенными. Довольно много критики было высказано по поводу обеих моделей.
Семиуровневая модель OSI является теоретической, и содержит ряд недоработок. Были попытки строить сети в точном соответствии с моделью OSI, но созданные таким образом сети были дорогими, ненадёжными и неудобными в эксплуатации. Реальные сетевые протоколы, используемые в существующих сетях, вынуждены отклоняться от неё, обеспечивая непредусмотренные возможности, поэтому привязка некоторых из них к уровням OSI является несколько условной: некоторые протоколы занимают несколько уровней модели OSI, функции обеспечения надёжности реализованы на нескольких уровнях модели OSI.
Основная недоработка OSI — непродуманный транспортный уровень. На нём OSI позволяет обмен данными между приложениями (вводя понятие порта — идентификатора приложения), однако, возможность обмена простыми датаграммами (по типу UDP) в OSI не предусмотрена — транспортный уровень должен образовывать соединения, обеспечивать доставку, управлять потоком и т.п. (по типу TCP). Реальные же протоколы реализуют такую возможность.
Многим экспертам в данной области казалось, что модель OSI и ее протоколы завоюют весь мир и вытеснят все остальное. Этого не случилось. Почему? Может быть полезно оглянуться и учесть некоторые из уроков этой истории. Основных причин неудачи модели OSI было четыре.
1. Несвоевременность.
2. Неудачная технология.
3. Неудачная реализация.
4. Неудачная политика.
2.1 Несвоевременность
Прежде всего, рассмотрим причину номер один: несвоевременность. Для успеха стандарта чрезвычайно важно, в какое время он устанавливается. У Дэвида Кларка (David Clark) из M.I.T. есть теория стандартов, которую он называет апокалипсисом двух слонов (рис. 1).
Рис. 1 - Апокалипсис двух слонов
На этом рисунке изображена активность, сопровождающая новую разработку. Открытие новой темы вызывает всплеск исследовательской активности в виде дискуссий, статей и собраний. Через некоторое время наступает спад активности, корпорации открывают для себя эту тему, в результате в нее инвестируются миллиарды долларов.
Существенным является то, что стандарты пишутся именно в период между двумя «слонами». Если их создавать слишком рано, прежде чем закончатся исследования, предмет может оказаться еще слишком мало изучен и поня
Теперь становится ясно, что стандартные протоколы OSI потерпели неудачу. К моменту их появления среди исследовательских университетов уже получили широкое распространение конкурирующие с ними протоколы TCP/IP. И хотя волна миллиардных инвестиций еще не обрушилась в данной области, рынок университетов был достаточно широк для того, чтобы многие разработчики стали осторожно предлагать продукты, поддерживающие протоколы TCP/IP. Когда же появился OSI, разработчики не захотели поддерживать второй стек протоколов, таким образом, начальных предложений не было. Каждая компания выжидала, пока первым начнет кто-нибудь другой, поэтому OSI так никто и не стал поддерживать.
2.2 Плохая технология
Второй причиной, по которой модель OSI не была реализована, оказалась некорректность как самой модели, так и ее протоколов. Большинство дискуссий по поводу семиуровневой модели создают впечатление, что окончательно выбранное количество и содержимое уровней были единственными из возможных или, по крайней мере, очевидными. Это далеко не так. Сеансовый уровень практически не используется приложениями, а уровень представления почти пуст. На самом деле британским предложением была модель OSI с пятью уровнями. В противоположность сеансовому уровню и уровню представления, уровень передачи данных и сетевой уровень оказались настолько функционально перегруженными, что впоследствии они были разбиты на несколько подуровней, каждый из которых выполнял отличные от других функции.
Хотя вряд ли кто-либо когда-либо публично сознается в этом, действительной причиной того, что модель OSI включает именно семь уровней, является то, что во время ее создания существовал частный протокол корпорации IBM, называемый SNA™ (Systems Network Architecture). В это время IBM настолько доминировала в компьютерной индустрии, что все остальные, включая телефонные компании, конкурирующие компьютерные фирмы и даже правительства ведущих стран мира, были смертельно напуганы, что IBM может использовать свой сектор рынка с тем, чтобы заставить всех использовать стандарт SNA, который она могла менять по собственному усмотрению. Модель OSI создавалась с целью произвести похожую на стандарт IBM эталонную модель и стек протоколов и сделать их всемирными стандартами, управляемыми не одной компанией, а нейтральной организацией, ISO.
Модель OSI вместе с определениями служб и протоколов необычайно сложна. Если распечатать все стандарты и сложить их друг на друга, то получится стопка бумаг высотой почти в метр. К тому же стандарты трудно реализуемы и неэффективны в работе. В данном контексте вспоминается шутка, сформулированная Полом Мокапетрисом (Paul Mockapetris).
Помимо невозможности понять стандарты OSI, еще одна проблема заключалась в том, что некоторые функции, такие как адресация, управление потоком, обработка ошибок, повторялись снова и снова в каждом уровне. Так, например, для того, чтобы контроль за ошибками был эффективным, он должен осуществляться на самом верхнем уровне, поэтому повторение его снова и снова на каждом уровне часто оказывается излишним и неэффективным.
Другим аспектом является тот факт, что решение поместить ту или иную функцию в определенном уровне не всегда очевидно. В течение почти всей разработки стандарта управление виртуальным терминалом, сейчас находящееся в прикладном уровне, помещалось в уровне представления. Его переместили в прикладной уровень, поскольку комитет никак не мог решить, для чего использовать уровень представления. Аспекты безопасности данных и шифрования информации были настолько противоречивыми, что по вопросу их размещения так и не было найдено удовлетворяющего всех решения, поэтому обе эти функции были оставлены за пределами модели. По аналогичным причинам был опущен также вопрос управления сетью.
Еще одним критическим замечанием в адрес оригинального стандарта было то, что он полностью игнорировал службы без установления соединения и протоколы без установления соединения, хотя большинство локальных сетей работало именно таким образом. Последующие дополнения (называемые в мире программирования bug fixes) исправили эти недостатки.
Возможно, наиболее сильным является следующее критическое замечание: в модели доминирует коммуникационная ментальность. Взаимоотношения компьютерной индустрии и коммуникаций почти нигде не упоминаются, и некоторые из решений, использованных в модели, абсолютно неприемлемы с точки зрения работы компьютеров и программного обеспечения. В качестве примера рассмотрите примитивы OSI, приведенные в табл. 1.2. В частности, хорошенько подумайте о том, как использовать эти примитивы в программе.
Примитив CONNECT.request довольно прост. Можно представить себе библиотечную процедуру connect, которую программы могут вызывать для установки связи. Теперь рассмотрим примитив CONNECT.indication. Когда прибывает сообщение, получающий процесс должен быть об этом проинформирован. В результате этот процесс должен получить прерывание, что вряд ли является приемлемой концепцией в программах, написанных на любом современном языке программирования высокого уровня. Разумеется, на самом нижнем уровне индикация (прерывание) происходит.
Если бы программа ожидала входящего звонка, она могла бы сама обратиться к библиотечной процедуре receive. Но в таком случае почему receive не был сделан примитивом вместо indication? Примитив receive ориентирован на метод работы компьютеров, тогда как indication скорее отражает способ работы телефонов. Компьютеры отличаются от телефонов. Телефоны звонят. Компьютеры не звонят. Короче говоря, семантическая модель системы, основанной на прерываниях, является плохой идеей, совершенно не согласующейся со всеми современными идеями структурного программирования.
2.3 Неудачная реализация
Учитывая огромную сложность модели и протоколов, то, что первоначальные реализации оказались громоздкими, неуклюжими и медленными, не стало неожиданностью. Неудачу потерпели все, кто попытался реализовать эту модель. Поэтому вскоре понятие "OSI" стало ассоциироваться с "плохим качеством". И хотя со временем продукты улучшились, ассоциации остались.
Первые реализации TCP/IP, основанные на Berkley UNIX®, напротив, были достаточно хороши (не говоря уже о том, что они были открытыми). Они довольно быстро вошли в употребление, что привело к появлению большого сообщества пользователей. Это вызвало исправления и улучшения реализации, в результате сообщество пользователей еще выросло. В данном случае обратная связь явно была положительной.
2.4 Неудачная политика
Из-за особенностей первоначальной реализации многие, особенно в университетских кругах, считали TCP/IP частью системы UNIX, а к системе UNIX в университетских кругах в 1980-е гг. испытывали чувства средние между родительскими (в те времена некорректно, в свете ущемления прав мужского населения, называемые материнскими) и чувствами к яблочному пирогу.
С другой стороны, OSI считался созданием европейских телекоммуникационных министерств, Европейского сообщества и (позднее) правительства США. Все это было лишь отчасти верным, однако сама мысль о группе правительственных чиновников, пытающихся протолкнуть более худший в техническом отношении стандарт в глотки бедным исследователям и программистам, прокладывавшим компьютерные сети в траншеях, не способствовала продвижению этой модели. Кое-кто рассматривал это развитие в том же свете, что и заявления корпорации IBM в 1960 г., что PL/I будет языком будущего, или Министерства обороны, поправлявшим позднее это утверждение своим заявлением, что в действительности таким языком будет Ada®.
Несмотря на то, что модель OSI и ее протоколы не добились оглушительного успеха, многие организации по-прежнему интересуются ими, особенно Европейская почтово-телеграфная и телефонная связь (РТТ), все еще обладающая монополией на телекоммуникации. Впоследствии были предприняты скромные попытки улучшить OSI, что привело к появлению исправленной модели, опубликованной в 1994 г.