Как я могу контролировать перегрузку для протокола UDP?
У меня есть пользовательский протокол UDP с несколькими отправителями/приемниками, предназначенный для отправки больших файлов вокруг как можно быстрее. Это клиент/сервер.
Как я могу обнаружить перегрузку в локальной сети, чтобы замедлить скорость отправки пакетов UDP?
РЕДАКТИРОВАТЬ: пожалуйста, никаких комментариев относительно использования UDP, подходит ли это или нет. Этот протокол использует UDP, но повторно собирает пакеты в целые файлы, когда они приходят.
Чтобы перефразировать вопрос: как работают алгоритмы управления перегрузками и как обнаруживается перегрузка?
Ответы
Ответ 1
Предполагается, что вы должны использовать UDP (предпочтительным будет TCP).
Внутри приложения единственным признаком перегрузки сети является потеря IP-пакетов. В зависимости от того, как у вас есть протокол, вы можете сделать что-то вроде номера каждой дейтаграммы, и если получатель видит, что он отсутствует (или выдает их из строя), отправьте сообщение (или несколько) отправителю чтобы указать на потерю IP-пакетов и замедление.
Существует протокол под названием RTP (протокол передачи в реальном времени), который используется в потоковых приложениях реального времени.
RTP работает через UDP и RTCP (протокол управления транспортным средством в реальном времени), работающий с RTP, обеспечивает меры для QoS (Quality of Service), такие как потеря пакетов, задержки, дрожание и т.д., чтобы сообщать отправителю, чтобы он знал, когда замедлять вниз или изменить кодеки.
Нельзя сказать, что вы можете использовать RTP, но может быть полезно посмотреть, как это работает.
Ответ 2
Задержка - это хороший способ обнаружить заторы. Если ваша латентность начинает расти, то вам, вероятно, следует замедлить работу. Потерянный пакет эквивалентен задержке = бесконечность. Но вы никогда не можете быть уверены, что пакет был потерян или просто очень медленный, поэтому у вас должен быть тайм-аут для "обнаружения" потерянных пакетов.
Ответ 3
Управление потоком является сложной проблемой, потому что все, что вы действительно знаете, - это когда вы отправили пакет и получили пакет. Такие вещи, как латентность, потеря и даже скорость, являются статистикой, которую вы должны рассчитать и интерпретировать.
В следующей статье рассматриваются эти статистические данные и их значение в глубине:
DEI Tech Note 0021: Потеря, Задержка и Скорость
Нахождение хорошего решения стало предметом многих исследований и коммерческих усилий.
Различные алгоритмы (TCP, UDT, Многоцелевой протокол транзакций и т.д.) используют разные методы и делают разные предположения, все пытаются выяснить, что происходит в сети на основе очень редких данных.
Ответ 4
Кажется, алгоритм AIMD - это то, что они используют в TCP и UDT, чтобы избежать перегрузок.
Со страницы Википедии:
Алгоритм аддитивного увеличения/мультипликативного уменьшения (AIMD) представляет собой алгоритм управления с обратной связью, наиболее известный его использованием в TCP Congestion Avoidance. AIMD сочетает линейный рост окна скопления с экспоненциальным уменьшением при перегрузке. Несколько потоков, использующих управление перегрузкой AIMD, в конечном итоге сходятся, чтобы использовать равные количества конкурирующей ссылки.
Ответ 5
У меня была следующая идея:
- Отправитель отправляет данные.
- Приемник ждет пару секунд, а затем вычисляет пропускную способность /s
- Приемник отправляет скорость, с которой его принимающие пакеты (байты/с) отправителю
- Отправитель рассчитывает скорость отправки пакетов
- Если скорость отправителя значительно выше, уменьшите ее, чтобы она соответствовала скорости приема.
Альтернативно, более продвинутый подход:
- Отправитель начинает отправку с предопределенной минимальной скоростью (например, 1 кбит/с)
- Приемник отправляет вычисленную скорость приема обратно отправителю.
- Если скорость приема равна скорости передачи (принимая во внимание задержку), увеличьте скорость с помощью набора pct (например, rate * 2)
- Продолжайте делать это, пока скорость отправки не станет выше скорости приема.
- Следите за тем, чтобы тарифы учитывались при изменении скорости увеличения/уменьшения полосы пропускания, если это необходимо.
Отказ от ответственности: im не эксперт сети, это может не сработать для вас.