Вопрос: Масштабирование окна Windows TCP Запуск плато слишком рано


Сценарий. У нас есть несколько клиентов Windows, регулярно загружающих большие файлы (FTP / SVN / HTTP PUT / SCP) на серверы Linux, которые находятся на расстоянии ~ 100-160 мс. У нас есть синхронная пропускная способность 1 Гбит / с в офисе, а серверы - либо экземпляры AWS, либо физически размещены в США.

Первоначальный отчет состоял в том, что загрузка на новый экземпляр сервера была намного медленнее, чем они могли быть. Это проявилось в тестировании и в нескольких местах; клиенты видели стабильные 2-5 Мбит / с для хоста из своих систем Windows.

Я разразился iperf -s на экземпляре AWS, а затем из Windows клиент в офисе:

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

Последняя цифра может значительно различаться при последующих тестах (Vagaries of AWS), но обычно составляет от 70 до 130 Мбит / с, что более чем достаточно для наших нужд. Проводя сеанс, я вижу:

  • iperf -c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (* 512) iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN - Windows 64kb, Масштаб 1 - Linux SYN, ACK: Окно 14kb, Масштаб: 9 iperf window scaling with default 1MB Window

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

И наоборот, от клиента Linux в той же сети прямой, iperf -c (используя системный по умолчанию 85kb) дает мне:

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

Без какого-либо принуждения он масштабируется так, как ожидалось. Это не может быть чем-то вроде промежуточных перелетов или наших локальных коммутаторов / маршрутизаторов и, похоже, влияет на клиентов Windows 7 и 8. Я читал множество руководств по автонастройке, но обычно они обычно отключают масштабирование, чтобы обойти плохой домашний сетевой набор.

Может ли кто-нибудь сказать мне, что здесь происходит, и дать мне способ его исправить? (Предпочтительно, что я могу вставить в реестр через объект групповой политики).

Заметки

Экземпляр AWS Linux имеет следующие параметры ядра, применяемые в sysctl.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

Я использовал dd if=/dev/zero | nc перенаправление на /dev/null на сервере, чтобы исключить iperf и удалить любые другие возможные узкие места, но результаты почти одинаковы. Тесты с ncftp (Cygwin, Native Windows, Linux) так же, как и вышеперечисленные тесты iperf на их соответствующих платформах.

редактировать

Я заметил еще одну последовательную вещь, которая может быть актуальной: enter image description here

Это первая секунда захвата 1 МБ, увеличенная. Вы можете видеть Медленный старт в действии, когда окно масштабируется и буфер становится больше. Тогда это крошечное плато ~ 0.2s в точку в тот момент, когда по умолчанию окно iperf test сглаживается навсегда. Это, конечно, масштабируется до огромных высот, но любопытно, что эта пауза в масштабировании (значения - 1022 байт * 512 = 523264), прежде чем это произойдет.

Обновление - 30 июня.

Следуя различным ответам:

  • Включение CTCP - это не имеет значения; масштабирование окна идентично. (Если я это правильно понимаю, этот параметр увеличивает скорость, с которой увеличивается окно перегрузки, а не максимальный размер, который он может достичь)
  • Включение временных меток TCP. - Здесь тоже нет изменений.
  • Алгоритм Нагле - это имеет смысл, и, по крайней мере, это означает, что я могу, вероятно, игнорировать эти конкретные всплески на графике как любое указание проблемы.
  • Файлы pcap: Zip-файл доступен здесь: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymised with bittwiste, извлекает до ~ 150 МБ, так как есть один из каждого клиента ОС для сравнения)

Обновление 2 - 30 июня

O, поэтому, следуя инструкциям по Кайлу, я включил ctcp и отключил выгрузку дымоходов: Глобальные параметры TCP

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

Но, к сожалению, никаких изменений в пропускной способности.

У меня есть вопрос причины / эффекта здесь: Графики имеют значение RWIN, установленное в ACK сервера, клиенту. С клиентами Windows я правильно понимаю, что Linux не масштабирует это значение за пределами этой низкой точки, потому что ограниченный CWIN клиент предотвращает заполнение этого буфера? Может ли быть другая причина, что Linux искусственно ограничивает RWIN?

Примечание. Я попытался включить ECN, черт возьми; но никаких изменений нет.

Обновление 3 - 31 июня.

Никаких изменений после эвакуации при отключении и автонастройки RWIN. Обновите сетевые драйверы Intel до последней версии (12.10.28.0) с помощью программного обеспечения, которое отображает вкладки менеджера viadevice functioanlity. Карта представляет собой чипсет 82579V на борту NIC - (я собираюсь провести еще несколько тестов от клиентов с realtek или другими поставщиками)

Сосредоточив внимание на сетевом адаптере на какое-то время, я пробовал следующее (в основном, просто исключая маловероятных преступников):

  • Увеличьте прием буферов до 2k с 256 и передайте буферы на 2k из 512 (оба теперь в максимуме) - Без изменений
  • Отключена вся разгрузка контрольной суммы IP / TCP / UDP. - Без изменений.
  • Отключено Large Send Offload - Нада.
  • Отключено IPv6, планирование QoS - Nowt.

Обновление 3 - 3 июля

Попытка устранить серверную часть Linux, я запустил экземпляр Server 2012R2 и повторил тесты, используя iperf (бинарный cygwin) и NTttcp,

С iperf, Я должен был явно указать -w1m на и то и другое до того, как соединение будет масштабироваться за пределы ~ 5 Мбит / с. (Кстати, меня можно проверить, а BDP ~ 5 Мбит при латентности 91 мс - это почти ровно 64 кб. Пятно предел ...)

В настоящее время ntttcp-двоичные файлы показывают такое ограничение. С помощью ntttcpr -m 1,0,1.2.3.5 на сервере и ntttcp -s -m 1,0,1.2.3.5 -t 10 на клиенте я вижу гораздо лучшую пропускную способность:

Copyright Version 5.28
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8MB / s ставит его на уровни, которые я получал с явно большими окнами iperf, Как ни странно, 80 МБ в 1273 буферах = буфер 64 КБ снова. Еще один проводник показывает хороший переменный RWIN, возвращающийся с сервера (Масштабный коэффициент 256), который, по-видимому, выполняет клиент; поэтому, возможно, ntttcp неверно сообщает окно отправки.

Обновление 4 - 3 июля

По просьбе @ karyhead я провел еще несколько тестов и создал еще несколько снимков: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

  • Еще два iperfs, как из Windows, так и из того же Linux-сервера, что и раньше (1.2.3.4): один со 128-кратным размером Socket и по умолчанию 64k-окном (ограничивается ~ 5 Мбит / с) и один с 1MB-окном отправки и размером 8kb по умолчанию. (весы выше)
  • Один ntttcp трассировка с одного и того же клиента Windows на экземпляр EC2 сервера 2012R2 (1.2.3.5). здесь пропускная способность хорошо масштабируется. Примечание. NTttcp делает что-то нечетное на порту 6001, прежде чем он откроет тестовое соединение. Не уверен, что там происходит.
  • Одна трассировка данных FTP, загрузка 20 МБ /dev/urandom к почти идентичному хосту linux (1.2.3.6) с использованием Cygwin ncftp, Опять предел. Образец очень похож на Windows Filezilla.

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


50
2018-06-26 09:31


Источник


Редкий пример хорошо изученной проблемы, которая явно не содержится в документации. Ницца - будем надеяться, что кто-то найдет решение (потому что почему-то я думаю, что могу использовать это тоже). - TomTom
Попробуйте включить RFC 1323 Timestamps, поскольку по умолчанию они отключены в Windows, в то время как Linux по умолчанию активирован). netsh int tcp set global timestamps=enabled - Brian
Задержка в 200 мс, вероятно, является алгоритмом Нагле в действии. Поскольку данные принимаются TCP по конкретному соединению, он отправляет подтверждение обратно только в том случае, если выполнено одно из следующих условий: для предыдущего полученного сегмента не было отправлено подтверждение; Получается сегмент, но ни один другой сегмент не достигает 200 миллисекунд для этого соединения. - Greg Askew
Есть ли вероятность разместить некоторые захваты пакетов у одного из более медленных отправителей? - Kyle Brandt♦
Я обновил свой OP с результатами этих тестов и ссылками на репрезентативные файлы захвата. - SmallClanger


Ответы:


Попробовали ли вы включить Соединение TCP (CTCP) в ваших клиентах Windows 7/8.

Пожалуйста прочти:

Увеличение производительности передатчика для передачи с высоким BDP

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

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

Чтобы лучше использовать пропускную способность TCP-соединений в этих   ситуации, стек TCP / IP следующего поколения включает Compound TCP   (CTCP). CTCP более агрессивно увеличивает окно отправки для соединения с большими размерами окна приема и BDP, CTCP пытается   максимизировать пропускную способность на этих типах соединений за счет задержки мониторинга   вариаций и потерь. Кроме того, CTCP гарантирует, что его поведение   не оказывает отрицательного влияния на другие TCP-соединения.

...

CTCP включен по умолчанию на компьютерах под управлением Windows Server 2008 и отключен   по умолчанию на компьютерах под управлением Windows Vista. Вы можете включить CTCP с помощью netsh interface tcp set global congestionprovider=ctcp команда. Вы можете отключить CTCP с помощью    netsh interface tcp set global congestionprovider=none команда.

Изменить 6/30/2014

чтобы проверить, действительно ли CTCP включен,

> netsh int tcp show global

то есть

enter image description here

PO сказал:

Если я правильно это понимаю, эта настройка увеличивает скорость при которые увеличивают окно скопления, а не максимальный размер он может достичь

CTCP агрессивно увеличивает окно отправки

http://technet.microsoft.com/en-us/library/bb878127.aspx

Соединение TCP

Существующие алгоритмы, которые предотвращают отправку TCP-партнера из   подавляющая сеть известна как медленный запуск и перегруженность   избегание. Эти алгоритмы увеличивают количество сегментов, которые   отправитель может отправить, известное как окно отправки, при первоначальной отправке данных   на соединение и при восстановлении с потерянного сегмента. Медленный старт   увеличивает окно отправки одним полным TCP-сегментом для каждого   принятый сегмент подтверждения (для TCP в Windows XP и Windows   Server 2003) или для каждого сегмента, подтвержденного (для TCP в Windows   Vista и Windows Server 2008). Уклонение от перегрузок увеличивает   отправьте окно одним полным TCP-сегментом для каждого полного окна данных, которое   признается.

Эти алгоритмы хорошо работают для скорости ЛВС и меньшего окна TCP   размеры. Однако, когда у вас есть TCP-соединение с большим приемом   размер окна и большой продукт с задержкой полосы пропускания (высокая пропускная способность и   высокая задержка), например, репликация данных между двумя расположенными серверами   через высокоскоростную WAN-связь со временем обратного хода 100 мс, эти   алгоритмы не увеличивают окно отправки достаточно быстро, чтобы полностью   использовать пропускную способность соединения. Например, на 1 гигабит   в секунду (Gbps) WAN со временем обратного хода 100 мс (RTT), оно может занять до часа, чтобы окно отправки сначала увеличилось до размер большого окна, который рекламируется получателем и восстанавливается, когда есть потерянные сегменты.

Чтобы лучше использовать полосу пропускания соединений TCP в этих   ситуаций, стек TCP / IP следующего поколения включает Соединение TCP   (CTCP). CTCP более агрессивно увеличивает окно отправки для   соединения с большими размерами окна приема и большой задержкой полосы пропускания   продукты. CTCP пытается максимизировать пропускную способность по этим типам   связи по мониторинг изменений задержки и потерь, CTCP также   гарантирует, что его поведение не оказывает отрицательного влияния на другие TCP   соединения.

При тестировании, выполняемом внутренне в Microsoft, большое время резервного копирования файлов   были уменьшены почти вдвое для соединения 1 Гбит / с с RTM 50 мс.   Соединения с продуктом с большей задержкой полосы пропускания могут быть еще лучше   представление. CTCP и Auto Auto Tuning работают вместе для   увеличение использования ссылок и может привести к существенной производительности   выигрыши для подключения к продуктам с большой пропускной способностью.


15
2018-06-29 10:03



Как дополнение к этому ответу, эквивалент Powershell в Server 2012 / Win8.1 Set-NetTCPSetting с -CongestionProvider параметр ..., который принимает CCTP, DCTCP и значение по умолчанию. Клиент и серверы Windows используют разные поставщики перегрузок по умолчанию. technet.microsoft.com/en-us/library/hh826132.aspx - Ryan Ries
Я вижу, к чему вы клоните, но, похоже, это не так. Ради этого я провел 30 минут iperf и Окно все еще никогда не масштабируется за пределами ~ 520kb. Что-то еще ограничивает CWND, прежде чем этот агрессивный алгоритм может показать какие-либо преимущества. - SmallClanger
есть старая (уже исправленная) ошибка Vista, которая представляла такие проблемы при передаче не-HTML-протоколов. Ваша проблема выглядит одинаково при передаче одного и того же файла по HTML или, скажем, по FTP? - Pat
@Pat - Это так. SVN Commits (через HTTP и HTTPS) и передача FTP в другую систему на AWS также демонстрируют те же ограничения. - SmallClanger
как насчет брандмауэра клиента Win? вы можете полностью протестировать брандмауэр? глянь сюда: ask.wireshark.org/questions/2365/tcp-window-size-and-scaling - Pat


Уточнение проблемы:

TCP имеет два окна:

  • Окно приема: сколько байтов осталось в буфере. Это управление потоком, наложенное приемником. Вы можете увидеть размер окна приема в wirehark, поскольку он составлен из размера окна и коэффициента масштабирования окна внутри заголовка TCP. Обе стороны TCP-соединения будут рекламировать свое окно приема, но в целом тот, который вам интересен, является тем, кто получает основную часть данных. В вашем случае это «сервер», поскольку клиент загружается на сервер
  • Окно перегруженности. Это управление потоком, наложенное отправителем. Это поддерживается операционной системой и не отображается в заголовке TCP. Он контролирует скорость передачи быстрых данных.

В файле захвата, который вы предоставили. Мы видим, что буфер приема никогда не переполняется:

enter image description here

Мой анализ заключается в том, что отправитель не отправляет достаточно быстро, потому что окно отправки (иначе это окно управления перегрузкой) не открывается достаточно, чтобы удовлетворить RWIN получателя. Короче говоря, приемник говорит «Дайте мне больше», и когда Windows отправитель, он не отправляет достаточно быстро.

Об этом свидетельствует тот факт, что в приведенном выше графике RWIN остается открытым, а с временем прохождения в обратном направлении 0,9 секунды и RWIN ~ 500 000 байт мы можем ожидать максимальную пропускную способность в соответствии с продуктом задержки полосы пропускания (500000 /0.09) * 8 = ~ 42 Мбит / с (и вы получаете около ~ 5 в выигрыше для захвата Linux).

Как это исправить?

Я не знаю. interface tcp set global congestionprovider=ctcp кажется правильным для меня, потому что это увеличит окно отправки (это еще один термин для окна перегруженности). Вы сказали, что это не работает. Поэтому просто чтобы убедиться:

  1. Вы перезагрузились после включения этого?
  2. Распыляется ли дымоход? Если это возможно, попробуйте отключить его как эксперимент. Я не знаю, что именно выгружается, когда это включено, но если контроль над окном отправки является одним из них, возможно, congestionprovider не влияет, когда это включено ... Я просто догадываюсь ...
  3. Кроме того, я думаю, что это могут быть предварительные окна 7, но вы можете попробовать добавить и сыграть с двумя разделами реестра, называемыми DefaultSendWindow и DefaultReceiveWindow, в HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters. Если они даже работают, вы, вероятно, считаете, что ctcp выключен.
  4. Еще одно предположение, попробуйте проверить netsh interface tcp show heuristics, Я думаю, что это может быть RWIN, но он не говорит, поэтому, возможно, играйте с отключением / включением, если оно влияет на окно отправки.
  5. Кроме того, убедитесь, что ваши драйверы обновлены на вашем тестовом клиенте. Может быть, что-то просто сломано.

Я бы попробовал все эти эксперименты, когда вы полностью отключили функции, чтобы исключить возможность того, что сетевые драйверы выполняют некоторую переписывание / модификацию вещей (оставляйте глазный процессор во время разгрузки отключен). Структура TCP_OFFLOAD_STATE_DELEGATED по крайней мере, подразумевает, что CWnd разгрузка, по крайней мере, возможна.


12
2018-06-30 15:11



Я сообщил о вашем «ответе», потому что это не ответ; Я сразу же ушел - проголосовал; теперь я вижу, как «люди» голосуют за ваш «не-ответ» ... действительно смешно - Pat
@Pat: вы можете щелкнуть номер голосования, также увидеть разбивку Upvotes / Downvotes. В настоящее время у вас нет нисходящего потока ответа. Мой ответ не решает его проблемы (но ответа еще нет), он объясняет и локализует проблему (надеюсь, правильно!), Что является важным шагом в устранении неполадок. - Kyle Brandt♦
@ Кайл Брандт, если вы принимаете свои, это не ответ. Я задаюсь вопросом, почему он не «автоматически» удален без дальнейшего рассмотрения? и вы ошибаетесь; Я получил нисходящий голос (unupvote) «как только», как я сообщил ваш «ответ»; тот еще не удален. Кажется, вы играете «специальные» правила здесь. - Pat
@Pat Если это помогает, неполучение Кайла было невероятно полезным. Теперь у меня есть более четкое представление о том, какие буферы ограничены, и я чувствую, что я немного ближе к правильному решению в результате. Иногда такие вопросы могут быть совместными усилиями, которые с небольшим количеством разумного редактирования могут стать правильными Q и надлежащее , - SmallClanger
@SmallClanger со всем уважением, SF имеет набор правил, которым должны следовать все его пользователи, включая Kyle Brandt; если его не ответ, он должен быть удален или перемещен как комментарий, независимо от того, сколько у него друзей среди клубов «модераторов». - Pat


Здесь была подробная информация от @Pat и @Kyle. Определенно обратите внимание на @ Kyle's объяснение из TCP получать и отправлять окна, я думаю, что была некоторая путаница вокруг этого. Чтобы еще больше запутать вопросы, iperf использует термин «окно TCP» с -w который является разновидностью двусмысленного термина в отношении получающего, посылающего или общего скользящего окна. На самом деле он устанавливает буфер отправки сокета для -c (клиент) и буфера приема сокета на -s (сервер). В src/tcp_window_size.c:

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

Как упоминает Кайл, проблема связана не с окном получения в ящике Linux, а с отправителем, которое не открывает окно отправки достаточно. Дело не в том, что он не открывается достаточно быстро, он просто закрывается на 64k.

Размер буфера сокета по умолчанию для Windows 7 равен 64k. Вот что говорит документация о размере буфера сокета по отношению к пропускной способности в MSDN

При отправке данных по TCP-соединению с использованием сокетов Windows это   важно хранить достаточное количество данных (отправлено, но   еще не подтверждено) в TCP для достижения наивысшего уровня   пропускная способность. Идеальное значение для объема выдаваемых данных   достичь наилучшей пропускной способности для TCP-соединения, называется идеальным   отправьте размер отставания (ISB). Значение ISB является функцией   продукт задержки полосы пропускания TCP-соединения и приемник   рекламируемое окно приема (и частично количество перегрузок в   сети).

Хорошо, бла-бла-бла, Теперь мы идем:

Приложения, выполняющие один блокирующий или неблокирующий запрос на отправку   время обычно полагается на внутреннюю буферизацию отправки Winsock для достижения   достойная пропускная способность. Предел буфера отправки для данного соединения   управляемый опцией сокета SO_SNDBUF. Для блокировки и   неблокирующий метод отправки, лимит буфера отправки определяет, сколько   данные сохраняются в TCP, Если значение ISB для подключения   больше, чем предел буфера отправки, тогда пропускная способность, достигнутая на   соединение не будет оптимальным.

Средняя пропускная способность вашего последнего теста iperf с использованием окна 64k составляет 5,8 Мбит / с. Это из Статистика> Резюме в Wireshark, который подсчитывает все биты. Вероятно, iperf подсчитывает пропускную способность TCP-данных, которая составляет 5,7 Мбит / с. Мы видим такую ​​же производительность с тестом FTP, ~ 5.6Mbps.

Теоретическая пропускная способность с буфером отправки 64k и RTMS 91 мс составляет ... 5.5 Мбит / с. Достаточно близко для меня.

Если мы посмотрим на ваш iperf-тест на 1 Мб, то tput будет 88.2 Мбит / с (86.2 Мбит / с только для данных TCP). Теоретическая пропускная способность с окном 1 МБ составляет 87,9 Мбит / с. Опять же, достаточно близко для работы правительства.

Это демонстрирует, что буфер сокета send напрямую управляет окном отправки и который, в сочетании с окном приема с другой стороны, контролирует пропускную способность. В объявленном окне приема есть место, поэтому мы не ограничены получателем.

Подождите, как насчет этого автозапуска? Не обрабатывает ли Windows 7 этот материал автоматически? Как уже упоминалось, Windows обрабатывает автоматическое масштабирование окна приема, но также может динамически обрабатывать буфер отправки. Вернемся к странице MSDN:

Динамическая буферизация отправки для TCP была добавлена ​​в Windows 7 и Windows   Server 2008 R2. По умолчанию динамическая буферизация отправки для TCP включена   если приложение не задает параметр сокета SO_SNDBUF в потоке   разъем.

iperf использует SO_SNDBUF при использовании -w , поэтому динамическая буферизация отправки будет отключена. Однако, если вы не используете -w то он не использует SO_SNDBUF, Динамическая буферизация отправки должна быть включена по умолчанию, но вы можете проверить:

netsh winsock show autotuning

В документации указано, что вы можете отключить ее:

netsh winsock set autotuning off

Но это не сработало для меня. Мне пришлось внести изменения в реестр и установить значение 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

Я не думаю, что отключение этого поможет; это просто FYI.

Почему ваш буфер отправки не превышает значение 64К по умолчанию при отправке данных в ящик Linux с большим количеством места в окне приема? Отличный вопрос. В ядрах Linux также есть стек автонастройки TCP. Как и T-Pain, и Kanye вместе делают дуэт autotune, это может показаться не очень хорошим. Возможно, есть проблема с этими двумя стеками TCP-автонастройки, говорящими друг с другом.

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

На данный момент я считаю, что предельным фактором является размер буфера отправки на хосте Windows. Учитывая, что он, похоже, не динамично растет должным образом, что делать девушке?

Ты можешь:

  • Используйте приложения, которые позволяют вам установить параметр буфера отправки, то есть окно
  • Использовать локальный прокси-сервер Linux
  • Использовать удаленный прокси-сервер Windows?
  • Откройте случай с Microsofhahahahahahaha
  • Пиво

Отказ от ответственности: я провел много часов, исследуя это, и это правильно, насколько мне известно и google-fu. Но я не буду ругаться над могилой моей матери (она все еще жива).


5
2017-07-03 08:24



Фантастический вход; Спасибо. Я использую iperf 2.0.4, я буду экспериментировать с настройками и обновлять свой OP с некоторыми новыми шапками. - SmallClanger
Хорошо, я обновил свой «ответ» на основе большего количества исследований и недавних тестов - karyhead
Благодарю. По крайней мере отчасти приятно знать, что я не просто схожу с ума. Я прочитал несколько блогов / потоков из XP / 2003 дней, которые рекомендуют эти параметры реестра, но они были написаны до Vista / 2008, и я уверен, что они игнорируются в Vista и далее. Я думаю, что я действительно подниму билет с MS по этому поводу (желаю удачи) - SmallClanger
Полезным инструментом, который я обнаружил в своих исследованиях, был tcpanalyzer.exe в SDK (microsoft.com/en-us/download/details.aspx?id=8279). Это графический netstat, в котором вы можете выбрать индивидуальное соединение и получить статистику TCP, такую ​​как RTT, cwnd, повторные передачи и т. Д. Я мог бы получить cwnd, чтобы он выходил за пределы размера буфера отправки, но tput не увеличивался, а wirehark verified что он все равно посылает буфер ограниченным. - karyhead
Я нашел комментарии на нескольких форумах о командах «netsh», которые не работают в 7/8, и люди вынуждены вручную вводить соответствующие записи в реестре; Интересно, может ли что-то подобное произойти с опцией CTCP. - Pat


После настройки TCP-стека у вас может быть узкое место на уровне Winsock. Я обнаружил, что настройка Winsock (Драйвер вспомогательной функции в реестре) имеет огромное значение для скорости загрузки (толкание данных на сервер) в Windows 7. Microsoft подтвердила ошибку в автонастройке TCP для неблокирующих сокетов - только вид сокета, который используют браузеры ;-)

Добавьте ключ DWORD для DefaultSendWindow и установите его в BDP или выше. Я использую 256000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

Изменение настройки Winsock для загрузки может помочь - добавьте ключ для DefaultReceiveWindow.

Вы можете поэкспериментировать с различными настройками уровня сокета, используя обманщик Прокси и команды для настройки размеров буфера клиента и сервера:

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF

4
2018-04-23 21:02



Отличный дополнительный бит информации. У вас есть ссылка на ошибку MS, случайно? - SmallClanger


Прочитав весь анализ в ответах, эта проблема очень похожа на то, что вы можете запускать Windows7 / 2008R2 aka Windows 6.1

Сетевой стек (TCP / IP и Winsock) в Windows 6.1 был ужасно ошибочным и имел целый ряд ошибок и проблем с производительностью, которые Microsoft в конечном итоге устранила в течение многих лет исправления с момента первоначальной версии 6.1.

Лучший способ применить эти исправления - это вручную просеять все соответствующие страницы на веб-сайте support.microsoft.com и вручную запросить и загрузить версии LDR исправлений сетевого стека (их много десятков).

Чтобы найти соответствующие исправления, вы должны использовать www.bing.com со следующим поисковым запросом site:support.microsoft.com 6.1.7601 tcpip.sys

Вам также необходимо понять, как работают потоки исправлений LDR / GDR в Windows 6.1

Обычно я использовал собственный список исправлений LDR (а не только исправлений сетевого стека) для Windows 6.1, а затем проактивно применял эти исправления к любому серверу / клиенту Windows 6.1, с которым я столкнулся. Задача, требующая много времени, регулярно проверять новые исправления LDR.

К счастью, Microsoft прекратила практику исправлений LDR с новыми версиями ОС, и исправления теперь доступны через автоматические службы обновления от Microsoft.

ОБНОВИТЬ: Только один пример многих сетевых ошибок в Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785

ОБНОВЛЕНИЕ 2: Вот еще одно исправление, которое добавляет netsh-переключатель для принудительного масштабирования окна после второй повторной передачи пакета SYN (по умолчанию масштабирование окна отключается после повторного передачи 2 SYN-пакетов) https://support.microsoft.com/en-us/kb/2780879


3
2018-06-06 12:34



Спасибо Кристофу; какой-то очень интересный новый вход на эту и эту функцию SYN-повторной передачи очень странно; Я не вижу цели дизайна за этим. (Возможно, что-то вроде грубого обнаружения перегрузок?). Все оригинальные тесты были выполнены на Win7SP1; мы скоро проведем пробную версию Win10, и мне придется повторно запустить большую часть этого, чтобы посмотреть, как это работает. - SmallClanger
С какой веткой Windows 10 вы будете тестировать? У меня нет опыта работы с сетевым стеком в Windows 10. - Christoph Wegener
Предприятие 1511 - это то, что мы нацеливаем. - SmallClanger
Понимаю. В ветке с Windows 10 довольно сложно решить, так как их так много. Я уже столкнулся с одной проблемой с Windows 10, где я не мог использовать определенную функцию, потому что был на ветке LTSB. Я хочу, чтобы Microsoft сократила количество доступных филиалов в целом и вместо этого улучшила их документацию о том, какие исправления и функции включены в каждую сборку .... - Christoph Wegener


Я вижу, что это немного старше, но это может помочь другим.

Короче, вам нужно включить «Автоматическая настройка окна приема»:

netsh int tcp set global autotuninglevel=normal

