Вікно масштабування вікон 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 AWS), але зазвичай становить від 70 до 130 Мбіт / с, що більш ніж достатньо для наших потреб. Підключивши сеанс, я бачу:

• iperf -c Windows SYN - вікно 64kb, масштаб 1 - Linux SYN, ACK: вікно 14kb, масштаб: 9 (* 512)
• iperf -c -w1M Windows SYN - Windows 64kb, масштаб 1 - Linux SYN, ACK: вікно 14kb, масштаб: 9

Зрозуміло, що посилання може підтримувати таку високу пропускну спроможність, але я повинен з ясністю встановити розмір вікна, щоб використовувати його будь-яке використання, що більшість реальних програм не дозволяють мені робити. Рукостискання TCP використовують однакові вихідні точки у кожному випадку, але вимушене масштабування

І навпаки, від клієнта Linux в тій же мережі прямий iperf -c(з використанням системних стандартних 85 кб) дає мені:

[  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 на відповідних платформах.

Редагувати

Тут я помітив ще одну послідовну річ, яка може бути актуальною:

Це перша секунда захоплення масштабом 1 Мб. Ви можете бачити Повільний старт у дії, коли вікно збільшується, а буфер збільшується. Ось тоді це крихітне плато розміром ~ 0,2 секунди саме в тій точці, коли тест iperf за замовчуванням вічно вирівнюється. Це, звичайно, масштабується до дуже запаморочливих висот, але цікаво, що в масштабуванні є ця пауза (Значення 1022 байт * 512 = 523264), перш ніж це зробити.

Оновлення - 30 червня.

Слідкуйте за різними відповідями:

• Увімкнення CTCP - це не має значення; масштабування вікон ідентична. (Якщо я правильно це розумію, цей параметр збільшує швидкість, з якою збільшується вікно заторів, а не максимальний розмір, який він може досягти)
• Увімкнення часових позначок TCP. - Тут також ніяких змін.
• Алгоритм Nagle - Це має сенс і, принаймні, це означає, що я, мабуть, можу ігнорувати ці конкретні пробіли в графіку, як будь-які вказівки на проблему.
• Файли pcap: Zip-файл доступний тут: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Анонімізовано з bittwiste, витягує до ~ 150 МБ, оскільки є по одному від кожного клієнта ОС для порівняння)

Оновлення 2 - 30 червня

О, тож після вказівки на пропозицію Кайла, я ввімкнув ctcp і відключив димовідвід: TCP Global Parameters

----------------------------------------------
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. Картка - це мікросхема 82579 В на борту NIC - (я збираюся зробити ще тестування від клієнтів з realtek або іншими постачальниками)

На деякий час зосередившись на NIC, я спробував таке (здебільшого просто виключаючи малоймовірних винуватців):

• Збільшення буферів прийому до 2k з 256 та передавання буферів до 2k від 512 (Обидва зараз максимум) - Без змін
• Вимкнено завантаження всіх контрольних сум IP / TCP / UDP. - Без змін.
• Інвалідизовані великі розвантаження відправки - Nada.
• Вимкнено IPv6, планування QoS - Nowt.

Оновлення 3 - 3 липня

Намагаючись усунути сторону сервера Linux, я запустив екземпляр Server 2012R2 і повторив тести з використанням iperf(cygwin binary) та 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

8 Мб / с ставить його на рівні, які я отримував із явно великими вікнами в 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): один з розміром сокета 128k і типом 64k за замовчуванням (знову обмежується ~ 5Mbit / s) і один з вікном відправлення 1MB та гніздом 8kb за замовчуванням розмір. (масштаби вище)
• Один ntttcpслід від того самого клієнта Windows до екземпляра Server 2012R2 EC2 (1.2.3.5). тут пропускна здатність добре масштабується. Примітка: NTttcp робить щось дивне на порту 6001 перед тим, як відкрити тестове з'єднання. Не впевнений, що там відбувається.
• Один траєкторій даних FTP, завантажуючи 20 Мб /dev/urandomна майже ідентичний хост Linux (1.2.3.6) за допомогою Cygwin ncftp. Знову ж таки межа є. Шаблон майже однаковий за допомогою Windows Filezilla.

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

Ви намагалися ввімкнути Compound 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

тобто

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

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

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

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

TCP має два вікна:

• Вікно отримання: скільки байтів залишилось у буфері. Це контроль потоку, накладений приймачем. Ви можете побачити розмір вікна прийому в проводці, оскільки він складається з розміру вікна та коефіцієнта масштабування вікон всередині заголовка TCP. Обидві сторони з'єднання TCP рекламуватимуть вікно прийому, але, як правило, найважливішим є той, який отримує основну частину даних. У вашому випадку це "сервер" з моменту завантаження клієнта на сервер
• Вікно заторів. Це контроль потоку, який накладає Відправник. Це підтримується операційною системою і не відображається в заголовку TCP. Він контролює швидкість, наскільки швидко будуть надсилатися дані.

