Медленная скорость загрузки с Windows по единственному TCP-соединению, вероятно, из-за переупорядочивания пакетов.

Между серверами windows-in-Finland <-> linux-in-Germany я испытываю загрузка в 100 раз медленнее, чем скачивание (windows -> linux в 100 раз медленнее, чем windows <- linux).

Детали и существующие исследования

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

Для воспроизведения проблемы я использую провайдера дата-центров Hetzner, при этом Windows машина находится в Финляндии (выделенный сервер, Windows Server 2019), загружая на обе:

• Linux Hetzner выделенный сервер в Германии
• Linux Hetzner Cloud VM в Германии (которая уже имеет Combined: 1, так как это виртуальная машина)

Обе из них находятся в одном и том же парке дата-центров, и, следовательно, обе имеют 37 ms ping от Windows машины. В то время как соединение между Финляндией и Германией обычно находится в частной сети Hetzner, оно в настоящее время перенаправляется через публичные интернет-маршруты из-за разрыва подводного кабеля C-LION1 в Балтийском море в 2024 году (сообщение о статусе от Hetzner), поэтому соединение “симулирует” использование обычных публичных интернет-маршрутов и пирингов.

Я измеряю с помощью iperf3, windows <- linux:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-dedicated.examle.com

Подключение к хосту linux-germany-dedicated.examle.com, порт 5201
[  5] локальный 192.0.2.1 порт 62234 подключен к 192.0.2.2 порт 5201
[ ID] Интервал           Передача     Скорость
[  5]   0.00-1.00   сек  15.8 MBytes   132 Mbits/sec
[  5]   1.00-2.00   сек  1.88 MBytes  15.7 Mbits/sec
[  5]   2.00-3.00   сек  1.38 MBytes  11.5 Mbits/sec
[  5]   3.00-4.00   сек  1.75 MBytes  14.7 Mbits/sec
[  5]   4.00-5.00   сек  2.25 MBytes  18.9 Mbits/sec
[  5]   5.00-6.00   сек  2.88 MBytes  24.1 Mbits/sec
[  5]   6.00-7.00   сек  3.25 MBytes  27.3 Mbits/sec
[  5]   7.00-8.00   сек  3.38 MBytes  28.3 Mbits/sec
[  5]   8.00-9.00   сек  2.75 MBytes  23.1 Mbits/sec
[  5]   9.00-10.00  сек  1.25 MBytes  10.5 Mbits/sec

Больше наблюдений с iperf3:

• В другом направлении (добавляя -R к iperf3) значительно быстрее около ~900 Mbit/s. (Обратите внимание, что стороны Linux используют контроль перегрузки BBR, что, вероятно, помогает в этом направлении.)
• При загрузке с 30 соединениями (iperf3 с -P 30) соединение 1 Gbit/s полностью загружено, что указывает на то, что проблема заключается в пропускной способности одного TCP соединения загрузки.
• Когда я заменяю Windows машину на Linux машину в Финляндии, оба направления достигают максимальной скорости в 1 Gbit/s. Это приводит меня к выводу, что вовлеченность Windows является виновной.
• Обратите внимание, что есть статья Microsoft, утверждающая, что iperf3 является лучшим вариантом для высокопроизводительных измерений на Windows. Это не имеет отношения к данному вопросу, поскольку это касается только соединений >= ~10 Gbit/s, и тот факт, что iperf3 через несколько машин Windows/Linux в одном и том же дата-центре доказывает, что скорость в 1 Gbit/s легко достижима с iperf3 в обоих направлениях.

В 2021 году Dropbox выпустил статью Ускорение загрузки Dropbox и улучшение TCP стека Windows, которая указывает на неправильную (неполную) обработку TCP повторных передач в Windows; Microsoft опубликовала Алгоритмические улучшения повышают производительность TCP в Интернете совместно с ней.

Это, похоже, во многом объясняет ситуацию, и Wireguard медленно, но только для загрузки Windows показывает потенциальное решение, а именно изменение числа очередей RSS (Receive Side Scaling) на 1:

ethtool -L eth0 combined 1

Это изменение с 16 (16 потоков на моем выделенном Linux сервере) на 1 увеличивает совокупную скорость загрузки iperf3 с 10.5 до 330 Mbit/s.

Это неплохо, но должно быть 1000 Mbit/s.

Особенно странно: тестируя windows -> linux-Hetzner-Cloud вместо windows -> Hetzner-dedicated, я наблюдаю идеальные скорости загрузки:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-hcloud.example.com

Подключение к хосту linux-germany-hcloud.example.com, порт 5201
[  5] локальный 192.0.2.1 порт 55615 подключен к 192.0.2.3 порт 5201
[ ID] Интервал           Передача     Скорость
[  5]   0.00-1.00   сек   108 MBytes   903 Mbits/sec
[  5]   1.00-2.00   сек   112 MBytes   942 Mbits/sec
...
[  5]   9.00-10.00  сек   112 MBytes   942 Mbits/sec

Это странно, потому что облачная машина имеет значительно более низкие характеристики. У нее 8 виртуальных ядер, но вывод ethtool -l уже по умолчанию установлен на Combined: 1, так как, будучи виртуальной машиной, она вообще не поддерживает RSS:

root@linux-germany-hcloud ~ # ethtool -x enp1s0

Таблица индирекции хешей потока RX для enp1s0 с 1 RX кольцом:
Операция не поддерживается
RSS хеш ключ:
Операция не поддерживается
RSS хеш функция:
    toeplitz: включена
    xor: отключена
    crc32: отключена

Таким образом, каким-то образом более слабая машина не имеет этой проблемы. Возможно, в выделенной машине есть какая-то хитрая аппаратная проблема сетевой карты, которая создает эту проблему? Что это может быть?

Я уже пробовал отключить закрепление TCP сегментов (ethtool -K eth0 tso off), но это не влияет на результаты. Функция, которая вызвала проблему в статье Dropbox (flow-director-atr), недоступна на моей сетевой карте, так что это не может быть причиной.

Вопрос

Что может объяснить дальнейшее 3-кратное узкое место в загрузке при сравнении двух серверов Linux?

Как я могу получить быстрые загрузки с Windows?

Дополнительная информация о среде

• Обе машины Linux используют одну и ту же версию Linux 6.6.33 x86_64 и одинаковые sysctl (это обеспечено через NixOS), которые следующие:

  net.core.default_qdisc=fq
  net.core.rmem_max=1073741824
  net.core.wmem_max=1073741824
  net.ipv4.conf.all.forwarding=0
  net.ipv4.conf.net0.proxy_arp=0
  net.ipv4.ping_group_range=0 2147483647
  net.ipv4.tcp_congestion_control=bbr
  net.ipv4.tcp_rmem=4096 87380 1073741824
  net.ipv4.tcp_wmem=4096 87380 1073741824
  

• Windows Server 2019 Version 1809 (OS Build 17763.6293)