Уровневые протоколы и модель взаимодействия открытых систем 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

 

 

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 (Trans­mission Control Protocol). Рассмотрим более подробно ра­боту каждого из этих протоколов.

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

Для идентификации ТСР-сегмента используют два 4-байтовых числа, которые играют также роль счетчика пакетов — порядковый номер (Sequence Number) и номер подтверждения (Acknowledgment Number). Во время уста­новления соединения хосты могут обмениваться коман­дами, номера которых указываются в 6-разрядном поле флагов (<Control bits>) и задаются установкой в единицу соответствующих битов этого поля. Это полеможет со­держать следующие команды (табл. 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, а в случае обнаружения ошибки предос­тавляет возможность ресинхронизации для переустанов­ления соединения.