Протокол связи — это система правил, которая позволяет двум или более объектам системы связи передавать информацию посредством любого изменения физической величины . Протокол определяет правила, синтаксис , семантику и синхронизацию связи , а также возможные методы устранения ошибок . Протоколы могут быть реализованы аппаратным , программным обеспечением или их комбинацией. [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]
Принципы системной инженерии были применены для создания набора общих принципов проектирования сетевых протоколов. Разработка сложных протоколов часто включает декомпозицию на более простые взаимодействующие протоколы. Такой набор взаимодействующих протоколов иногда называют семейством протоколов или набором протоколов [32] в рамках концептуальной структуры.
Коммуникационные системы работают одновременно. Важным аспектом параллельного программирования является синхронизация программного обеспечения для приема и передачи сообщений связи в правильной последовательности. Параллельное программирование традиционно было темой учебников по теории операционных систем. [50] Формальная проверка кажется необходимой, поскольку параллельные программы печально известны скрытыми и сложными ошибками, которые они содержат. [51] Математический подход к изучению параллелизма и коммуникации называется коммуникативными последовательными процессами (CSP). [52] Параллелизм также можно моделировать с использованием конечных автоматов , таких как автоматы Мили и Мура . Машины Мили и Мура используются в качестве инструментов проектирования в системах цифровой электроники, встречающихся в виде аппаратного обеспечения, используемого в телекоммуникациях или электронных устройствах в целом. [53] [ нужен лучший источник ]
В литературе представлены многочисленные аналогии между компьютерной коммуникацией и программированием. По аналогии, механизм передачи протокола можно сравнить с центральным процессором (ЦП). Фреймворк вводит правила, которые позволяют программисту разрабатывать взаимодействующие протоколы независимо друг от друга.
В современном дизайне протоколов протоколы располагаются по уровням, образуя стек протоколов. Многоуровневое представление — это принцип проектирования, который делит задачу разработки протокола на более мелкие этапы, каждый из которых выполняет определенную часть, взаимодействуя с другими частями протокола только небольшим количеством четко определенных способов. Многоуровневое распределение позволяет разрабатывать и тестировать части протокола без комбинаторного взрыва случаев, сохраняя каждую конструкцию относительно простой.
Протоколы связи, используемые в Интернете , предназначены для работы в разнообразных и сложных условиях. Интернет-протоколы разработаны с учетом простоты и модульности и вписываются в грубую иерархию функциональных уровней, определенных в наборе протоколов Интернета . [54] Первые два взаимодействующих протокола, протокол управления передачей (TCP) и интернет-протокол (IP), возникли в результате декомпозиции исходной программы управления передачей, монолитного протокола связи, в этот многоуровневый пакет связи.
Модель OSI была разработана на международном уровне на основе опыта работы с сетями, предшествовавшими Интернету, в качестве эталонной модели для общего общения с гораздо более строгими правилами взаимодействия протоколов и строгим многоуровневым разделением.
Обычно прикладное программное обеспечение построено на надежном уровне передачи данных. В основе этого транспортного уровня лежит механизм доставки и маршрутизации дейтаграмм, который обычно не требует установления соединения в Интернете. Ретрансляция пакетов между сетями происходит на другом уровне, который включает только технологии сетевых каналов, которые часто специфичны для определенных технологий физического уровня, таких как Ethernet . Уровни предоставляют возможности для обмена технологиями, когда это необходимо, например, протоколы часто объединяются в туннельную структуру для обеспечения соединения разнородных сетей. Например, IP может туннелироваться через сеть с асинхронным режимом передачи (ATM).
Уровни протоколов составляют основу проектирования протоколов. [31] Это позволяет разлагать отдельные сложные протоколы на более простые взаимодействующие протоколы. [54] Каждый уровень протокола решает отдельный класс проблем связи. Вместе слои составляют схему или модель слоев.
Вычисления имеют дело с алгоритмами и данными; Коммуникация включает протоколы и сообщения; Таким образом, аналогом диаграммы потока данных является своего рода диаграмма потока сообщений. [4] Для визуализации уровней протоколов и наборов протоколов на рисунке 3 показана диаграмма потоков сообщений в двух системах A и B и между ними. Обе системы A и B используют один и тот же набор протоколов. Вертикальные потоки (и протоколы) находятся внутри системы, а горизонтальные потоки сообщений (и протоколы) — между системами. Потоки сообщений регулируются правилами, а форматы данных определяются протоколами. Синие линии обозначают границы (горизонтальных) уровней протокола.
Программное обеспечение, поддерживающее протоколы, имеет многоуровневую организацию, и его взаимосвязь с уровнями протоколов показана на рисунке 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]
Урок, извлеченный из 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 службы различаются по номерам портов. Соответствие этим номерам портов является добровольным, поэтому в системах проверки контента термин « служба» строго относится к номерам портов, а термин « приложение» часто используется для обозначения протоколов, идентифицируемых с помощью проверочных сигнатур.
Как вспоминает Кан: ... Вклад Пола Бэрана ... Я также думаю, что Пол был почти полностью мотивирован голосовыми соображениями.
Если вы посмотрите на то, что он написал, он говорил о переключателях, которые представляли собой дешевую электронику.
Идея разместить в этих местах мощные компьютеры не совсем пришла ему в голову как экономически выгодная.
Так что идея компьютерных переключателей отсутствовала.
В то время не существовало самого понятия протоколов.
А идея межкомпьютерной связи на самом деле была второстепенной.
Была статья, написанная [Полом Бэраном] из Rand Corporation, которая, в некотором смысле, предвещала коммутацию пакетов для речевых сетей и голосовых сетей.
[Скантлбери сказал] Очевидно, что Дональд и Пол Бэран независимо пришли к похожей идее, хотя и с разными целями.
Пол за живучую голосовую/телексную сеть, наш за высокоскоростную компьютерную сеть.
Фактически, CYCLADES, в отличие от ARPANET, был специально разработан для облегчения межсетевого взаимодействия; например, он может обрабатывать различные форматы и различные уровни обслуживания.
Помимо сети NPL и ARPANET, важную роль в развитии компьютерных сетевых технологий сыграла также академическая и исследовательская экспериментальная сеть CYCLADES.
В начале 1970-х годов Пузен создал инновационную сеть передачи данных, которая связала места во Франции, Италии и Великобритании.
Ее простота и эффективность указали путь к сети, которая могла бы соединить не только десятки машин, но и миллионы из них.
Он захватил воображение доктора Серфа и доктора Кана, которые включили аспекты его конструкции в протоколы, которые сейчас поддерживают Интернет.
Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана;
Д. Дэвис и Л. Пузен, конструктивно прокомментировавшие вопросы фрагментации и учета;
и С. Крокер, комментировавшие создание и разрушение ассоциаций.
Эта базовая эталонная модель взаимодействия открытых систем основана на предположении, что соединение необходимо для передачи данных.