Nets2010 (1131259), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

1.7.1.5. Уровень сессии

Уровень сессии позволяет пользователям на А-машинах (напомним, что пользователем может быть программа) устанавливать между собой сессии. Сессия позволяет передавать данные, как это может делать транспортный уровень, но, кроме того, этот уровень имеет более сложный сервис, полезный в некоторых приложениях. Например, он может осуществлять вход в удаленную систему, передавать файл между двумя приложениями и т.п. Один из видов услуг на этом уровне - управление диалогом. Потоки данных могут быть разрешены в обоих направлениях одновременно, либо поочередно в одном направлении. Сервис на уровне сессии будет управлять направлением передачи. Другой вид сервиса на этом уровне - управление маркером. Для некоторых протоколов недопустимо выполнение одной и той же операции на обоих концах соединения одновременно. Для этого уровень сессии выделяет активной стороне маркер. Операцию может выполнять тот, кто владеет маркером. Другим примером сервиса на этом уровне является синхронизация. Пусть нам надо передать такой файл, что его пересылка займет два часа, между машинами, время наработки на отказ у которых - один час. Ясно, что «в лоб» передачу такого файла средствами транспортного уровня не решить. Уровень сессии позволяет расставлять контрольные точки. В случае отказа одной из машин передача возобновится с последней контрольной точки.

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

Уровень представления предоставляет решения для часто возникающих проблем, чем облегчает участь пользователей. В основном это проблемы семантики и синтаксиса передаваемой информации. Данный уровень имеет дело с информацией, а не с потоком битов. Типичным примером услуги на этом уровне является унифицированная кодировка данных. На разных машинах используются разные способы кодировки символов, например, ASCII, Unicode и т.п., разные способы представления целых - в прямом, обратном или дополнительном кодах. Пользователи, как правило, используют структуры данных, а не случайный набор байт. Чтобы машины с разной кодировкой и представлением данных могли взаимодействовать, передаваемые структуры данных определяются специальным абстрактным способом, не зависящим от кодировки, используемой при передаче. Уровень представления работает со структурами данных в абстрактной форме, преобразует это представление во внутреннее для конкретной машины и из внутреннего, машинного представления, в стандартное представление для передачи по сети.

1.7.1.7. Уровень приложений

Уровень приложений обеспечивает работу часто используемых протоколов. Cуществуют сотни разных типов терминалов. Если мы захотим создать сетевой экранный редактор, то нам придется прописывать для каждого типа терминала свою версию. Есть другой путь: определить сетевой виртуальный терминал и написать для него редактор. Для каждого типа терминала написать программу отображения этого терминала на сетевой виртуальный терминал. Все программное обеспечение для виртуального сетевого терминала расположено на уровне приложений. Другой пример - передача файлов. Разные ОС используют разные механизмы именования, представления текстовых строк и т.д. Для передачи файлов между разными системами надо преодолевать все такие различия. Для этого есть приложение FTP, также расположенное на уровне приложений. На этом же уровне находятся: электронная почта, удаленная загрузка программ, удаленный просмотр информации и т.д.

1.7.1.8. Передача данных в МОС-модели

На рисунке 1-14 показана последовательность действий при передаче данных в МОС-модели. Хотя данные движутся вертикально, каждый уровень предполагает их горизонтальное передвижение. Здесь аналогия с синхронным переводом. Когда оратор говорит перед нами на урду, то он считает, что он обращается к нам. Не тут-то было. Он обращается к переводчику, а тот уже обращается к нам.

Рисунок 1-14. Пример передачи данных в модели МОС

1.7.2. Эталонная модель TCP/IP

Здесь мы рассмотрим другую эталонную модель, прототипом для которой послужил прародитель всех компьютерных сетей - сеть ARPA. Эта сеть образовалась в результате научно-исследовательской работы, проведенной по инициативе Министерства Обороны США. Позднее к этому проекту подключились сотни университетов и государственных учреждений Америки. С самого начала эта сеть задумывалась как объединение нескольких разных сетей. Одной из основных целей этого проекта было разработать унифицированные способы соединения сетей. С появлением спутниковых и радио цифровых каналов связи проблема становилась только актуальнее. Так появилась модель TCP/IP. Свое название она получила по именам двух основных протоколов: TCP - протокол управления передачей (Transmission Control Protocol), и IP - межсетевой протокол (Internet Protocol). Другой целью проекта ARPA было создание протоколов, не зависящих от характеристик конкретных хост-машин, маршрутизаторов, шлюзов и т.п. Кроме этого, связь должна поддерживаться, даже если отдельные компоненты сети будут выходить из строя во время соединения. Другими словами, связь должна поддерживаться до тех пор, пока источник информации и получатель информации работоспособны. Архитектура сети не должна ограничивать приложения, начиная от простой передачи файлов до передачи речи и изображения в реальном времени.

1.7.2.1. Межсетевой уровень

В силу вышеперечисленных требований выбор организации транспортной среды был очевиден: сеть с коммутацией пакетов с межсетевым уровнем без соединений. Этот уровень называется межсетевым уровнем. Он является основой всей архитектуры. Его назначение - обеспечить доставку пакетов, движущихся в сети независимо друг от друга, даже если получатель принадлежит другой сети. Причем пакеты могут поступать к получателю не в том порядке, в котором они были посланы. Упорядочить их в надлежащем порядке - задача вышележащего уровня. Межсетевой уровень определяет межсетевой протокол IP и формат пакета. Обратите внимание, что ни протокол, ни формат пакета не являются официальными международными стандартами, в отличие от протоколов эталонной модели МОС. Там большинство протоколов имеют статус международных стандартов. Назначение межсетевого уровня в TCP/IP - доставить IP-пакет по назначению. Это как раз то, за что отвечает сетевой уровень в МОС-модели. На рисунке 1-15 показано соответствие между уровнями этих двух эталонных моделей. Рисунок 1-15. Соответствие между МОС и TCP/IP

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

Над межсетевым уровнем расположен транспортный уровень. Как и в МОС-модели, его задача - обеспечить связь «точка-точка» между двумя равнозначными активностями. В рамках TCP/IP модели было разработано два транспортных протокола. Первый - TCP (Transmission Control Protocol) - надежный протокол с соединением. Он получает поток байт, фрагментирует его на отдельные сообщения и передает их на межсетевой уровень. На машине-получателе равнозначная активность TCP-протокола собирает эти сообщения в поток байтов. TCP-протокол также обеспечивает управление потоком. Второй протокол - UDP (User Datagram Protocol). Это ненадежный протокол без соединения для тех приложений, которые используют свои механизмы фрагментации и управления потоком. Он часто используется для передачи коротких сообщений в клиент-серверных приложениях, а также там, где скорость передачи важнее ее точности. Соотношение этих протоколов и их приложений показано на рисунке 1-16.

Рисунок 1-16. Протоколы и СПД-системы, учитываемые моделью TCP/IP

Напомним, что ненадежным мы называем протокол без уведомления о получении кадра, фрейма, пакета, сообщения и т.п.

1.7.2.3. Уровень приложений

В TCP/IP-модели нет уровней сессии и представления. Необходимость в них была неочевидна для ее создателей. На сегодня дело обстоит так, что разработчик сложного приложения берет проблемы этих уровней на себя. Над транспортным протоколом располагается уровень приложений. Этот уровень включает следующие приложения: виртуальный терминал - TELNET, передачу файлов - FTP, электронную почту - SMTP. Позднее к ним добавились: служба имен домена - DNS (Domain Name Service), отображающая логические имена хост-машин на их сетевые адреса, протокол для передачи новостей - NNTP и протокол для работы с гипертекстовыми документами во Всемирной паутине - HTTP. Под межсетевым уровнем в TCP/IP-модели великая пустота. Модель ничего не говорит, что там происходит, кроме того, что хост-машина должна быть связана с сетью через некоторый протокол. Никаких ограничений на этот протокол, равно как и рекомендаций нет.

1.7.3. Сравнение моделей МОС и TCP/IP

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

• сервис

• интерфейс

• протокол

Наибольшее методологическое значение этой модели - в четком выделении и разделении этих понятий. Сервис определяет, что делает уровень, но ничего не говорит, как. Интерфейс уровня определяет для вышележащего уровня доступ к сервису. Протокол определяет реализацию сервиса. Здесь можно провести аналогию с объектно-ориентированным программированием. У каждого объекта есть набор методов - сервис, который определяет те операции, которые этот объект может выполнять. Иными словами, сервис - это семантика методов. Каждый метод имеет интерфейс - набор параметров, имя и т.п. Реализация методов скрыта в объекте - протоколе - и невидима пользователю. В TCP/IP-модели нет столь же четкого выделения этих понятий. В ней понятие протокола четко «упрятано» и независимо от остальных частей модели. Этот факт есть следствие того, как создавались эти модели. TCP/IP-модель создавалась post factum, а МОС - до того, как появились протоколы. Поэтому понятие протокола там абсолютно не зависит от остальных частей модели. Например, изначально протоколы канального уровня в МОС-модели создавались для соединений «точка-точка». Позднее, когда появились средства типа вещания, на этот уровень были добавлены соответствующие протоколы. Никаких других изменений не последовало. TCP/IP-модель была создана, когда TCP/IP-стек уже существовал. Поэтому эта модель прекрасно описывала этот стек, но только его, и никакой другой. Модели имеют разное число уровней. Обе имеют уровень приложений, транспортный уровень и сетевой уровень. Все остальные уровни разные. МОС-модель поддерживает на сетевом уровне как сервис с соединением, так и без соединения. На транспортном уровне этой модели поддерживается сервис только с соединением. В TCP/IP наоборот: сетевой уровень обеспечивает сервис без соединения, но транспортный - как с соединением, так и без.

1.7.4. Недостатки модели и протоколов МОС

Ни модель и протоколы МОС, ни модель и протоколы TCP/IP не являются совершенными. Начнем с модели и протоколов МОС. В конце 80-х годов казалось, что у протоколов МОС-модели нет конкурентов. Однако в настоящее время очевидно, что протоколы TCP/IP захватили большую часть мира. В чем причины? 1. Не вовремя. 2. Не технологичны. 3. Трудно реализуемы. 4. Неправильная стратегия. «Не вовремя»: введение стандарта должно следовать за окончанием исследований, но прежде, чем начнутся крупные вложения в разработку. Эту идею поясняет рисунок 1-17. Не технологичны: • Функциональность между семью уровнями распределена неравномерно. • МСО поспешило за IBM SNA (System Network Architecture). • Описание модели и ее протоколов очень сложно. • Некоторые функции, такие как управление потоком, исправление ошибок, адресация, повторяются на каждом уровне. • Для некоторых функций не ясно, на какой уровень их поместить (виртуальный терминал); шифрование и защита в модели отсутствуют. • Модель слишком ориентирована на сервис с соединениями и мало внимания уделяет сервису без соединений. • В модели доминирует связь, практически не отражена взаимосвязь между вычислениями и связью (indication vs. receive). В МОС-модели слушком велико влияние Международного комитета по телефонии и телеграфии (МКТТ).

Трудно реализуемы: первые реализации протоколов МОС были громоздки и неэффективны. Первые реализации TCP/IP были сделаны в университете Беркли в рамках проекта по созданию операционной системы UNIX.

Характеристики

Список файлов ответов (шпаргалок)