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

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

Ранее мы давали определение сетевой архитектуры как “совокупности аппаратных стандартов и протоколов, используемых в конкретной сети”. Одной из характеристик сетевой архитектуры является четкое деление по “уровням” – каждый уровень отвечает за соблюдение каких-либо условий или выполняет определенное задание. Все уровни архитектуры взаимосвязаны, а протоколы определяют методы сообщения между уровнями. Деление протоколов, необходимых для создания сетевых архитектур, на уровни имеет фундаментальное значение для создания стандартных сетей. Все стандартные сети базируются на уровнях протоколов, которые являются основами архитектур. Протокол – система правил для формирования отправляемых сообщений и расшифровки получаемых сообщений. В настоящее время существует большое число протоколов для работы различных сетей. В сети Интернет базовым набором протоколов является так называемый стек протоколов TCP/IP.

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

Сложившаяся ситуация позволяет сделать вывод, что, скорее всего, у каждой компании – производителя аппаратуры – была своя концепция сети, воплощенная в совершенно несовместимых сетевых и коммуникационных стандартах.

Для того чтобы хоть как-то справиться с этим “Вавилонским столпотворением”, несколько сотрудничающих организаций и комитетов выработали примерную модель компьютерной сети, известную под названием OSI – Open System Interconnection – взаимосвязь открытых систем.

Модель OSI была введена международной организацией стандартов в 1984 г. Эта модель разносит функции компьютерных коммуникаций по уровням. Как и во всех протоколах, каждый уровень функционирует независимо от выше- и нижележащих. Каждый уровень может общаться с непосредственным соседом, однако он полностью изолирован от прямого обращения к следующим уровням.

Связь между уровнями

В уровневых протоколах уровень является поставщиком сервиса и может состоять из нескольких сервисных функций. Например, один из уровней может обеспечивать сервисные функции по кодовым преобразованиям, таким, как преобразование из международного алфавита №5 (IA5) в/из EBCDIC, TELEX в/из ASCII, Videotex в/из EBCDIC и календарных дат в числовую форму и обратно. Функция – это некоторая подсистема уровня (некоторая реальная подпрограмма в какой-то программе, например). Каждая подсистема может, кроме того, состоять из логических объектов. Объект – это некоторый специализированный модуль.

Основная идея заключается в том, что уровень “добавляет стоимость” к услугам, обеспечиваемым нижележащими уровнями. Следовательно, верхний уровень, который взаимодействует непосредственно с приложением конечного пользователя, обеспечен полным набором услуг, предлагаемых всеми нижними уровнями.

На рис. 3.1 показана стандартная технология взаимодействия с уровнем или поставщиком сервиса. Посредством точек доступа к сервису (SAP) осуществляется вызов в уровень или из уровня четырех транзакций, называемых примитивами. (Некоторые сеансы не требуют всех транзакций.)

Запрос. Примитив, используемый пользователем сервиса для вызова некоторой функции.
Индикация. Примитив, используемый поставщиком сервиса для: а) вызова функции; б) уведомления о том, что функция была вызвана в некоторой точке доступа к сервису (SAP).
Ответ. Примитив, используемый пользователем сервиса для завершения функции, ранее вызванной индикацией в этой SAP.
Подтверждение. Примитив, используемый поставщиком сервиса для завершения функции, ранее вызванной запросом в этой SAP.

Примитивы обычно имеют дополнительные параметры для передачи информации в уровень или из уровня.

Приложение пользователя или терминал вызывают функцию поставщика сервиса путем посылки запроса в смежный нижний уровень. Этот запрос на услугу подтверждается поставщиком сервиса путем возвращения подтверждения. Если услуга должна предоставить другому пользователю функцию (в данном случае пользователю В), поставщик услуг должен направить В в индикацию, после чего от В ожидается ответ. Полагая, что поставщиком сервиса является некоторый уровень, он осуществляет связь пользователей А и В посредством уровневых точек доступа к сервису SAP. А и В должны знать соответствующую точку SAP, чтобы получить некоторую услугу от поставщика сервиса. SAP содержит адрес конкретной сервисной функции.

На рис. 3.2 дано другое представление этого процесса. Поставщик сервиса находится в середине диаграммы, а пользователи А и В – с левой и правой стороны соответственно. Запрос направляется поставщику сервиса, который предоставляет индикацию пользователю В. Пользователь В выдает ответ, который передается через поставщика сервиса пользователю А как подтверждение.

В этом процессе представлен общий метод, дающий возможность уровням “разговаривать” друг с другом, даже если уровни реализованы с использованием систем различных фирм. Напомним, что поставщиком сервиса может быть уровень, функция или логический объект внутри уровня, а процесс – это просто установление общих средств обмена данными между уровнями.

На рис. 3.3 представлена стандартная терминология, используемая уровневыми сетями при запросе услуг. В процесс связи вовлечены три уровня: уровни N+1, N и N–1. Алфавитно-числовое обозначение уровней является относительным. Центральную роль играет уровень N. Следовательно, уровень, находящийся над ним, обозначен N+1, а уровень под ним – N–1. Следует выделить пять компонент во взаимодействующих уровнях. Их функциями являются:

– SDU (сервисный блок данных). Это данные пользователя, передаваемые в прозрачном режиме уровнем N+1 в уровень N и далее в N–1;

– PCI (управляющая информация протокола). Информация, которой обмениваются одноуровневые объекты в различных узлах сети, чтобы сообщить некоторому объекту о необходимости выполнения сервисной функции;

– PDU (протокольный блок данных). Комбинация SDU и PCI;

– ICI (управляющая информация интерфейса). Временной параметр, передаваемый между N и N–1 для вызова сервисных функций между двумя уровнями;

– IDU (интерфейсный блок данных). Полный блок информации, передаваемой через границы уровней, включает PCI, SDU и ICI. IDU передается через точку доступа к сервису (SAP).

Когда блок IDU из уровня N+1 передается в уровень N, он становится для этого уровня блоком SDU. В свою очередь ICI выделяется в уровне, выполняет свои функции и отбрасывается. К SDU на уровне N добавляется PCI, а также еще ICI, что в совокупности образует IDU для уровня N–1. Таким образом, через каждый уровень передается полный протокольный блок. К SDU добавляется PCI на каждом уровне. Фактически – это добавление на каждом уровне заголовка. Заголовок используется объектом того же уровня в другом узле сети для вызова некоторой функции. Этот процесс повторяется на каждом уровне.

Практическая иллюстрация

По мере того как блок передается через уровни, к нему добавляется заголовок (рис. 3.4). Для последующих нижележащих уровней он становится информацией пользователя. Наконец, полный блок данных протокола передается в канал связи, откуда он берется принимающим узлом и совершает прохождение уровней в обратном порядке по отношению к тому порядку, который имел место в передающем узле. Заголовки, добавленные на соответствующих уровнях в передающем узле, используется для вызова симметричных и взаимно дополняющих функций в принимающем узле (например, вместо кодирования данных, которое было выполнено в передающем узле, в принимающем узле выполняется декодирование). После того как функции выполнены, блок передается на следующий уровень. Заголовок, который был добавлен некоторым объектом в передающем узле, изымается одноуровневым объектом в принимающем узле.

Заголовок играет инструментальную роль в вызове функций для уровня того же ранга. Давайте взглянем опять на эти понятия с практической точки зрения и посмотрим, что могут представлять собой некоторые из этих функций.

Уточнённым вариантом рис. 3.4 является рис. 3.5.

Здесь в заголовки помещаются команды для вызова функций в одноуровневых объектах, находящихся в другом узле сети. Рассматриваются три уровня. Уровни будут вызывать один сервисный объект в каждом уровне. Уровень N+1 вызывает сервисный объект для формирования в передающем узле поля контрольной последо-

Предыдущий узел Уровни Принимающий узел

N+1

N-1

Рис. 3.4. Обмен данными между двумя узлами сети: Н–заголовок; DAT – данные

вательности. Уровень N+1 принимающего узла производит проверку наличия ошибок при передаче на основе сравнения контрольного поля со значением счетчика приема. Сервисный объект на уровне N добавляет поле контрольной последовательности в виде заголовка, который будет использоваться в принимающем уровне N , без ошибок.

