Из Википедии, бесплатной энциклопедии
  (Перенаправлен из протокола связи )
Перейти к навигации Перейти к поиску

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

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

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

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

Коммуникационные системы [ править ]

История [ править ]

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

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

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

Международная рабочая группа по сети согласовало установления соединения дейтаграмм стандарт , который был представлен на CCIT в 1975 году , но не был принят МСЭ или по ARPANET. [11] Международные исследования, в частности , работа Ремигия Депре , внесли свой вклад в развитие X.25 стандарта, на основе виртуальных каналов со стороны МСЭ-Т в 1976 г. [12] [13] Производители компьютеров разработали собственные протоколы , такие как IBM, Системная сетевая архитектура (SNA), DECnet и Digital Equipment Corporation.Сетевые системы Xerox . [14]

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

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

Концепция [ править ]

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

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

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

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

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

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

Основные требования [ править ]

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

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

Форматы данных для обмена данными
Обмен битовыми строками цифрового сообщения. Строки битов разделены на поля, и каждое поле несет информацию, относящуюся к протоколу. Концептуально цепочка битов делится на две части, называемые заголовком и полезной нагрузкой . Фактическое сообщение переносится в полезной нагрузке. Область заголовка содержит поля, относящиеся к работе протокола. Строки битов длиннее максимальной единицы передачи (MTU) делятся на части подходящего размера. [28]
Форматы адресов для обмена данными
Адреса используются для идентификации как отправителя, так и предполагаемых получателей. Адреса переносятся в области заголовка цепочек битов, позволяя получателям определять, представляют ли цепочки битов интерес и должны ли их обрабатываться, или их следует игнорировать. Соединение между отправителем и получателем можно определить с помощью пары адресов (адрес отправителя, адрес получателя) . Обычно некоторые значения адресов имеют особое значение. An all - 1 сек - адрес может быть принят для обозначения адресации всех станций в сети, так что отправка по этому адресу приведет к трансляции по локальной сети. Правила, описывающие значения значения адреса, в совокупности называются схемой адресации . [29]
Отображение адресов
Иногда протоколам необходимо сопоставить адреса одной схемы с адресами другой схемы. Например, для преобразования логического IP-адреса, указанного приложением, в MAC-адрес Ethernet. Это называется отображением адресов . [30]
Маршрутизация
Когда системы не связаны напрямую, промежуточные системы на пути к предполагаемому получателю (ям) должны пересылать сообщения от имени отправителя. В Интернете сети соединяются с помощью маршрутизаторов. Взаимосвязь сетей через маршрутизаторы называется межсетевым взаимодействием .
Обнаружение ошибок передачи
Обнаружение ошибок необходимо в сетях, где возможно повреждение данных. В обычном подходе CRC области данных добавляется в конец пакетов, что позволяет получателю обнаруживать различия, вызванные повреждением. Получатель отклоняет пакеты при различиях CRC и каким-то образом организует повторную передачу. [31]
Благодарности
Подтверждение правильного приема пакетов требуется для связи с установлением соединения . Подтверждения отправляются получателями обратно их соответствующим отправителям. [32]
Потеря информации - таймауты и повторные попытки
Пакеты могут теряться в сети или задерживаться в пути. Чтобы справиться с этим, в соответствии с некоторыми протоколами отправитель может ожидать подтверждения правильного приема от получателя в течение определенного периода времени. Таким образом, по истечении времени ожидания отправителю может потребоваться повторно передать информацию. [a] В случае постоянно разрыва связи повторная передача не имеет никакого эффекта, поэтому количество повторных передач ограничено. Превышение лимита повторов считается ошибкой. [33]
Направление информационного потока
Направление необходимо адресовать, если передача может происходить только в одном направлении за раз, как на полудуплексных каналах, или от одного отправителя за раз, как на совместно используемой среде . Это называется контролем доступа к среде . Должны быть приняты меры для учета случая коллизии или разногласий, когда две стороны соответственно одновременно передают или желают передать. [34]
Последовательный контроль
Если длинные цепочки битов разделены на части, а затем отправлены по сети по отдельности, части могут быть потеряны или задержаны, или, в некоторых типах сетей, по разным маршрутам к месту назначения. В результате части могут поступать не по порядку. Повторная передача может привести к дублированию частей. Помечая части с информацией о последовательности у отправителя, получатель может определить, что было потеряно или дублировано, запросить необходимые повторные передачи и повторно собрать исходное сообщение. [35]
Управление потоком
Управление потоком необходимо, когда отправитель передает быстрее, чем получатель или промежуточное сетевое оборудование может обработать передачи. Управление потоком может быть реализовано путем обмена сообщениями от получателя к отправителю. [36]
Очередь
Взаимодействующие процессы или конечные автоматы используют очереди (или «буферы»), обычно очереди FIFO, для работы с сообщениями в порядке отправки, и иногда могут иметь несколько очередей с разными приоритетами.

Дизайн протокола [ править ]

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

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

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

Наслоение [ править ]

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

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

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

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

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

Распределение протоколов [ править ]

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

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

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

Уровни программного обеспечения [ править ]

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

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

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

Перевод программы разбит на подзадачи. В результате программное обеспечение для перевода также является многоуровневым, что позволяет разрабатывать уровни программного обеспечения независимо. Тот же подход можно увидеть в многоуровневом TCP / IP. [43]

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

Строгое наслоение [ править ]

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

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

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

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

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

Формальные методы описания коммуникационного синтаксиса - это абстрактная синтаксическая нотация 1 ( стандарт ISO ) и расширенная форма Бэкуса-Наура ( стандарт IETF ).

Модели конечных автоматов [54] [55] и коммуникационные конечные автоматы [56] используются для формального описания возможных взаимодействий протокола.

Разработка протокола [ править ]

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

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

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

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

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

Организации по стандартизации [ править ]

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

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

Процесс стандартизации [ править ]

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

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

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

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

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

Стандартизация OSI [ править ]

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

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

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

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

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

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

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

Таксономии [ править ]

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

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

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

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

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

См. Также [ править ]

  • Списки сетевых протоколов

Заметки [ править ]

  1. ^ Неполучение подтверждения означает, что либо исходная передача, либо подтверждение были потеряны. Отправитель не имеет возможности различать эти случаи, и поэтому, чтобы гарантировать получение всех данных, он должен сделать консервативное предположение, что исходная передача была потеряна.