CTCP не означает ничего, кроме включенного выше.

Если вы отключите «Автоматическую настройку окна приема», вы будете застревать с размером пакета 64 КБ, что негативно скажется на длинных RTT в высокоскоростных соединениях. Вы также можете экспериментировать с «ограниченным» и «ограниченным» вариантом.

Очень хорошая рекомендация: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html


1
2018-02-23 15:51





У меня возникла аналогичная проблема с Windows Clients (Windows 7). Я прошел большую часть отладки, которую вы прошли, отключив алгоритм Nagle, TCP Chimney Offloading и множество других изменений, связанных с TCP. Никакие из них не имели никакого эффекта.

Наконец, для меня это изменило изменение окна отправки по умолчанию в реестре службы AFD. Проблема, похоже, связана с файлом afd.sys. Я тестировал несколько клиентов, некоторые показывали медленную загрузку, а некоторые - нет, но все были машинами Windows 7. Машины, которые демонстрировали медленное поведение, имели ту же версию AFD.sys. Обходной путь реестра необходим для компьютеров с определенными версиями AFD.sys (извините, не помните версию #).

HKLM \ CurrentControlSet \ Services \ AFD \ Parameters

Добавить - DWORD - DefaultSendWindow

Значение - десятичное - 1640960

Это значение было тем, что я нашел здесь: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Я думаю, чтобы использовать правильное значение, вы должны рассчитать его самостоятельно, используя:

например. Рекламируемая загрузка: 15 Мбит / с = 15 000 Кбит / с

(15000/8) * 1024 = 1920000

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

Я заметил, что в большинстве продуктов MS была проблема медленной загрузки (IE, Mini-redirector (WebDAV), FTP через проводник Windows и т. Д.). При использовании стороннего программного обеспечения (например, Filezilla) у меня не было таких же замедлений ,

AFD.sys влияет на все соединения Winsock, поэтому это исправление должно применяться к FTP, HTTP, HTTPS и т. Д. ...

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


1
2017-07-16 20:11





Ну, я столкнулся с подобной ситуацией (мой вопрос Вот), и в конце мне пришлось отключить эвристику масштабирования TCP, вручную установить профиль автонастройки и включить CTCP:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok. 

0
2018-02-02 23:28





У меня недостаточно очков для комментариев, поэтому я отправлю «ответ» вместо этого. У меня есть то, что похоже на аналогичную / идентичную проблему (см. Вопрос serverfault Вот). Моя (и, вероятно, ваша) проблема - это буфер отправки клиента iperf в windows. Он не превышает 64 КБ. Предполагается, что Windows динамически вырастет буфер, если этот процесс не будет определен явно. Но такого динамического роста не происходит.

Я не уверен в вашем графике масштабирования окна, который показывает окно, открывающееся до 500 000 байт для вашего «медленного» случая Windows. Я ожидал увидеть, что этот график открыт только для ~ 64 000 байт, учитывая, что вы ограничены 5 Мбит / с.


0
2017-08-24 23:22





Это захватывающая тема и точно соответствует тем вопросам, которые я использовал с помощью Win7 / iperf для проверки пропускной способности на длинных жировых трубах.

Решение для Windows 7 должно выполнить следующую команду как на сервере iperf, так и на клиенте.

netsh interface tcp set global autotuninglevel = экспериментальный

NB: Прежде чем вы это сделаете, обязательно запишите текущий статус автонастройки:

netsh interface tcp показать глобальные

Уровень автоматической настройки окна приема: отключен

Затем запустите iperf server / client на каждом конце канала.

Сбросьте значение автонастройки после тестирования:

netsh interface tcp set global autotuninglevel =

   autotuninglevel - One of the following values:
                     disabled: Fix the receive window at its default
                         value.
                     highlyrestricted: Allow the receive window to
                         grow beyond its default value, but do so
                         very conservatively.
                     restricted: Allow the receive window to grow
                         beyond its default value, but limit such
                         growth in some scenarios.
                     normal: Allow the receive window to grow to
                         accomodate almost all scenarios.
                     experimental: Allow the receive window to grow
                         to accomodate extreme scenarios.

0
2017-12-23 10:44