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

Типы сетевых протоколов

Рассмотрим несколько самых популярных сегодня протоколов, работающих на разных уровнях:

MAC

Уже известный вам Media Access Control (MAC) это низкоуровневый сетевой протокол. С ним, в той или иной мере приходится сталкиваться всем пользователям. Используется он для идентификации сетевых устройств.

IP

На следующем уровне после MAC располагается IP – Internet Protocol, имеющий две основные разновидности IPv4 и IPv6. Он назначает компьютерам уникальные IP-адреса, благодаря которым устройства могут себя обнаруживать в сети.

ICMP, TCP и UDP

Выше IP находятся такие протоколы:

  • ICMP (Internet control message protocol), отвечающий за обмен информацией. Не используется для передачи данных. Именно ICMP используется в известной вам команде ping.
  • TCP (Transmission control protocol). Этот сетевой протокол управляет передачей данных. TCP дает гарантия в том, что все переданные пакеты данных будут приняты правильно и ошибки будут полностью исключены.
  • UDP (user datagram protocol) похож на TCP, но работает быстрее, так как в нем данные при получении не проверяются. В некоторых случаях использование UDP бывает вполне достаточным.

HTTP

По своей распространенности в Интернет Hyper Text Transfer protocol находится на первом месте, ведь именно на его основе работают все сайты. С его помощью с локального компьютера можно открыть веб-сервис на удалённом сервере.

FTP

Как понятно из перевода названия, File Transfer Protocol служит для передачи файлов. Советуем не использовать его для передачи важных данных, так как в FTP не поддерживается необходимая безопасность.

SSH

Протокол SSH (Secure Shell) относится к уровню приложений. Создает защищенный канал для удаленного управления другой операционной системой. Поддерживает различные алгоритмы шифрования.

BIDIR PIM

Many-to-ManyПонятное дело, что инертный PIM SSM здесь совсем не подходит?Bidirectional PIM, BIDIR PIMИсточник1Источником2Источник1Источник2каждыйПолучательDF — Designated Forwarder

Если запрос PIM Join/Leave приходит на тот интерфейс, который в данном сегменте является DF, он передаётся в сторону RP по стандартным правилам.
Вот, например, R3. Если запросы пришли в DF интерфейсы, что помечены красным кругом, он их передаёт на RP (через R1 или R2, в зависимости от таблицы маршрутизации).

Если запрос PIM Join/Leave пришёл на не DF интерфейс, он будет проигнорирован.
Допустим, что клиент, находящийся между R1 и R3, решил подключиться и отправил IGMP Report. R1 получает его через интерфейс, где он выбран DF (помечен красным кругом), и мы возвращаемся к предыдущему сценарию. А R3 получает запрос на интерфейс, который не является DF. R3 видит, что тут он не лучший, и игнорирует запрос.

Если мультикастовый трафик пришёл на DF интерфейс, он будет отправлен в интерфейсы из списка OIL и в сторону RP.
Например, Источник1 начал передавать трафик

R4 получает его в свой DF интерфейс и передаёт его и в другой DF-интерфейс — в сторону клиента и в сторону RP, — это важно, потому что трафик должен попасть на RP и распространиться по всем получателям. Также поступает и R3 — одна копия в интерфейсы из списка OIL — то есть на R5, где он будет отброшен из-за проверки RPF, и другая — в сторону RP

Если мультикастовый трафик пришёл на не DF интерфейс, он должен быть отправлен в интерфейсы из списка OIL, но не будет отправлен в сторону RP.
К примеру, Источник2 начал вещать, трафик дошёл до RP и начал распространяться вниз по RPT. R3 получает трафик от R1, и он не передаст его на R2 — только вниз на R4 и на R5.

Протоколы для разных типов информации

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

Подобные стандарты прописаны и для разных способов сетевого обмена данными:

  • HTTP (Hyper Text Transfer Protocol) хорошо известен нам по веб-серфингу. Благодаря ему мы можем не просто просматривать сайт, но и активно использовать все представляемые им возможности (переход по ссылкам, просмотр видео, проходить аутентификацию при входе в личный кабинет).
  • POP3 (Post Office Protocol) и SMTP (Simple Mail Transfer Protocol) относятся к наиболее востребованным, поскольку первый отвечает за взаимодействие почтовых программ с серверами, а второй контролирует этот процесс на наличие ошибок.
  • FTP (File Transfer Protocol) обеспечивает взаимодействие в системе «клиент-сервер» и позволяет работать с двоичными и текстовыми файлами.
  • TELNET — правила взаимодействия двух устройств, при котором с первого осуществляется удаленное управление вторым (работа с ПО, администрирование).

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

