Масштабирование окна TCP в Windows Слишком раннее достижение плато

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

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

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

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

...

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

Чтобы лучше использовать полосу пропускания TCP-соединений в этих ситуациях, стек TCP / IP следующего поколения включает составной 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 команда.

Изменить 30.06.2014

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

> netsh int tcp show global

т.е.

ПО сказал:

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

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 мс время эти алгоритмы не увеличивают окно отправки достаточно быстро, чтобы полностью использовать пропускную способность соединения. Например, для канала WAN со скоростью 1 гигабит в секунду (Гбит / с) и временем приема-передачи 100 мс (RTT), это может занимает до часа, прежде чем окно отправки первоначально увеличится до получатель объявляет большой размер окна и восстанавливается, когда есть потерянные сегменты.

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

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

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

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

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

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

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

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

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

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

1. Вы перезагружались после включения этого?
2. Разгрузка дымохода включена? Если да, то попробуйте выключить его в качестве эксперимента. Я не знаю, что именно выгружается, когда это включено, но если управление окном отправки является одним из них, возможно, congestionprovider не действует, когда он включен ... Я просто предполагаю ...
3. Кроме того, я думаю, что это может быть до Windows 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 по крайней мере возможна.

Здесь есть отличная информация от @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 составляет 64 КБ. Вот что в документации говорится о размере буфера сокета по отношению к пропускной способности при MSDN

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

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

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

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

Теоретическая пропускная способность с буфером отправки 64 КБ и RTT 91 мс составляет .... 5,5 Мбит / с. Достаточно близко для меня.

Если мы посмотрим на ваш тест iperf окна размером 1 МБ, пропускная способность составляет 88,2 Мбит / с (86,2 Мбит / с только для данных 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

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

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

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

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

Ты можешь:

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

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

После того, как вы настроили стек 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

Прочитав весь анализ в ответах, эта проблема очень похоже на то, что вы можете использовать Windows7 / 2008R2, также известную как 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

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

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

netsh int tcp set global autotuninglevel=normal

CTCP ничего не значит без включения выше.

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

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

У меня возникла аналогичная проблема с клиентами Windows (Windows 7). Я прошел через большую часть отладки, через которую вы прошли, отключив алгоритм Нэгла, разгрузку 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, мини-перенаправитель (WebDAV), FTP через проводник Windows и т. Д.). При использовании стороннего программного обеспечения (например, 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. 

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

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

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

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

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

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

netsh interface tcp show global

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

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

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

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.