Тонкая Настройка TCP. Решено Оптимизация TCP, Win и возможная борьба с лагами
- Перевод
И некоторые технологии - 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 .Если ветка, указанная в пункте 5, отсутствует, то делается следующее:
Открываем – Пуск – Панель управления – Программы и Компоненты – (слева) Включение и отключение компонентов Windows.
Там находим пункт – Сервер очереди сообщений Майкрософт (MSMQ) , и ставим галочку напротив него и все галочки внутри в выпадающем списке компонентов. Перегружаемся, идем в реестр и видим там нужную нам запись
Есть вариант изменения ключа рееста
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT \CurrentVersion\Multimedia\SystemProfile
Имя: NetworkThrottlingIndex (если нет - создаем)
Параметр: DWORDЗначение означает количество пакетов не мультимедиа трафика в 1 миллисекунду, по умолчанию 10. Можно попробовать увеличить число или просто поставить шестнадцатеричное FFFFFFFF , в последнем случае полностью отключится регулирование трафика.
Дополнительные параметры:
Эти параметры так же способны оптимизировать сетевой обмен для нашего случая. При выборе их значений я руководствовался личным опытом, а не просто верил на слово различным советам. Я временно сижу на 3G интернете, где пинг сам по себе не очень, особенно в вечернее время, и мне ниже перечисленные настройки помогли . Однако, есть риск, что какой-нибудь параметр из них может и ухудшить ситуацию с пингом (хоть и не на много), поэтом я назвал их дополнительными и необязательными к выставлению.
Раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Tcpip\Parameters
Раздел HKEY_LOCAL_MACHINE\SOFTWARE \Policies\Microsoft\Windows\Psched
- SackOpts
Выборочная передача поврежденных данных. Отлично помогает в борьбе с лагами, если клиент не кривой.
Рекомендуемое значение: 1 (единица).
Чтобы отключить: 0- EnablePMTUDiscovery
Автоматически определять максимальный размер передаваемого блока данных.
Рекомендуемое значение: 1 (единица).
Чтобы отключить: 0- EnablePMTUBHDetect
Включает алгоритм обнаружения маршрутизаторов типа "черная дыра". Видел советы по выставлению этого параметра в 0, однако, для себя я не заметил влияние этого параметра на пинг, а надежная связь нужна всем =)
Рекомендуемое значение:1 (единица).
Чтобы отключить: 0- DisableTaskOffload
Позволяет разгрузить центральный процессор, освободив его от вычислений контрольных сумм для протокола TCP, переложив эту задачу на сетевой адаптер.
Рекомендуемое значение: 0 (нуль).
Чтобы отключить: 1
Недостаток: Если возникли сбои в соединениях - отключите параметр.- DefaultTTL
Определяет максимальное время нахождения пакета IP в сети, если он не может попасть на узел назначения. Это позволяет значительно ограничить количество маршрутизаторов, через которые может пройти пакет IP, прежде чем будет отброшен (вдруг пакет заблудился, зачем мы будем его ждать?).
Рекомендуемое десятичное значение: 64
Чтобы отключить: удалить параметрЧтобы вручную не править эти дополнительные параметры в реестре, можно воспользоваться готовыми reg-файлами для Включения и Отключения этих фитч.
- NonBestEffortLimit
Отключает резервирование пропускной способности канала для QoS.
Рекомендуемое значение: 0 (нуль).Сетевые твики:
Начиная с этой версии ОС появились дополнительные сетевые параметры, которые могут нам пригодится. Данные твики представляют собой команды, в данном случае, сразу содержащие рекомендуемые настройки. Чтобы их применить, нужно запустить командную строку (cmd) от имени администратора. Чтобы посмотреть текущие настройки, можно воспользоваться командой netsh int tcp show globalИтак, команды:
- netsh int tcp set global rss=enabled
Использование нескольких процессов для обработки входящего потока, без RSS TCP/IP работает всегда только на одном процессоре даже если ПК многопроцессорный.- netsh int tcp set global netdma=enable
Обмен информацией между сетевой платой и памятью ОЗУ без участия CPU (NetDMA).
Возможные значения: enable / disable- netsh int tcp set global dca=enable
Прямой доступ к кэшу NetDMA 2.0 (Direct Cache Acess).
Возможные значения: enable / disable- netsh interface tcp set heuristics wsh=enable
Автоматический подбор размера окна TCP (WSH). По идее, сводит на нет настройку следующего параметра, но пусть будет чтобы потом можно было что-то безболезненно включать / отключать, не сильно отступаясь от цели.
Возможные значения: enable / disable- netsh int tcp set global autotuninglevel=highlyrestricted
Автонастройка размера приемного окна TCP, не сильно отступаясь от значения по умолчанию.
Возможные значения: disable / higlyrestricted / restricted / normal / experimental- netsh int tcp set global timestamps=enable
Штампы времени при установки с ключами как Auto-Tuning Level оптимальный выбор размера окна приема.
Возможные значения: enable / disable- netsh int tcp set global ecncapability=enable
ECN - это механизм взаимодействия маршрутизаторов о заторах в сети. Он предназначен для уменьшения ретрансляции пакетов. Это позволяет автоматически снижать скорость передачи данных для предотвращения потерь данных. Описание говорит само за себя, для надежности.
Возможные значения: enable / disable- netsh int tcp set global congestionprovider=none
CTCP увеличивает темп передачи с одновременным контролем размера окна и пропускной способности (Add-On Congestion Control Provider). Во всех гайдах в интернете, которые мне попадались, советовали установить этот параметр равным ctcp. Однако, на практике, всё оказалось куда более сложнее. В моем случае он вызвал только более продолжительные лаги, несмотря на то, что потери пакетов (и всё в этом роде) он, вроде как, и призван устранять. Поэтому я рекомендую всё же значение none, исходя из опыта. Возможно, в сетях с более надежной связью CTCP и даст профит.
Возможные значения: none / ctcp / defaultОтключаем сетевой протокол Teredo (для тех кто не использует IPv6).
Инновация, которая все время чекает соединение и пакеты на предмет принадлежности их к сети IPv6, нагружая сетевую карту и забивая наш канал данных. Отключение Teredo может ускорить работу сети и интернета, как это делается:
Запускаем Командную строку (Пуск > Выполнить > cmd ) и вводим команды по очереди.
netsh
interface
teredo
set state disabledДля возврата Teredo, команды вводятся такие же, кроме последней. Последняя должна быть set state default
Переключение между окнами.
Не знаю как вы, а я столкнулся с проблемой переключения окон запущенного клиента. Суть проблемы в том, что при переключении активного окна, система либо переключала на рабочий стол, либо не переключала окно вовсе. К счастью я нашел решение! Проблема таилась в интерфейсе Aero стандартного переключателя окон. Небольшой фикс сменит стиль свитчера на стиль классического Win XP. Ссылка на архив ниже...
В архиве два файла, один для установки, другой для отмены изменений, если вдруг вам этот фикс не помог.
Оптимизация настроек TCP/IP необходима для улучшения пропускной способности сети. Как это сделать? Разбираемся.
заг��зка...
Такие операционные системы, как Windows Vista и Windows 7 позволяют изменять много параметров для настройки сетевого протокола TCP/IP и улучшения пропускной способности.
Тем не менее большинство из них спрятаны от прямого доступа в реестре Windows. Некоторые из этих параметров могут быть обнаружены в недрах конфигурации сетевой карты. Но их значение зачастую понятны только специалистам. Опытные пользователи понимают, что изменение параметров реестра и настроек сетевого оборудования следует проводить лишь со знанием дела, ведь подобные манипуляции могут привести к необратимым последствиям. В тоже время помните, что оптимизация настроек сетевого протокола не влияет на скорость Интернета от провайдера, а лишь улучшает пропускную способность Вашей линии. Проводя измерение скорости интернета онлайн Вы можете убедиться в этом, запустив тест до и после применения новых параметров.
Итак, переходим к практике. Есть несколько бесплатных программ, основная функция которых − оптимизация настроек TCP/IP . Одна из них ¬− SG TCP Optimizer: она устанавливает рекомендуемые параметрам TCP/IP, основанные на опыте специалистов в этой области. Многие пользоваели считают, что данное приложение является лучшим среди примитивных программ оптимизации TCP/IP, но продвинутые юзеры не готовы признать подобный программный продукт за качестенное решение проблем сети.
Итак:
первое, что нужно сделать – скачать и установить программу SG TCP Optimizer. Затем запустить ее «от имени администратора».
Далее в окне программы выберите пропускную способность Вашей сетевой карты (вверху). Потом установите внизу окна режим работы «оптимальный» и примените изменения. Перезагрузите компьютер.Оптимизация настроек TCP/IP завершена. Теперь скорость передачи данных будет больше до 30 %. Короткий тест на Windows Vista показал, что скорость передачи больших файлов увеличилась с 30 Мбайт/с до 50 Мбайт/с.
Проблемы при регистрации на сайте? НАЖМИТЕ СЮДА ! Не проходите мимо весьма интересного раздела нашего сайта - проекты посетителей . Там вы всегда найдете свежие новости, анекдоты, прогноз погоды (в 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
В Linux 2.4 реализован механизм автоконфигурирования размера буферов отправляющей стороны, но это предполагает, что вы установили большие буфера на получающей стороне, поскольку буфер отправки не будет расти в зависимости от получающего буфера.
Однако, у Linux 2.4 есть другая странность, о которой нужно знать. Например: значение ssthresh для данного пути кэшируется в таблице маршрутизации. Это означает, что, если подключение осуществляет повторную передачу и уменьшает значение окна, то все подключения с тем хостом в течение следующих 10 минут будут использовать уменьшенный размер окна, и даже не будут пытаться его увеличить. Единственный способ отключить это поведение состоит слкдующем (с правами пользователя root):
sysctl -w net.ipv4.route.flush=1
Дополнительную информацию можно получить в руководстве .
Linux 2.6
Начинаясь с Linux 2.6.7 (с обратным портированием на 2.4.27), linux включает в себя альтернативные алгоритмы управления перегрузкой, помимо традиционного ‘reno’ алгоритма. Они разработаны таким образом, чтобы быстро оправиться от потери пакета на высокоскоростных глобальных сетях.
Linux 2.6 также включает в себя алгоритмы автоматической оптимизации буферов принимающей и отправляющей стороны. Может применяться тоже решение, чтобы устранить странности ssthresh кэширования, что описанно выше.
Есть пара дополнительных sysctl параметров настройки для 2.6:
# don"t cache ssthresh from previous connection
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
# recommended to increase this for 1000 BT or higher
net.core.netdev_max_backlog = 2500
# for 10 GigE, use this
# net.core.netdev_max_backlog = 30000
Начиная с версии 2.6.13, Linux поддерживает подключаемые алгоритмы управления перегрузкой. Используемый алгоритм управления перегрузки можно задать, используя sysctl переменную net.ipv4.tcp_congestion_control, которая по умолчанию установлена в cubic or reno, в зависимости от версии ядра.
Для получения списка поддерживаемых алгоритмов, выполните:
sysctl net.ipv4.tcp_available_congestion_control
Выбор опций контроля за перегрузкой выбирается при сборке ядра. Ниже представлены некоторые из опций, доступных в 2.6.23 ядрах:
* reno: Традиционно используется на большинстве ОС. (default)
* :CUBIC-TCP (Внимание: Есть бага в ядре Linux 2.6.18. Используйте в 2.6.19 или выше!)
* :BIC-TCP
* :Hamilton TCP
* :TCP Vegas
* :оптимизирован для сетей с потерями
Для очень длинных и быстрых каналов я предлагаю пробовать cubic или htcp, если использование reno желательно. Чтобы установить алгоритм, сделайте следующее:
sysctl -w net.ipv4.tcp_congestion_control=htcp
Дополнительную информацию по алгоритмам и последствиям их использования можно посмотреть .
Вниманию использующих большие MTU: если вы сконфигурировали свой Linux на использование 9K MTU, а удаленная сторона использует пекеты в 1500 байт, то вам необходимо в 9/1.5 = 6 раз большее значение буферов, чтобы заполнить канал. Фактически, некоторые драйверы устройств распределяют память в зависимости от двойного размера, таким образом Вы можете даже нуждаться в 18/1.5 = в 12 раз больше!
И наконец предупреждение и для 2.4 и для 2.6: для очень больших BDP путей, где окно > 20 MB, вы вероятно столкнетесь с проблемой Linux SACK. Если в «полете» находится слишком много пакетов и наступает событие SACK, то обработка SACKed пакета может превысить таймаут TCP и CWND вернется к 1 пакету. Ограничение размера буфера TCP приблизительно равно 12 Мбайтам, и кажется позволяет избежать этой проблемы, но ограничивает вашу полную пропускную способность. Другое решение состоит в том, чтобы отключить SACK.
Если вы используете Linux 2.2, обновитесь! Если это не возможно, то добавьте следущее в /etc/rc.d/rc.local :
echo 8388608 > /proc/sys/net/core/wmem_max
echo 8388608 > /proc/sys/net/core/rmem_max
echo 65536 > /proc/sys/net/core/rmem_default
echo 65536 > /proc/sys/net/core/wmem_default
FreeBSD
Добавьте это в /etc/sysctl.conf и перезагрузитесь:
kern.ipc.maxsockbuf=16777216
net.inet.tcp.rfc1323=1
В FreeBSD 7.0 добавлена функция автокогфигурирования буферов. Но значения их можно отредактировать, так как по умолчанию буферы 256 KB, а это очень мало:
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
Для общего развития покажу еще несколько параметров, но их дефолтные значения и так хороши:
net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
net.inet.tcp.sendbuf_inc=8192 # step size
net.inet.tcp.recvbuf_auto=1 # enabled
net.inet.tcp.recvbuf_inc=16384 # step size
У FreeBSD есть кое-какие ограничения, включенным по умолчанию. Это хорошо для модемных подключений, но может быть вредно для пропускной способности на высокоскоростных каналах. Если Вы хотите «нормальное» TCP Reno, сделайте следущее:
net.inet.tcp.inflight.enable=0
По умолчанию, FreeBSD кэширует подробности подключения, такие как порог slow start и размер окна перегрузки(congestion windows) с предыдущего подключения на тот же самый хост в течение 1 часа. В то время как это хорошая идея для веб-сервера, но плохая для тестирования пропускной способности, поскольку 1 большой случай перегрузки задушит производительность в течение следующего часа. Чтобы уменьшить этот эффект, установите это:
net.inet.tcp.hostcache.expire=1
Для получения информации о тюнинге NetBSD, обратитесь к .
Внимание: у FreeBSD версий ниже 4.10 нет реализации SACK, что сильно снижает ее производительность по сравнению с другими операционными системами. Вы необходимо обновиться до 4.10 или выше.
Solaris
Для Solaris просто сделайте загрузочный скрипт (например, /etc/rc2.d/S99ndd) следующего содержания:
#!/bin/sh
# increase max tcp window
# Rule-of-thumb: max_buf = 2 x cwnd_max (congestion window)
ndd -set /dev/tcp tcp_max_buf 4194304
ndd -set /dev/tcp tcp_cwnd_max 2097152# increase DEFAULT tcp window size
ndd -set /dev/tcp tcp_xmit_hiwat 65536
ndd -set /dev/tcp tcp_recv_hiwat 65536
Для получения дополнительной информации, обратитесь к
Windows XP
Самый простой способ настроить TCP под Windows XP состоит в том, чтобы получить DrTCP из «DSL Reports». Установите «Tcp Receive Window» в вычесленное значение BDP (e.g. 4000000), включите «Window Scaling» «Selective Acks» и «Time Stamping».
Провести дополнительную настройку можно с помощью сторонних утилит, таких как и .
Для проверки изменений можно воспользоваться редактором реестра. Наша цель — вот эти параметры:
# turn on window scale and timestamp option
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=3
# set default TCP receive window size
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=256000
# set max TCP send/receive window sizes (max you can set using setsockopt call)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=16777216
Вы можете использовать setsockopt() для программного изменения значения буферов до размера GlobalMaxTcpWindowSize, или можете использовать TcpWindowSize для задания значения буферов по умолчанию всех сокетов. Второй вариант может быть плохой идеей, если у вас мало памяти.
Для получения дополнительной информации, обратитесь к документам , и
Windows Vista
Хорошая новость! У Windows Vista имеется автонастройка TCP. Максимальный размер окна может быть увеличен до 16 MB. Если вы знаете, как сделать его больше. Дайте мне знать.
Vista также включает в себя «Compound TCP (CTCP)», что очень похоже на cubic в Linux. Для задействования этого механизма, необходимо выполнить:
netsh interface tcp set global congestionprovider=ctcp"
Если вы хотите включить/выключить автонастройку, выполните следующие команды:
netsh interface tcp set global autotunninglevel=disabled
netsh interface tcp set global autotunninglevel=normal
Внимание, команды выполняются с привилегиями Администратора.
Нет возможности увеличить значение буферов по умолчанию, которое составляет 64 KB. Также, алгоритм автонастройки не используется, если RTT не больше чем 1 ms, таким образом единственный streamTCP переполнит этот маленький заданный по умолчанию буфер TCP.
Для получения дополнительной информации, обратитесь к следующим документам:
Mac OSX
Mac OSX настраивается подобно FreeBSD.
sysctl -w net.inet.tcp.win_scale_factor=8
sysctl -w kern.ipc.maxsockbuf=16777216
sysctl -w net.inet.tcp.sendspace=8388608
sysctl -w net.inet.tcp.recvspace=8388608
Для OSX 10.4, Apple также предоставляет патч , увеличивающий максимальный размер буферов сокета до 8MB и еще кое-что по мелочи.
Для получения дополнительной информации, обратитесь к .
AIX
Для повышения производительности на SMP системах, выполните:
Это позволит обработчику прерываний интерфейов GigE на многопроцессорной машине AIX выполняться в многопоточном режиме.
IRIX
Добавьте в файл /var/sysgen/master.d/bsd такие строки:
tcp_sendspace
tcp_recvspace
Максимальный размер буфера в Irix 6.5 составляет 1MB и не может быть увеличен.
Оригинал статьи:
Перевод: Сгибнев Михаил
Загрузка...
