Хотя вряд ли кто-либо когда-либо публично сознается в этом, действительной причиной того, что модель 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 скорее отражает способ работы телефонов. Компьютеры отличаются от телефонов. Телефоны звонят. Компьютеры не звонят. Короче говоря, семантическая модель системы, основанной на прерываниях, является плохой идеей, совершенно не согласующейся со всеми современными идеями структурного программирования.
Учитывая огромную сложность модели и протоколов, то, что первоначальные реализации оказались громоздкими, неуклюжими и медленными, не стало неожиданностью. Неудачу потерпели все, кто попытался реализовать эту модель. Поэтому вскоре понятие "OSI" стало ассоциироваться с "плохим качеством". И хотя со временем продукты улучшились, ассоциации остались.
Первые реализации TCP/IP, основанные на Berkley UNIX®, напротив, были достаточно хороши (не говоря уже о том, что они были открытыми). Они довольно быстро вошли в употребление, что привело к появлению большого сообщества пользователей. Это вызвало исправления и улучшения реализации, в результате сообщество пользователей еще выросло. В данном случае обратная связь явно была положительной.
Из-за особенностей первоначальной реализации многие, особенно в университетских кругах, считали TCP/IP частью системы UNIX, а к системе UNIX в университетских кругах в 1980-е гг. испытывали чувства средние между родительскими (в те времена некорректно, в свете ущемления прав мужского населения, называемые материнскими) и чувствами к яблочному пирогу.
С другой стороны, OSI считался созданием европейских телекоммуникационных министерств, Европейского сообщества и (позднее) правительства США. Все это было лишь отчасти верным, однако сама мысль о группе правительственных чиновников, пытающихся протолкнуть более худший в техническом отношении стандарт в глотки бедным исследователям и программистам, прокладывавшим компьютерные сети в траншеях, не способствовала продвижению этой модели. Кое-кто рассматривал это развитие в том же свете, что и заявления корпорации IBM в 1960 г., что PL/I будет языком будущего, или Министерства обороны, поправлявшим позднее это утверждение своим заявлением, что в действительности таким языком будет Ada®.
Несмотря на то, что модель OSI и ее протоколы не добились оглушительного успеха, многие организации по-прежнему интересуются ими, особенно Европейская почтово-телеграфная и телефонная связь (РТТ), все еще обладающая монополией на телекоммуникации. Впоследствии были предприняты скромные попытки улучшить OSI, что привело к появлению исправленной модели, опубликованной в 1994 г.