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

Останній показник може суттєво відрізнятися від наступних випробувань (Вагари AWS), але зазвичай становить від 70 до 130 Мбіт/с, що більш ніж достатньо для наших потреб. Переглядаючи сесію, я бачу:

  • iperf -c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512) iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN - Windows 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 iperf window scaling with default 1MB Window

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

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

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

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

Чи може хто-небудь сказати мені, що відбувається тут, і дати мені спосіб її виправлення? (Бажано щось, що я можу вставити в реєстр за допомогою 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, якщо =/dev/zero | nc перенаправляє на /dev/null на кінці сервера, щоб виключити iperf і видалити будь-які інші можливі вузькі місця, але результати те ж саме. Тести з ncftp (Cygwin, Native Windows, Linux) масштабуються так само, як і вищезазначені тести iperf на відповідних платформах.

Редагувати

I've spotted another consistent thing in here that might be relevant: enter image description here

Це перша секунда з 1 МБ захоплення, збільшена. Ви можете переглянути Повільний початок у дії, коли масштаб вікна і буфер збільшується. Тоді на цьому крихітному плато ~ 0.2s точно в тому випадку, коли тест 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 червня

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

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

Але, на жаль, змін у пропускній здатності немає.

У мене є питання причин/наслідків, хоча: Графіки мають значення RWIN, встановлене в ACK сервера на клієнті. З клієнтами Windows, я маю на увазі, що Linux не масштабує це значення за межами цієї низької точки, оскільки обмежена CWIN клієнта не дозволяє заповнити навіть цей буфер? Чи може бути якась інша причина, чому Linux штучно обмежує RWIN?

Примітка: Я намагався включити ECN для пекла його; але ніяких змін немає.

Оновлення 3 - 31 червня.

Ніяких змін після вимкнення евристики та автонастроювання RWIN. Оновили драйвери мережі Intel до останньої версії (12.10.28.0) з програмним забезпеченням, яке надає функції налаштувань вкладки менеджера мереж. Карта є вбудованим NIC набором мікросхем 82579V - (я збираюся виконати додаткове тестування від клієнтів з Realtek або іншими постачальниками)

Орієнтуючись на НІЦ на хвилину, я спробував наступне (в основному просто виключаючи неправдоподібних винуватців):

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

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

Намагаючись усунути серверну сторону Linux, я запустив примірник Server 2012R2 і повторив тести, використовуючи iperf (cygwin binary) і NTttcp .

З iperf , я повинен був явно вказати -w1m на обох сторонах перед тим, як зв'язок перевищуватиме ~ 5Mbit/s. (До речі, я міг би бути перевірений, і BDP ~ 5 Мбіт при затримці 91ms майже точно 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 буферах = 64kB буфер знову. Далі wireshark показує хорошу, змінну RWIN, що повертається з сервера (Scale factor 256), що клієнт, здається, виконує; тому, можливо, ntttcp неправильно повідомляє вікно надсилання.

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

At @karyhead's request, I've done some more testing and generated a few more captures, here: 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) і один з 1 Мб вікна надсилання і розміром сокета за замовчуванням 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 робить очікувану різницю графіку тимчасової послідовності (набагато більше вертикальних розділів), але фактична пропускна здатність не змінюється.

50
Будь-який шанс поставити деякі захоплення пакета від одного з більш повільних відправників десь?
додано Автор MaikoID, джерело
@SmallClanger: Що стосується "Чи може бути якась інша причина, чому Linux штучно обмежує RWIN?". Я не позитивний, але я погоджуюся з вашою теорією, що RWIN не збільшується, тому що він ніколи не стає низьким. Це було б нерозумно робити це, тому що це означало б більше використання пам'яті, коли немає ніяких причин брати більше пам'яті для буфера прийому.
додано Автор MaikoID, джерело
@SmallClanger: Також подивіться на "Експертний аналіз" у двох захопленнях. У Linux-to-Linux, ви бачите нульові вікна повідомлень, дублікати acks і т.д. У випадку з Windows для Linux, все чисто, тому що TCP не є «стрес-тестом».
додано Автор MaikoID, джерело
@SmallClanger: Ах, і щоб допомогти пояснити, мій графік, якщо я розумію, це правильно відображає RWIN, як це в даний час з плином часу. Іншими словами, це "доступні в даний момент байти" в буфері. Таким чином, RWIN завжди має достатньо місця.
додано Автор MaikoID, джерело
@SmallClanger: Ще одна здогадка, спробуйте грати з netsh int tcp показувати евристику / netsh інтерфейс tcp show heuristics відключений |
додано Автор MaikoID, джерело
На відстані, в якому ми все йдемо, це виглядає так, як правильна відповідь буде "Переключити всіх ваших клієнтів на Linux" ;-)
додано Автор MaikoID, джерело
Рідкісний приклад добре вивченої проблеми, що не є очевидною в документації. Приємно - давайте сподіватися, що хтось знайде рішення (тому що я думаю, що я можу використовувати це теж).
додано Автор TomTom, джерело
Чи є ці клієнти Windows 7 і поза ними? Це дерьмо. Вимкнення автоматичної настройки зазвичай виправлено для мене. Але цей патч виглядає так, як він зазвичай не встановлений і, схоже, вирішує проблему, яку ви описуєте. support.microsoft.com/kb/983528 .
додано Автор JumpingPA, джерело
netsh інтерфейс tcp set global autotuning = відключений зазвичай працює для мене.
додано Автор JumpingPA, джерело
@SmallClanger: Що таке версія tcpip.sys на тестовій системі?
додано Автор Mohamad-jaafar, джерело
Затримка 200 мс, ймовірно, є алгоритмом Nagle в дії. Оскільки дані приймаються TCP по певному з'єднанню, він відправляє підтвердження назад тільки в тому випадку, якщо виконується одна з наступних умов: не було відправлено підтвердження для попереднього отриманого сегмента; Отримано сегмент, але жоден інший сегмент не доставляється протягом 200 мілісекунд для цього з'єднання.
додано Автор Mohamad-jaafar, джерело
@ AndréBorie - у мене немає. Це питання, яке було заблоковано цим (для мене), пройшло, і я не встиг попрацювати через деякі пізніші рішення на основі реєстру, запропоновані тут. FWIW, я впевнений, що CTCP є правильним маршрутом, але я думаю, що існують проблеми з реалізацією TCP з певними пакетами програмного забезпечення, які є вузькими, навіть якщо CTCP правильно налаштований.
додано Автор SmallClanger, джерело
@KyleBrandt - я б, напевно, прийняв "lol, використовуйте linux, nub" як відповідь. Схоже, що шлях найменшого опору в даний момент :)
додано Автор SmallClanger, джерело
@GregAskew 6.1.7601.22648 на клієнті Win7SP1. 6.3.9600.17088 На клієнті Win8.1.
додано Автор SmallClanger, джерело
@Matt Це було одне з перших речей, які я спробував. Як я розумію, автотюнінг є чисто пов'язаним з RWIN і низхідною пропускною здатністю. (Це схоже обмежено, але зміна налаштувань автонастроювання не мала ефекту).
додано Автор SmallClanger, джерело
Я оновлював свою операційну систему з результатами цих тестів і посиланнями на репрезентативні файли захоплення.
додано Автор SmallClanger, джерело
@SmallClanger ви коли-небудь знайти рішення? Я стикаюся з тією ж проблемою.
додано Автор chun, джерело
Спробуйте увімкнути тимчасові мітки RFC 1323, оскільки вони за замовчуванням відключені в Windows, тоді як Linux включений за замовчуванням. netsh int tcp встановити глобальні тимчасові позначки = увімкнено
додано Автор Damien Ó Ceallaigh, джерело

10 Відповіді

Ви намагалися ввімкнути Compound TCP (CTCP) у клієнтах Windows 7/8.

Будь ласка, прочитайте:

Збільшення продуктивності на стороні відправника для передачі з високим BDP

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

...

     

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

     

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

     

...

     

CTCP увімкнено за замовчуванням на комп'ютерах під керуванням Windows Server 2008 і вимкнено   за замовчуванням на комп'ютерах під керуванням Windows Vista. CTCP можна ввімкнути за допомогою netsh   інтерфейс tcp set global congestionprovider = команда ctcp . Ви можете вимкнути CTCP за допомогою   команду netsh interface tcp set global congestionprovider = none .

Редагувати 30.06.2014

щоб побачити, чи дійсно CTCP "включено"

> netsh int tcp show global

тобто

enter image description here

PO сказав:

     

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

CTCP агресивно збільшує вікно надсилання

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

Складений TCP

     

Існуючі алгоритми, що запобігають відправці вузла TCP   Переважна мережа відома як повільний запуск і перевантаження   уникнення. Ці алгоритми збільшують кількість сегментів, які   Відправник може відправити, відоме як вікно надсилання, коли спочатку надсилає дані   на підключенні і при відновленні з втраченого сегмента. Повільний початок   збільшує вікно надсилання на один повний сегмент TCP для кожного з них   отриманий сегмент підтвердження (для TCP в Windows XP і Windows   Server 2003) або для кожного визнаного сегмента (для TCP в Windows   Vista та Windows Server 2008). Уникнення перевантажень збільшує   відправити вікно на один повний сегмент TCP для кожного повного вікна даних   

     

Ці алгоритми добре працюють для локальних мереж і меншого вікна TCP   розмірів. Однак при наявності TCP-з'єднання з великим приймачем   розмір вікна і великий продукт затримки смуги пропускання (висока пропускна здатність і. \ t   висока затримка), наприклад, реплікація даних між двома розташованими серверами   на високошвидкісному WAN-каналі зі швидкістю 100 мсек   Алгоритми не збільшують швидкість надсилання вікна надсилання   використовувати пропускну здатність з'єднання. Наприклад, на 1 гігабіт   за секунду (Гбіт/с) WAN-зв'язок зі швидкістю 100 мс/год. (RTT), вона може    Вам потрібно близько години, щоб вікно надсилання спочатку збільшилося до    розмір великого вікна рекламується одержувачем та відновлюється, коли    є втрачені сегменти.

     

Щоб краще використовувати пропускну здатність з’єднань TCP у них   Стек TCP/IP наступного покоління містить Compound TCP   (CTCP). CTCP більш агресивно збільшує вікно надсилання для   з'єднання з великими розмірами вікна прийому та великою затримкою пропускної здатності   продуктів. CTCP намагається максимізувати пропускну спроможність цих типів   з'єднань: моніторинг затримок і втрат . КТЗП також   гарантує, що його поведінка негативно не вплине на інші TCP   з'єднання.

     

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

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

Пояснення проблеми:

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

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

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

enter image description here

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

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

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

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

  1. Чи ви перезавантажилися після цього?
  2. Чи вивантажено Chimney? Якщо це можливо, спробуйте вимкнути його як експеримент. Я не знаю, що саме вивантажується, коли це увімкнено, але якщо керування вікном відправки є одним з них, можливо, пропускник перевантажень не діє, коли це ввімкнено ... Я просто гадаю ...
  3. Крім того, я вважаю, що це може бути до Windows 7, але ви можете спробувати додати та відтворити два розділи реєстру: DefaultSendWindow і DefaultReceiveWindow в параметрах HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD. Якщо вони навіть працюють, ви, мабуть, це має ctcp off.
  4. Ще раз припустимо, перевірте netsh інтерфейс tcp show heuristics . Я думаю, що це може бути RWIN, але це не говорить, так що, можливо, грати з відключенням/увімкненням, якщо це вплине на вікно надсилання.
  5. Також переконайтеся, що драйвери оновлені на тестовому клієнті. Можливо, щось просто порушено.

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

