Протокол связи

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

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

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

Несколько протоколов часто описывают разные аспекты одной связи. Группа протоколов, предназначенных для совместной работы, известна как набор протоколов; при реализации в программном бюллетене они отличаются собой стек протоколов ..

Протоколы связи в Интернете публикуются Инженерной группой Интернета (IETF). IEEE (Институт инженеров по электротехнике и электронике) обрабатывает проводные и беспроводные сети, а Международная организация по стандартизации (ISO) обрабатывает другие типы. ITU-T обрабатывает телекоммуникационные протоколы и форматы для коммутируемой телефонной сети общего пользования (PSTN). По мере того как ТСОП и Интернет сходятся, стандарты также стремятся к конвергенции.

Содержание
  • 1 Коммуникационные системы
    • 1.1 История
    • 1.2 Концепция
  • 2 Основные требования
  • 3 Дизайн протокола
    • 3.1 Уровни
      • 3.1.1 Уровни протоколов
      • 3.1. 2 Уровни программного обеспечения
      • 3.1.3 Строгие уровни
    • 3.2 Шаблоны проектирования для протоколов прикладного уровня
    • 3.3 Формальная спецификация
  • 4 Разработка протокола
    • 4.1 Потребность в стандартах протоколов
    • 4.2 Организации по стандартизации
    • 4.3 Процесс стандартизации
    • 4.4 Стандартизация OSI
  • 5 Таксономии
  • 6 См. Также
  • 7 Примечания
  • 8 Ссылки
    • 8.1 Библиография
  • 9 Дополнительная литература
  • 10ние ссылки
Коммуникационные системы

История

Одно из первых применений термина «протокол» в контексте коммутации данных в меморандуме «Протокол для использования в сети передачи данных NPL. написано Роджером Скантлбери и Китом Бартлеттом в апреле 1967 года.

На ARPANET отправной точки связи хост-хост в 1969 г. 1822 г., определяющий протокол передачи сообщений IMP. Программа управления сетью для ARPANET была впервые реализована в 1970 году. Интерфейс NCP позволяет прикладному программному обеспечению подключаться через ARPANET, реализовать протоколы связи более высокого уровня , ранний пример концепции многоуровневого протокола.

Исследования сетей в начале 1970-х, проведенные Робертом Э. Каном и Винтом Серфом, привести к формулировке Программа управления коробкой передач (TCP). Его спецификация RFC 675 была написана Серфом с Йогеном Далалом и Карлом Саншайном в декабре 1974 года, в то время все еще представляет собой монолитную конструкцию.

Международная рабочая группа по сетям согласовала стандарт дейтаграммы без объединения соединений, который был представлен в CCIT в 1975 году, но не был принят МСЭ или через ARPANET. Международные исследования, в частности, работа Реми Деспре, способствовали разработке стандарта X.25, основанного на виртуальных цепях, ITU-T в 1976 году. Производители компьютеров разработали проприетарные протоколы, такие как IBM Systems Network Architecture (SNA), DECnet и Xerox Network от Digital Equipment Corporation. Системы.

Программное обеспечение TCP было переработано в модульный стек протоколов. Первоначально называвшийся IP / TCP, он был установлен в SATNET в 1982 году и в ARPANET в январе 1983 года. Разработка полного набора протоколов к 1989 году, как в RFC 1122 и RFC 1123, заложили основу для TCP / IP как всеобъемлющего набора протоколов, как основная развивающаяся Интернет.

Международная работа над эталонной моделью для стандартов связи привел к модели OSI, опубликованной в 1984 году. В течение периода в конце 1980-х и начале 1990-х инженеры, организации и страны разошлись по вопросу о том, какой стандарт, модель OSI или набор Интернет-протоколов приведет к созданию лучших и наиболее надежных компьютерных сетей.

Концепция

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

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

для реализации сетевого протокола программных модулей протокола взаимодействия со структурой, реализованной в операционной системе машины. Эта структура реализует сетевые функции операционной системы. Когда алгоритмы выражаются на переносимом языке программирования, программное обеспечение может быть сделано операционной системой протокола независимым протоколом. Самыми известными фреймворками являются модель TCP / IP и модель OSI.

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

