Билл Алдерсон, Дж. Скотт Хогдал
Network Computing
Проблема: Для передачи файлов с серверов 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.
Скотт: Маршрутизатор имел только два интерфейса, поэтому вряд ли проблема могла быть связана с его перегруженностью. Конфигурация маршрутизатора также не дала нам ключа к пониманию внутренней природы проблемы. Посему дальнейшими изысканиями мы посоветовали заняться производителю устройства.
Билл: Между тем установка другого маршрутизатора быстро решила проблему. А пользователь и производитель маршрутизатора пусть и дальше разбираются в том, что же вызвало необоснованный сброс пакетов