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

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

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

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

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


Rambler's Top100

  

Если TCP упрямится

Билл Алдерсон, Дж. Скотт Хогдал

Проблема. У наших клиентов было разработано специализированное приложение для выполнения анализа информации по запросу руководства, основанное на механизме OLAP (Online Analytical Processing). База данных системы OLAP обновлялась по сценарию, который предусматривал сбор информации из девяти файлов, расположенных в семи удаленных офисах. Пользователей беспокоило, что сбор данных по сети с протоколом TCP/IP занимал гораздо больше времени, чем это было необходимо с учетом незначительного объема передаваемой информации. Совершенно очевидно, что выделенные каналы T1, использовавшиеся в данной системе для связи с удаленными серверами, работали далеко не с полной отдачей. Однако каждый раз после сбора и обработки данных связь через эти каналы становилась просто замечательной и ответ на дополнительный запрос к удаленному серверу можно было получить без задержки.

Скотт: Для начала было бы неплохо иметь полную картину происходящего.

Билл: Согласно документации наших заказчиков, рабочая станция, собирающая данные, работала в сети Token Ring. Эта сеть имела прямой интерфейс с маршрутизатором, который был соединен через каналы T1 с удаленными сетями.

Скотт: Таким образом, со стороны клиента система не внушала никаких опасений.

Билл: Удаленные сети тоже ничем особенно не выделялись. Они состояли из рабочих станций, подключенных к тому же сегменту локальной сети, что и маршрутизатор, разве что удаленные локальные сети использовали протокол Ethernet.

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

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

Скотт: Однако, несмотря на видимое благополучие, приложение OLAP при выполнении заданного сценария опроса удаленных серверов показывало скорость обмена всего 220 Кбит/с, или приблизительно 28 Кбайт/с.

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

Скотт: Таким образом, можно было предположить следующее: либо приложение обменивалось порциями данных длиной 512 байт (что мало вероятно), либо настройка MSS (Maximum Segment Size) в стеке TCP/IP составляла 512 байт.

Билл: Запустив повторно инициализацию TCP-соединения (нас интересовал этап синхронизации), мы заметили, что сервер Unix, выполнявший сбор данных, объявлял удаленному хосту свой параметр MSS равным 512.

Скотт: Иногда процесс установки MSS называют согласованием (negotiating). На самом же деле в TCP предусмотрено только объявление противоположной стороне максимального размера сегмента, который на данном конце может быть обработан. Никакого "согласования" здесь нет.

Билл: В результате хост удаленной сети посылал серверу, собиравшему данные для системы OLAP, пакеты с максимальной длиной 512 байт.

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

Билл: Хуже того, мы обнаружили, что размер приемного окна TCP, объявленный Unix-сервером, почему-то падал до нуля, и перед приемом новой порции данных был равен уже 4096 байт, несмотря на то что исходный размер окна составлял 16 384 байт.

Скотт: Для тех, кто еще не осведомлен: размер приемного окна — это критически важный параметр при обмене по TCP между двумя хостами, поскольку он устанавливает, какой объем данных хост хотел бы принять, прежде чем выслать пакет подтверждения (ACK).

Билл: Вооруженные этим знанием, мы отыскали, где можно "отрегулировать" TCP на сервере Unix.

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

Билл: Что касается нас, то мы начали с увеличения размера MSS, изначально составлявшего 512 байт.

Скотт: Мы уже знали, что данная Unix-машина может использовать MSS размером свыше 512 байт, поскольку другие соединения TCP, осуществлявшиеся с нее же, использовали MSS, равный 1460 байт.

Билл: Что такого особенного было в этих соединениях, что позволяло им не ограничивать себя столь малой величиной MSS?

Скотт: Внимательно приглядевшись к их IP-адресам, мы обнаружили, что они принадлежали другому классу, т. е. данные соединения являлись локальными.

Билл: Более того, они, скорее всего, были установлены в той же подсети, в которой находился сервер Unix.

Скотт: Узнав маску локальной подсети, мы подтвердили наше предположение.

Билл: Данный сервер Unix был несколько "консервативен" и не позволял TCP-соединениям с удаленными сетями использовать MSS свыше 512 байт.

Скотт: Иногда это и правда бывает необходимо, так как сервер Unix не "знает", что лежит между двумя подсетями IP.

Билл: Но нам не хотелось, чтобы наши маршрутизаторы разбивали пакеты на несколько дейтаграмм IP только из-за предполагаемого несоответствия ограничений на размер максимального блока передачи (Maximum Transfer Unit — MTU).

Скотт: Еще раз обратившись к сетевой документации и проверив величину MTU для портов Т1 маршрутизаторов на обоих концах, мы решили, что максимальный "безопасный" размер MSS, который будет хорошо работать на всех трех топологиях, равен 1460 байт.

Билл: Мы установили для удаленных подсетей размер MSS по умолчанию равный 1460 байт, и проанализировали трафик еще раз. Результаты улучшились.

Скотт: Но это было еще не все, потому что размер приемного окна продолжал падать и не мог удержаться на уровне 16 384 байт.

Билл: Звонок поставщику данной версии Unix прояснил нам, как можно удвоить размер приемного окна. Теперь он составлял 32 678 байт.

Скотт: В конечном счете мы добились скорости свыше 1 Мбит/с и увеличили производительность приблизительно в четыре раза по сравнению с первоначальным значением


распечатать статью




  
7 '1997
СОДЕРЖАНИЕ

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

• Microsoft и сыр

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

• Коммутаторы Ethernet и Fast Ethernet. Сделай правильный выбор

• Как Кристофер Робин модернизировал свое предприятие

• Масштабируемость сервера

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

• Лучшие продукты 1997 года

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

• Оптические абонентские сети - уже сегодня

• CDMA: сказка становится былью

• Технология ADSL

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

• Меняю ваучер на компьютер с доступом в Интернет

• Групповое ПО: миграция в Интернет

• Если TCP упрямится

• Прикладные программные интерфейсы для Web

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

• ИБП для централизованных систем питания

• "Спасательное" ПО, или Как удержаться на плаву

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

• Коммутатор ForeRunnerLE 155 фирмы FORE Systems, Универсальный сетевой анализатор PrismLite

только на сервере

• Вокруг сетевого компьютера

• Интернет в вопросах и ответах

• Рецепты для корпоративных пользователей Интернет



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