Наконец, объект в N–1 уровне производит сжатие данных. В принимающем узле этот заголовок будет использован как команда уровню N–1 преобразовать данные к исходному виду. (Хотя конкретная функция могла быть выполнена без использования заголовков.)

Уровни модели OSI

В настоящее время общепринятой является семиуровневая модель архитектуры открытых систем (Open System Interconnection). В этой модели рассматриваются (рис. 3.6):

• уровень 1 – физический уровень (управление физическим каналом);

• уровень 2 – канальный уровень (управление информационным каналом);

• уровень 3 – сетевой уровень (управление сетью);

• уровень 4 – транспортный уровень (управление передачей);

• уровень 5 – сеансовый уровень (управление сеансом);

•уровень 6 – представительный уровень (управление представлением);

• уровень 7 – прикладной уровень (управление сервисом);

Какие же задачи решаются на различных уровнях протоколов открытых систем? Рассмотрим этот вопрос несколько подробнее.

7 – прикладной уровень (уровень приложения), предоставляет конечным пользователям возможность пользоваться сетью. На этом уровне производятся высокоуровневые действия, управляемые компонентами локальной операционной системы. В отличие от остальных уровней модели OSI этот уровень напрямую доступен конечным пользователям. В его функции входит передача данных, обработка сообщений, управление структурой каталогов, удаленное выполнение программ и эмуляция терминала. Прикладной уровень обеспечивает доступ конкретным прикладным службам к сетевым услугам. Существует огромное число протоколов прикладного уровня, например протоколы для работы с электронной почтой POP3, IMAP, SMTP, протоколы маршрутизации RIP, OSPF, протокол сетевого управления SNMP и др.

В модели OSI прикладная программа, которой нужно выполнить конкретную задачу (например, обновить базу данных на компьютере В), посылает конкретные данные в виде дейтаграммы на прикладной уровень. Одна из основных “обязанностей” этого уровня — определить, как следует обрабатывать запрос прикладной программы, иными словами — какой вид должен принять данный запрос. Если в запросе прикладной программы определен, например, дистанционный ввод заданий, то это потребует работы нескольких программ, которые будут собирать информацию, организовывать ее, обрабатывать и посылать по соответствующему адресу.

Виды сервиса прикладного уровня. Прикладной уровень содержит несколько так называемых общих элементов прикладного сервиса ACSE — Application Common Service Elements и специальных элементов прикладного сервиса (SASE — Specific Application Service Elements). Общие элементы прикладного сepвиса ACSE предоставляются прикладным процессам во всех системах. Они включают, например, требование определенных параметров качества сервиса.

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

Специальные элементы прикладного сервиса (SASE) обеспечивают сервис для конкретных прикладных программ, таких как программы пересылки файлов и эмуляции терминалов. Если, например, прикладной программе необходимо переслать файлы, то обязательно будет использован протокол передачи, доступа и управления файлами (FTAM — File Transfer, Access and Management), являющийся одним из ключевых протоколов прикладного уровня.

Важная составляющая SASE прикладного уровня – сервис виртуального терминала (VT – Virtual Terminal). VT – это сложный сервис, который освобождает компьютер от необходимости посылать соответствующие сигналы для обращения ко всем терминалам, подключённым ко второму компьютеру. Первый компьютер может использовать набор параметров виртуального терминала, а решение вопросов конкретизации конфигурации терминалов можно предоставить второму компьютеру.

Функции управления сетями на прикладном уровне. Помере усложнения информационных сетей вопрос административного управления ими приобретает все большее значение. Поскольку сейчас любые системы передачи информации позволяют обрабатывать и передавать также и речевые данные, а локальные сети все теснее связываются с глобальными сетями и мэйнфреймами, то все очевиднее необходимость в разработке эффективного метода организации этой информации и управления ею. Фирма IBM в качестве решения предложила свои системы NetViewH NetView/PC, a Hewlett-Packard вышла на рынок с пакетом прикладных программ OpenView.

На сегодняшний день проблема заключается в том, что при наличии нескольких решений нет международного стандарта по управлению сетями. Для прикладного уровня модели OSI существует несколько спецификаций информационно-управляющих протоколов, которые претендуют на то, чтобы в будущем стать международными стандартами.

