stringtranslate.com

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

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

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

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

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

Коммуникационные системы

История

Первое использование термина « протокол» в современном контексте коммутации данных произошло в апреле 1967 года в меморандуме, озаглавленном « Протокол для использования в сети передачи данных 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 . Архитектура (SNA), DECnet корпорации Digital Equipment и Xerox Network Systems . [22]

Программное обеспечение TCP было переработано как модульный стек протоколов. Первоначально называвшийся IP/TCP , он был установлен в 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 , или в структурированных текстовых форматах, таких как XML или JSON .

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

Сетевые приложения используют различные методы инкапсуляции данных. Одним из методов, очень распространенных в интернет-протоколах, является текстовое представление, при котором запросы и ответы передаются в виде строк текста ASCII , заканчивающихся символом новой строки (и обычно символом возврата каретки). Примерами протоколов, которые используют простой, удобочитаемый текст для своих команд, являются FTP ( протокол передачи файлов ), SMTP ( простой протокол передачи почты ), ранние версии HTTP ( протокол передачи гипертекста ) и протокол 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. Протоколы относительно многоуровневой схемы Интернета.
Рисунок 2. Модель TCP/IP или многоуровневая схема Интернета и ее связь с некоторыми распространенными протоколами.

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

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

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

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

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

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

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

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

Многоуровневое программное обеспечение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В отличие от многоуровневой схемы 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. ^ США 7529565, Хилпиш, Роберт Э.; Дачшер, Роб и Сил, Марк и др., «Протокол беспроводной связи», опубликовано 5 мая 2009 г., передано Starkey Laboratories Inc. и Oticon AS. 
  2. ↑ Протокол, Британская энциклопедия , заархивировано из оригинала 12 сентября 2012 г. , получено 24 сентября 2012 г.
  3. ^ ab Comer 2000, разд. 11.2 – Необходимость использования нескольких протоколов, с. 177: «Они (протоколы) для общения то же самое, что языки программирования для вычислений».
  4. ^ abc Comer 2000, разд. 1.3 – Интернет-услуги, с. 3: «Протоколы для связи — то же самое, что алгоритмы для вычислений».
  5. ↑ Нотон, Джон (24 сентября 2015 г.). Краткая история будущего. Орион. ISBN 978-1-4746-0277-8.
  6. ^ Кэмбелл-Келли, Мартин (1987). «Передача данных в Национальной физической лаборатории (1965–1975)». Анналы истории вычислительной техники . 9 (3/4): 221–247. дои : 10.1109/MAHC.1987.10023. S2CID  8172150.
  7. ^ Пелки, Джеймс Л. «6.1 Подсеть связи: BBN 1969». Предпринимательский капитализм и инновации: история компьютерных коммуникаций 1968–1988 гг . Как вспоминает Кан: ... Вклад Пола Бэрана ... Я также думаю, что Пол был почти полностью мотивирован голосовыми соображениями. Если вы посмотрите на то, что он написал, он говорил о переключателях, которые представляли собой дешевую электронику. Идея разместить в этих местах мощные компьютеры не совсем пришла ему в голову как экономически выгодная. Так что идея компьютерных переключателей отсутствовала. В то время не существовало самого понятия протоколов. А идея межкомпьютерной связи на самом деле была второстепенной.
  8. ^ Барбер, Дерек (весна 1993 г.). «Истоки коммутации пакетов». Бюллетень Общества охраны компьютеров (5). ISSN  0958-7403 . Проверено 6 сентября 2017 г. Была статья, написанная [Полом Бэраном] из Rand Corporation, которая, в некотором смысле, предвещала коммутацию пакетов для речевых сетей и голосовых сетей.
  9. ^ «О коммутации пакетов» . Чистая история . Проверено 8 января 2024 г. [Скантлбери сказал] Очевидно, что Дональд и Пол Бэран независимо пришли к похожей идее, хотя и с разными целями. Пол за живучую голосовую/телексную сеть, наш за высокоскоростную компьютерную сеть.
  10. ^ Процессор сообщений интерфейса: Спецификации взаимодействия хоста и IMP (PDF) (Отчет). Болт Беранек и Ньюман (BBN). Отчет № 1822.
  11. ^ КНИГИ, ВЫСОКОЕ РАЗРЕШЕНИЕ. UGC-NET/JRF/SET PTP и руководство по преподаванию и исследованиям: UGC-NET от HD. Книги высокого разрешения.
  12. ^ «NCP - Программа управления сетью» . Живой Интернет . Архивировано из оригинала 7 августа 2022 года . Проверено 8 октября 2022 г.
  13. ^ Беннетт, Ричард (сентябрь 2009 г.). «Создан для перемен: сквозные аргументы, интернет-инновации и дебаты о сетевом нейтралитете» (PDF) . Фонд информационных технологий и инноваций. стр. 7, 11 . Проверено 11 сентября 2017 г.
  14. ^ Аббате, Джанет (2000). Изобретение Интернета. МТИ Пресс. стр. 124–127. ISBN 978-0-262-51115-5. Фактически, CYCLADES, в отличие от ARPANET, был специально разработан для облегчения межсетевого взаимодействия; например, он может обрабатывать различные форматы и различные уровни обслуживания.
  15. ^ Ким, Бён Гын (2005). Интернационализация Интернета: коэволюция влияния и технологий. Эдвард Элгар. стр. 51–55. ISBN 1845426754. Помимо сети NPL и ARPANET, важную роль в развитии компьютерных сетевых технологий сыграла также академическая и исследовательская экспериментальная сеть CYCLADES.
  16. ^ "Пятый человек Интернета" . Экономист . 30 ноября 2013 г. ISSN  0013-0613 . Проверено 22 апреля 2020 г. В начале 1970-х годов Пузен создал инновационную сеть передачи данных, которая связала места во Франции, Италии и Великобритании. Ее простота и эффективность указали путь к сети, которая могла бы соединить не только десятки машин, но и миллионы из них. Он захватил воображение доктора Серфа и доктора Кана, которые включили аспекты его конструкции в протоколы, которые сейчас поддерживают Интернет.
  17. ^ Мошовит 1999, с. 78-9
  18. ^ Серф, В.; Кан, Р. (1974). «Протокол пакетной сетевой связи» (PDF) . Транзакции IEEE в области коммуникаций . 22 (5): 637–648. дои : 10.1109/TCOM.1974.1092259. ISSN  1558-0857. Архивировано (PDF) из оригинала 6 января 2017 года . Проверено 23 февраля 2020 г. Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана; Д. Дэвис и Л. Пузен, конструктивно прокомментировавшие вопросы фрагментации и учета; и С. Крокер, комментировавшие создание и разрушение ассоциаций.
  19. ^ Маккензи, Александр (2011). «INWG и концепция Интернета: рассказ очевидца». IEEE Анналы истории вычислений . 33 (1): 66–71. дои : 10.1109/MAHC.2011.9. ISSN  1934-1547. S2CID  206443072.
  20. ^ Шварц, Миша (2010). «Виртуальные каналы X.25 - TRANSPAC ВО Франции - Сети передачи данных до Интернета [История коммуникаций]». Журнал коммуникаций IEEE . 48 (11): 40–46. дои : 10.1109/MCOM.2010.5621965. ISSN  1558-1896. S2CID  23639680.
  21. ^ Рыбчинский, Тони (2009). «Коммерциализация коммутации пакетов (1975–1985): канадская перспектива [История коммуникаций]». Журнал коммуникаций IEEE . 47 (12): 26–31. дои : 10.1109/MCOM.2009.5350364. ISSN  1558-1896. S2CID  23243636.
  22. ^ «Скрытая» предыстория европейских исследовательских сетей. Траффорд Паблишинг. п. 354. ИСБН 978-1-4669-3935-6.
  23. ^ «Интернет-протокол TCP/IP» . Живой Интернет . Архивировано из оригинала 1 сентября 2022 года . Проверено 8 октября 2022 г.
  24. ↑ Эндрю Л. Рассел (30 июля 2013 г.). «OSI: Интернет, которого не было». IEEE-спектр . Том. 50, нет. 8.
  25. ^ Рассел, Эндрю Л. «Приблизительный консенсус и работающий код» и война стандартов Интернет-OSI» (PDF) . IEEE Анналы истории вычислений. Архивировано (PDF) из оригинала 17 ноября 2019 года . Проверено 23 февраля 2020 г.
  26. ^ «Войны стандартов» (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, разд. 11.2 – Необходимость использования нескольких протоколов, с. 177, указано то же самое.
  33. ^ Приход 2000, разд. 11.3 – Концептуальные уровни протокольного программного обеспечения, с. 178: «Каждый уровень берет на себя ответственность за решение одной части проблемы».
  34. ^ Приход 2000, разд. 11.11 – Основная идея мультиплексирования и демультиплексирования, с. 192, указано то же самое.
  35. ^ «Передача данных - обзор | Темы ScienceDirect» . 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. ^ «Добро пожаловать на веб-сайт UML!». Uml.org . Архивировано из оригинала 30 сентября 2019 года . Проверено 15 января 2017 г.
  40. ^ Марсден 1986, Глава 3 - Фундаментальные концепции протокола и проблемные области, стр. 26-42, объясняет многое из следующего.
  41. ^ Приход 2000, разд. 7.7.4 – Размер дейтаграммы, сетевой MTU и фрагментация, стр. 104. Объясняет фрагментацию и влияние на заголовок фрагментов.
  42. ^ Comer 2000, Глава 4 - Классовые интернет-адреса, стр. 64-67;71.
  43. ^ Марсден 1986, Раздел 14.3 - Концепции многоуровневого представления и общие определения, стр. 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. ^ Хоар 1985, Глава 4 - Коммуникация, с. 133, посвящен связи.
  53. ^ С. Сринивасан, Цифровые схемы и системы, курсы NPTEL, заархивировано из оригинала 27 декабря 2009 г.
  54. ^ ab Comer 2000, разд. 11.2 – Необходимость использования нескольких протоколов, с. 177, представлено разложение по слоям.
  55. ^ Приход 2000, разд. 11.3 – Концептуальные уровни протокольного программного обеспечения, с. 179, первые два параграфа описывают отправку сообщения через последовательные уровни.
  56. ^ Приход 2000, разд. 11.2 – Необходимость нескольких протоколов, с. 178, объясняет сходство программного обеспечения протокола и компилятора, ассемблера, компоновщика, загрузчика.
  57. ^ Приход 2000, разд. 11.9.1 — Границы операционной системы, стр. 11.9.1. Границы операционной системы. 192 описывает границу операционной системы.
  58. ^ IETF 1989, раздел 1.3.1 - Организация, стр. 15, 2-й абзац: многие варианты дизайна предполагают творческий «нарушение» строгой многослойности.
  59. ^ Приход 2000, разд. 11.10 – Недостаток многослойности, с. 192, объясняет, почему «строгое разделение на уровни может быть крайне неэффективным», приводя примеры оптимизации.
  60. ^ Уэйкман, I (январь 1992 г.). «Наслоение считается вредным». Сеть IEEE : 20–24.
  61. ^ Куросе, Джеймс; Росс, Кейт (2005). Компьютерные сети: нисходящий подход . Пирсон.
  62. ^ Ласкано, Хорхе Эдисон; Клайд, Стивен; Раза, Али. «Шаблоны проектирования коммуникационных протоколов (CommDP) - COMMDP». Архивировано из оригинала 18 марта 2017 года . Проверено 17 марта 2017 г.
  63. ^ Ласкано, JE; Клайд, С. (2016). Язык шаблонов для протоколов связи прикладного уровня . ICSEA 2016, Одиннадцатая Международная конференция по достижениям в области программной инженерии. стр. 22–30.
  64. ^ Дайно, Р. (2011). Шаблоны проектирования сервисов: фундаментальные решения по проектированию для веб-служб SOAP/WSDL и RESTful (1-е изд.). Река Аппер-Сэддл, Нью-Джерси: Addison-Wesley Professional.
  65. ^ Фаулер, М. (2002). Шаблоны архитектуры корпоративных приложений (1-е изд.). Бостон: Аддисон-Уэсли Профессионал. ISBN 0-321-12742-0.
  66. ^ [1] Ф. Бушманн, К. Хенни и Д.С. Шмидт, Шаблонно-ориентированная архитектура программного обеспечения, том 4: язык шаблонов для распределенных вычислений, издание тома 4. Чичестер Англия; Нью-Йорк: Уайли, 2007.
  67. ^ Бохманн, Г. (1978). «Конечное состояние протоколов связи». Компьютерная сеть . 2 (4–5): 361–372. дои : 10.1016/0376-5075(78)90015-6.
  68. ^ Comer 2000, Глоссарий терминов и сокращений межсетевого взаимодействия, стр. 704, протокол срока.
  69. ^ Брэнд, Дэниел; Зафиропуло, Питро (1983). «О связи конечных автоматов». Журнал АКМ . 30 (2): 323. дои : 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 - Концепции многоуровневого представления и общие определения, стр. 14.3. 183-185, поясняет терминологию.
  77. ^ Марсден 1986, Раздел 14.4 - Прикладной уровень, стр. 188, объясняет это.
  78. ^ Марсден 1986, Раздел 14.5 - Уровень представления, с. 189, объясняет это.
  79. ^ Марсден 1986, Раздел 14.6 - Сеансовый уровень, стр. 190, объясняет это.
  80. ^ Марсден 1986, Раздел 14.7 - Транспортный уровень, стр. 14.7. 191, объясняет это.
  81. ^ Марсден 1986, Раздел 14.8 - Сетевой уровень, стр. 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. ^ Марсден 1986, раздел 14.11 - Режим без установления соединения и RM/OSI, стр. 14.11. 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. ПТС.
  111. ^ Харди 2019, с. 7-8.
  112. ^ Томсон и Поли, 2021, 3. Активное использование.
  113. ^ Томсон и Поли 2021, 3.5. Восстановление активного использования.
  114. ^ Приход 2000, разд. 11.5.1 – 5-уровневая эталонная модель TCP/IP, стр. 183, указано то же самое.

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

Внешние ссылки