Системы обычно не используют один протокол для обработки передачи. Вместо этого они используют набор используемых протоколов, иногда называемый набором протоколов. Некоторые из наиболее известных наборов протоколов: TCP / IP, IPX / SPX, X.25, AX.25 и <78.>AppleTalk.

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

Основные требования

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

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

Форматы данных для обмена данными
Обмен битовыми строками цифровых сообщений. Строки битов разделены на поля, и несет поле информацию, относящуюся к протоколу. Концептуально цепочка битов делится на части, называемые заголовком и полезной нагрузкой. Фактическое сообщение переносится в полезной нагрузке. Область заголовка содержит поля, относящиеся к работе протокола. Строки битов длиннее максимальной единицы передачи (MTU) делятся на части соответствующего размера.
Форматы адресов для обмена данными
Адреса используются для обозначения как отправителя, так и предполагаемый получатель (и). Адреса переносятся в области заголовка цепочек битов, позволяя получать данные, получать ли цепочки битов интерес и должны ли их обрабатываться, или их следует игнорировать. Соединение между отправителем и получателем можно определить с помощью пары (адрес отправителя, адрес получателя). Обычно некоторые значения адресов имеют особое значение. Адрес all-1s может означать адресацию всех станций в сети, поэтому отправка на этот адрес приведет к широковещательной рассылке в локальной сети. Правила, описывающие значения значения адреса, в совокупности называются схемой адресации.
Отображение адресов
Иногда протоколам необходимо сопоставить адреса одной схемы с адресами другими схемами. Например, для преобразования логического IP-адреса, приложения, в MAC-Ethernet. Это называется нанесением адресов.
Маршрутизация
Когда системы не подключены напрямую, промежуточным системам на пути к предполагаемому получателю (ям) необходимо пересылать сообщения от имени отправителя. В Интернете сети соединяются с помощью маршрутизаторов. Взаимосвязь сетей через маршрутизаторы называется Межсетевым взаимодействием.
Обнаружение ошибок передачи
Обнаружение ошибок в сети, где возможно повреждение данных. В обычном подходе CRC области данных добавляется в конец пакетов, что позволяет обнаруживать различия, вызванные повреждением. Получатель отклоняет пакеты из-за разницы CRC и каким-то образом организует повторную передачу.
Подтверждения
Подтверждение правильного приема пакетов требуется для связи с установлением соединения. Подтверждения отправляются получателями обратно их отправителям.
Потеря информации - таймауты и повторные попытки
Пакеты могут быть потеряны в сети или задержаны при передаче. Чтобы справиться с этим, в соответствии с некоторыми протоколами отправителя может ожидать подтверждения правильного приема от получателя в течение определенного периода времени. Таким образом, по истечении времени ожидания отправителю может потребоваться повторно передать информацию. В случае постоянно разрыва связи повторная передача не имеет никакого эффекта, поэтому количество повторных передач ограничено. Превышение лимита повторных попыток считается ошибкой.
Направление информационного потока
Необходимо указать направление, если передача может происходить только в одном направлении за раз, как в полудуплексе или от одного отправителя за раз, как на общем носителе . Это известно как управление доступом к среде. Необходимо принять меры для учета случая коллизии или конфликта, когда две стороны соответственно передают или желают передать.
Управление последовательностью
Если цепочки битов разделены на части, а затем отправлены по сети по отдельной, части могут быть потеряны или задержаны, или в некоторых типах сетей, по разным маршрутам к месту назначения. В результате части могут поступать не по порядку. Повторная передача может привести к дублированию частей. Помечая часть с информацией о отправителю, получатель может определить, что было потеряно или дублировано, запросить необходимые повторные передачи и повторно восстановить исходное сообщение.
Управление потоком
Управление потоком необходимо, когда отправитель передает быстрее, чем может обработать получатель или промежуточное сетевое оборудование. Управление потоком может быть реализовано путем обмена сообщениями от получателя к отправителю.
Организация очередей
Коммуникационные процессы или конечные автоматы используют очередь (или «буферы»), обычно очереди FIFO, для обработки сообщений в заказ отправлен, и иногда может иметь несколько очередей с разными приоритетами
Разработка

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

