Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

Глава 2

Связь

2.1.

Уровни протоколов

2.2.

Удаленный вызов процедур

2.3.

Обращение к удаленным объектам

2.4.

Связь посредством сообщений

2.5. Связь на основе потоков данных

2.6.

Итоги

Связь между процессами

—

это суть распределенных систем. Нет смысла изучать

распределенные системы, не рассматривая при этом во всех подробностях спосо-

бы обмена информацией между различными процессами, выполняющимися на

разных машинах. Взаимодействие в распределенных системах всегда базируется

на низкоуровневом механизме передачи сообщений, предоставляемом базовой

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

передачу сообщений сложнее, чем использование примитивов на базе разделяе-

мой памяти. Современные распределенные системы часто включают в себя тыся-

чи или даже миллионы процессов, разбросанных по ненадежной сети, такой как

Интернет. Если не заменить простейшие средства взаимодействия в компьютер-

ных сетях чем-то иным, разработка масштабных приложений будет достаточно

сложной.

Мы начнем эту главу с обсуждения правил, которых придерживаются сооб-

щающиеся между собой процессы. Их обычно называют протоколами. Мы со-

средоточимся на структурировании этих протоколов в виде уровней. Затем мы

рассмотрим четыре широко распространенные модели взаимодействия: удален-

ный вызов процедур (Remote Procedure Call, RPC), удаленное обращение к ме-

тодам (Remote Method Invocation, RMI), ориентированный на сообщения про-

межуточный уровень (Message-Oriented Middleware, MOM) и потоки данных

(streams).

Нашей первой моделью взаимодействия в распределенных системах станет

удаленный вызов процедур. Механизм RFC нацелен на сокрытие большей части

проблем передачи сообщений и идеален для приложений архитектуры клиент-

сервер. Усовершенствованный вариант модели RFC имеет вид удаленного обра-

82 Глава 2. Связь

щения к методам, которое основано на представлении распределенных объектов.

Механизмы RPC и RMI рассматриваются в отдельных разделах.

Во многих распределенных приложениях связь не ограничивается слегка уре-

занным шаблоном взаимодействий клиента и сервера. В подобных случаях мыс-

лить категориями сообщений оказывается предпочтительнее. Однако применение

разнообразных низкоуровневых средств связи компьютерных сетей приведет

к серьезным нарушениям прозрачности распределения. Альтернативой им явля-

ется высокоуровневая модель очереди сообщений, связь в которой очень напо-

минает системы электронной почты. Ориентированный на сообщения средний

уровень

—

это достаточно важная тема, чтобы отвести отдельный раздел и на

нее.

Что касается мультимедиа в распределенных системах, понемногу становится

очевидным, что такр1м системам недостает поддержки передачи непрерывных

потоков, таких как аудио или видео. Им необходимо понятие потока, который

позволяет поддерживать непрерывно идущие сообщения в соответствии с раз-

личными огранР1чениями по синхронизации. Потоки обсуждаются в последнем

разделе этой главы.

2.1.

Уровни протоколов

в условиях отсутствия совместно используемой памяти вся связь в распределен-

ных системах основана на обмене (низкоуровневыми) сообщениями. Если про-

цесс Л хочет пообщаться с процессом

В,

он должен сначала построить сообщение

в своем собственном адресном пространстве. Затем он выполняет системный вы-

зов,

который пересылает сообщение по сети процессу В. Хотя основная идея

выглядит несложной, во избежание хаоса А и В должны договориться о смысле

пересылаемых нулей и единиц. Если А посылает потрясающий новый роман, на-

писанный по-французски, в кодировке IBM EBCDIC, а В ожидает результаты пе-

реучета в супермаркете, на английском языке и в кодировке ASCII, их взаимо-

действие будет не слишком успешным.

Необходимо множество различных договоренностей. Сколько вольт следует

использовать для передачи нуля, а сколько для передачи единицы? Как получа-

тель узнает, что этот бит сообщения

—

последний? Как ему определить, что со-

общение было повреждено или утеряно, и что ему делать в этом случае? Какую

длину имеют числа, строки и другие элементы данных и как они отображаются?

Короче говоря, необходимы соглашения различного уровня, от низкоуровневых

подробностей передачи битов до высокоуровневых деталей отображения инфор-

мации.

Чтобы упростить работу с множеством уровней и понятий, используемых

в передаче данных. Международная организация по стандартам {International

Standards

Organization,

ISO) разработала эталонную модель, которая ясно опре-

деляет различные уровни, дает им стандартные имена и указывает, какой уро-

вень за что отвечает. Эта модель получила название

Эталонной

модели взаимо-

действия открытых систем {Open Systems Interconnection Reference

Model)

[120].

2.1.

Уровни протоколов 83

Это название обычно заменяется сокращением модель ISO OSI, или просто мо-

дель OSL Следует заметить, что протоколы, которые должны были реализовы-

вать части модели OSI, никогда не получали широкого распространения. Однако

сама по себе базовая модель оказалась вполне пригодной для исследования ком-

пьютерных сетей. Несмотря на то что мы не собираемся приводить здесь полное

описание этой модели и всех ее дополнений, небольшое введение в нее будет нам

полезно. Дополнительные детали можно почерпнуть в

[446].

Модель OSI разрабатывалась для того, чтобы предоставить открытым систе-

мам возможность взаимодействовать друг с другом. Открытая система — это

система, которая способна взаимодействовать с любой другой открытой систе-

мой по стандартным правилам, определяющим формат, содержимое и смысл от-

правляемых и принимаемых сообщений. Эти правила зафиксированы в том, что

называется протоколами {protocols). Для того чтобы группа компьютеров могла

поддерживать связь по сети, OHPI ДОЛЖНЫ договориться об используемых прото-

колах. Все протоколы делятся на два основных типа. В протоколах с устаповле-

нием соединения (connection-oriented) перед началом обмена данными отправи-

тель и получатель должны установить соединенрш и, возможно, договориться

о том, какой протокол они будут использовать. После завершения обмена они

должны разорвать соединение. Системой с установлением соединения является,

например, телефон. В случае протоколов без установления соединения (connec-

tionless) никакой подготовки не нужно. Отправитель посылает первое сообще-

ние,

как только он готов это сделать. Письмо, опущенное в почтовый ящик, —

пример связи без установления соединения. В компьютерных технологиях ши-

роко применяется как связь с установлением соединения, так и связь без уста-

новления соединения.

В модели OSI взаимодействие подразделяется на семь уровней, как показано

на рис. 2.1. Каждый уровень отвечает за один специфический аспект взаимодей-

ствия. Таким образом, проблема может быть разделена на поддающиеся реше-

РП1Ю части, каждая из которых может разбираться независимо от других. Каж-

дый из уровней предоставляет интерфейс для работы с вышестоящим уровнем.

Интерфейс состоит из набора операций, которые совместно определяют интер-

фейс,

предоставляемый уровнем тем, кто им пользуется.

Когда процесс А на машине 1 хочет пообщаться с процессом В на машине 2,

он строит сообщение и посылает его прикладному уровню своей машины. Этот

уровень может представлять собой, например, библиотечную процедуру или реа-

лизовываться как-то иначе (например, внутри операционной системы или внеш-

него сетевого процессора). Программное обеспечение прикладного уровня до-

бавляет в начало сообщения свой заголовок (header) и передает получившееся

сообщение через интерфейс с уровня 7 на уровень 6, уровень представления.

Уровень представления, в свою очередь, добавляет в начало сообщения свой за-

головок и передает результат вниз, на сеансовый уровень и т. д. Некоторые уров-

ни добавляют не только заголовок в начало, но и завершение в конец. Когда со-

общение дойдет до физического уровня, он осуществит его реальную передачу,

как это показано на рис. 2.2.

Глава 2. Связь

1 1

Сеть

Рис.

2.1.

Уровни, интерфейсы и протоколы модели OSI

Приложение

Представление

Сеанс

Транспорт

Сеть

Передача данных

Физическое воплощение

^--

Ч--

^--

Прикладной протокол

Протокол представлений

Сеансовый протокол

Транспортный протокол

Сетевой протокол

Канальный протокол

Физический протокол

—^

—w^

- -W

• Заголовок канального уровня

- Заголовок сетевого уровня

Заголовок транспортного уровня

•

Заголовок сеансового уровня

- Заголовок уровня представления

г- Заголовок прикладного уровня

У t У Т

Сообщение

Завершение

- канального

уровня

Фактически передаваемые по сети биты

Рис. 2.2. Передача по сети типового сообщения

Когда сообщение приходит на машину 2, оно передается наверх, при этом на

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

концов сообщение достигает получателя, процесса Б, который может ответить на

него,

при этом вся история повторяется в обратном направлении. Информация

из заголовка уровня п используется протоколом уровня п.

В качестве примера важности многоуровневых протоколов рассмотрим обмен

информацией между двумя компаниями, авиакомпанией Zippy Airlines и постав-

щиком продуктов Mushy Meals, Inc. Каждый месяц начальник отдела обслужи-

вания пассажиров Zippy просит свою секретаршу связаться с секретаршей ме-

неджера по продажам Mushy и заказать 100 000 коробок «резиновых» цыплят.

Обычно заказы пересылались почтой. Однако из-за постепенного ухудшения ка-

чества почтовых услуг в один прекрасный момент секретарши решают больше

не писать друг другу письма, а связываться по факсу. Они могут делать это, не

беспокоя своих боссов, поскольку протокол касается физической передачи зака-

зов,

а не их содержания.

2.1.

Уровни протоколов 85

Точно так же начальник отдела обслуживания пассажиров может решить от-

казаться от цыплят и перейти на новый деликатес от Mushy, превосходные козьи

ребра, это решение никак не скажется на работе секретарш. Это происходит по-

тому, что у нас есть два уровня

—

боссы и их секретарши. Каждый уровень имеет

свой собственный протокол (темы для обсуждения и технологию), который мож-

но изменить независимо от другого. Эта независимость делает многоуровневые

протоколы привлекательными. Каждый уровень при появлении новых техноло-

гий может быть изменен независимо от других.

В модели OSI, как было показано на рис. 2.1, не два уровня, а семь. Набор

протоколов, используемых в конкретной системе, называется

комплектом,

или

стеком

протоколов.

Важно отличать эталонную модель от реальных протоколов.

Как мы отмечали, протоколы OSI никогда не были популярны. В противополож-

ность им протоколы, разрабатывавшиеся для Интернета, такие как TCP и IP,

используются повсеместно. В последующих пунктах мы кратко рассмотрим каж-

дый из уровней модели OSI, начиная с нижнего. Однако вместо того, чтобы при-

водить примеры соответствующих протоколов OSI, мы рассмотрим протоколы

Интернета, используемые на каждом из этих уровней.

2.1.1.

Низкоуровневые протоколы

Мы начнем с обсуждения трех нижних уровней комплекта протоколов OSI. Эти

три уровня совместно реализуют основные функции компьютерной сети.

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

Физический уровень ответственен за передачу щлш и единиц. Сколько вольт

использовать для передачи нуля или единицы, сколько бит в секунду можно пе-

редать и можно ли осуществлять передачу одновременно в двух направлениях

—

вот основные проблемы физического уровня. Кроме того, к физическому уровню

относится размер и форма сетевых коннекторов (разъемов), а также число выво-

дов и назначение каждого из них.

Протоколы физического уровня отвечают за стандартизацию электрических,

механических и сигнальных интерфейсов, чтобы, если одна машина посылает

ноль,

другая приняла его как ноль, а не как единицу. Было разработано множест-

во стандартов физического уровня для различных носителей, например стандарт

RS-232-C для последовательных линий связи.

Канальный уровень

Физический уровень только пересылает биты. Пока нет ошибок, все хорошо. Од-

нако в реальных сетях происходят ошибки, и их нужно как-то находить и исправ-

лять.

Это и является главной задачей канального уровня. Он группирует биты

в модули, обычно называемые кадрами {frames), и следит за тем, чтобы каждый

кадр был передан правильно.

Канальный уровень делает это путем помещения специальной битовой маски

в начало и конец каждого кадра для их маркировки, а также путем вычисления

контрольной

суммы

{checksum),

то есть суммирования всех байтов кадра опреде-

Глава 2. Связь

ленным образом. Канальный уровень добавляет контрольную сумму к кадру. Ко-

гда кадр принимается, приемник повторно вычисляет контрольную сумму данных

и сравнивает результат с контрольной суммой, пришедшей вместе с кадром. Ес-

ли они совпадают, кадр считается верным и принимается. Если они различны,

получатель просит отправителя снова отправить этот кадр. Кадры последова-

тельно нумеруются с указанием номеров в заголовке, так что все понимают, где

какой кадр.

На рис. 2.3 мы видим случай (отчасти патологический) посылки двух сооб-

щений

и 2 с машины Л на машину

В.

Сообщение с данными

посылается с ма-

шины

в момент времени 0. Когда в момент времени

это сообщение достигает

машины В, обнаруживается, что оно повреждено помехами в линии передачи

и контрольная сумма не соответствует действительности. Машина В обнаружи-

вает это и в момент времени 2 запрашивает повторную посылку, отправляя соот-

ветствующее контрольное сообщение 0. К сожалению, в тот же самый момент

машина Л посылает сообщение 1. В ответ на полученный машиной Л запрос на

повторную посылку отправляется сообщение 0. Когда машина В получает сооб-

щение с данными 1 (а ведь она запрашивала сообщение с данными О!), она посы-

лает машине Л новое контрольное сообщение 1, настаивая на том, что она хочет

получить сообщение с данными О, а не 1. Когда контрольное сообщение 1 дохо-

дит до машины Л, та посылает сообщение с данными

в третий раз.

Время А

Сообщение

сданными 0

Сообщение

сданными 1

Контрольное

сообщение 0

Сообщение

сданными 0

Контрольное

сообщение 1

Сообщение

сданными 0

\//

...X...

j/^

\ Х

..рк!..

Сообщение

сданными 0

Контрольное

сообщение 0

Сообщение

сданными 1

Контрольное

сообщение 1

ic ^4( Сообщение

сданными 0

Сообщение

с данными 0

Событие

Машина А посылает сообщение

сданными 0

Машина В получает сообщение

сданными 0

Машина А посылает сообщение с данными 1.

Машина В обнаруживает несовпадение

контрольной суммы

Оба сообщения достигают своей

цели без ошибок

Машина А снова посылает сообщение с данными

Машина В говорит: «Мне нужно сообщение

сданными 0, а не 1»

Оба сообщения достигают

своей цели без ошибок

Машина А снова посылает

сообщение с данными 0

В конце концов машина В получает

сообщение с данными 0

Рис. 2.3. Обмен между получателем и отправителем канального уровня

Задача этого обсуждения

—

не показать, насколько хорош описанный прото-

кол (он очень плох), а объяснить, что на каждом уровне существует необходи-

мость во взаимодействии между отправителем и получателем. Типичные сооб-

щения: «Пошли, пожалуйста, сообщение п заново»

—

«Уже посылал дважды»

—

2.1.

Уровни протоколов 87

«Нет, ты этого не делал» — «А я говорю, делал» ~ «Ну ладно, пускай делал, все

равно пошли еще раз» и т. д. Это взаимодействие происходит в полях заголовка,

где определены различные запросы и ответы и могут поддерживаться параметры

(например, номера кадров).

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

в локальных сетях у отправителя обычно нет необходимости находить местопо-

ложение получателя. Он просто бросает сообщение в локальную сеть, а получа-

тель забирает его оттуда. Глобальные сети, однако, содержат множество машин,

каждая из которых имеет собственные линии связи с другртми машинами. Так на

крупномасштабной карте показано множество городов и соединяющих их дорог.

Сообщение, посылаемое от отправителя к получателю, должно пройти массу

сетевых сегментов, на каждом из которых происходит выбор исходящей линии.

Задача выбора наилучшего пути называется маршрутизацией (routing) и являет-

ся основной задачей сетевого уровня.

Проблема усложняется тем, что наиболее короткий путь не всегда является

наилучшим. На самом деле важна величина задержки на выбрагиюм маршруте.

Она, в свою очередь, зависит от объема трафика и числа сообщений, стоящих

в очереди на отправку по различным линиям. С течением времени задержка мо-

жет меняться. Некоторые алгоритмы маршрутизации могут подстраиваться под

изменения загруженности линий, некоторые же удовлетворяются тем, что при-

нимают решение на основе усредненных значений.

В настоящее время, вероятно, наиболее широко распространенным сетевым

протоколом является не требующий установкрг соединения протокол Интерне-

та {Internet protocol, IP), входящий в комплект протоколов Интернета. На сете-

вом уровне сообщение именуется термином пакет {packet). IP-пакет может быть

послан без какой-либо предварительной подготовки. Маршрут каждого из IP-па-

кетов до места назначения выбирается независимо от других пакетов. Никакие

внутренние пути не выбираются заранее и не запомрнлаются.

Протоколом с соединением, приобретающим популярность в настоящее вре-

мя,

является виртуальный канал {virtual channel) на базе сетей ATM. Виртуаль-

ный канал в ATM — это непрямое соединение, устанавливаемое от источника

к приемнику, возможно, проходящее через несколько промежуточных АТМ-ком-

мутаторов. Чтобы между двумя компьютерами не устанавливать каждый из вир-

туальных каналов по отдельности, набор виртуальных каналов может быть сгруп-

пирован в виртуальный путь {virtual path). Виртуальный путь сравним с пред-

определенным маршрутом между двумя узлами, вдоль которого выстраиваются

все его виртуальные каналы. Р1зменение маршрута виртуального пути означает

автоматическую перекладку всех ассоциированных с ним каналов

[194].

2.1.2.

Транспортные протоколы

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

—

это последняя часть того, что называют базовым стеком

сетевых протоколов, поскольку в нем реализованы все службы, которые необхо-

димы для построения сетевых приложений и которые не вошли в интерфейс се-

88 Глава 2. Связь

тевого уровня. Другими словами, транспортный уровень дает возможность разра-

ботчикам приложений использовать базовую сеть, лежащую в его основе.

Функции транспортного уровня

На пути от отправителя к получателю пакеты могут теряться. В то время как од-

ни приложения задействуют собственные процедуры исправления ошибок, дру-

гие предпочитают надежную связь. Предоставить им эту службу

—

дело транс-

портного уровня. Идея состоит в том, что приложение должно быть в состоянии

передать сообщение транспортному уровню и ожидать того, что оно будет достав-

лено без потерь.

После получения сообщения с прикладного уровня транспортный уровень

разбивает его для успешной передачи на достаточно мелкие части, присваивает

им последовательные номера и пересылает их. Взаимодействие на уровне заго-

ловка транспортного уровня сводится к обсуждению того, какой пакет был по-

слан, какой

—

принят, сколько места есть у адресата для приема дальнейших со-

общений, что следует послать повторно и тому подобным вопросам.

Надежное транспортное соединение (которое по определению представляет

собой связь с установкой соединения) можно построить поверх сетевых служб

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

доставлены в правильной последовательности (если они посылаются одновре-

менно), а в последнем возможно, что один из пакетов пойдет по другому мар-

шруту и придет раньше, чем пакет, посланный до него. Это побуждает программное

обеспечение транспортного уровня складывать пакеты в правильной последова-

тельности, чтобы поддержать представление о транспортном соединении как

о большой трубе

—

вы кладете в него сообщения на одном конце, и они добира-

ются до другого неповрежденными, в том же порядке, в котором и отправлялись.

Транспортный протокол для Р1нтернета называется протоколом управления

передачей {Transmission Control

Protocol,

TCP). Он детально разобран в книге

[109].

Комбинация TCP/IP в настоящее время является стандартом де-факто при сете-

вых взаимодействиях. Комплект протоколов Интернета также включает в себя

не требующий соединения транспортный протокол под названием UDP {Univer-

sal Datagram Protocol

—

универсальный протокол датаграмм), который, по сути,

представляет собой IP с некоторыми небольшими дополнениями. Пользователь-

ские программы, не нуждающиеся в протоколе с соединениями, обычно исполь-

зуют UDP.

Официальный транспортный протокол ISO имеет пять разновидностей

—

от

ТРО до ТР4. Различия относятся к обработке ошибок и к возможности работать

с несколькими транспортными соединениями на базе одного соединения низко-

го уровня (особенно Х.25). Выбор того, какой из них использовать, завр1сит от

свойств лежащего ниже сетевого уровня. Никогда ни один из них не должен пе-

регружаться.

Время от времени предлагаются дополнительные транспортные протоколы.

Так, например, для поддержки передачи данных в реальном времени был опре-

делен транспортный протокол реального времени {Real-time Transport Protocol,

RTP).

RTP — это кадровый протокол, который определяет формат пакета для

2.1.

Уровни протоколов 89

данных реального времени, ничего не говоря о механизмах гарантированной дос-

тавки этих данных. Кроме того, в нем определен протокол для мониторинга

и управления передачей RTP-пакетов

[406].

TCP в архитектуре клиент-сервер

Взаимодействие клиент-сервер в распределенных системах часто осуществляется

путем использования транспортного протокола базовой сети. С ростом популяр-

ности Интернета нередко можно наблюдать построение приложений клиент-сер-

вер и систем на базе TCP. Преимущества протокола TCP по сравнению с UDP

состоят в том, что он надежно работает в любой сети. Очеврщная оборотная сто-

рона

—

протокол TCP создает значительную дополнительную нагрузку на сеть,

особегпю в тех случаях, когда базовая сеть высоконадежна, например, в локаль-

ных сетях.

Когда на карту поставлены производительность и надежность, альтернативой

всегда является протокол UDP в сочетании с дополнительными процедурами

контроля ошибок и потоков, оптимизированными для конкретного приложения.

Оборотная сторона этого подхода состоит в том, что приходится проделывать

массу дополнительной работы, а также в том, что полученное решение будет ча-

стным, снижающим открытость системы.

Протокол TCP во многих случаях непривлекателен из-за невозможности при-

способить его для поддержки синхронного поведения запрос-ответ, используемого

во многих взаимодействиях клиент-сервер. На рис. 2.4, а показано применение

протокола TCP для поддержки взаимодействия клиент-сервер в нормальных ус-

ловиях (когда сообщения не пропадают). Сначала клиент инициирует установ-

ление соединения, которое происходит по трехэтапному протоколу установле-

ния связи (первые три сообщения на рисунке). Этот протокол необходим для

достижения договоренности о порядке нумерации пакетов, пересылаемых через

соединение (детали можно найти в [446]). Когда соединение установлено, кли-

ент посылает свой запрос (сообщение 4), сопровождаемый пакетом, требующим

от сервера разорвать соединение (сообщение 5).

Сервер отвечает немедленным подтверждением приема запроса от клиента,

которое скомпоновано с подтверждеиР1ем разрыва соединения (сообщение 6).

Затем сервер выполняет требуемую работу и посылает клиенту ответ (сообще-

ние 7), также сопровождаемый требованием разорвать соединение (сообщение 8).

Клиент должен только послать подтверждение разрыва связи на сервер (сообще-

ние 9).

Ясно,

что большая часть дополнительной нагрузки на сеть связана с управле-

нием соединением. При использовании TCP для управления взаимодействием

клиент-сервер гораздо дешевле будет скомбинировать установление соединения

с немедленной посылкой запроса, а посылку ответа — с разрывом соедиР1ения.

Получившийся протокол носит название TCP для транзакций {TCP for Tran-

sactions),

сокращаемое до

Т/ТСР.

То, как функционирует этот протокол в нор-

мальных условиях, можно увидеть на рис. 2.4, б.

В нормальной обстановке происходит следующее: клиент посылает одно со-

общение (сообщение 1), содержащее три порции информации: запрос на уста-

Глава

Связь

новленрге соединения, собственно запрос

серверу

запрос, сообщающий серве-

ру,

что

после этого

он

может немедленно разорвать соединение.

Клиент

Время

SYN

.SYN,ACK(SYN)

••ACK(SYN)

^запрос

"FIN

Сервер

Время

Сервер

SYN.aanpoc.FIN

SYN.ACK(FIN).OTBeT,FlN

ACK(FIN)

Рис.

2.4.

Нормальное функционирование протокола TCP

(а).

Функционирование протокола TCP для транзакций

(б)

Сервер отвечает только после того,

как

обработает запрос.

Он

может послать

данные,

для

передачи которых

создавалось соединение,

немедленно потребо-

вать

его

разрыва,

что

иллюстрирует сообще1П1е

После этого клиенту остается

только подтвердить разрыв соединения (сообщение

3).

Протокол Т/ТСР, созданный

как

расширение

TCP,

автоматически преобра-

зуется

нормальный протокол

TCP,

если другая сторона

не

поддерживает

это

расширение. Дополнительную информацию

по

TCP/IP можно найти

[437].

2.1.3. Протоколы верхнего уровня

Поверх транспортного уровня

OSI

указывает

на

наличие трех дополнительных

уровней.

На

практике используется только прикладной уровень. На самом деле

комплекте протоколов Интернета все,

что

находится выше транспортного уров-

ня,

собирается

одну «кучу».

этом пункте

мы

увидим, почему

точки зрения

систем промежуточного уровня нас не устраивает

ни

подход OSI,

ни

подход

Ин-

тернета.

Сеансовые протоколы

протоколы представления

Сеансовый уровень представляет собой фактически расширенную версию транс-

портного уровня.

Он

обеспечивает управление диалогом, отслеживая

запоми-

ная,

какая сторона говорит

настоящий момент,

предоставляет средства

сип-