информация

Беспроводные веб-технологии — это, конечно, замечательное изобретение по­следних лет, однако далеко не единственное. Для многих не что иное, как мульти­медиа, служит чашей святого Грааля сетевых технологий. Слово «мультимедиа» возбуждает и физиков, и лириков, и разработчиков, и коммерсантов. Одни видят в мультимедиа бесконечный источник интересных технических проблем, связанных, например, с доставкой (интерактивного) видео по заказу, другие — не меньший источник прибыли. Поскольку для передачи мультимедийных данных требуется очень высокая пропускная способность, довольно трудно заставить систему рабо­тать даже поверх стационарных соединений. Что касается беспроводных техно­логий, то добиться даже VHS-качества пока что не удается, и на решение этой проблемы потребуется, как минимум, несколько лет. Мы будем рассматривать далее методы передачи мультимедийных данных по проводным сетям.

Буквально мультимедиа означает использование двух или более средств аудио­визуальной информации. Если бы издатель этой книги захотел присоединиться к всеобщей моде пускания пыли в глаза, он мог бы разрекламировать ее как ис­пользующую мультимедийные технологии. В конце концов, в ней действительно используются два средства информации: текст и графика (рисунки). Тем не ме­нее, когда употребляется это слово, обычно имеются в виду некие информаци­онные сущности, длящиеся во времени, то есть проигрываемые в течение опре­деленного интервала времени, обычно во взаимодействии с пользователем. На практике чаще всего это аудио и видео, то есть звук плюс движущееся изобра­жение.

Несмотря на такое довольно понятное определение, многие, говоря «мульти­медиа», имеют в виду только чисто звуковую информацию, например интернет- телефонию или интернет-радио. Строго говоря, они не правы. Более удачным термином в данном случае является словосочетание потоковая информация (strea­ming media), однако мы, поддавшись стадному инстинкту, все же будем имено­вать аудиоданные, передающиеся в реальном масштабе времени, «мультимедиа». В следующих разделах мы узнаем, как компьютер обрабатывает звук и видео и как он сжимает такого рода данные. Затем мы рассмотрим некоторые сетевые технологии, связанные с мультимедиа. Довольно понятно и в хорошем объе­ме (три тома) взаимодействие сетевых и мультимедийных технологий описано в (Steinmetz и Nahrstedt, 2002; Steinmetz и Nahrstedt, 2003а; Steinmetz и Nahr- stedt, 2003b),

Методы, рассмотренные нами ранее, направлены на уменьшение перегрузок и по­вышение производительности в сетях передачи данных.

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

Большинство алгоритмов маршрутизации пытаются искать наилучшие пути для каждого адресата и направлять весь трафик по оптимальному пути.

Альтернатив­ный подход, позволяющий повысить качество обслуживания, состоит в разделе­нии трафика для одного и того же адресата между несколькими маршрутами. По­скольку маршрутизаторы обычно не следят за нагрузкой на всю сеть в целом, остается лишь один способ разделения трафика — на основе доступной локаль­ной информации. Одним из простых методов является маршрутизация, пропор­циональная или эквивалентная емкостям исходящих связей. Однако существуют и более сложные алгоритмы (Nelakuditi и Zhang, 2002).

Маршрутизация на основе векторов расстояний использовалась в сети ARPANET вплоть до 1979 года, когда ее сменил алгоритм маршрутизации с учетом состоя­ния линий. Отказаться от прежнего алгоритма пришлось по двум причинам. Во- первых, старый алгоритм при выборе пути не учитывал пропускную способность линий. Пока все линии имели пропускную способность 56 Кбит/с, в учете пропу­скной способности не было необходимости. Однако стали появляться линии со скоростью 230 Кбит/с, а затем и 1,544 Мбит/с, и не принимать во внимание про­пускную способность стало невозможно. Конечно, можно было ввести пропуск­ную способность в качестве множителя для единицы измерения, но имелась еще и другая проблема, заключавшаяся в том, что алгоритм слишком долго приходил к устойчивому состоянию (проблема счета до бесконечности). Поэтому он был заменен полностью новым алгоритмом, который сейчас называется маршрутиза­цией с учетом состояния линий. Варианты этого алгоритма широко применяют­ся в наши дни.

В основе алгоритма лежит простая идея, ее можно изложить в пяти требова­ниях к маршрутизатору. Каждый маршрутизатор должен:

1. Обнаруживать своих соседей и узнавать их сетевые адреса.
2. Измерять задержку или стоимость связи с каждым из своих соседей.
3. Создавать пакет, содержащий всю собранную информацию.
4. Посылать этот пакет всем маршрутизаторам.
5. Вычислять кратчайший путь ко всем маршрутизаторам.

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

