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

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
НД 2 3016/3016 3100/3101 2734/2735 3054/3054
ЛА 2901/2941 2932/2975 2938/2942 2712/2712
НЛД 3038/3038 2771/2772 2724/2724 2791/2791
ЯПН 2551/2552 2886/2886 2836/2838 2887/2887

 

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

Получатель
НД 1 НД 2 ЛА НЛД ЯПН
НД 1 100 99.97 100 99.97
НД 2 100 99.97 99.97 100
ЛА 98.64 98.55 99.86 100
НЛД 100 99.97 100 100
ЯПН 99.96 100 100 100

 

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

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

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

0-115 116-215 216-315 316-515 516-715 716-915
13 11 12 13 23 23

 

В общем-то, ничего очевидного. Произошла ли потеря пакетов примерно в одно и то же время? К сожалению, Карл не сохранил временные метки, но с каждой парой серверов был ассоциирован соответствующий счетчик. Если проанализировать полученные данные, то можно заметить, что из 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
НД 2 0 3147 2459 4645
ЛА 3980 3861 3237 4010
НЛД 3125 1826 3133 4189
ЯПН 3920 4417 4147 4425

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

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

Получатель
НД 1 НД 2 ЛА НЛД ЯПН
НД 1  2981  1514  1658  1123
НД 2 3016 1627 1483 1161
ЛА 1227 1259 1485 1067
НЛД 1407 1645 1220 1096
ЯПН 980 1083 1141 1087

 

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

Получатель
НД 1 НД 2 ЛА НЛД ЯПН
НД 1 100 52.40 55.94 36.77
НД 2 100 52.47 54.22 38.02
ЛА 41.72 42.32 50.48 39.34
НЛД 46.32 59.34 44.79 39.27
ЯПН 38.40 37.53 40.20 37.65

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

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

Получатель
НД 1 НД 2 ЛА НЛД ЯПН
НД 1  2981  2061  2235  1807
НД 2 3016 2214 2041 1889
ЛА 1868 1873 2066 1720
НЛД 2200 2273 1920 1712
ЯПН 1541 1804 1735 1732

 

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

Получатель
НД 1 НД 2 ЛА НЛД ЯПН
НД 1 100 71.34 75.40 59.17
НД 2 100 71.40 74.63 61.85
ЛА 63.52 62.96 70.22 63.42
НЛД 72.42 82.00 70.48 61.34
ЯПН 60.38 62.51 61.13 59.99

 

 Вывод

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

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

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

Не смешно? А здесь смешно: @ithumor