6 – Представительный уровень – уровень представления определяет форму, которую принимают данные при обмене между рабочими станциями. На компьютере-отправителе программное обеспечение этого уровня конвертирует данные из формата уровня приложений в промежуточный формат, распознанный остальными уровнями. На компьютере-получателе этот уровень совершает обратные преобразования данных.

Уровень представления также управляет средствами защиты сети от несанкционированного доступа, предоставляя такие услуги, как кодирование. Кроме того, этот уровень устанавливает правила передачи данных и занимается сжатием передаваемой информации для повышения пропускной способности сети. К представительному уровню чаще всего относят криптопротоколы, предназначенные для шифрования информации. Примерами криптопротоколов в стеке TCP/IP являются Secure Sockets Layer (SSL), Transport Layer Security (TLS) и Private Communication Technology (PCT). Наибольшее распространение получил криптопротокол SSL, который был разработан компанией Netscape и в настоящее время поддерживается всеми современными Web-браузерами.

Уровень представления данных отвечает за физическое отображение (представление) информации. Так, в полях базы данных информация должна быть представлена в виде букв и цифр, а зачастую — и графических изображений. Обрабатывать же эти данные нужно, например, как числа с плавающей запятой.

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

Важность уровня представления данных заключается в том, что в основу его работы положена единая для всех уровней модели OSI система обозначений для описания абстрактного синтаксиса — ASN.1. Эта система служит для описания структуры файлов. На прикладном уровне система ASN.1 применяется и для выполнения всех операций пересылки файлов, и при работе с виртуальным терминалом. Использование этой системы позволяет также решить одну из важнейших проблем, возникающих при управлении крупными сетями, — шифрование данных. Шифрование данных с помощью ASN.1 можно выполнять на уровне представления данных; разработка стандарта OSI для этого уровня окажет значительное влияние на обеспечение межмашинной связи.

5 – Сеансовый уровень выполняет функции посредника между верхними уровнями и нижними уровнями, ориентированными на коммуникации в реальном уровне. Сеансовый уровень представляет возможности для управления и контроля данных во множестве одновременных соединений, контролируя диалог связанных по сети приложений. Этот уровень обеспечивает возможности запуска, приостановки, инициализации или перезапуска сети.

Сеансовый уровень позволяет двум субъектам соединения устанавливать, использовать и завершать сеанс связи. Сеансовый уровень не представлен ни одним протоколом из стека TCP/IP.

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

Сеансовый уровень отвечает за такие серьезные вопросы, как режим передачи и установка точек синхронизации. Иными словами, на этом уровне определяется, какой будет передача между двумя прикладными процессами: полудуплексной (процессы будут передавать и принимать данные по очереди) или дуплексной (процессы будут передавать и принимать данные одновременно). В полудуплексном режиме сеансовый уровень выдает маркер данных тому процессу, который первым начинает передачу. Когда второму процессу приходит время отвечать, маркер данных передается ему. Сеансовый уровень, таким образом, разрешает передачу только той стороне, которая обладает маркером данных.

Синхронизирующие точки представляют собой точки внутри “диалога”, в которых сеансовый уровень проверяет наличие фактического обмена.

Еще одна функция сеансового уровня модели OSI заключается в решении вопроса о восстановлении связи в случае ее нарушения. Например, логично было бы ставить точки синхронизации между страницами текста и в случае нарушения связи начинать передачу с последней синхронизирующей точки. Таким образом, для восстановления сеанса не нужно будет начинать все сначала и повторять передачу текста, который уже принят правильно.

Сеансовый уровень, кроме того, отвечает за детали, связанные с упорядоченным (“плавным”) завершением соединения в конце сеанса. Могут возникнуть и ситуации, когда требуется безусловное (“резкое”) завершение. Это необходимо в тех случаях, когда одна из сторон прекращает обмен и отказывается с этого момента принимать данные.

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

4 – Транспортный уровень отвечает за надежность обработки данных вне зависимости от нижележащих уровней. Этот уровень управляет потоком данных в сети и контролем соединения между конечными адресами. Стандартные протоколы этого уровня: Transport Class0, Class1 и Class4, относящиеся к модели OSI, TCP и SPX.

В задачу транспортного уровня входит обеспечение передачи данных вышележащим уровням модели OSI с той степенью надежности, которая им требуется. На транспортном уровне функционируют два протокола стека TCP/IP: UDP (User Datagram Protocol) и TCP (Transmission Control Protocol). Рассмотрим более подробно работу каждого из этих протоколов.

TCP-протокол является более надежным средством передачи информации по сравнению с протоколом UDP, поскольку перед передачей ТСР-сегментов здесь устанавливается специальное логическое соединение — виртуальный канал, который ликвидируется сразу после завершения передачи данных. При использовании виртуального канала не нарушается последовательность передачи пакетов данных. Виртуальный канал может динамически перенаправляться и физически изменяться в ходе одного сеанса передачи данных (табл. 3.1).

Для идентификации ТСР-сегмента используют два 4-байтовых числа, которые играют также роль счетчика пакетов — порядковый номер (Sequence Number) и номер подтверждения (Acknowledgment Number). Во время установления соединения хосты могут обмениваться командами, номера которых указываются в 6-разрядном поле флагов () и задаются установкой в единицу соответствующих битов этого поля. Это полеможет содержать следующие команды (табл. 3.2).

Таблица 3.1

Формат TCP-сегмента

Рассмотрим пример процедуры создания TCP-соединения. Предположим, что хосту А необходимо установить соединение с хостом В. Тогда процедура будет следующей.

1. Хост A—— SYN, ISNa —— Хост В.

Это означает, что в сообщении, передаваемом хостом А, в поле (Control bits) установлен бит SYN, а в поле, содержащем порядковый номер, установлено значение ISNa.

2. Хост A——— SYN, ACK, ISNb, ISNa +1——— Хост В.

В качестве ответа на полученный запрос хост В посылает сообщение, в котором устанавливает биты SYN и ACK, а в поле порядкового номера хост В устанавливает свое начальное значение ISNb.

3. Хост А —— ACK, ISNb + 1, ISNa + 1——- Хост В.

Завершая трехступенчатое установление виртуального канала связи, хост А отсылает ответ хосту В, в котором установлен бит АСК, полесодержит значение ISNa + 1, а полесодержит ISNb + 1. Теперь хост А может начать передачу данных, используя для этого только что созданный виртуальный канал.

1. Хост А — АСК, ISNb + 1, ISNa + 1, Данные —— — Хост В.

В рамках соединения правильность передачи каждого сегмента должна подтверждаться квитанцией получателя. Квитирование — это один из традиционных методов обеспечения надежной связи, идея которого состоит в следующем. Для того чтобы имелась возможность организации повторной передачи искаженных по каким-либо причинам данных, отправитель нумерует отправляемые единицы информации. Для каждого сегмента он ожидает от приемника так называемую положительную квитанцию или служебное сообщение, извещающее о том, что исходный сегмент действительно был получен и данные в нем оказались корректными. Это же сообщение должно содержать порядковый номер следующего сегмента (ISN + 1), который необходимо послать получателю. Время ожидания получения подтверждающего пакета ограничено — при отправке каждого ТСР-сегмента передатчик запускает таймер. Если по истечении заданного времени положительная квитанция не получена, кадр считается утерянным. При передаче каждого нового пакета старый таймер сбрасывается и запускается новый. Пакеты, подтверждающие прием информации, являются кумулятивными, т. е. пакет, в котором установлен бит АСК и который содержит последовательный номер (ISN)n, автоматически подтверждает прием пакетов с последовательными номерами вплоть до n – 1. Если передаваемый пакет был утерян, то получатель будет продолжать передавать пакеты с установленным битом АСК и последовательным номером утерянного пакета.

