Увеличение скорости выд смена tcp. TCPOptimizer - повышение скорости интернет, оптимизация, уменшение пинга
В 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 и не может быть увеличен.
Оригинал статьи:
Перевод: Сгибнев Михаил
Не знаю, как поведут себя данные фиксы на этом сервере,
но на руофе они мне очень помогали... Приемы, увеличивающие, отзывчивость игры и в некоторых случаях, устраняющие лаги:
Данные действия применимы и тестировались на 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 Мбайт/с.
- Перевод
В первой части мы разобрали «тройное рукопожатие» TCP и некоторые технологии - 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-пакете. Это новый алгоритм, его должны поддерживать и клиент и сервер. Изучите, может ли ваше приложение извлечь из него пользу.
Слишком часто разработчики винят недостаточную производительность сети, хотя на самом деле зачастую причина в неправильно настроенном программном обеспечении. В этой статье описаны некоторые утилиты для анализа и настройки сети, которые позволяют разработчикам оптимизировать свои приложения для оптимизации сетевых возможностей.
Как-то раз мой друг Боб пришел ко мне с вопросом. Он написал программу на 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, устраняющий эту проблему.