Каковы хорошие значения времени ожидания и повторов UDP?

Question

Я работаю над конфигурацией сервера / клиента UDP. Клиент отправляет серверу один пакет, размер которого варьируется, но обычно <500 байтов. Сервер отвечает практически мгновенно с помощью одного исходящего пакета, обычно меньшего, чем пакет входящего запроса. Завершенные транзакции всегда состоят из одного пакета обмена. </p>

Если клиент не видит ответ в течение периода времени T, он повторяет R раз, увеличивая T на X перед каждой повторной попыткой, прежде чем окончательно сдаться и вернуть ошибку. В настоящее время R никогда не изменяется.

Есть ли какая-то особая логика для выбора оптимальных начальных значений T (время ожидания), R (повторные попытки) и X (увеличение ожидания)? Насколько постоянными должны быть попытки (т. Е. Какой минимальный R использовать), чтобы достичь некоторого приближения к «надежному» протоколу?

Answer 1

Это похоже на вопрос 5227520 .Поиск в Google «tcp retries» и «tcp retransmission» приводит к множеству предложений, которые были опробованы на протяжении многих лет.К сожалению, ни одно решение не кажется оптимальным.

Я бы выбрал T , чтобы начать через 2 или 3 секунды.Мое увеличение X было бы половиной T (удвоение T кажется популярным, но вы быстро получаете длительные тайм-ауты).Я бы настроил R на лету, чтобы он был по крайней мере 5 и больше, если это необходимо, поэтому мой полный тайм-аут составляет, по крайней мере, одну или две минуты.

Буду осторожен, чтобы не оставить Rи T слишком высокий, если последующие транзакции обычно выполняются быстрее;вы можете захотеть снизить R и T, если позволяют ваши статистические данные, чтобы вы могли повторить попытку и получить быстрый ответ вместо того, чтобы оставить R и T на максимуме (особенно если ваши клиенты люди и вы хотите быть отзывчивыми).

Имейте в виду: вы никогда не станете настолько надежным, как алгоритм, который повторяет больше, чем вы, если эти попытки будут успешными.С другой стороны, если ваш сервер всегда доступен и всегда «реагирует практически мгновенно», то, если клиент не видит ответ, это сбой вне контроля вашего сервера, и единственное, что можно сделать, это повторить попытку клиента (хотя повторная попытка может быть чем-то большим, чем просто повторная отправка, например закрытие / повторное открытие соединения, попытка сервера резервного копирования с другим IP-адресом и т. д.).

Answer 2

Минимальное время ожидания должно быть временем ожидания пути, или половиной времени прохождения сигнала туда и обратно (RTT).

http://www.faqs.org/rfcs/rfc908.html

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

Если вы обнаружите, что пакеты часто теряются, а задержка вызывает беспокойство, тогда вам нужно взглянуть налибо с сохранением того же времени ожидания, либо с медленным нарастанием до экспоненциального времени ожидания, например, 1x, 1x, 1x, 1x, 2x, 4x, 8x, 16x, 32x.

Если пропускная способность не является большой проблемой, нозадержка действительно есть, затем следуйте UDT и форсируйте данные с малым временем ожидания и избыточной доставкой.Это полезно для сред WAN, особенно межконтинентальных расстояний, и почему UDT часто встречается в ускорителях WAN.

Скорее всего, задержка не так уж важна, и предпочтение отдается другим протоколам, тогда используйте стандартную обратную связь.-off pattern, 1x, 2x, 4x, 8x, 16x, 32x.

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