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

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

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

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

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


Rambler's Top100

  

Задержки при передаче файлов

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

Проблема: Каждая региональная сеть нашей корпорации с помощью мостов и маршрутизаторов объединяет несколько ЛВС Ethernet и Token Ring. Региональные сети соединены между собой выделенными линиями через маршрутизаторы. Хотя большая часть ежедневного трафика ограничена пределами региона, все же возникает необходимость удаленного доступа.

Соединение с сервером, просмотр каталогов, другие операции с устройствами удаленного компьютера протекают очень быстро. Передача же файлов приводит нас в замешательство. Каждая попытка с рабочей станции ЛВС Token Ring копировать файл даже сравнительно небольшого размера (10 - 60 Кбайт) требует от 30 до 45 с. Для пересылки файлов удаленных узлов используется командный файл, который подключает станцию к серверу, передает файлы и разрывает соединение. Мы обнаружили, что повторная передача того же файла во время одного сеанса связи занимает лишь несколько секунд! Интересно также отметить, что пользователи ЛВС Ethernet не наблюдают подобных мистических задержек при запуске того же командного файла. Помогите!

***

Скотт: Билл, у меня уже есть решение.

Билл: Какое?

Скотт: Поскольку сети Ethernet работают, надо просто заменить сети Token Ring на Ethernet.

Билл: Ага, правильно! Я не знаю проблем с сетями, которые нельзя было бы решить с помощью денег.

Скотт: Ну а если серьезно, мы собрали чемоданы, вскочили в самолет и полетели к нашему клиенту.

Билл: Мы выбрали узел, на котором возникали задержки в передаче файлов, и начали работу с изучения документации.

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

Билл: Проведенный затем анализ трафика показал, что процедура регистрации в сети NetWare проходит нормально . Рабочая станция успешно соединяется с сервером NetWare 3.12 и устанавливает размер пакета 4172 байта.

Скотт: До сих пор все шло хорошо. Сценарий входа в систему также был прекрасно отработан.

Билл: А теперь перейдем к самому интересному. Мы достигли момента, когда командный файл на рабочей станции вот-вот должен был запросить копирование файла с удаленного сервера.

Скотт: Файл-сервер положительно ответил на запрос об открытии файла, и рабочая станция послала команду прочитать первые 4110 байт файла.

Билл: Но ответа от сервера не последовало.

Скотт: Через 2,75 с протокол ядра NetWare (NetWare Core Protocol — NCP) попросил переслать повторно те же 4110 байт.

Билл: Затем прошли еще 2,75 с и была предпринята третья попытка. С этого момента протокол NCP более не пытался связаться с сервером, предположив, что маршрут к удаленной сети потерян или изменен, и направил запрос IPX RIP, чтобы найти сеть, связанную с удаленным сервером.

Скотт: Локальный маршрутизатор ответил сразу же, и NCP попытался прочитать файл снова, на этот раз запросив пересылку 4096 байт.

Билл: Она опять не состоялась, и мы увидели последовательные попытки с запросами на передачу 3584, 2560, 2048, 1536 и 1024 байт. На последнее предложение удаленный сервер, наконец, ответил.

Скотт: Размеры запрашиваемых пакетов могут поначалу показаться странными, но если начать отсчет с 4096 байт, то нетрудно увидеть, что протокол NCP при каждой следующей попытке вычитает 512 байт.

Билл: Не лишним будет упомянуть, что между последовательными попытками проходят те же 2,75 с.

Скотт: Таким образом, общее время от первой попытки до успешной последней составило 24 с. Начиная с этого момента, рабочая станция использовала размер пакета 1 Кбайт для всех последующих операций с удаленными файлами.

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

Скотт: Недавно мы рассматривали случай, когда маршрутизатор и рабочая станция преодолевали проблему слишком большой MTU в IP-сети.

Билл: На этот раз мы имели дело с протоколом IPX, в котором отсутствует фрагментация передаваемого файла. Поэтому нам пришлось действовать по-другому.

Скотт: Увеличение MTU маршрутизатора для порта распределенной сети, поскольку посылать пакеты размером 4 Кбайт по выделенной линии, работающей на скорости 256 Кбит/с, нецелесообразно.

Билл: Еще одна возможность — ограничить максимальный размер пакета в момент загрузки драйвера NetWare на рабочей станции. Однако такое решение нежелательно, поскольку оно лишает пользователей сети Token Ring возможности передавать по кольцу кадры размером 4 Кбайта.

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

Билл: Теперь протокол NCP на рабочей станции использовал совершенно другой алгоритм для определения размера пакета.

Скотт: Сразу же после согласования с удаленным сервером размера пакета, который составил 4174 байта, протокол NCP расширил команду создания канала связи, в которую были включены эхо-данные LIP (Large Internet Packet) и пробелы, чтобы дополнить IPX-данные до 4174 байта.

Билл: После неудачной попытки эхо-тест установил прежнюю минимальную единицу передачи для IPX-пакета — 576 байт.

Скотт: Это сработало: сервер послал рабочей станции эхо-ответ на команду.

Билл: Далее рабочая станция выполнила последовательность эхо-тестов и остановилась на максимальной единице передачи пакетов IPX в 1478 байт. Этот процесс занял менее 8 с.

Скотт: Таким образом определилась общая длина кадра для рабочей станции Token Ring, которая составила 1515 байт, включая CRC.

Билл: Из того факта, что при такой MTU узлы сети Ethernet использовали длину кадра 1518 байт без каких-либо проблем, мы заключили, что один из портов маршрутизатора, подключенного к выделенной линии корпоративной сети, вероятно, настроен на максимальную единицу передачи, соответствующую Ethernet.

Скотт: Такая настройка позволяла небольшому пакету, содержащему запрос на чтение 4 Кбайт, прекрасно проходить к серверу, но посылаемые сервером в ответ данные размером 4 Кбайта просто сбрасывались.

Билл: Поэтому необходимо, чтобы рабочая станция могла настраиваться на MTU, установленную в сети. VLM не только производит настройку передачи быстрее, чем NETX, но и предлагает оптимальный размер пакета.

Скотт: Так была решена еще одна мистическая задача.


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




  
3 '1996
СОДЕРЖАНИЕ

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

• Как заработать миллион

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

• Слишком много справочников

• Жесткие диски большой емкости для серверов

• Проблема сертификации кабелей

• Виртуальные ЛВС: мифы и реальность

• NDS - совместимое клиентское ПО для Windows 95

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

• Технология АТМ

• Сетевые технологии XXI века

• Суперсервер в сети NetWare

• Программные средства удаленного доступа

• Задержки при передаче файлов

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

• Спутниковая сеть ТЕЛЕПОРТ-ТП: технология DAMA на российском рынке

• Компьютерная телефония снова в пути

• Спутниковая система передачи данных ROMANTIS DATA

приложения клиент-сервер

• Системы обмена электронными сообщениями

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

• Windows 95: окно в Internet

• Парад программ просмотра

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

• Защита от электронного шпионажа

• Защищайтесь, а не то ...

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

• Новая версия Back Offise, Система хранения данных SPANStor-Mag, IWare облегчает работу по TCP/IP в сети NetWare, Концентраторы TigerStack



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