Чего мы ждем от Internet?

С начала публикации материалов о технологиях Internet и информационных ресурсах этой глобальной сети прошло чуть больше двух лет. За это время Internet-сообщество России существенно изменилось. Как грибы после дождя появляются новые Web-серверы в городах и весях, бурно растет число абонентов Dial-IP, многие организации намерены строить intranet, а некоторые, самые смелые, уже приступили к такому строительству. Все это не может не радовать, но некоторые моменты Всероссийского Internet/intranet-строительства настораживают.

Если уподобить создание информационной среды строительству здания, то окажется, что многие важные этапы технологического цикла пройдены очень быстро или вообще не были выполнены. О возможных последствиях такой ситуации и пойдет речь в этой статье.

Современное состояние Internet-технологий - это результат напряженной работы всего сообщества пользователей сетей TCP/IP за четвертьвековую историю этих сетей. Большинство отечественных пользователей Internet и разработчиков немногочисленных программных продуктов для Internet подключились к Сети и стали осваивать ее технологии в течение последних пяти лет ее существования. Этот период ознаменован существенными изменениями, которые в основном связаны с появлением графических мультипротокольных интерфейсов доступа к информационным ресурсам сети и внедрением распределенной гипертекстовой системы WWW.

С точки зрения конечного потребителя, Internet из инструмента профессионалов превратился в товар широкого потребления. При этом, однако, технология World Wide Web - это не только простое средство поиска информации в Сети, но и простой способ опубликования информации в сети.

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

Фактически был реализован тезис о четырех основных группах субъектов, так или иначе имеющих отношение к работе с гипертекстовыми системами: авторы гипертекстовых статей, администраторы гипертекстовых баз данных, разработчики программного обеспечения и пользователи. С пользователями и программистами все ясно. Графические интерфейсы сделали работу пользователя приятной и привнесли в нее удобство и простоту освоения. К программистам предъявляются стандартные требования, которые предполагают глубокое знание предмета, т. е. технологий межсетевого обмена в рамках TCP/IP. Гораздо интереснее обстоят дела с авторами и администраторами Web-узлов. В отечественной практике это обычно одни и те же люди. До тех пор пока Web была уделом профессионалов, в таком совмещении не было ничего плохого, но по мере роста популярности Web все чаще администрированием Web-узлов стали заниматься люди, которые недостаточно знакомы с технологиями обмена данными в сетях TCP/IP. При этом у них не хватает времени прочитать тысячи RFC, которые регламентируют этот обмен.

Освоение технологии идет главным образом эмпирическим путем. В результате знания и опыт носят фрагментарный характер. Наши учебные заведения не готовят специалистов по технологиям сетей TCP/IP. Каждый грамотный сетевик - это профессионализм, приобретенный в результате многолетней самостоятельной работы. Поэтому по-настоящему хорошие специалисты - явление очень редкое.

Что должен знать и уметь администратор Web-узла?

В первую очередь администратор Web-узла должен быть знаком с основами межсетевого обмена в рамках TCP/IP. Это прежде всего знание отображения стека протоколов TCP/IP на семиуровневую модель OSI, особенности IP-адресации, маршрутизации и транспорта в сети Internet. Примеров, подтверждающих необходимость этих знаний, не счесть. Приведем только некоторые из них.

Первое, что лежит на поверхности, - это создание виртуальных Web-серверов. Такие серверы бывают двух типов: software virtual server и hardware virtual server. Software virtual server мы рассмотрим чуть позже, а пока займемся вторым случаем. Этот тип виртуального сервера предполагает, что одна и та же программа, реализующая функции сервера протокола HTTP, откликается на обращения, которые приходят на разные IP-адреса и разные доменные имена. При этом еще могут быть задействованы и разные порты TCP, в том числе и отличные от стандартного 80 порта.

Для того чтобы реализовать такой сервер, его администратор должен уметь настраивать сетевые интерфейсы для работы с несколькими IP-адресами и знать особенности такой настройки. Так, например, в HP-UX нельзя назначать на один интерфейс IP-адреса из разных подсетей, тогда как в других системах это делать можно. Работа с интерфейсами требует от администратора Web-узла наличия прав суперпользователя, а это в свою очередь накладывает на него дополнительные обязательства.

Другой пример связан с особенностями настройки серверов для работы по протоколу HTTP. Это режим keep-alive. Данная настройка связана с неэффективностью протокола HTTP с точки зрения транспорта TCP. За примерами далеко ходить не надо. Стоит в хорошо нагруженной сети запустить FTP, как сразу все пользователи это почувствуют. Дело в том, что протокол HTTP несеансовый. Соединение устанавливается только на время получения текущей страницы, а после этого рвется. Протокол FTP, напротив, сеансовый, и соединение устанавливается на все время работы клиента и сервера. Так вот, транспорт TCP был разработан в расчете на сеансовые соединения. В этом случае издержки, связанные с транспортом TCP, оправданы. В HTTP они чересчур велики. Но сделать сеансовый протокол для Web тоже нельзя. Достаточно обратиться к тому же FTP, чтобы понять это. Как часто вам отказывали в доступе к FTP-архиву из-за того, что число пользователей вашего класса превышено. Это означает, что превышен лимит сессий FTP для данного сервера, который определяется числом виртуальных терминалов.

В проекте Hyper-G делаются попытки обойти эти ограничения за счет учета времени соединения и квотирования доступа к ресурсам, но пока это только эксперименты. В новых версиях HTTP решили ввести ограниченную по времени сессию, чтобы повысить эффективность обмена. Теперь в рамках одного TCP-соединения можно передать сразу несколько файлов, например текст и всю графику, которые есть на странице. Именно этими параметрами и управляет keep-alive. Но чтобы его настроить, необходимо анализировать статистику доступа и определить, что же будет действительно приемлемо для данного сервера. Большое число коротких соединений или продолжительные одновременно установленные соединения. Все будет зависеть не только от эффективности сети, но и от аппарата, на котором сервер установлен.

И наконец, знания основ технологий TCP/IP совершенно необходимы при размещении proxy-серверов. Задача proxy - работа в качестве посредника между клиентами и другими серверами сети. Устанавливают proxy либо в защищенных сетях, либо для изменения баланса внешнего и внутреннего трафика организации.

В случае защиты proxy принимает запросы от внутренних клиентов по одному порту TCP, а транслирует их в сеть уже по другому. При этом еще в системе, как правило, существует межсетевой экран, который экранирует внутреннего пользователя от внешней сети, а свою сеть от Internet. Запрет прохождения запросов по стандартным портам - порты WKS (Well Known Services) - заставляет пользователя прибегнуть к услугам proxy. Естественно, в этом случае необходима синхронизация в работе системного администратора и администратора Web-узла, которая в простейшем случае реализуется путем назначения одного и того же человека на обе должности.

Перераспределение трафика между внутренней сетью и внешним миром при использовании proxy заключается в применении кэширующего proxy. В этом случае эксплуатируется правило 80/20, т. е. 80% пользователей обращаются только к 20% информации. Если позволяют ресурсы вычислительной установки, то эту информацию можно коллекционировать на своем сервере. Теперь запросы перестанут отправляться в Internet, а будут удовлетворяться в рамках локальной сети. Пропускная способность локальных сетей обычно выше пропускной способности канала подключения локальной сети к Internet. Кэширование информации приводит к тому, что обмен данными на внешнем канале должен уменьшаться. Однако при принятии решения о кэширующем proxy следует отдавать себе отчет в том, что поначалу реактивность системы ухудшится. Proxy сначала перекачивает данные к себе, а только потом отдаст их клиенту. В худшем случае время доступа к ресурсу удвоится. Но кэш кроме сокращения внешнего трафика обеспечивает возможность контроля за информационным потоком, который выходит из организации, что тоже немаловажно.

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

Кроме собственно TCP/IP-обмена администратор должен знать и смежные сервисы, такие, например, как DNS. DNS используется и при организации виртуальных доменов, и при разрешении обратных запросов, когда сервер по IP-адресу определяет доменное имя машины-клиента. Кроме того, как раз доменное имя сервера чаще всего используется в URL (Universal Resource Locator). DNS способен преподнести массу сюрпризов. Например, если за вашей машиной когда-то был закреплен IP-адрес, который в данный момент не используется, в один прекрасный момент он может всплыть на каком-нибудь из многочисленных серверов сети. Если это произойдет, то Web-узел станет "мигающим", что, естественно, не желательно. Это эффект необходимо выявить и начать поиски сервера DNS, с которого приходит этот "мертвый" адрес.

Software virtual server, о котором уже было упомянуто, требует настроек своего сервера DNS, чтобы можно было использовать разные доменные имена для одной и той же машины. Особо стоит подчеркнуть необходимость регистрации таких имен. Ведь если вы назначаете имя машины из домена второго уровня (например www.microsoft.com), то домен надо регистрировать по всем правилам.

Но наиболее актуальны, конечно, комплексные проблемы, связанные с созданием и размещением Web-узла у различных провайдеров. В этом случае часть прав по администрированию ложится на провайдера, а если быть точным, то все, что было перечислено выше. Но это не означает, что в области TCP/IP нет проблем и можно сэкономить на специалистах.

Считается особым шиком открыть свой домен в домене com. В этом решении есть свои подводные камни, которые связаны с особенностями маршрутизации в сетях TCP/IP. Дело в том, что Internet - это фактически двухуровневая сеть. Она состоит из так называемых автономных систем, которые, в свою очередь, состоят из сетей. Когда сосредотачиваются на IP-адресах и настройках отдельных машин, то, как правило, имеют дело с настройкой маршрутизации в пределах сети, т. е. внутри автономной системы. Но для того, чтобы попасть в Австралию, необходимо выйти за пределы своей автономной системы, т. е. воспользоваться услугами внешней маршрутизации. Так вот, при регистрации в домене com запросто можно оказаться внутри автономной системы, которая зарегистрирована за тридевять земель, благо средства связи позволяют работать через моря и океаны. Неприятность здесь только одна - пакеты будут дважды пересекать океан. Время доступа к такому серверу окажется даже больше, чем время доступа к американским информационным ресурсам. Если ваш бизнес ориентирован на иностранцев, то в этом есть определенные преимущества, но если основные ваши клиенты находятся на другой стороне улицы, то решение о размещении такого сервера было бы неверным.

Для того чтобы отследить эти казусы, достаточно воспользоваться программой ping или traceroute, где в первом приближении трассируется путь движения пакетов.

Не только TCP/IP

Однако для того, чтобы ввязаться в игру под названием World Wide Web, нужно знать не только основы межсетевого обмена. Для администратора Web-узла необходимо еще и хорошее знание операционной среды, в которой функционирует сервер.

В современных Web-узлах фактически лишь малая толика информации представляет собой статический гипертекст, состоящий из HTML-документов. Большинство страниц Web-узла - это виртуальные страницы, которые генерируются сервером перед отправкой клиенту. Даже счетчик числа обращений и тот является программой, результаты обращения к которой вставляются внутрь заготовки HTML-страницы. Наиболее известными примерами применения навыков программирования являются server-site imagemap и кириллизация.

Server-site позволяет администратору выбирать между API-модулем своего сервера или CGI-скриптом. В обоих случаях придется компилировать программу. Только в первом - это будет сам сервер, а во втором - внешняя программа.

Если говорить о кириллизации, то времена, когда приходилось вести копии деревьев для различных кодировок, давно канули в Лету. После написания Крюковым модуля для сервера Apache достаточно иметь только одну основную кодировку, из которой сервер на лету производит документы нужной кодировки, опираясь на информацию о типе клиента, адресе ресурса, номере IP-порта или на IP-адрес. Большинство наших провайдеров используют именно этот метод.

Однако если вы захотите подключить через этот сервер универсальную СУБД, то у вас могут возникнуть проблемы. При разработке модулей для доступа к базам данных их авторы максимально стремятся повысить производительность такого обмена и часто используют методы нижнего уровня для передачи данных между СУБД и сервером. В этом случае модуль кириллизации может оказаться не у дел, т. е. данные в одну сторону (от клиента к серверу) будут перекодироваться, а в обратную сторону уходить без перекодировки. Такая картина наблюдается, например, при работе с модулем взаимодействия с СУБД Postgres95. Необходимо править исходный текст этого модуля, чтобы сохранить перекодировку на лету.

Отдельной проблемой в World Wide Web является разграничение доступа к информационным ресурсам. Бесплатная реклама должна соседствовать с подпиской, а это означает, что администратор должен быть знаком с принципами разграничения доступа на его вычислительной установке и с возможностями своего сервера по этой части.

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

За границами TCP/IP

Но если и не затрагивать динамическое создание гипертекстовых страниц, даже при статическом гипертексте администратор, а точнее автор Web-узла, должен быть знаком с основами программирования. В Сети все больше и больше Web-узлов, на которых применяются языки управления сценариями просмотра. Это предполагает знакомство автора с принципами объектно-ориентированного программирования. Еще больше требований к администраторам и авторам предъявляет технология Java.

Как видно из этой статьи, технология World Wide Web, постепенно разрастаясь, увеличивает свои требования к персоналу, вынуждая его вводить разделение обязанностей в группах администрирования Web-узлов, и это при том, что стандартов на World Wide Web фактически еще нет.