У страха глаза велики, и слабый мочевой пузырь.

Жена с похмелья спрашивает у закодированного мужа: ...

Опубликован официальный перевод лицензий Creative Commons 4.0
Fri, 20 Apr 2018 18:02:54 +0300

Компания Apple открыла код распределённой СУБД FoundationDB
Fri, 20 Apr 2018 09:52:43 +0300

Выпуск KDE Applications 18.04
Fri, 20 Apr 2018 08:52:38 +0300

Стабильный релиз СУБД MySQL 8.0
Thu, 19 Apr 2018 23:25:33 +0300

Второй кандидат в релизы GIMP 2.10
Thu, 19 Apr 2018 10:49:37 +0300

Проект Python представил новый каталог пакетов PyPI и пакетный менеджер Pip 10
Thu, 19 Apr 2018 09:09:58 +0300

Крис Лэм переизбран на пост лидера проекта Debian
Thu, 19 Apr 2018 08:19:28 +0300

Доступен полностью свободный Linux-дистрибутив Trisquel 8.0
Wed, 18 Apr 2018 23:19:14 +0300

Выпуск платформы обмена сообщениями Zulip 1.8
Wed, 18 Apr 2018 21:19:14 +0300

Релиз web-браузера Chrome 66
Wed, 18 Apr 2018 15:09:42 +0300

Второй бета-выпуск Oracle Solaris 11.4
Wed, 18 Apr 2018 10:07:11 +0300

Релиз системы виртуализации VirtualBox 5.2.10
Wed, 18 Apr 2018 09:31:02 +0300

Доступен дистрибутив Oracle Linux 7.5 и платформа Spacewalk 2.7
Tue, 17 Apr 2018 22:43:40 +0300

Выпуск браузера Pale Moon 27.9.0
Tue, 17 Apr 2018 22:27:28 +0300

Релиз nginx 1.14.0
Tue, 17 Apr 2018 19:39:51 +0300

Microsoft представил IoT-платформу Azure Sphere на базе ядра Linux
Tue, 17 Apr 2018 08:22:44 +0300

Заморозка пакетной базы Debian 10 "Buster" намечена на март следующего года
Mon, 16 Apr 2018 23:57:53 +0300

Проект postmarketOS приступил к созданию загрузчика и прошивки модема для смартфонов
Mon, 16 Apr 2018 23:25:23 +0300

JavaScript-приложения криптовалют, использующие SecureRandom(), могли генерировать уязвимые ключи
Mon, 16 Apr 2018 18:55:43 +0300

Ядро Linux достигло 6 млн git-объектов, что могло бы стать хорошим поводом для выпуска 5.0
Mon, 16 Apr 2018 12:01:38 +0300

Релиз операционной системы ReactOS 0.4.8
Sun, 15 Apr 2018 22:30:02 +0300

Релиз системы управления версиями Apache Subversion 1.10.0
Sun, 15 Apr 2018 18:34:27 +0300

В следующем выпуске Android появится поддержка "DNS over TLS"
Sat, 14 Apr 2018 12:39:43 +0300

Релиз pgAdmin 4 3.0, интерфейса для управления СУБД PostgreSQL
Sat, 14 Apr 2018 07:57:03 +0300

Выпуск Wine 3.6
Sat, 14 Apr 2018 07:30:55 +0300

Представлен проект Qt for Python
Fri, 13 Apr 2018 18:38:27 +0300

Первый выпуск музыкального проигрывателя Elisa, развиваемого сообществом KDE
Fri, 13 Apr 2018 16:28:11 +0300

Первый стабильный релиз сервера приложений NGINX Unit
Thu, 12 Apr 2018 21:47:39 +0300

Первый выпуск свободного сервера навыков 0Mind
Thu, 12 Apr 2018 18:39:50 +0300

Организация утечки данных через линию электропередач
Thu, 12 Apr 2018 11:29:11 +0300

Модель OSI Модель TCP/IP Порты Протоколы
Эталонные модели

Несмотря на то что протоколы, связанные с эталонной моделью OSI, используются сейчас очень редко, сама модель до сих пор весьма актуальна, а свойства ее уровней, которые будут обсуждаться в этом разделе, очень важны. В эталонной модели TCP/IP все наоборот — сама модель сейчас почти не используется, а ее протоколы являются самыми распространенными. Исходя из этого, мы обсудим подробности, касающиеся обеих моделей.

Эталонная модель OSI

