в такому стані процес копіювання міг перебувати як завгодно довго, абсолютно не реагуючи ні на які дії користувача стосовно до вікна.
Перед нами постає резонне питання, що ж це за динамічне вікно передачі і який вплив ця технологія надає на процес передачі файлів між хостами в мережі? Стосовно до протоколу TCP / IP визначені такі поняття як вікно прийому TCP (TCP Receive Window, RWIN) і вікно передачі TCP (TCP Send Window). Насправді це одне логічне вікно, просто створюється воно як на приймаючої, так і на передавальної сторони при ініціалізації TCP з'єднання між двома вузлами мережі, має на обох сторонах однакову розмірність, вдає із себе, фактично, типовий буфер (блок даних в пам'яті). Вікно використовується для контролю швидкості потоку приймаючою стороною, а так само для вказівки кількості даних, які можуть бути відправлені відправником за один прийом, воно так само визначає, який обсяг непідтверджених даних може знаходитися в дорозі від відправника до одержувача. Відправник може посилати тільки байти переданого потоку, що знаходяться в даний момент всередині цього логічного вікна. Вікно переміщається по вихідний байтовому потоку даних на відправляє стороні і входить байтовому потоку даних на приймаючій стороні. Висловлюючись інакше, частина цих в вихідному байтовому потоці, який відправнику дозволено відправляти, відповідає ділянці даних у вхідному байтовому потоці, який одержувач може прийняти.
Ключовий момент полягає в тому, що дане вікно може масштабироваться протягом життя сесії TCP з метою оптимального використання пропускної здатності каналу.
Відмінна технологія, і все було б добре, якби всі пристрої вміли обробляти алгоритм автоматичної настройки вікна прийому TCP.
Але ж ні, величезна кількість мережевих маршрутизаторів, фаєрволів і інших "просунутих" пристроїв цього робити не вміють, а деякі вже ніколи і не навчаться по причині того, що виробники не випускають до них нові версії прошивок.
Для вирішення проблеми зависання копіювання файлів по мережі до нас на виручку приходить системна утиліта командного рядка netsh. призначена для управління параметрами конфігурації мережі локальної або віддаленої станції.
Наведені нижче команди необхідно виконувати з-під облікового запису з правами локального адміністратора.
Давайте подивимося поточний стан деяких параметрів настройки інтерфейсу TCP / IP, виконавши наступну команду:
netsh interface tcp show global
У відповідь ми отримали висновок поточну конфігурацію TCP / IP, серед яких нас цікавить "Рівень автонастройки вікна отримання", який за замовчуванням має значення "normal":
Параметр може набувати таких значень:
- disabled наказує використовувати фіксоване значення вікна прийому TCP. Значення за замовчуванням = 64 кілобайт (65535 байт). Повна сумісність зі застарілим мережевим обладнанням;
- highlyrestricted дозволяє вікна прийому TCP виходити за межі стандартних значень, в розумних межах;
- restricted дозволяє вікна прийому TCP виходити за межі стандартних значень, ще більш вільно;
- normal установка за замовчуванням. Допускає збільшення вікна прийому TCP з урахуванням більшості можливих сценаріїв обміну;
- experimental дозволяє вікна прийому TCP збільшуватися до максимальних значень (16+ мегабайт). Не рекомендується, тому що це може викликати падіння продуктивності в більшості можливих сценаріїв обміну;
Після застосування нижчеописаних команд буде потрібно перезавантаження операційної системи.
Для початку переводимо рівень автонастройки вікна отримання в значення "disabled", фактично відключаючи автонастройку і наказуючи використання фіксованого значення:
netsh interface tcp set global autotuninglevel = disabled
Вищенаведена команда повністю усуває зависання копіювання файлів, однак, опціонально, я б рекомендував виконати ще й наступну.
Наступна команда відключає масштабування на приймаючій стороні (receive-side scaling), яке розподіляє мережеву навантаження між декількома ядрами процесора в багатопроцесорної системі:
netsh interface tcp set global rss = disabled
У ситуації, коли обмін даними відбувається між двома, безпосередньо підключеними один до одного, станціями під управлінням операційних систем Windows версій Vista і більш пізніх, то проблема ніколи себе не виявляє, однак в сучасній корпоративної мережевому середовищі досить часто застосовуються керовані комутатори та інші складні мережеві пристрою, і ось саме їх побратими з застарілим мікропрограмним забезпеченням, які не підтримують динамічне вікно передачі, і стають джерелом проблеми зависання копіювання файлів і ряду смеж их. Саме в нашому випадку винуватцем був Cisco Catalyst 3750 v2 з версією Cisco IOS Software молодше 12.3 (15). На додаток до цієї конфігурації, теоретично помилка може проявлятися при передачі між двома станціями, підключеними безпосередньо, одна з яких працює під управлінням Windows версії Vista і більш пізніх, а інша під управлінням старих операційних систем, таких як Windows XP і більш ранніх, проте я особисто подібну зв'язки не тестував.