Лекции 2010-го года (1130544), страница 4
Текст из файла (страница 4)
Сначала активность выполняет CONNECT.request, в результате чего в сетьвыпускается пакет. Получатель получает CONNECT.indication, указывающий на то, что сним хотят установить соединение. В ответ получатель через примитив CONNECT.responseсообщает, готов он установить соединение или отказывает в установлении соединения. Врезультате активность - инициатор установления соединения получает ответ черезпримитив CONNECT.confirm, чего следует ожидать.Большинство примитивов имеет параметры. Параметры примитива CONNECT.requestопределяют адресата, соединение, желаемое качество сервиса и максимальный размерсообщения, допустимый для данного соединения.
Параметры примитиваCONNECT.indication указывают, кто обратился, желаемое качество обслуживания,предлагаемый размер сообщений. Если активность, к которой обратились, не согласна,например, с предлагаемым размером сообщений, то она предлагает свой размер черезпримитив response, который становится известным активности, добивающейсясоединения, через примитив confirm. Подробности этих переговоров - существопротокола. Например, в случае конфликта при установлении максимального размерасообщения протокол может установить, что выбирается наименьший из предложенных.Услуга может быть либо с подтверждением, либо без подтверждения. При услуге сподтверждением действуют все четыре примитива - request, indication, response, confirm.При услуге без подтверждения используются только два примитива - request и indication.Услуга CONNECT обязательно должна быть с подтверждением.
УслугаDATA_TRANSFER может быть как с подтверждением, так и без, в зависимости от того,нужно отправителю уведомление или нет. Оба вида услуг используются в сетях.Продемонстрируем концепцию услуг на следующем примере простых услуг ссоединением со следующими 8-ю примитивами:1.CONNECT.request - запрос на установление соединения.2.CONNECT.indication - сигнал для удаленной активности.3.CONNECT.response - используется удаленной активностью длясогласия/несогласия на соединение.4.CONNECT.confirm - cообщает активности, инициирующей соединение, принятооно или нет.5.DATA.request - запрос на передачу данных.6.DATA.indication - сигнал поступления данных.7.DISCONNECT.request - запрос на разрыв соединения.198.DISCONNECT.indication - сигнал равнозначной активности на запрос.Ниже, взяв в качестве примере телефонный разговор, показано как в терминахвышеприведенных примитивов можно описать телефонный разговор:1.CONNECT.request - Вы набираете номер друга.2.CONNECT.indication - Он слышит звонок.3.CONNECT.response - Он берет трубку.4.CONNECT.confirm - Вы слышите, что гудки прекратились.5.DATA.request - Вы предлагаете ему встретиться.6.DATA.indication - Он слышит Ваше приглашение.7.DATA.request - Он говорит, что согласен.8.DATA.indication - Вы слышите его ответ.9.DISCONNECT.request - Он кладет трубку.10.
DISCONNECT.indication - Вы слышите, что он положил трубку и кладете трубку.1.6.7. Взаимосвязь сервиса и протоколовСервис и протоколы - понятия разные, но их часто путают. Различие между ниминастолько важно, что рассмотрим его еще раз. Сервис - это набор услуг, который уровеньпредоставляет уровню над ним. Сервис определяют в терминах примитивных операций,образующих интерфейс между уровнями.
Инициируя выполнение определеннойпоследовательности примитивных операций, вышележащий уровень определяет, какойсервис ему нужен. Но он ничего не говорит о том, как эти операции должны бытьреализованы. Сервис относится к интерфейсу между уровнями. Нижележащий уровеньявляется поставщиком сервиса, а вышележащий - его пользователем.Протокол - это набор правил, определяющих формат, назначение передаваемыхфрагментов данных: фреймов, пакетов, сообщений, которыми обмениваютсяравнозначные активности на определенном уровне. Активности используют протоколыдля реализации сервиса. Они могут изменить протокол, но не сервис, видимый ихпользователями. Отсюда ясно, что сервис и протокол не связаны между собой.Раздел 1.7.
Модели сетей.До сих пор мы рассматривали некоторые абстрактные понятия. Теперь мы рассмотрим двеконкретные эталонные модели сетей: эталонную модель ISO OSI и эталонную модельTCP/IP.1.7.1. Эталонная модель OSIМодель OSI (Open Systems Interconnection - модель взаимодействия открытых систем(рисунок 1-13) была разработана Международной организацией по стандартизации (МОС20- International Standards Organization (ISO)) - для определения международных стандартовкомпьютерных сетей.
Эта модель описывает, как должна быть организована система,открытая для взаимодействия с другими системами.Рисунок 1-13. Модель взаимодействия открытых систем (OSI)Модель МОС имеет семь уровней. Принципы выделения этих уровней таковы:1.Каждый уровень имеет определенное предназначение.2.Каждый уровень защищает нижележащий уровень от различий возможныхреализаций.3.Предназначение каждого уровня выбиралось прежде всего так, чтобы для негоможно было определить международный стандарт.4.Границы между уровнями выбирались с целью минимизировать поток информациичерез интерфейсы.5.Число уровней выбиралось достаточно большим, чтобы не объединять разныефункции на одном уровне, но и достаточно малым, чтобы архитектура не былагромоздкой.Теперь рассмотрим каждый уровень этой модели. Отметим, что это - модель, а неархитектура сети. Она не определяет протоколы и сервисы каждого уровня, а лишьговорит, какие функции должны быть реализованы на нем.
Организация ISO выпустилатакже стандарты для каждого уровня, но они не являются частью этой модели.211.7.1.1. Физический уровеньФизический уровень отвечает за передачу последовательности битов через канал связи.Одной из основных проблем, решаемых на этом уровне, является то, как гарантировать,что если на одном конце отправили 1, то на другом получили 1, а не 0. На этом уровнетакже решаются такие вопросы, как: каким напряжением нужно представлять 1, а каким 0; сколько микросекунд тратится на передачу одного бита; следует ли поддерживатьпередачу данных в обоих направлениях одновременно; как устанавливается начальноесоединение и как оно разрывается; каково количество контактов на физическом разъеме,для чего используется каждый контакт этого разъема.
Здесь в основном решаютсявопросы механики и электрики.1.7.1.2. Уровень канала данныхОсновная задача уровня канала данных - превратить несовершенную физическую средупередачи в надежный канал, свободный от ошибок передачи. Эта задача решаетсяразбиением данных отправителя на фреймы (обычно от нескольких сотен до несколькихтысяч байтов), последовательной передачей фреймов и обработкой фреймов уведомления,поступающих от получателя. Поскольку физический уровень не распознает структуры впередаваемых данных, то сохранение этой структуры - целиком и полностью задачаканала данных, а именно, на этом уровне нужно определить границы фрейма. Эта задачарешается введением специальной последовательности битов, которая добавляется вначало и в конец фрейма и всегда интерпретируется как границы фрейма.Помехи на линии могут разрушить фрейм. В этом случае он должен быть переданповторно.
Он будет повторен также в том случае, если фрейм уведомления будет потерян.И это уже заботы уровня - как бороться с дубликатами одного и того же фрейма, потерямиили искажениями фреймов. Уровень канала данных может поддерживать для сетевогоуровня сервис разных классов, разного качества и стоимости.Другая проблема, возникающая на уровне канала данных (равно как и на другихвышележащих уровнях), - как управлять потоком передачи. Например, как предотвратить«захлебывание» получателя? Как сообщить передающему размер буфера для приемапередаваемых данных, имеющийся у получателя в этот момент?Если канал позволяет передавать данные в обоих направлениях одновременно, т.е.
еслифреймы уведомления для потока от А к В используют тот же канал, что и трафик от В к А,то можно использовать для передачи фреймов уведомлений от В к А фреймы DU от А к В.В сетях с вещательным способом передачи возникает проблема управления доступом кобщему каналу.
За это отвечает специальный подуровень канального уровня - подуровеньдоступа к среде (MAC - Media ACcess).1.7.1.3. Сетевой уровеньОсновная проблема, решаемая на сетевом уровне, - как маршрутизировать пакеты ототправителя к получателю. Маршруты могут быть определены заранее и прописаны встатической таблице, которая не изменяется.
Они могут также определяться в моментустановления соединения. Наконец, они могут строиться динамически по ходу передачи взависимости от загрузки сети.22Если в транспортной подсети циркулирует слишком много пакетов, то они могутиспользовать одни и те же маршруты, что будет приводить к заторам или перегрузкам.Эта проблема также решается на сетевом уровне.Поскольку за использование транспортной подсети, как правило, предполагается оплата,то на этом уровне присутствуют функции учета: как много байт (или символов) послалили получил абонент сети.
Если абоненты расположены в разных странах, где действуютразные тарифы, то надо должным образом скорректировать цену услуги.Если пакет адресован в другую сеть, то надо предпринять надлежащие меры: в ней можетбыть другой формат пакетов, способ адресации, размер пакетов, другие протоколы и т.д. все эти проблемы решаются на сетевом уровне.В сетях с вещательной передачей проблемы маршрутизации просты, и этот уровень частоотсутствует.1.7.1.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
