Соседи по комнате отстают от интернет-соединения, просматривая видео с китайского сайта. Может ли QoS решить проблему?
Я не читал всю вашу историю, но, исходя из вопроса, который вы задали, ответ, как правило, не совсем. QoS может, в некоторых идеальных обстоятельствах, частично решить проблему, если вы используете определенные высокоприоритетные сервисы (например, Voice over IP), и пакеты правильно помечены, и ваш поставщик восходящего трафика уважает QoS. Но это не поможет вам, если приоритет ваших пакетов и пакетов вашего соседа по комнате одинаков.
То, что вы хотите, это какое-то активное управление очередью.
Что происходит, когда ваш сосед по комнате смотрит видео? Итак, ваш общий маршрутизатор / модем получает огромное количество данных. Чтобы предотвратить потерю этих данных, которые поступают так быстро, как модем может получить, он создает все больший и больший внутренний буфер внутри модема, который ставит в очередь все пакетные данные.
Он должен это делать, потому что он получает IP-пакеты не по порядку и из разных мест (ваши загрузки, загрузки соседа по комнате и т.д.), И он должен собрать части вместе, чтобы сформировать целые TCP-пакеты. Таким образом, он создает этот огромный буфер, чтобы избежать потери пакетов; в противном случае при небольшом буфере некоторые пакеты пришлось бы отбросить, что может привести к необходимости повторной отправки данных.
К сожалению, когда буфер превышает определенный размер, преимущества его использования перевешиваются его недостатками. Основным недостатком "раздутого" буфера является то, что при получении пакета возникает огромная задержка .
Задержка означает, что приложение, отправляющее или получающее данные, должно ждать очень долго, чтобы подтвердить, что оно правильно отправлено или получено. Поскольку данные в TCP-сокетах "проверяются" другой стороной в качестве подтверждения "ОК", я понял!msgstr "другой конец может предположить, что после некоторой задержки, пакет был потерян, и попытаться переслать в любом случае. Таким образом, цель большого буфера состояла в том, чтобы предотвратить повторные отправки, но в своем стремлении сделать это, вызывает повторные отправки !!! Каждая повторная отправка потребляет больше пропускной способности и увеличивает задержку.
Концептуально Active Queue Management - это своего рода решение, которое пытается разумно ограничить размер буферов. Сохраняя буферы настолько маленькими, насколько это возможно, и в то же время достаточно большими, чтобы предотвратить потерю большинства данных из-за ожидания неупорядоченных пакетов, вы можете предотвратить переполнение буфера.
Исследователи пытались делать это годами (а мы только частично добились успеха в мае 2012 года) - разработать алгоритм, который реализует правильное активное управление очередью (AQM) без какой-либо ручной настройки или настройки пользователя (потому что это будет трудоемким и раздражающим). Просто своего рода "волшебная палочка", которая правильно балансирует размеры очереди, чтобы минимизировать потерю пакетов и минимизировать задержку одновременно.
Пока что единственное, что мы обнаружили, что является чрезвычайно успешным на домашних маршрутизаторах, это Active Queue Management с контролируемой задержкой (CoDel), которое является недавним дополнением к ядру Linux.
CoDel очень полезен, потому что он контролирует задержку (задержку) пакетов. Как это сделать, это слишком технический вопрос.
Некоторые ссылки на CoDel, чтобы вы могли прочитать об этом:
CoDel на bufferbloat.net
CeroWRT
Статьи Джима Геттиса о коделе
Изменить: QoS это только половина решения. QoS на основе портов (например, предоставление вашим пакетам более высокого приоритета) займет у вас только так далеко; это совсем не уменьшит раздувание буфера, а ваша задержка все равно будет высокой. Но потеря вашего пакета может немного снизиться.
CoDel в сочетании с QoS, а-ля CeroWRT на вашем роутере, действительно лучший подход.