Имеются и другие протоколы, работающие в узкоспециализированных сферах (например DTN, созданный NASA для космической связи.

Набор протоколов в OSI:

Пора рассказать на мой взгляд самое интересное, это распределение протоколов по уровням модели OSI, тут будут описаны самые основные протоколы, так как, их очень много.

1. Протоколы физического уровня модели OSI:

  • Ethernet — Протокол для работы кабеля Ethernet, или кабеля для интернета;
  • GSM — Протокол для работы со сотовой связи;
  • 802.11 — Протокол для работы Wi-Fi;
  • USB — Протокол для работы шины в компьютере или флешки;
  • IrDA — Протокол для работы с  инфракрасным портом;
  • Bluetooth — Протокол для работы с Bluetooth;

2. Протоколы канального уровня модели OSI:

  • Ethernet — Протокол самого кабеля интернет;
  • Frame Relay — Протокол для передачи сотовой связи;
  • PPP — Протокол передачи данных один на один, между двумя компьютерами;

3. Протоколы сетевого уровня модели OSI:

  • IPv4 — Протокол для работы IP адресов версии четыре;
  • IPv6 — Протокол для работы IP адресов версии шесть;
  • ICMP — Протокол для ошибок в сотовой связи;
  • RiP — Протокол позволяет маршрутизаторам быстро и динамически находить путь;

4. Протоколы транспортного уровня модели OSI:

  • TCP — Протокол который отправляет пакет проверяя, но медленно, используется для сайтов;
  • UDP — Протокол который отправляет пакет не проверяя, но быстро, используется в онлайн играх;

5. Протоколы сеансового уровня модели OSI:

  • PPTP — Протокол для туннельного соединена с компьютер на компьютер или VPN;
  • L2TP — Подобный протокол PPTP
  • SSH — Протокол позволяет производить удалённое управление операционной системой;

6. Протоколы представления уровня модели OSI:

  • SSL — Криптографический протокол для безопасного соединения;
  • XDR — Протокол позволяет организовать не зависящую от платформы передачу данных между компьютерами в гетерогенных сетях;

7. Протоколы прикладного уровня модели OSI:

  • HTTP — Протокол для передачи гипертекста или HTML;
  • FTP, TFTP, SFTP — Протоколы для передачи файлов;
  • TELNET — Протокол для уделённого управления другим компьютером;
  • DHCP — Протокол для автоматического получение IP адреса;
  • IRC — Протокол для обмена сообщениями в режиме реального времени;
  • SNMP — Протокол для управление устройствам в IP-ситах;
  • DNS — Протокол позволяющий получать информацию о доменах;
  • BitTorrent — Пиринговый (P2P) сетевой протокол для кооперативного обмена файлами через Интернет;
  • SMTP, POP3, IMAP4— Протоколы для отправки, доставки электронной почты;

SSM

ASM — Any Source MulticastSSM — Source Specific Multicast

  • Поиска RP (протоколы Bootstrap и Auto-RP),
  • Регистрации источника на мультикасте (а это лишнее время, двойное использование полосы пропускания и туннелирование)
  • Переключения на SPT.
  • Запрашивать подключение к просто группе, без указания источников. То есть работает как типичный ASM.
  • Запрашивать подключение к группе с определённым источником. Источников можно указать несколько — до каждого из них будет построено дерево.
  • Запрашивать подключение к группе и указать список источников, от которых клиент не хотел бы получать трафик

SSM MappingOne-to-Many

Протокол Ethernet POWERLINK компании B&R

Протокол Powerlink разработан австрийской компанией B&R в начале 2000-х. Это еще одна реализация протокола реального времени поверх стандарта Ethernet. Спецификация протокола доступна и распространяется свободно. 

В технологии Powerlink применяется механизм так называемого смешанного опроса, когда всё взаимодействие между устройствами делится на несколько фаз. Особо критичные данные передаются в изохронной фазе обмена, для которой настраивается требуемое время отклика, остальные данные, будут переданы по мере возможности в асинхронной фазе.

Изначально протокол был реализован поверх физического уровня 100Base-TX, но позже была разработана и гигабитная реализация.

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

Схематическое представление сети Ethernet POWERLINK с несколькими узлами.

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

Изохронная фаза выполняется, как уже было сказано, с настраиваемым временем цикла. В асинхронной фазе обмена используется стек протокола IP, контроллер запрашивает некритичные данные у всех узлов, которые посылают ответ по мере получения доступа к передаче в сеть. Соотношение времени между изохронной и асинхронной фазами можно настроить вручную.

Основные протоколы интернета

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

  • MAC или (Media Access Control) — это протокол низкого уровня, который используется для идентификации устройств в локальной сети. У каждого устройства, подключенного к сети есть уникальный MAC адрес, заданный производителем. В локальных сетях, а все данные выходят из локальной сети и попадают в локальную сеть перед тем, как попасть к получателю, используются физические MAC адреса для обозначения устройств. Это один из немногих протоколов уровня соединения, с которым довольно часто приходится сталкиваться.
  • IP ( Internet Protocol) — расположен уровнем выше, за MAC. Он отвечает за определение IP адресов, которые будут уникальными для каждого устройства и позволяют компьютерам находить друг друга в сети. Он относится к сетевому уровню модели TCP/IP. Сети могут быть связанны друг с другом в сложные структуры, с помощью этого протокола компьютеры могут определить несколько возможных путей к целевому устройству, причем во время работы эти пути могут меняться. Есть несколько реализаций протокола, но наиболее популярной на сегодняшний день является IPv4 и IPv6.
  • ICMP (Internet control message protocol) — используется для обмена сообщениями между устройствами. Это могут быть сообщения об ошибках или информационные сообщения, но он не предназначен для передачи данных. Такие пакеты используются в таких диагностических инструментах, как ping и traceroute. Этот протокол находится выше протокола IP;
  • TCP (Transmission control protocol) — это еще один основной сетевой протокол, который находится на том же уровне, что и ICMP. Его задача — управление передачей данных. Сети ненадежны. Из-за большого количества путей пакеты могут приходить не в том порядке или даже теряться. TCP гарантирует, что пакеты будут приняты в правильном порядке, а также позволяет исправить ошибки передачи пакетов. Информация приводится к правильному порядку, а уже затем передается приложению. Перед передачей данных создается соединение с помощью так называемого алгоритма тройного рукопожатия. Он предусматривает отправку запроса и подтверждение открытия соединения двумя компьютерами. Множество приложений используют TCP, это SSH, WWW, FTP и многие другие.
  • UDP (user datagram protocol) — это популярный протокол, похожий на TCP, который тоже работает на транспортном уровне. Отличие между ними в том, что здесь используется ненадежная передача данных. Данные не проверяются при получении, это может выглядеть плохой идеей, но во многих случаях этого вполне достаточно. Поскольку нужно отправлять меньше пакетов, UDP работает быстрее, чем TCP. Поскольку соединение устанавливать не нужно, то этот протокол может использоваться для отправки пакетов сразу на несколько машин или IP телефонии.
  • HTTP (hypertext transfer protocol) — это протокол уровня приложения, который лежит в основе работы всех сайтов интернета. HTTP позволяет запрашивать определенные ресурсы у удаленной системы, например, веб страницы, и файлы;
  • FTP (file transfer protocol) — это протокол передачи файлов. Он работает на уровне приложений и обеспечивает передачу файла от одного компьютера к другому. FTP — не безопасный, поэтому не рекомендуется его применять для личных данных;
  • DNS (domain name system) — протокол того же уровня, используемый для преобразования понятных и легко читаемых адресов в сложные ip адреса, которые трудно запомнить и наоборот. Благодаря ему мы можем получить доступ к сайту по его доменному имени;
  • SSH (secure shell) — протокол уровня приложений, реализованный для обеспечения удаленного управления системой по защищенному каналу. Многие дополнительные технологии используют этот протокол для своей работы.

Есть еще очень много других протоколов, но мы рассмотрели только сетевые протоколы, которые больше всего важны. Это даст вам общие понятия того, как работает сеть и интернет в целом.

Уровни сетей и модель OSI

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

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

Модель OSI

Так сложилось исторически, что когда дело доходит до уровней работы сетей, используется модель OSI или Open Systems Interconnect. Она выделяет семь уровней:

  • Уровень приложений — самый верхний уровень, представляет работу пользователя и приложений с сетью Пользователи просто передают данные и не задумываются о том, как они будут передаваться;
  • Уровень представления — данные преобразуются в более низкоуровневый формат, чтобы быть такими, какими их ожидают получить программы;
  • Уровень сессии — на этом уровне обрабатываются соединения между удаленным компьютерами, которые будут передавать данные;
  • Транспортный уровень — на этом уровне организовывается надежная передача данных между компьютерами, а также проверка получения обоими устройствами;
  • Сетевой уровень — используется для управления маршрутизацией данных в сети пока они не достигнут целевого узла. На этом уровне пакеты могут быть разбиты на более мелкие части, которые будут собраны получателем;
  • Уровень соединения — отвечает за способ установки соединения между компьютерами и поддержания его надежности с помощью существующих физических устройств и оборудования;
  • Физический уровень — отвечает за обработку данных физическими устройствами, включает в себя программное обеспечение, которое управляет соединением на физическом уровне, например, Ehternet или Wifi.

Как видите, перед тем, как данные попадут к аппаратному обеспечению им нужно пройти множество слоев.

Модель протоколов TCP/IP

Модель TCP/IP, еще известная как набор основных протоколов интернета, позволяет представить себе уровни работы сети более просто. Здесь есть только четыре уровня и они повторяют уровни OSI:

  • Приложения — в этой модели уровень приложений отвечает за соединение и передачу данными между пользователям. Приложения могут быть в удаленных системах, но они работают как будто бы находятся в локальной системе;
  • Транспорт — транспортный уровень отвечает за связь между процессами, здесь используются порты для определения какому приложению нужно передать данные и какой протокол использовать;
  • Интернет — на этом уровне данные передаются от узла к узлу по сети интернет. Здесь известны конечные точки соединения, но не реализуется непосредственная связь. Также на этом уровне определяются IP адреса;
  • Соединение — этот уровень реализует соединение на физическом уровне, что позволяет устройствам передавать между собой данные не зависимо от того, какие технологии используются.

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

Зачем сравнивать TCP или что с ним не так

  • packet loss — примерно 0,6% пакетов, которые мы отправляем, теряются по пути;
  • reordering — перестановка пакетов местами, в реальной жизни довольно редкое явление, но случается в 0,2% случаев;
  • jitter — когда пакеты отправляются равномерно, а приходят очередями с задержкой примерно в 50 мс.

Как вычислить RTT

RIPE Atlasбеспроводные сети популярны и нестабильны

  • Более 80% пользователей используют беспроводной интернет;
  • Параметры беспроводных сетей динамично меняются в зависимости, например, от того, что пользователь повернул за угол;
  • Беспроводные сети имеют высокие показатели packet loss, jitter, reordering;
  • Фиксированный ассиметричный канал, смена IP-адреса.

TCP в нестабильных сетях

меньше половины канала

  • Беспроводные мобильные сети победили и нестабильны.
  • TCP не до конца утилизирует канал в нестабильных сетях.
  • Потребление контента зависит от скорости интернета: чем выше скорость интернета, тем больше пользователи смотрят, а мы очень любим наших пользователей и хотим, чтобы они смотрели больше.

Реализация протокола FBUS в компании Fastwel

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

Существует две физические реализации FBUS. Одна из них — это шина, в которой протокол FBUS работает поверх стандарта RS485. Кроме этого есть реализация FBUS в промышленной сети Ethernet.

FBUS сложно назвать быстродействующим протоколом, время ответа сильно зависит от количества модулей ввода-вывода на шине и от параметров обмена, обычно оно колеблется в пределах 0,5—10 миллисекунд. Один подчиненный узел FBUS может содержать только 64 модуля ввода-вывода. Для полевой шины длина кабеля не может превышать 1 метр, поэтому о распределенных системах речь не идет. Вернее идет, но только при использовании промышленной сети FBUS поверх TCP/IP, что означает увеличение времени опроса в несколько раз. Для подключения модулей могут использоваться удлинители шины, что позволяет удобно расположить модули в шкафу автоматики.

Схема протокола

Взаимодействие «клиент-сервер» при FTP-соединении можно наглядно представить следующим образом:

Безопасный FTP

FTP изначально не задумывался как защищенный, поскольку предназначался для связи между несколькими военными объектами и учреждениями. Но с развитием и распространением интернета опасность несанкционированного доступа возросла во много раз. Возникла необходимость защиты серверов от различного рода атак. В мае 1999 авторы RFC 2577 свели уязвимости в следующий список проблем:

  • Скрытые атаки (bounce attacks)
  • Спуф-атаки (spoof attacks)
  • Атаки методом грубой силы (brute force attacks)
  • Перехват пакетов, сниффинг (packet capture, sniffing)
  • Захват портов (port stealing)

Обычный FTP не обладает возможностью передачи данных в зашифрованном виде, вследствие чего имена пользователей, пароли, команды и другая информация могут при желании легко и просто быть перехвачены злоумышленниками. Обычное решение этой проблемы — использовать «безопасные», TLS-защищённые версии уязвимых протокола (FTPS) или же другой, более защищённый протокол, вроде SFTP/SCP, предоставляемого с большинством реализаций протокола Secure Shell.

Протоколы уровня 7 (Прикладной уровень)

  • ADC — peer-to-peer-протокол обмена файлами
  • AFP, Apple Filing Protocol
  • BACnet, Building Automation and Control Network protocol
  • BitTorrent — peer-to-peer-протокол обмена файлами
  • BOOTP, Bootstrap Protocol
  • DIAMETER — протокол аутентификации, авторизации и работы с аккаунтами
  • DICOM содержит определение сетевого протокола
  • DICT — словарный протокол
  • DNS — система доменных имён
  • DHCP, Dynamic Host Configuration Protocol
  • ED2K — peer-to-peer-протокол обмена файлами
  • FTP — протокол передачи файлов
  • Finger — протокол, возвращающий информацию о пользователях на удалённом компьютере
  • Gnutella — peer-to-peer-протокол скачивания файлов
  • Gopher — иерархический протокол на основе гиперссылок
  • HTTP, Hypertext Transfer Protocol
  • IMAP, Internet Message Access Protocol
  • IRC — протокол для чата
  • ISUP, ISDN User Part
  • XMPP — протокол мгновенного обмена сообщениями
  • LDAP Lightweight Directory Access Protocol
  • MIME, Multipurpose Internet Mail Extensions
  • MSNP, Microsoft Notification Protocol (используется в Windows Live Messenger)
  • MAP, Mobile Application Part
  • NetBIOS — протокол общего пользования файлами и разрешения имен — основа обмена файлами в Windows.
  • NNTP — сетевой протокол передачи новостей
  • NTP — сетевой протокол времени
  • NTCIP, National Transportation Communications for Intelligent Transportation System Protocol
  • POP3 — почтовый протокол версии 3
  • RADIUS — протокол аутентификации, авторизации и работы с аккаунтами
  • Rlogin — протокол удаленного входа в UNIX
  • rsync — протокол передачи файлов для резервного копирования, копирования и зеркалирования
  • RTP, Real-time Transport Protocol
  • RTSP, Real-time Transport Streaming Protocol
  • SSH, Secure Shell
  • SISNAPI, Siebel Internet Session Network API
  • SIP, Session Initiation Protocol, сигнальный протокол
  • SMTP, Simple Mail Transfer Protocol
  • SNMP, Simple Network Management Protocol
  • SOAP, Simple Object Access Protocol
  • STUN, Session Traversal Utilities for NAT
  • TUP, Telephone User Part
  • Telnet — протокол удаленного доступа к терминалу
  • TCAP, Transaction Capabilities Application Part
  • TFTP, Trivial File Transfer Protocol, простой протокол передачи файлов
  • WebDAV, Web Distributed Authoring and Versioning
  • DSM CC Digital Storage Media Command and Control

FTPS

FTPS (FTP + SSL) – расширение стандартного протокола передачи файлов, добавляющее в его базовый функционал создание шифрованных сессий с помощью протокола SSL (Secure Sockets Layer — уровень защищенных сокетов). На сегодняшний день защита обеспечивается его более продвинутым аналогом TLS (Transport Layer Security — защита транспортного уровня).

SSL

Протокол SSL предложен корпорацией Netscape Communications в 1996 году с целью обеспечения безопасности и секретности интернет-соединений. Протокол поддерживает аутентификацию (установление подлинности) клиента и сервера, не зависит от приложений и прозрачен для протоколов HTTP, FTP и Telnet.

Протокол SSL Handshake состоит из двух этапов: установление подлинности сервера и необязательное установление подлинности клиента. На первом этапе сервер в ответ на запрос клиента посылает свой сертификат и параметры шифрования. Затем клиент генерирует мастер-ключ, зашифровывает его открытым ключом сервера и отсылает серверу. Сервер расшифровывает мастер-ключ своим частным ключом и подтверждает свою подлинность клиенту, возвращая ему сообщение, заверенное мастером-ключом клиента.

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

SSL поддерживает разнообразные криптографические алгоритмы. В ходе установления связи используется криптосистема открытого ключа RSA. После обмена ключами используется много разных шифров: RC2, RC4, IDEA, DES и TripleDES. Также используется MD5 — алгоритм создания дайджеста сообщений. Синтаксис сертификатов открытого ключа описан в X.509.

Одним из немаловажных преимуществ SSL, является его полная программно-платформенная независимость. Протокол разработан на принципах переносимости, и идеология его построения, не зависит, от тех приложений, в составе которых он используется

Помимо этого, важно и то, что поверх протокола SSL, могут прозрачно накладываться и другие протоколы; либо для еще большего увеличения степени защиты целевых информационных потоков, либо, для адаптации криптографических способностей SSL под какую-нибудь другую, вполне определенную задачу

SSL-подключение

Предоставляемый SSL безопасный канал обладает тремя основными свойствами:

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

Особенности FTPS

Существуют две реализации FTPS, использующие различные методы предоставления безопасности:

  • Неявный метод предполагает использование стандартного протокола SSL с установлением сессии перед отправкой данных, что, в свою очередь, нарушает совместимость с обычным FTP клиентами и серверами. Для обратной совместимости с клиентами, которые не поддерживают FTPS, для контрольного соединения используется TCP-порт 990, а для передачи данных — 989. Это позволяет сохранить стандартный порт 21 для протокола FTP. Данный метод признан устаревшим.
  • Явный – намного более удобен, так как использует команды стандартного FTP, но при ответе шифрует данные, что позволяет использовать одно и тоже управляющее соединение как для FTP, так и для FTPS. Клиент должен явно запросить защищенную передачу данных у сервера, а после утвердить способ шифрования. Если клиент не запросит защищенную передачу, FTPS сервер вправе как сохранить, так и закрыть незащищенное соединение. Механизм согласования идентификации и защиты данных был добавлен под RFC 2228 который включает в себя новую FTP команду AUTH. Хотя этот стандарт не определяет явно механизмы защиты, он определяет, что защищенное соединение должен инициировать клиент с помощью описанного выше алгоритма. Если защищенные соединения не поддерживаются сервером, должен быть возвращен код ошибки 504. FTPS клиенты могут получить информацию о поддерживаемых сервером протоколах защиты при помощи команды FEAT, тем не менее сервер не обязан разглашать то, какие уровни безопасности он поддерживает. Наиболее распространены FTPS команды AUTH TLS и AUTH SSL, обеспечивающие защиту TLS и SSL соответственно.

Протокол Ethernet/IP компании Rockwell Automation

Протокол EtherNet/IP разработан при активном участии американской компании Rockwell Automation в 2000 году. Он использует стек TCP и UDP IP, и расширяет его для применения в промышленной автоматизации. Вторая часть названия, вопреки расхожему мнению, означает не Internet Protocol, а Industrial Protocol. UDP IP использует коммуникационный стек протокола CIP (Common Interface Protocol), который также используется в сетях ControlNet / DeviceNet и реализуется поверх TCP/IP.

Спецификация EtherNet/IP является общедоступной и распространяется бесплатно. Топология сети Ethernet/IP может быть произвольной и включать в себя кольцо, звезду, дерево или шину.

В дополнение к стандартным функциям протоколов HTTP, FTP, SMTP, EtherNet/IP реализует передачу критичных ко времени доставки данных между опрашивающим контроллером и устройствами ввода/вывода. Передача некритичных ко времени данных обеспечивается пакетами TCP, а критичная ко времени доставка циклических данных управления идет по протоколу UDP. 

Для синхронизации времени в распределенных системах EtherNet/IP использует протокол CIPsync, который является расширением коммуникационного протокола CIP.

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

TCP vs self-made UDP

  • С перегрузками, когда пакетов очень много и некоторые из них дропаются из-за перегрузки каналов или оборудования.
  • Высокоскоростные с большими round-trip (например когда сервер располагается относительно далеко).
  • Странные — когда в сети вроде бы ничего не происходит, но пакеты все равно пропадают просто потому-что Wi-Fi точка доступа находится за стенкой.
  • Профиль Видео, когда вы подключаетесь и стримите тот или иной контент. Скорость соединения увеличивается, как на верхнем графике. Требования к этому протоколу: низкие задержки и адаптация битрейта.
  • Вариант просмотра Ленты: импульсная загрузка данных, фоновые запросы, промежутки простоя. Требования к этому протоколу: получаемые данные мультиплексируются и приоритизируются, приоритет пользовательского контента выше фоновых процессов, есть отмена загрузки.

Отличия HTTP 2.0

  • бинарный, сжатие заголовков;
  • мультиплексирование данных;
  • приоритизация;
  • возможна отмена загрузки;
  • server push

Высокоприоритетный контент загружается раньше.Server pushReset stream

  • Профилях сети: Wi-Fi, 3G, LTE.
  • Профилях потребления: cтриминг (видео), мультиплексирование и приоритизация с отменой загрузки (HTTP/2) для получения контента ленты. 

Размер буфера

  • пакеты 1 и 2 уже отправлены, для них получено подтверждение;
  • пакеты 3, 4, 5, 6 отправлены, но результат доставки неизвестен (on-the-fly packets);
  • остальные пакеты находятся в очереди.

Вывод:

Congestion control

  • Flow control — это некий механизм защиты от перегрузки. Получатель говорит, на какое количество данных у него реально есть место в буфере, чтобы он был готов их принять. Если передать сверх flow control или recv window, то эти пакеты просто будут выкинуты. Задача flow control — это back pressure от нагрузки, то есть просто кто-то не успевает вычитывать данные.
  • У congestion control совершенно другая задача. Механизмы схожие, но задача — спасти сеть от перегрузки.
  • Если TCP window = 1, то данные передаются как на схеме слева: дожидаемся acknowledgement, отправляем следующий пакет и т.д. 
  • Если TCP window = 4, то отправляем сразу пачку из четырех пакетов, дожидаемся acknowledgement и дальше работаем.
  • На верхней схеме сеть, в которой все хорошо. Пакеты отправляются с заданной частотой, с такой же частотой возвращаются подтверждения. 
  • Во второй строке начинается перегруз сети: пакеты идут чаще, acknowledgements приходят с задержкой. 
  • Данные копятся в буферах на маршрутизаторах и других устройствах и в какой-то момент начинают пропускать пакеты, acknowledgements на эти пакеты не приходят (нижняя схема).
  • Cubic — дефолтный Congestion Control с Linux 2.6. Именно он используется чаще всего и работает примитивно: потерял пакет — схлопнул окно.
  • BBR — более сложный Congestion Control, который придумали в Google в 2016 году. Учитывает размер буфера.

BBR Congestion Control

  • BBR понимает, что идет переполнение буфера, и пытается схлопнуть окно, уменьшить нагрузку на маршрутизатор. 
  • Cubic дожидается потери пакета и после этого схлопывает окно.

jitterHighLoad++

Какой Congestion control выбрать

Выводы про congestion control:

  • Для видео всегда хорош BBR. 
  • В остальных случаях, если мы используем свой UDP-протокол, можно взять congestion control с собой.
  • С точки зрения TCP можно использовать только congestion control, который есть в ядре. Если хотите реализовать свой congestion control в ядро, нужно обязательно соответствовать спецификации TCP. Невозможно раздуть acknowledgement, сделать изменения, потому что просто их нет на клиенте.

Выводы

  • Как реально работает сеть, и что TCP можно повторить поверх UDP и сделать лучше. 
  • Что TCP не так плох, если его правильно настроить, но он реально сдался и больше уже почти не развивается.
  • Не верьте хейтерам UDP, которые говорят, что в user space работать не будет. Все эти проблемы можно решить. Пробуйте — это ближайшее будущее.
  • Если не верите, то сеть можно и нужно трогать руками. Я показывал, как почти все можно проверить.

Настраивайте протокол (TCP, UDP — неважно) под ситуацию (профиль сети + профиль нагрузки).
Используйте рецепты TCP, которые я вам рассказал: TFO, send/recv buffer, TLS1.3, CC… 
Делайте свои UDP-протоколы, если есть ресурсы. 
Если сделали свой UDP, проверьте UDP check list, что вы сделали все, что надо. Забудете какую-нибудь ерунду типа pacing, не будет работать.

Полезные ссылки

  • Миллион видеозвонков в сутки или «Позвони маме!».
  • Пишем свой протокол поверх UDP.
  • Подкаст про сетевую оптимизацию.
  • Увеличение скорости передачи данных в плохих сетях.