Проверка надёжности UDP-протокола | OTUS
⚡ Открываем подписку на курсы!
Проходите параллельно 3 онлайн-курса в месяц по цене одного.
Подробнее

Курсы

Программирование
Flutter Mobile Developer Подготовка к сертификации Oracle Java Programmer (OCAJP)
-8%
Алгоритмы и структуры данных
-12%
Web-разработчик на Python
-11%
Архитектура и шаблоны проектирования
-14%
JavaScript Developer. Basic Супер-интенсив «СУБД в высоконагруженных системах»
-18%
iOS-разработчик. Базовый курс
-23%
Разработчик на Spring Framework
-23%
Python Developer. Basic
-16%
C# ASP.NET Core разработчик
-18%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
JavaScript Developer. Professional
-9%
Android Developer. Basic
-10%
Java Developer. Professional Разработчик C# AWS для разработчиков Highload Architect Reverse-Engineering. Professional CI/CD Vue.js разработчик Agile Project Manager Нереляционные базы данных Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Advanced Fullstack JavaScript developer
Инфраструктура
PostgreSQL
-10%
IoT-разработчик
-12%
Administrator Linux. Professional
-11%
Базы данных
-19%
Administrator Linux.Basic
-18%
Супер-интенсив «СУБД в высоконагруженных системах»
-18%
Супер-интенсив "SQL для анализа данных"
-16%
Software Architect
-12%
Сетевой инженер AWS для разработчиков Highload Architect Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Проверка надёжности UDP-протокола

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — один из важнейших элементов набора сетевых интернет-протоколов. Термин UDP подразумевает передачу данных без установления соединения (мы говорим о соединении, не имеющем подтверждения связи). В результате нет никаких гарантий по поводу доставки либо порядка получения пакетов. Но что же это значит на практике?

Автор этой статьи провёл эксперимент, основной целью которого было выяснение степени надёжности вышеописанного способа передачи данных. Было создано 5 VPS для отправки друг другу нескольких UDP-пакетов на протяжении семи часов. Трафик был невелик, а каждый сервер с периодом от 9 до 11 сек. рандомно выбирал получателя, посылая 5-10 пакетов, размер которых составлял 16-1016 байт.

Два из пяти серверов находились в одном ЦОД в Нью-Джерси (NJ 1 и NJ 2), один находился в Лос-Анджелесе (LA), один в Амстердаме (NLD) и ещё один в Токио (JPN).

Проверка надёжности

При первоочередной проверке надёжности предполагалось, что показатели частоты доставки будут находиться в пределах 25-75 %.

Посмотрим на таблицу переданных/полученных пакетов:

1-20219-eeb91b.png

И на их процентное соотношение:

1-20219-1e3592.png

Но результаты превзошли его ожидания. Предполагалось, что во время передачи данных из Амстердама в Японию и обратно потери будут больше нормы, однако потерь не было вообще. Зато данные, которые посылались из Лос-Анджелеса в Нью-Джерси, передавались как бы с трудом. Существует ли тут закономерность?

Может, проблема в размере пакета данных? Он состоял из 16-байтного заголовка и полезных данных размером 0-1000 байт. Давайте посмотрим на потери пакетов в зависимости от их размера в байтах:

1-20219-5e82b4.png

Ничего очевидного. Возникает следующий вопрос: потеря данных произошла в одно и то же время или нет? Временных меток не было, зато с каждой парой взаимодействующих серверов был ассоциирован счетчик. Проанализировав результат, можно отметить, что из 43 пакетов, не дошедших из Лос-Анджелеса до 2-го сервера в Нью-Джерси, 29 потерялись во время 1-2-минутных промежутков. Собственно говоря, потеря пакетов, которые передавались первому серверу, тоже во-многом случилась за два коротких временных периода.

Порядок получения пакетов

Следующий аспект — порядок получения пакетов. Поначалу была измерена инверсия массива, то есть количество пар, в которых элементы располагаются не по порядку. Допустим, если перед нами массив со значениями 10, 8, 3, 7, 4, то придётся выполнить восемь перестановок ((10,8), (10,3), (10,7), (10,4), (8,3), (8,7), (8,4), (7,4)).

Инверсия:

1-20219-43361c.png

Но так ли полезен этот метод? Как мы знаем, одной из причин применения UDP является возможность отбрасывать некоторые пакеты данных. Если мы посылаем 10 тысяч пакетов, и все они пришли по порядку, причём последний почему-то оказался на месте первого, то мы можем просто отбросить его, не делая 9999 перестановок.

Но что будет, если мы отбросим любой пакет, пришедший после более позднего, уже обработанного (то есть после пакета с бо́льшим порядковым номером)? Допустим, если бы мы получили 1, 5, 4, 3, 6, 7 , мы отбросили бы 4 и 3, так как 5 всё равно уже получили. И какое число «хороших» будет тогда проигнорировано?

Число упорядоченных пакетов:

1-20219-5a2dc5.png

Их процентное соотношение

1-20219-b40f1f.png

В виде небольшой настройки можно объединить вместе 5 пакетов, выполнить их сортировку, а потом опять применить вышеуказанный код, чтобы отбросить ненужные пакеты.

Число упорядоченных пакетов с группировкой:

1-20219-506d23.png

Их процентное соотношение:

1-20219-d45d79.png

Итоги

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

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

Источник: «How unreliable is UDP?»

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться