Кажется, это та же или, по крайней мере, похожая проблема, как описано в Dropbox (https://dropbox.tech/infrastructure/boosting-dropbox-upload-скорость).
Насколько я понимаю (пожалуйста, поправьте меня!), когда Linux Gateway использует несколько очередей NIC с Wireguard, происходит много переупорядочения пакетов, и, по-видимому, Windows 10 не справляется с этим слишком хорошо.
Переупорядочивание пакетов каким-то образом заставляет Windows 10 замедлять скорость отправки, ожидая подтверждения почти после каждого отправленного пакета данных вместо отправки нескольких пакетов и принятия выборочных подтверждений.
К сожалению, я забыл сделать скриншоты анализируемых сеансов Wireshark, но было очень хорошо видно, что при загрузке хост Windows обычно получает около 10-20 пакетов данных tcp перед отправкой подтверждения. Но при загрузке я получил подтверждение TCP для каждого отправленного пакета данных.
Чтобы исправить это, отключите многоочередность на хосте Linux.
ethtool -L PHYSICAL_LOCAL_INTERFACE в сочетании 1
ethtool -L PHYSICAL_NETWORK_INTERFACE в сочетании 1
Чтобы увидеть, было ли оно применено, можно использовать
ethtool -l ИМЯ ИНТЕРФЕЙСА
Параметры канала для INTERFACENAME:
Предустановленные максимумы:
Прием: 0
Техас: 0
Другое: 1
В сумме: 63
Текущие настройки оборудования:
Прием: 0
Техас: 0
Другое: 1
Комбинированный: 1
Последняя строка должна быть 1. Приведенная выше команда устанавливает это только временно, чтобы сделать его постоянным, необходимо использовать специальные инструменты дистрибутива.
Для Debian это может быть примерно так:
кот /etc/сеть/интерфейсы
авто ИНТЕРФЕЙС
iface ИНТЕРФЕЙС inet статический
адрес IPADDR
маска сети
шлюз ШЛЮЗ
# Это соответствующая строка
post-up ethtool -L ИНТЕРФЕЙС в сочетании 1
Это может создать узкое место, если у шлюза нет мощного процессора. Мы используем 8-ядерные процессоры AMD EPYC 7262 и получаем полную скорость загрузки и загрузки 1 Гбит с использованием ~ 70% одного ядра.