Для того чтобы ускорить процесс передачи информации, TCP-протоколом назначается так называемое окно, содержащее число ТСР-сегментов, которое может быть отправлено без получения подтверждения (квитанции). Одно из последних расширений TCP-протокола — TCP Selective Acknowledgement (TCP-протокол с выборочным подтверждением) — позволяет, как следует из его названия, подтверждать корректный прием данных не в порядке их поступления, а выборочно. Реализация этого расширения существенно повышает быстродействие работы TCP-протокола, поскольку позволяет более адекватно оценить реальные размеры окна передачи данных и, следовательно, установить оптимальную скорость передачи информации. Существуют несколько версий TCP-протоколов, в которых реализованы различные алгоритмы регулировки размера окна: TCP-OldTahoc, TCP-Tahoe, TCP-Reno, TCP-PseudoRate.

Протокол UDP, в отличие от транспортного протокола TCP, не предусматривает предварительного установления логического канала связи. Из-за отсутствия встроенных механизмов контроля целостности данных этот протокол является менее надежным в сравнении с TCP-протоколом, однако обладает более высокой производительностью. UDP-дейтаграммы могут быть отправлены источником информации по разным маршрутам и поступать получателю данных в разное время. Обязанности по контролю за порядком прибытия дейтаграмм протокол возлагает на вышележащие уровни. Формат UDP-дейтаграммы изображен ниже:

Протокол UDP весьма эффективен при организации IP-телефонии или видеоконференций в реальном масштабе времени. В настоящее время он используется следующими службами сети Интернет: доменной службой имен DNS (Domain Name System), протоколом маршрутизации RIP (Routing Information Protocol), протоколом передачи контрольной информации IСМР (Internet Control Message Protocol), протоколом передачи файлов TFTP (Trivial File Transmission Protocol) и простым протоколом сетевого управления SNMP (Simple Network Management Protocol). Процент пакетов, передаваемых в сети Интернет с использованием транспортного протокола UDP, составляет приблизительно 2 % общего графика сети.

Классы и типы сервисов транспортного протокола. Транспортный уровень имеет большое значение для пользователей компьютерных сетей, поскольку именно он определяет качество сервиса, которое необходимо обеспечить посредством сетевого уровня. Для того чтобы лучше понять функции транспортного уровня, представим его как аналогию набора специальных услуг, которые местное почтовое отделение предоставляет клиентам за дополнительную плату. Например, заплатив некоторую сумму, клиент может получить квитанцию о том, что письмо доставлено по указанному им адресу. Можно заказать срочную доставку, если клиент желает, чтобы его посылка пришла, к примеру, в Бостон на следующий день. Плату за эти дополнительные высококачественно услуги почтовое ведомство США взимает с клиентов деньгами, а для пользователя сети, работающего с OSI-совместимыми аппаратными и программными средствами, эта плата выражается в дополнительных битах, необходимых для предоставления информации о статусе возможных дополнительных услуг.

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

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

Транспортный уровень, тем не менее, предоставляет программистам возможность писать программы для прикладного уровня в самых различных сетях, не обращая внимания на то, надежна ли передача по этим сетям или нет. Некоторые называют три верхних уровня модели OSI “пользователями транспортного уровня”, а четыре нижних — “поставщиками транспортного уровня”.

Существует пять классов сервиса транспортного протокола (табл. 3.3).

Класс 0, известный как телекс, представляет собой сервис с самым низким качеством. В этом классе сервиса предусматривается, что управление потоком данных осуществляет сетевой уровень (под транспортным уровнем). Транспортный уровень разрывает соединение, когда аналогичную операцию выполняет сетевой уровень.

Класс 1 был разработан для сети с коммутацией пакетов. Он обеспечивает передачу срочных данных, однако управление потоком все равно осуществляется на сетевом уровне.

Класс 2 — это модифицированный класс 0. Уровень сервиса этого класса базируется на предположении о том, что сеть обладает высокой надежностью. Предлагаемое качество сервиса предусматривает возможность мультиплексирования множества транспортных соединений из одного сетевого соединения. Класс 2 обеспечивает необходимую сборку мультиплексированных пакетов данных, прибывающих неупорядоченными.

Класс 3 обеспечивает виды сервиса, предлагаемыеуровнями 1 и 2, а в случае обнаружения ошибки предоставляет возможность ресинхронизации для переустановления соединения.

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

Статьи к прочтению:

Уровневые Поилки

Похожие статьи: