Настройка окон для передачи TCP с высокой задержкой / высокой пропускной способностью

Как я могу ускорить передачу TCP-файлов в Windows 7 по каналу со скоростью 100 Мбит / с между Чикаго и Лондоном?

Прямо сейчас я передаю два файла по 4 ГБ за два сеанса sftp. Каждая передача файла выполняется со скоростью 500 КБ / с (4 Мбит / с). (B == байтов, b == бит, естественно). Это довольно медленно, поскольку тесты iperf показывают скорость 16,8 Мбит / сек для одного потока TCP. Это 2 МБ / сек.

Запуск второго сеанса sftp не влияет на скорость первого йота. Для меня это имеет смысл, поскольку я заметил, что мои тесты iperf были ограничены TCP - каждое соединение составляло 16 Мбит / с, что оставляет место для дополнительных подключений. Я смог заставить iperf насыщать мою линию, запустив много параллельных соединений, и это было линейное увеличение пропускной способности. То есть с 5 параллельными подключениями я достиг пропускной способности около 5x16 == 80 Мбит / с.

Замечу, что локальная передача файлов с использованием sftp составляет около 30 МБ / с ... неплохо. Поэтому я не думаю, что шифрование канала SSH является узким местом.

Я просмотрел Как лучше всего передать один большой файл по высокоскоростному каналу WAN с высокой задержкой? а также другие вопросы о сбоях сервера, и есть много интересных инструментов, но то, что я ищу, - это способ для меня настроить TCP-стек Windows, чтобы убедиться, что я получаю полные 2 МБ, по крайней мере ... и, возможно, больше, поскольку тесты iPerf проводились на ненастроенных машинах.

Я также замечаю, что когда я перетаскиваю файл на лондонский компьютер с моего файлового сервера в Чикаго, кажется, что он передается довольно неплохо (как видно из подробностей во время передачи), но через несколько минут он падает со скалы на скорости 10 Кбит / с. Это было очень странно.

Моя задержка стабильна и составляет около 88 мс, поэтому я считаю, что сетевая инфраструктура в порядке. У нас есть выделенная линия; это не VPN через Интернет или что-то в этом роде.

========

У меня есть виртуальная машина Linux, которая с точки зрения сети «близка» к моему рабочему столу Windows. То есть они находятся в разных подсетях, но обе машины подключены к коммутаторам, которые оба подключаются к другому коммутатору, который идет в Лондон. Прямо сейчас я использую sftp из Linux в Лондон, и он работает со скоростью 8 МБ / с, а мой рабочий стол продолжает работать со скоростью 500 КБ / с.

======== Хорошо, я поставил свой ноутбук с Linux на тот же переключатель, что и рабочий стол. Если в этот момент настольный компьютер выполняет sftp со скоростью 500 КБ / с, ноутбук с Linux отправляет файл 4Gig со скоростью 7,6 МБ / с. Конечно, на тот же сервер в Лондоне.

======== Другой тест: я использовал SecureFX от VanDyke Corp. У меня также есть Cygwin на моем ПК, и я просто пошел и использовал там команду CLI sftp. Я только что увеличил пропускную способность в пять раз ... Теперь я получаю 2,5 МБ / с вместо 500к! : - \ Это сравнимо с моими результатами iPerf со скоростью 16 Мбит / с. Этим я был бы доволен ... хотя теперь я замечаю, что мой ноутбук в три раза быстрее этого.

======== Другой тест: на моем лондонском компьютере я запустил копию файла Windows Explorer с моего файлового сервера в Чикаго в локально смонтированную папку Downloads (то есть на внутреннем жестком диске). Пропускная способность была стабильной 5,49 МБ / с в течение примерно 12 минут. Для меня это почти нормально! И снова копирование через SecureCRT было ужасно медленным - стабильные 500 КБ / с.

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

Спасибо за предложения и ответы.

======================

Хорошо, я проследовал по ссылкам Тодда Уилкокса и понял несколько вещей:

• Во-первых, по данным Microsoft, из https://technet.microsoft.com/en-us/library/cc957546.aspx?f=255&MSPPError=-2147217396, "TCP использует окно приема ... Для сетей Ethernet значение по умолчанию этой записи - 0x4470 (17 520, или 12 сегментов по 1460 байт каждый)" Ну, у меня глобальная сеть с задержкой 80 мс, так что это слишком мало.
• Я установил для GlobalMaxTcpWindowSize и TcpWindowSize в реестре (последний на моем адаптере) значение 1 MiB, затем перешел в командную строку и использовал netsh для изменения уровня автонастройки окна приема с нормального на отключенный. Скорость передачи по сети не изменилась, поэтому я перезагрузил машину и снова выполнил sftp со своего рабочего стола на лондонский сервер.
• Пропускная способность упала до 700 КБ / с. Что и говорить, я все поставил обратно и снова перезагрузился. Теперь моя пропускная способность вернулась к 2,1 МБ / с.
• Во время sftp Wireshark показывает странную зубчатую форму при масштабировании окна TCP, увеличиваясь с 64000 до 62000 байтов, а затем снова увеличивая их. Цикл длится около 35 секунд.
• Скажем, мой средний размер окна составляет 63000 байт. Следовательно, моя пропускная способность в битах в секунду должна быть (от http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/), Размер окна (байты) / Задержка (сек) == 700 КБ / с. Странно, что у меня получается 2,1 МБ / с ... это выше теоретического! Я уверен, что между ними нет ускорителей Wan или чего-то более сложного, чем Cisco 4948. Может быть, график масштабирования окна Wireshark не совпадает с размером окна, я не знаю, но Google сказал мне, что именно здесь я ' d найти размер окна TCP.
• Вещи не складываются. Хотя я действительно обнаружил, что мой тидлинг действительно все испортил, я не знаю, как окончательно определить размеры моих TCP-окон. Более того, часто размещаемая страница Брэда Хедлунда дает некоторые расчеты, которые не отражаются в моем опыте.
• Наконец, и это величайший урок, который я усвоил: я думаю, что оставлю достаточно хорошо в покое. Если мы обнаружим, что нам нужна более высокая пропускная способность, возможно, я порекомендую ускоритель WAN. Но поскольку мы идем через полмира, нам не следует ожидать феноменальной пропускной способности от одного TCP-соединения.