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

Первое упоминание термина «протокол» в современном контексте обмена данными встречается в апреле 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 — возникли как результат декомпозиции монолитной 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].

Важной особенностью, выявленной на опыте 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 рекомендует все сигналы с линии делать преднамеренными, контролируемыми сторонами соединения, аутентифицированными и ограниченными по объёму и кругу получателей.

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

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

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

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

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