Эталонная модель OSI (за исключением физической среды) показана на рис. 1.16. Эта модель основана на разработке Международной организации по стандарти­зации (International Organization for Standardization, ISO) и является первым ша­гом к международной стандартизации протоколов, используемых на различных уровнях (Day и Zimmerman, 1983). Затем она была пересмотрена в 1995 году (Day, 1995). Называется эта структура эталонной моделью взаимодействия от­крытых систем ISO (ISO OSI (Open System Interconnection) Reference Model), поскольку она связывает открытые системы, то есть системы, открытые для свя­зи с другими системами. Для краткости мы будем называть эту модель просто «модель OSI».

Модель OSI имеет семь уровней. Появление именно такой структуры было обусловлено следующими соображениями.

1. Уровень должен создаваться по мере необходимости отдельного уровня абстракции.

2. Каждый уровень должен выполнять строго определенную функцию.

3. Выбор функций для каждого уровня должен осуществляться с учетом создания стандартизированных международных протоколов.

4. Границы между уровнями должны выбираться так, чтобы поток данных между интерфейсами был минимальным.

5. Количество уровней должно быть достаточно большим, чтобы различные функции не объединялись в одном уровне без необходимости, но не слишком высоким, чтобы архитектура не становилась громоздкой.

Далее мы обсудим каждый уровень модели, начиная с самого нижнего. Обра­тите внимание: модель OSI не является сетевой архитектурой, поскольку она не описывает службы и протоколы, используемые на каждом уровне. Она просто определяет, что должен делать каждый уровень. Тем не менее ISO также разработала стандарты для каждого уровня, хотя эти стандарты не входят в саму эталонную модель. Каждый из них был опубликован как отдельный международный стандарт.

Физический уровень

Физический уровень занимается реальной передачей необработанных битов по каналу связи. При разработке сети необходимо убедиться, что когда одна сторона передает единицу, то принимающая сторона получает также единицу, а не ноль. Принципиальными вопросами здесь являются следующие: какое напряжение должно использоваться для отображения единицы, а какое — для нуля; сколько микросекунд длится бит; может ли передача производиться одновременно в двух направлениях; как устанавливается начальная связь и как она прекращается, когда обе стороны закончили свои задачи; из какого количества проводов должен состоять кабель и какова функция каждого провода. Вопросы разработки в основном связаны с механическими, электрическими и процедурными интерфейсами, а также с физическим носителем, лежащим ниже физического уровня.

Уровень передачи данных

Основная задача уровня передачи данных — быть способным передавать «сырые» данные физического уровня по надежной линии связи, свободной от необнаруженных ошибок с точки зрения вышестоящего сетевого уровня. Уровень выполняет эту задачу при помощи разбиения входных данных на кадры, обычный размер которых колеблется от нескольких сотен до нескольких тысяч байт. Кадры данных передаются последовательно с обработкой кадров подтверждения, отсылаемых обратно получателем.

Еще одна проблема, возникающая на уровне передачи данных (а также и на большей части более высоких уровней), — как не допустить ситуации, когда быстрый передатчик заваливает приемник данными. Должен быть предусмотрен некий механизм регуляции, который информировал бы передатчик о наличии свободного места в буфере приемника на текущий момент. Часто подобное управление объединяется с механизмом обработки ошибок.

В широковещательных сетях существует еще одна проблема уровня передачи данных: как управлять доступом к совместно используемому каналу. Эта проблема разрешается введением специального дополнительного подуровня уровня передачи данных — подуровня доступа к носителю.

Сетевой уровень

Сетевой уровень занимается управлением операциями подсети. Важнейшим моментом здесь является определение маршрутов пересылки пакетов от источника к пункту назначения. Маршруты могут быть жестко заданы в виде таблиц и редко меняться. Кроме того, они могут задаваться в начале каждого соединения, например терминальной сессии. Наконец, они могут быть в высокой степени динамическими, то есть вычисляемыми заново для каждого пакета с учетом текущей загруженности сети.

Если в подсети одновременно присутствует слишком большое количество пакетов, то они могут закрыть дорогу друг другу, образуя заторы в узких местах. Недопущение подобной закупорки также является задачей сетевого уровня. В бо­лее общем смысле сетевой уровень занимается предоставлением определенного уровня сервиса (это касается задержек, времени передачи, вопросов синхронизации).

При путешествии пакета из одной сети в другую также может возникнуть ряд проблем. Так, способ адресации, применяемый в одной сети, может отличаться от принятого в другой. Сеть может вообще отказаться принимать пакеты из-за того, что они слишком большого размера. Также могут различаться протоколы, и т. д. Именно сетевой уровень должен разрешать все эти проблемы, позволяя объединять разнородные сети.

В широковещательных сетях проблема маршрутизации очень проста, поэтому в них сетевой уровень очень примитивный или вообще отсутствует.

Транспортный уровень

Основная функция транспортного уровня — принять данные от сеансового уровня, разбить их при необходимости на небольшие части, передать их сетевому уровню и гарантировать, что эти части в правильном виде прибудут по назначению. Кроме того, все это должно быть сделано эффективно и таким образом, чтобы изолировать более высокие уровни от каких-либо изменений в аппаратной технологии.

Транспортный уровень также определяет тип сервиса, предоставляемого сеансовому уровню и, в конечном счете, пользователям сети. Наиболее популярной разновидностью транспортного соединения является защищенный от ошибок канал между двумя узлами, поставляющий сообщения или байты в том порядке, в каком они были отправлены. Однако транспортный уровень может предоставлять и другие типы сервисов, например пересылку отдельных сообщений без гарантии соблюдения порядка их доставки или одновременную отправку сообщения различным адресатам по принципу широковещания. Тип сервиса определяется при установке соединения. (Строго говоря, полностью защищенный от ошибок канал создать невозможно. Говорят лишь о таком канале, уровень ошибок в котором достаточно мал, чтобы ими можно было пренебречь на практике.)

Транспортный уровень является настоящим сквозным уровнем, то есть доставляющим сообщения от источника адресату. Другими словами, программа на машине-источнике поддерживает связь с подобной программой на другой машине при помощи заголовков сообщений и управляющих сообщений. На более низких уровнях для поддержки этого соединения устанавливаются соединения между всеми соседними машинами, через которые проходит маршрут сообщений.

Сеансовый уровень

Сеансовый уровень позволяет пользователям различных компьютеров устанавливать сеансы связи друг с другом. При этом предоставляются различные типы сервисов, среди которых управление диалогом (отслеживание очередности передачи данных), управление маркерами (предотвращение одновременного выполнения критичной операции несколькими системами) и синхронизация (установка служебных меток внутри длинных сообщений, позволяющих после устранения ошибки продолжить передачу с того места, на котором она оборвалась).

Уровень представления

В отличие от более низких уровней, задача которых — достоверная передача битов и байтов, уровень представления занимается по большей части синтаксисом и семантикой передаваемой информации. Чтобы было возможно общение компьютеров с различными представлениями данных, необходимо преобразовывать форматы данных друг в друга, передавая их по сети в неком стандартизированном виде. Уровень представления занимается этими преобразованиями, предоставляя возможность определения и изменения структур данных более высокого уровня (например, записей баз данных).

Прикладной уровень

Прикладной уровень содержит набор популярных протоколов, необходимых пользователям. Одним из наиболее распространенных является протокол передачи гипертекста HTTP (HyperText Transfer Protocol), который составляет основу технологии Всемирной Паутины. Когда браузер запрашивает веб-страницу, он передает ее имя (адрес) и рассчитывает на то, что сервер будет использовать HTTP. Сервер в ответ отсылает страницу. Другие прикладные протоколы используются для передачи файлов, электронной почты, сетевых рассылок.

Критика модели и протоколов OSI

Некоторое время назад, многим экспертам в данной области казалось, что модель OSI и ее протоколы завоюют весь мир и вытеснят все остальное. Этого не случилось. По­чему? Может быть, полезно оглянуться и учесть некоторые из уроков этой истории. Основных причин неудачи модели OSI было четыре:

- несвоевременность;

- неудачная технология;

- неудачная реализация;

- неудачная политика.

Несвоевременность

Прежде всего рассмотрим причину номер один: несвоевременность. Для успеха стандарта чрезвычайно важно, в какое время он устанавливается. У Дэвида Клар­ка (David Clark) из M.I.T. есть теория стандартов, которую он называет апокалипсисом двух слонов.

На этом рисунке изображена активность, сопровождающая любую новую разработку. Открытие новой темы вначале вызывает всплеск исследовательской активности в виде дискуссий, статей и собраний. Через некоторое время наступает спад активности, эту тему открывают для себя корпорации, и в результате в нее инвестируются миллиарды долларов.

Существенным является то, что стандарты пишутся именно в период между двумя «слонами». Если их создавать слишком рано, прежде чем закончатся исследования, предмет может оказаться еще слишком мало изучен и понят, что повлечет принятие плохих стандартов. Если создавать их слишком поздно, компании могут успеть вложить деньги в несколько отличные от стандартов технологии, так что принятые стандарты могут оказаться проигнорированными. Если интервал между двумя пиками активности будет слишком коротким (а все стремятся делать деньги как можно быстрее), разработчики стандартов могут просто не успеть их выработать.

Теперь становится ясно, почему стандартные протоколы OSI потерпели неудачу. К моменту их появления среди исследовательских университетов уже получили широкое распространение конкурирующие с ними протоколы TCP/IP. И хотя волна инвестиций еще не обрушилась на данную область, рынок университетов был достаточно широк для того, чтобы многие разработчики стали осторожно предлагать продукты, поддерживающие протоколы TCP/IP. Когда же появился OSI, разработчики не захотели поддерживать второй стек протоколов; таким образом, начальных предложений не было. Каждая компания выжидала, пока первым начнет кто-нибудь другой, поэтому OSI так никто и не стал поддерживать.

Плохая технология

Второй причиной, по которой модель OSI не была реализована, оказалось несовершенство как самой модели, так и ее протоколов. Выбор семиуровневой структуры стал больше политическим решением, чем техническим. В результате два уровня (сеансовый и уровень представления) почти пусты, тогда как два других (сетевой и передачи данных) перегружены.

Эталонная модель OSI вместе с соответствующими определениями служб и протоколами оказалась невероятно сложной. Если сложить в стопку распечатку официального описания стандартов, получится кипа бумаги высотой в один метр. Модель тяжело реализуема и неэффективна в работе.

Еще одна проблема, помимо невозможности понять стандарты OSI, заключалась в том, что некоторые функции, такие как адресация, управление потоком и обработка ошибок, повторялись снова и снова в каждом уровне. Так, например, в книге Saltzer и др. (1984) указывается, что для того, чтобы контроль за ошибками был эффективным, он должен осуществляться на самом верхнем уровне, поэтому повторение его снова и снова на каждом уровне часто оказывается излишним и неэффективным.

Неудачная реализация

Учитывая огромную сложность модели и протоколов, громоздкость и медлительность первых реализаций не стали неожиданностью. Неудачу потерпели все, кто попытался реализовать эту модель. Поэтому вскоре понятие «OSI» стало ассоциироваться с плохим качеством. И хотя со временем продукты улучшились, ассоциации остались.

Первые реализации TCP/IP, основанные на Berkley UNIX, напротив, были достаточно хороши (не говоря уже о том, что они были открытыми). Они довольно быстро вошли в употребление, что привело к появлению большого сообщества пользователей. Это вызвало исправления и улучшения реализации, в результате чего сообщество пользователей еще выросло. В данном случае обратная связь явно была положительной.

Неудачная политика

Из-за особенностей первоначальной реализации многие, особенно в университетских кругах, считали TCP/IP частью системы UNIX. А к системе UNIX в университетских кругах в 80-е годы испытывали чувства, средние между родительскими (в те времена некорректно по отношению к правам мужского населения называемые материнскими) и чувствами к яблочному пирогу.

С другой стороны, OSI считался детищем европейских телекоммуникационных министерств, Европейского сообщества и (позднее) правительства США. Все это было лишь отчасти верным, однако сама мысль о группе правительственных чиновников, пытающихся протолкнуть неудачный в техническом отношении стандарт в глотки бедных исследователей и программистов, прокладывавших компьютерные сети в траншеях, не способствовала продвижению этой модели. Кое-кто рассматривал это развитие в том же свете, что и заявления корпорации IBM, сделанные в 1960 году, о том, что PL/I будет языком будущего, или Министерства обороны, поправлявшего позднее это утверждение своим заявлением, что в действительности таким языком будет Ada.

Несмотря на все недостатки, модель OSI (кроме сеансового уровня и уровня представления) показала себя исключительно полезной для теоретических дискуссий о компьютерных сетях. Протоколы OSI, напротив, не получили широкого распространения. Для TCP/IP верно обратное: модель практически не существует, тогда как протоколы чрезвычайно популярны.

НОВОСТИ: Опубликован официальный перевод лицензий Creative Commons 4.0 Fri, 20 Apr 2018 18:02:54 +0300

Организация Creative Commons представила официальный перевод на русский язык набора лицензий Creative Commons 4.0, изначально выпущенного в 2013 году. Официальный перевод подготовлен после вступления в силу статьи 1286.1 Гражданского кодекса Российской Федерации, в которой введено понятие открытой лицензии на использование произведения науки, литературы или искусства. Перевод учитывает обозначенную в статье терминологию и оформлен в контексте определений открытых лицензий в российском законодательстве.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome