Слишком часто разработчики винят недостаточную производительность сети, хотя на самом деле зачастую причина в неправильно настроенном программном обеспечении. В этой статье описаны некоторые утилиты для анализа и настройки сети, которые позволяют разработчикам оптимизировать свои приложения для оптимизации сетевых возможностей.
Как-то раз мой друг Боб пришел ко мне с вопросом. Он написал программу на Java, которая копировала 100 МБ файлы с его компьютера под управлением в его офисе на Linux-сервер в региональный офис компании. В обоих офисах используются 100Мбит сети Ethernet, соединенные через 155Mbps VPN канал. Однако он был очень неприятно удивлен тем, что измеренная скорость передачи была ниже 4Мбит, и попросил меня объяснить причину такого поведения.
В результате я написал эту статью, чтобы объяснить причину такого поведения и что должен сделать Боб, чтобы максимально использовать пропускную способность своей сети. Слишком часто разработчики винят недостаточную производительность сети, хотя на самом деле зачастую причина в неправильно настроенном программном обеспечении. В этой статье описаны некоторые утилиты для анализа и настройки сети, которые позволяют разработчикам оптимизировать свои приложения для оптимизации сетевых возможностей.
Как Работает TCP
Самый распространенный сетевой протокол, используемый в Интернет это Transmission Control Protocol, или . TCP использует «окно перегрузки» - число пакетов, которое должен послать или принять стек, прежде чем перейти в режим ожидания сигнала подтверждения. Чем больше размер этого окна, тем выше пропускная способность. Алгоритмы «медленного запуска» и «предотвращения перегрузки» определяют размер окна перегрузки. Максимальный размер окна перегрузки зависит от размера буфера, который ядро отводит для каждого сокета. Для каждого сокета существует значение буфера, установленное по умолчанию, которое программы могут изменять, используя системный вызов библиотек перед открытием сокета. Для некоторых операционных систем существует определенный максимум размера буфера на уровне ядра. Вы можете установить собственное значение буфера как для отправляющего, так и для принимающего конца сокета.
Чтобы достичь максимальной скорости, важно использовать оптимальный размер буфера для TCP сокета для используемого подключения. Если буферы слишком маленькие, окно перегрузки TCP некогда не откроется полностью, таким образом отправитель не сможет работать по полной. Если буферы слишком большие, отправитель попросту завалит получателя, что приведет к тому, что получатель просто будет резать пакеты и окно перегрузки выключится. Наиболее вероятна такая ситуация когда отправляющий хост по производительности лучше, чем получающий. Слишком большое окно на отправляющей стороне это не проблема, пока существует некоторый избыток памяти.
Рассчитываем Размер Буфера TCP
Предположим, что сеть не перегружена и пакеты в ней не теряются, тогда пропускная способность сети зависит прямо пропорционально от размера TCP буфера и сетевой задержки. Сетевая задержка есть не что иное, как количество времени, необходимое пакету для прохода через сеть. Чтобы сосчитать максимальную пропускную способность, нужно:
Пропускная способность = размер буфера / задержка
В обычной сети задержка между двумя офисами составит около 40ms, а в Windows XP размер буфера по умолчанию равен 17,520 байт. Значит, максимальная пропускная способность будет равна:
17520 Байт / .04 секунды = .44 МБ/сек = 3.5 Мб/сек
Размер буфера по умолчанию для Mac OS X установлен в 64K, таким образом, при использовании у Боба получилось бы лучше, однако были бы достигнуты далеко не 100Mbps, которые по идее должны быть.
65936 Байт / .04 сек = 1.6 МБ/сек = 13 Мб/сек
(Люди, которые постоянно используют сеть, думают о битах в секунду, тогда как все оставшиеся думают о байтах, что часто приводит к путанице.)
Большинство экспертов по сетям соглашаются, что оптимальный размер буфера для определенной сети равен удвоенному произведению задержки и полосы пропускания:
Размер буфера = 2 * задержка * полоса пропускания
Программа ping даст вам округленное время (round trip time - RTT) для сетевого соединения, что в два раза больше задержки. Формула принимает следующий вид:
Размер буфера = RTT * полоса пропускания
Для сети Боба ping вернул RTT в 80ms. Это значит, что размер буфера TCP должен быть:
08 секунд * 100 Мбс / 8 = 1 МБ
Боб знал скорость 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:
Java.net.Socket skt; int sndsize; int sockbufsize; /* установка буфера отправки */ skt.setSendBufferSize(sndsize); /* проверим получили ли мы то, что просили */ sockbufsize = skt.getSendBufferSize(); /* установим буфер получения */ skt.setReceiveBufferSize(sndsize); /* еще разок проверим получили ли мы то, что хотели */
sockbufsize = skt.getReceiveBufferSize();
Хорошей идеей будет вызвать getSendBufferSize (или getReceiveBufferSize) после установки размера буфера. Таким образом, мы удостоверимся, что наша ОС поддерживает буферы таких размеров. Вызов setsockopt не вернет ошибку, если вы используете значение, большее чем максимальный размер буфера, но попросту будет использовать максимальный размер вместо значения, которое установили вы. Linux загадочным образом удваивает значение, которое вы передаете для размера буфера, так что когда вы делаете getSendBufferSize / getReceiveBufferSize и видите в два раза больше, чем указали, не волнуйтесь - для Linux это «нормально».
А вот и пример на С:
Int skt, sndsize; err = setsockopt(skt, SOL_SOCKET, SO_SNDBUF, (char *)&sndsize, (int)sizeof(sndsize)); err = setsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)&sndsize, (int)sizeof(sndsize));
Фрагмент кода на С, проверяющий текущий размер буфера:
Int sockbufsize = 0; size = sizeof(int); err = getsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)&sockbufsize, &size);
Устанавливаем Максимальный Размер буфера TCP
Для большинства соединений невозможно увеличить предопределенный системой максимальный размер ТСР буфера. Например, возьмем соединение в 100Mbps между Калифорнией и Великобританией, время задержки RTT которого 150 мсек. Оптимальный размер буфера для такого соединения будет равен 1,9 МБ, что в 30 раз больше чем размер буфера по умолчанию и в 7,5 раз больше, чем максимальный размер буфера ТСР в Linux.
Чтобы поменять параметры ТСР в Linux, добавьте следующие строки в файл / etc/sysctl.conf , и затем запустите sysctl -p. Теперь наши настройки будут применяться во время загрузки.
# увеличиваем максимальный размер буфера ТСР net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # увеличиваем ограничения автоподчтройки буфера ТСР Linux # мин, по умолчанию, и максимальное число байт, которое можно использовать net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216
Устанавливайте максимальные размеры буферов таким образом, чтобы полностью использовать ресурсы соединения. В 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, устраняющий эту проблему.
Проблемы при регистрации на сайте? НАЖМИТЕ СЮДА ! Не проходите мимо весьма интересного раздела нашего сайта - проекты посетителей . Там вы всегда найдете свежие новости, анекдоты, прогноз погоды (в ADSL-газете), телепрограмму эфирных и ADSL-TV каналов , самые свежие и интересные новости из мира высоких технологий , самые оригинальные и удивительные картинки из интернета , большой архив журналов за последние годы, аппетитные рецепты в картинках , информативные . Раздел обновляется ежедневно. Всегда свежие версии самых лучших бесплатных программ для повседневного использования в разделе Необходимые программы . Там практически все, что требуется для повседневной работы. Начните постепенно отказываться от пиратских версий в пользу более удобных и функциональных бесплатных аналогов. Если Вы все еще не пользуетесь нашим чатом , весьма советуем с ним познакомиться. Там Вы найдете много новых друзей. Кроме того, это наиболее быстрый и действенный способ связаться с администраторами проекта. Продолжает работать раздел Обновления антивирусов - всегда актуальные бесплатные обновления для Dr Web и NOD. Не успели что-то прочитать? Полное содержание бегущей строки можно найти по этой ссылке .
Тонкая настройка параметров TCP/IP под толстые каналы
Пропускная способность локальных сетей и Интернет-каналов неуклонно растет, однако вместе с ней растут и потребности, вызывающие естественное желание выжать из TCP/IP-стека максимум возможного, чем мы сейчас, собственно, и займемся, главным образом акцентируя внимания на Windows Server 2003, хотя описанные технология оптимизации справедливы и для рабочих станций, собранных на базе W2K/XP.
Введение
По поводу кручения настроек TCP/IP существуют два диаметрально противоположных мнения: многие администраторы (а вместе с ними и авторы популярных книг!) считают, что разработчики уже сделали все, что нужно и любое вмешательство в этот четко отлаженный механизм может только навредить. В то же самое время в Интернете валяется множество руководств, обещающих если не путевку в рай, то радикальное увеличение производительности ценою изменения пары-тройки ключей в системном реестре.
Истина, как водится, где-то посередине. Операционные системы уже давно научились автоматически распознавать тип подключения, выбирая соответствующий ему набор настроек по умолчанию. Адаптивные алгоритмы динамически подстраиваются под характеристики канала и неквалифицированные "указания" пользователя действительно только мешают. Однако адаптивным алгоритмам свойственно ошибаться, а настройки по умолчанию далеко не всегда соответствуют характеристикам конкретно взятых каналов связи, разброс которых просто колоссален.
Какой прирост производительности может дать оптимизация параметров TCP/IP, при условии, что она выполнена правильно? Зависит от того, насколько настройки по умолчанию близки к свойствам используемого канала. В среднем, следует ожидать 20%...30% выигрыша, однако в "клинических" случаях скорость увеличивается в несколько раз!
Прежде чем приступать к оптимизации
Вместо того, чтобы, засучив рукава, с первых же строк бросаться в бой, лучше сперва покурить и подумать. Допустим, мы имеем 10 мегабитный канал и скачиваем/раздаем файлы с превалирующей скоростью порядка мегабайта в секунду. Понятно, что никакими ухищрениями нам не удастся поднять производительность на сколь-нибудь заметную величину. Так стоит ли возиться?! К тому же, достаточно большое количество администраторов умышленно ущемляет отдачу в районе 50-100 Кбайт/с, предотвращая перегрузку сети. Какая уж тут оптимизация...
Другое дело, если наблюдаемая пропускная способность составляет менее 2/3 от заявленной аплинком. Тут уже без оптимизации никак не обойтись! Однако помимо TCP/IP-стека за производительность отвечают и другие системные компоненты - например, процессор. При большом количестве одновременно установленных соединений, загрузка ЦП может достигать 100%, особенно с учетом того, что в дешевом сетевом оборудовании подсчет контрольных сумм пакетов реализован на программном, а не аппаратном (как у дорогих моделей) уровне.
Еще одна виновница - видеокарта, надолго захватывающая шину безо всяких видимых причин, в результате чего все остальные периферийные устройства садятся на голодный паек и скорость ввода/вывода (в том числе и сетевого) многократно снижается. Обновление драйверов или отключение всех "агрессивных" настроек видеокарты обычно решают проблему даже без обращения к стеку TCP/IP.
Также не стоит забывать и о том, что чрезмерная фрагментация дискового пространства существенно замедляет скорость отдачи/приема файлов, что является одной из основных причин замедления загрузок web-страничек у конечных пользователей.
В общем, прежде чем лезть в TCP/IP стек, следует убедиться, что все остальные возможные причины устранены и узким местом являются именно настройки сетевых протоколов, а не что-то иное (внимание : "убедиться" это совсем не тоже самое, что "убедить себя" ).
MTU + MSS = ???
MTU (M aximum T ransmission U nit - Максимальный [размер] Передаваемого Пакета), вероятно, самый известный параметр TCP/IP, рекомендации по настройке которого можно встретить практически в любой статье по оптимизации TCP/IP. Сотни утилит предлагают свои услуги по определению предельно точного значения, но, увы, обещанного увеличения производительности как-то не достигается.
MTU задет наибольший возможный размер отправляемого IP-пакета (вместе с заголовком), нарезая отправляемые данные на порции фиксированного размера. Чем больше MTU, тем ниже накладные расходы на передачу служебной информации, а, значит, выше "КПД" канала. С другой стороны, маршрутизаторы сваливают пакеты, поступающие от разных узлов, в общую очередь и потому гораздо выгоднее отправить один большой пакет, чем два маленьких, причем чем сильнее загружен маршрутизатор, тем больший выигрыш мы получим.
Рисунок 1.
Так в чем же дело?! Выкручиваем MTU до предела и... скорость падает до нуля. Почему? Причина в том, что с ростом размера пакетов увеличивается и время, необходимое для их повторной передачи в том случае, если пакет потерян или искажен. К тому же, промежуточные узлы имеют свои собственные настройки, и если размер передаваемого пакета, превышает текущий MTU, пакет разрезается на два или более пакетов, (т.е. фрагментируется) и эти фрагменты собираются воедино только на узле-приемнике, в результате чего пропускная способность уменьшается. Причем, если MTU узла отправителя лишь чуть-чуть превышает MTU промежуточного узла, то второй пакет состоит практически из одного заголовка, в результате чего зависимость скорость передачи от размера превращается в характерную пилообразную кривую (см. рис. 2).
Значения MTU, используемые Windows Server 2003 по умолчанию, приведены в таблице 1, однако при желании их можно изменить.
Рисунок 2. Зависимость скорости передачи данных от размера MTU (по данным http://member.nifty.ne.jp/oso/faq.mtu-faq.html ).
Запускаем утилиту "Редактора Реестра" и открываем в ней следующий раздел: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interfaceGUID . Видим там параметр MTU типа DWORD (а если не видим, то создаем) и вводим размер в байтах (0xFFFFFFFF означает "использовать значение MTU по умолчанию). Интерфейсы заданы GUID-идентификаторами и обычно их бывает намного больше одного. Как среди них найти интерфейс кабельного модема или конкретной сетевой карты? Да очень просто - по IP-адресу!
Рисунок 3. Тонкая настройка TCP/IP параметров через "Редактор Реестра".
Существует возможность автоматического определения маршрута, по которому пакеты с заданным MTU проходят без фрагментации (параметр EnablePMTUDiscovery типа DWORD, находящийся в той же ветви реестра, что и MTU (значение "1" включает данную функцию, "0" - выключает). Однако многие администраторы промежуточных узлов по соображениям "безопасности" блокируют отправку ICMP-сообщений и узел-отправитель остается в полном неведении относительно факта фрагментации. Специально для обнаружения таких вот "неправильных" маршрутизаторов (прозванных "черными дырами" или, по-английски, Black Hole), Windows поддерживает специальный алгоритм, управляемый параметром EnablePMTUDiscovery (во всем аналогичным EnablePMTUDiscovery).
Рисунок 4. "Черными дырами" называют маршрутизаторы, не отправляющие ICMP-сообщения о факте фрагментации ретранслируемого пакета, что создает большие проблемы при попытке определения оптимального значения MTU.
В подавляющем большинстве случаев использование опций EnablePMTUDiscovery и EnablePMTUDiscovery приводит к снижению производительности и значение MTU лучше выбирать, отталкиваясь от таблицы 2, или действовать методом перебора.
Еще один параметр - MSS (M aximum S egment S ize - Максимальный Размер Сегмента) отвечает за максимальный размер передаваемых данных за вычетом длины заголовка IP-пакета (см. рис. 1). Трогать его не следует, да и Windows это все равно не позволяет. В общем случае, MSS = MTU - 40 байт.
Таблица 1. Значения MTU и MSS по умолчанию в Microsoft Windows Server 2003.
Таблица 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 мегабит/сек, независящий от пропускной способности. Кошмар! Ну, как дальше жить?!
Вот потому-то создатели TCP/IP и разрешили узлу "A" отправлять более одного сегмента, не дожидаясь подтверждения. Максимальное количество сегментов, которые можно передать до прихода подтверждения и называется размером TCP-окна (процесс передачи хорошо проиллюстрированном на анимированном gif"e: http://cable-dsl.home.att.net/rwinanim.htm ). Почему этот параметр так важен для достижения наибольшей производительности?
Допустим, мы имеем 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-протокола, в наибольшей степени ответственные за его производительность. Но помимо них существует и другие, за разъяснением которых мы оправляем читателя по ссылкам ниже.
Полезные ссылки
Оптимизация работы протокола ТСР в распределенных сетях:
http://www.gurnov.ru/kms_catalog+stat+cat_id-4+page-1+nums-14.html
Enabling High Performance Data Transfers:
http://www.psc.edu/networking/projects/tcptune/
Step-by-step instructions for tuning TCP under Windows:
http://www.psc.edu/networking/projects/tcptune/OStune/winxp/winxp_stepbystep.html
UNIX IP Stack Tuning Guide:
http://www.cymru.com/Documents/ip-stack-tuning.html
Navas Cable Modem/DSL Tuning Guide:
http://cable-dsl.home.att.net
Microsoft Windows 2000 TCP/IP Implementation Details:
http://www.microsoft.com/technet/network/deploy/depovg/tcpip2k.mspx
TCP/IP and NBT configuration parameters for Windows 2000 or for Windows
NT:
http://support.microsoft.com/kb/120642/
PMTU black hole detection algorithm change for Windows:
http://support.microsoft.com/kb/136970/
Default MTU size for different network topology:
http://support.microsoft.com/kb/140375/
Dial-Up and Home Networking Troubleshooting Reference:
http://www.internetweekly.org/llarrow/mtumss.html
- Перевод
И некоторые технологии - TCP Fast Open, контроль потока и перегрузкой и масштабирование окна. Во второй части узнаем, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.
Медленный старт (Slow-Start)
Несмотря на присутствие контроля потока в TCP, сетевой коллапс накопления был реальной проблемой в середине 80-х. Проблема была в том, что хотя контроль потока не позволяет отправителю «утопить» получателя в данных, не существовало механизма, который бы не дал бы это сделать с сетью. Ведь ни отправитель, ни получатель не знают ширину канала в момент начала соединения, и поэтому им нужен какой-то механизм, чтобы адаптировать скорость под изменяющиеся условия в сети.Например, если вы находитесь дома и скачиваете большое видео с удаленного сервера, который загрузил весь ваш даунлинк, чтобы обеспечить максимум скорости. Потом другой пользователь из вашего дома решил скачать объемное обновление ПО. Доступный канал для видео внезапно становится намного меньше, и сервер, отправляющий видео, должен изменить свою скорость отправки данных. Если он продолжит с прежней скоростью, данные просто «набьются в кучу» на каком-то промежуточном гейтвэе, и пакеты будут «роняться», что означает неэффективное использование сети.
В 1988 году Ван Якобсон и Майкл Дж. Карелс разработали для борьбы с этой проблемой несколько алгоритмов: медленный старт, предотвращение перегрузки, быстрая повторная передача и быстрое восстановление. Они вскоре стали обязательной частью спецификации TCP. Считается, что благодаря этим алгоритмам удалось избежать глобальных проблем с интернетом в конце 80-х/начале 90-х, когда трафик рос экспоненциально.
Чтобы понять, как работает медленный старт, вернемся к примеру с клиентом в Нью-Йорке, пытающемуся скачать файл с сервера в Лондоне. Сначала выполняется тройное рукопожатие, во время которого стороны обмениваются своими значениями окон приема в АСК-пакетах. Когда последний АСК-пакет ушел в сеть, можно начинать обмен данными.
Единственный способ оценить ширину канала между клиентом и сервером – измерить ее во время обмена данными, и это именно то, что делает медленный старт. Сначала сервер инициализирует новую переменную окна перегрузки (cwnd) для TCP-соединения и устанавливает ее значение консервативно, согласно системному значению (в Linux это initcwnd).
Значение переменной cwnd не обменивается между клиентом и сервером. Это будет локальная переменная для сервера в Лондоне. Далее вводится новое правило: максимальный объем данных «в пути» (не подтвержденных через АСК) между сервером и клиентом должно быть наименьшим значением из rwnd и cwnd. Но как серверу и клиенту «договориться» об оптимальных значениях своих окон перегрузки. Ведь условия в сети изменяются постоянно, и хотелось бы, чтобы алгоритм работал без необходимости подстройки каждого TCP-соединения.
Решение: начинать передачу с медленной скоростью и увеличивать окно по мере того, как прием пакетов подтверждается. Это и есть медленный старт.
Начальное значение cwnd исходно устанавливалось в 1 сетевой сегмент. В RFC 2581 это изменили на 4 сегмента, и далее в RFC 6928 – до 10 сегментов.
Таким образом, сервер может отправить до 10 сетевых сегментов клиенту, после чего должен прекратить отправку и ждать подтверждения. Затем, для каждого полученного АСК, сервер может увеличить свое значение cwnd на 1 сегмент. То есть на каждый подтвержденный через АСК пакет, два новых пакета могут быть отправлены. Это означает, что сервер и клиент быстро «занимают» доступный канал.
Рис. 1. Контроль за перегрузкой и ее предотвращение.
Каким же образом медленный старт влияет на разработку браузерных приложений? Поскольку каждое TCP-соединение должно пройти через фазу медленного старта, мы не можем сразу использовать весь доступный канал. Все начинается с маленького окна перегрузки, которое постепенно растет. Таким образом время, которое требуется, чтобы достичь заданной скорости передачи, - это функция от круговой задержки и начального значения окна перегрузки.
Время достижения значения cwnd, равного N.
Чтобы ощутить, как это будет на практике, давайте примем следующие предположения:
- Окна приема клиента и сервера: 65 535 байт (64 КБ)
- Начальное значение окна перегрузки: 10 сегментов
- Круговая задержка между Лондоном и Нью-Йорком: 56 миллисекунд
Тот факт, что клиент и сервер могут быть способны обмениваться мегабитами в секунду между собой, не имеет никакого значения для медленного старта.
Рис. 2. Рост окна перегрузки.
Чтобы уменьшить время, которое требуется для достижения максимального значения окна перегрузки, можно уменьшить время, требуемое пакетам на путь «туда-обратно» - то есть расположить сервер географически ближе к клиенту.
Медленный старт мало влияет на скачивание крупных файлов или потокового видео, поскольку клиент и сервер достигнут максимальных значений окна перегрузки за несколько десятков или сотен миллисекунд, но это будет одним TCP-соединением.
Однако для многих HTTP-запросов, когда целевой файл относительно небольшой, передача может закончиться до того, как достигнут максимум окна перегрузки. То есть производительность веб-приложений зачастую ограничена временем круговой задержкой между сервером и клиентом.
Перезапуск медленного старта (Slow-Start Restart - SSR)
Дополнительно к регулированию скорости передачи в новых соединениях, TCP также предусматривает механизм перезапуска медленного старта, который сбрасывает значение окна перегрузки, если соединение не использовалось заданный период времени. Логика здесь в том, что условия в сети могли измениться за время бездействия в соединении, и чтобы избежать перегрузки, значение окна сбрасывается до безопасного значения.Неудивительно, что SSR может оказывать серьезное влияние на производительность долгоживущих TCP-соединений, которые могут временно «простаивать», например, из-за бездействия пользователя. Поэтому лучше отключить SSR на сервере, чтобы улучшить производительность долгоживущих соединений. На Linux проверить статус SSR и отключить его можно следующими командами:
$> sysctl net.ipv4.tcp_slow_start_after_idle $> sysctl -w net.ipv4.tcp_slow_start_after_idle=0
Чтобы продемонстрировать влияние медленного старта на передачу небольшого файла, давайте представим, что клиент из Нью-Йорка запросил файл размером 64 КБ с сервера в Лондоне по новому TCP-соединению при следующих параметрах:
- Круговая задержка: 56 миллисекунд
- Пропускная способность клиента и сервера: 5 Мбит/с
- Окно приема клиента и сервера: 65 535 байт
- Начальное значение окна перегрузки: 10 сегментов (10 х 1460 байт = ~14 КБ)
- Время обработки на сервере для генерации ответа: 40 миллисекунд
- Пакеты не теряются, АСК на каждый пакет, запрос GET умещается в 1 сегмент
Рис. 3. Скачивание файла через новое TCP-соединение.
- 0 мс: клиент начинает TCP-хэндшейк SYN-пакетом
- 28 мс: сервер отправляет SYN-ACK и задает свой размер rwnd
- 56 мс: клиент подтверждает SYN-ACK, задает свой размер rwnd и сразу шлет запрос HTTP GET
- 84 мс: сервер получает HTTP-запрос
- 124 мс: сервер заканчивает создавать ответ размером 64 КБ и отправляет 10 TCP-сегментов, после чего ожидает АСК (начальное значение cwnd равно 10)
- 152 мс: клиент получает 10 TCP-сегментов и отвечает АСК на каждый
- 180 мс: сервер увеличивает cwnd на каждый полученный АСК и отправляет 20 TCP-сегментов
- 208 мс: клиент получает 20 TCP-сегментов и отвечает АСК на каждый
- 236 мс: сервер увеличивает cwnd на каждый полученный АСК и отправляет 15 оставшихся TCP-сегментов
- 264 мс: клиент получает 15 TCP-сегментов и отвечает АСК на каждый
Рис. 4. Скачивание файла через существующее TCP-соединение.
- 0 мс: клиент отправляет НТТР-запрос
- 28 мс: сервер получает НТТР-запрос
- 68 мс: сервер генерирует ответ размером в 64 КБ, но значение cwnd уже больше, чем 45 сегментов, требуемых для отправки этого файла. Поэтому сервер отправляет все сегменты сразу
- 96 мс: клиент получает все 45 сегментов и отвечает АСК на каждый
В обоих случаях тот факт, что клиент и сервер пользуются каналом с пропускной способностью 5 Мбит/с, не оказал никакого влияния на время скачивания файла. Только размеры окон перегрузки и сетевая задержка были ограничивающими факторами. Интересно, что разница в производительности при использовании нового и существующего TCP-соединений будет увеличиваться, если сетевая задержка будет расти.
Как только вы осознаете проблемы с задержками при создании новых соединений, у вас сразу появится желание использовать такие методы оптимизации, как удержание соединения (keepalive), конвейеризация пакетов (pipelining) и мультиплексирование.
Увеличение начального значения окна перегрузки TCP
Это самый простой способ увеличения производительности для всех пользователей или приложений, использующих TCP. Многие операционные системы уже используют новое значение равное 10 в своих обновлениях. Для Linux 10 – значение по умолчанию для окна перегрузки, начиная с версии ядра 2.6.39.Предотвращение перегрузки
Важно понимать, что TCP использует потерю пакетов как механизм обратной связи, который помогает регулировать производительность. Медленный старт создает соединение с консервативным значением окна перегрузки и пошагово удваивает количество передаваемых за раз данных, пока оно не достигнет окна приема получателя, системного порога sshtresh или пока пакеты не начнут теряться, после чего и включается алгоритм предотвращения перегрузки.Предотвращение перегрузки построено на предположении, что потеря пакета является индикатором перегрузки в сети. Где-то на пути движения пакетов на линке или на роутере скопились пакеты, и это означает, что нужно уменьшить окно перегрузки, чтобы предотвратить дальнейшее «забитие» сети трафиком.
После того как окно перегрузки уменьшено, применяется отдельный алгоритм для определения того, как должно далее увеличиваться окно. Рано или поздно случится очередная потеря пакета, и процесс повторится. Если вы когда-либо видели похожий на пилу график проходящего через TCP-соединение трафика – это как раз потому, что алгоритмы контроля и предотвращения перегрузки подстраивают окно перегрузки в соответствии с потерями пакетов в сети.
Стоит заметить, что улучшение этих алгоритмов является активной областью как научных изысканий, так и разработки коммерческих продуктов. Существуют варианты, которые лучше работают в сетях определенного типа или для передачи определенного типа файлов и так далее. В зависимости от того, на какой платформе вы работаете, вы используете один из многих вариантов: TCP Tahoe and Reno (исходная реализация), TCP Vegas, TCP New Reno, TCP BIC, TCP CUBIC (по умолчанию на Linux) или Compound TCP (по умолчанию на Windows) и многие другие. Независимо от конкретной реализации, влияния этих алгоритмов на производительность веб-приложений похожи.
Пропорциональное снижение скорости для TCP
Определение оптимального способа восстановления после потери пакета – не самая тривиальная задача. Если вы слишком «агрессивно» реагируете на это, то случайная потеря пакета окажет чрезмерно негативное воздействие на скорость соединения. Если же вы не реагируете достаточно быстро, то, скорее всего, это вызовет дальнейшую потерю пакетов.Изначально в TCP применялся алгоритм кратного снижения и последовательного увеличения (Multiplicative Decrease and Additive Increase - AIMD): когда теряется пакет, то окно перегрузки уменьшается вдвое, и постепенно увеличивается на заданную величину с каждым проходом пакетов «туда-обратно». Во многих случаях AIMD показал себя как чрезмерно консервативный алгоритм, поэтому были разработаны новые.
Пропорциональное снижение скорости (Proportional Rate Reduction – PRR) – новый алгоритм, описанный в RFC 6937, цель которого является более быстрое восстановление после потери пакета. Согласно замерам Google, где алгоритм и был разработан, он обеспечивает сокращение сетевой задержки в среднем на 3-10% в соединениях с потерями пакетов. PPR включен по умолчанию в Linux 3.2 и выше.
Произведение ширины канала на задержку (Bandwidth-Delay Product – BDP)
Встроенные механизмы борьбы с перегрузкой в TCP имеют важное следствие: оптимальные значения окон для получателя и отправителя должны изменяться согласно круговой задержке и целевой скорости передачи данных. Вспомним, что максимально количество неподтвержденных пакетов «в пути» определено как наименьшее значение из окон приема и перегрузки (rwnd и cwnd). Если у отправителя превышено максимальное количество неподтвержденных пакетов, то он должен прекратить передачу и ожидать, пока получатель не подтвердит какое-то количество пакетов, чтобы отправитель мог снова начать передачу. Сколько он должен ждать? Это определяется круговой задержкой.BDP определяет, какой максимальный объем данных может быть «в пути»
Если отправитель часто должен останавливаться и ждать АСК-подтверждения ранее отправленных пакетов, это создаст разрыв в потоке данных, который будет ограничивать максимальную скорость соединения. Чтобы избежать этой проблемы, размеры окон должны быть установлены достаточно большими, чтобы можно было отсылать данные, ожидая поступления АСК-подтверждений по ранее отправленным пакетам. Тогда будет возможна максимальная скорость передачи, никаких разрывов. Соответственно, оптимальный размер окна зависит от скорости круговой задержки.
Рис. 5. Разрыв в передаче из-за маленьких значений окон.
Насколько же большими должны быть значения окон приема и перегрузки? Разберем на примере: пусть cwnd и rwnd равны 16 КБ, а круговая задержка равна 100 мс. Тогда:
Получается, что какая бы ни была ширина канала между отправителем и получателем, такое соединение никогда не даст скорость больше, чем 1,31 Мбит/с. Чтобы добиться большей скорости, надо или увеличить значение окон, или уменьшить круговую задержку.
Похожим образом мы можем вычислить оптимальное значение окон, зная круговую задержку и требуемую ширину канала. Примем, что время останется тем же (100 мс), а ширина канала отправителя 10 Мбит/с, а получатель находится на высокоскоростном канале в 100 Мбит/с. Предполагая, что у сети между ними нет проблем на промежуточных участках, мы получаем для отправителя:
Размер окна должен быть как минимум 122,1 КБ, чтобы полностью занять канал на 10 Мбит/с. Вспомните, что максимальный размер окна приема в TCP равен 64 КБ, если только не включено масштабирование окна (RFC 1323). Еще один повод перепроверить настройки!
Хорошая новость в том, что согласование размеров окон автоматически делается в сетевом стэке. Плохая новость в том, что иногда это может быть ограничивающим фактором. Если вы когда-либо задумывались, почему ваше соединение передает со скоростью, которая составляет лишь небольшую долю от имеющейся ширины канала, это происходит, скорее всего, из-за малого размера окон.
BDP в высокоскоростных локальных сетях
Круговая задержка может являться узким местом и в локальных сетях. Чтобы достичь 1 Гбит/с при круговой задержке в 1 мс, необходимо иметь окно перегрузки не менее чем 122 КБ. Вычисления аналогичны показанным выше.Блокировка начала очереди (Head-of-line blocking – HOL blocking)
Хотя TCP – популярный протокол, он не является единственным, и не всегда – самым подходящим для каждого конкретного случая. Такие его особенности, как доставка по порядку, не всегда необходимы, и иногда могут увеличить задержку.Каждый TCP-пакет содержит уникальный номер последовательности, и данные должны поступать по порядку. Если один из пакетов был потерян, то все последующие пакеты хранятся в TCP-буфере получателя, пока потерянный пакет не будет повторно отправлен и не достигнет получателя. Поскольку это происходит в TCP-слое, приложение «не видит» эти повторные отправки или очередь пакетов в буфере, и просто ждет, пока данные не будут доступны. Все, что «видит» приложение – это задержка, возникающая при чтении данных из сокета. Этот эффект известен как блокировка начала очереди.
Блокировка начала очереди освобождает приложения от необходимости заниматься упорядочиванием пакетов, что упрощает код. Но с другой стороны, появляется непредсказуемая задержка поступления пакетов, что негативно влияет на производительность приложений.
Рис. 6. Блокировка начала очереди.
Некоторым приложениям может не требоваться гарантированная доставка или доставка по порядку. Если каждый пакет – это отдельное сообщение, то доставка по порядку не нужна. А если каждое новое сообщение перезаписывает предыдущие, то и гарантированная доставка также не нужна. Но в TCP нет конфигурации для таких случаев. Все пакеты доставляются по очереди, а если какой-то не доставлен, он отправляется повторно. Приложения, для которых задержка критична, могут использовать альтернативный транспорт, например, UDP.
Потеря пакетов – это нормально
Потеря пакетов даже нужна для того, чтобы обеспечить лучшую производительность TCP. Потерянный пакет работает как механизм обратной связи, который позволяет получателю и отправителю изменить скорость отправки, чтобы избежать перегрузки сети и минимизировать задержку.Некоторые приложения могут «справиться» с потерей пакета: например, для проигрывания аудио, видео или для передачи состояния в игре, гарантированная доставка или доставка по порядку не обязательны. Поэтому WebRTC использует UDP в качестве основного транспорта.
Если при проигрывании аудио произошла потеря пакета, аудио кодек может просто вставить небольшой разрыв в воспроизведение и продолжать обрабатывать поступающие пакеты. Если разрыв небольшой, пользователь может его и не заметить, а ожидание доставки потерянного пакета может привести к заметной задержке воспроизведения, что будет гораздо хуже для пользователя.
Аналогично, если игра передает свои состояния, то нет смысла ждать пакет, описывающий состояние в момент времени T-1, если у нас уже есть информация о состоянии в момент времени T.
Оптимизация для TCP
TCP – это адаптивный протокол, разработанный для того, чтобы максимально эффективно использовать сеть. Оптимизация для TCP требует понимания того, как TCP реагирует на условия в сети. Приложениям может понадобиться собственный метод обеспечения заданного качества (QoS), чтобы обеспечить стабильную работу для пользователей.Требования приложений и многочисленные особенности алгоритмов TCP делает их взаимную увязку и оптимизацию в этой области огромным полем для изучения. В этой статье мы лишь коснулись некоторых факторов, которые влияют на производительность TCP. Дополнительные механизмы, такие как выборочные подтверждения (SACK), отложенные подтверждения, быстрая повторная передача и многие другие осложняют понимание и оптимизацию TCP-сессий.
Хотя конкретные детали каждого алгоритма и механизма обратной связи будут продолжать изменяться, ключевые принципы и их последствия останутся:
- Тройное рукопожатие TCP несет серьезную задержку;
- Медленный старт TCP применяется к каждому новому соединению;
- Механизмы контроля потока и перегрузки TCP регулируют пропускную способность всех соединений;
- Пропускная способность TCP регулируется через размер окна перегрузки.
Настройка конфигурации сервера
Вместо того, чтобы заниматься настройкой каждого отдельного параметра TCP, лучше начать с обновления до последней версии операционной системы. Лучшие практики в работе с TCP продолжают развиваться, и большинство этих изменений уже доступно в последних версиях ОС.«Обновить ОС на сервере» кажется тривиальным советом. Но на практике многие серверы настроены под определенную версию ядра, и системные администраторы могут быть против обновлений. Да, обновление несет свои риски, но в плане производительности TCP, это, скорее всего, будет самым эффективным действием.
После обновления ОС вам нужно сконфигурировать сервер в соответствии с лучшими практиками:
- Увеличить начальное значение окна перегрузки: это позволит передать больше данных в первом обмене и существенно ускоряет рост окна перегрузки
- Отключить медленный старт: отключение медленного старта после периода простоя соединения улучшит производительность долгоживущих TCP-соединений
- Включить масштабирование окна: это увеличит максимальное значение окна приема и позволит ускорить соединения, где задержка велика
- Включить TCP Fast Open: это даст возможность отправлять данные в начальном SYN-пакете. Это новый алгоритм, его должны поддерживать и клиент и сервер. Изучите, может ли ваше приложение извлечь из него пользу.
Практически каждый пользователь хочет, чтобы скорость соединения его компьютера со всемирной паутиной была как можно выше. Особенно актуальным данный вопрос является для низкоскоростных сетей передачи данных, у которых, как говорится, каждый КБ/с на счету. Давайте выясним, как повысить этот показатель на ПК с операционной системой Windows 7.
Сразу нужно отметить, что увеличить параметры быстродействия интернета свыше тех, которые способна предоставить пропускная способность сети, попросту невозможно. То есть, объявленная провайдером максимальная скорость передачи данных – это та граница, выше которой прыгнуть не получится. Так что не верьте, различным «чудо-рецептам», которые якобы способны ускорить передачу информации в разы. Это возможно только при смене провайдера или переходе на другой тарифный план. Но, в то же время, определенным ограничителем может выступать сама система. То есть, её настройки могут снижать пропускную способность ещё ниже той планки, которую задает интернет-оператор.
В данной статье мы объясним, как настроить компьютер на Windows 7 так, чтобы он был способен поддерживать соединение со всемирной паутиной на максимально высокой скорости. Это можно сделать как изменив определенные параметры внутри самой операционной системы, так и применив некоторые сторонние программы.
Способ 1: TCP Optimizer
Существует целый ряд программ, которые предназначены для оптимизации настроек подключения компьютера ко всемирной паутине, что, в свою очередь, приводит к увеличению скорости интернета. Таких приложений довольно много, но мы опишем действия в одном из них, которое называется TCP Optimizer.
Способ 2: NameBench
Существует ещё одно приложение для ускорения скорости получения данных из сети — NameBench. Но, в отличие от предыдущей программы, оно не оптимизирует настройки компьютера, а производит поиск DNS-серверов, через которые связь будет максимально быстрой. Путем замены в свойствах подключения существующих DNS-серверов на те, которые рекомендует программа, есть возможность увеличить быстроту загрузки сайтов.
- После загрузки NameBench запустите инсталляционный файл. Административными правами обладать не обязательно. Жмите «Extract» . После этого выполнится распаковка приложения.
- В поле «Query Data Source» программа сама выбирает наиболее подходящий по её мнению браузер, который установлен на данном компьютере, для проверки. Но при желании, кликнув по данному полю, вы можете выбрать из списка любой другой веб-обозреватель. Для запуска поиска DNS-серверов жмите «Start Benchmark» .
- Выполняется процедура поиска. Она может занять существенное количество времени (до 1 часа).
- После окончания теста откроется браузер, который установлен на компьютере по умолчанию. На его странице программа NameBench в блоке «Recommended configuration» отобразит адреса трех рекомендуемых DNS-серверов.
- Не закрывая браузер, проделайте следующий манипуляции. Щелкайте «Пуск» , войдите в «Панель управления» .
- В блоке «Сеть и интернет» кликните по позиции «Просмотр состояния сети и задач» .
- В появившемся окошке «Центра управления сетями» в группе параметров «Подключение или отключение» щелкайте по наименованию текущей сети, которая указана после параметра «Подключение» .
- В появившемся окошке щелкайте «Свойства» .
- После запуска окошка в блоке компонентов выберите позицию «TCP/IPv4» . Жмите «Свойства» .
- В появившемся окошке в разделе «Общие» перейдите к нижней части параметров. Установите радиокнопку в позицию «Использовать следующие адреса DNS-серверов» . Два нижних поля станут активными. Если в них уже есть какие-то значения, то обязательно перепишите их, так как некоторые операторы работают только с определенными DNS-серверами. Поэтому, если вследствие дальнейших изменений соединение со всемирной паутиной будет утеряно, то придется вернуть старые адреса. В поле «Предпочитаемый DNS-сервер» «Primary Server» браузера. В поле «Альтернативный DNS-сервер» введите тот адрес, который отображается в области «Secondary Server» браузера. Кликайте «OK» .
После этого скорость интернета должна несколько прибавиться. В случае же, если вообще не получается зайти в сеть, верните прежние настройки DNS-серверов.
Способ 3: Настройка планировщика пакетов
Значение изучаемого параметра можно увеличить путем изменения настройки планировщика пакетов.
- Вызовите средство «Выполнить»
, применив Win+R
. Вбейте:
Щелкайте «OK» .
- Открывается окно «Редактор локальной групповой политики» . В левой области оболочки данного инструмента раскрывайте блок «Конфигурация компьютера» и щелкайте по наименованию папки «Административные шаблоны» .
- Затем перемещайтесь в правую часть интерфейса щелкайте там по папке «Сеть» .
- Теперь входите в каталог «Планировщик пакетов QoS» .
- Наконец, перейдя в указанную папку, щелкайте по пункту «Ограничить резервируемую пропускную способность» .
- Запускается окно, имеющее то же наименование, что и у пункта, по которому мы ранее перешли. В верхней левой его части выставьте радиокнопку в позицию «Включить» . В поле «Ограничение пропускной способности» обязательно выставьте значение «0» , иначе вы рискуете не увеличить скорость приема и передачи данных по сети, а, наоборот, снизить её. Затем щелкайте «Применить» и «OK» .
- Теперь нужно проверить, подключен ли планировщик пакетов в свойствах используемой сети. Для этого нужно открыть окошко «Состояние» текущей сети. Как это делается, было рассмотрено в Способе 2 . Кликните по кнопке «Свойства» .
- Открывается окно свойств текущего подключения. Удостоверьтесь, чтобы напротив пункта «Планировщик пакетов QoS» был установлен флажок. Если он стоит, то все в порядке и можете просто закрыть окно. Если же флажка нет, то установите его, а затем жмите «OK» .
После этого вы вполне вероятно получите некоторую прибавку к существующему уровню скорости интернета.
Способ 4: Настройка сетевой карты
Также увеличить скорость подключения к сети можно путем настройки электропитания сетевой карты ПК.
- Переходите с помощью меню «Пуск» в «Панель управления» так же, как мы это делали выше. Заходите в раздел «Система и безопасность» .
- Далее в группе настроек «Система» переходите по пункту «Диспетчер устройств» .
- Запускается окно «Диспетчера устройств» . В левой части окна щелкайте по пункту «Сетевые адаптеры» .
- Раскрывается список установленных на компьютере сетевых адаптеров. В этом перечне может быть как один элемент, так и несколько. В последнем случае вам придется выполнить указанные ниже операции с каждым адаптером поочередно. Итак, щелкайте по наименованию сетевой карты.
- Открывается окошко свойств. Переместитесь во вкладку «Управление электропитанием» .
- После того, как будет открыта соответствующая вкладка, проверьте наличие флажка около пункта «Разрешить отключение этого устройства» . Если пометка присутствует, то следует её снять. Также, в случае наличия, снимите флажок с пункта «Разрешить этому устройству выводить компьютер из спящего режима» , если, конечно, данный пункт вообще у вас активный. Щелкайте «OK» .
- Как говорилось уже выше, проделайте данную операцию со всеми элементами, которые расположены в группе «Сетевые адаптеры» в «Диспетчере устройств» .
Если вы используете стационарный компьютер, негативных последствий после применения данных шагов не будет. Функция вывода компьютера из спящего режима сетевой картой применяется очень редко, если вам нужно, например, связаться с выключенным компьютером удаленно. Конечно, при деактивации возможности отключения сетевой карты, когда она не применяется, несколько увеличивается расход электроэнергии, но в реальности данное увеличение будет минимальным и почти не скажется на уровне электропотребления.
Важно: для ноутбуков отключение данной функции может быть довольно весомым, так как увеличатся темпы разрядки батареи, а значит, уменьшится период работы устройства без подзарядки. Тут нужно будет определиться, что для вас важнее: небольшая прибавка скорости интернета или более продолжительное время работы ноутбука без подзарядки.
Способ 5: Изменение плана энергопитания
Добиться определенного увеличения скорости обмена данными со всемирной паутиной можно также путем изменения текущего плана электропитания.
Дело в том, что в режиме экономии или в сбалансированном режиме работы, подача электричества на сетевую карту, как и на другие компоненты системы, ограничена. Произведя вышеуказанные действия, мы тем самым снимаем эти ограничения и увеличиваем производительность адаптера. Но, опять же, стоит отметить, что для ноутбуков данные действия чреваты увеличением темпов разрядки батареи. Как вариант, для минимизации этих негативных последствий при использовании ноутбука можно производить переключение на более высокий режим производительности только при непосредственном использовании интернета или когда устройство подключено к электрической сети.
Способ 6: Расширение COM-порта
Увеличить показатель скорости подключения на Windows 7 можно также, произведя расширение COM-порта.
Таким образом пропускная способность порта будет увеличена, а значит, увеличен будет и показатель быстродействия интернета. Особенно полезным данный способ является при использовании высокоскоростных сетей, когда провайдер предоставляет более высокую скорость соединения, чем та, на которую настроен порт COM компьютера.
Можно дать также некоторые общие советы, которые позволят повысить скорость интернета. Так, если у вас есть возможность выбора между проводным соединением и Wi-Fi, то в таком случае выбирайте первое, так как проводное соединение функционирует с меньшими потерями, чем беспроводное.
Если же нет возможности использовать проводное подключение, то попытайтесь расположить Wi-Fi-роутер как можно ближе к компьютеру. Если вы используете ноутбук, не подключенный к электросети, то, наоборот, можно расположиться с ним поближе к роутеру. Тем самым вы минимизируете потери при передаче сигнала и увеличите скорость интернета. При использовании 3G-модемов располагайте компьютер как можно ближе к окну. Это позволит максимально свободно проходить сигналу. Также можете обернуть 3G-модем медной проволокой, придав ей форму антенны. Это тоже обеспечит определенную прибавку быстроты передачи данных.
При использовании Wi-Fi обязательно устанавливайте пароль на подключение. Без пароля к вашей точке сможет подсоединить кто угодно, тем самым «забирая» часть скорости себе.
Обязательно периодически , используя при этом не штатный антивирус, а специализированные утилиты, например . Дело в том, что многие вредоносные программы используют компьютер для передачи данных своему «хозяину» и других манипуляций через сеть, тем самым снижая скорость соединения. По этой же причине рекомендуется отключать все неиспользуемые тулбары и плагины в браузерах, так как они тоже передают и принимают через сетевой канал часто бесполезную для пользователя информацию.
Ещё один вариант увеличить целевой показатель – это отключить антивирус и брандмауэр. Но данный метод мы использовать не рекомендуем. Конечно, антивирусы несколько снижают быстроту приема данных, пропуская их через себя. Но, отключив инструменты защиты, вы рискуете нахвататься вирусов, что в свою очередь приведет к обратному от желаемого эффекту – скорость интернета снизится ещё больше, чем при включенной антивирусной программе.
Как видим, существует довольно широкий перечень вариантов увеличить скорость интернета без смены тарифного плана и провайдера. Правда, не стоит обольщаться. Все эти варианты могут дать только сравнительно небольшую прибавку величины данного показателя. В то же время, если использовать их в комплексе, а не ограничиваться применением какого-то одного способа, то можно добиться существенных результатов.
Предлагаю вашему вниманию программу, с помощью которой вы можете оптимизировать ваше интернет соединение, повысить скорость, стабилизировать и уменьшить пинг в он-лайн играх.1. Скачиваем установку самой программы из данной темы во вложении.
2. Устанавливаем на ваш компьютер.
3. Запускаем от имени администратора.
4. Выставляем настройки для он-лайн игр, как показано на скринах:Вкладка "General Settings"
Выбираем свою сетевую карту для настройки. "Network Adapter selection"
В шкале скорости, выставляем скорость своего интернет соединения.Вкладка "Advanced Settings"
5. Нажимаем применить - "Apply changes"
6. Программа в новом окне, покажет какие изменение будут приняты, в данном окошке обязательно выставляем галочку возле "backup", это нужно для восстановления прежних настроек интернет соединения в windows.7. Нажимаем "ОК" - после программа применит новые настройки интернет соединения и попросить перезагрузить систему, перезагружаем.
Все готово!
Если есть какие то вопросы или же предложения, задавайте в этой теме.
Как и обещал, перевод на русский инструкции - "TCP Optimizer"
1. Введение
TCP Optimizer – это программа с легким, интуитивным интерфейсом для настройки TCP/IP параметров широкополосных соединений на текущих (и некоторых устаревших) версиях Windows. TCP Optimizer Version 4 работает на всех версиях Windows, начиная от XP/NT/2000/2003, Windows Vista/7/2008 Server и заканчивая более свежими Windows 8, 2012 Server, а также Windows 10. Настройки всех вышеперечисленных ОС разные, поэтому программа предложит только поддерживаемый набор опций для выбранной операционной системы. При создании TCP Optimizer были учтены все нюансы Microsoft относительно TCP/IP, а также документы RFC, имеющие отношение к программе. Утилита может править все важные реестры с параметрами конфигурации TCP/IP; в новых версиях Windows оперирует командлетами PowerShell; содержит в себе все твики, перечисленные нами ранее в статьях об улучшении скорости передачи, и в целом делает опыт работы с твиками легким, как бриз.
Ниже мы опишем все опции, доступные в TCP Optimizer. Некоторые из опций могут быть доступны только для Windows 8 и выше.
2. Пользование программой. Краткий обзор.
Если вам не хочется знакомиться со всей документацией, приведенной ниже, или же вам нужны твики прямо сейчас, просто выполните все пункты этой короткой инструкции:
Запустите программу от имени администратора: чтобы сделать это, нажмите по ярлычку программы правой кнопкой мыши, выберите «Свойства», перейдите в раздел «Совместимость» -> «Запуск от имени администратора» -> OK.
Установите бегунок на максимальную скорость Интернет-соединения (согласно данным Интернет-провайдера).
Выберите тип сетевого устройства, через которое осуществляется выход в Интернет (или поставьте галочку напротив «Изменять все сетевые устройства»).
Внизу в меню настроек выберите «Оптимальные».
Кликните «Применить». Решите, будете ли вы создавать резервную копию и лог, и перезагрузите компьютер.Всю оставшуюся работу за вас сделает TCP Optimizer, он же оптимизирует ваше Интернет-соединение. Со списком всех значимых изменений вы сможете ознакомиться предварительно, до того как они будут применены на компьютере. Программу можно использовать для быстрого восстановления пользовательских настроек, а при желании – для экспериментов с другими настройками. Возможно для последнего, вам придется сначала ознакомиться со всей документацией и нашими статьями о твиках, чтобы понять значение тех или иных настроек и их действие.
Чтобы узнать больше обо всех особенных параметрах программы, пожалуйста, прочитайте следующие главы.
Заметка: Вам нужно будет заходить в программу под своей учетной записью (некоторые опции работают только с учетными записями), а также под именем администратора, чтобы у программы появились права на изменение некоторых настроек.
Ниже дано краткое описание всех опций вкладки «Общие настройки» в программе TCP Optimizer в текущей версии Windows.
Скорость соединения
Этот бегунок позволяет выбрать максимально возможную скорость Интернет-соединения, которая заявлена вашим Интернет-провайдером. Не нужно указывать здесь текущую скорость соединения или заносить сюда результат теста на замер скорости. Здесь требуется максимальная теоретическая скорость вашего соединения. Заметьте, что скорость указывается в Мбайт/с, что означает мегабайт в секунду (не путайте с простыми мегабайтами).
Перемещение бегунка скорости соединения будет влиять на оптимальный размер окна TCP. В старых версиях Windows изменение положения бегунка сразу ведет к подсчету оптимального для данной скорости размера окна приема TCP. В новых операционных системах Windows данное действие может изменить алгоритм автоматической настройки окна приема TCP («restricted» для скоростей ниже 1 Мбайт/с; «normal» для большинства широкополосных соединений; «experimental» для скоростей свыше 90 Мбайт/с). Заметьте, что значение «experimental» в разделе автонастройки окна TCP должно использоваться с осторожностью.
Выбор сетевых устройств
В списке будут указываться все подключенные/активные сетевые устройства, распознанные системой. Если при помощи разворачивающегося вниз меню будет выбран определенный сетевой адаптер, его IP адрес будет отражаться в правом нижнем углу текущей секции. Также вы можете одновременно изменять или не изменять все сетевые устройства.
В этом разделе программы можно установить пользовательское значение MTU (максимальный размер блока данных). Для стандартных подключений значение MTU равно 1500 байтам, исключение составляют PPPoE соединения и некоторые подключения через DSL-модемы. Индекс MTU следует исправлять только для них. Например, максимальное значение MTU для инкапсуляции Windows PPPoE будет равно 1480 байтам (а иногда и 1492).
Заметка: В редких случаях программа может неправильно распознать предпочитаемое сетевое устройство. Это не будет сильно влиять на производительность нашего продукта. В этом случае нужно просто поставить галочку напротив «Изменять все сетевые устройства». Мы были бы очень вам благодарны, если бы вы сообщали нам о таких случаях, чтобы мы могли улучшить программу.
Автоматическая настройка окна приема TCP
Эта настройка регулирует алгоритм для определения размера окна приема TCP в Windows. Маленькое окно приема TCP может ограничивать высокоскоростные соединения с большой задержкой, коими являются все широкополосные Интернет-соединения. Для большинства соединений мы рекомендуем выбирать значение «normal» при настройке этого параметра. Вам нужно будет также убедиться, что вы отключили «Windows Scaling heuristics» (эвристика масштабирования окна TCP) ниже, чтобы ОС Windows не изменяла этот параметр автоматически.
Вот пара исключений, для которых не обязательно выставлять значение автонастройки TCP «normal»:
1. Если скорость Вашего соединения менее 1 Мбит/с, вы можете выбрать значение «highlyrestricted» (строго ограничено).
2. Если у вас соединение типа dial-up, вы можете выбрать «disabled» (отключено; так как для вашей скорости не потребуется буфер больше, чем на 64KB).
3. Если скорость Вашего соединения около/свыше 100 Мбит/с, вы можете выбрать «experimental» (экспериментальный). Однако, чтобы обеспечить хорошую стабильность передачи данных, этот параметр нуждается в более пристальном изучении. Если у вас возникли какие-либо трудности со значением «experimental», пожалуйста, верните значение на «normal» и поделитесь своим опытом на форумах или напишите нам на электронную почту.Эвристика масштабирования окна TCP
Если эта опция оставлена включенной, Windows может ограничить размер окна относительно значения по умолчанию в любой точке в любое время, в которое посчитает, что условия сети оправдывают действия. Когда Windows ограничивает размер окна TCP, оно не всегда возвращается к стандартным значениям. Настоятельно рекомендуется установить этот параметр на «disabled», чтобы сохранить пользовательские параметры автонастройки TCP.
Поставщик надстройки контроля перегрузки
Обычно TCP удается избежать перегрузки сети за счет плавного увеличения размера окна отправки на старте соединения. При работе с широкополосными соединениями чтобы полностью использовать доступную пропускную способность алгоритмы протокола также не увеличивают размер окна довольно быстро. Compound TCP – это новый метод контроля перегрузки, который увеличивает размер окна отправки TCP для широкополосных соединений (с большим RWIN и BDP) более агрессивно. Протокол CTCP максимизирует пропускную способность благодаря отслеживанию задержек и потерь данных.
В большинстве стандартных сценариев следует выбирать «CTCP».
CTCP (Compound TCP) увеличивает размер окна приема TCP и количество отправляемых данных. Этот протокол улучшает пропускную способность широкополосных Интернет-соединений с большим уровнем задержки.
DCTCP (Data Center TCP) регулирует размер окна TCP основываясь на уведомлениях о перегрузке сети ECN. Протокол повышает пропускную способность локальных соединений и соединений с маленькой задержкой. Заметьте, что этот протокол может работать только на операционных системах модификации Server.Масштабирование на стороне приема (RSS)
RSS позволяет параллельно обрабатывать принимаемые пакеты на нескольких процессорах, избегая при этом переотправки пакетов. Эта опция разделяет пакеты в потоки и использует разные процессоры для обработки каждого потока.
Объединение полученных сегментов (RSC)
Функция объединения полученных сегментов (RSC) позволяет сетевому адаптеру объединять множественные пакеты TCP/IP, получаемые в единой передаче, в большие по размеру пакеты (до 64 км). Таким образом, сетевому стеку приходиться обрабатывать меньше заголовков пакетов. Это уменьшает нагрузку на сервер с интенсивным вводом-выводом и процессор.
Прямой доступ к кэшу (DCA)
Прямой доступ к кэшу (DCA) позволяет поддерживаемому устройству ввода-вывода, например, сетевому контроллеру, размещать данные прямо в кэш-памяти процессора. Задача DCA – уменьшить задержку памяти и улучшить пропускную способность каналов в высокоскоростных (гигабитных) средах. Необходимо, чтобы устройства ввода-вывода, системные чипсеты и процессоры поддерживали DCA.
Заметка: эффект DCA более заметен на старых процессорах.
Время жизни пакета (TTL)
Эта настройка определяет по умолчанию время жизни пакета (TTL) согласно коду в заголовке исходящего IP-пакета. TTL определяет максимальный временной интервал в секундах (или хопах), в течение которого IP-пакет может существовать в сети до достижения своего назначения. По сути, это определенное количество маршрутизаторов, через которые IP-пакету позволено пройти, прежде чем он исчезнет. Эта настройка не влияет на скорость напрямую, однако заниженное значение этого параметра может помешать пакетам достигать дальние серверы. А завышенное значение будет забирать лишнее время на распознавание потерянных пакетов.
Мощность ECN
ECN (Explicit Congestion Notification, RFC 3168) – это механизм, который предоставляет маршрутизаторам альтернативный метод работы с перегрузкой сети. Его задача – снизить число ретрансмиссий. По сути, ECN свидетельствует о том, что причиной любой потери пакета является перегрузка маршрутизатора. Эта опция позволяет столкнувшимся с перегрузкой роутерам помечать отброшенные пакеты и разрешает клиентам автоматически снижать скорость передачи для предотвращения дальнейшей потери пакетов. Обычно протокол TCP/IP реагирует на перегрузку сетей отбрасыванием пакетов. Когда же к делу подключается ECN, то поддерживающий ECN роутер вместо отбрасывания пакета вставляет в IP-заголовок бит с целью оповещения о перегрузке. Получатель передает уведомление о перегрузке отправителю. Последний в свою очередь должен среагировать на отброску пакетов. В современных реализациях протокола TCP/IP опция ECN по умолчанию отключена, так как это может спровоцировать проблемы при наличии устаревших маршрутизаторов, которые отбрасывают пакеты с битом ECN или же просто игнорируют бит.
Обычно рекомендуется отключать опцию. Включать ее следует с осторожностью, так как некоторые маршрутизаторы отбрасывают пакеты с ECN-битом, что ведет к потере пакетов или к иным проблемам. Однако для ECN-поддерживающих маршрутизаторов включенная опция может сократить время задержки в некоторых играх и улучшить скорость соединения, несмотря на потерю пакетов.
Заметка: в некоторых играх издателя EA Games при входе в профиль возникают проблемы с вводом логина (возможно проблема в ECN-поддержке роутера).
Разгрузка контрольной суммы
Эта опция позволяет сетевому адаптеру подсчитать контрольное число при передаче пакетов и определить контрольную сумму при получении пакетов на свободный процессор, сокращая трафик по шине PCI. Разгрузка контрольной суммы также требуется для работы некоторых других stateless-объектов, таких как RSS (масштабирование на стороне приема), RSC (объединение полученных сегментов) и LSO (разгрузки большой отправки).
Разгрузка канала TCP Chimney
TCP Chimney позволяет освободить процессор главного компьютера от обработки TCP-трафика и переложить эту функцию на сетевой адаптер. Это помогает улучшить процесс обработки сетевых данных на вашем компьютере, не прибегая к помощи дополнительных программ и не теряя в производительности или безопасности системы. Программы, которые в настоящее время заняты обработкой сетевых заголовков, работают лучше в связке с опцией TCP Chimney. В прошлом активирование этой опции имело ряд негативных последствий из-за драйверов сетевых адаптеров, содержащих ошибки. Однако работа этой опции со временем стала более отлаженной. Она очень полезна для процессоров клиентских компьютеров и для высокоскоростных широкополосных соединений. Не рекомендуется в некоторых серверных средах.
Заметка: Не работает с NetDMA (NetTDMA не поддерживается Windows 8 и выше).
Разгрузка сегментации LSO
При включенной опции сетевой адаптер используется для завершения сегментации данных, так как теоретически он это делает быстрее, чем программное обеспечение операционной системы. Это улучшает скорость передачи данных и уменьшает нагрузку на центральный процессор. Проблемы с применением этой опции встречаются на многих уровнях, включая проблемы с драйверами сетевых адаптеров. Известно, что с драйверами Intel и Broadcom эта опция включается по умолчанию. В связи с этим может возникнуть множество трудностей.
Отметки времени TCP 1323
Согласно RFC 1323, отметки времени предназначены для повышения надежности передачи посредством ретрансмиссии неподтвержденных сегментов по истечению интервала времени RTO (интервала до повторной передачи). Проблема отметок времени заключается в том, что они добавляют дополнительных 12 байт к 20-байтному TCP-заголовку каждого пакета, таким образом, ведя к расходу полосы в связи с увеличением заголовка.
Заметка: В Windows Vista/7 из опций TCP 1323 мы рекомендуем оставить включенной только «Window Scaling».
Сеть прямого доступа к памяти NetDMA (Windows Vista/7)
NetDMA (TCPA) дает расширенные возможности использования прямого доступа к памяти. По сути, эта опция позволяет более эффективно размещать сетевые данные, минимизируя при этом нагрузку на процессор. Опция NetDMA освобождает процессор от хранения пакетов данных, передаваемых с буферов сетевой карты в буферы приложений при помощи движка DMA. Опция должна поддерживаться вашим BIOS, а ваш процессор должен поддерживать технологию Intel I/O Acceleration (I/OAT).
NetDMA не поддерживается Windows 8 и выше.
4. Продвинутые настройки
Этот раздел рассказывает о секции программы под названием «Продвинутые настройки», актуальной для текущих версий Windows.
Оптимизация Internet Explorer
Согласно спецификации HTTP 1.1 в RFC 2616 между клиентом и веб-сервером рекомендуется использовать не более 2 параллельных соединений по умолчанию. Равнозначно спецификация HTTP 1.0 рекомендует использовать не более 4 параллельных соединений (HTTP 1.0 не может обеспечить долговременное соединение, поэтому выигрывает за счет большего количества параллельных соединений). Традиционно Internet Explorer учитывал рекомендации RFC, однако после выпуска IE8, Firefox 3 и Chrome 4 большинство лидирующих браузеров отошли от этих рекомендаций в поисках более высокой скорости загрузки веб-страниц и увеличили число параллельных соединений с серверами до 6 как для HTTP 1.0, так и для 1.1.
Мы же рекомендуем довести количество параллельных соединений до 8-10 на сервер ввиду усложнившейся архитектуры веб-страниц и появления большого количества их элементов. Таким образом, установление множественных соединений оправдывается, особенно для широкополосных Интернет-соединений. Заметьте, что устанавливать более 10 соединений не рекомендуется, так как некоторые веб-серверы ограничивают количество параллельных соединений на одно IP и могут прервать или отбросить такие соединения. Помимо прочих проблем это приведет к незагруженным страницам и к негативному пользовательскому опыту.
Приоритеты разрешений хоста
Эта опция предназначена для повышения приоритета DNS/имени хоста посредством повышения приоритета четырех связанных по умолчанию процессов. Важно отметить, что опция повышает приоритет всех четырех связанных процессов в сравнении с сотнями других активных процессов и держит их в строгом соответствии очереди. Также важно отметить, что в таких случаях мы рекомендуем выбирать здесь значение «optimal» не для того, чтобы создать конфликт между приоритетами других процессов. Будьте осторожны, выбирая другое значение.
Чтобы узнать об этом подробнее, ознакомьтесь с нашей статьей о твике для установления приоритетов разрешений хоста.
Ретрансмиссии
Два значения в этой секции программы контролируют процесс восстановления соединения системой.
Max SYN Retransmissions: позволяет задать число попыток восстановления соединения при помощи SYN пакетов.
Non Sack RTT Resiliency: контролирует расчет времени возврата повторных передач для клиентов без SACK. Это помогает замедлить клиентские соединения за счет того, что TCP/IP становится менее агрессивным в ретрансмиссии пакетов.Интервал до повторной передачи (RTO) для Windows 8 и выше
Интервал до повторной передачи (RTO) определяет, сколько миллисекунд будет затрачено на обработку неподтвержденных данных прежде, чем соединение будет разорвано. Эта опция помогает сократить задержки в ретрансмиссии данных. Значение интервала Initial RTO по умолчанию, равное 3000мс (3 секундам), может быть сокращено до ~2с (за исключением удаленных локаций) для современных широкополосных соединений с низким уровнем задержки. Для соединений с большой задержкой (спутники, удаленные локации) слишком агрессивное снижение этого значения может привести к досрочным ретрансмиссиям. Не стоит постоянно пренебрегать лимитом RTO. Рекомендуемое минимальное значение Min RTO по умолчанию равно 300мс.
Смотри документ RFC 6298
Кэширование ошибок DNS - Windows 7/Vista/2k/XP
Эта опция предназначена для предотвращения занесения в кэш-память отрицательных ответов DNS.
MaxNegativeCacheTtl: определяет, как долго в кэше DNS будет храниться запись об отрицательном ответе (работает только для Windows XP/2003).
NegativeCacheTime: определяет, как долго в кэше DNS будет храниться запись об отрицательном ответе (работает только для Windows 2000/2008/Vista/Windows 7, аналогично MaxNegativeCacheTtl).
NetFailureCacheTime: определяет, как долго DNS-клиент будет отправлять запросы после обнаружения разрыва сети. В течение этого интервала времени DNS-клиент разошлет всем запросам уведомление об истечении срока ожидания ответа. Если значение этой опции будет равно «0», то она будет отключена и DNS продолжит отправлять запросы, несмотря на обрыв сети.
NegativeSOACacheTime: определяет, как долго в кэше DNS будет храниться запись об отрицательном ответе, в то время как начальная запись зоны SOA (Start of Authority) будет оставаться в кэше DNS.
Тип/качество обслуживания
Этот раздел связан с политикой QoS и с планировщиком пакетов QoS в Windows.
NonBestEffortLimit: планировщик пакетов QoS в Windows 7/8/8.1 по умолчанию резервирует 20% сетевого трафика для QoS-приложений, требующих приоритета. Заметьте, резервирование трафика происходит только при активных QoS-приложениях, требующих приоритета в трафике, таких как, например, Windows Update. Выставляя этот параметр на «0» вы убережете Windows от резервирования 20% трафика для такого рода приложений.
Do not use NLA (не используйте NLA): эта не описанная в документации опция является частью tcpip.sys, отвечающей за изменение QoS DSCP-значения. Microsoft требует, чтобы системы Windows 7/8 присоединялись к домену, а также чтобы этот домен был видим специальному сетевому адаптеру для применения политики локальной группы и для настройки DSCP-значения. Если выставить сюда «1», то это уберет все ограничения и позволить вам задать DSCP-значение для всех сетевых устройств, не являясь частью домена. В рамках политики локальных групп DSCP-значение может быть отрегулировано при помощи gpedit.msc.
Игровой твик – опция Network Throttling Index и System Responsiveness (скорость отклика системы)
Network Throttling Index: Windows использует механизм троттлинга, чтобы ограничить обработку немультимедийного сетевого трафика. Так как обработка сетевых пакетов является слишком ресурсо-затратной задачей, цель троттлинга заключается в том, чтобы помочь процессору пропустить некоторые такты для предоставления приоритетного доступа мультимедийным программам. В некоторых случаях, например для гигабитных сетей и некоторых онлайн игр, будет лучше отключить троттлинг для достижения максимальной пропускной способности.
SystemResponsiveness: мультимедийные приложения используют Планировщика классов мультимедиа (MMCSS) для получения приоритетного доступа к ресурсам процессора, при этом они не ущемляют фоновые приложения с более низким приоритетом. А вот на работу с фоновыми приложениями по умолчанию уходит 20% ресурсов процессора. Таким образом, на обработку мультимедиа и некоторых игр остается только 80% отдачи процессора. Optimizer может освободить закрепленные за фоновыми приложениями 20% ресурсов процессора для того, чтобы предоставить их играм.
Заметка: На некоторых серверных операционных системах (Windows 2008 Server) значение SystemResponsiveness может быть выставлено на 100 вместо 20 по умолчанию. При таких значениях больший приоритет все равно будет отдаваться фоновым сервисам, нежели мультимедиа.
Игровой твик – отключаем алгоритм Нейгла
Алгоритм Нейгла был разработан для объединения маленьких пакетов в единый, больший по размеру пакет для более производительной передачи. Несмотря на то, что алгоритм повышает пропускную способность сети и сокращает количество TCP/IP-заголовков, он все же ненадолго задерживает отправку маленьких пакетов. Отключение алгоритма сокращает задержку/пинг в некоторых играх, однако может негативно сказаться на передаче файлов. В Windows алгоритм Нейгла включен по умолчанию.
TcpAckFrequency: «1» для игр и Wi-FI (отключает нейглинг), небольшие значения больше «2» для лучшей пропускной способности.
TcpNoDelay: «1» для игр (отключает нейглинг), «0» чтобы включить нейглинг
TcpDelAckTicks: «0» для игр (отключает), «1-6» означает 100-600мс. Установка значения «1» сокращает эффект алгоритма (по умолчанию 2=200мс).
