У нас есть два сервера в разных дата-центрах, географически разделенных несколькими сотнями миль. RTT (время приема-передачи) для эхо-запроса между ними составляет 61 мс по нашей VPN. Оба сервера подключены к гигабитному каналу WAN.
Любой тип копирования файлов, будь то SMB (перетаскивание), FTP (попробовал FileZilla, TFTP и т. Д.), Является мучительно медленным, около 1 Мбит / с. Я пробовал включать и отключать уровень автонастройки окна приема, многопоточное копирование и так далее. У наших брандмауэров много свободного места для ЦП, поэтому шифрование VPN не играет роли.
Я подумал о том, чтобы вручную установить размер окна TCP, потому что здесь он кажется очевидным кандидатом, но я понимаю, что Windows Server 2008 R2 игнорирует любой пользовательский параметр TcpWindowSize в реестре.
Обновить: Размеры окна TCP кажутся нормальными. Wireshark показывает размер окна 513 с масштабным коэффициентом 256 для расчетного размера окна 131328. Звучит правильно? Байт в полете остается около 9000 байтов во время текущей FTP-передачи.
Ударьте их простым бегом netcat - поток случайных данных, который отбрасывается на другом конце. Я знаю, что где-то есть версия для Windows. Используйте это как основу.
Если он не работает на полной скорости, понюхайте ваше соединение и сделайте это снова. Ищите потерю пакетов, неупорядоченные квитанции, неверные контрольные суммы и т. Д.
Изолируйте проблему. Бегать netcat внутри обеих сетей. Запустите его от границы, заменив роутер. Продолжайте до тех пор, пока вы не узнаете, в чем проблема, или не сообщите своему интернет-провайдеру, что проблема находится где-то в ссылке между сайтами, с подробной информацией о том, как проблема представляет собой.
Это ведение журнала. Отключите все журналы на сервере. Каждый пакет записывается на диск, что замедляет скорость передачи.
Следует учитывать, что многие из этих переводов очень болтливы. Это означает, что при передаче файлов идет много разговоров. У нас была такая же проблема, и мы обнаружили, что труба большего размера не помогает, так как накладных расходов слишком много.
Невозможно заставить все это общение идти быстрее света, и, поскольку существует так много поездок туда и обратно, большая труба часто не помогает. Вы можете посмотреть на ускоритель WAN. Что касается наших проблем с SharePoint и CRM на сайтах в нескольких городах, разница была поразительной.
Я не предлагаю конкретный продукт, а просто место для поиска технической информации. Мы рассмотрели множество различных продуктов и в конце концов остановились на устройствах Riverbed Steelhead. Мы установили пробные версии на трех объектах, и обращения в службу поддержки почти сразу прекратились. Вы можете легко увидеть разницу, используя веб-интерфейс и веб-трафик для SharePoint, который мы сократили до 90%, поэтому мы повысили скорость и сократили трафик, что снизило затраты. Поскольку мы не могли даже получить более быстрое соединение на нескольких сайтах, это было отличным решением.
Русло реки предполагает ускорение в 5-50 раз, а в некоторых случаях мы превышали его. У них есть много технической информации по проблеме, с которой вы столкнулись, которая, я думаю, поможет больше, чем я могу здесь рассказать Riverbed Steelhead