Закон Хлейда

Решение сложной задачи поручайте ленивому сотруднику — он найдет более легкий путь.

Cтоит мужичёк, смотрит на диски (долго смотрит, ибо порядочно выпивший), потом выдаёт продавцу: ...

Релиз Chrome OS 71
Sat, 15 Dec 2018 00:06:28 +0300

Выпуск hostapd и wpa_supplicant 2.7
Fri, 14 Dec 2018 20:57:58 +0300

В WordPress 5.0.1 устранена уязвимость, приводящая к индексации паролей поисковыми движками
Fri, 14 Dec 2018 10:55:54 +0300

Релиз системы проектирования трёхмерных интерфейсов Qt 3D Studio 2.2
Fri, 14 Dec 2018 09:59:50 +0300

CentOS возобновляет поддержку репозитория Fasttrack
Fri, 14 Dec 2018 09:54:37 +0300

Компания Alibaba присоединилась к инициативе по защите Linux от патентных претензий
Thu, 13 Dec 2018 22:41:04 +0300

Выпуск KDE Applications 18.12
Thu, 13 Dec 2018 21:18:36 +0300

В рамках проекта libcamera развивается стек для поддержки камер в Linux
Thu, 13 Dec 2018 14:12:10 +0300

Выпуск сборочной системы Meson 0.49.0
Thu, 13 Dec 2018 11:36:41 +0300

Разработчики ядра Linux обсуждают вопрос удаления субархитектуры x32
Wed, 12 Dec 2018 22:41:30 +0300

Разработка распределённого хранилища etcd переведена в организацию CNCF
Wed, 12 Dec 2018 21:15:16 +0300

Релиз FreeBSD 12.0
Wed, 12 Dec 2018 12:30:52 +0300

Релиз эмулятора QEMU 3.1
Wed, 12 Dec 2018 10:39:00 +0300

Выпуск графического тулкита wxWidgets 3.1.2
Wed, 12 Dec 2018 09:54:47 +0300

Релиз дистрибутива Tails 3.11 и браузера Tor Browser 8.0.4
Wed, 12 Dec 2018 09:10:35 +0300

Доступен интерпретатор mruby 2.0
Wed, 12 Dec 2018 01:51:15 +0300

Аудит не выявил следов установки шпионских чипов в материнских платах Super Micro
Tue, 11 Dec 2018 22:07:09 +0300

Первый выпуск dav1d, декодировщика AV1 от проектов VideoLAN и FFmpeg
Tue, 11 Dec 2018 21:44:38 +0300

Релиз Firefox 64
Tue, 11 Dec 2018 19:23:28 +0300

Первая открытая реализация анклава для аппаратно изолированных окружений
Tue, 11 Dec 2018 13:47:41 +0300

Выявлен 21 вид вредоносных программ, подменяющих OpenSSH
Tue, 11 Dec 2018 11:05:20 +0300

Google перенёс закрытие Google+ с августа на апрель из-за выявления новой уязвимости
Tue, 11 Dec 2018 10:19:30 +0300

Доля государственных фондов США в финансировании Tor снизилась с 85% до 51%
Tue, 11 Dec 2018 09:31:39 +0300

Выпуск облачного хранилища Nextcloud 15 с реализацией социальной сети
Mon, 10 Dec 2018 22:01:22 +0300

Голосование за поддержку Adobe Premiere в Linux
Mon, 10 Dec 2018 18:58:45 +0300

В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к удалённому выполнению кода
Mon, 10 Dec 2018 11:40:32 +0300

Выпуск распределенной системы управления исходными текстами Git 2.20
Mon, 10 Dec 2018 09:46:04 +0300

В 22 приложениях, загруженных из Google Play более 2 млн раз, выявлен вредоносный код
Sun, 09 Dec 2018 08:40:05 +0300

Релиз языка программирования Rust 2018 (1.31)
Sat, 08 Dec 2018 15:58:53 +0300

Уязвимости в PHP и PHPMailer
Sat, 08 Dec 2018 10:36:52 +0300

Зафиксирована подмена сайта Linux.org через захват DNS
Sat, 08 Dec 2018 08:35:19 +0300

Выпуск CentOS Atomic Host 7.1811, специализированной ОС для запуска контейнеров Docker
Sat, 08 Dec 2018 08:34:36 +0300

Первый кандидат в релизы Wine 4.0
Fri, 07 Dec 2018 22:53:26 +0300

Шестое обновление прошивки UBports, пришедшей на смену Ubuntu Touch
Fri, 07 Dec 2018 21:58:43 +0300

Релиз системы управления web-контентом WordPress 5.0 с новым web-редактором
Fri, 07 Dec 2018 20:47:01 +0300

Выпуск Mesa 18.3.0, свободной реализации OpenGL и Vulkan
Fri, 07 Dec 2018 17:51:22 +0300

Microsoft официально объявил о переходе Edge на движок Chromium
Fri, 07 Dec 2018 12:11:50 +0300

Фонд СПО признал Hyperbola полностью свободным дистрибутивом
Fri, 07 Dec 2018 11:55:53 +0300

Доступен пакетный менеджер GNU Guix 0.16 и дистрибутив GuixSD на его основе
Fri, 07 Dec 2018 10:30:48 +0300

Mozilla подготовит версию Firefox, оптимизированную для архитектуры ARM64
Fri, 07 Dec 2018 09:44:39 +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 верно обратное: модель практически не существует, тогда как протоколы чрезвычайно популярны.

НОВОСТИ: Аудит не выявил следов установки шпионских чипов в материнских п ... Tue, 11 Dec 2018 22:07:09 +0300

Компания Super Micro опубликовала результаты независимого аудита, проведённого после публикации изданием Bloomberg сведений о выявлении интегрированного на этапе производства шпионского чипа в серверных материнских платах Supermicro, поставляемых 30 компаниям из США, среди которых упоминались Apple и Amazon. Аудит не выявил каких-либо доказательств существования шпионских аппаратных имплантов и вредоносных модификаций оборудования Supermicro.

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