✖


Jump to content

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

(Перенаправлено из двоичного протокола )

Протокол связи — это система правил, которая позволяет двум или более объектам системы связи передавать информацию посредством любого изменения физической величины . Протокол определяет правила, синтаксис , семантику и синхронизацию связи , а также возможные методы устранения ошибок . Протоколы могут быть реализованы аппаратным , программным обеспечением или их комбинацией. [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] Производители компьютеров разработали собственные протоколы , такие как Systems Network Architecture от Digital Equipment Corporation (SNA) от IBM, 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 ( протокол передачи файлов ), 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]
Потеря информации – таймауты и повторные попытки
Пакеты могут быть потеряны в сети или задержаны при передаче. Чтобы справиться с этим, в соответствии с некоторыми протоколами отправитель может ожидать подтверждения правильного приема от получателя в течение определенного периода времени. Таким образом, по таймаутам отправителю может потребоваться повторная передача информации. [а] В случае необратимого разрыва связи повторная передача не имеет эффекта, поэтому количество повторных передач ограничено. Превышение лимита повторных попыток считается ошибкой. [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.

Чтобы отправить сообщение в систему А, программный модуль верхнего уровня взаимодействует с модулем, находящимся непосредственно под ним, и передает сообщение для инкапсуляции. Нижний модуль заполняет данные заголовка в соответствии с протоколом, который он реализует, и взаимодействует с нижним модулем, который отправляет сообщение по каналу связи нижнему модулю системы 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

[ редактировать ]
Модель 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] Процесс стандартизации описывается РФК   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 , Хилпиш, Роберт Э.; Дачшер, Роб и Сил, Марк и др., «Протокол беспроводной связи», опубликовано 5 мая 2009 г., передано Starkey Laboratories Inc. и Oticon AS.  
  2. ^ Протокол , Британская энциклопедия , заархивировано из оригинала 12 сентября 2012 года , получено 24 сентября 2012 года.
  3. ^ Jump up to: а б Комер 2000, разд. 11.2 – Необходимость использования нескольких протоколов, с. 177: «Они (протоколы) предназначены для общения то же самое, что языки программирования для вычислений».
  4. ^ Jump up to: а б с Комер 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. ^ Уолдроп, М. Митчелл (2018). Машина мечты . Полоса Пресс. п. 286. ИСБН  978-1-953953-36-0 . Бэран уделял больше внимания цифровой голосовой связи, чем компьютерной связи.
  9. ^ Кляйнрок, Л. (1978). «Принципы и уроки пакетной связи» . Труды IEEE . 66 (11): 1320–1329. дои : 10.1109/PROC.1978.11143 . ISSN   0018-9219 . Пол Бэран... сосредоточился на процедурах маршрутизации и на живучести распределенных систем связи во враждебной среде, но не сосредоточился на необходимости совместного использования ресурсов в той форме, в какой мы ее сейчас понимаем; действительно, концепция программного переключателя не присутствовала в его работе.
  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. ^ Jump up to: а б Марсден 1986, Раздел 6.1 – Зачем нужны стандарты?, с. 64-65 использует BSC в качестве примера, чтобы показать необходимость как в стандартных протоколах, так и в стандартной структуре.
  30. ^ Приход 2000, разд. 11.2 – Необходимость использования нескольких протоколов, с. 177, объясняет это, проводя аналогии между компьютерной коммуникацией и языками программирования.
  31. ^ Jump up to: а б Секта. 11.10 – Недостаток многослойности, с. 192, говорится: многоуровневость формирует основу для разработки протокола.
  32. ^ Jump up to: а б Комер 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. ^ Jump up to: а б Комер 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. ^ Ласкано, Дж. Э.; Клайд, С. (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 - Сеансовый уровень, стр. 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. ^ Jump up to: а б Trammell & Kuehlewind 2019 , с. 2.
  90. ^ Jump up to: а б Trammell & Kuehlewind 2019 , с. 3.
  91. ^ Trammell & Kuehlewind 2019 , стр. 4.
  92. ^ Jump up to: а б Fairhurst & Perkins 2021 , 7. Выводы.
  93. ^ Trammell & Kuehlewind 2019 , стр. 5.
  94. ^ Trammell & Kuehlewind 2019 , стр. 6.
  95. ^ Trammell & Kuehlewind 2019 , стр. 7-8.
  96. ^ Фаррелл и Чофениг 2014 , с. 2.
  97. ^ Jump up to: а б Фаррелл и Чофениг 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, указано то же самое.

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

[ редактировать ]
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Communication_protocol&oldid=1238634712#Binary"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 6af86c6b266a546c3b6f2a9dd43a6d02__1722797700
URL1:https://arc.ask3.ru/arc/aa/6a/02/6af86c6b266a546c3b6f2a9dd43a6d02.html
Заголовок, (Title) документа по адресу, URL1:
Communication protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)