Материал из РУВИКИ — свободной энциклопедии

Протокол передачи данных

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

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

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

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

Коммуницирующие системы

[править | править код]

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

Первое упоминание термина «протокол» в современном контексте обмена данными встречается в апреле 1967 года в меморандуме «A Protocol for Use in the NPL Data Communications Network». Под руководством Дональда Дэвиса, пионера пакетной коммутации в Национальной физической лаборатории (Великобритания), этот документ написали Роджер Скэнтлбери и Кит Бартлетт для NPL-сети.[5][6][7][8][9]

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

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

Боб Меткалф и команда Xerox PARC описали концепцию Ethernet и PUP[17].

Исследования Кана и Винта Серфа в начале 1970-х годов привели к созданию TCP[18]. Спецификация была подготовлена Серфом, Йогеном Далалом и Карлом Саншайном в декабре 1974 года как монолитный протокол.

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

ПО для TCP было переработано в виде ступенчатого стека протоколов под названием TCP/IP. Он был внедрён на SATNET в 1982 году и в ARPANET в январе 1983 года. К 1989 году был разработан полный набор протоколов Интернета, зафиксированный в и[23].

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

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

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

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

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

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

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

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

Типы

[править | править код]

Существует два типа протоколов передачи данных по способу представления передаваемого содержимого: текстовые и бинарные.

Текстовые протоколы[править | править код]

Текстовый протокол (англ. text-based protocol) представляет данные в читаемом человеком формате, часто в тексте, закодированном в ASCII, UTF-8 или структурированных текстовых форматах, таких как Intel Hex, XML, JSON.

Возможность чтения человеком контрастирует с бинарными протоколами, обладающими преимуществами при обработке машиной (простота разбора, эффективное использование пропускной способности).

Приложения сети используют различные методы инкапсуляции данных. В интернет-протоколах распространён текстовый формат, где запросы и ответы передаются строками ASCII, заканчивающимися переводом строки. Примеры протоколов — File Transfer Protocol, Simple Mail Transfer Protocol, ранние версии Hypertext Transfer Protocol, finger[34].

Текстовые протоколы удобны для анализа и отладки, особенно при проектировании новых протоколов.

Бинарные протоколы[править | править код]

Бинарный протокол (англ. binary protocol) использует все значения байт, в отличие от текстовых протоколов, использующих коды читаемых символов ASCII. Бинарные протоколы рассчитаны на обработку машиной, обладают компактностью, что ускоряет передачу и интерпретацию[35].

Бинарные протоколы используются в стандартах EbXML, HTTP/2, HTTP/3, EDOC[36]. Интерфейс в UML[37] также может рассматриваться как бинарный протокол.

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

[править | править код]

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

В общем случае протокол должен описывать:[38]

Форматы данных для обмена
Цифровые сообщения передаются в виде битовых строк, делящихся на поля — заголовок и полезная нагрузка. Сообщения длиннее MTU дробятся на фрагменты[39].
Форматы адресации
Для указания отправителя и получателя используются адреса, передаваемые в заголовке пакета. Правила смысла адресов образуют схему адресации[40].
Маппинг адресов
Иногда требуется проецировать один тип адреса на другой (например, IP в MAC-адрес) — map адресов[41].
Маршрутизация
При отсутствии прямого соединения сообщения пересылаются через промежуточные системы (роутеры). Соединение через роутеры — это межсетевое взаимодействие.
Обнаружение ошибок передачи
Для сетей, где возможна порча пакетов. CRC добавляется к пакету; несоответствие приводит к отклонению пакета[42].
Квитирование
Подтверждение приёма пакетов необходимо для соединений; отправляется от получателя к отправителю[43].
Потери информации — таймауты и повторная передача
Для устранения потерь данных отправитель по истечении таймаута перезапускает передачу. Лимит числа попыток ограничен[44].
Направление передачи информации
Необходимо учитывать односторонность/двунаправленность (half-duplex, shared medium), возможные конфликты (collisions)[45].
Управление последовательностью
Для восстановления порядка пакетов используют метки последовательности[46].
Управление потоком
Для согласования скоростей передачи/приёма[47].
Очереди сообщений
Процессы используют FIFO-очереди для обработки сообщений в порядке отправки.

Проектирование протоколов

[править | править код]

Современное проектирование протоколов основано на принципах системной инженерии. Для сложных протоколов часто используется декомпозиция на более простые, взаимодействующие между собой протоколы — семейство (набор) протоколов.

Коммуницирующие системы работают параллельно, что требует синхронизации последовательности сообщений. Классическая задача — конкурентное программирование, где для описания коммуникаций применяются методы формальной верификации[48]. Один из формальных методов — CSP[49]. Также применяют конечные автоматы, например автоматы Мили и Мура[50].

Уровневая организация[править | править код]

Стек протоколов TCP/IP и его соотношение с часто используемыми протоколами

В современной практике протоколы проектируются как уровневые стеки. Каждый уровень решает определённую задачу, взаимодействуя с соседними уровнями строго по регламенту. Это позволяет делать отдельные элементы относительно простыми и независимыми.

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

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

Обычно прикладное ПО строится поверх надёжного транспортного уровня; под ним — датаграммная доставка и маршрутизация, ещё ниже — сетевые интерфейсы, часто специфичные для физической среды (например, Ethernet). Для соединения разнородных сетей протоколы могут «инкапсулироваться» друг в друга (туннелирование).

Уровневая структура протокола[править | править код]

Потоки сообщений с использованием стека протоколов. Чёрные петли — реальные передачи; красные — логические взаимодействия между уровнями, опосредованные нижележащими.

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

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

Типовые задачи при проектировании протоколов можно решать с помощью шаблонов проектирования.[51][52][53][54][55]

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

Часто используются формальные методы описания синтаксиса коммуникаций, например, ASN.1 (стандарт ISO) и расширенная форма Бэкуса — Наура (стандарт IETF).

Для формального описания поведения протоколов применяются модели конечных автоматов[56][57] и взаимодействующих автоматов[58].

Разработка протоколов и стандартизация

[править | править код]

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

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

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

Ранний протокол BSC (Binary Synchronous Communication, IBM) хорошо иллюстрирует проблемы: отсутствие согласованного стандарта привело к появлению десятков несовместимых версий, мешающих совместимости устройств разных производителей[29]. В других случаях протоколы становятся де-факто стандартами, особенно на формирующихся или монополизированных рынках.

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

К основным международным организациям относятся ISO, ITU, IEEE, IETF. IETF поддерживает протоколы Интернета, IEEE отвечает за многие программные и аппаратные протоколы. ITU объединяет специалистов по электросвязи для создания стандартов публичных телефонных сетей и радиосвязи. Для морской электроники применяются стандарты NMEA. W3C разрабатывает стандарты для web-технологий.

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

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

В ISO он стартует с рабочей группы, обсуждающей черновики, затем готовится проект стандарта, при необходимости дорабатывается и утверждается как международный стандарт[60].

OSI и уровни стандартизации[править | править код]

Важной особенностью, выявленной на опыте ARPANET, является необходимость общей структурированной схемы для стандартизации протоколов, чтобы устранить дублирование функций и чётко разделить ответственности по слоям[61]. Так появилась модель OSI, которая обеспечивает основу для разработки стандартных протоколов и сервисов по уровням[62].

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

Слои OSI (сверху вниз):

  • Прикладной уровень — идентификация партнёров, проверка полномочий, аутентификация, договорённость о конфиденциальности, ответственность за обработку ошибок и др[64].
  • Представительный уровень — преобразования синтаксиса, сжатие, шифрование[65].
  • Сеансовый уровень — установление/разрыв сеансов, управление обменом, синхронизация[66].
  • Транспортный уровень — надёжная передача данных, мультиплексирование соединений[67].
  • Сетевой уровень — установка и поддержка маршрутов, качество обслуживания, контроль перегрузок[68].
  • Канальный уровень — управление рамками, обнаружение/исправление ошибок передачи[69].
  • Физический уровень — электрические характеристики, способы передачи, установка/разрыв соединений[70].

В отличие от TCP/IP, традиционно предполагающего безсоединительные сети, OSI рассчитана на соединительные.

Образ протокола в среде передачи

[править | править код]

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

Если часть wire image не защищена криптографически, содержимое может быть изменено промежуточными устройствами (middleboxes), влияя на работу протокола. Даже если данные аутентифицированы, но не зашифрованы, прокси могут их интерпретировать и вмешиваться, например, дропать пакеты с определёнными флагами. Современная инженерия wire image заключается в том, чтобы намеренно шифровать всё, что не должно быть доступно узлам сети, и оставлять видимыми только сигналы, предназначенные для сети. Если же сигналы разъединяются с внутренней логикой протокола, они теряют достоверность.

