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

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

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

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

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


Rambler's Top100

  

Файловая система для Интернет: WebNFS или CIFS

Тодд Танненбаум

Прикладные программы, создаваемые для сети Интернет и Web, становятся все сложнее, и соответственно все большие требования предъявляются к серверам Интернет. Например, они должны играть роль хост-машин для ПО поддержки коллективных работ (groupware), а также обеспечивать высокую производительность и согласованное выполнение вычислительных и коммерческих приложений. Однако из-за отсутствия у Интернет собственной файловой системы этот нарождающийся класс интерактивных приложений до сих пор находится в менее выгодном положении, чем их «коллеги» из локальных сетей. Компания Sun Microsystems и корпорация Microsoft надеются изменить эту ситуацию каждая с помощью собственных протоколов WebNFS и CIFS.

Файловые системы Интернет, в частности WebNFS или CIFS, позволят клиентам монтировать удаленные диски (тома), просматривать содержимое каталогов и предоставят такой же доступ к удаленным файлам в Интернет, какой имеет место при их нахождении на локальной машине. И хотя службы FTP и HTTP в состоянии выполнять некоторые элементарные функции файловой системы, например такие, как передача файлов от клиента к серверу (upload) и обратно (download), большинство других ее важных элементов в них отсутствует. Так, ни FTP, ни HTTP не поддерживают функций блокировки файла или исключительного доступа к нему. Оба этих протокола предназначены для последовательной передачи всего файла целиком, следовательно возможность произвольного доступа к файлу, т. е. чтение его отдельных фрагментов, в них не предусмотрена.

В протоколе HTTP версии 1.1 такой доступ и средства, значительно улучшающие сетевую производительность, уже есть, но и эта версия пока «не умеет» выполнять самые простые операции. Например, HTTP 1.1 не может сообщить пользователю, сколько свободного места осталось на диске; концепция каталогов отражена вообще очень слабо и отсутствуют самые элементарные функции файловой системы, даже такие, как переименование файла.

В настоящее время процесс редактирования документа через Интернет не так прост: сначала вам при помощи службы HTTP или FTP приходится загружать его с сервера на свою локальную машину и потом, уже после редактирования, передавать обратно на сервер. Будь в Интернет файловая система, она позволила бы осуществлять «прозрачный» удаленный доступ и редактировать файл прямо на месте, с помощью соответствующего приложения, и это существенно снизило бы сетевую нагрузку, порождаемую передачей файлов между сервером и клиентом. В этом случае многие приложения коллективных работ, поддерживающие использование общего каталога, сразу же стали бы пригодными для Интернет и отсутствовала бы необходимость как-либо переделывать их, в частности придавать им вид приложения клиент—сервер.

WebNFS = NFS + «кое-что сверху»

Компания Sun Microsystems, создавшая в свое время сетевую файловую систему NFS, предложила группе IETF принять протокол WebNFS в качестве стандарта файловой системы для Интернет. Получив широчайшее распространение на файл-серверах, работающих в среде Unix, NFS стала стандартом де-факто и помимо этого, обеспечила себе большой успех на рынке ПК. Более того, множество самых разных поставщиков предлагают ПО клиента NFS практически для всех существующих ОС, причем более 50% установленных NFS-клиентов работают на ПК в среде Microsoft Windows. Самой распространенной разновидностью NFS стала ее версия 2, а версия 3 была создана с целью снять некоторые ограничения, существовавшие в предыдущей версии. В свою очередь, WebNFS была просто «надстроена» над версией 3 и к ней добавлены средства, улучшающие работу в Интернет.

В настоящее время NFS работает либо по протоколу UDP, либо по протоколу TCP, причем первый используется чаще. Однако для установления соединений в Интернет лучше всего подходит именно TCP, так как он гарантирует правильный порядок доставки пакетов, к тому же в нем реализованы алгоритмы для контроля за потоками данных и отслеживания перегрузок в сети.

Компания Sun сделала и другое дополнение к NFS: возможность взаимодействия WebNFS с межсетевыми экранами Интернет. В системе NFS версий 2 и 3 используется механизм вызова удаленных процедур RPC. Причем, чтобы воспользоваться им, клиент должен послать запрос на обслуживание процессу portmapper (распределитель портов), находящемуся в режиме ожидания на сервере с общеизвестным IP-портом. В ответ portmapper пересылает клиенту номер порта, на котором он сможет найти сервер NFS.

Проблема заключается в том, что лишь немногие межсетевые экраны Интернет в состоянии справиться с такой операцией; большинство их поддерживают только TCP-соединения с постоянными, т. е. общеизвестными, портами. Поскольку NFS уже использует порт 2049, совершенно естественно, что WebNFS-клиенты должны игнорировать описанный выше процесс и соединяться с ним напрямую.

Для получения логического номера файла (file handle) от программы-демона NFS MOUNT, инициирующей соединение с сервером NFS, также требуется отправка запроса к portmapper. Протокол WebNFS «обходит» эту процедуру, используя открытые логические номера файлов — по аналогии с общеизвестными портами. Это позволяет WebNFS не только «договариваться» с межсетевыми экранами, но и существенно уменьшать объем передаваемых туда и обратно данных, необходимых для инициации соединения. Принимая во внимание значительное время ожидания отклика в Интернет, можно надеяться, что сокращение двустороннего обмена данными окажет самое благоприятное воздействие на этот параметр.

WebNFS присущи практически все преимущества NFS расширенной версии 3. Ранее NFS всегда критиковали за низкую производительность процедуры записи, но в версии 3 и WebNFS благодаря внедрению механизма, позволяющего клиенту обнаруживать потерю данных, этот показатель существенно возрос.

WebNFS, CIFS и Web-браузеры

Компании-разработчики планируют реализовать протоколы WebNFS и CIFS в качестве клиентов уровня ОС, а также встраивая их в Web-браузеры. Клиенты уровня ОС позволят организовать доступ к удаленным серверам так же, как если бы они были локальными устройствами. Что же касается WebNFS, то соответствующее клиентское ПО, скорее всего, будут предлагать самые разные поставщики для целого ряда платформ, в том числе PC-NFS фирмы Sun Microsystems, NFS Maestro фирмы Hummingbird Communications и др.

Клиенты уровня ОС для CIFS предполагается встраивать в ОС Windows. CIFS-клиенты для всех прочих ОС весьма немногочисленны, и их, как правило, поставляют небольшие компании типа Thursby Software Systems, чей продукт DAVE является CIFS-клиентом для ОС Macintosh.

Доступ к файлам WebNFS и CIFS можно получить и через Web-браузеры по их URL-адресам. По заявлению компаний Sun и Netscape, поддержка WebNFS будет встроена в следующие версии продуктов Netscape Communicator и HotJava — собственного браузера фирмы Sun. Однако не стоит рассчитывать на то, что в ближайшем будущем Microsoft обеспечит поддержку WebNFS в своем продукте Internet Explorer.

Поддержку последней спецификации CIFS предполагается обеспечить в браузере Internet Explorer. Корпорация Microsoft планирует переработать перечень обрабатываемых им файлов. К примеру, URL для CIFS-файла может иметь следующий вид: file://server.wherever.com/pathname. Возможность реализации CIFS в браузере Netscape представляется сомнительной, ведь URL вида file:// при работе Netscape в среде Windows будет интерпретирован как ссылка на локальный файл. Впрочем, CIFS-клиенты уровня ОС, вероятно, смогут справиться с этой проблемой.

Другими расширениями, заимствованными WebNFS из NFS версии 3, являются поддержка операций чтения/записи блоков размером более 8 Кбайт в рамках одной NFS-транзакции и принятие 64-битовых полей (таких, как file offset — смещение файла), что позволяет WebNFS поддерживать передачу файлов размером несколько терабайтов.