Главный протокол архитектуры интегрального обслуживания, разработанный IETF, называется протоколом резервирования ресурсов (RSVP — Resource reSerVa- tion Protocol). Он описывается в документе RFC 2205 и других документах-про­токолах. Как следует из названия, протокол предназначен для резервирования ресурсов; другие протоколы применяются для описания передачи данных. RSVP позволяет нескольким отправителям посылать данные нескольким группам або­нентов, разрешает отдельным получателям переключать каналы и оптимизирует использование пропускной способности, в то же время устраняя возникновение перегрузки.

Простейшая форма этого протокола использует многоадресную маршрутиза­цию с применением связующих деревьев, обсуждавшуюся ранее. Каждой группе назначается групповой адрес. Чтобы послать данные группе, отправитель поме­щает ее адрес в заголовки пакетов. Затем стандартный алгоритм многоадресной маршрутизации строит связующее дерево, покрывающее всех членов группы. Алгоритм маршрутизации не является частью протокола RSVP. Единственное отличие от нормальной многоадресной маршрутизации состоит в том, что груп­пе периодически рассылается дополнительная информация, с помощью которой маршрутизаторы обновляют определенные структуры данных.

Для примера рассмотрим сеть, показанную на рис. 5.32, а. Хосты 1 и 2 явля­ются многоадресными передатчиками, а хосты 3, 4 и 5 — многоадресными при­емниками. В данном примере передатчики и приемники разделены, однако в об­щем случае эти два множества могут перекрываться. Деревья многоадресной рассылки для хостов 1 и 2 показаны на рис. 5.32, б и в соответственно.

Для улучшения качества приема и устранения перегрузки каждый получа­тель в группе может послать передатчику (вверх по дереву) запрос на резервирова­ние. Запрос продвигается, используя обсуждавшийся ранее алгоритм обратного, пути. На каждом транзитном участке маршрутизатор замечает запрос и резерви­рует необходимую пропускную способность. Если пропускной способности не­достаточно, он отвечает сообщением об ошибке. К тому моменту как запрос до­ходит до передатчика, пропускная способность зарезервирована вдоль всего пути от отправителя к получателю.

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

Когда два или более маршрутизаторов объединены в локальную сеть, ситуа­ция несколько усложняется. На рис. 5.9, а изображена ЛВС, к которой напря­мую подключены три маршрутизатора — А, С и F. Каждый из них, как показано на рисунке, соединен также с одним или несколькими дополнительными мар­шрутизаторами.

Один из способов моделирования локальной сети состоит в том, что ЛВС рас­сматривается в виде узла графа, как и маршрутизаторы. Это показано на рис. 5.9, б. На рисунке сеть изображена в виде искусственного узла N, с которым соединены маршрутизаторы А, С и F. Возможность передачи пакетов от Л к С по локальной сети отражается здесь наличием пути ANC.

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

Далее, какая организация будет заведовать Управлением? Довольно трудно представить себе какую-либо законную структуру с большим кредитом доверия мирового масштаба. В некоторых странах предпочтительно, чтобы это было ка- кое-нибудь правительственное учреждение, а где-то — наоборот, чтобы это было чем угодно, но не правительством.

По этим причинам был разработан альтернативный способ сертификации открытых ключей. Он известен под общим названием PKI (Public Key Infra­structure — инфраструктура систем с открытыми ключами). В этом разделе мы
рассмотрим только общие принципы действия PKI, поскольку было внесено мно­жество предложений по ее модификации и некоторые детали могут со временем измениться.

ЦУ

РО 2

УС принято. Открытый ключ: 6384AF863B... Подпись РО 2

а                                                                                                            б Рис. 8.22. Иерархия PKI (а); цепочка сертификатов (б) Итак, наш PKI работает следующим образом. Допустим, Алисе нужен откры­тый ключ Боба, чтобы она могла с ним пообщаться. Она ищет и находит содер­жащий его сертификат, подписанный УС 5. Однако Алиса никогда ничего не слышала про УС 5. Этим «Управлением» может оказаться, на самом деле, деся­тилетняя дочка Боба. Алиса может отправиться в УС 5 и попросить подтвердить легитимность. Управление в ответ может показать сертификат, полученный от

PKI состоит из множества компонентов, среди которых Управления сертифи­кации, сами сертификаты, а также каталоги. Инфраструктура систем с открытыми ключами предоставляет возможность структурной организации этих компонен­тов и определяет стандарты, касающиеся различных документов и протоколов. Одним из простейших видов PKI является иерархия Управлений, представлен­ная на рис. 8.22. На рисунке представлены три уровня, однако реально их может быть как больше, так и меньше. Управление сертификации верхнего уровня (root) мы будем называть Центральным управлением (ЦУ). Центральное управление сертифицирует управления второго уровня — назовем их Региональными отде­лами (РО), — так как они могут обслуживать некоторый географический регион, например, страну или континент. Этот термин не стандартизован. Названия для уровней иерархии вообще не оговариваются стандартом. Региональные отделы, в свою очередь, занимаются легализацией реальных Управлений сертификации (УС), эмитирующих сертификаты стандарта Х.509 для физических и юриди­ческих лиц. При легализации Центральным управлением нового Регионального отдела последнему выдается сертификат, подтверждающий его признание. Он содержит открытый ключ нового РО и подпись ЦУ. Аналогичным образом РО взаимодействуют с Управлениями сертификации: выдают и подписывают серти­фикаты, содержащие открытые ключи УС и признающие легальность деятель­ности.

