Тонкая настройка сетевого стека на windows хостах

Обновлено: 06.07.2024

Улучшение сетевого стека MS Windows.

Данный список далеко не полный, поэтому будет время от времени обновляться и дополняться.

Отключаем автотюниг окна приёма TCP:
netsh int tcp set heuristics disabled
или
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\services\Tcpip\Parameters\EnableWsd=0 (по-умолчанию: 1, рекомендуемое: 0)

Отключаем автотюнинг RWIN (окно приема):
netsh int tcp set global autotuninglevel=disabled

Включаем более агресивное увеличение окна отправки CTCP:
netsh int tcp set global congestionprovider=ctcp

Включаем согласование ECN, для избежания заторов на маршруте:
netsh int tcp set global ecncapability=enabled

Включаем RSS, для управления окном приема для распараллеленных процессов на многопроцессорных системах:
netsh int tcp set global rss=enabled

Включаем TCP Chimney Offload, для разгрузки всех процессов для всех сетевых адаптеров:
netsh int tcp set global chimney=enabled

Включаем DCA (прямой доступ к контроллеру):
netsh int tcp set global dca=enabled

Включаем опции TCP 1323:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\Tcpip\Parameters\Tcp1323Opt s=1

Включаем NetDMA:
netsh int tcp set global netdma=enabled

Включаем разгрузку CPU:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\Tcpip\Parameters\DisableTas kOffload=0

Включаем защиту от SYN атак:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\Tcpip\Parameters\SynAttackP rotect=2

После внесений вышеизложеннных изменений необходимо перезагрузить компьютер.

Это лишь самый небольшая часть из возможных настроек по оптимизации стека протоколов TCP/IP в MS Windows. Остальная часть настроек, которые позволяют защитить хост с MS Windows на борту от разного рода сетевых атак будет мною опубликована несколько позже.

По поводу кручения настроек TCP/IP существуют два диаметрально противоположных мнения: многие администраторы (а вместе с ними и авторы популярных книг!) считают, что разработчики уже сделали все, что нужно и любое вмешательство в этот четко отлаженный механизм может только навредить. В то же самое время в Интернете валяется множество руководств, обещающих если не путевку в рай, то радикальное увеличение производительности ценою изменения пары-тройки ключей в системном реестре.

Истина, как водится, где-то посередине. Операционные системы уже давно научились автоматически распознавать тип подключения, выбирая соответствующий ему набор настроек по умолчанию. Адаптивные алгоритмы динамически подстраиваются под характеристики канала и неквалифицированные "указания" пользователя действительно только мешают. Однако адаптивным алгоритмам свойственно ошибаться, а настройки по умолчанию далеко не всегда соответствуют характеристикам конкретно взятых каналов связи, разброс которых просто колоссален.

Какой прирост производительности может дать оптимизация параметров TCP/IP, при условии, что она выполнена правильно? Зависит от того, насколько настройки по умолчанию близки к свойствам используемого канала. В среднем, следует ожидать 20%. 30% выигрыша, однако в "клинических" случаях скорость увеличивается в несколько раз!

Прежде чем приступать к оптимизации

Вместо того, чтобы, засучив рукава, с первых же строк бросаться в бой, лучше сперва покурить и подумать. Допустим, мы имеем 10 мегабитный канал и скачиваем/раздаем файлы с превалирующей скоростью порядка мегабайта в секунду. Понятно, что никакими ухищрениями нам не удастся поднять производительность на сколь-нибудь заметную величину. Так стоит ли возиться?! К тому же, достаточно большое количество администраторов умышленно ущемляет отдачу в районе 50-100 Кбайт/с, предотвращая перегрузку сети. Какая уж тут оптимизация.

Другое дело, если наблюдаемая пропускная способность составляет менее 2/3 от заявленной аплинком. Тут уже без оптимизации никак не обойтись! Однако помимо TCP/IP-стека за производительность отвечают и другие системные компоненты - например, процессор. При большом количестве одновременно установленных соединений, загрузка ЦП может достигать 100%, особенно с учетом того, что в дешевом сетевом оборудовании подсчет контрольных сумм пакетов реализован на программном, а не аппаратном (как у дорогих моделей) уровне.