Организация IETF с 2014 года считает массовое наблюдение за метаданными протоколов атакой и разрабатывает протоколы с прицелом на минимизацию влияния wire image на приватность. Internet Architecture Board рекомендует все сигналы с линии делать преднамеренными, контролируемыми сторонами соединения, аутентифицированными и ограниченными по объёму и кругу получателей.

Окостенение протоколов (ossification)

[править | править код]

Окостенение протокола (англ. protocol ossification) — потеря гибкости, расширяемости и эволюционной способности сетевых протоколов. Это в первую очередь вызвано влиянием middlebox-устройств, строго интерпретирующих wire image протокола и препятствующих прохождению новых типов сообщений; вторично — негибкостью конечных устройств[71].

Окостенение становится препятствием для внедрения новых протоколов и расширений — приходится эмулировать wire image известных протоколов или инкапсулировать новый протокол «поверх» старого. Из-за этого для Интернета фактически доступны только TCP и UDP, причём сам TCP тоже в значительной степени окостенел[72].

Противодействие окостенению включает расширение метаданных, активное применение расширений, шифрование служебных данных. Протокол QUIC стал первым транспортным IETF-протоколом, спроектированным с учётом антиокостенения.

Классификация протоколов

[править | править код]

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

Уровневая схема (модель), комбинирующая область и функцию, — интернет-модель (TCP/IP) и модель OSI. В конфигурации сетевого оборудования термин протокол обычно соотносится с транспортным уровнем, сервис — с портами в TCP/UDP, а приложение — с анализируемыми на уровне пакета протоколами.

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ Hilpisch, Robert E.; Rob Duchscher & Mark Seel et al., "Wireless communication protocol", US 7529565, published 2009-05-05
  2. ↑ Protocol. Encyclopædia Britannica. Дата обращения: 24 сентября 2022. Архивировано 12 сентября 2012 года.
  3. ↑ 1 2 Comer 2000, Sect. 11.2 — The Need For Multiple Protocols, с. 177: «Они (протоколы) для коммуникаций то же, что языки программирования для вычислений»
  4. ↑ 1 2 Comer 2000, Sect. 1.3 — Internet Services, с. 3: «Протоколы для коммуникаций то же, что алгоритмы для вычислений»
  5. ↑ Naughton, John. A Brief History of the Future : [англ.]. — Orion, 2015-09-24. — ISBN 978-1-4746-0277-8.
  6. ↑ Campbell-Kelly, Martin (1987-07). “Data Communications at the National Physical Laboratory (1965-1975)”. IEEE Annals of the History of Computing. 9 (3): 221—247. DOI:10.1109/MAHC.1987.10023. Проверьте дату в |date= (справка на английском)
  7. ↑ Pelkey, James L. 6.1 The Communications Subnet: BBN 1969 // Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968–1988.
  8. ↑ Waldrop, M. Mitchell. The Dream Machine : [англ.]. — Stripe Press, 2018. — P. 286. — ISBN 978-1-953953-36-0.
  9. ↑ Kleinrock, L. (1978). “Principles and lessons in packet communications”. Proceedings of the IEEE. 66 (11): 1320—1329. DOI:10.1109/PROC.1978.11143.
  10. ↑ Interface Message Processor: Specifications for the Interconnection of a Host and an IMP, Bolt Beranek and Newman (BBN), Report No. 1822, <http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf>. 
  11. ↑ BOOKS, HIGH DEFINITION. UGC -NET/JRF/SET PTP & Guide Teaching and Research Aptitude: UGC -NET By HD : [англ.]. — High Definition Books.
  12. ↑ NCP – Network Control Program. Living Internet. Дата обращения: 8 октября 2022. Архивировано 7 августа 2022 года.
  13. ↑ Bennett, Richard Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate 7, 11. Information Technology and Innovation Foundation (сентябрь 2009). Дата обращения: 11 сентября 2017.
  14. ↑ Abbate, Janet. Inventing the Internet : [англ.]. — MIT Press, 2000. — P. 124–127. — ISBN 978-0-262-51115-5.
  15. ↑ Kim, Byung-Keun. Internationalising the Internet the Co-evolution of Influence and Technology. — Edward Elgar, 2005. — P. 51–55. — ISBN 1845426754.
  16. ↑ The internet's fifth man (30 ноября 2013). Дата обращения: 22 апреля 2020.
  17. ↑ Moschovitis, Christos J. P. History of the Internet: A Chronology, 1843 to the Present. — ABC-CLIO, 1999. — ISBN 978-1-57607-118-2.
  18. ↑ Cerf, V.; Kahn, R. (1974-05). “A Protocol for Packet Network Intercommunication”. IEEE Transactions on Communications. 22 (5): 637—648. DOI:10.1109/TCOM.1974.1092259. Проверьте дату в |date= (справка на английском)
  19. ↑ McKenzie, Alexander (2011-01). “INWG and the Conception of the Internet: An Eyewitness Account”. IEEE Annals of the History of Computing. 33 (1): 66—71. DOI:10.1109/MAHC.2011.9. Проверьте дату в |date= (справка на английском)
  20. ↑ Schwartz, Mischa (2010-11). “X.25 Virtual Circuits - TRANSPAC IN France - Pre-Internet Data Networking [History of communications]”. IEEE Communications Magazine. 48 (11): 40—46. DOI:10.1109/MCOM.2010.5621965. Проверьте дату в |date= (справка на английском)
  21. ↑ Rybczynski, Tony (2009-12). “Commercialization of packet switching (1975-1985): A Canadian perspective [History of Communications]”. IEEE Communications Magazine. 47 (12): 26—31. DOI:10.1109/MCOM.2009.5350364. Проверьте дату в |date= (справка на английском)
  22. ↑ The "Hidden" Prehistory of European Research Networking : [англ.]. — Trafford Publishing. — P. 354. — ISBN 978-1-4669-3935-6.
  23. ↑ TCP/IP Internet Protocol. Living Internet. Дата обращения: 8 октября 2022. Архивировано 1 сентября 2022 года.
  24. ↑ Andrew L. Russell (2013-07-30). “OSI: The Internet That Wasn't”. IEEE Spectrum. 50 (8).
  25. ↑ Russell, Andrew L. 'Rough Consensus and Running Code' and the Internet-OSI Standards War. IEEE Annals of the History of Computing. Дата обращения: 23 февраля 2020. Архивировано 17 ноября 2019 года.
  26. ↑ Standards Wars (2006). Дата обращения: 23 февраля 2020. Архивировано 24 февраля 2021 года.
  27. ↑ Ben-Ari 1982, глава 2 — Абстракция конкурентного программирования, с. 18-19.
  28. ↑ Ben-Ari 1982, раздел 2.7 — Краткое изложение, с. 27.
  29. ↑ 1 2 Marsden 1986, Section 6.1, с. 64-65.
  30. ↑ 1 2 3 Comer 2000, Sect. 11.2.
  31. ↑ 1 2 Sect. 11.10 — The Disadvantage Of Layering, с. 192.
  32. ↑ Comer 2000, Sect. 11.3.
  33. ↑ Comer 2000, Sect. 11.11.
  34. ↑ Kirch, Olaf Text Based Protocols (16 января 2002). Дата обращения: 21 октября 2014. Архивировано 30 мая 2010 года.
  35. ↑ Kirch, Olaf Binary Representation Protocols (16 января 2002). Дата обращения: 4 мая 2006. Архивировано 30 мая 2010 года.
  36. ↑ Kirch, Olaf Binary Representation Protocols (16 января 2002). Дата обращения: 4 мая 2006. Архивировано 5 марта 2006 года.
  37. ↑ Welcome To UML Web Site! Uml.org. Дата обращения: 15 января 2017. Архивировано 30 сентября 2019 года.
  38. ↑ Marsden 1986, глава 3, с. 26-42.
  39. ↑ Comer 2000, Sect. 7.7.4.
  40. ↑ Comer 2000, Chapter 4, с. 64-67;71.
  41. ↑ Marsden 1986, Section 14.3, с. 187.
  42. ↑ Marsden 1986, Section 3.2, с. 27.
  43. ↑ Marsden 1986, Section 3.3, с. 28-33.
  44. ↑ Marsden 1986, Section 3.4, с. 33-34.
  45. ↑ Marsden 1986, Section 3.5, с. 34-35.
  46. ↑ Marsden 1986, Section 3.6, с. 35-36.
  47. ↑ Marsden 1986, Section 3.7, с. 36-38.
  48. ↑ Ben-Ari 1982, предисловие, с. xiii-xiv.
  49. ↑ Hoare 1985, глава 4, с. 133.
  50. ↑ S. Srinivasan. Digital Circuits and Systems. Архивировано 27 декабря 2009 года.
  51. ↑ Lascano, Jorge Edison; Clyde, Stephen; Raza, Ali Communication-protocol Design Patterns (CommDP). Дата обращения: 17 марта 2017. Архивировано 18 марта 2017 года.
  52. ↑ Lascano, J. E.; Clyde, S. (2016). A Pattern Language for Application-level Communication Protocols. ICSEA 2016. pp. 22—30.
  53. ↑ Daigneau, R. Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services. — Addison-Wesley Professional, 2011.
  54. ↑ Fowler, M. Patterns of Enterprise Application Architecture. — Addison-Wesley Professional, 2002. — ISBN 0-321-12742-0.
  55. ↑ F. Buschmann, K. Henney, D. C. Schmidt, Pattern-Oriented Software Architecture, Vol. 4, Wiley, 2007.
  56. ↑ Bochmann, G. (1978). “Finite state description of communication protocols”. Computer Networks. 2 (4—5): 361—372. DOI:10.1016/0376-5075(78)90015-6.
  57. ↑ Comer 2000, Глоссарий, с. 704.
  58. ↑ Brand, Daniel; Zafiropulo, Pitro (1983-04). “On Communicating Finite-State Machines”. Journal of the ACM. 30 (2): 323—342. DOI:10.1145/322374.322380. Проверьте дату в |date= (справка на английском)
  59. ↑ Marsden 1986, Section 6.3, с. 66-67.
  60. ↑ Marsden 1986, Section 6.4, с. 67.
  61. ↑ Marsden 1986, Section 6.1, с. 65.
  62. ↑ Marsden 1986, Section 14.1, с. 181.
  63. ↑ Marsden 1986, Section 14.3, с. 183—185.
  64. ↑ Marsden 1986, Section 14.4, с. 188.
  65. ↑ Marsden 1986, Section 14.5, с. 189.
  66. ↑ Marsden 1986, Section 14.6, с. 190.
  67. ↑ Marsden 1986, Section 14.7, с. 191.
  68. ↑ Marsden 1986, Section 14.8, с. 192.
  69. ↑ Marsden 1986, Section 14.9, с. 194.
  70. ↑ Marsden 1986, Section 14.10, с. 195.
  71. ↑ Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna (2017). “De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives”. IEEE Communications Surveys & Tutorials. 19: 619—639. DOI:10.1109/COMST.2016.2626780. HDL:2164/8317.
  72. ↑ McQuistin, Stephen; Perkins, Colin; Fayed, Marwan (2016-07). Implementing Real-Time Transport Services over an Ossified Network. 2016 Applied Networking Research Workshop. DOI:10.1145/2959424.2959443. HDL:1893/26111. Проверьте дату в |date= (справка на английском)

Литература

[править | править код]
  • Radia Perlman. Interconnections: Bridges, Routers, Switches, and Internetworking Protocols : [англ.]. — 2nd. — Addison-Wesley, 1999. — ISBN 0-201-63448-1.
  • Gerard J. Holzmann. Design and Validation of Computer Protocols : [англ.]. — Prentice Hall, 1991. — ISBN 0-13-539925-4.
  • Douglas E. Comer. Internetworking with TCP/IP - Principles, Protocols and Architecture : [англ.]. — 4th. — Prentice Hall, 2000. — ISBN 0-13-018380-6.
  • M. Ben-Ari. Principles of concurrent programming : [англ.]. — Prentice Hall International, 1982. — ISBN 0-13-701078-8.
  • C.A.R. Hoare. Communicating sequential processes : [англ.]. — Prentice Hall International, 1985. — ISBN 0-13-153271-5.
  • R.D. Tennent. Principles of programming languages : [англ.]. — Prentice Hall International, 1981. — ISBN 0-13-709873-1.
  • Brian W Marsden. Communication network protocols : [англ.]. — Chartwell Bratt, 1986. — ISBN 0-86238-106-1.
  • Andrew S. Tanenbaum. Structured computer organization : [англ.]. — Prentice Hall International, 1984. — ISBN 0-13-854605-3.

Ссылки

[править | править код]
Источник — https://ru.ruwiki.ru/w/index.php?title=Протокол_передачи_данных&oldid=1217478967