Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
ДОМОЙПОДПИСКАГДЕ КУПИТЬСТАТЬИRambler's Top100   
 
 
 
    
ЖУРНАЛ
   
Главная
Архив новостей
Новый номер
Архив статей
Адреса в интернет

РУБРИКАТОР
   
• Колонка редактора
• Только на сервере
• Локальные сети
• Бизнес
• Корпоративные сети
• Услуги сетей связи
• Защита данных
• Системы
   учрежденческой связи

• Электронная
   коммерция

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

РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Тематический план
Отдел рекламы

E-MAIL


Rambler's Top100

  

Следите за маршрутизаторами!

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

Проблема: Для передачи файлов с серверов Windows NT центрального офиса нашего предприятия на компьютеры сотрудников, работающих в филиалах, требуется очень много времени — от нескольких секунд до нескольких минут, в зависимости от объема пересылаемой информации. И это при том, что некоторые филиалы подключены по каналам Т1 (1,544 Мбит/с), а все ЛВС являются сегментами Ethernet (10 Мбит/с). Надеемся, что существующая проблема не связана с технологией Frame Relay, которую мы выбрали для транспортировки данных по территориально распределенной сети.

Скотт: Ответ прост: ваши трудности конечно же связаны с технологией Frame Relay. Откажитесь от нее, перейдите на арендованные каналы — и все трудности исчезнут.

Билл: Честно, без дураков!

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

Билл: Просто подсчитав среднюю скорость передачи, мы получили очень низкое ее значение — 4 Кбайт/с, или около 32 Кбит/с! Допустим, причина столь низкой скорости кроется в сети Frame Relay. Что же нужно для получения более высокой пропускной способности?

Скотт: Холодная погода и низкое давление?

Билл: На самом деле здесь стоит подумать не об атмосферных условиях, а о прикладном уровне, запрашивающем большие объемы информации, и особенно о транспортном уровне, использующем механизм скользящего окна (sliding windows) и форсированный режим (packet burst protocol) для выполнения запросов.

Скотт: В нашем случае для взаимодействия с сервером Windows NT центрального офиса рабочая станция Windows 95, находящаяся в сети его филиала, использовала протокол SMB (Server Message Block) поверх NetBIOS и IPX.

Билл: Что ж, давай разбираться дальше.

Скотт: Хотя приложение запрашивало вполне разумные объемы информации (10 Кбайт по запросу SMB "Read Block Raw"), NetBIOS разбивал поток данных на множество дейтаграмм для уровня IPX.

Билл: Итак, по существу, отсутствует транспортный уровень, который выполнял бы оконное управление квитированием и передачей данных.

Скотт: Одно из возможных решений проблемы — переход на TCP/IP.

Билл: Но пользователи TCP/IP также сталкиваются с медленной передачей файлов — значит, надо искать другую причину. В этом нам помогла трассировка пакетов, которая и дала первый ключ к разгадке.

Скотт: Трассировка показала, что скорость чтения файлов с сервера Windows NT центрального офиса порой достигала 1 Мбит/с, однако, как мы уже отметили, средняя скорость была всего лишь 32 Кбит/с.

Билл: Скорость один мегабит в секунду все равно не дотягивает до скорости линии Т1, хотя это и на порядок выше 32 Кбит/с. Итак, в данном случае мы имеем дело с серьезным соперничеством либо за сетевые ресурсы, либо за ресурсы сервера Windows NT, либо...

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

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

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

Билл: Одно из двух: либо запрос не доходил до сервера, либо ответ не возвращался обратно.

Скотт: Пришло время проанализировать всю цепочку от станции до сервера.

Билл: Находясь на удаленном узле, мы подключили наш верный анализатор к интерфейсу V.35, который использовался маршрутизатором для обмена синхронным потоком данных с устройством сетевого окончания (CSU/DSU).

Скотт: Это была уже "территория" распределенной сети, и мы надеялись, что проблема обнаружится здесь.

Билл: Интересно, но мы увидели, что с сервера поступают ответы (правильно сформированные пакеты без ошибок CRC) на каждый запрос SMB.

Скотт: Так как анализатор "видел" правильные ответы на каждый запрос, значит, запросы доходили до сервера.

Билл: Более того, это говорит о том, что с Т1, Frame Relay и устройствами на другом конце канала также все в порядке.

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

Билл: По иронии судьбы каждый пакет, прошедший через Ethernet со скоростью 10 Мбит/с, нормально передавался по каналу Т1, но далеко не каждый из них, пройдя по более медленному каналу Т1, "пробивался" в Ethernet.

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

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





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

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

• Российский сетевой ландшафт в двух измерениях

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

• Двухпроцессорные серверы на базе Pentium Pro

• Восемь сетевых цветных принтеров

• Философия успешного производства (интервью Зоара Зисапеля)

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

• Многопротокольный удаленный доступ через Интернет

• Модернизация сети с помощью АТМ (часть I)

• Следите за маршрутизаторами!

• Передовые технологии: Layer 3 Switching (часть II)

• Ярмарка компьютерных чудес в Новом Орлеане

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

• Развитие российской сети ОКС №7 - основа современных услуг связи

• Анатомия модемных "56К-технологий" (часть II)

• Конференц-связь: проблемы и решения

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

• Сезам, откройся!

• Проектирование отказоустойчивых корпоративных сетей TCP/IP

• Анализ журнала регистраций узла Web, или Поиск рецепта успеха

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

• Игра ва-банк с сетевыми "медвежатниками"

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

• О суеверии, коммутаторе Catalyst 5500 и лаборатории PLUS Communications, Недорогой сервер Digital в России

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

• Интернет в вопросах и ответах. Продолжение



 Copyright © 1997-2001 ООО"Антонюк Консалтинг". Тел. (095) 234-53-21. Факс (095) 974-7110. вверх