Ссылки [ править ]

  1. ^ [1] , «Протокол беспроводной связи», выпущенный 01.12.2004. 
  2. ↑ Протокол , Британская энциклопедия , получено 24 сентября 2012 г.
  3. ^ a b Comer 2000, разд. 11.2 - Потребность в нескольких протоколах, стр. 177, «Они (протоколы) для связи, что языки программирования для вычислений»
  4. ^ a b c Comer 2000, разд. 1.3 - Интернет-услуги, п. 3, «Протоколы для коммуникации такие же, как алгоритмы для вычислений»
  5. ^ Нотон, Джон (24 сентября 2015). Краткая история будущего . Орион. ISBN 978-1-4746-0277-8.
  6. ^ Кэмбелл-Келли, Мартин (1987). «Обмен данными в Национальной физической лаборатории (1965-1975)» . Анналы истории вычислительной техники . 9 (3/4): 221–247. DOI : 10.1109 / MAHC.1987.10023 . S2CID 8172150 . 
  7. ^ Процессор интерфейсных сообщений: Спецификации для взаимодействия хоста и IMP , Отчет № 1822, Bolt Beranek and Newman, Inc. (BBN)
  8. ^ КНИГИ, ВЫСОКОЕ ОПРЕДЕЛЕНИЕ. UGC -NET / JRF / SET PTP и руководство по обучению и исследованиям: UGC -NET Автор HD . Книги в высоком разрешении.
  9. ^ "NCP - Программа управления сетью" , Living Internet
  10. ^ Cerf, V .; Кан Р. (1974). «Протокол межсетевого взаимодействия в пакетной сети» (PDF) . Транзакции IEEE по коммуникациям . 22 (5): 637–648. DOI : 10.1109 / TCOM.1974.1092259 . ISSN 1558-0857 . Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана; Д. Дэвис и Л. Пузин, конструктивно прокомментировавшие проблемы фрагментации и учета; и С. Крокер, который прокомментировал создание и разрушение ассоциаций.  
  11. ^ Маккензи, Александр (2011). «INWG и концепция Интернета: рассказ очевидцев». IEEE Annals of the History of Computing . 33 (1): 66–71. DOI : 10,1109 / MAHC.2011.9 . ISSN 1934-1547 . S2CID 206443072 .  
  12. ^ Шварц, Миша (2010). «Виртуальные каналы X.25 - ТРАНСПАК ВО Франции - Сети передачи данных до Интернета [История коммуникаций]». Журнал IEEE Communications . 48 (11): 40–46. DOI : 10,1109 / MCOM.2010.5621965 . ISSN 1558-1896 . S2CID 23639680 .  
  13. ^ Рыбчинский, Тони (2009). «Коммерциализация коммутации пакетов (1975-1985): канадская перспектива [История коммуникаций]». Журнал IEEE Communications . 47 (12): 26–31. DOI : 10.1109 / MCOM.2009.5350364 . ISSN 1558-1896 . S2CID 23243636 .  
  14. ^ "Скрытая" предыстория европейских исследовательских сетей . Издательство Trafford. п. 354. ISBN 978-1-4669-3935-6.
  15. ^ "Интернет-протокол TCP / IP" , Живой Интернет
  16. ↑ Эндрю Л. Рассел (30 июля 2013 г.). «OSI: Интернет, которого не было» . IEEE Spectrum . Vol. 50 шт. 8.
  17. ^ Рассел, Эндрю Л. «Грубый консенсус и работающий код» и война стандартов OSI и Интернета » (PDF) . IEEE Annals of the History of Computing.
  18. ^ "Стандарты войны" (PDF) . 2006 г. Цитировать журнал требует |journal=( помощь )
  19. ^ Бен-Ари 1982, глава 2 - Абстракция параллельного программирования, стр. 18-19, говорится то же самое.
  20. ^ Бен-Ари 1982, Раздел 2.7 - Резюме, стр. 27, резюмирует абстракцию параллельного программирования.
  21. ^ a b Marsden 1986, Раздел 6.1 - Зачем нужны стандарты ?, стр. 64-65, использует BSC в качестве примера, чтобы показать необходимость как стандартных протоколов, так и стандартной структуры.
  22. ^ Comer 2000, п. 11.2 - Потребность в нескольких протоколах, стр. 177, объясняет это, проводя аналогии между компьютерным общением и языками программирования.
  23. ^ a b Разд. 11.10 - Недостаток наслоения, стр. 192, гласит: многоуровневость формирует основу для разработки протокола.
  24. ^ a b Comer 2000, разд. 11.2 - Потребность в нескольких протоколах, стр. 177, утверждает то же самое.
  25. ^ Comer 2000, п. 11.3 - Концептуальные уровни программного обеспечения протокола, стр. 178, «Каждый уровень берет на себя ответственность за решение одной части проблемы».
  26. ^ Comer 2000, п. 11.11 - Основная идея мультиплексирования и демультиплексирования, стр. 192, утверждает то же самое.
  27. ^ Марсден 1986, Глава 3 - Основные концепции протокола и проблемные области, стр. 26-42, объясняет многое из следующего.
  28. ^ Comer 2000, п. 7.7.4 - Размер дейтаграммы, MTU сети и фрагментация, стр. 104, Объясняет фрагментацию и влияние на заголовок фрагментов.
  29. ^ Comer 2000, Глава 4 - Классные Интернет-адреса, стр. 64-67; 71.
  30. ^ Марсден 1986, Раздел 14.3 - Понятия наслоения и общие определения, стр. 187, объясняет отображение адресов.
  31. ^ Марсден 1986, Раздел 3.2 - Ошибки обнаружения и передачи, стр. 27, объясняет преимущества обратной коррекции ошибок.
  32. ^ Марсден 1986, Раздел 3.3 - Благодарность, стр. 28-33, объясняет преимущества только положительного подтверждения и упоминает протоколы дейтаграмм как исключения.
  33. ^ Марсден 1986, Раздел 3.4 - Потеря информации - таймауты и повторные попытки, стр. 33-34.
  34. ^ Марсден 1986, Раздел 3.5 - Направление информационного потока, стр. 34-35, объясняет ведущий / ведомый и переговоры для получения контроля.
  35. ^ Марсден 1986, Раздел 3.6 - Контроль последовательности, стр. 35-36, объясняет, как пакеты теряются и как последовательность решает эту проблему.
  36. ^ Марсден 1986, Раздел 3.7 - Управление потоком, стр. 36-38.
  37. ↑ Ben-Ari 1982, в его предисловии, стр. xiii.
  38. ↑ Ben-Ari 1982, в его предисловии, стр. xiv.
  39. ↑ Hoare 1985, Глава 4 - Связь, стр. 133, занимается коммуникацией.
  40. ^ С. Сринивасан, Цифровые схемы и системы , курсы NPTEL, заархивировано с оригинала 27 декабря 2009 г.
  41. ^ a b Comer 2000, разд. 11.2 - Потребность в нескольких протоколах, стр. 177, вводит разложение по слоям.
  42. ^ Comer 2000, п. 11.3 - Концептуальные уровни программного обеспечения протокола, стр. 179, первые два абзаца описывают отправку сообщения через последовательные уровни.
  43. ^ Comer 2000, п. 11.2 - Необходимость использования нескольких протоколов, стр. 178, объясняет сходство программного обеспечения протокола и компилятора, ассемблера, компоновщика, загрузчика.
  44. ^ Comer 2000, п. 11.9.1 - Границы операционной системы, стр. 192, описывает границы операционной системы.
  45. ^ IETF 1989, раздел 1.3.1 - Организация, стр. 15, 2-й абзац: многие варианты дизайна предполагают творческое «нарушение» строгого наслоения.
  46. ^ Comer 2000, п. 11.10 - Недостаток наслоения, стр. 192, объясняет, почему «строгое разделение на слои может быть крайне неэффективным», приводя примеры оптимизации.
  47. ↑ Wakeman, I (январь 1992 г.). «Наслоение считается вредным». Сеть IEEE : 20–24.
  48. ^ Куроз, Джеймс; Росс, Кейт (2005). Компьютерные сети: подход сверху вниз . Пирсон.
  49. ↑ Хорхе Эдисон Ласкано, Стивен Клайд и Али Раза. «Шаблоны проектирования коммуникационного протокола (CommDP) - COMMDP». [В сети]. Доступно: http://commdp.serv.usu.edu/wiki/index.php/Communication-protocol_Design_Patterns_(CommDP). Архивировано 18 марта 2017 г. на Wayback Machine . [Доступ: 17 марта 2017 г.].
  50. ^ JE Lascano и S. Clyde, «Язык шаблонов для протоколов связи на уровне приложений», представленный на ICSEA 2016, Одиннадцатая Международная конференция по достижениям в разработке программного обеспечения, 2016, стр. 22–30.
  51. ^ Р. Дайно, Шаблоны проектирования сервисов: фундаментальные дизайнерские решения для SOAP / WSDL и веб-сервисов RESTful, 1-е издание. Аппер-Сэдл-Ривер, Нью-Джерси: Addison-Wesley Professional, 2011.
  52. ^ М. Фаулер, Шаблоны архитектуры корпоративных приложений, 1-е издание. Бостон: Addison-Wesley Professional, 2002.
  53. ^ [1] F. Бушманн, К. Хенни и Д.К. Шмидт, Шаблонно-ориентированная архитектура программного обеспечения Том 4: Язык шаблонов для распределенных вычислений, издание тома 4. Чичестер, Англия; Нью-Йорк: Wiley, 2007.
  54. ^ Бохманн, Г. (1978). «Конечное описание протоколов связи». Компьютерные сети (1976) . 2 (4–5): 361–372. DOI : 10.1016 / 0376-5075 (78) 90015-6 .
  55. ^ Comer 2000, Глоссарий терминов и сокращений межсетевого взаимодействия, стр. 704, срочный протокол.
  56. ^ Бренд, Дэниел; Зафиропуло, Питро (1983). «О сообщающихся конечных машинах». Журнал ACM . 30 (2): 323. DOI : 10,1145 / 322374,322380 . S2CID 11607967 . 
  57. ^ Марсден 1986, Раздел 6.3 - Преимущества стандартизации, стр. 66-67, говорится то же самое.
  58. ^ Марсден 1986, раздел 6.4 - Некоторые проблемы стандартизации, стр. 67, следует за HDLC, чтобы проиллюстрировать процесс.
  59. ^ Марсден 1986, Раздел 6.1 - Зачем нужны стандарты?, Стр. 65, объясняет уроки, извлеченные из ARPANET.
  60. ^ Марсден 1986, Раздел 14.1 - Введение, стр. 181, представляет OSI.
  61. ^ Марсден 1986, Раздел 14.3 - Понятия наслоения и общие определения, стр. 183-185, объясняет терминологию.
  62. ^ Марсден 1986, Раздел 14.4 - Уровень приложения, стр. 188, объясняет это.
  63. ^ Марсден 1986, Раздел 14.5 - Уровень представления, стр. 189, объясняет это.
  64. ^ Марсден 1986, Раздел 14.6 - Сессионный слой, стр. 190, объясняет это.
  65. ^ Марсден 1986, Раздел 14.7 - Транспортный слой, стр. 191, объясняет это.
  66. ^ Марсден 1986, Раздел 14.8 - Сетевой уровень, стр. 192, объясняет это.
  67. ^ Марсден 1986, Раздел 14.9 - Уровень канала передачи данных, стр. 194, объясняет это.
  68. ^ Марсден 1986, Раздел 14.10 - Физический уровень, стр. 195, объясняет это.
  69. ^ Марсден 1986, Раздел 14.11 - Режим без установления соединения и RM / OSI, стр. 195, упоминает об этом.
  70. ^ Comer 2000, раздел 1.9 - Интернет-протоколы и стандартизация, стр. 12 объясняет, почему IETF не использовала существующие протоколы.
  71. ^ Comer 2000, п. 11.5.1 - Пятиуровневая эталонная модель TCP / IP, стр. 183, утверждает то же самое.

Библиография [ править ]

  • Радиа Перлман : Межсетевые соединения: мосты, маршрутизаторы, коммутаторы и протоколы межсетевого взаимодействия. 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 . 
  • Карл Хоар (1985): Сообщение последовательных процессов 10-й печати. Prentice Hall International, ISBN 0-13-153271-5 . Доступно на сайте http://www.usingcsp.com 
  • RD Tennent (1981): Принципы языков программирования 10th Print. 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 . 

Дальнейшее чтение [ править ]

  • Радиа Перлман , Соединения: мосты, маршрутизаторы, коммутаторы и протоколы межсетевого взаимодействия (2-е издание) . Аддисон-Уэсли 1999. ISBN 0-201-63448-1 . В частности, гл. 18 по "фольклору сетевого дизайна". 
  • Джерард Дж. Хольцманн , Разработка и проверка компьютерных протоколов . Прентис Холл, 1991. ISBN 0-13-539925-4 . Также доступно в Интернете по адресу http://spinroot.com/spin/Doc/Book91.html 

Внешние ссылки [ править ]

  • Словарь протокола Яввина
  • Обзор протоколов в области телеуправления с эталонной моделью OSI