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

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

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

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

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

Системы связи

История

Первое использование термина протокол в современном контексте коммутации данных произошло в апреле 1967 года в меморандуме под названием Протокол для использования в сети передачи данных NPL. Под руководством Дональда Дэвиса , который был пионером пакетной коммутации в Национальной физической лаборатории в Соединенном Королевстве, он был написан Роджером Скэнтлбери и Кейтом Бартлеттом для сети NPL . [5] [6] [7] [8] [9]

В ARPANET отправной точкой для связи между хостами в 1969 году стал протокол 1822 года , написанный Бобом Каном , который определял передачу сообщений в IMP. [10] Программа управления сетью (NCP) для ARPANET, разработанная Стивом Крокером и другими аспирантами, включая Джона Постела и Винта Серфа , была впервые реализована в 1970 году. [11] Интерфейс NCP позволял прикладному программному обеспечению подключаться через ARPANET, реализуя протоколы связи более высокого уровня, ранний пример концепции многоуровневого протокола . [12]

Сеть CYCLADES , разработанная Луи Пузеном в начале 1970-х годов, была первой, которая реализовала принцип «из конца в конец » и сделала хосты ответственными за надежную доставку данных в сети с коммутацией пакетов, а не за то, чтобы это было услугой самой сети. [13] Его команда была первой, кто взялся за сложнейшую проблему предоставления пользовательских приложений надежной службы виртуального канала при использовании службы «наилучших усилий» , ранний вклад в то, что впоследствии станет протоколом управления передачей (TCP). [14] [15] [16]

Боб Меткалф и другие в Xerox PARC изложили идею Ethernet и универсального пакета PARC (PUP) для межсетевого взаимодействия. [17]

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

Международная сетевая рабочая группа согласовала стандарт датаграмм без установления соединения , который был представлен CCITT в 1975 году, но не был принят ни CCITT, ни ARPANET. [19] Отдельные международные исследования, в частности работа Реми Депре , способствовали разработке стандарта X.25 , основанного на виртуальных цепях , который был принят CCITT в 1976 году. [20] [21] Производители компьютеров разработали собственные протоколы , такие как IBM Systems Network Architecture (SNA), Digital Equipment Corporation's DECnet и Xerox Network Systems . [22]

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

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

Концепция

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

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

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

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

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

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

Типы

Существует два типа протоколов связи, основанных на представлении передаваемого контента: текстовые и двоичные. [35]

Текстовый

Текстовый протокол или протокол простого текста представляет свое содержимое в удобном для восприятия человеком формате , часто в виде простого текста, закодированного в машиночитаемой кодировке, такой как ASCII или UTF-8 , или в структурированных текстовых форматах, таких как шестнадцатеричный формат Intel , XML или JSON .

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

Сетевые приложения имеют различные методы инкапсуляции данных. Один из методов, очень распространенных в интернет-протоколах, — это текстовое представление, которое передает запросы и ответы как строки текста ASCII , завершающиеся символом новой строки (и обычно символом возврата каретки). Примерами протоколов, которые используют простой, понятный человеку текст для своих команд, являются FTP ( File Transfer Protocol ), SMTP ( Simple Mail Transfer Protocol ), ранние версии HTTP ( Hypertext Transfer Protocol ) и протокол finger . [36]

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

Двоичный

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

Двоичные данные использовались в нормативных документах, описывающих современные стандарты, такие как EbXML , HTTP/2 , HTTP/3 и EDOC . [38] Интерфейс в UML [39] также можно считать двоичным протоколом.

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

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

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

Форматы данных для обмена данными
Обмен цифровыми битовыми строками сообщений. Битовые строки делятся на поля, и каждое поле несет информацию, относящуюся к протоколу. Концептуально битовая строка делится на две части, называемые заголовком и полезной нагрузкой . Фактическое сообщение передается в полезной нагрузке. Область заголовка содержит поля, имеющие отношение к работе протокола. Битовые строки, длина которых превышает максимальную единицу передачи (MTU), делятся на части соответствующего размера. [41]
Форматы адресов для обмена данными
Адреса используются для идентификации как отправителя, так и предполагаемого получателя(ей). Адреса переносятся в области заголовка битовых строк, позволяя получателям определять, представляют ли битовые строки интерес и должны ли они быть обработаны или должны быть проигнорированы. Соединение между отправителем и получателем может быть идентифицировано с помощью пары адресов (адрес отправителя, адрес получателя) . Обычно некоторые значения адресов имеют особое значение. Адрес из всех единиц может быть воспринят как адресация всех станций в сети, поэтому отправка на этот адрес приведет к широковещательной передаче в локальной сети. Правила, описывающие значения значения адреса, в совокупности называются схемой адресации . [42]
Адресное отображение
Иногда протоколам необходимо сопоставлять адреса одной схемы с адресами другой схемы. Например, чтобы преобразовать логический IP-адрес, указанный приложением, в MAC-адрес Ethernet. Это называется сопоставлением адресов . [43]
Маршрутизация
Когда системы не соединены напрямую, промежуточные системы на пути к предполагаемому получателю(ям) должны пересылать сообщения от имени отправителя. В Интернете сети соединены с помощью маршрутизаторов. Взаимосвязь сетей через маршрутизаторы называется межсетевым взаимодействием .
Обнаружение ошибок передачи
Обнаружение ошибок необходимо в сетях, где возможно повреждение данных. В общем подходе CRC области данных добавляется в конец пакетов, что позволяет получателю обнаружить различия, вызванные повреждением. Получатель отклоняет пакеты из-за различий CRC и каким-то образом организует повторную передачу. [44]
Благодарности
Подтверждение правильного приема пакетов требуется для ориентированной на соединение коммуникации . Подтверждения отправляются от получателей обратно их соответствующим отправителям. [45]
Потеря информации - тайм-ауты и повторные попытки
Пакеты могут быть потеряны в сети или задержаны в пути. Чтобы справиться с этим, в некоторых протоколах отправитель может ожидать подтверждения правильного приема от получателя в течение определенного времени. Таким образом, при тайм-аутах отправителю может потребоваться повторно передать информацию. [a] В случае постоянно разорванной связи повторная передача не имеет никакого эффекта, поэтому количество повторных передач ограничено. Превышение лимита повторных попыток считается ошибкой. [46]
Направление потока информации
Направление должно быть рассмотрено, если передача может происходить только в одном направлении за раз, как в полудуплексных соединениях или от одного отправителя за раз, как в общей среде . Это известно как управление доступом к среде . Должны быть приняты меры для урегулирования случая столкновения или конфликта , когда две стороны соответственно одновременно передают или хотят передать. [47]
Контроль последовательности
Если длинные битовые строки разделены на части и затем отправлены по сети по отдельности, части могут потеряться или задержаться или, в некоторых типах сетей, пойти разными путями к месту назначения. В результате части могут прибывать не в порядке. Повторные передачи могут привести к дублированию частей. Помечая части информацией о последовательности у отправителя, получатель может определить, что было потеряно или дублировано, запросить необходимые повторные передачи и собрать исходное сообщение. [48]
Управление потоком
Управление потоком необходимо, когда отправитель передает быстрее, чем получатель или промежуточное сетевое оборудование может обрабатывать передачи. Управление потоком может быть реализовано путем обмена сообщениями от получателя к отправителю. [49]
Очередь
Взаимодействующие процессы или конечные автоматы используют очереди (или «буферы»), обычно очереди FIFO, для обработки сообщений в порядке их отправки, и иногда могут иметь несколько очередей с разным приоритетом.

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

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

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

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

Наслаивание

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

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

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

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

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

Протокольное расслоение

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

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

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

Программное обеспечение слоёв

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

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

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

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

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

Строгая многослойность

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

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

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

Часто повторяющиеся проблемы при проектировании и реализации протоколов связи можно решить с помощью шаблонов проектирования программного обеспечения . [62] [63] [64] [65] [66]

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

Популярными формальными методами описания синтаксиса коммуникации являются Abstract Syntax Notation One ( стандарт ISO ) и расширенная форма Бэкуса–Наура ( стандарт IETF ).

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

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

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

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

Необходимость стандартов протоколов

Необходимость в стандартах протоколов можно продемонстрировать, посмотрев на то, что случилось с протоколом Binary Synchronous Communications (BSC), изобретенным IBM . BSC — это ранний протокол канального уровня, используемый для соединения двух отдельных узлов. Первоначально он не предназначался для использования в многоузловой сети, но при этом были выявлены некоторые недостатки протокола. В отсутствие стандартизации производители и организации чувствовали себя свободно в улучшении протокола, создавая несовместимые версии в своих сетях. В некоторых случаях это было сделано намеренно, чтобы отговорить пользователей от использования оборудования других производителей. Существует более 50 вариантов исходного протокола bi-sync. Можно предположить, что стандарт предотвратил бы хотя бы часть этого. [29]

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

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

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

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

В разработке протокола могут участвовать несколько органов стандартизации. Если они не скоординированы, то результатом могут стать множественные несовместимые определения протокола или множественные несовместимые интерпретации сообщений; важные инварианты в одном определении (например, что значения времени жизни монотонно уменьшаются, чтобы предотвратить устойчивые циклы маршрутизации ) могут не соблюдаться в другом. [71]

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

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

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