12
додано
@Pat: Ви можете натиснути на номер голосу, також побачити розбивку голосів/голосів. Наразі у вас немає відповідей на відповідь. Моя відповідь не вирішує його проблему (але відповіді поки що немає), вона пояснює та локалізує проблему (сподіваюся, правильно!), Що є важливим кроком у усуненні несправностей.
додано Автор MaikoID, джерело
@Pat Якщо це допомагає, невідповідь Кайла була надзвичайно корисною. Тепер у мене є чітке уявлення про те, які буфери обмежені, і я відчуваю, що я трохи ближче до належного рішення в результаті. Іноді такі питання, як це, можуть бути спільними зусиллями, які, з трохи розумного редагування, можуть стати належним Q та належним A .
додано Автор SmallClanger, джерело
@SmallClanger з усією повагою, SF має набір правил, яким повинні відповідати всі його користувачі, включаючи Кайла Брандта; якщо його не є відповіддю, його треба стерти або перенести як коментар незалежно від того, скільки друзів він має в клубі "модераторів".
додано Автор Masood Salik, джерело
@ Кайл Брандт, якщо ви приймаєте ваш не є відповіддю Цікаво, чому це не "автоматично" видаляється без подальшого розгляду ?? і ви помиляєтеся; Я отримав голос (unupvote) "як тільки", як я повідомив "відповідь"; одна ще не була видалена. Здається, ви граєте тут за "спеціальними" правилами.
додано Автор Masood Salik, джерело
Я повідомив про вашу "відповідь", тому що ваша відповідь не є; Я негайно проголосував; тепер я бачу, як "люди" голосують за вашу "ні-відповідь" ... дійсно смішно
додано Автор Masood Salik, джерело

Тут була чудова інформація від @Pat і @Kyle. Звичайно, зверніть увагу на пояснення протоколу прийому та надсилання повідомлень про TCP, я вважаю, що навколо цього було певна плутанина. Для того, щоб плутати питання далі, iperf використовує термін "вікно TCP" з параметром -w , який є неоднозначним терміном щодо вікна прийому, відправки або загального ковзання. Насправді, це встановлює буфер передачі сокету для екземпляра -c (клієнт) та буфера отримання сокету в екземплярі -s (server). У 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.

The default socket buffer size on Windows 7 is 64k. Here's what the documentation says about the socket buffer size in relation to throughput at MSDN

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

Добре, бла-бла-бла, тепер ми йдемо:

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

The average throughput of your most recent iperf test using the 64k window is 5.8Mbps. That's from Statistics > Summary in Wireshark, which counts all the bits. Likely, iperf is counting TCP data throughput which is 5.7Mbps. We see the same performance with the FTP test as well, ~5.6Mbps.

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

Якщо ми подивимося на тест iperf на 1 Мб вікна, то tput становить 88.2Mbps (86.2Mbps для даних TCP). Теоретичний tput з 1МБ вікна 87.9Mbps. Знову ж таки, досить близько для роботи уряду.

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

Затримайтеся, що про цей бізнес автотюнінгу? Хіба 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 СИСТЕМА CurrentControlSet Послуги AFD Параметри \ t

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

Чому масштабування вашого буфера надсилання не перевищує стандартне значення 64k при відправленні даних у вікно Linux з великою кількістю місця у вікні прийому? Велике питання. Ядра Linux також мають стек TCP. Як і T-Pain і Kanye, які роблять дует з автонастройкою разом, це просто не звучить добре. Можливо, існує певна проблема з двома стеками автотюнінгу TCP, які розмовляють один з одним.

Another person had a problem just like yours and was able to fix it with a registry edit to increase the default send buffer size. Unfortunately, that doesn't seem to work anymore, at least it didn't for me when I tried it.

At this point, I think it's clear the limiting factor is the send buffer size on the Windows host. Given that it doesn't seem to be dynamically growing properly, what's a girl to do?

Ти можеш:

  • Використовуйте програми, які дозволяють встановлювати буфер надсилання, тобто параметр вікна
  • Використовуйте локальний проксі-сервер Linux
  • Використовувати віддалений проксі-сервер Windows?
  • Відкрийте випадок з Microsofhahahahahahaha
  • Пиво

Відмова від відповідальності: Я витратив багато годин на дослідження цього, і це правильно, наскільки мені відомо, і google-fu. Але я б не поклявся на могилі своєї матері (вона ще жива).

5
додано
Корисним інструментом, з яким я зіткнувся у своєму дослідженні, був tcpanalyzer.exe у SDK ( microsoft.com/en-us/download/details.aspx?id=8279 ). Це графічний netstat, за допомогою якого ви можете вибрати індивідуальне підключення і отримати статистику TCP, як RTT, cwnd, ретрансляції тощо. що він все ще обмежений.
додано Автор Mister_Tom, джерело
Гаразд, я оновив мій "відповідь" на основі додаткових досліджень і ваших останніх тестів
додано Автор Mister_Tom, джерело
Вікно отримання на вашому сервері Windows на тесті Win-to-Win веде себе зовсім інакше, ніж Linux, тобто набагато динамічніше. Можливо, це фактор з точки зору роботи буфера динамічного надсилання. Я спробував вимкнути вікно отримання автотюнінгу на Linux (/ proc/sys/net/ipv4/tcp_moderate_rcvbuf) і встановити його на max (/ proc/sys/net/ipv4/tcp_rmem), але це не збільшило tput для мене. Ви можете спробувати це. Удачі вам у MSFT. Я пропоную спробувати ескалацію справи якомога швидше. Ви, мабуть, потребуєте пройти перші кілька рівнів; може знадобитися інженерна увага.
додано Автор Mister_Tom, джерело
І нарешті. Це було дуже цікаво для досліджень, оскільки я не знаю багато про TCP у Windows. Я сподіваюся, що ви знайдете щось із MSFT. Якщо ви не заперечуєте, я буду писати це для мого пакету аналізу пакетів packetbomb.com.
додано Автор Mister_Tom, джерело
Дякую. Принаймні у частині це приємно знати, що я не просто зійшов з розуму. Я прочитав кілька блогів/ниток з XP/2003 днів, які рекомендують ці параметри реєстру, але вони були написані до Vista/2008 і я впевнений, що вони ігноруються в Vista далі. Я думаю, що я дійсно підніму квиток з MS про це (побажайте мені удачі)
додано Автор SmallClanger, джерело
Фантастичний вхід; спасибі. Я використовую iperf 2.0.4, я буду експериментувати з налаштуваннями і оновлювати мою операційну систему з деякими новими ковпаками.
додано Автор SmallClanger, джерело
Якщо проблема полягає в тому, що багато програмного забезпечення просторового користувача просто має занадто низький рівень розпізнавання буферів сокетів, тоді стає питання: "Чи є робота ОС втручатися в ці справи? Я буду слідувати, якщо MS повернеться з корисною відповіддю.
додано Автор SmallClanger, джерело
Я знайшов коментарі на декількох форумах про команди "netsh", які не працюють як рекламуються в 7/8, і люди змушені вручну вводити відповідні записи реєстру; Цікаво, що щось подібне може бути з варіантом CTCP.
додано Автор Masood Salik, джерело

Після того, як стек 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
4
додано
Великий додатковий біт інформації. Чи є у вас посилання на MS bug, випадково?
додано Автор SmallClanger, джерело

Прочитавши весь аналіз у відповідях, ця проблема дуже схожа на те, що ви можете запустити Windows7/2008R2 ака Windows 6.1

The networking stack (TCP/IP & Winsock) in Windows 6.1 was horribly flawed and had a whole host of bugs and performance problems which Microsoft eventually addressed over many years of hotfixing since the initial release of 6.1.

Найкращий спосіб застосувати ці виправлення - вручну просіювати всі відповідні сторінки на support.microsoft.com і вручну запитувати і завантажувати LDR версії виправлень мережевого стека (їх налічується багато десятків).

To find the relevant hotfixes, you must use www.bing.com with the following search query 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.

UPDATE: Just one example of many network bugs in Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785

UPDATE 2: Here's another hotfix that adds a netsh switch to force Window scaling after the second retransmission of a SYN packet (by default, window scaling is disabled after 2 SYN packets are retransmitted) https://support.microsoft.com/en-us/kb/2780879

