Windows TCP Window Scaling Попадание на плато слишком рано

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

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

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

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

...

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

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

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

Разъяснение проблемы:

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

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

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

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

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

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

Я не знаю. 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 окон 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 с использованием окна 64 КБ составляет 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-фу. Но я не буду ругаться на могиле моей матери (она все еще жива).

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

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

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

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

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

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

У меня была похожая проблема с клиентами Windows (Windows 7). Я прошел через большинство отладок, которые вы прошли, отключив алгоритм Nagle, разгрузку TCP Chimney и множество других изменений настроек, связанных с 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 Explorer и т. Д.). При использовании программного обеспечения сторонних производителей (например, Filezilla) у меня не было таких же замедлений,

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

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

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

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

netsh int tcp set global autotuninglevel=normal

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

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

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

Ну, я сам столкнулся с подобной ситуацией (мой вопрос здесь), и в итоге мне пришлось отключить эвристику масштабирования 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. 

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

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

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

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

интерфейс netsh tcp show global

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

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

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

интерфейс netsh 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.

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

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