У наданому вами файлі захоплення. Ми можемо бачити, що буфер прийому ніколи не переповнюється:

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

Про це свідчить той факт, що у наведеному вище графіку RWIN залишається відкритим, і з часом кругової відстані 0,09 секунд та RWIN ~ 500 000 байтів ми можемо очікувати, що максимальна пропускна здатність відповідно до продукту затримки пропускної здатності буде (500000 /0.09) * 8 = ~ 42 Мбіт / с (а ви отримуєте лише близько 5 при перемозі в захопленні Linux).

Як це виправити?

Не знаю. interface tcp set global congestionprovider=ctcpзвучить як правильно, що потрібно зробити мені, тому що це збільшить вікно надсилання (це ще один термін для вікна перевантаженості). Ви сказали, що це не працює. Отже, щоб переконатися:

1. Ви перезавантажилися після ввімкнення цього?
2. Чи вмикається димохід? Якщо це можливо, спробуйте вимкнути це як експеримент. Я не знаю, що саме вивантажується, коли це ввімкнено, але якщо керування вікном надсилання є одним із них, можливо, застосунок переповнення не впливає, коли це ввімкнено ... я просто здогадуюсь ...
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, але відправник недостатньо відкриває вікно надсилання. Це не те, що він не відкривається досить швидко, він просто обмежується на 64 к.

Типовий розмір буфера сокетів у Windows 7 - 64k. Ось що говорить документація про розмір буфера сокета стосовно пропускної здатності в MSDN

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

Гаразд, бла-бла-бла, зараз ось ми йдемо:

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

Середня пропускна здатність останнього тесту iperf за допомогою вікна 64k становить 5.8Mbps. Це зі статистики> Підсумок у Wireshark, який підраховує всі біти. Ймовірно, iperf підраховує пропускну здатність даних TCP, яка становить 5,7 Мбіт / с. Ми бачимо таку ж ефективність, що і для тесту FTP, ~ 5,6 Мбіт / с.

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

Якщо ми подивимось на тест iperf у вікні 1 МБ, tput становить 88,2 Мбіт / с (86,2 Мбіт / с для лише даних TCP). Теоретичний tput з вікном 1 МБ становить 87,9 Мбіт / с. Знову ж таки, досить близько для роботи уряду.

Це свідчить про те, що буфер сокетів передачі безпосередньо керує вікном надсилання і що в поєднанні з вікном прийому з іншого боку контролює пропускну здатність. У рекламованому вікні отримання є місце, тому одержувач нас не обмежує.

Тримайся, а що з цим автотунінг-бізнесом? Чи Windows 7 не обробляє ці речі автоматично? Як вже було сказано, Windows обробляє автоматичне масштабування вікна прийому, але також може динамічно обробляти буфер відправлення. Повернемося до сторінки MSDN:

Динамічне буферизація відправки для TCP додано в Windows 7 та Windows Server 2008 R2. За замовчуванням динамічне буферизація відправки для TCP увімкнено, якщо програма не встановить параметр socket 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

Я не думаю, що відключення цього допоможе; це просто вигадка.

Чому під час надсилання даних у вікно Linux з великою кількістю місця у вікні отримання не буває масштабування буфера відправлення вище 64k за замовчуванням? Чудове запитання. Ядра 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 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 : Ось ще одне виправлення, яке додає мережевий перемикач, щоб примусити масштабування вікон після другої повторної передачі пакету 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). Я пройшов більшу частину налагодження, яку ви пройшли, відключивши алгоритм Nagle, TCP Chimney Offloading та багато інших змін у налаштуваннях TCP. Ніхто з них не мав жодного ефекту.

Нарешті, для мене це було виправлено - це змінити вікно надсилання за замовчуванням у реєстрі служби AFD. Здається, проблема пов’язана з файлом afd.sys. Я протестував декількох клієнтів, деякі демонстрували повільне завантаження, а деякі не, але всі були машинами Windows 7. Машини, що демонстрували повільну поведінку, мали ту ж версію AFD.sys. Вирішення реєстру потрібне для комп'ютерів з певними версіями AFD.sys (вибачте, не згадуйте версії #).

HKLM \ CurrentControlSet \ Services \ AFD \ Параметри

Додати - 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 Explorer тощо). При використанні програмного забезпечення сторонніх виробників (наприклад, 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 інтерфейс tcp встановлює глобальний автоматичний рівень = експериментальний

Примітка. Перш ніж зробити це, обов'язково запишіть поточний статус автоматичної настройки:

netsh інтерфейс tcp показати глобальним

Рівень автоматичної настройки вікна отримання: відключений

Потім запустіть сервер / клієнт iperf на кожному кінці труби.

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

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.