Я работаю с парой совместно расположенных серверов CentOS Linux, расположенных за расширенным межсетевым экраном Sonicwall PRO 2040, работающим в режиме прозрачного моста.
На этих серверах возникает странная проблема с загрузкой файлов размером более нескольких мегабайт. Например, если я попытаюсь загрузить или FTP копию ядра Linux с kernel.org, первые ~ 1-2 МБ будут загружены со скоростью 600 + К / с, а затем пропускная способность упадет до 1 КБ / с.
Я просмотрел все настройки конфигурации брандмауэра на предмет подозрительности, но ничего не нашел. Что еще интереснее, я выполнил ту же загрузку с сервером Windows, сидящим за тем же брандмауэром, и он все время шел со скоростью 600+ К / с.
Кто-нибудь это видел? С чего начать поиск и устранение этой проблемы?
Мы тоже сталкиваемся с той же проблемой. Все, что больше того, что может быть передано при первоначальной загрузке (~ 3,7 МБ для нас), уходит до ~ 1–4 КБ в секунду независимо от доступной полосы пропускания.
Похоже, это проблема, характерная для брандмауэра SonicWall PRO 2040 и общая для него https://discussions.apple.com/message/12250946?messageID=12250946
Корень проблемы - это брандмауэр, и лучшее долгосрочное решение - найти в брандмауэре параметр, позволяющий включить параметр масштабирования окна TCP, а также правильно использовать коэффициент масштабирования окна TCP на исходной машине при инициализации окна. подключение.
Хотя эта статья относится к маршрутизаторам, та же логика применима к тому, что происходит с брандмауэром SonicWall Pro 2040, http://lwn.net/Articles/92727/:
Детали все еще выясняются, но может показаться, что некоторые маршрутизаторы в сети переписывают параметр TCP масштабирования окна для пакетов SYN по мере их прохождения. В частности, они, кажется, устанавливают коэффициент масштабирования равным нулю, но оставляют опцию на месте. Принимающая сторона видит вариант и отвечает собственным масштабным коэффициентом окна. На этом этапе инициирующая система считает, что ее масштабный коэффициент принят, и соответственно масштабирует свои окна. Другой конец, однако, считает, что коэффициент масштабирования равен нулю. В результате возникает недопонимание реального размера окна приема, когда система за брандмауэром считает, что он намного меньше, чем есть на самом деле. Если ожидаемый коэффициент масштабирования (и, следовательно, расхождение) велик, результатом будет в лучшем случае очень медленная связь. Во многих случаях небольшое окно может привести к тому, что пакеты не будут передаваться вообще, что полностью нарушит TCP между двумя затронутыми системами.
Подобно тому, что было упомянуто выше, есть обходные пути для отдельных машин - http://prowiki.isc.upenn.edu/wiki/TCP_tuning_for_broken_firewalls, отключив расширение TCP rfc1323, брандмауэру никогда не дается возможность передать коэффициент масштабирования окна TCP, равный 0, и вместо этого передает, что расширение rfc1323 не включено, предположительно используя максимально разрешенный размер окна TCP без расширения rfc1323 , что составляет 64 КБ.
Команды, которые мы использовали на наших различных машинах в качестве временного решения:
Ubuntu 10.10:
Изменение вступает в силу немедленно:
sudo sysctl -w net.ipv4.tcp_window_scaling=0
Постоянное изменение, после следующей перезагрузки:
sudo sh -c 'echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf'
Mac OS X:
Изменение вступает в силу немедленно:
sudo sysctl -w net.inet.tcp.rfc1323=0
Постоянное изменение, после следующей перезагрузки:
sudo sh -c 'echo "net.inet.tcp.rfc1323=0" >> /etc/sysctl.conf'
Win7:
Смотрите доступные варианты:
netsh interface tcp show global
Отключить команду (постоянная):
netsh interface tcp set global autotuning=disabled
В ответ на то, почему с Windows Server не было никаких проблем, я нашел эту статью - http://msdn.microsoft.com/en-us/library/ms819736.aspx
Масштабирование окна TCP согласовывается по запросу в Windows Server 2003 на основе значения, установленного для параметра SO_RCVBUF Windows Sockets при инициировании соединения. Кроме того, параметр Window Scale используется по умолчанию для соединения, если полученный сегмент SYN для этого соединения, инициированный одноранговым узлом TCP, содержит параметр Window Scale. TCP Windows Server 2003 не инициирует соединения с масштабированием окна по умолчанию. Чтобы указать стеку TCP Windows Server 2003 попытаться согласовать больший размер окна приема с помощью параметра Window Scale, установите для параметра реестра Tcp1323Opts значение 1.
Эти брандмауэры перестанут работать, если у вас включены предотвращение вторжений и / или антивирус. Особенно, если в качестве одного из типов для сканирования выбран TCP Stream. Он попытается создать в своей памяти весь файл, чтобы просканировать его ...
Временно отключите эти функции и посмотрите, повысится ли ваша производительность. Если да, то посмотрите на добавление ваших серверов в список исключений, чтобы вам не пришлось ронять штаны для всей сети.
Вы видите проблемы с загрузкой на сервер Linux из сети? Если нет, это должно быть связано с комбинацией Linux и брандмауэра. Можно ли на брандмауэре наблюдать за использованием ЦП или искать предупреждения? А как насчет сброса брандмауэра?
Может быть, после первого МБ или около того Linux автоматически внесет изменения в параметры TCP (или, может быть, на уровне 2), и брандмауэру это не нравится? Просмотр различных сетевых параметров в / proc может дать вам представление. Кроме того, дамп пакета в Linux может показать некоторые изменения в том, что происходит при замедлении.
Хотя я не нашел первопричины этого, я нашел быстрое обходное решение, которое позволяет мне передавать файлы через:
sysctl -w net.ipv4.tcp_window_scaling = 0
По умолчанию ядро для масштабирования окна TCP включено, но эта команда позволяет мне временно отключить его. Я не сохранял этот параметр постоянно через sysctl.conf, потому что я не уверен в его общем влиянии на производительность, но он работает в крайнем случае, а затем я могу вернуть его к 1, когда закончу.
Попробуйте изменить окна TCP на Sonicwall.
Здесь осталось выполнить много первоначальной диагностики.
Ошибки в /var/log/messages?
Ошибки в dmesg?
Потеря пакетов, подтвержденная в /sbin/ifconfig?
Проблемы с согласованием ссылки?
Есть ли какие-либо различия, физические или нет, между коробкой Windows и системой Linux?
Редактировать 1
Можете ли вы воспроизвести спектакль с использованием разных протоколов и сайтов?