Комбинации сервисов, предоставляемых протоколами
Протоколы Канального и Сетевого уровней взаимодействуют вместе и на своих уровнях взаимозаменяемы. Это означает, что допустимо использовать практически любой протокол Канального уровня совместно с любым протоколом Сетевого уровня. Однако протоколы Транспортного уровня тесно привязаны к определенному протоколу Сетевого уровня и не могут быть замещены. Комбинация из протоколов Транспортного и Сетевого уровней предоставляет полный набор услуг, соответствующий конкретному приложению. Так же, как и на Сетевом уровне, среди протоколов Транспортного уровня могут быть выделены протоколы с установлением соединения и без установления соединения. Документ модели OSI описывает четыре возможные на этом уровне комбинации протоколов с установлением соединения и без него (рис. 2.11). Какую из комбинаций следует использовать, зависит от требуемых сервисов. Процесс выбора комбинации протоколов для выполнения определенной задачи называется отображением (mapping) службы Транспортного уровня на службу Сетевого уровня. Выбор протокола Транспортного уровня основывается на требованиях приложения, создавшего сообщение, и сервисов, уже предоставленных протоколами нижних уровней. Руководство OSI описывает пять теоретических классов протокола Транспортного уровня. ОТРО. Протокол без дополнительной функциональности. Предполагает,
что протоколы нижних уровней уже предоставляют приложению все не
|
|
|
Обходимые услуги. ОТР1. Протокол с исправлением обнаруженных ошибок. Дает возмож
Ность исправить ошибки, обнаруженные протоколами, функционирую
Щими на нижних уровнях. ОТР2. Протокол с мультиплексированием. Включает коды, идентифици
Рующие процесс, создавший пакет, и процесс, который должен обрабо
Oы достигнуть своего места назначения наиболее рациональным путем. Так
Глава 2. Эталонная сетевая модель OSI
ная
тать пакет на принимающей стороне. Это позволяет переносить трафик.
Создаваемый несколькими приложениями, через одну сетевую среду. ОТР3. Протокол с исправлением обнаруженных ошибок и мультиплекси
рованием. Сочетает услуги, предоставляемые TP1 и TP2. ОТР4. Предлагает полный набор ориентированных на подключение услуг.
Включает обнаружение и исправление ошибок, управление потоком данных и другие сервисы. Предполагает использование на нижних уровнях протоколов без установления соединения, которые не оказывают перечисленных услуг.
Протокол без установления
соединения
Протокол с установлением
соединения
Протокол бөз установления
Соединения
Протокол с установлением
|
|
|
Соединения
Рис. 2.11. Система может использовать различные комбинации протоколов с установлением соединения и без установления соединения
Данная классификация сервисов Транспортного уровня является еще одним местом, где теоретическая конструкция модели OSI основательно отличается от действительности. Ни один из широко используемых наборов протоколов не обладает пятью различными протоколами транспортного уровня, согласующимися с этими классами. Большинство блоков протоколов, таких как TCP/P, имеют в своем составе два протокола, которые в основном соотносятся с классами TPO и TP4, обеспечивающими услуги без установления соединения и с установлением соединения соответственно.
Функции протокола Транспортного уровня Протокол UDP представляет собой службу, которая вместе с протоколом IP Сетевого уровня обеспечивает минимальный объем услуг для коротких транзакций, не нуждающихся в сервисах протокола с установлением соедине
42
Часть I. Введение в сетевые технологии
ния. Транзакции системы имен доменов (DNS, Domain Name System) обычно состоят из обмена короткими сообщениями, которые умещаются в один пакет; вследствие этого управление потоком данных не требуется. Типичная транзакция состоит из запроса и ответа, который выполняет функцию подтверждения приема. Таким образом, нет необходимости в использовании какого-либо механизма, гарантирующего доставку. Однако протокол UDP имеет механизм выявления ошибок, реализованный в виде подсчета контрольной суммы, которая вычисляется на обеих системах - отправителе и получателе. Поскольку UDP обеспечивает минимум дополнительных услуг, длина его заголовка не превышает 8 байт, и издержки, вызванные добавлением служебной информации к пакету, очень незначительны. Протокол TCP, с другой стороны, является протоколом с установлением соединения, и предоставляет полный спектр услуг, но цена этого — более высокие издержки. Длина заголовка TCP составляет 20 байт. Также протокол порождает большое количество дополнительных пакетов, вызванных исключительно потребностями процедур управления, таких как установка соединения, разрыв соединения и подтверждение приема пакета.
|
|
|
Сегментация и восстановление Транспортные протоколы с установлением соединения разработаны для передачи большого количества данных, при этом информация должна быть разбита на сегменты, умещающиеся в отдельных пакетах. Сегментация данных и нумерация сегментов являются важным элементом процесса передачи и помимо этого делают осуществимым выполнение других функций, таких как исправление ошибок. Процесс маршрутизации, выполняемый на Сетевом уровне, является динамическим; и в случае передачи данных возможно возникновение ситуации, когда сегменты следуют до места назначения разными путями и приходят не в том порядке, как они были отправлены. Нумерация сегментов позволяет принимающей системе восстановить исходный порядок следования сегментов. Эта нумерация также дает возможность системе-получателю сообщить отправителю, какой из пакетов был поврежден или потерян. В результате, отправитель может не повторять целиком всю передачу, а повторно переслать только потерянные сегменты.
|
|
|
Управление потоком данных Управление потоком данных (flow control) – это одна из функций, обычно предоставляемая протоколами Транспортного уровня с установлением соединения. Она представляет собой механизм, согласно которому система, принимающая данные, может сообщить отправителю о том, что он должен снизить скорость передачи данных, или об опасности перегрузки системыполучателя и потери данных. Заголовок ТСР, например, включает в себя поле Window, при помощи которого получатель устанавливает количество байт, которое он может принять от отправителя в единицу времени. Если
Глава 2. Эталонная стевая модель OSI
это значение в пакетах, успевших дойти, уменьшается, то отправитель знает, что он должен уменьшить скорость передачи. Когда значение начинает снова расти, отправитель может увеличить скорость пересылки.
Обнаружение ошибок и восстановление информации Эталонная модель OSI определяет две формы исправления ошибок, которые могут быть реализованы протоколами Транспортного уровня с установлением соединения. Одна из них — это реакция на ошибки, обнаруженные другими протоколами стека. Данный механизм не предусматривает поиска ошибок передачи самим протоколом Транспортного уровня. Вместо этого, протокол Транспортного уровня получает извещение от протоколов СетеВого или Канального уровня о том, что возникла ошибка и определенный пакет был потерян или поврежден. Ему остается только послать сообщение, содержащее перечень пакетов и запрос на их повторную пересылку обратно системе-отправителю. Другая, и наиболее широко применяемая форма исправления ошибок на Транспортном уровне представляет собой законченный процесс, начинающийся с обнаружения ошибок и заканчивающийся их коррекцией. Этот процесс охватывает и ошибки, которые еще не были обнаружены какимлибо другим способом. Несмотря на то, что большинство протоколов Канального уровня имеют свои собственные механизмы выявления и коррекции ошибок, они функционируют только при промежуточных пересылках между двумя системами. Механизм выявления ошибок Транспортного уровня обеспечивает контроль ошибок на всем участке между двумя конечными системами и включает в себя возможность исправления ошибок, которая осуществляется путем запроса у отправителя повторной передачи определенных пакетов. Для осуществления этого в заголовок протокола Транспортного уровня включена контрольная сумма, значение которой получено из полей, не меняющихся в ходе всего путешествия до места назначения. Периодически изменяющиеся поля, такие как индикатор Time-to-Live, значение которого увеличивает каждый маршрутизатор, обрабатывающий пакет, исключены из вычисления контрольной суммы.
Сеансовый уровень
Начиная с Сеансового уровня, границы между уровнями и их функциями становятся более расплывчатыми. Нельзя выделить отдельный протокол, который функционировал бы исключительно на Сеансовом уровне. Более того, функциональные возможности Сеансового уровня поддержаны другими протоколами, в том числе функции, попадающие в сферу деятельности протоколов Представительского и Прикладного уровней. NetBIOS (Network Basic Input/Output System, сетевая базовая система ввода/вывода) и NetBEUT
44
Часть 1. Введена в сетевые технологии
(NetBIOS Extended User Interface, расширенный пользовательский интерфейс NetBIOS) — показательные примеры таких протоколов. Нижняя граница Сеансового уровня является чертой, за которой остаются все аспекты, связанные с передачей данных между двумя системами. Вопросы, касающиеся обнаружения ошибок, подтверждения приема пакетов и управления потоком данных, остаются позади этой границы, так как все, что требуется для реализации этих функций, уже делается протоколами Транспортного уровня и уровней, лежащих ниже. Сеансовый уровень также не имеет особого значения для обеспечения безопасности и процессов регистрации в сети, как это может показаться, глядя на его название. Более того, основные функции этого уровня связаны с обменом сообщениями между двумя конечными системами. Этот обмен называется диалогом (dialog). Помимо указанной, Сеансовый уровень обеспечивает множество других функций, являясь поистине многоцелевым "инструментарием" для разработчиков программного обеспечения. Сервисы, обеспечиваемые Сеансовым уровнем, очень широко трактуются, и даже во время разработки модели OSI существовал ряд вопросов относительно того, к какому уровню их отнести. Двадцать два различных сервиса, предоставляемые Сеансовым уровнем, собраны в подгруппы, такие как блок функций ядра (Kernel Function Unit), подмножество основных действий (Basic Activity Subset) и подмножество основной синхронизации (Basic Synchronization Subset). Большинство этих сервисов интересны только разработчикам, а некоторые даже дублируются в результате компромисса, принятого комитетами во время слияния двух стандартов при создании модели OSI. Взаимодействие между уровнями модели OSI упрощается за счет применения примитивов службы запросов (service request primitives), представляющих собой отдельные средства инструментария разработчика. Каждый уровень предоставляет услуги уровню, расположенному непосредственно над ним. Процесс использования уровнем услуг, оказываемых нижележащим уровнем, осуществляется путем выполнения команд, предлагаемых соответствующим примитивом службы запросов, с указанием значений дополнительных требуемых параметров. Таким образом, процесс Прикладного уровня осуществляет запрос сетевого ресурса, используя примитив, предложенный Представительским уровнем. Когда запрос передается вниз через уровни, каждый из них задействует соответствующий примитив нижележащего уровня. Этот процесс выполНяется до тех пор, пока сообщение не будет готово для передачи по сети. Как только пакет достигнет своего места назначения, он преобразуется в указательные примитивы (indication primitives), которые передаются вверх через уровни стека процессу приложения-получателя. Управление диалогом и разделение диалогов – два наиболее важных сервиса, относящихся к Сеансовому уровню. Управление диалогом (dialog control) — это средство, которое позволяет двум системам начать диалог, обменяться
Глава 2. Эталонная стевая модель OSI
Сообщениями, а после закончить диалог с уверенностью, что каждая система получила предназначенные для нее сообщения. Это может показаться простой задачей, но примем во внимание тот факт, что система может передать сообщение другой системе и получить назад сообщение без уверенности в том, что это ответ. Было ли принятое сообщение ответной посылкой или оно было передано раньше? Такой тип коллизии может вызвать серьезные проблемы, особенно когда одна из систем пытается завершить диалог или создать контрольную точку. Разделение диалога (dialog separation) — это процесс вставки указателей в поток данных, доставляемых между двумя системами. Эти указатели называются точками контроля (checkpoints), они размещаются таким образом, что в один и тот же момент времени может быть получена информация о состоянии обеих систем.
Управление диалогом Когда две системы вступают в диалог Сеансового уровня, они выбирают Один из двух режимов управления обменом сообщениями на все время сеанса: либо полудуплексный обмен, либо дуплексный. Каждое сеансовое соединение имеет уникальный идентификатор размером 196 байт, состоящий из четырех элементов: Оуказатель SS-USER инициатора; Оуказатель SS-USER ответчика; ообщий указатель; Одополнительный указатель. Однажды выбранный режим обмена не подлежит изменению. Для того чтобы переключиться на другой режим, необходимо разорвать соединение и установить его заново. При полудуплексном режиме в любой из моментов времени только одна из систем может передавать сообщения. Право передачи определяется посредством маркера данных (data token). Каждая система по завершении передачи отправляет маркер другой системе, используя примитив S-TOKEN-GIVE. Только получив маркер, другая система может начать передачу своего сообщения. Также существует примитив S-TOKEN-PLEASE, который система может использовать для того, чтобы запросить маркер. Использование дуплексного режима значительно усложняет процесс обмена. Как свидетельствует название режима, при дуплексном обмене маркер не используется и обе системы могут передавать сообщения одновременно.
Примечание
Важно понимать, что маркер и соединение на Сеансовом уровне не имеют ничего общего с одноименными элементами нижележащих протоколов. Маркер Сеансового уровня не является эквивалентом маркера, используемого прото
46
Часть I. Введены
в сетевые технологии
Колом Token Ring, как и соединение Сеансового уровня не эквивалентно соединению Транспортного уровня протокола ТСР. Две системы могут разорвать соединение Сеансового уровня, в то время как соединение Транспортного уровня будет открыто для дальнейшего обмена.
Использование маркера предотвращает возникновение проблем, связанных с перекрестными сообщениями, и обеспечивает механизм упорядоченного завершения (оrdеrlу termination) соединения между системами. Согласно порядку процедуры завершения соединения, одна из систем сигнализирует о своем намерении разорвать соединение и передает маркер. Другая система, получив маркер, пересылает все данные, оставшиеся в ее буферах, и использует примитив S-RELEASE, чтобы подтвердить прием запроса разъединения. Приняв примитив S-RELEASE, первая система знает, что она получила от другой системы все данные, ожидавшие отправки. Теперь она может использовать примитив S-DISCONNECT для разрыва соединения. В управлении диалогом предусмотрен механизм согласованного разъединения (negotiated release). Он дает возможность одной системе отказать другой системе в разъединении. Эта возможность используется в случае появления коллизии, которая может возникнуть, если обе системы одновременно сделают запрос на разъединение. Также существует маркер разъединения (release token), который в первую очередь служит для предотвращения возникновения подобных коллизий. Он позволяет сделать запрос на разъединение только одной из систем. Все эти механизмы являются "инструментами" из набора средств, который Сеансовый уровень предоставляет разработчикам приложений; они не являются автоматически выполняющимися фоновыми процессами. Когда создается приложение, разработчик должен сам принять решение о соответствии используемых примитивов поставленной задаче. Например, употребить примитив S-TOKEN-GIVE вместо примитива S-TOKEN-PLEASE, или применить согласованное разъединение вместо упорядоченного.
Разделение диалога Приложения создают контрольные точки, чтобы сохранить свое текущее состояние на диске на случай системного сбоя. Во время разработки модели OSI этот метод более широко использовался, нежели сейчас. Как и в случае с процессами управления диалогом, которые обсуждались ранее, процедура расстановки контрольных точек должна быть явно определена разработчиком, если в ней есть необходимость. Когда приложение вовлекло во взаимодействие через сеть две системы, контрольная точка должна обеспечить сохранение состояния обеих систем в один и тот же момент. Выполнить согласованное действие на двух различных компьютерах в точно определенный момент почти невозможно. Системы могут осуществлять тысячи действий в секунду, и их синхронизация
Глава 2. Эталонная гевая модель OSI
должна быть точна настолько, насколько это необходимо для одновремен
47 ного выполнения конкретной задачи. Вдобавок возникает проблема сообщений, которые могут быть еще в пути во время создания контрольной точки. В результате разделение диалога посредством сохранения контрольной Точки в определенном месте потока данных, пересылаемого между двумя системами, оказывается точнее, чем выполнение этого действия в опреден ленный момент времени. В полудуплексном режиме процесс создания контрольных точек сравнительно прост. Одна система создает точку контроля и отправляет примитив, называемый S-SYNC-MINOR. Другая система, получив этот примитив, создает свою собственную точку контроля, уверенная в том, что во время синхронизации не осталось данных, находящихся в процессе передачи. Такой процесс называется простой синхронизацией (minor synchronization), так как он работает с потоком данных, следующим только в одном направлении, и требует только одной операции обмена управляющими сообщениями. В дуплексном (полнодуплексном) режиме также возможно применение простой синхронизации. Для этого используется специальный маркер простой синхронизации, который удерживает обе системы от одновременной передачи примитива S-SYNC-MINOR. Если бы было возможно переключиться из дуплексного режима в полудуплексный, не разрывая соединения, то в применении дополнительного маркера не было бы необходимости, но переключиться между режимами невозможно. Это как раз то, что многие люди считают основным недостатком в спецификации Сеансового уровня. В большинстве случаев системы, использующие дуплексный режим соединения, должны выполнять сложную синхронизацию (major synchronization), которая Отвечает не только за трафик, который может передаваться в обоих направлениях, но также и за скоростной трафик. Примитив S-EXPEDITED позволяет осуществить передачу от одной системы к другой, используя высокоскоростной канал, отделенный от обычных коммуникационных каналов. Выполняя рассматриваемую синхронизацию, система, владеющая маркером сложной синхронизации (major/activity token), отправляет примитив S-SYNC-MAJOR, а затем останавливает передачу до тех пор, пока не получит ответ. Тем не менее, система, пославшая Этот примитив, не может пока еще создать контрольную Точку, как это легко получается при простой синхронизации, поскольку трафик от другой системы в данный момент может еще передаваться. Получив примитив, принимающая сторона может создать свою контрольную точку, так как все переданные ей данные уже приняты, включая срочные, которые должны были прибыть до получения примитива. Затем принимающая система передает подтверждающий ответ через обычный канал и специальное сообщение PREPARE через канал срочной связи. Система, инициировавшая процедуру синхронизации, получает сначала сообщение PREPARE, а затем подтверждение. После чего она может приступить к созданию своей точки контроля.
Часть I. Введенче в сетевые технологии
Представительский уровень
В отличие от Сеансового уровня, который обеспечивает множество различных функций, Представительский уровень имеет только одну. На самом деле большую часть времени Представительский уровень в основном функционирует как служба перевода (pass-through service). Это значит, что он получает примитивы от Прикладного уровня и передает их дубликаты вниз Сеансовому уровню, используя точку доступа к сервису Представительского уровня (PSAP, Presentation Service Access Point) и точку доступа к сервису Сеансового уровня (SSAP, Session Service Access Point). Все рассуждения предыдущих разделов об использовании приложениями служб Сеансового уровня в действительности, хотя и неявно, уже затрагивали вопросы, связанные со службой перевода Представительского уровня, так как процессы на любом уровне модели OSI могут непосредственно взаимодействовать только с соседними уровнями. В то время как основные функции примитивов не изменяются в процессе прохождения ими Представительского уровня, сами примитивы могут быть подвергнуты процессу перевода, являющемуся основной функцией уровня. Приложение создает запрос к сетевым ресурсам, используя свой "родной" синтаксис, однако язык системы, принимающей запрос, может быть отличным. Например, соединение между РС и Мэйнфреймом может потребовать перекодирования сообщений из ASCII в EBCDIC. Системы могут также применять шифрование и/или сжатие данных, передаваемых через сеть. Процесс перевода осуществляется в две фазы, одна из которых выполняется на Представительском уровне каждой из систем. Каждый из компьютеров поддерживает абстрактный синтаксис, который представляет собой "родной" синтаксис приложения, выполняемого в системе, и синтаксис передачи, используемый для доставки данных через сеть. Представительский уровень системы, отправляющей сообщение, переводит данные из формата, соответствующего абстрактному синтаксису, в формат синтаксиса передачи, а затем
Передает их вниз Сеансовому уровню. Когда сообщение достигает системыполучателя, тот же Представительский уровень переводит данные из синтаксиса передачи в абстрактный синтаксис приложения, принимающего сообщение. Выбор синтаксиса передачи для каждого абстрактного синтаксиса основывается на соглашении, которое достигается после установления соединения Представительского уровня между двумя системами. В зависимости от требований приложения и природы соединения между системами, синтаксис передачи может поддерживать шифрование информации, сжатие данных или просто преобразование.
Примечание
Дата добавления: 2018-06-27; просмотров: 295; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!