Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Не пренебрегайте возможностью настроить TCP

Эрик Холл

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

Существует несколько параметров TCP, позволяющих управлять производительностью соединения, но наиболее важным из них является размер приемного окна. Он определяет число байтов данных, которые передающая сторона может отправить в определенный момент времени. Каждый TCP-пакет (в соответствии со стандартами IETF называемый сегментом) имеет заголовок, среди прочих параметров он содержит поле “размер окна” (WINDOW). Это поле служит для объявления размера доступного пространства в приемном буфере системы в момент отправки сегмента. Сообщением о размере доступного пространства система управляет количеством данных, посылаемых ей удаленным хостом. При увеличении размера окна отправляющая сторона может посылать больше данных. Соответственно уменьшение окна ограничивает объем посылаемой информации, что может привести к неэффективному использованию канала связи.

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

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

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

Пропускная способность, умноженная на время обращения

При решении вопроса о наиболее эффективном размере окна для вашей сети самыми важными представляются два параметра: полное время задержки, связанное с подтверждением приема (round-trip latency), и сквозная пропускная способность (end-to-end bandwidth) сети. Значения этих параметров определяют количество битов данных, которое может передаваться по сети (т. е. находиться “в пути”) в любой заданный момент времени.

Задержка — это интервал времени, требующийся для передачи бита информации из одной системы в другую, включая и время, затрачиваемое на обработку этого бита в обеих системах и во всех переходах (hops) между ними. Чем больше времени требует это “путешествие”, тем больше битов может оказаться в сети. Например, в сети с задержкой 60 мс может находиться в шесть раз больше битов, чем в сети с задержкой 10 мс. Время, затрачиваемое на передачу данных и подтверждение их приема, называется полным временем задержки или временем обращения.

Сквозная пропускная способность тоже непосредственно влияет на количество битов, находящихся в пути, так как от нее зависит, сколько битов можно переслать в единицу времени. Если сквозная пропускная способность составляет 1 Мбит/с, то за каждую секунду можно отправить только 1 Мбит, в то время как при 100 Мбит/с за ту же секунду можно передать уже 100 Мбит данных.

Умножив значение полного времени задержки на значение сквозной пропускной способности, вы получите максимально возможное количество находящихся в пути данных для отдельного TCP-соединения. Эта цифра, по существу, и определяет оптимальный размер WINDOW в первом приближении. Установка меньшей величины приведет к недостаточной загрузке сети: отправитель будет ограничен размером окна, объявленным удаленной системой, а не пропускной способностью сети. Это означает, что, когда количество переданных данных достигнет величины, равной размеру окна, отправитель должен будет прекратить передачу и ждать прибытия подтверждения их приема получателем. Но если значение WINDOW установлено правильно, то отправитель может посылать данные непрерывно, так как к моменту окончания отправки очередной их порции всегда будет появляться подтверждение приема предыдущей. Это позволяет производить обмен информацией непрерывно и в случае потери части данных дает возможность уменьшить время их восстановления.

При выполнении вычислений для определения оптимального размера окна помните, что основное внимание следует обращать именно на сквозную пропускную способность, поскольку в ней учтены все узкие места вашей сети. Если на рабочей станции установлена 100-Мбит/с карта Ethernet и вы связываетесь с удаленной системой по 64-Кбит/с линии ISDN, то максимальная пропускная способность сквозного соединения составляет 64 Кбит/с. Кроме того, как уже отмечалось, необходимо определить время обращения. В случае, когда вы посылаете данные через территориально распределенную ATM-сеть, а подтверждение их приема удаленная система передает вам по спутниковому каналу, полное время задержки будет равно сумме значений задержки в сети ATM и спутниковом канале.

Измерить полное время задержки совсем нетрудно — для этого достаточно провести эхотестирование (pinging) удаленной системы. Эту процедуру следует выполнить несколько раз в течение рабочего дня (так как перегруженность сети в часы пик может привести к увеличению времени задержки) и использовать в расчетах наиболее часто повторяющееся время обращения (оно совсем не обязательно должно быть средним!). Для посылки тестовых запросов, размер которых соответствовал бы наиболее распространенной длине пакетов вашей сети, понадобится генерирующая сообщения произвольной длины утилита ping. Слишком короткие ICMP-сообщения покажут меньшее время обращения по сравнению с реальными сегментами TCP.

И наоборот, использование слишком длинных ICMP-сообщений вызовет очень большие задержки либо приведет к фрагментации IP-пакетов, что может еще более исказить результаты ваших тестов. Для сети Ethernet нужно генерировать IP-пакеты размером 1500 байт, у которых 20 байт занимает заголовок IP и 8 байт — заголовок ICMP. При этом само зондирующее сообщение ICMP будет состоять из 1472 байт данных.

Выполняя вычисления, убедитесь, что используете одинаковые единицы измерения для всех величин — биты или байты, если это удобнее, а также миллисекунды или секунды, иначе результаты будут неверными. Помните также, что 1 Кбайт — это 1024 байт, а 1 Мбайт — это 1024 ґ 1024 байт.

Например, если вы умножаете значение пропускной способности модемного соединения 19,2 Кбит/с на среднее время обращения, составляющее 60 мс (0,06 с), то максимальное количество находящихся в пути данных составит приблизительно 1180 бит (результат округления 1179,648 до целого). Дополнительные примеры вы найдете в табл. 1. Имейте в виду, что этот расчет дает нам лишь число битов, которые могут оказаться в пути в любой заданный момент времени, а вовсе не окончательный оптимальный размер окна.

Как видно из таблицы, число битов в пути существенно зависит от времени обращения и пропускной способности сети. Обратите внимание на порядок этого показателя для линии 384 Кбит/с территориально распределенной сети с задержкой 60 мс и для канала 10 Мбит/с Ethernet с задержкой 2 мс. Пропускная способность сети Ethernet существенно выше, но ее задержка предельно мала, поэтому-то в ней невозможно “запасти” большое число битов в пути. Заслуживает внимания и то, как этот запас битов увеличивается в локальной сети с пропускной способностью 100 Мбит/с

и задержкой 10 мс по сравнению с такой же ЛВС, но с задержкой 2 мс. Ясно, что, чем больше элементов инфраструктуры вы добавляете в вашу сеть, тем сильнее увеличивается задержка. Теперь вам должно быть понятно, почему так важны конкретные измерения именно в вашей сети.

Умножим максимальный размер сегмента на 2n

Еще раз подчеркиваем, что само по себе число битов в пути не является оптимальным размером окна. Вы должны также учесть максимальный размер сегмента (Maximum Segment Size — MSS) применительно к рассматриваемому соединению. Умножайте эту величину на 2n (n = 1, 2, 3…), пока не превысите величину, равную максимальному числу битов в пути. Дело в том, что имеющийся в протоколе TCP алгоритм Delayed Acknowledgment задерживает отсылку подтверждения, пока не будут получены два полноразмерных сегмента TCP. Если отправитель не передаст достаточного количества данных, то получатель не пришлет подтверждение вовремя, вследствие чего обмен данными будет осуществляться неровно.

Например, если максимальный размер сегмента равен 1460 байт (что обычно имеет место для соединений Ethernet и PPP), то размер окна должен быть равен четному числу байтов, кратному 1460. Если размер окна будет равен нечетному числу, умноженному на MSS, то в результате к получателю не придут два полноразмерных сегмента, поэтому он будет задерживать отправку подтверждения до тех пор, пока не истечет значение тайм-аута. На самом деле значение WINDOW по умолчанию должно быть равно не менее чем четырехкратному значению MSS, потому что меньший размер приемного буфера негативно скажется на равномерной передаче данных. В случае, когда размер окна составляет всего два значения MSS, отправитель передаст два сегмента и остановится в ожидании подтверждения на тот период, пока сегменты проходят свой путь по сети. После их получения подтверждение, в свою очередь, тоже должно прийти к отправителю, и только после этого будет выслана следующая порция данных. Все это увеличивает время простоя. Размер окна, равный четырем MSS, по крайней мере, позволит отправителю передать четыре сегмента, при этом последний из них будет отправлен одновременно с получением подтверждения о приеме первых двух.