Модель OSI
по уровням
7.  Прикладной уровень
6.  Уровень представления
5.  Сеансовый уровень
4.  Транспортный уровень
3.  Сетевой уровень
2.  Уровень канала передачи данных
1.  Физический уровень

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

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

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

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

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

В то время [ когда? ] IETF пришлось с этим справляться, а также с тем фактом, что Интернету нужны были протоколы, которых просто не было. [ необходима цитата ] В результате IETF разработала свой собственный процесс стандартизации, основанный на «грубом консенсусе и работающем коде». [88] Процесс стандартизации описан в RFC  2026.

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

Изображение провода

Образ провода протокола — это информация, которую наблюдатель, не участвующий в процессе, может почерпнуть из наблюдения за сообщениями протокола, включая как информацию, явно имеющую значение в протоколе, так и выводы, сделанные наблюдателем. [89] Незашифрованные метаданные протокола являются одним из источников, составляющих образ провода, а побочные каналы, включая синхронизацию пакетов, также вносят свой вклад. [90] Разные наблюдатели с разными точками зрения могут видеть разные образы провода. [91] Образ провода имеет отношение к конфиденциальности конечного пользователя и расширяемости протокола. [92]

Если некоторая часть образа провода не криптографически аутентифицирована , она может быть изменена промежуточными сторонами (т. е. промежуточными устройствами ), что может повлиять на работу протокола. [90] Даже если аутентифицирована, если часть не зашифрована, она станет частью образа провода, и промежуточные стороны могут вмешаться в зависимости от ее содержимого (например, отбрасывая пакеты с определенными флагами). Сигналы, намеренно предназначенные для промежуточного потребления, могут быть оставлены аутентифицированными, но не зашифрованными. [93]

Образ сети может быть намеренно сконструирован, шифруя части, которые посредники не должны иметь возможности наблюдать, и предоставляя сигналы для того, что они должны иметь возможность. [94] Если предоставленные сигналы отделены от работы протокола, они могут стать ненадежными. [95] Доброкачественное управление сетями и исследования страдают от шифрования метаданных; разработчики протоколов должны сбалансировать наблюдаемость для работоспособности и исследований с устойчивостью к окостенению и конфиденциальностью конечного пользователя. [92] В 2014 году IETF объявила, что она определила, что крупномасштабное наблюдение за операциями протокола является атакой из-за возможности выводить информацию из образа сети о пользователях и их поведении, [96] и что IETF будет «работать над смягчением всеобъемлющего мониторинга» в своих проектах протоколов; [97] это не было сделано систематически ранее. [97] В 2023 году Совет по архитектуре Интернета рекомендовал, чтобы раскрытие информации протоколом в сети было преднамеренным, [98] осуществлялось с согласия как получателя, так и отправителя, [99] аутентифицировалось в возможной и необходимой степени, [100] действовало только в соответствии со степенью его надежности, [101] было сведено к минимуму и предоставлялось минимальному количеству субъектов. [102] [103] По данным IAB, проектирование образа провода и контроль того, какие сигналы предоставляются сетевым элементам, были «развивающейся областью» в 2023 году. [104]

Окостенение

Окостенение протокола — это потеря гибкости, расширяемости и развиваемости сетевых протоколов . Это во многом связано с промежуточными устройствами , которые чувствительны к образу протокола и могут прерывать или мешать сообщениям, которые являются допустимыми, но которые промежуточное устройство не распознает правильно. [105] Это нарушение принципа сквозной связи . [106] Вторичные причины включают негибкость в реализациях протоколов на конечных точках. [107]

Окостенение является серьезной проблемой в разработке и развертывании интернет -протоколов, поскольку оно может помешать развертыванию новых протоколов или расширений в Интернете или наложить ограничения на разработку новых протоколов; новые протоколы, возможно, придется инкапсулировать в уже развернутый протокол или имитировать сетевой образ другого протокола. [108] Из-за окостенения протокол управления передачей (TCP) и протокол пользовательских датаграмм (UDP) являются единственными практичными вариантами для транспортных протоколов в Интернете, [109] а сам TCP значительно окостенел, что затрудняет расширение или модификацию протокола. [110]

Рекомендуемые методы предотвращения окостенения включают шифрование метаданных протокола [111] и обеспечение того, чтобы точки расширения были задействованы, а изменчивость изображения проводов была представлена ​​как можно полнее; [112] устранение существующего окостенения требует координации между участниками протокола. [113] QUIC является первым транспортным протоколом IETF , который был разработан с преднамеренными свойствами, препятствующими окостенению. [89]

Таксономии

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

Схема слоев объединяет как функцию, так и область использования. Доминирующими схемами слоев являются те, которые разработаны IETF и ISO. Несмотря на то, что базовые предположения схем слоев достаточно различны, чтобы оправдать различие между ними, общепринятой практикой является сравнение двух схем путем соотнесения общих протоколов с уровнями двух схем. [114] Схема слоев от IETF называется слоистостью Интернета или слоистостью TCP/IP . Схема слоев от ISO называется моделью OSI или слоями ISO .

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

Смотрите также

Примечания

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

Ссылки

  1. ^ US 7529565, Hilpisch, Robert E.; Duchscher, Rob & Seel, Mark et al., «Протокол беспроводной связи», опубликовано 2009-05-05, передано Starkey Laboratories Inc. и Oticon AS 
  2. ↑ Протокол, Encyclopaedia Britannica , архивировано из оригинала 12 сентября 2012 г. , извлечено 24 сентября 2012 г.
  3. ^ ab Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, "Они (протоколы) для коммуникации то же, что языки программирования для вычислений"
  4. ^ abc Comer 2000, Раздел 1.3 - Интернет-услуги, стр. 3, "Протоколы для коммуникации то же, что алгоритмы для вычислений"
  5. ^ Нотон, Джон (24 сентября 2015 г.). Краткая история будущего. Орион. ISBN 978-1-4746-0277-8.
  6. ^ Кэмбелл-Келли, Мартин (1987). «Передача данных в Национальной физической лаборатории (1965-1975)». Annals of the History of Computing . 9 (3/4): 221–247. doi :10.1109/MAHC.1987.10023. S2CID  8172150.
  7. ^ Pelkey, James L. "6.1 The Communications Subnet: BBN 1969". Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968–1988 . Как вспоминает Кан: ... Вклад Пола Барана ... Я также думаю, что Пол был мотивирован почти исключительно голосовыми соображениями. Если вы посмотрите на то, что он написал, он говорил о коммутаторах, которые были недорогой электроникой. Идея размещения мощных компьютеров в этих местах не совсем пришла ему в голову как экономически эффективная. Поэтому идея компьютерных коммутаторов отсутствовала. Само понятие протоколов не существовало в то время. И идея коммуникаций между компьютерами была действительно второстепенной.
  8. ^ Уолдроп, М. Митчелл (2018). Машина снов. Stripe Press. стр. 286. ISBN 978-1-953953-36-0Баран уделял больше внимания цифровой голосовой связи, чем компьютерной.
  9. ^ Клейнрок, Л. (1978). «Принципы и уроки пакетной связи». Труды IEEE . 66 (11): 1320–1329. doi :10.1109/PROC.1978.11143. ISSN  0018-9219. Пол Баран ... сосредоточился на процедурах маршрутизации и на выживаемости распределенных систем связи во враждебной среде, но не сосредоточился на необходимости совместного использования ресурсов в той форме, как мы это понимаем сейчас; действительно, концепция программного коммутатора не присутствовала в его работе.
  10. ^ Интерфейсный процессор сообщений: спецификации для взаимодействия хоста и IMP (PDF) (отчет). Bolt Beranek и Newman (BBN). Отчет № 1822.
  11. ^ КНИГИ, ВЫСОКОЕ РАЗРЕШЕНИЕ. UGC -NET/JRF/SET PTP & Guide Teaching and Research Aptitude: UGC -NET By HD. Книги с высоким разрешением.
  12. ^ "NCP – Network Control Program". Living Internet . Архивировано из оригинала 7 августа 2022 года . Получено 8 октября 2022 года .
  13. ^ Беннетт, Ричард (сентябрь 2009 г.). «Создано для перемен: сквозные аргументы, инновации в Интернете и дебаты о нейтральности сети» (PDF) . Фонд информационных технологий и инноваций. стр. 7, 11. Получено 11 сентября 2017 г.
  14. ^ Эббейт, Джанет (2000). Изобретение Интернета. MIT Press. С. 124–127. ISBN 978-0-262-51115-5. Фактически, CYCLADES, в отличие от ARPANET, был специально разработан для облегчения межсетевого взаимодействия; он мог, например, обрабатывать различные форматы и различные уровни обслуживания.
  15. ^ Ким, Бён-Кён (2005). Интернационализация Интернета: совместная эволюция влияния и технологий. Эдвард Элгар. С. 51–55. ISBN 1845426754. Помимо сетей NPL и ARPANET, важную роль в развитии компьютерных сетевых технологий сыграла также академическая и исследовательская экспериментальная сеть CYCLADES.
  16. ^ "Пятый человек интернета". The Economist . 30 ноября 2013 г. ISSN  0013-0613 . Получено 22 апреля 2020 г. В начале 1970-х годов г-н Пузен создал инновационную сеть передачи данных, которая связала местоположения во Франции, Италии и Великобритании. Ее простота и эффективность указали путь к сети, которая могла бы соединять не просто десятки машин, а миллионы из них. Она захватила воображение доктора Серфа и доктора Кана, которые включили аспекты ее дизайна в протоколы, которые теперь питают интернет.
  17. ^ Мошовитис 1999, стр. 78-9
  18. ^ Cerf, V.; Kahn, R. (1974). "Протокол для пакетной сетевой интеркоммуникации" (PDF) . IEEE Transactions on Communications . 22 (5): 637–648. doi :10.1109/TCOM.1974.1092259. ISSN  1558-0857. Архивировано (PDF) из оригинала 6 января 2017 г. . Получено 23 февраля 2020 г. Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно R. Metcalfe, R. Scantlebury, D. Walden и H. Zimmerman; D. Davies и L. Pouzin, которые конструктивно прокомментировали вопросы фрагментации и учета; и S. Crocker, который прокомментировал создание и разрушение ассоциаций.
  19. ^ Маккензи, Александр (2011). «INWG и концепция Интернета: свидетельство очевидца». IEEE Annals of the History of Computing . 33 (1): 66–71. doi :10.1109/MAHC.2011.9. ISSN  1934-1547. S2CID  206443072.
  20. ^ Шварц, Миша (2010). «Виртуальные каналы X.25 — TRANSPAC во Франции — сети передачи данных до появления Интернета [История коммуникаций]». Журнал IEEE Communications . 48 (11): 40–46. doi :10.1109/MCOM.2010.5621965. ISSN  1558-1896. S2CID  23639680.
  21. ^ Рыбчинский, Тони (2009). «Коммерциализация пакетной коммутации (1975-1985): канадская перспектива [История коммуникаций]». Журнал IEEE Communications . 47 (12): 26–31. doi :10.1109/MCOM.2009.5350364. ISSN  1558-1896. S2CID  23243636.
  22. ^ «Скрытая» предыстория европейских исследовательских сетей. Trafford Publishing. стр. 354. ISBN 978-1-4669-3935-6.
  23. ^ "TCP/IP Internet Protocol". Живой Интернет . Архивировано из оригинала 1 сентября 2022 года . Получено 8 октября 2022 года .
  24. ↑ Эндрю Л. Рассел (30 июля 2013 г.). «OSI: Интернет, которого не было». IEEE Spectrum . Том 50, № 8.
  25. ^ Рассел, Эндрю Л. «Грубый консенсус и работающий код и война стандартов Интернет-OSI» (PDF) . Анналы истории вычислений IEEE. Архивировано (PDF) из оригинала 17 ноября 2019 г. Получено 23 февраля 2020 г.
  26. ^ "Standards Wars" (PDF) . 2006. Архивировано (PDF) из оригинала 24 февраля 2021 г. . Получено 23 февраля 2020 г. .
  27. ^ Бен-Ари 1982, глава 2 — Абстракция параллельного программирования, стр. 18-19, утверждает то же самое.
  28. ^ Бен-Ари 1982, Раздел 2.7 - Резюме, стр. 27, суммирует абстракцию параллельного программирования.
  29. ^ ab Marsden 1986, Раздел 6.1 - Почему необходимы стандарты?, стр. 64-65, использует BSC в качестве примера, чтобы показать необходимость как стандартных протоколов, так и стандартной структуры.
  30. ^ Комер 2000, раздел 11.2 — Необходимость множественных протоколов, стр. 177, объясняет это, проводя аналогии между компьютерной коммуникацией и языками программирования.
  31. ^ В разделе 11.10 — Недостаток многоуровневости, стр. 192, говорится: многоуровневость формирует основу для разработки протокола.
  32. ^ ab Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, утверждает то же самое.
  33. ^ Комер 2000, Раздел 11.3 - Концептуальные уровни программного обеспечения протокола, стр. 178, «Каждый уровень берет на себя ответственность за обработку одной части проблемы».
  34. ^ Comer 2000, Sect. 11.11 - Основная идея мультиплексирования и демультиплексирования, стр. 192, утверждает то же самое.
  35. ^ "Data Communication - an overview | ScienceDirect Topics". www.sciencedirect.com . Архивировано из оригинала 31 мая 2022 . Получено 31 мая 2022 .
  36. ^ Кирх, Олаф (16 января 2002 г.). «Протоколы на основе текста». Архивировано из оригинала 30 мая 2010 г. Получено 21 октября 2014 г.
  37. ^ Кирх, Олаф (16 января 2002 г.). "Протоколы двоичного представления". Архивировано из оригинала 30 мая 2010 г. Получено 4 мая 2006 г.
  38. ^ Кирх, Олаф (16 января 2002 г.). "Протоколы двоичного представления". Архивировано из оригинала 5 марта 2006 г. Получено 4 мая 2006 г.
  39. ^ "Welcome To UML Web Site!". Uml.org . Архивировано из оригинала 30 сентября 2019 года . Получено 15 января 2017 года .
  40. ^ Марсден 1986, Глава 3 — Основные концепции протокола и проблемные области, стр. 26-42, объясняет многое из следующего.
  41. ^ Comer 2000, Раздел 7.7.4 — Размер датаграммы, сетевой MTU и фрагментация, стр. 104, объясняет фрагментацию и ее влияние на заголовок фрагментов.
  42. ^ Комер 2000, Глава 4 - Классовые интернет-адреса, стр. 64-67;71.
  43. ^ Марсден 1986, Раздел 14.3 — Концепции наложения слоев и общие определения, стр. 187, объясняет сопоставление адресов.
  44. ^ Марсден 1986, Раздел 3.2 — Ошибки обнаружения и передачи, стр. 27, объясняет преимущества обратной коррекции ошибок.
  45. ^ Марсден 1986, Раздел 3.3 - Подтверждение, стр. 28-33, объясняет преимущества только положительного подтверждения и упоминает протоколы датаграмм как исключения.
  46. ^ Марсден 1986, Раздел 3.4 — Потеря информации — тайм-ауты и повторные попытки, стр. 33-34.
  47. ^ Марсден 1986, Раздел 3.5 - Направление информационного потока, стр. 34-35, объясняет понятие «хозяин/раб» и переговоры по получению контроля.
  48. ^ Марсден 1986, Раздел 3.6 - Управление последовательностью, стр. 35-36, объясняет, как теряются пакеты и как последовательность решает эту проблему.
  49. ^ Марсден 1986, Раздел 3.7 - Управление потоком, стр. 36-38.
  50. ↑ Бен-Ари 1982, в предисловии, стр. xiii.
  51. ↑ Бен-Ари 1982, в предисловии, стр. xiv.
  52. ^ Hoare 1985, Глава 4 — Коммуникация, стр. 133, посвящена коммуникации.
  53. ^ С. Шринивасан, Цифровые схемы и системы, курсы NPTEL, архивировано из оригинала 27 декабря 2009 г.
  54. ^ ab Comer 2000, раздел 11.2 — Необходимость множественных протоколов, стр. 177, вводит разложение на слои.
  55. ^ Comer 2000, Раздел 11.3 - Концептуальные уровни программного обеспечения протокола, стр. 179, первые два абзаца описывают отправку сообщения через последовательные уровни.
  56. ^ Комер 2000, раздел 11.2 — Необходимость множественных протоколов, стр. 178, объясняет сходство программного обеспечения протоколов и компилятора, ассемблера, компоновщика, загрузчика.
  57. ^ Comer 2000, Раздел 11.9.1 — Граница операционной системы, стр. 192, описывает границу операционной системы.
  58. ^ IETF 1989, Раздел 1.3.1 — Организация, стр. 15, 2-й абзац: многие решения по дизайну предполагают творческое «нарушение» строгой многослойности.
  59. ^ Comer 2000, раздел 11.10 — Недостаток многоуровневости, стр. 192, объясняет, почему «строгая многоуровневость может быть крайне неэффективной», приводя примеры оптимизаций.
  60. ^ Уэйкман, И. (январь 1992 г.). «Наслоение считается вредным». IEEE Network : 20–24.
  61. ^ Куроуз, Джеймс; Росс, Кит (2005). Компьютерные сети: подход сверху вниз . Пирсон.
  62. ^ Ласкано, Хорхе Эдисон; Клайд, Стивен; Раза, Али. "Шаблоны проектирования протоколов связи (CommDP) - COMMDP". Архивировано из оригинала 18 марта 2017 г. Получено 17 марта 2017 г.
  63. ^ Ласкано, Дж. Э.; Клайд, С. (2016). Язык шаблонов для протоколов связи на уровне приложений . ICSEA 2016, Одиннадцатая международная конференция по достижениям в области программной инженерии. С. 22–30.
  64. ^ Daigneau, R. (2011). Шаблоны проектирования служб: фундаментальные решения проектирования для SOAP/WSDL и RESTful веб-служб (1-е изд.). Upper Saddle River, NJ: Addison-Wesley Professional.
  65. ^ Фаулер, М. (2002). Модели архитектуры корпоративных приложений (1-е изд.). Бостон: Addison-Wesley Professional. ISBN 0-321-12742-0.
  66. ^ [1]Ф. Бушманн, К. Хенни и Д.К. Шмидт, Архитектура программного обеспечения, ориентированная на шаблоны. Том 4: Язык шаблонов для распределенных вычислений, издание тома 4. Чичестер, Англия; Нью-Йорк: Wiley, 2007.
  67. ^ Бохманн, Г. (1978). «Конечно-однородное описание протоколов связи». Компьютерные сети . 2 (4–5): 361–372. doi :10.1016/0376-5075(78)90015-6.
  68. ^ Комер 2000, Глоссарий терминов и сокращений межсетевого взаимодействия, стр. 704, термин протокол.
  69. ^ Бранд, Дэниел; Зафиропуло, Питро (1983). «О коммуникационных конечных автоматах». Журнал ACM . 30 (2): 323. doi : 10.1145/322374.322380 . S2CID  11607967.
  70. ^ Марсден 1986, Раздел 6.3 — Преимущества стандартизации, стр. 66-67, утверждает то же самое.
  71. ^ Брайант и Морроу 2009, стр. 4.
  72. ^ Марсден 1986, Раздел 6.4 - Некоторые проблемы со стандартизацией, стр. 67, следует HDLC для иллюстрации процесса.
  73. ^ "X.225: Информационные технологии – Взаимосвязь открытых систем – Протокол сеанса с установлением соединения: Спецификация протокола". Архивировано из оригинала 1 февраля 2021 г. Получено 10 марта 2023 г.
  74. ^ Марсден 1986, Раздел 6.1 — Почему необходимы стандарты?, стр. 65, объясняет уроки, извлеченные из ARPANET.
  75. ^ Марсден 1986, Раздел 14.1 - Введение, стр. 181, представляет OSI.
  76. ^ Марсден 1986, Раздел 14.3 — Концепции наложения слоев и общие определения, стр. 183-185, объясняет терминологию.
  77. ^ Марсден 1986, Раздел 14.4 - Уровень приложений, стр. 188, объясняет это.
  78. ^ Марсден 1986, Раздел 14.5 - Уровень представления, стр. 189, объясняет это.
  79. ^ Марсден 1986, Раздел 14.6 - Уровень сеанса, стр. 190, объясняет это.
  80. ^ Марсден 1986, Раздел 14.7 - Транспортный уровень, стр. 191, объясняет это.
  81. ^ Марсден 1986, Раздел 14.8 - Сетевой уровень, стр. 192, объясняет это.
  82. ^ Марсден 1986, Раздел 14.9 - Уровень канала передачи данных, стр. 194, объясняет это.
  83. ^ Марсден 1986, Раздел 14.10 - Физический уровень, стр. 195, объясняет это.
  84. ^ ISO 7498:1984 – Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. стр. 5. Эта базовая эталонная модель взаимосвязи открытых систем основана на предположении, что для передачи данных требуется соединение.
  85. ^ ISO 7498:1984/ADD 1:1987 – Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Приложение 1.
  86. ^ Marsden 1986, Раздел 14.11 - Режим без установления соединения и RM/OSI, стр. 195, упоминает об этом.
  87. ^ ISO 7498:1994 – Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель.
  88. ^ Comer 2000, Раздел 1.9 — Интернет-протоколы и стандартизация, стр. 12, объясняет, почему IETF не использовала существующие протоколы.
  89. ^ ab Trammell & Kuehlewind 2019, стр. 2.
  90. ^ ab Trammell & Kuehlewind 2019, стр. 3.
  91. ^ Траммелл и Кюхлевинд 2019, стр. 4.
  92. ^ ab Fairhurst & Perkins 2021, 7. Выводы.
  93. ^ Траммелл и Кюхлевинд 2019, стр. 5.
  94. ^ Траммелл и Кюлевинд 2019, стр. 6.
  95. ^ Траммелл и Кюлевинд 2019, стр. 7-8.
  96. ^ Фаррелл и Чофениг 2014, стр. 2.
  97. ^ ab Farrell & Tschofenig 2014, стр. 3.
  98. ^ Аркко и др. 2023, 2.1. Преднамеренное распространение.
  99. ^ Аркко и др. 2023, 2.2. Контроль распространения информации.
  100. ^ Аркко и др. 2023, 2.3. Защита информации и аутентификация.
  101. ^ Аркко и др. 2023, 2.5. Ограничение воздействия информации.
  102. ^ Аркко и др. 2023, 2.4. Минимизируйте информацию.
  103. ^ Аркко и др. 2023, 2.6. Минимальный набор сущностей.
  104. ^ Аркко и др. 2023, 3. Дальнейшая работа.
  105. ^ Папастерджиу и др. 2017, с. 619.
  106. ^ Папастерджиу и др. 2017, с. 620.
  107. ^ Папастерджиу и др. 2017, с. 620-621.
  108. ^ Папастерджиу и др. 2017, с. 623-4.
  109. ^ МакКвистин, Перкинс и Файед 2016, стр. 1.
  110. ^ Томсон и Поли 2021, А.5. TCP.
  111. ^ Харди 2019, стр. 7-8.
  112. ^ Томсон и Поли 2021, 3. Активное использование.
  113. ^ Томсон и Поли 2021, 3.5. Восстановление активного использования.
  114. ^ Comer 2000, раздел 11.5.1 — Эталонная модель TCP/IP 5-Layer, стр. 183, утверждает то же самое.

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

  • Радия Перлман (1999). Взаимосвязи: мосты, маршрутизаторы, коммутаторы и протоколы межсетевого взаимодействия (2-е изд.). Addison-Wesley. ISBN 0-201-63448-1.. В частности, гл. 18 о «фольклоре сетевого дизайна», которая также доступна онлайн.
  • Джерард Дж. Хольцман (1991). Проектирование и проверка компьютерных протоколов. Prentice Hall. ISBN 0-13-539925-4.
  • Дуглас Э. Комер (2000). Сетевое взаимодействие с TCP/IP — принципы, протоколы и архитектура (4-е изд.). Prentice Hall. ISBN 0-13-018380-6.В частности, гл. 11. Уровни протоколов. Также имеется руководство RFC и глоссарий терминов и сокращений межсетевого взаимодействия.
  • R. Braden , ed. (1989). Требования к хостам Интернета — коммуникационные уровни. Internet Engineering Task Force, сокр. IETF. doi : 10.17487/RFC1122 . RFC 1122.Описывает TCP/IP для разработчиков программного обеспечения протокола. В частности, введение дает обзор целей проектирования пакета.
  • М. Бен-ари (1982). Принципы параллельного программирования (10-е издание). Prentice Hall International. ISBN 0-13-701078-8.
  • CAR Hoare (1985). Коммуникационные последовательные процессы (10-е издание). Prentice Hall International. ISBN 0-13-153271-5.
  • RD Tennent (1981). Принципы языков программирования (10-е печатное издание). Prentice Hall International. ISBN 0-13-709873-1.
  • Брайан В. Марсден (1986). Протоколы сетей связи (2-е изд.). Chartwell Bratt. ISBN 0-86238-106-1.
  • Эндрю С. Таненбаум (1984). Структурированная компьютерная организация (10-е печатное издание). Prentice Hall International. ISBN 0-13-854605-3.
  • Брайант, Стюарт; Морроу, Моник, ред. (ноябрь 2009 г.). Нескоординированная разработка протокола считается вредной. doi : 10.17487/RFC5704 . RFC 5704.
  • Фаррелл, Стивен; Чофениг, Ханнес (май 2014 г.). Всепроникающий мониторинг — это атака. doi : 10.17487/RFC7258 . RFC 7258.
  • Траммелл, Брайан; Кюхлевинд, Мирья (апрель 2019 г.). Образ сетевого протокола в сети. doi : 10.17487/RFC8546 . RFC 8546.
  • Hardie, Ted, ред. (апрель 2019 г.). Сигналы пути транспортного протокола. doi : 10.17487/RFC8558 . RFC 8558.
  • Фэрхерст, Горри; Перкинс, Колин (июль 2021 г.). Соображения относительно конфиденциальности заголовка транспорта, сетевых операций и эволюции транспортных протоколов Интернета. doi : 10.17487/RFC9065 . RFC 9065.
  • Томсон, Мартин; Поли, Томми (декабрь 2021 г.). Долгосрочная жизнеспособность механизмов расширения протокола. doi : 10.17487/RFC9170 . RFC 9170.
  • Аркко, Яри; Харди, Тед; Поли, Томми; Кюлевинд, Мирья (июль 2023 г.). Соображения по применению — сетевое взаимодействие с использованием сигналов пути. doi : 10.17487/RFC9419 . RFC 9419.
  • МакКвистин, Стивен; Перкинс, Колин; Файед, Марван (июль 2016 г.). Реализация транспортных служб реального времени через окостеневшую сеть . Семинар по прикладным сетевым исследованиям 2016 г. doi : 10.1145/2959424.2959443. hdl : 1893/26111 .
  • Папастергиу, Гиоргос; Фэрхерст, Горри; Рос, Дэвид; Брунстром, Анна; Гриннемо, Карл-Йохан; Хуртиг, Пер; Хадеми, Наим; Туксен, Майкл; Вельцль, Майкл; Дамьянович, Драгана; Манджанте, Симоне (2017). «Декостенение транспортного уровня Интернета: обзор и будущие перспективы». Обзоры и руководства по коммуникациям IEEE . 19 : 619–639. doi : 10.1109/COMST.2016.2626780. hdl : 2164/8317 . S2CID  1846371.
  • Мошовитис, Христос Дж. П. (1999). История Интернета: хронология с 1843 года по настоящее время. ABC-CLIO. ISBN 978-1-57607-118-2.
  • Словарь протоколов Джаввина
  • Обзор протоколов в области телеуправления с использованием эталонной модели OSI
Retrieved from "https://en.wikipedia.org/w/index.php?title=Communication_protocol&oldid=1254883701"