Еще одна виновница - видеокарта, надолго захватывающая шину безо всяких видимых причин, в результате чего все остальные периферийные устройства садятся на голодный паек и скорость ввода/вывода (в том числе и сетевого) многократно снижается. Обновление драйверов или отключение всех "агрессивных" настроек видеокарты обычно решают проблему даже без обращения к стеку TCP/IP.

Также не стоит забывать и о том, что чрезмерная фрагментация дискового пространства существенно замедляет скорость отдачи/приема файлов, что является одной из основных причин замедления загрузок web-страничек у конечных пользователей.

В общем, прежде чем лезть в TCP/IP стек, следует убедиться, что все остальные возможные причины устранены и узким местом являются именно настройки сетевых протоколов, а не что-то иное (внимание: "убедиться" это совсем не тоже самое, что "убедить себя").

MTU + MSS = .

MTU (Maximum Transmission Unit - Максимальный [размер] Передаваемого Пакета), вероятно, самый известный параметр TCP/IP, рекомендации по настройке которого можно встретить практически в любой статье по оптимизации TCP/IP. Сотни утилит предлагают свои услуги по определению предельно точного значения, но, увы, обещанного увеличения производительности как-то не достигается.

Рисунок 1. MTU и MSS.

Так в чем же дело?! Выкручиваем MTU до предела и. скорость падает до нуля. Почему? Причина в том, что с ростом размера пакетов увеличивается и время, необходимое для их повторной передачи в том случае, если пакет потерян или искажен. К тому же, промежуточные узлы имеют свои собственные настройки, и если размер передаваемого пакета, превышает текущий MTU, пакет разрезается на два или более пакетов, (т.е. фрагментируется) и эти фрагменты собираются воедино только на узле-приемнике, в результате чего пропускная способность уменьшается. Причем, если MTU узла отправителя лишь чуть-чуть превышает MTU промежуточного узла, то второй пакет состоит практически из одного заголовка, в результате чего зависимость скорость передачи от размера превращается в характерную пилообразную кривую (см. рис. 2).

Значения MTU, используемые Windows Server 2003 по умолчанию, приведены в таблице 1, однако при желании их можно изменить.

Запускаем утилиту "Редактора Реестра" и открываем в ней следующий раздел: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interfaceGUID. Видим там параметр MTU типа DWORD (а если не видим, то создаем) и вводим размер в байтах (0xFFFFFFFF означает "использовать значение MTU по умолчанию). Интерфейсы заданы GUID-идентификаторами и обычно их бывает намного больше одного. Как среди них найти интерфейс кабельного модема или конкретной сетевой карты? Да очень просто - по IP-адресу!

Рисунок 3. Тонкая настройка TCP/IP параметров через "Редактор Реестра".

В подавляющем большинстве случаев использование опций EnablePMTUDiscovery и EnablePMTUDiscovery приводит к снижению производительности и значение MTU лучше выбирать, отталкиваясь от таблицы 2, или действовать методом перебора.

Еще один параметр - MSS (Maximum Segment Size - Максимальный Размер Сегмента) отвечает за максимальный размер передаваемых данных за вычетом длины заголовка IP-пакета (см. рис. 1). Трогать его не следует, да и Windows это все равно не позволяет. В общем случае, MSS = MTU - 40 байт.

Параметр	Канал с скоростью <128 Kbps	Канал со скоростью >= 128
MTU (Maximum Transmission Unit)	576	1500
MSS (Maximum Segment Size)	536	1460

Таблица 1. Значения MTU и MSS по умолчанию в Microsoft Windows Server 2003.

MTU (байт)	Протокол	Нормативный RFC
576	по умолчанию	879
1500	PPP по умолчанию	1134
296	PPP (low relay)	1144
1500	Ethernet	895
1006	SLIP	1055
1492	PPPOE	2516

Таблица 2. Значения MTU, автоматически выбираемые Microsoft Windows Server 2003 в зависимости от типа подключения.

TCP Receive Window

Размер TCP-окна - малоизвестный, но чрезвычайно важный (в плане производительности) параметр, способный увеличить пропускную способность в несколько раз. Рассмотрим два узла - "A" и "B" и заставим узел "A" передавать узлу "B" данные, разбитые на сегменты, размер которых (как уже говорилось) определяется параметром MSS. Протокол TCP работает с установкой соединения, что обязывает его отправлять уведомления об успешно принятых сегментах. Неподтвержденные сегменты спустя некоторое время передаются узлом "A" вновь.

Промежуток времени между отправкой пакета и его получением называется латентностью (latency) и эта латентность в зависимости от типа и загруженности сети варьируется от 20 ms (и менее) до 100 ms (и более). Легко посчитать, что если бы подтверждался каждый сегмент, до даже в низколатентной сети реальная скорость передачи заметно отставала от ее реальных возможностей и была бы равна MTU / (2 * latency), что образует предел в 6 мегабит/сек, независящий от пропускной способности. Кошмар! Ну, как дальше жить?!

Допустим, мы имеем 10-мегабитный канал и передаем 7 сегментов по 1460 байт каждый, потратив на этого 8 ms. Если латентность составляет 100 ms, то. 100 ms + 92 ms = 192 ms. Мы, как идиоты, ждем подтверждения целых 192 ms и 96% времени узел "А" проводит в бездействии, используя лишь 4% пропускной способности канала. Это, конечно, крайний случай, но все-таки не настолько далекий от истины, как можно было бы подумать.

В процессе установки соединения, узел "A" предлагает узлу "B" установить размер окна, равный 16 Кбайтам (значение по умолчанию, прописанное в параметре ТсрWindowSize реестра, который при желании можно изменить). Размер окна всегда округляется до целого количества сегментов (см. параметр MSS).

Если размер окна превышает 64 Кбайт, система активирует алгоритм автоматического масштабирования, который, впрочем, работает только в том случае, если узел B также поддерживает этот механизм, поэтому лучше задавать размер TCP-окна вручную, руководствуясь таблицей 3. (Однако следует помнить, что слишком большое окно забивает канал пакетами, вызывая перегрузку сети, препятствующую пересылке уведомлений, в результате чего производительность падает).

Минимально необходимый размер TCP-окна
Скорость канала в (Килобит/сек)
500	1000	1500	2000	2500
Латентность канала (ms)	50	2K	5K	7K	10K	12K
	100	5K	10K	15K	20K	24K
	150	7K	15K	22K	29K	37K
	200	10K	20K	29K	39K	49K
	250	12K	24K	37K	49K	61K
Windows 9x/NT по умолчанию		8K
Windows Me/2000/XP Server 2003 по умолчанию		Скорость канала
		< 1 Мегабит/сек		100 Мегабит/сек		> 100 Мегабит/сек
		8 KB		17 KB		64 KB
Рекомендуемые значения		32-63K

Один за всех - все за одного!

Если клиенты локальной сети работают через Proxy-сервер, то для достижения максимальной производительности достаточно изменить размер TCP-окна непосредственно на самом сервере.

При работе же через NAT необходимо настроить TCP-окно на каждой рабочей станции, подключенной к локальной сети.

Медленный старт и выборочное подтверждение

Для предотвращения перегрузок сети в протокол TCP был введен так называемый "медленный старт" ("slow start"), подробно описанный в RFC 1122 и RFC 2581.

При создании нового TCP/IP соединения система устанавливает размер окна, равный одному сегменту. После получения подтверждения размер окна увеличивается вдвое и так продолжается вплоть до достижения максимально возможного размера.

Экспоненциальный рост ширины окна "съедает" совсем немного времени при передачи огромных файлов, но вот при установке множества TCP/IP соединений (характерных, например, для браузеров), обменивающихся крошечными порциями данных (классический пример которых - web-сервер), медленный старт заметно снижает эффективность широких каналов, кроме того даже при кратковременной перегрузке сети система сбрасывает размер окна в единицу, в результате чего график скорости отдачи файла из степной равнины превращается в холмистую терраформу (см. рис. 5).

Рисунок 5. "Медленный старт" и его последствия (CW - размер окна в сегментах).

Кроме того, система поддерживает специальный параметр Slow Start Threshold Size (Пороговый Размер [окна] Медленного Старта), по умолчанию равный 65636, но после распознавания ситуации "перегрузка сети", принимающий значение W / 2 и в дальнейшем является верхней границей экспоненциального роста параметра CW, что вызывает драматическое падение производительности (см. рис. 6).

Рисунок 6. Уменьшение размеров TCP-окна при обнаружении перегрузки сети.

Непосредственно отключить "медленный старт" штатными средствами Windows (не прибегая к патчу ядра) нельзя, однако если задействовать SACK-алгоритм (Selective Acknowledgement - Выборочное подтверждение, одно из расширений TCP-протокола, описанное в RFC 2018), "медленный старт" вырубается сам собой, становясь при этом никому не нужным пережитком старины.

Выборочное подтверждение передачи позволяет осуществлять повторную передачу неподтвержденных сегментов в одном окне (при неактивном SACK'е потерянные сегменты передаются один за другим в индивидуальном порядке). Другими словами, узел "А" повторно передает узлу "B" только реально потерянные сегменты, а не весь блок, в состав которого входят и успешно принятые пакеты. Очевидно, что максимальный прирост производительности будет наблюдаться на нестабильных каналах связи, регулярно теряющих пакеты.

Для активации алгоритма SACK достаточно установить параметр реестра SackOpts в значение "1" (значение по умолчанию для W2K и XP).

Время, работающее против нас

С подтвержденными сегментами все ясно. Если подтверждение пришло, сегмент можно считать успешно доставленным. Весь вопрос в том, сколько это самое подтверждение ждать и когда начинать повторную пересылку.

По умолчанию Windows Server 2003 ждет три секунды (при желании это значение можно изменить редактированием параметра TcpInitialRTT), после чего осуществляет повторную посылку неподтвержденных пакетов, а сам интервал ожидания увеличивают в соответствии с алгоритмом SRTT (Smoothed Round Trip Time - сглаженное оцененное время обращения). Максимальное количество повторных передач хранится в параметре TcpMaxDataRetransmissions (по умолчанию равному пяти), при достижении которого соединение разрывается.

Очевидно, что на нестабильных каналах, страдающих хроническими задержками, количество разрывов соединений можно сократить путем увеличения параметра TcpMaxDataRetransmissions до любой разумной величины (но не больше FFFFFFFFh). С другой стороны, для повышения производительности и "нейтрализации" пагубного влияния потерянных пакетов на быстрых каналах с малым временем задержки значение TcpInitialRTT рекомендуется уменьшить до одной секунды.

Главный недостаток статического таймера в его неспособности реагировать на кратковременные изменения характеристик канала связи. Выбранное системой время ожидания подтверждения оказывается то мало, то велико. Производительность падает, пользователь рвет и мечет, а пропускная способность "плавает" в очень широких пределах, заметно отставая от ожидаемой.

Задержанное подтверждение (Delayed Acknowledgement) - еще одно расширение протокола TCP/IP, описанное в RFC 1122 и впервые реализованное в W2K (а также в NT 4.0 SP4). Вместо того, чтобы подтверждать каждый полученный сегмент, узел "B" теперь отправляет подтверждение только в случае, если в течении определенного промежутка времени (хранящегося в параметре TcpDelAckTicks и по умолчанию равном 200 ms), от узла "A" не было получено ни одного сегмента. Другими словами, если сегменты идут дружными косяками и все работает нормально, подтверждения не отправляются до тех пор, пока в сети не возникнет "затор". Немного подождав, узел "B" высылает подтверждение обо всех полученных сегментах, давая узлу "A" возможность самостоятельно разобраться - какие сегменты потерялись в дороге и передать их повторно с минимальными накладными расходами.

К сожалению, задержка, выбранная компанией Microsoft по умолчанию, близка к латентности сетей с большими задержками, что сводит на нет все достоинства данного алгоритма и для повышения производительности значение TcpDelAckTicks рекомендуется увеличить в несколько раз. Соответственно, на низколатентных сетях его лучше уменьшить, ликвидируя никому не нужные простои.

Значения данного параметра могут варьироваться в диапазоне от 0 до 6, выражаемом в десятых долях секунды, т.е. единица соответствует 100 ms, а нуль трактуется как запрет на использование задержанных подтверждений.

При использовании TCP-окон большого размера рекомендуется задействовать алгоритм временных меток (TCP-Timestamps), описанный в RFC 1323, и автоматически адаптирующий значение таймера повторной передачи даже в условиях быстро меняющихся характеристик канала связи. За это отвечает параметр Tcp1323Opts, который, будучи установленным в значение 3, разрешает использование всех расширений RFC 1323.

Заключение

В статье рассмотрены лишь некоторые опции TCP/IP-протокола, в наибольшей степени ответственные за его производительность. Но помимо них существует и другие, за разъяснением которых мы оправляем читателя по ссылкам ниже.

Слишком часто разработчики винят недостаточную производительность сети, хотя на самом деле зачастую причина в неправильно настроенном программном обеспечении. В этой статье описаны некоторые утилиты для анализа и настройки сети, которые позволяют разработчикам оптимизировать свои приложения для оптимизации сетевых возможностей.

Как-то раз мой друг Боб пришел ко мне с вопросом. Он написал программу на Java, которая копировала 100 МБ файлы с его компьютера под управлением Windows XP в его офисе на Linux-сервер в региональный офис компании. В обоих офисах используются 100Мбит сети Ethernet, соединенные через 155Mbps VPN канал. Однако он был очень неприятно удивлен тем, что измеренная скорость передачи была ниже 4Мбит, и попросил меня объяснить причину такого поведения.

В результате я написал эту статью, чтобы объяснить причину такого поведения и что должен сделать Боб, чтобы максимально использовать пропускную способность своей сети. Слишком часто разработчики винят недостаточную производительность сети, хотя на самом деле зачастую причина в неправильно настроенном программном обеспечении. В этой статье описаны некоторые утилиты для анализа и настройки сети, которые позволяют разработчикам оптимизировать свои приложения для оптимизации сетевых возможностей.

Как Работает TCP

Самый распространенный сетевой протокол, используемый в Интернет это Transmission Control Protocol, или TCP . TCP использует «окно перегрузки» - число пакетов, которое должен послать или принять стек, прежде чем перейти в режим ожидания сигнала подтверждения. Чем больше размер этого окна, тем выше пропускная способность. Алгоритмы «медленного запуска» и «предотвращения перегрузки» определяют размер окна перегрузки. Максимальный размер окна перегрузки зависит от размера буфера, который ядро отводит для каждого сокета. Для каждого сокета существует значение буфера, установленное по умолчанию, которое программы могут изменять, используя системный вызов библиотек перед открытием сокета. Для некоторых операционных систем существует определенный максимум размера буфера на уровне ядра. Вы можете установить собственное значение буфера как для отправляющего, так и для принимающего конца сокета.

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

Рассчитываем Размер Буфера TCP

Предположим, что сеть не перегружена и пакеты в ней не теряются, тогда пропускная способность сети зависит прямо пропорционально от размера TCP буфера и сетевой задержки. Сетевая задержка есть не что иное, как количество времени, необходимое пакету для прохода через сеть. Чтобы сосчитать максимальную пропускную способность, нужно:

Пропускная способность = размер буфера / задержка

В обычной сети задержка между двумя офисами составит около 40ms, а в Windows XP размер буфера по умолчанию равен 17,520 байт. Значит, максимальная пропускная способность будет равна:

Размер буфера по умолчанию для Mac OS X установлен в 64K, таким образом, при использовании Mac OS X у Боба получилось бы лучше, однако были бы достигнуты далеко не 100Mbps, которые по идее должны быть.

(Люди, которые постоянно используют сеть, думают о битах в секунду, тогда как все оставшиеся думают о байтах, что часто приводит к путанице.)

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

Программа ping даст вам округленное время (round trip time - RTT) для сетевого соединения, что в два раза больше задержки. Формула принимает следующий вид:

Для сети Боба ping вернул RTT в 80ms. Это значит, что размер буфера TCP должен быть:

Боб знал скорость VPN канала компании, но часто вы не знаете о пропускной способности сетевого маршрута. Определить пропускную способность сети иногда очень сложно. На сегодняшний день самой большой пропускной способностью является 1Gbps (в США, Европе и Японии), получается, что узкое место это местные сети на обоих концах. В моей практике я встречал в основном офисы, где компьютеры объединены 100Mbps сетью Ethernet. Тогда имеем следующую картину: 100Mbps=12MBps, что, согласитесь, совсем неплохо.

Перенастройка размера буфера никак не повлияет на производительность в сетях, где регламентированная скорость составляет 10Mbps или ниже; например, с хостами, соединенными через DSL, кабельный модем, ISDN, или линию T1. Существует программа pathrate, которая выполняет хорошую работу: оценивает пропускную способность. Но она не позволяет проводить глубокий анализ полученных временных рядов. Например, не ставилась задача получать различные функции распределения, а так же недостаточен набор параметров, которые можно варьировать при проведении измерений. Программа работает только на платформе Linux и требует возможности логина на оба компьютера.

Устанавливаем размер буфера TCP

Итак, имеем две настройки, которые нужно оптимизировать: размер буфера TCP по умолчанию и максимальный размер буфера. С правами пользователя можно изменить размер буфера по умолчанию, но для изменения его максимального размера требуются права администратора. Заметьте, что большинство сегодняшних Unix-Like систем по умолчанию имеют значение максимального размера буфера TCP всего лишь 256K. В Windows нет максимального размера буфера по умолчанию, но администратор может его установить. Очень важно изменить размеры буферов у посылающей и принимающей машин. Изменение только отправляющего буфера не даст ничего, т.к. TCP согласовывает размер буфера с меньшим из двух. Это означает, что не обязательно устанавливать оптимальный размер буфера на отправляющей и принимающей машинах. Обычно делают следующее: устанавливают размер буфера на серверной стороне довольно большим (например 1,024K) и затем позволяют клиенту определить и установить «оптимальное» значение для данного сетевого маршрута. Чтобы установить размер буфера TCP, используйте метода setSendBufferSize и setReceiveBufferSize в Java, или вызов setsockopt в С. Ниже представлен пример установки размеров буфера ТСР в пределах приложения на Java:

Хорошей идеей будет вызвать getSendBufferSize (или getReceiveBufferSize) после установки размера буфера. Таким образом, мы удостоверимся, что наша ОС поддерживает буферы таких размеров. Вызов setsockopt не вернет ошибку, если вы используете значение, большее чем максимальный размер буфера, но попросту будет использовать максимальный размер вместо значения, которое установили вы. Linux загадочным образом удваивает значение, которое вы передаете для размера буфера, так что когда вы делаете getSendBufferSize / getReceiveBufferSize и видите в два раза больше, чем указали, не волнуйтесь - для Linux это «нормально».

А вот и пример на С:

Фрагмент кода на С, проверяющий текущий размер буфера:

Устанавливаем Максимальный Размер буфера TCP

Для большинства соединений невозможно увеличить предопределенный системой максимальный размер ТСР буфера. Например, возьмем соединение в 100Mbps между Калифорнией и Великобританией, время задержки RTT которого 150 мсек. Оптимальный размер буфера для такого соединения будет равен 1,9 МБ, что в 30 раз больше чем размер буфера по умолчанию и в 7,5 раз больше, чем максимальный размер буфера ТСР в Linux.

Чтобы поменять параметры ТСР в Linux, добавьте следующие строки в файл / etc/sysctl.conf , и затем запустите sysctl -p. Теперь наши настройки будут применяться во время загрузки.

Устанавливайте максимальные размеры буферов таким образом, чтобы полностью использовать ресурсы соединения. В Windows не требуется вносить каких-либо изменений, как например максимальный размер буфера ТСР по умолчанию (GlobalMaxTcpWindowSize) не определяется. На моем сайте TCP Tuning Guide web site можно найти информацию о том, как установить максимальный размер буфера в других операционных системах.

От Теории к Практике

Наверняка сейчас у вас возник вопрос «А как же я могу осуществить все эти возможности в реальных условиях? Доверить ли пользователям установку размера буфера? Стоит ли подсчитать оптимальный размер буфера для пользователя? Или может вообще стоит установить больший буфер и больше не вспоминать об этом?»

Обычно, я предлагаю следующее для большинства приложений, ориентированных на высокоскоростную (более 40Mbps), с большой задержкой (RTT > 10ms) сеть. Ваш клиент должен запустить ping, чтобы определить RTT и затем просто принять пропускную способность, равную 100Mbps. Ping трафик блокируется некоторыми сайтами. В этом случае можно воспользоваться утилитой synack, которая использует ТСР вместо ICMP для определения RTT. Если ваши пользователи разбираются в сетях, то можно предоставить им самим самостоятельно выбирать размер TCP буфера. Не правильно тупо устанавливать большие размеры буферов для всех сетевых маршрутов, особенно если приложение могут запустить через медленные линии, такие как DSL или модемы.

Linux на Помощь

Начиная с версии 2.4, в Linux добавлена возможность автоподстройки ТСР буфера отправителя . Это означает, что отправителю больше не нужно задумываться о вызове setsockopt(). Однако все еще следует выполнять setsockopt() на стороне получателя, и вам придется подкорректировать максимальный размер буфера при автоподстройке, что по умолчанию составляет лишь 128 кБ. Начиная с Linux 2.6.7, была добавлена функция автоподстройки для серверной стороны, таким образом вам не нужно больше думать о получателе. Свершилось! К несчастью, максимальный размер буфера ТСР все еще маленький - но хотя бы теперь это проблема системного администрирования, а не программиста.

Мои начальные результаты довольно-таки внушительные. После увеличения максимальных буферов ТСР, при соединении в 1Gbps через США (RTT = 67ms), производительность с 10Mbps при использовании Linux 2.4 поднялась до 700Mbps при использовании Linux 2.6.12, ускорение в 70 раз! На соединении из Калифорнии в Великобританию (RTT = 150 мсек), скорость с 4Mbps на Linux 2.4 выросла до 560Mbps - ускорение в 140 раз. Этого удалось достичь всего лишь увеличением максимального размера буфера ТСР.

В Linux 2.6 кроме того включены некоторые улучшения ТСР, что означает, что скорость можно увеличить еще в несколько раз. Особенно то, что в Linux 2.6 теперь используется алгоритм контроля перегрузки BIC (BIC - bus interface controller, контроллер магистрального интерфейса), который задумывался для увеличения производительности ТСР при использовании высокоскоростных линий и большими задержками. Ручная подстройка Linux 2.4 при использовании тех же соединений дает пропускную способность в 300Mbps через США и 70Mbps до Великобритании. Надеюсь, в скором времени все эти прелести появятся в Windows.

Наладка Сети

Если все попытки повысить пропускную способность закончились неудачей, то, скорее всего причина в самой сети. Итак, сначала попробуйте netstat -s, чтобы посмотреть количество повторных передач. Если их много, то это говорит о том, что сеть перегружена, построена на плохом «железе» или вовсе с нарушением топологии. Также повторные передачи происходят в случае, когда отправляющая машина намного быстрее принимающей. Также обратите внимание на число ошибок, возвращаемых netstat- большое число ошибок также говорит о проблеме в самой сети. Мне самому с трудом верится, но очень часто причина неполадок LAN с сетями 100BT заключается в том, что хост настроен на работу в полном дуплексе, а свитч Ethernet работает в режиме полудуплекса, или наоборот. Новое оборудование автоматически согласует дуплексы, тогда как со старым могут возникнуть проблемы, результатом будет работающая, но ужасно медленная сеть. Лучше всего работать в режиме полного дуплекса, но некоторое старое оборудование 100ВТ поддерживает только полудуплекс. Смотрите TCP Tuning Guide, чтобы узнать, как проверить настройки дуплекса для вашего компьютера.

Internet2's Network Diagnostic Tool (NDT) - отличная утилита, предназначенная для определения проблем с перегрузкой и дуплексом. NDT это Java аплет, который можно запустить с одного из NDT серверов.

Обратите Внимание на Программу scp

Для копирования файлов через Интернет обычно пользуются программой scp. К сожалению, тонкая настройка ТСР не поможет пропускной способности >scp, потому что в scp используетсяOpenSSL, в котором используются статически определенные потоки буферов. Эти буферы действуют на пропускную способность сети как узкое место, особенно в сетях с длинной задержкой и высокими скоростями. Питсбургская страница Сверхвысокопроизводительного Центра High Performance SSH/SCP объясняет это более подробно и, кроме того, там имеется патч для OpenSSL, устраняющий эту проблему.

Кто онлайн

Гость Гость Гость Гость Гость Гость Гость Гость Гость
Всего: 9

Именинники

Первый сервер

Второй сервер

Третий сервер

Оптимизация TCP/IP стека ОС Windows

* На этой вкладке, в списках URLs выбираем любой их хостов(4.) и жмём кнопку LargesMTU(5.), запоминаем или записываем полученное значение (6.). Для точности, можете прогнать тестирование(ping) для 2-ух, 3-х узлов из меню(4.). Разницы в результате быть не должно. На этой вкладке больше делать нечего, возвращаемся к первой.
На ней прописываем полученный результат теста в строку(7.)
Лучше наверное разбить на 2-а этапа, настройку. Далее жмём кнопку Apply changes(первый скрин, обведена красным но не промаркирована). В появившемся окне внизу слева, обязательно ставим галочку в опции Backup и жмём ОК.
В появившемся окне вам прдложат перезагрузку,ОК - немедленно, и второй вариант(кнопку не помню) отложенный.
Короче, отказываемся, и переходим ко второй части.

В папке с программой появились 2-а файлика, это слепки веток реестра, FirstBackup.spg это слепок ветки, на момент запуска утилиты, но до внесения каких-либо изменений, он вам понадобиться(?) для сброса настроек в первоночальное состояние. А второй, sg_backup_2016-xx-xx-xxxx.spg и последующие типичные(где xx-xx-xxxx это мес-число-время) будут копией веток на дату внесения крайних изменений(короче это для тестирования разных комбинаций параметров).

* Далее, запускаем утилиту опять(от имени администратора), и на первой вкладке опции областей C и D (выделены чёрным) приводим ко значениям как на первом скриншоте.

* Затем, тоже самое проделываем с опциями областей E F G, как на снимке ниже.

Далее, жмём кнопку Apply changes, затем в следующем окне ставим галочку Backup и жмем ОК.
Перезагружайтесь и пробуйте поиграть.
Значение изменяемых параметров и цель изменения опишу попозже(может быть).

Ссылки для самостоятельных изысканий

И вот еще, что можете попробывать, но если эта опция потдерживается сетевой картой.

В диспетчере устройств, ноходите сетевую карту, "вызываете" ее свойства и на вкладке дополнительно,
ишете опцию Large Send Offload (ее может не быть) и отключаете ее (disabled).

Читайте также: