Надежность UDP — протокола

5b211ce564ff61b004b075a1ac8b1385_1

UDP – это передача данных без установления соединения, которое не имеет подтверждения связи и, таким образом, не дает никаких гарантий относительно доставки или порядка получения пакетов.  Но что это означает на практике?

Карл Сегин (Karl Seguin) провел эксперимент, чтобы выяснить, какова же надежность  такого способа передачи данных.

Он создал 5 VPS для отправки друг другу нескольких UDP-пакетов  в течение 7 часов. Карл не посылал много трафика (хотя, как он отмечает,  это, конечно, стоит попробовать).  Каждый сервер с периодом в 9-11 секунд случайно выбирал получателя и посылал 5-10 пакетов размером от 16 до 1016 байт.

Два сервера располагались в одном центре обработки данных в Нью-Джерси (НД 1 и НД 2) и по одному в Лос-Анджелесе (ЛА), Амстердаме (Нидерланды/НЛД) и Токио (Япония/ЯПН).

 Надежность

Первое, что Карл решил проверить — это надежность UDP.  Он предполагал, что показатели частоты доставки будут варьироваться от 25% до 75%.

Таблица переданных/полученных пакетов

Получатель
НД 1НД 2ЛАНЛДЯПН
НД 1 2981/2981 2888/2889 2964/2964 3053/3054
НД 23016/30163100/31012734/27353054/3054
ЛА2901/29412932/29752938/29422712/2712
НЛД3038/30382771/27722724/27242791/2791
ЯПН2551/25522886/28862836/28382887/2887

 

Таблица переданных/полученных пакетов (процентное соотношение)

Получатель
НД 1НД 2ЛАНЛДЯПН
НД 110099.9710099.97
НД 210099.9799.97100
ЛА98.6498.5599.86100
НЛД10099.97100100
ЯПН99.96100100100

 

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

Автор эксперимента полагал, что проблема заключается в размере пакета данных.  Пакет состоял из 16 байт заголовка и от 0 до 1000 байт полезных данных:

Потери пакетов в зависимости от размера (в байтах)

0-115116-215216-315316-515516-715716-915
131112132323

 

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

Порядок

Второй аспект, интересовавший Карла, — это порядок получения пакетов.
Изначально, автор эксперимента решил измерить инверсию массива. По сути, это число пар, в которых элементы расположены не по порядку. Если у вас есть массив со значениями 10, 8, 3, 7, 4, то вам в конечном итоге придется сделать 8 перестановок ((10,8), (10,3), (10,7), (10,4), (8,3), (8,7), (8,4), (7,4)).

Инверсия

Получатель
НД 1НД 2ЛАНЛДЯПН
НД 1 0 2994 2581 4658
НД 20314724594645
ЛА3980386132374010
НЛД3125182631334189
ЯПН3920441741474425

Карл засомневался в полезности данного метода, которая на первый взгляд кажется высокой. Одна из причин использовать UDP – это возможность отбрасывать некоторые пакеты данных. Если вы посылаете 10 000 пакетов, и они все пришли по порядку, а последний пакет каким-то образом оказался на месте первого, то вы можете просто отбросить его, а не делать 9999 перестановок.
Что если отбросить любой пакет, который придет после более позднего, уже обработанного пакета (т.е. после пакета с большим порядковым номером)? Например, если мы получим 1, 5, 4, 3, 6, 7 , мы бы отбросили 4 и 3, так как мы уже получили 5. Сколько «хороших» пакетов в итоге будет проигнорировано?

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

Получатель
НД 1НД 2ЛАНЛДЯПН
НД 1 2981 1514 1658 1123
НД 23016162714831161
ЛА1227125914851067
НЛД1407164512201096
ЯПН980108311411087

 

Количество упорядоченных пакетов (процентное соотношение)

Получатель
НД 1НД 2ЛАНЛДЯПН
НД 110052.4055.9436.77
НД 210052.4754.2238.02
ЛА41.7242.3250.4839.34
НЛД46.3259.3444.7939.27
ЯПН38.4037.5340.2037.65

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

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

Получатель
НД 1НД 2ЛАНЛДЯПН
НД 1 2981 2061 2235 1807
НД 23016221420411889
ЛА1868187320661720
НЛД2200227319201712
ЯПН1541180417351732

 

Количество упорядоченных пакетов с группировкой (процентное соотношение)

Получатель
НД 1НД 2ЛАНЛДЯПН
НД 110071.3475.4059.17
НД 210071.4074.6361.85
ЛА63.5262.9670.2263.42
НЛД72.4282.0070.4861.34
ЯПН60.3862.5161.1359.99

 

 Вывод

Трудно делать какие-либо выводы, так как необходимо проводить тестирование в течение большего периода времени и с большим количеством данных.  Тем не менее, кажется, что надежность UDP довольно высока.  Расстояние обычно включает в себя больше «прыжков» (Каждое встречающееся на пути пакета промежуточное сетевое устройство заставляет пакет «перепрыгивать»  на очередное соединение (следующий сетевой сегмент), и каждый «прыжок» увеличивает риск того, что что-то пойдет не так, но если все будет налажено, то расстояние не будет проблемой.

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

Перевод статьи: «How unreliable is UDP?»