Медленная пропускная способность с iperf3 при использовании Windows, но Linux работает на полной скорости.

У меня есть Droplet на DigitalOcean, который использует гигабитное подключение, и, к счастью, мой студенческий общежитие также имеет гигабитное подключение. Я заметил, что передача данных между двумя устройствами была довольно медленной, поэтому я запустил iperf3, используя Droplet в качестве сервера, а мой компьютер в качестве клиента. Тест показал ужасные скорости. Когда я запустил тот же тест с UDP или с достаточным количеством параллельных потоков (80), я достиг полной гигабитной скорости.

Я запустил iperf3 на другом компьютере с Windows и получил те же результаты. После дополнительной диагностики я обнаружил, что использование Ubuntu вместо Windows позволяет достичь гигабитных скоростей.

У меня есть экземпляр EC2, который находится на несколько штатов ближе ко мне, чем Droplet, и когда я установил его в качестве сервера, а мой компьютер с Windows в качестве клиента, я достиг около 30 мегабит. И снова, используя UDP или достаточно параллельных потоков, я также смог получить гигабит.

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

Я был бы очень признателен за любую помощь или совет, которые могли бы помочь мне это исправить. Спасибо.

ИЗМЕНЕНИЕ: Я связался с автором статьи, и он ответил, что мне потребуется оптимизатор WAN. Вот ссылка на Pastebin с электронной почтой, которую он мне отправил. Можете ли кто-то это подтвердить или предложить более простое решение? Хотя мне бы хотелось думать, что я разбираюсь в технологиях, я всего лишь первокурсник, и почти все в этом письме было мне непонятно.

ИЗМЕНЕНИЕ2: http://www.dslreports.com/speedtest/41142166

Для оптимизации tcp в Windows, вы можете попробовать использовать оптимизатор, такой как приведенный ниже:

https://www.speedguide.net/downloads.php

Для оптимизации tcp в Linux вот аналогичный вариант, который имеет ту же цель – увеличить пропускную способность сети:

https://www.cascaderangenetworks.com/

Мы использовали оба на разных системах, и их довольно просто установить.

Звучит так, будто ваш интернет-провайдер ограничивает пропускную способность, из-за чего Windows не может справиться с этим ограничением без значительного ухудшения производительности. По моему опыту, если вы используете Linux и настраиваете его для использования алгоритма управления перегрузкой TCP CDG, вы получите довольно хорошую пропускную способность с минимальной задержкой. Это работает хорошо, потому что по умолчанию Linux использует алгоритм управления очередями, называемый fq-codel, если у вас достаточно новая система Linux.

Однако Windows не поддерживает никакие алгоритмы управления очередями, насколько я могу судить, и вы можете выбрать только из нескольких алгоритмов управления перегрузкой TCP. Я бы рекомендовал попробовать алгоритмы NewReno или BBR2 для Windows, но ни один из них не является действительно хорошим решением без надлежащего управления очередями. Вы можете попробовать использовать алгоритм управления перегрузкой Cubic, чтобы увидеть, улучшит ли это вашу пропускную способность. Однако будьте осторожны: Cubic оптимизирует для сырой пропускной способности и полностью игнорирует проблему буферного разрыва, что может привести к плохому пользовательскому опыту при любом взаимодействии с интернетом, даже если он дает вам максимальную пропускную способность (например, загрузка файлов завершится за минимальное время, но любой, кто использует то же самое соединение для выхода в интернет, игр или поиска видео на youtube, столкнется с большой задержкой).

Большинство людей, похоже, считают, что единственное приемлемое решение – это использовать устройство на базе Linux в качестве фильтра между Windows и выходным подключением к интернету, чтобы обойти проблемы в Windows. Наиболее часто рекомендуемое устройство для этого – Ubiquiti EdgeRouter X, который является отличным продуктом, если ваше выходное подключение составляет 300 Мбит/с или меньше, потому что процессор внутри EdgeRouter X не может справляться с более быстрым трафиком. Некоторые маршрутизаторы (если ваше подключение к интернету идет на WLAN точку доступа, которую вы можете контролировать) уже поддерживают активное управление очередями (AQM) или умное управление очередями (SQM), что может быть достаточным, чтобы заставить Windows вести себя корректно. Идея AQM или SQM заключается в том, чтобы установить пропускную способность очереди немного ниже, чем ваше физическое соединение, чтобы значительно снизить задержку. Обычно настройка предела около 95% скорости, которую Cubic может поддерживать без ограничений, приемлема, если маршрутизатор имеет достаточную мощность процессора для быстрой обработки всех пакетов TCP/IP.

К сожалению, похоже, что Microsoft не заинтересована в добавлении недостающего управления очередями в свою систему, поэтому Windows не может корректно справиться с ситуацией.

Если вы не можете позволить себе приобрести одно дополнительное сетевое устройство для исправления Windows, бедным решением было бы отрегулировать настройки сетевого адаптера, установив скорость соединения на 100 Мбит/с в дуплексном режиме, что ограничивает максимальную скорость Windows до 100 Мбит/с, но оно должно обеспечить хотя бы 90 Мбит/с в любых случаях, так как больше не достигает пределов уровня провайдера.

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

Если кто-то может указать на ошибку в вышеизложенном и сказать, как включить активное управление очередями (что-то подобное fq-codel, cake или pie в Linux) в Windows, пожалуйста, добавьте комментарий ниже. Мне было бы интересно настроить наш игровой компьютер на Windows в иначе полностью линуксовую сеть, где все устройства на Linux не имеют проблем с использованием FTTH соединения.