РО 2 принят. Открытый ключ: 47383АЕ349...

Подпись ЦУ

РО 2 и содержащий открытый ключ УС 5. Теперь, вооружившись открытым ключом УС 5, Алиса может удостовериться в том, что сертификат Боба действи­тельно подписан УС 5, а значит, является легальным.

Если только РО 2 не является двенадцатилетним сыном Боба. Если Алисе вдруг придет в голову такая мысль, она может запросить подтверждение леги­тимности РО 2. Ответом будет служить сертификат, подписанный Центральным управлением и содержащий открытый ключ РО 2. Вот теперь Алиса может не сомневаться, что она получила открытый ключ Боба, а не кого-то другого.

А если Алиса хочет узнать открытый ключ ЦУ? Как это сделать? Загадка. Предполагается, что открытый ключ ЦУ знают все. Например, он может быть «зашит» внутрь ее браузера.

Но наш Боб — добряк, он не хочет доставлять Алисе лишние хлопоты. Он по­нимает, что она захочет проверить легитимность УС 5 и РО 2, поэтому он сам собирает соответствующие сертификаты и отправляет их ей вместе со своим. Те­перь, зная открытый ключ ЦУ, Алиса может проверить по цепочке все интере­сующие ее организации. Ей не придется никого беспокоить для подтверждения. Поскольку все сертификаты подписаны, она может запросто уличить любые по­пытки подлога. Цепочка сертификатов, восходящая к ЦУ, иногда называется до­верительной цепочкой или путем сертификата. Описанный метод широко при­меняется на практике.

Конечно, остается проблема определения владельца ЦУ. Следует иметь не од­но Центральное управление, а несколько, причем связать с каждым из них свою иерархию региональных отделов и управлений сертификации. На самом деле, в современные браузеры действительно «зашиваются» открытые ключи более 100 центральных управлений, иногда называемые доверительными якорями. Как видите, можно избежать проблемы одного всемирного учреждения, занимающе­гося сертификацией.

Однако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. Все, на самом деле, сводится к тому, насколько конечный пользователь доверяет разработчику браузера, насколько он уверен в том, что решения генерируются грамотно и доверительные якоря не принимаются от всех желающих за умеренную плату. Большинство браузеров обеспечивают возможность проверки ключей ЦУ (обычно это делается с помо­щью сертификатов, подписанных им) и удаления подозрительных ключей.

Каталоги

Инфраструктура систем с открытыми ключами должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сер­тификаты у себя. Это безопасно (так как невозможно подделать подписанные сертификаты незаметно), но не слишком удобно. В качестве каталога для серти­фикатов было предложено использовать DNS. Прежде чем соединиться с Бобом, Алисе, видимо, все равно придется узнать с помощью службы имен доменов (DNS) его IP-адрес. Так почему бы не заставить DNS возвращать вместе с 1Р-ад- ресом всю цепочку сертификатов?

Кому-то это кажется выходом из положения, однако некоторые считают, что лучше иметь специализированные серверы с каталогами для хранения серти­фикатов Х.509. Такие каталоги могли бы с помощью имен Х.500 обеспечивать возможность поиска. Например, теоретически можно представить себе услугу сер­вера каталогов, позволяющую получать ответы на запросы типа «Дайте мне пол­ный список всех людей по имени Алиса, работающих в отделе продаж в любом месте США или Канады». Хранить такую информацию можно, например, при помощи LDAP.

Аннулирование

Реальный мир полон разного рода сертификатов, среди которых, например, пас­порта, водительские удостоверения. Иногда эти сертификаты необходимо анну­лировать (например, водительское удостоверение надо аннулировать за езду в нетрезвом состоянии). Та же проблема возникает и в мире цифровых технологий: лицо, предоставившее сертификат, может отозвать его за нарушение противопо­ложной стороной каких-либо условий. Это необходимо делать и тогда, когда за­крытый ключ, в сущности, перестал быть защищенным или, что еще хуже, ключ УС потерял кредит доверия. Таким образом, инфраструктура систем с открыты­ми ключами должна как-то обеспечивать процедуру аннулирования.

Первым шагом в этом направлении является принуждение всех УС к перио­дическому выпуску списка аннулированных сертификатов (CRL — Certificate Revocation List). В нем перечисляются порядковые номера всех аннулированных сертификатов. Поскольку в сертификатах содержится дата окончания срока год­ности, в CRL следует включать номера только тех из них, срок годности которых еще не истек. По истечении срока годности сертификаты перестают быть дейст­вительными автоматически, поэтому нужно различать случаи аннулирования «по старости» и по другим причинам. В любом случае их использование необхо­димо запрещать.

К сожалению, возникновение списков аннулированных сертификатов означа­ет, что лицо, собирающееся использовать сертификат, должно вначале убедиться в том, что его нет в этом списке. В противном случае от использования надо от­казаться. Тем не менее, сертификат мог быть аннулирован тотчас же после вы­пуска самого свежего варианта черного списка. Получается, что единственный надежный способ — это узнать о состоянии сертификата непосредственно у УС. Причем эти запросы придется посылать при каждом использовании сертифика­та, так как нет никакой гарантии, что его аннулирование не произошло несколь­ко секунд назад.

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

Где хранить списки аннулированных сертификатов? Было бы здорово хра­нить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что

УС периодически выпускает «черные» списки и заставляет вносить обновления в каталоги (удаляя отозванные сертификаты). Если для хранения сертификатов каталоги не используются, можно кэшировать их в разных удобных местах в се­ти. Поскольку «черный» список сам по себе является подписанным документом, любые попытки подлога тотчас будут замечены.

Если сертификаты имеют большие сроки годности, списки аннулированных сертификатов также будут довольно длинными. Например, количество отозван­ных кредитных карточек со сроком годности 5 лет будет гораздо больше списка отозванных трехмесячных карточек. Стандартным способом борьбы с длинными списками является довольно редкий выпуск самих списков и частый — обновле­ний к ним. Кроме всего прочего, это помогает снизить необходимую для распро­странения списков пропускную способность.

Довольно простым способом повышения производительности является сохране­ние ранее загружавшихся страниц на случай их повторного запроса. Этот метод особенно эффективен при работе с часто посещаемыми страницами (такими как www.yahoo.com или www.cnn.com). Сохранение веб-страниц «про запас» для по­следующего использования называется кэшированием. Обновление кэша являет­ся обычной процедурой для некоторого процесса, называемого сервером-посред­ником, или прокси. Чтобы иметь возможность использовать метод кэширования, браузер должен быть настроен на обращение к посреднику, а не к реальному сер­веру, на котором хранится страница. Если у сервера-посредника есть нужная стра­ница, она сразу же возвращается пользователю. В противном случае ее придется получить с сервера, добавить в кэш для будущего использования и только после этого предоставить пользователю.

С кэшированием связаны два важных вопроса.

1. Кто должен .заниматься кэшированием?

2.    Сколько времени страницы должны храниться в кэше?

А

На первый вопрос есть несколько ответов. На отдельных персональных ком­пьютерах часто имеется прокси, поэтому поиск ранее запрошенных страниц про­исходит быстро. В корпоративной ЛВС прокси-сервер обычно устанавливается на машине с разделяемыми ресурсами, и если один из клиентов данной ЛВС за­просил страницу с сервера, то другой может получить ее уже из кэша сервера-по- средника (прокси). Прокси-серверы часто устанавливают у себя провайдеры с целью повышения скорости доступа для всех своих клиентов. Нередко все эти кэши работают одновременно, поэтому запрос вначале отправляется на локаль­ный прокси-сервер. Если там страница не обнаружена, запрос передается на прок­си-сервер ЛВС. Не найдя у себя запрашиваемую страницу, последний обраща­ется к прокси-серверу провайдера. На этом этапе страница уже должна быть по­лучена в любом случае: либо она берется из кэша, либо приходит с веб-сервера. Схема с несколькими кэшами, работающими последовательно, называется ие­рархическим кэшированием. Возможная реализация этого метода показана на рис. 7.18.

Прокси                                     Интернет Прокси Кэширование" title="Кэширование" border=0 width=361 height=70 src="http://s006.radikal.ru/i213/1007/ef/471b79f5605b.jpg"> Клиентская Клиентская машина                                       ЛВС         провайдера Рис. 7.18. Иерархическое кэширование с тремя серверами-посредниками

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

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

Решается этот философский вопрос с использованием двух подходов. Пер­вый подразумевает эвристический анализ для принятия решения о сроке хране­ния страницы. Обычно он основывается на значении заголовка Last-Modified (см. табл. 7.13). Если страница подвергалась изменениям час назад, она будет храниться в кэше также в течение часа. Если же последние изменения были вне­сены в страницу год назад, очевидно, она содержит довольно стабильную инфор­мацию (например, список греческих и римских богов), и ее можно хранить в кэше в течение года, резонно предполагая, что за это время ничего на ней не изменит­ся. Несмотря на то, что такой эвристический анализ работает весьма успешно, все же время от времени из кэша извлекаются устаревшие страницы.

Другой подход является более дорогим, но и более надежным в смысле ис­ключения возможности хранения в кэше устаревших страниц. Используются осо­бенности RFC 2616, имеющие отношение к управлению кэшем. Одной из самых полезных особенностей является наличие заголовка If-Modified-Since, который сервер-посредник может посылать веб-серверу. В нем указывается страница, со­стояние которой хочет выяснить прокси, а также время внесения последних из­менений (значение заголовка Last-Modified на странице). Если страница не под­вергалась изменениям, сервер отошлет обратно короткое сообщение Not Modified («Изменений нет», код 304, см. табл. 7.12). Это будет означать, что прокси может использовать хранящуюся в кэше страницу. Если же на странице произошли ка­кие-либо изменения, сервер пришлет ее обновленную версию. Такой подход тре­бует обмена запросами и ответами, но если страница еще не устарела, ответ сер­вера будет очень коротким.

Два указанных подхода можно комбинировать. В течение первого интервала времени AT после получения страницы прокси просто извлекает запрошенную страницу из кэша. По прошествии определенного промежутка времени прокси использует If-Modified-Since для проверки состояния страницы. Выбор А Г под­разумевает некоторый эвристический анализ, базирующийся на знании времени последних изменений на странице.

Динамические веб-страницы (например, созданные PHP-скриптом) не должны кэшироваться вообще никогда, так как их содержимое переменное по определе­нию. Для этого, а также для некоторых других специальных случаев предусмотрен механизм, с помощью которого сервер может информировать все серверы-посред- ники на пути к клиенту о том, что не следует использовать текущую страницу без запроса ее актуальности. Этот же механизм может применяться для страниц, которые могут меняться довольно часто. В RFC 2616 определен также ряд дру­гих механизмов управления кэшированием.

Еще один подход к повышению производительности называется упреждаю­щим кэшированием. Получая страницу с веб-сервера, прокси-сервер может про­верить ее на наличие гиперссылок. Если таковые имеются, он может запросить и поместить в кэш страницы, на которые указывают гиперссылки, просто на тот случай, если они понадобятся пользователю. Этот метод может помочь умень­шить время доступа к последующим запросам, однако может привести к загруз­ке линий связи при передаче страниц, которые, возможно, так и не будут запро­шены.

Понятно, что кэширование во Всемирной паутине реализуется далеко не три­виально. Эту тему можно было бы обсуждать еще долго. На самом деле, ей по­священы отдельные книги, например (Rabinovich и Spatscheck, 2002; Wessels, 2001). Однако нам пора двигаться дальше.

Мы несколько раз упоминали о том, что веб-страницы могут быть связаны между собой ссылками. Пора познакомиться с тем, как эти ссылки реализованы. Уже при создании Паутины было очевидно, что для реализации ссылок с одних стра­ниц на другие необходим механизм именования и указания расположения стра­ниц. В частности, прежде чем выводить выбранную страницу на экран, нужно узнать ответы на три следующих вопроса.

1.   Как называется эта страница?

2.    Где она расположена?

3.    Как получить к ней доступ?

Если бы каждой странице можно было присвоить уникальное имя, то в иденти­фикации страниц не было бы никакой неоднозначности. Тем не менее, проблему бы это не решило. Для примера проведем параллель между страницами и людь­ми. В Соединенных Штатах почти у всех граждан есть номер карточки социаль­ного страхования, представляющий собой уникальный идентификатор, так как нет двух людей с одинаковым номером. Тем не менее, зная только номер карточки социального страхования, нет способа узнать адрес владельца и, конечно, нельзя определить, следует ли писать этому гражданину по-английски, по-испански или по-китайски. Во Всемирной паутине проблемы, в принципе, те же самые.

В результате было принято решение идентифицировать страницы способом, решающим сразу все три проблемы. Каждой странице назначается унифициро­ванный указатель информационного ресурса (URL, Uniform Resource Locator), который служит уникальным именем страницы. URL состоят из трех частей: про­токола (также называемого схемой), DNS-имени машины, на которой располо­жена страница, и локального имени, единственным образом идентифицирующе­го страницу в пределах этой машины (обычно это просто имя файла). Например, веб-сайт факультета, на котором работает автор, содержит несколько видеофраг­ментов об университете и городе Амстердаме. Унифицированный указатель страницы с видео выглядит следующим образом: http://www.cs.vu.nl/video/index-en.html

Этот URL состоит из трех частей: протокола (http), DNS-имени хоста (www.cs.vu.nl) и имени файла (video/index-en.html). Отдельные части URL-указа­теля разделяются специальными знаками пунктуации. Имя файла представляет собой относительный путь по отношению к веб-катологу cs.vu.vu.nl.

У сайтов могут быть сокращенные имена для ускоренного доступа к опреде­ленным файлам. Скажем, при отсутствии в URL имени файла может выводиться главная (домашняя) страница сайта. Если имя файла заканчивается именем ка­талога, то из него по умолчанию выбирается файл с именем index.html. Наконец, имя -user/ может соответствовать WWW-каталогу пользователя, причем может быть также задано имя файла по умолчанию, например, index.html. Так, на до­машнюю страницу автора можно попасть по адресу

http://www.cs.vu.nl/~ast/ несмотря на то, что действительное имя файла (index.html) отличается от указан­ного.

Теперь надо понять, как работает гипертекст. Чтобы на неком участке текста браузер мог реагировать на щелчок мыши, при написании веб-страницы нужно обозначить два элемента: отображаемый на экране текст ссылки и URL страни­цы, которая должна стать текущей при щелчке мышью. Синтаксис такой коман­ды будет пояснен далее в этой главе.

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

Такая схема является открытой в том смысле, что она позволяет использо­вать разные протоколы для доставки информационных единиц разного типа. Определены URL-указатели для других распространенных протоколов, пони­маемые многими браузерами. Слегка упрощенные формы наиболее употреби­тельных URL-указателей приведены в табл. 7.9.

Таблица 7.9. Некоторые распространенные URL-указатели Имя Применение Пример http Гипертекст (HTML) http://www.cs.vu.nl/~ast/ ftp FTP ftp://ftp.cs.vu.nl/pub/minix/README file Локальный файл file:////usr/suzanne/prog.c news Телеконференция news:comp.os.minix news Статья новостей news:AA0134223112@cs.utah.edu gopher Gopher gopher://gopher.tc.umn.edU/11/Libraries mailto Отправка электронной почты mailto:JohnUser@acm.org telnet Удаленный терминал telnet://www.w3.org:80

Кратко рассмотрим этот список. Протокол http является родным языком Все­мирной паутины, на нем разговаривают веб-серверы. HTTP — это сокращение, которое расшифровывается как HyperText Transfer Protocol (протокол передачи гипертекста). Более подробно мы рассмотрим его далее в этой главе.

Протокол ftp используется для доступа к файлам по FTP — протоколу пере­дачи файлов по Интернету. За двадцать лет своего существования он достаточно хорошо укоренился в сети. Многочисленные FTP-серверы по всему миру позво­ляют пользователям в любых концах Интернета регистрироваться на сервере и скачивать разнообразные файлы, размещенные на сервере. Всемирная паутина здесь не вносит особых изменений. Она просто упрощает доступ к FTP-серверам и работу с файлами, ибо само по себе FTP имеет несколько загадочный интер­фейс (однако более мощный, чем HTTP: например, он позволяет пользователю машины А передать файл с машины В на машину С),

К локальному файлу также можно обратиться как к веб-странице, либо ис­пользуя протокол file, либо просто указав имя файла. Такой подход напоминает FTP, но не требует наличия сервера. Разумеется, он работает только с локальны­ми файлами, а не с расположенными на удаленных терминалах.

Задолго до появления Интернета появилась система групп новостей USENET. Она состоит примерно из 30 ООО конференций, в которых миллионы людей обсу­ждают широкий круг вопросов, отправляя и читая сообщения, связанные с тема­тикой данной конференции. Протокол news позволяет пользователю вызывать на экран статью с новостями, как если бы она была обычной веб-страницей. Это означает, что веб-браузер легким движением руки превращается в элегантную программу чтения новостей. На самом деле, благодаря кнопкам и пунктам меню многих браузеров чтение новостей USENET становится даже удобнее, чем с по­мощью специальных программ чтения сетевых новостей.

Для протокола news поддерживается два формата URL-указателей. Первый формат указывает телеконференцию, и с его помощью можно получить список новых статей с указанного заранее сайта новостей. Второй формат позволяет по­лучить конкретную статью по ее идентификатору, например, AA0134223112@cs. utah.edu. Для получения этой статьи с заранее настроенного сайта браузер ис­пользует протокол NNTP (Network News Transfer Protocol — сетевой протокол передачи новостей). Мы изучим NNTP в этой книге, однако надо понимать, что это нечто вроде SMTP, они весьма похожи даже по стилю.

Протокол gopher используется системой Gopher, разработанной в универси­тете штата Миннесота и получившей свое название от университетской спортив­ной команды «Golden Gophers» («Золотые суслики»). (Гоферами называют уро­женцев штатов Миннесота, Арканзас и Флорида. Кроме того, на американском сленге это слово означает «добывать», «копать», «искать».) Система Gopher поя­вилась в Интернете на несколько лет раньше Всемирной паутины. Концепту­ально они похожи: и та, и другая представляют собой схему поиска и получения информации, хранящейся на различных серверах, однако система Gopher под­держивала только тексты и не поддерживала изображений. Сейчас ее можно счи­тать полностью устаревшей, используется она крайне редко.

Последние два протокола не занимаются имитацией получения веб-страниц, но они также полезны. Протокол mailto позволяет пользователю посылать элек­тронную почту из веб-браузера. Например, в некоторых браузерах для этого нужно щелкнуть на кнопке OPEN и ввести URL-указатель, состоящий из слова mailto:, за которым следует почтовый адрес получателя. В ответ в большинстве браузеров откроется специальная форма, содержащая поля для редактирования темы письма и других заголовков, а также окно для ввода текста самого письма.

С помощью протокола telnet можно установить в подключенном режиме со­единение с удаленным компьютером. Он используется так же, как и программа Telnet, что неудивительно, так как большинство браузеров просто вызывают са­му программу Telnet как вспомогательное приложение.

Итак, URL-указатели позволяют пользователям не только путешествовать по Всемирной паутине, но и работать с FTP-серверами, BBS, Gopher-серверами, электронной почтой и регистрироваться на удаленных серверах с помощью про­граммы Telnet. Все эти ресурсы оказываются доступны при помощи всего одной программы — веб-браузера, что очень удобно. Если бы отцом этой идеи не был ученый-физик, она стала бы, вероятно, самой убедительной рекламой какой-ни­будь компании, специализирующейся на выпуске программного обеспечения.

Несмотря на все перечисленные достоинства, все продолжающийся рост по­пулярности Всемирной паутины выявил один врожденный недостаток URL-схе­мы. URL указывает на определенный хост. Часто запрашиваемые по сети стра­ницы было бы лучше дублировать и хранить копии в удаленных концах сети, чтобы снизить сетевой трафик. Беда в том, что URL-указатели не предоставляют возможности для ссылки на страницу без указания ее точного адреса. Нельзя сказать: «Мне нужна страница abc, и мне все равно, где вы ее раздобудете». Для решения задачи репликации страниц проблемная группа проектирования Ин­тернета IETF (Internet Engineering Task Force) работает над системой URN (Uniform Resource Name — универсальное имя ресурса). Универсальное имя ре­сурса URN можно считать обобщенным URL-указателем. В настоящее время этот вопрос находится в стадии исследования, хотя уже предложен синтаксис, опи­санный в RFC 2141.

Конфиденциальность и цензура — это те области, в которых сталкиваются техно­логические аспекты и общественные интересы. Третьей такой областью является защита авторских прав. Авторское право гарантирует свободу распоряжения ин­теллектуальной собственностью ее создателям, которыми могут быть, напри­мер, писатели, художники, композиторы, музыканты, фотографы, кинорежиссе­ры, хореографы и т. д. Авторское право выдается на определенный срок, который обычно равен сроку жизни автора плюс 50 лет (75 лет — в случае корпоративного авторского права). По окончании этого срока интеллектуальная собственность становится достоянием общества, и каждый волен распоряжаться ею, как хочет. Так, например, проект «Gutenberg» (www.promo.net/pg) разместил в Сети тысячи произведений, давно уже ставших общественным достоянием (работы Шекспи­ра, Диккенса, Марка Твена). По просьбе Голливуда в 1998 году Конгресс США разрешил продлить срок действия авторских прав еще на 20 лет, утверждая, что без принятия этой меры больше никто ничего не станет создавать. В то же время, патенты на изобретения действуют в течение всего лишь 20 лет, и никто не жалу­ется — люди продолжают совершать открытия и делать изобретения.

Вопрос о защите авторских прав вышел на первый план, когда у службы Napster, незаконным образом распространявшей музыку, внезапно оказалось 50 миллионов пользователей. Несмотря на то, что записи системой Napster ни­куда не копировались, судом было предъявлено обвинение в хранении централь­ной базы данных с информацией о том, какие у кого из пользователей имеются записи. Таким образом, система побуждала пользователей совершать преступ­ные действия, нарушающие закон об авторских правах. В общем-то, никто не жа­луется на то, что идея авторских прав плоха (хотя многим не нравится то, что компании обладают намного большими привилегиями в этом плане, чем про­стые граждане), однако следующее поколение технологий распространения му­зыкальных записей уже поднимает вопросы этического характера.

Например, рассмотрим равиоранговую сеть, члены которой занимаются впол­не законным обменом файлами (записями, являющимися общественным достоя­нием, домашними видеозаписями, религиозными трактатами (не составляющи­ми коммерческую тайну церквей) и т. д.). Возможно, какая-то небольшая часть этих файлов защищена законом об авторских правах. Допустим, все участники проекта находятся на постоянном соединении (пользуются ADSL или кабель­ным Интернетом). На каждой машине хранится список того, что есть на жестком диске, а также список всех машин сети. В поисках какого-либо файла можно об­ратиться к произвольно выбранной машине и запросить у нее список имеющихся материалов. Если нужная информация не находится, можно попробовать опро­сить все остальные машины из списка, а также машины из списков, хранящихся у других. Компьютеры здесь сильно облегчают задачу поиска некоторых редких материалов. Найдя нужный файл, пользователь просто копирует его себе.

Если найденная работа оказывается защищенной законом об авторских пра­вах, пользователь, сам того не желая, становится нарушителем этого закона (тут еще, конечно же, играет роль то, в какой стране происходит дело и, соответствен­но, какие законы следует применять в каждом конкретном случае). А виноват ли поставщик информации? Является ли преступлением хранение у себя на жест­ком диске записей, за которые были заплачены деньги и которые были вполне легально загружены из Интернета, при условии, что к диску могут иметь доступ посторонние лица? Если в вашу лачугу, никогда не знавшую замков и засовов, проникает вор с ноутбуком и сканером, снимает копию с книги, защищенной за­коном об авторских правах, и уходит восвояси, разве вы виноваты в этом престу­плении, разве вы должны защищать чужие авторские права?

Однако есть еще одна проблема, связанная с авторскими правами. Ведется ожесточенная борьба между Голливудом и компьютерной индустрией. Голливуд требует усилить защиту интеллектуальной собственности, а компьютерщики го­ворят, что они не обязаны сторожить голливудские ценности. В октябре 1998 года Конгресс принял Акт об авторских правах в цифровых технологиях (DCMA — Digital Millenium Copyright Act), в котором говорится о том, что взлом меха­низма защиты, присутствующего в работе, защищенной законом об авторских правах, а также сообщение другим технологии взлома является преступлением. Аналогичный законодательный акт был принят и в Евросоюзе. С одной стороны, все как-то забыли подумать о том, что для пиратов с Дальнего Востока такие ак­ты указом не являются, а с другой стороны, многие считают, что новый закон на­рушил баланс между интересами владельцев авторских прав и общественными интересами.

Взять хотя бы такой пример. В сентябре 2000 года консорциум, связанный с му­зыкальной индустрией, озабоченный созданием надежной онлайновой системы продажи аудиозаписей, организовал конкурс, пригласив всех желающих попро­бовать взломать систему (это действительно очень важный этап, необходимый при создании любой новой системы защиты). Группа ученых из различных уни­верситетов под руководством профессора Эдварда Фельтена (Edward Felten) из Принстона, специализирующихся в области защиты информации, приняли вы­зов и сломали систему. Затем была написана статья, описывающая выводы, еде- данные в ходе исследования. Она была направлена на конференцию USENIX, посвященную проблемам защиты информации. Доклад был рассмотрен и при­нят на соответствующем уровне. Однако незадолго до конференции Фельтен по­лучил уведомление от Ассоциации звукозаписи о том, что эта организация в слу­чае опубликования статьи подаст на авторов в суд за нарушение акта DCMA.

Ученым ничего не оставалось делать, как послать запрос в федеральный су­дебный орган, пытаясь выяснить, является ли еще легальным опубликование на­учных статей, касающихся защиты информации. Опасаясь, что дальнейшее раз­витие событий будет отнюдь не в пользу звукозаписывающей индустрии, ее представители сняли свои претензии к Фельтену, и на этом инцидент был исчер­пан. Несомненно, причиной недовольства звукозаписывающей индустрии была слабость предложенной ими системы. Получилось, что сначала пригласили лю­дей, чтобы те попытались взломать защиту, а когда некоторым это реально уда­лось, на них чуть было не подали за это в суд. После того, как все конфликты были улажены, статья все-таки была напечатана (Craver и др., 2001). Почти очевидно, что таких конфронтаций впереди еще много.

С обсуждаемой темой тесно связана доктрина законного использования, ставшая результатом судебных решений во многих странах. Эта доктрина состо­ит в том, что покупатели продукции, защищенной законом об авторских правах, имеют сильно ограниченные права на копирование этой продукции, включая да­же использование ее частей для научных целей (например, в качестве обучающе­го материала в школах и колледжах) и создание архивных резервных копий на тот случай, если что-нибудь случится с исходным носителем. Как проверить, является ли использование продукции законным? Показатели таковы: 1) ком­мерческое использование; 2) количество процентов скопированных данных; 3) вли­яние копирования на объем продаж. Так как DMCA и аналогичные законы, приня­тые Евросоюзом, запрещают взлом систем защиты от копирования, такие законы заодно запрещают легальное добросовестное использование. По сути, DMCA отбирает у потребителей историческое право активно поддерживать продавцов, у которых они приобрели продукцию. Провал этой идеи неизбежен.

Еще одно явление, затмевающее собой по уровню смещения баланса между обладателями авторских прав и потребителями даже DMCA, — это Альянс надеж­ных вычислительных платформ (ТСРА — Trusted Computing Platform Alliance). Разрабатывается этот проект совместными усилиями Intel и Microsoft. Идея со­стоит в том, чтобы процессор и операционная система зорко наблюдали за дей­ствиями пользователя (например, за воспроизведением скопированной незакон­ным образом звукозаписи) и запрещали совершать нежелательные действия. Та­кая система могла бы даже позволить обладателям авторских прав удаленно манипулировать персональными компьютерами пользователей, изменяя при не­обходимости определенные правила. Несомненно, общественный резонанс будет огромен. Конечно, это очень здорово, что индустрия наконец обратила внимание на проблемы защиты информации, однако нельзя не заметить с прискорбием, что большинство усилий направлено на усиление законов об авторских правах, а не на борьбу с вирусами, взломщиками, мошенниками и другими проблемами, волнующими большинство пользователей.

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