3
додано
Завдяки Christoph; деякі дуже цікаві нові дані про це і що SYN-ретрансляція 'особливість' дуже дивно; Я взагалі не бачу мети дизайну. (Деякий вид виявлення сирої перевантаженості, можливо?). Всі оригінальні тести були виконані на Win7SP1; ми скоро будемо випробовувати Win10, і це на мене повторно запустити більшу частину цього, щоб побачити, як це коштує.
додано Автор SmallClanger, джерело
Enterprise 1511 - це те, що ми націлюємо.
додано Автор SmallClanger, джерело
З якою гілкою Windows 10 ви будете тестувати? У мене ще немає досвіду роботи з мережним стеком у Windows 10. \ t
додано Автор Bon Dacasin, джерело
Я бачу. Досить складно визначитися з гілкою з Windows 10, оскільки їх дуже багато. Я вже зіткнувся з однією проблемою з Windows 10, де я не міг використовувати особливу функцію, тому що я був у відділенні LTSB. Мені б хотілося, щоб Microsoft зменшила загальну кількість доступних гілок і замість цього покращила свою документацію про те, які виправлення та функції включені в кожну збірку ....
додано Автор Bon Dacasin, джерело

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

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

HKLM CurrentControlSet Послуги Параметри AFD

Додати - DWORD - За замовчуваннямSendWindow

Значення - Decimal - 1640960

That value is was something I found here: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Я думаю, що для використання потрібного значення, ви повинні розрахувати його самостійно, використовуючи:

напр. Розміщено рекламою: 15 Mbps = 15,000 Kbps

(15000/8) * 1024 = 1920000

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

Я помітив, що в основному продукти MS мали повільну проблему завантаження (IE, Mini-redirector (WebDAV), FTP через Провідник Windows, і т.д.). .

AFD.sys впливає на всі з'єднання Winsock, тому це виправлення має застосовуватися до FTP, HTTP, HTTPS і т.д.

Крім того, це виправлення було перераховане вище десь, так що я не хочу брати кредит на це, якщо він працює для кого-небудь, однак у цій темі було так багато інформації, що я боявся, що це могло б бути приховано.

1
додано

Я бачу, що це трохи старше повідомлення, але це може допомогти іншим.

Коротше кажучи, потрібно ввімкнути "Автоматичне налаштування вікна":

netsh int tcp set global autotuninglevel=normal

CTCP нічого не означає без включеного вище.

Якщо ви вимкнете "Отримати автоматичне налаштування вікна", ви будете застрягати на розмірі пакетів 64 Кб, що має негативний вплив на довгі RTT у високошвидкісних з'єднаннях. Можна також експериментувати з опцією "обмежений" і "обмежений".

Very good reference: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

1
додано

Це захоплюючий потік і точно збігається з проблемами, які я використовував, використовуючи Win7/iperf для тестування пропускної здатності на довгих жирових трубах.

Рішення для Windows 7 полягає у виконанні наступної команди як на сервері iperf, так і на клієнті.

netsh interface tcp встановити глобальний autotuninglevel = експериментальний

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

netsh interface tcp show global

Рівень автоматичного налаштування вікна: вимкнено

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

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

netsh interface 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.
0
додано

Я не маю достатньо точок для коментарів, тому замість цього я напишу відповідь. Я маю подібну/ідентичну проблему (див. Запитання serverfault тут ). Моя (і, можливо, ваша) проблема - це буфер відправки клієнта iperf на вікнах. Він не перевищує 64 Кб. Передбачається, що Windows буде динамічно рости буфер, коли цей процес явно не визначається. Але динамічного зростання не відбувається.

Я не впевнений, що ваш графік масштабування вікна, який показує вікно відкриття до 500000 байт для вашого "повільного" випадку Windows. Я очікував, що цей графік відкриється лише для 64 000 байтів, якщо ви обмежені 5 Мбіт/с.

0
додано

Я сам зіткнувся з подібною ситуацією (моє питання тут ), і в кінці кінців мені довелося вимкнути евристику масштабування TCP, встановити вручну профіль автонабудови та включити CTCP:

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

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

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

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok. 
0
додано