CIFS = SMB + «кое-что сверху»

Как уже говорилось выше, в качестве своего варианта файловой системы для Интернет корпорация Microsoft предлагает протокол CIFS. Если компания Sun создала WebNFS, расширив уже имеющуюся у нее технологию, то Microsoft, чтобы произвести на свет CIFS, тоже доработала свой протокол SMB (Server Message Block). Последний является протоколом для коллективного использования файлов в сетевой среде Windows, и на его языке «объясняются» и Windows NT, и Windows 95, и Windows for Workgroups, и LAN Manager.

Благодаря такой преемственности CIFS избежал переделок, которые пришлось претерпеть WebNFS. Ведь SMB уже работает на общеизвестных постоянных TCP/IP- портах, поэтому межсетевые экраны для него не проблема. Кроме того, двусторонний обмен данными в SMB сведен к минимуму благодаря использованию механизма AndX, позволяющего клиентам SMB и CIFS выполнять множество запросов протокольного уровня в пакетном режиме.

Однако SMB в отличие от возникшего и развивавшегося в среде TCP/IP протокола NFS появился на свет в начале 80-х годов как протокол для небольших рабочих групп ПК и использовался в качестве транспортной среды NetBIOS/NetBEUI. Естественно, была разработана (и под сокращенным названием NBT описана в RFC 1001 и 1002) спецификация для работы NetBIOS поверх TCP/IP, однако при установлении сетевых соединений для перевода имени хост-машины в IP-адрес SMB все так же «полагается» на службу именования NetBIOS.

При поиске имени NetBIOS использует службу WINS (Windows Internet Name Service) корпорации Microsoft и файл LMHOSTS, но в Интернет перевод имени хоста в IP-адрес и обратно выполняется серверами DNS (Domain Name System). Поэтому Microsoft пришлось доработать свой протокол таким образом, чтобы клиенты CIFS могли осуществлять поиск имени хоста непосредственно через службу DNS. Все предыдущие версии протокола SMB корпорации Microsoft, не считая нынешней спецификации CIFS, так и не удалось полностью интегрировать с DNS.

Microsoft также добавила в протокол CIFS поддержку своей распределенной файловой системы (Distributed File System — DFS). Поддержка Microsoft DFS позволяет CIFS обрабатывать логические имена томов. Например, сетевым томом совместно могут пользоваться множество рабочих групп и серверов, причем доступ к нему осуществляется через один общий подкаталог.

DFS позволяет перемещать тома между серверами, не меняя маршруты (paths) или сетевые URL. В WebNFS аналогичные функции выполняет NFS Automounter, но его смогут предоставить далеко не все поставщики NFS-продуктов; кроме того, в управлении он сложнее, чем DFS.

Помимо приведенных выше небольших дополнений к протоколу CIFS, последний в значительной степени представляет собой описание процесса реализации протоколом SMB совместного использования файлов в Windows 95 и Windows NT. Microsoft имеет далеко идущие планы в отношении CIFS. Так, в ОС Windows NT 5.0 корпорация намерена реализовать функционирование CIFS непосредственно через TCP/IP без всяких там NetBIOS. Причем вместо схемы именования, используемой службой NetBIOS (broadcasts, WINS, LMHOSTS), в CIFS Windows NT 5.0 будет применяться протокол LDAP.

WebNFS против CIFS

Как определить, какой из протоколов лучше подходит для вашей сети? На этот вопрос поможет ответить сравнение их самых важных показателей.

Эффективность и пропускная способность. Использование сервера-посредника и кэширование файлов на диске пользователя — вот два основных механизма, применяемые HTTP для повышения эффективности соединений с низкой пропускной способностью. Но протоколы WebNFS и CIFS не поддерживают сервер-посредник так хорошо, как это делает HTTP. Более того, на данный момент CIFS даже не выполняет кэширования на жесткий диск пользователя. Впрочем, большинство реализаций NFS также не делают это, однако некоторые из них (такие, как NFS-продукты для ПК и ОС Solaris фирмы SunSoft) все же имеют средства CacheFS для кэширования на диск.

Традиционно сложилось так, что большинство NFS-серверов работают в среде Unix, а большинство SMB-серверов — на аппаратной платформе Intel, благодаря чему WebNFS изначально пользуется преимуществами аппаратной масштабируемости. С приобретением (по соответствующей цене) больших Unix-серверов, содержащих более двух дюжин RISC-процессоров проблем нет, а вот купить ПК с восьмью и более процессорами Intel — дело практически невозможное. Уже длительное время NFS является открытой спецификацией, что стало причиной возникновения сильной конкуренции между различными производителями NFS-серверов и, таким образом, гарантировало их высокую эффективность.

Основные «игроки» на этом поле не только Sun, но и такие гиганты серверной индустрии, как Auspex Systems, Falcon Systems и Network Appliance. Со своей стороны Microsoft, сделав спецификацию своего CIFS открытой, сможет быстро сократить «дистанцию», отделяющую ее от них. Корпорации SCO (Santa Cruz Operation) и Network Appliance — да и не только они! — уже приступили к поставкам коммерческих CIFS-серверов.

Аутентификация пользователя. Если ваша цель — создание открытой общедоступной сети с томами только для чтения, т. е. нечто вроде современного варианта анонимного FTP-узла, то можно не беспокоиться об обеспечении безопасности. Но если необходимо предоставление доступа через Интернет к корпоративным файлам, причем не только для чтения, но и для записи, то вы, без сомнения, захотите тщательно проработать вопросы обеспечения безопасности в протоколах WebNFS и CIFS. Увы, это невозможно. С помощью WebNFS и CIFS администратор всего лишь решает, кому и куда именно предоставлять доступ на чтение и запись, но ведь, помимо этого, контроль за входящими «визитерами» требует их аутентификации.

Передача Web-страниц

Сторонники WebNFS и CIFS горячо заверяют нас, что скорость «путешествий» по Web намного увеличится после замены гиперссылок http:// и ftp:// на nfs:// (для WebNFS) и file:// (для CIFS), но верится в это с трудом. К тому же стоит принять во внимание сообщения для печати, сравнительные характеристики и прочие официальные материалы компаний, в которых эффективность WebNFS и CIFS, как правило, сравнивается с эффективностью HTTP версии 1.0, и не более.

Для загрузки каждого элемента Web-страницы (в том числе и самых маленьких файлов изображений) HTTP 1.0 открывает новое TCP-соединение. Из-за такой расточительности эффективность HTTP 1.0 никак нельзя назвать оптимальной, не говоря уже о невысокой скорости TCP и о том факте, что алгоритмы контроля сетевых перегрузок были разработаны для более «длинных» потоков данных. Во многих фирменных реализациях HTTP версии 1.0, в том числе и в Navigator 3.x корпорации Netscape и Internet Explorer 3.x корпорации Microsoft, содержится механизм Keepalive, резко увеличивающий их эффективность благодаря сохранению TCP-соединений открытыми для многократных загрузок. В спецификации следующей версии HTTP 1.1 предложены еще более радикальные усовершенствования, в частности позволяющие передавать только часть файла, задавая ее объем в байтах.

Таким образом, если сравнить временные показатели при загрузке Web-страниц посредством протоколов WebNFS, CIFS и HTTP 1.1, то результаты окажутся более чем скромными. Кроме того, при загрузке файлов Web-браузеры выполняют кэширование на локальный диск. Но при этом еще неизвестно, будут ли первые версии браузеров, поддерживающих WebNFS и CIFS, «вести себя» так же.

И хотя HTTP не хватает многих элементарных функций файловой системы, он достаточно хорошо проработан и является вполне «приличным» гипермедийным протоколом передачи данных. Он поддерживает CGI-интерфейс, серверы-посредники, сценарии, а также различные методы сжатия и шифрования данных при весьма приемлемом соотношении цена/производительность. Большинство Web-ссылок, скорее всего, будут обрабатываться посредством HTTP, и лишь некоторые из них — с помощью WebNFS или CIFS. При этом нужно иметь в виду, что Web-браузеры для всех существующих платформ всегда будут поддерживать последнюю версию HTTP и только некоторая их часть сможет работать с WebNFS и CIFS.

Маловероятно, чтобы эти два протокола стали популярными среди разработчиков Web-узлов, за исключением тех случаев, когда, например, требуется поддержка блокировки файлов при совместных работах. Соответственно и «битва» между различными файловыми системами для Интернет будет вестись на уровне ОС, а в отношении передачи Web-страниц можно по-прежнему говорить о сохранении господства за протоколом HTTP.

Вероятно, задача аутентификации пользователя слишком сложна для системы WebNFS, которая, как и NFS, «отказывается» проводить эту процедуру. В большинстве случаев этим занимаются протоколы pcnfsd, NIS, NIS+ или же находится какой-нибудь другой способ аутентификации. Протокол NFS не поддерживает пароли, а только позволяет контролировать, с каким именно хостом (исходя из его IP-адреса) «общается» ваш сервер. Как раз отсутствие механизма аутентификации и породило такую популярную и широко распространенную в NFS практику экспортировать тома только на доверенные хосты.

Допустим, вам повезло: вы имеете в Интернет постоянный IP-адрес и никто не нападает на вас, используя IP-спуфинг (имитацию соединения). Выведение механизма аутентификации за пределы протокола WebNFS совсем неплохая «конструкторская» мысль, но, вероятно, в этом случае для решения проблемы безопасности придется использовать какое-нибудь широко распространенное универсальное средство типа Secure Sockets Layer (SSL), IP Security (IPsec) или Kerberos. Sun намерена устранить проблему в этом году, внедрив в собственные реализации NFS аутентификацию по методу Kerberos.

Со своей стороны CIFS имеет мощный и широко реализованный интегрированный механизм аутентификации. К сожалению, его разработчикам, чтобы обеспечить обратную совместимость, пришлось в какой-то мере пожертвовать безопасностью. CIFS осуществляет аутентификацию с помощью довольно сложного механизма «запрос—ответ», требующего пересылки по сети только зашифрованных паролей. При этом более ранние реализации SMB не справляются с таким сложным механизмом. И если одна из сторон — сервер или клиент — сообщит другой, что не понимает этого механизма, CIFS отменит все дополнительные уровни защиты, реализованные в нем, и «прикажет» клиенту послать, а серверу принять открытый незашифрованный текст, не обременяя себя никакими паролями. Такое «поведение» CIFS делает его защитный механизм весьма уязвимым. Служба именования NetBIOS и функция Network Neighborhood также дают основания для беспокойства, ибо злоумышленник может «уговорить» их выдать нужную ему информацию.

Справедливости ради спешим сообщить следующее: Microsoft выпустила несколько «заплат» к системе безопасности, предназначенных для нейтрализации некоторых видов нападений. Кроме того, в последней переработанной спецификации CIFS была «заштопана» часть прорех, оставленных для обеспечения обратной совместимости (что же касается «заплат» к уже существующим реализациям, то на момент выхода этой статьи их было выпущено совсем немного). Однако, несмотря на все усовершенствования, за какие-то 10 мин нашего «плавания по волнам» Интернет мы обнаружили весьма популярный среди хакеров Web-узел, на котором хранится весьма толково написанный 34-страничный документ, подробно излагающий процесс проведения успешной атаки на CIFS. Поэтому в настоящее время для экспорта томов частной информации посредством Интернет вместе с WebNFS или CIFS вам следует воспользоваться еще и виртуальной частной сетью (Virtual Private Network — VPN) или же какой-либо другой системой шифрования.

Сохранять или не сохранять сеансы? В серверах WebNFS не сохраняется информация о текущем состоянии пользовательского сеанса, это осуществляет здесь (и в NFS) клиентская программа. Такой подход, утверждают его сторонники, обеспечивает высокую отказоустойчивость и упрощает преодоление сбоев на сервере. В случае его перезагрузки клиентская программа после некоторой паузы продолжит свою работу. На серверах CIFS, напротив, текущая информация сохраняется. После сбоя для клиентской программы восстанавливается последнее сохраненное сервером состояние, зависящее от статуса клиентского соединения, что может привести к потере некоторых данных или состояний и не позволит клиентам нормально продолжить свою работу.

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

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

Несмотря на снижение фирмой Sun цены на PC-NFS до 79 долл. за одно клиентское место (а оптовые скидки делают ее еще ниже), у администраторов систем с Windows-клиентами, пекущихся об экономии бюджета своей организации, имеется по крайней мере 79 причин (умноженных на число клиентов), чтобы предпочесть CIFS.

Разумеется, для организаций с большим числом машин, ОС которых отлична от Windows, CIFS представляет значительно меньший интерес. Ведь рынок предлагает очень немного CIFS-клиентов для таких систем. Впрочем, распространяемый повсеместно корпорацией Microsoft список поставщиков, поддерживающих CIFS, весьма внушителен. Значит, CIFS — это прямой кандидат на то, чтобы де-факто стать файловой системой грядущего стандарта для сетевого ПК (Network PC), создаваемого тандемом Intel—Microsoft.

Соответственно и WebNFS тоже является весьма вероятным кандидатом на роль стандарта для сетевого компьютера (Network Computer — NC), как видят его Oracle и Sun. Причем на рынке Web-браузеров у Sun имеется очень сильный союзник — корпорация Netscape Communications, также внесшая свой вклад в разработку WebNFS. Впрочем, хотя Sun и может похвастаться огромным списком поставщиков продуктов для самых разных платформ, поддерживающих NFS, все же большинство их предлагают лишь NFS версии 2. Относительно поддержки поставщиками NFS версии 3 успехи у Sun оказались куда скромнее — более того, ей не удалось добиться того, чтобы они приняли некоторые периферийные технологии NFS, например такие, как CacheFS. Остается подождать, а потом подсчитать, сколько NFS-совместимых продуктов для Web появится на рынке за год. И здесь одним из главных козырей Sun станет ее контроль над языком Java. Когда придет время стандартизации Java-класса для сетевой файловой системы, можно поручиться за то, что таким стандартом будет WebNFS.





  
2 '1998
СОДЕРЖАНИЕ

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

• Не думай о минутах свысока

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

• Проблемы множественной адресации серверов Windows NT

• ВЛВС: стандарты p и Q на подходе

• Невыдуманные истории

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

• Системы ERP: основные задачи и область применения

• Сетевые тестеры и анализаторы протоколов

• Беспроводные мосты на 10 Мбит/с

• Системы видеоконференц-связи стандарта H.323

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

• Телефакс, приносящий прибыль

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

• Магистральные коммутаторы ATM для распределенных корпоративных сетей

• Средства связи подключения к ISDN

• О телефонистах замолвите слово...

• Адаптеры ISDN

• "Камень" решили сдвинуть "сверху"

• Аббревиатуры, применяемые при измерениях в ИКМ-системах

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

• Звуки Интернет

• "Петербургское оптическое волокно"

• Файловая система для Интернет: WebNFS или CIFS

• Кэширование Web-трафика с помощью серверов-посредников

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

• Как защитить сеть от "взлома"?

• Современные технологии сетевого резервного копирования

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

• FastStor: широкие возможности применения, Новый коммутатор Catalyst, Маленькие радости от MiLAN Technology

бизнес

• От РИФа к РИФу

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

• Измерения в системном администрировании

• Архитектура клиент–сервер или Web: выбор разработчика



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