Сценарий: У нас есть несколько клиентов 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
Последняя цифра может значительно изменяться при последующих тестах (причуды AWS), но обычно она составляет от 70 до 130 Мбит/с, что более чем достаточно для наших нужд. Проводя Wiresharking сессии, я могу видеть:
iperf -c
Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512)
iperf -c -w1M
Windows SYN - Windows 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9
Масштабирование окна iperf с окном по умолчанию 1MB]2.
Очевидно, что канал может поддерживать такую высокую пропускную способность, но я должен явно установить размер окна, чтобы использовать его, что большинство реальных приложений не позволит мне сделать. Рукопожатия 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. Я прочитал много руководств по автонастройке, но они обычно рассказывают об отключении масштабирования вообще, чтобы обойти плохой ужасный комплект домашней сети. Может ли кто-нибудь сказать мне, что здесь происходит, и дать мне способ исправить это? (Желательно что-то, что я могу внести в реестр через GPO).
На рассматриваемом экземпляре 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 на соответствующих платформах.
Я'заметил здесь еще одну последовательную вещь, которая может иметь значение: Это первая секунда захвата 1MB, увеличенная. Вы можете видеть Slow Start в действии, когда окно увеличивается и буфер становится больше. Затем появляется крошечное плато длительностью ~0.2 с точно в точке, где стандартный оконный iperf-тест сплющивается навсегда. Этот, конечно, масштабируется до гораздо более головокружительных высот, но любопытно, что есть эта пауза в масштабировании (Значения 1022 байт * 512 = 523264) перед тем, как это произойдет.
Следуя различным ответам:
Следуя предложению Кайла, я включил 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, установленное в ACKs сервера клиенту. В случае с клиентами Windows, прав ли я, думая, что Linux не масштабирует это значение дальше этой низкой точки, потому что ограниченный CWIN клиента не позволяет заполнить даже этот буфер? Может ли быть какая-то другая причина, по которой Linux искусственно ограничивает RWIN? Примечание: я'пробовал включить ECN, но без изменений.
Никаких изменений после отключения эвристики и автонастройки RWIN. Обновил сетевые драйверы Intel до последней версии (12.10.28.0) с помощью программного обеспечения, которое раскрывает функциональность вкладок viadevice manager. Карта представляет собой встроенную сетевую карту на чипсете 82579V - (я собираюсь провести еще несколько тестов с клиентами с Realtek или другими производителями). Сосредоточившись на сетевой карте, я попробовал следующее (в основном просто исключая маловероятные причины):
Пытаясь исключить серверную сторону Linux, я запустил экземпляр Server 2012R2 и повторил тесты, используя iperf
(двоичный файл cygwin) и NTttcp.
С iperf
мне пришлось явно указать -w1m
на обоих сторонах, прежде чем соединение вышло за пределы ~5 Мбит/с. (Кстати, я могу проверить, и BDP ~5Mbits при 91ms latency почти точно равен 64kb. Предел...)
Двоичные файлы 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
. Странно, однако, 80MB в 1273 буферах = 64kB буфер снова. Дальнейший wireshark показывает хороший, переменный RWIN, возвращающийся с сервера (масштабный коэффициент 256), который клиент, похоже, выполняет; так что, возможно, ntttcp неправильно сообщает об окне отправки.
По просьбе @karyhead'я'провел еще некоторое тестирование и создал еще несколько снимков, вот: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
iperf
, оба с Windows на тот же Linux сервер, что и раньше (1.2.3.4): Один с размером сокета 128k и окном по умолчанию 64k (снова ограничение до ~5Mbit/s) и другой с окном отправки 1MB и размером сокета по умолчанию 8kb. (масштабируется выше)ntttcp
от того же клиента Windows к экземпляру EC2 Server 2012R2 (1.2.3.5). здесь пропускная способность хорошо масштабируется. Примечание: NTttcp делает что-то странное на порту 6001 перед открытием тестового соединения. Не знаю точно, что там происходит./dev/urandom
на почти идентичный хост linux (1.2.3.6) с помощью Cygwin ncftp
. И снова ограничение присутствует. Аналогичная картина наблюдается и при использовании Windows Filezilla.
Изменение длины буфера iperf
приводит к ожидаемому изменению графика временной последовательности (гораздо больше вертикальных секций), но фактическая пропускная способность остается неизменной.Пробовали ли вы включить Compound TCP (CTCP) в своих клиентах Windows 7/8.
Пожалуйста, прочитайте:
Увеличение производительности на стороне отправителя для передачи данных с высокой скоростью.
http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx
...
Эти алгоритмы хорошо работают для малых BDP и меньших размеров окна приема. размеров. Однако, когда у вас есть 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
т.е.
PO сказал:
Если я правильно понимаю, эта настройка увеличивает скорость... которая увеличивает окно перегрузки, а не максимальный размер достигаемый им*
CTCP агрессивно увеличивает окно отправки
http://technet.microsoft.com/en-us/library/bb878127.aspx
Compound TCP
Существующие алгоритмы, которые не позволяют отправляющему TCP пиру от перегружать сеть, известны как медленный старт и перегрузка. избежание. Эти алгоритмы увеличивают количество сегментов, которые может > отправить отправитель. отправитель может отправить, известное как окно отправки, при первоначальной отправке данных при подключении и при восстановлении после потери сегмента. Медленный старт увеличивает окно отправки на один полный сегмент TCP для каждого > сегмента подтверждения. полученного сегмента подтверждения (для TCP в Windows XP и Windows Server 2003) или для каждого подтвержденного сегмента (для TCP в Windows Vista и Windows Server 2008). Избежание перегрузок увеличивает окно отправки на один полный сегмент TCP для каждого полного окна данных, которое подтверждается.
Эти алгоритмы хорошо работают при скорости передачи данных в локальной сети и меньших размерах окна TCP. размеров. Однако, когда у вас есть TCP-соединение с большим размером окна получения размером окна и большим произведением пропускной способности на задержку (высокая пропускная способность и высокая задержка), например, при репликации данных между двумя серверами, расположенными > на высокоскоростной сети. по высокоскоростному каналу WAN с временем в пути 100 мс, эти алгоритмы не увеличивают окно отправки достаточно быстро, чтобы полностью > использовать полосу пропускания. использования пропускной способности соединения. Например, при скорости 1 гигабит в секунду (Гбит/с) WAN-соединении с временем обхода (RTT) 100 мс, это может потребуется до часа, чтобы окно отправки первоначально увеличилось до *большого окна. большого размера окна, рекламируемого приемником, и на восстановление, когда потерянных сегментов.
Для лучшего использования пропускной способности TCP-соединений в таких ситуациях, стек TCP/IP следующего поколения включает Compound TCP (CTCP). CTCP более агрессивно увеличивает окно отправки для соединений с большими размерами окна приема и большими задержками в полосе пропускания. продуктов. CTCP пытается максимизировать пропускную способность на этих типах > соединений. соединений путем мониторинга изменений задержки и потерь. CTCP также следит за тем, чтобы его поведение не оказывало негативного влияния на другие TCP-соединения. соединения.
В ходе тестирования, проведенного внутри компании Microsoft, время резервного копирования больших файлов сократилось почти наполовину для соединения 1 Гбит/с с RTT 50 мс. Соединения с большим произведением задержки на пропускную способность могут иметь еще более высокую > > производительность. производительность. CTCP и автоматическая настройка окна приема работают вместе для увеличения использования канала и может привести к существенному > повышению производительности. повышения производительности для соединений с большим произведением задержки на пропускную способность.
TCP имеет два окна:
В предоставленном вами файле захвата. Мы видим, что буфер приема никогда не переполняется:
Мой анализ заключается в том, что отправитель не отправляет достаточно быстро, потому что окно отправки (оно же окно контроля перегрузки) не открывается достаточно, чтобы удовлетворить RWIN получателя. Короче говоря, получатель говорит "Дай мне больше", а когда Windows является отправителем, он не отправляет достаточно быстро.
Об этом свидетельствует тот факт, что на приведенном выше графике RWIN остается открытым, и при времени обхода .09 секунд и RWIN ~ 500 000 байт мы можем ожидать, что максимальная пропускная способность согласно произведению задержки на пропускную способность будет (500000/0.09) * 8 =~ 42 Мбит/с (а вы получаете только ~5 при перехвате с win на Linux).
Я не знаю. interface tcp set global congestionprovider=ctcp
кажется мне правильной вещью, потому что это увеличит окно отправки (что является другим термином для окна перегрузки). Вы сказали, что это не работает. Поэтому просто чтобы убедиться:
netsh interface tcp show heuristics
. Я думаю, что это может быть RWIN, но там не сказано, так что, возможно, поиграйте с отключением/включением этого параметра в случае, если это влияет на окно отправки.Я бы попробовал все эти эксперименты с отключенными функциями разгрузки, чтобы исключить возможность того, что сетевые драйверы что-то переписывают/изменяют (следите за процессором, пока разгрузка отключена). В TCP_OFFLOAD_STATE_DELEGATED struct, похоже, подразумевается, что разгрузка CWnd, по крайней мере, возможна.
Здесь есть отличная информация от @Pat и @Kyle. Определенно обратите внимание на объяснение @Kyle'а об окнах получения и отправки 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.8Mbps. Это следует из Statistics > Summary в Wireshark, который подсчитывает все биты. Скорее всего, iperf считает пропускную способность данных TCP, которая составляет 5,7 Мбит/с. Такую же производительность мы видим и в тесте FTP, ~5.6Mbps. Теоретическая пропускная способность при буфере отправки 64k и RTT 91ms составляет....5.5Mbps. Достаточно близко для меня. Если мы посмотрим на ваш тест iperf с 1MB окном, то пропускная способность составит 88.2Mbps (86.2Mbps только для данных TCP). Теоретическая пропускная способность с окном 1 МБ составляет 87,9 Мбит/с. Опять же, достаточно близко для работы в правительстве. Это показывает, что буфер сокета отправки напрямую контролирует окно отправки, и это, в сочетании с окном получения с другой стороны, контролирует пропускную способность. В объявленном окне приема есть место, поэтому мы не ограничены приемником. Подождите, а как насчет автонастройки? Разве 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
.
Я не думаю, что отключение этого параметра поможет, это просто информация к сведению.
Почему ваш буфер отправки не увеличивается выше стандартных 64k при отправке данных на Linux бокс с большим пространством в окне получения? Отличный вопрос. Ядра Linux также имеют автонастраивающийся TCP стек. Как T-Pain и Kanye, исполняющие дуэт автонастройки вместе, это может звучать не очень хорошо. Возможно, есть какая-то проблема с этими двумя автонастраивающимися TCP стеками, разговаривающими друг с другом.
У другого человека была такая же проблема, как у вас, и он смог решить ее с помощью правки реестра, чтобы увеличить размер буфера отправки по умолчанию. К сожалению, похоже, это больше не работает, по крайней мере, не сработало для меня, когда я пробовал.
На данный момент, я думаю, ясно, что ограничивающим фактором является размер буфера отправки на хосте Windows. Учитывая, что он не кажется динамически растущим должным образом, что делать девушке?
Вы можете:
Если у вас есть стек TCP настроен, вы все еще может быть узким местом в уровне winsock. Я обнаружил, что настройка интерфейса winsock (драйвере вспомогательной функции в реестре) имеет огромное значение для скорости загрузки (принудительная отправка данных на сервер) в Windows 7. Корпорация Microsoft признала ошибку в TCP autotuning для неблокирующих сокетов-как раз такой разъем, что браузеры используют ;-)
Добавить ключ dword для DefaultSendWindow и установить его на БПР или выше. Я использую 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
Прочитав все анализ в ответах, эта проблема очень похоже на запуск Windows7 на/2008R2 с ака ОС Windows 6.1
Сетевой стек (усилитель протокола TCP/IP и; в winsock) в Windows 6.1 был ужасно испорчены и имели целый ряд ошибок и проблем с производительностью, которой Microsoft в конце концов обратился за многие годы hotfixing с момента первоначального выпуска 6.1.
Лучший способ применить эти исправления вручную отсеивать всех соответствующих страниц support.microsoft.com и запрос вручную и скачать ЛДР варианты исправления сетевого стека (много десятков).
Чтобы найти соответствующие исправления, необходимо использовать www.bing.com с следующий запрос поиска
site:support.microsoft.com 6.1.7601 tcpip.sys
Вы также должны понимать, как ЛДР/ГДР исправления поезда работают в Windows 6.1
Я вообще привык поддерживать свой собственный список ЛДР исправления (а не только сетевой стек исправления) для операционной системы Windows 6.1 и затем активно применял эти исправления для любой ОС Windows 6.1-сервер/клиент, которые мне попадались. Это была очень трудоемкая задача регулярно проверять наличие новых исправлений ЛДР.
К счастью, корпорация Майкрософт прекратила практику ЛДР исправлений с новыми версиями операционных систем и исправления уже доступны с помощью служб автоматического обновления от Microsoft.
Обновление: просто один пример из многих сетевых ошибок в Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785
Обновление 2: Здесь's другое исправление, которое добавляет переключатель netsh в силу масштабирование окна после Второй повторной передачи SYN-пакет (по умолчанию масштабирование окна отключается после 2 SYN-пакеты передаются) https://support.microsoft.com/en-us/kb/2780879
Я вижу это немного старый пост, но может помочь другим.
Короче нужно включить "и автонастройки принимающего окна и":
netsh int tcp set global autotuninglevel=normal
Протокол ctcp ничего не значит без выше с поддержкой.
Если отключить и"автонастройки принимающего окна" вы будет застрял на 64 КБ размер пакета, который имеет отрицательное влияние в течение длительного РТТ's на высоких широкополосных подключений. Вы также можете экспериментировать с "ограниченного" и "highlyrestricted и" вариант.
Очень хорошая ссылка: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html
Я испытывал похожие проблемы с клиентами Windows (для Windows 7). Я прошел через большинство отладки вы прошли, отключить алгоритм Nagle, разгрузка TCP дымохода, и другие связанные с TCP изменения настроек. Не имели никакого эффекта.
Что наконец-то починил его для меня было изменение по умолчанию отправить окно в реестре АФД услуги. Проблема, кажется, связанных с файлом afd.sys . Я попробовал несколько клиентов, некоторые выставлены медленной загрузки, а некоторые так и'т, но все были в Windows 7 машин. Машины, которые выставлены на медленном поведения была такая же версия AFD.sys. Изменений реестра для компьютеров с определенными версиями AFD.sys (к сожалению, не помню версию #'ы).
Реестра HKLM\CurrentControlSet на\услуги\АФД\параметры
Добавить - параметр 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 были медленными проблема загрузки (т. е. мини-перенаправитель(с WebDAV), FTP через Проводник Windows, и т. д...) При использовании 3-й партии программного обеспечения (исх. С filezilla) у меня не было того же замедления.
В AFD.sys эффекты все подключения winsock, так что это исправление должно применяться к FTP, HTTP и по HTTPS, и т. д...
Кроме того, данное исправление было перечислено выше где-то также, Так что я Дон'т хотите, чтобы взять кредит на это, если это работает для кого, однако, не было столько информации в этой теме, Что я боялся, что это могло быть приукрашено.
Ну, я'вэ бежать в подобную ситуацию сам (мой вопрос здесь), и в итоге мне пришлось отключить масштабирование 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.
Я не'т иметь достаточно очков, чтобы комментировать, поэтому я'выложу то "отвечают" вместо. Я'м, что, кажется, похожие/идентичные проблемы (см. serverfault вопрос здесь). Мой (и, наверное, ваша) проблема-отправить буфер подобные клиент на Windows. Она не вырастет до 64 КБ. Windows-это должен динамично расти буфера, когда он явно не по размеру процессом. Но динамика роста не происходит.
Я'м не уверен, что ваш график масштабирования окна, которая показывает оконного проема до 500 000 байт за вашу "медленно" в случае Windows. Я ожидал увидеть, что график открыт только ~64000 байт, учитывая, что вы ограничены до 5 Мбит / с.
Это увлекательное нить и в точности соответствует вопросам, я'ве было Через с Win7/подобные для тестирования пропускной способности на длинный толстый труб.
Решение для Windows 7-выполнить следующую команду на сервере iperf и клиента.
команды netsh интерфейс TCP набор глобальных autotuninglevel=экспериментальная
Примечание: прежде чем вы сделаете это, будьте уверены, чтобы записать текущее состояние автотюнинга:
команды netsh интерфейс TCP показывают глобальный
Функция автонастройки окна получения уровня : отключено
Затем запустить подобные сервера/клиента на каждом конце трубы.
Сбросить значение автотюнинга следующие тесты:
команды netsh интерфейс TCP набор глобальных 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.