Вот почему при расчете размера окна по умолчанию любого соединения для многих стеков TCP/IP используют простую формулу MSS ґ 4. Этот метод хорошо работает в сетях с очень малыми значениями задержки, но для медленных соединений лучше использовать величину, в шесть, восемь или более раз превышающую MSS.

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

Единственная конфигурация ЛВС, способная использовать установку по умолчанию в MSS ґ 4, — это 10-Мбит/с Ethernet с задержкой в 2 мс. Остальные конфигурации, особенно сеть 100-Мбит/с Ethernet со множеством переходов (hops), требующая 90-кратного MSS размера окна, при такой настройке будут подвергаться серьезным ограничениям в производительности.

Эта проблема значительно обостряется в “разбросанных” ЛВС Fast Ethernet с многочисленными мостами и маршрутизаторами. Имея несколько сот пользователей единственного Web-узла во внутренней сети с множеством переходов, вы, по-видимому, никогда не достигнете максимальной производительности. К несчастью, если вы в соответствии с определенным вариантом использования сети установите один и тот же размер окна для всех ваших клиентов, у вас появятся проблемы, поскольку для большинства остальных вариантов окно такого размера окажется слишком большим (малым). Например, пользователи, подключаясь к Интернет, станут устанавливать соединения, использующие большие окна, даже если сквозная полоса пропускания у них будет равна всего 256 Кбит/с или даже меньше (чему соответствует намного меньшее число битов в пути).

При слишком большом окне в работе протокола TCP возникают затруднения в восстановлении потерянных данных. Например, если удаленный Web-сервер “увидит” объявленный вашим клиентским ПО размер окна, равный в 131 Кбайт, то он попытается послать именно это количество данных, даже если пропускная способность вашего соединения, умноженная на время обращения, в результате позволяет иметь только 4 Кбайт в пути. Тогда остальные 127 Кбайт будут просто-напросто помещены в очередь маршрутизатора где-то между Web-сервером и вашим клиентом.

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

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

Кроме того, важно отметить, что, поскольку поле размера окна TCP составляет всего 16 бит, максимальное число, которое может быть записано в нем, равно 65 535. Если вы работаете через спутниковую сеть или через какое-то другое соединение с большой задержкой, но широкой полосой пропускания, то необходимый размер окна может превысить эту величину. В этом случае вам нужно будет обратиться к опции WINDOW SCALE (см.: Сети и системы связи. 1999. № 6. C. 100).


http://www.scooterm.ru/category/ekipirovka/ Качественная мотоэкипировка




  
12 '1999
СОДЕРЖАНИЕ

колонка редактора

• Вопрос на триллион долларов

локальные сети

• Мультимедийные розетки изменяются к лучшему

• Кабельные короба: когда стены и потолок непреодолимы

• Стандарты для заводских испытаний оптических кабелей

• Тестируем серверы NAS

интернет и интрасети

• Не пренебрегайте возможностью настроить TCP

системы учрежденческой связи

• Системы речевой почты

новые продукты

• Объединяя сети, Новая платформа

корпоративные сети

• Почтовые системы для предприятий проходят тесты SMTP

• В поисках наилучшего подхода к мониторингу приложений

• Магистральные маршрутизирующие коммутаторы: убедительные результаты в отсутствие грандов

услуги сетей связи

• Серверы удаленного доступа для небольших и средних предприятий

• Телекоммуникационные операторы нового поколения

• Создание мультисервисных сетей: задачи и перспективы

защита данных

• Отечественные средства построения для виртуальных частных сетей

• Как обеспечить конфиденциальность открытых ключей

• "Встроенная" пожароопасность трехфазных ИБП с однофазным выходом



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх