Ускорение передачи файлов по протоколу UDP с защитой от потери?

Question

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

Я решил попытаться определить, когда пакеты потеряны, и отправить их заново.

Я реализовал систему, в которой сервер отправляет клиенту определенный файл в виде 10-байтовых блоков.После того, как он отправляет каждый кусок, он ожидает подтверждения.Если он не получит его в течение нескольких секунд, он снова отправляет чанк.

Мой вопрос: как можно быстро выполнить такую ​​передачу файлов?Если вы отправите файл и допустите 25% -ную вероятность того, что пакет может быть потерян, тогда будет много времени в ожидании подтверждения.

Есть ли способ обойти это?Или считается, что при большой потере пакетов это займет очень много времени?Каково допустимое значение времени ожидания для подтверждения?

Спасибо!

Answer 1

В вашем посте много вопросов, я постараюсь ответить на некоторые. Главное - это проверить и найти узкое место. Какая самая медленная операция?

Теперь я могу вам сказать, что узким местом вашего подхода является ожидание ACK после каждого куска. Вместо подтверждения фрагментов вы хотите подтвердить последовательность. Вторая самая большая проблема - смехотворно маленький кусок. При таком размере накладных расходов больше, чем фактических данных (посмотрите размеры заголовков для IP и UDP).

В заключение:

Я реализовал систему, в которую сервер будет отправлять клиент определенный файл в 10 байтовых блоков.

Возможно, вы захотите попробовать несколько сотен байтов.

После того как он отправляет каждый кусок, он ожидает подтверждения.

Отправьте больше кусков, прежде чем требовать подтверждения, и пометьте их. Существует несколько способов:

• Вместо подтверждения фрагментов, подтвердите данные: «Я получил 5000 байт "(TCP, традиционный)
• Подтверждение нескольких фрагментов в одном сообщении. «Я получил куски 1, 5, 7, 9» (TCP с SACK)

Answer 2

То, что вы реализовали, это Остановка и ожидание ARQ . В сети с высокой задержкой она неизбежно будет медленнее, чем некоторые другие более сложные опции, поскольку она ожидает полный цикл при каждой передаче.

Другие возможности см. В Скользящее окно и переходите по ссылкам на другие варианты. То, что у вас есть, это в основном вырожденная форма раздвижного окна с размером окна 1.

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

Если вы сделаете это, вы по сути заново изобретаете TCP, который использует эту тактику для обеспечения надежного соединения.

Answer 3

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

Пример:

Сервер отправляет пакет 1,2,3,4,5 клиенту. Клиент получает 1,4,5, поэтому он знает, что 2 и 3 были потеряны. Клиент получает 1,4 и 5 и запрашивает повторную отправку 2 и 3.

Тогда вам все еще нужно разобраться, как обрабатывать подтверждения / запросы на повторную отправку и т. Д. В любом случае, присваивание пакетам последовательности последовательных номеров, чтобы потеря пакетов могла быть обнаружена "пробелами" в последовательности достойный подход к этой проблеме.

Answer 4

Посмотрите на протокол TFTP . Это протокол передачи файлов на основе UDP со встроенными условиями подтверждения / повторной отправки.

Answer 5

Ваш вопрос точно описывает одну из проблем, на которые пытается ответить TCP. Ответ TCP особенно элегантен и экономен, так что, читая англоязычное описание TCP, вы можете быть вознаграждены.

Просто чтобы дать вам приблизительное представление о UDP в реальном мире: SNMP - это протокол управления сетью, предназначенный для работы по UDP. Запросы SNMP (около 1500 байт полезной нагрузки), отправленные менеджером на управляемый узел, никогда не подтверждаются явно, и это работает довольно хорошо. Потеря пакетов на двадцать пять процентов - это огромное количество - в худшем случае потеря пакетов на порядок меньше, и в такой неработающей среде SNMP вряд ли будет работать вообще. Конечно, человек, работающий с системой управления сетью - NMS, очень быстро подключится к поддержке сетевого оборудования.

Когда мы используем SNMP, мы обычно понимаем, что для тайм-аута приемлемое значение составляет три или четыре секунды, то есть агент SNMP в управляемом сетевом узле, вероятно, завершит свою работу в это время.

НТН