Коммуникационные системы работают одновременно. Важным аспектом параллельного программирования является синхронизация программного обеспечения для приема и передачи сообщений в надлежащей последовательности. Параллельное программирование, традиционное в текстах по операционной тем систем. Формальная проверка кажется необходимой, потому что параллельные программы печально известны скрытыми и сложными ошибками, которые они содержат. Математический подход к изучению параллелизма и связи называется взаимодействующими последовательными процессами (CSP). Параллелизм также можно смоделировать с помощью конечных автоматов, таких как Мили и машин Мура. Машины Мили и Мура используются в качестве инструментов проектирования систем цифрового электроники, встречающихся в видеовыходе, используемых в телекоммуникационных или электронных устройствах в целом.

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

Уровни

Рис. 2. Протоколы в соответствии со схемой многоуровневого Интернета. Рисунок 2. Модель TCP / IP или схема многоуровневого Интернета и ее связь с распространенными протоколами.

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

Протоколы связи, используемые в Интернете, предназначены для работы в разнообразных и сложных условиях. Интернет-протоколы разработаны для простоты и модульности и вписываются в грубую иерархию функциональных уровней, определенные в Internet Protocol Suite. Первые два взаимодействующих протокола, Протокол управления передачей (TCP) и Интернет-протокол (IP), возникший в результате декомпозиции исходной программы управления передачей, монолитного протокола связи, на этот многоуровневый коммуникационный пакет.

Модель OSI предоставлена ​​на международном уровне на основе опыта работы с сетями, предшествовавшими Интернету, в качестве эталонной модели для общей коммуникации с гораздо более строгими взаимодействием протоколов и строгим распределением уровней.

Обычно прикладное программное обеспечение построено на надежном транспортном уровне данных. В основе этого транспортного уровня механизм доставки и маршрутизации дейтаграмм, который обычно без соединения в Интернете. Ретрансляция пакетов по сетям происходит на другом уровне, включает только технологии сетевых соединений, которые часто специфичны для методов физического уровня, таких как Ethernet. При необходимости многоуровневый обмен технологиями предоставляет возможности, например, протоколы часто объединяются в систему восстановления туннелирования для обеспечения соединения разнородных сетей. Например, IP может быть туннелирован через сеть асинхронного режима передачи (банкомат).

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

Рисунок 3. Потоки сообщений с использованием набора протоколов. Рис. 3. Потоки сообщений с использованием набора протоколов. Черные петли показывают фактические петли обмена сообщениями, красные петли - эффективную связь между уровнями, обеспечиваемую нижними уровнями.

Распределение уровней протокола составляет основу конструкции протокола. Он позволяет разложить отдельные сложные протоколы на более простые взаимодействующие протоколы. Каждый уровень протокола решает отдельный класс коммуникационных проблем. Вместе слои составляют схему или модель наслоения.

Вычисления имеют дело с алгоритмами и данными; Коммуникация включает протоколы и сообщения; Таким образом, аналог диаграммы потока данных - это своего рода диаграмма потока сообщений. Для визуализации слоев протоколов и наборов протоколов на рисунке 3 показана схема потоков сообщений в двух системах, A и B, и между ними. В обеих системах A и B используется один и тот же набор протоколов. Вертикальные потоки (и протоколы) являются внутрисистемными, а горизонтальные потоки сообщений (и протоколы) - между системами. Потоки сообщений регулируются правилами, а форматы данных определяются протоколами. Синие линии отмечают границы (горизонтальных) уровней протокола.

Уровни программного обеспечения

Рисунок 5: уровни протоколов и программного обеспечения Рис. 5: Уровни протокола и программного обеспечения. Программные модули, реализующие протоколы, представлены кубами. Информационный поток между модулями представлен стрелками. Красные стрелки (две верхние горизонтальные) виртуальны. Синие линии отмечают границы уровней.

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

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

Трансляция программы разделена на четыре подзадачи: компилятор, ассемблер, редактор ссылок и загрузчик. В результате программное обеспечение для перевода также является многоуровневым, что позволяет разрабатывать уровни программного обеспечения независимо. Отметив, что способы преодоления сложности трансляции программ могут быть легко применены к протоколам из-за аналогии между языками программирования и протоколами, разработчики набора протоколов TCP / IP стремились наложить те же уровни на программную структуру. Это можно увидеть в разбиении на уровни TCP / IP, рассматривая перевод скомпилированной программы (сообщения) на паскале (функция уровня приложения) в программу ассемблера, которая собирается (функциятранспортный уровень) в объектный код (часть), который связан (функция уровня Интернета) вместе с объектомным кодом библиотеки (таблицей маршрутизации), редактором ссылок, создавая перемещаемый машинный код (дейтаграмму), который передается загрузчику, который заполняет ячейки (Ethernet) для создает исполняемый код (сетевой кадр), который должен быть загружен (функция уровня сетевого интерфейса) в физическую память (среду передачи). Чтобы показать, насколько точно подходит эта аналогия, термины в скобках в предыдущем предложении обозначают соответствующие аналоги, обозначенные курсивом, обозначают представления данных. Трансляция программы формирует линейную последовательность, которая выводит каждый слой передается как вводится на следующий уровень. Кроме того, процесс перевода включает в себя несколько представлений данных. То же самое происходит в программном блоке протокола.

Модули ниже уровня приложения обычно рассматриваемой операционной системы. Передача данных между этим модулями намного дешевле. Граница между приложениями и транспортным уровнем называется границей операционной системы.

Строгое разбиение на уровнях

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

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

Шаблоны проектирования для протоколов прикладного уровня

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

Формальная спецификация

Формальные методы описания синтаксиса связи являются Абстрактная нотация синтаксиса 1 (стандарт ISO ) и Расширенный Backus-Naur форма (стандарт IETF ).

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

Разработка протокола

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

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

Потребность в стандартах протоколов

Потребность в стандартах протоколов можно показать, посмотрев, что случилось с протоколом би-синхронизации (BSC), изобретенным IBM. BSC - это ранний протокол канального уровня, используемый для соединения двух отдельных узлов. Первоначально он не предназначался для использования в многоузловой сети, но это выявить некоторые ошибки протокола. В отсутствие стандартизации производители и не стеснялись «улучшать» протокол, создавая несовместимые версии в своих сетях. В некоторых случаях это было сделано намеренно, чтобы отговорить пользователей от использования оборудования других производителей. Существует более 50 вариантов исходного протокола би-синхронизации. Можно предположить, что стандарт предотвратил бы хотя бы часть этого.

В некоторых случаях протоколы завоевывают доминирующее положение на рынке без прохождения процесса стандартизации. Такие называются протоколми де-факто. Стандарты де-факто распространены на безопасных рынках, нишевых рынках или рынках, которые являются монополизированными (или олигополизированными). Они могут удерживать рынок в очень негативном состоянии, когда используются для отпугивания конкуренции. С исторической точки зрения стандартизация должна рассматриваться как мера противодействия отрицательному воздействию стандартов де-факто. Существуют положительные исключения; «Стандартная де-факто» операционная система, такая как GNU / Linux, не имеет такого негативного влияния на своем рынке, потому что исходные тексты публикуются и поддерживаются в открытом виде, что конкуренции. Таким образом, стандартизация - не единственное решение для соединения открытых систем.

Организации по стандартизации

Некоторые из организаций по стандартизации, имеющие отношение к протоколам связи, - это Международная организация по стандартизации (ISO), Международный союз электросвязи (ITU), Институт инженеров по электротехнике и электронике (IEEE) и Инженерная группа Интернета (IETF). IETF поддерживает протоколы, используемый в Интернете. IEEE контролирует многие программные и аппаратные протоколы в электронной промышленности для коммерческих и потребительских устройств. ITU является головной организацией инженеров электросвязи, проектирующими телефонную сеть общего пользования (PSTN), а также многие системы радиосвязи. Для морской электроники используются стандарты NMEA. Консорциум World Wide Web (W3C) производит протоколы и стандарты для веб-технологий.

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

Процесс стандартизации

Процесс стандартизации начинается с того, что ISO вводит в эксплуатацию рабочую группу подкомитета. Рабочая группа выдает рабочие проекты и документы для обсуждения заинтересованным сторонам (включая другие органы по стандартизации), чтобы вызвать обсуждение и комментарии. Это вызовет множество вопросов, как правило, некоторые разногласий по поводу того, что должно быть стандартным и может ли он удовлетворить все потребности (обычно нет). Все противоречивые мнения должны приниматься во внимание, часто в качестве компромисса, для продвижения проекту предложения рабочей группы.

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

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

  • Различные дополнительные режимы работы, например, для достижения достижимого консенсуса по оптимальному размеру пакета.
  • Параметры, которые оставлены неопределенными или разрешено принимать значения определенного набора по усмотрению разработчика. Это часто отражает противоречивые взгляды некоторых участников.
  • Параметры зарезерв для использования в будущем, что могло быть достигнуто за счет того, что могло быть предоставлено, но не удалось достичь согласия, как это должно быть сделано в доступное время.
  • При внедрении неизбежно будут обнаружены различные несоответствия и двусмысленности.

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

Стандартизация OSI

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

В OSI В модели принцип, что коммуникационные системы соединены обычным физическим средой, обеспечивающей базовый (и неуказанный) механизм передачи. Слои над ним пронумерованы (от одного до семи); n-слой называется (n) -уровнем. Каждый уровень предоставляет услуги вышележащему слою (или процессы приложения наверху), используя сервисы уровня, находящегося непосредственно под ним. Уровни связываются друг с другом посредством интерфейса, который называется точкой доступа к услуге. Соответствующие уровни в каждой системе называются одноранговыми объектами. Для связи два одноранговых объекта на данном уровне используют (n) -протокол, который реализуется с помощью сервисов (n-1) -уровня. Когда системы не подключены напрямую, используются промежуточные одноранговые объекты (называемые реле). Адрес однозначно определяет точку доступа к услуге. Домены именования адресов не обязательно должны быть ограничены одним уровнем, поэтому можно использовать только один домен именования для всех уровней. Для каждого уровня определяется уровень: стандарты, определяющие, как одноранговые объекты на данном уровне отвечают, и стандарты обслуживания, определяющие уровень.

В исходной версии RM / OSI уровни и их функциональность (от самого высокого до самого низкого уровня) следующие:

  • Уровни и их функциональность (от самого высокого до самого низкого уровня) следующие:

    • для связи, определение доступности и аутентификации партнеров, соглашение о механизмах конфиденциальности для связи, соглашение об ответственности за устранение ошибок и процедуры для обеспечения целостности данных, синхронизация между взаимодействующими процессами приложений, идентификация любых ограничений синтаксиса (например, наборы символов и структуры данных), определение стоимости и приемлемого качества обслуживания, выбор диалоговой дисциплины, включая необходимые процедуры входа в систему и выхода из системы.
    • Уровень представления может предоставлять следующие услуги прикладному уровню: запрос на установление сеанса, передача данных, согласование синтаксиса tob е используются между уровнями приложения, любые необходимые преобразования синтаксиса, форматирование и преобразования специального назначения (например, сжатие данных и шифрование данных).
    • Сеансовый уровень может предоставлять следующие услуги уровню представления: установление и разъединение сеансовых соединений, нормальный и ускоренный обмен данными, служба карантина, которая позволяет отправляющему объекту представления давать инструкции принимающий объект сеанса не выпускал данные в объект представления без разрешения, управление взаимодействием, чтобы объекты представления могли контролировать, чья очередь выполнять определенные функции управления, повторная синхронизация соединения сеанса, сообщение о неисправимых исключениях объекту представления.
    • Транспортный уровень обеспечивает надежную и прозрачную передачу данных экономичным способом в соответствии с выбранным качеством обслуживания. Он может поддерживать мультиплексирование нескольких транспортных соединений в одно сетевое соединение или разделять одно транспортное соединение на несколько сетевых соединений.
    • Сетевой уровень выполняет настройку, обслуживание и освобождение сетевых путей между транспортными одноранговыми объектами. Когда необходимы реле, этот уровень обеспечивает функции маршрутизации и ретрансляции. Качество обслуживания оговаривается между сетью и транспортными объектами во время установки соединения. Этот уровень также отвечает за контроль перегрузки сети.
    • Уровень канала данных выполняет настройку, обслуживание и освобождение соединений канала данных. Ошибки, возникающие на физическом уровне, обнаруживаются и могут быть исправлены. Об ошибках сообщается на сетевой уровень. Обмен звеньями передачи данных (включая управление потоком) определяется этим уровнем.
    • Физический уровень описывает такие детали, как электрические характеристики физического соединения, используемые методы передачи, а также настройку, обслуживание и очистку физические соединения.

    В отличие от Схема уровней TCP / IP, которая предполагает сеть без установления соединения, RM / OSI предполагает сеть, ориентированное на установление соединения. Сети с установлением больше подходят для глобальных сетей, а сети без соединения больше подходят для локальных сетей. Использование соединений для связи подразумевает некоторую форму сеансовых и (виртуальных) цепей, следовательно (в модели TCP / IP) сеансовый уровень. Составные члены ISO в основном занимались глобальными сетями, поэтому разработка RM / OSI была определена в сетях с установлением соединений, без соединения были упомянуты только в дополнении к RM / OSI. В то время IETF пришлось справиться с этим, а также с тем фактом, что Интернету нужны были протоколы, которых просто не было. В результате IETF разработала собственный процесс стандартизации, основанный на «приблизительном консенсусе и работающем коде».

    Процесс стандартизации в RFC2026.

    В настоящее время превратилась в организацию IETF в по стандартизации для протокола, используемого в Интернете. RM / OSI расширил свою модель, включив в нее соединения, и благодаря этому TCP и IP могут быть преобразованы в международные стандарты.

    Таксономии

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

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

    Схема многоуровневости от IETF называется многоуровневым Интернетом или TCP / IP.

    Схема слоев ISO называется моделью OSI или многоуровневой системой ISO.

    В конфигурации сетевого оборудования часто проводится различие в терминах искусства: термин «протокол» строго относится к транспортному уровню, а термин «служба» относится к протоколам, использующим «протокол» для транспорта.. В общем случае TCP и UDP службы различаются по номерам портов. Соответствие этим номерам портов является добровольным, поэтому в системе присутствует термин «служба» строго к номерам портов, а термин «приложение» часто используется для обозначения протоколов, идентифицированных с помощью проверочных подписей.

    См. Также
    Примечания
    Ссылки

    Библиография

    • Радиа Перлман: Межсоединения: мосты, маршрутизаторы, коммутаторы и протоколы межсетевого взаимодействия. 2-е издание. Аддисон-Уэсли 1999, ISBN 0-201-63448-1. В частности гл. 18 по «фольклору проектирования сетей», который также доступен в Интернете по адресу http://www.informit.com/articles/article.aspx?p=20482
    • Джерард Дж. Хольцманн: Разработка и проверка компьютерных протоколов. Прентис Холл, 1991, ISBN 0-13-539925-4. Также доступно в Интернете по адресу http://spinroot.com/spin/Doc/Book91.html
    • Дуглас Э. Комер (2000). Межсетевое взаимодействие с TCP / IP - принципы, протоколы и архитектура (4-е изд.). Прентис Холл. ISBN 0-13-018380-6.В частности, разделение уровней протокола в главе 11. Также имеется руководство по RFC и глоссарий терминов и сокращений межсетевого взаимодействия.
    • Инженерная группа Интернета сокр. IETF (1989): RFC1122, Требования к Интернет-хостам - Уровни связи, Р. Брейден (ред.), Доступно в Интернете по адресу http://tools.ietf.org/html/rfc1122. Описывает TCP / IP программного обеспечения протоколов. В частности, во введении дается обзор целей дизайна пакета.
    • М. Бен-Ари (1982): Принципы параллельного программирования 10-й печати. Prentice Hall International, ISBN 0-13-701078-8.
    • C.A.R. Хоар (1985): Сообщение последовательных процессов 10-й печати. Prentice Hall International, ISBN 0-13-153271-5. Доступно в Интернете по адресу http://www.usingcsp.com
    • R.D. Теннент (1981): Принципы языков программирования 10-й печати. Prentice Hall International, ISBN 0-13-709873-1.
    • Брайан Марсден (1986): Сетевые протоколы связи, 2-е издание. Чартвелл Братт, ISBN 0-86238-106-1.
    • Эндрю С. Таненбаум (1984): Структурированная компьютерная организация, 10-е издание. Prentice Hall International, ISBN 0-13-854605-3.
    Дополнительная литература
    • Radia Perlman, Межсоединения: мосты, маршрутизаторы, коммутаторы и протоколы межсетевого взаимодействия ( 2-е издание). Addison-Wesley 1999. ISBN 0-201-63448-1. В частности гл. 18 по "фольклору проектирования сетей".
    • Джерард Дж. Хольцманн, Дизайн и проверка компьютерных протоколов. Прентис Холл, 1991. ISBN 0-13-539925-4. Также доступно в Интернете по адресу http://spinroot.com /spin/Doc/Book91.html
    Внешние ссылки
Последняя правка сделана 2021-05-15 07:32:18
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте