пользователь

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

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

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

В 1995-1997 годы проблемная группа проектирования сети Интернет (IETF) прилагала множество усилий по продвижению архитектуры потокового мульти­медиа.

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

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

Любая из них может читать и запи­сывать проходящую через нее почту. Конфиденциальности не существует, что бы ни думали об этом многие пользователи. Тем не менее, многие пользователи же­лали бы иметь возможность посылать электронную почту так, чтобы ее мог про­читать только тот, для кого она предназначается, и никто другой: ни шеф, ни ха­керы, ни даже правительство. Эта потребность стимулировала применение некоторыми группами и отдельными разработчиками криптографических прин­ципов к электронной почте. В следующих разделах мы познакомимся с широко распространенной системой защиты электронной почты PGP, а также дадим об­щее представление о двух других: РЕМ и S/MIME. Дополнительную информа­цию см. в (Kaufman и др., 2002; Schneier, 1995).

вый блок складывается по модулю 2 со случайным вектором инициализации, IV (Initialization Vector), передаваемым вместе с зашифрованным текстом.

Ро Р1 Рг Рз 1111

Режим шифрованной обратной связи" title="Режим шифрованной обратной связи" border=0 width=279 height=77 src="http://s16.radikal.ru/i190/1007/20/aab6e803acc1.jpg"> Со С1 Сг С з а

Однако у метода сцепления блоков шифра есть и недостаток, заключающийся в том, что прежде чем может начаться шифрование или дешифрация, должен по­явиться целый 64-битовый блок данных. Для пользователей интерактивных тер­миналов, набирающих строки короче восьми символов и ждущих ответа, такой
метод не подходит. Для побайтового шифрования может применяться режим шифрованной обратной связи с использованием (тройного) DES, как показано на рис. 8.11. Для стандарта AES идея остается той же самой, только используется 128-разрядный сдвиговый регистр. На рисунке мы видим состояние шифрующей машины после того, как байты с 0 по 9 уже зашифрованы и посланы. Когда при­бывает десятый байт открытого текста, как показано на рис. 8.11, а, алгоритм DES обрабатывает 64-разрядный сдвиговый регистр, чтобы произвести 64-раз- рядный зашифрованный блок. Самый левый байт этого зашифрованного текста извлекается и складывается по модулю 2 с Р10. Этот байт передается по линии. Затем сдвиговый регистр сдвигается влево на 8 разрядов. При этом байт С2 извле­кается с левого конца регистра, а байт С10 вставляется в него на освободившееся место справа от С9. Обратите внимание на то, что содержимое сдвигового регист­ра зависит от всей предыстории открытого текста, так что повторяющиеся фраг­менты исходного текста будут кодироваться каждый раз по-разному. Как и для метода сцепленных блоков шифра, для начала шифрования этим методом требу­ется вектор инициализации.

 

64-разрядный сдвиговый регистр С2 Сз с4 с5 С6 С7 С8 С9 64-разрядный сдвиговый регистр Сг Сз С4 С5 С6 С7 Cg С9

Шифратор

Шифратор Выбор левого байта

Ключ •

Ключ

I

Выбор левого байта

 

--------------- С10

- Сложение по модулю 2

а                                                                                                 б

Рис. 8.11. Режим шифрованной обратной связи (а); обратная связь по выходу (б)

При использовании режима шифрованной обратной связи дешифрация ана­логична шифрованию. В частности, содержимое сдвигового регистра шифрует­ся, а не дешифруется, поэтому байт, который складывается по модулю 2 с Ci0 для получения Pw равен тому байту, который складывается по модулю 2 с PlQ для получения С10. Пока содержимое двух сдвиговых регистров идентично, де­шифрация выполняется корректно. Это показано на рис. 8.11, б.

>1*0

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

К сожалению, такое решение создает новую проблему: как пользователю забрать свою почту у агента передачи сообщений провайдера? Ответ таков: следует соз­дать специальный протокол, который позволил бы пользовательскому агенту (на машине клиента) соединиться с агентом передачи сообщений провайдера (на ма­шине провайдера) и скопировать хранящуюся для него почту. Одним из таких протоколов является РОРЗ (Post Office Protocol v. 3 — почтовый протокол, 3-я версия), определенный в документе RFC 1939.

Ситуация, при которой доставка осуществляется в условиях постоянного со­единения с Интернетом отправителя и получателя, показана на рис. 7.5, а. Ил­люстрация ситуации, в которой отправитель находится в текущий момент на ли­нии, а приемник — нет, приведена на рис. 7.5, б.

Агент передачи Пользовательский SMTP Интернет сооб1цений                             агент

Хост- отправитель

Постоянное подключение

Почтовый Хост- ящик приемник

к__                                           /

Рис. 7.5. Отправка и прием почты, когда приемник постоянно находится в подключенном состоянии и пользовательский агент работает на одной машине с агентом передачи сообщений (а); прием почты при модемном соединении получателя с провайдером (б)

Почтовый Машина ящик провайдера б

 

Протокол РОРЗ начинает свою работу, когда пользователь запускает почто­вый редактор. Последний дозванивается до провайдера (если только машина уже не находится в подключенном состоянии) и устанавливает TCP-соединение с аген­том передачи сообщений с использованием порта 110. После установки соедине­ния протокол РОРЗ проходит три последовательных состояния.

1. Авторизация.

2.    Транзакции.

3.    Обновление.

Авторизация связана с процессом входа пользователя в систему. В состоянии транзакций пользователь забирает свою почту и может пометить ее для удале­ния из почтового ящика. В состоянии обновления происходит удаление поме­ченной корреспонденции.

Можно посмотреть, как все это происходит, набрав команду вида

telnet mail.isp.com 110,

где mail.isp.com следует заменить на DNS-имя почтового сервера провайдера. Telnet устанавливает TCP-соединение с портом 110, прослушиваемым РОРЗ-сервером. После установки TCP-соединения сервер посылает ASCII-сообщение, объявляя о своем присутствии. Обычно оно начинается с +0К, затем следует комментарий. Возможный сценарий после установки TCP-соединения показан в листинге 7.4. Как и раньше, строки, начинающиеся с С:. говорят о том, что данная команда ис­ходит от клиента (пользователя), а начинающиеся с S: — что это сообщения сер­вера (агента передачи сообщений на машине провайдера).

Листинг 7.4. Получение трех сообщений по протоколу РОРЗ

S: +0К РОРЗ-сервер готов

С: USER carolyn

S: +0К

С: PASS vegetables

S: OK вход в систему произведен

С: LIST

S: 1 2505

S: 2 14302

S: 3 8122

S: .

C: RETR 1

S: (отправляет сообщение 1)

С: DELE 1

С: RETR 2

S: (отправляет сообщение 2)

С: DELE 2

С: RETR 3

S: (отправляет сообщение 3)

С: DELE 3

С: QUIT

S: +0К Конец соединения с РОРЗ-сервером

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

После этого пользователь может запросить сообщения командой RETR и поме­тить их для удаления командой DELE. После получения (и, возможно, установки меток удаления) всех писем пользователь посылает команду QUIT для заверше­ния состояния транзакций и входа в состояние обновления. После удаления сер­вером всех сообщений он посылает ответ и разрывает ТСР-соединение.

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

Теперь подведем небольшие итоги того, как происходит работа с электронной почтой клиентов провайдера. Элинор создает сообщение для Кэролайн с помо­щью редактора электронной почты (то есть пользовательского агента) и щелкает на значке, чтобы отослать его. Программа передает письмо агенту передачи сообще­ний на хосте Элинор. Агент передачи сообщений видит, что письмо адресова­но carolyn@xyz.com, и использует DNS для поиска записи MX для xyz.com (где xyz.com — провайдер Кэролайн). В ответ на запрос возвращается DNS-имя поч­тового сервера xyz.com. Агент передачи сообщений после этого снова обращается к DNS (например, используя gethostbyname): на этот раз ему нужно найти IP-ад­рес этой машины. Затем с помощью порта 25 найденной машины устанавливает­ся TCP-соединение с SMTP-сервером. Передавая команды SMTP, аналогичные показанным в листинге 7.3, агент пересылает сообщение в почтовый ящик для Кэролайн и разрывает ТСР-соединение.

Через некоторое время Кэролайн загружает свой компьютер, соединяется с провайдером и запускает программу электронной почты. Та устанавливает ТСР- соединение через порт 110 РОРЗ-сервера, работающего на машине провайдера. Имя DNS или IP-адрес этой машины обычно указывается при установке про­граммы электронной почты либо его получают у провайдера. После установки TCP-соединения почтовая программа Кэролайн запускает протокол РОРЗ для копирования содержимого почтового ящика на локальный жесткий диск. При этом происходит обмен командами, аналогичными показанным в листинге 7.4. По окончании передачи электронной почты ТСР-соединение разрывается. На самом деле в тот же момент можно разорвать и соединение с провайдером, по­скольку вся почта уже находится на жестком диске у Кэролайн. Конечно, чтобы отправить ответ на письма, Кэролайн придется снова соединяться с провайде­ром, поэтому не всегда пользователи разрывают соединение сразу после загруз­ки почты.

IMAP

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

Это неудобство привело к созданию альтернативного протокола доставки со­общений, IMAP (Interactive Mail Access Protocol — протокол интерактивного доступа к электронной почте), определенного в RFC 2060. В отличие от протоко­ла РОРЗ, который подразумевает, что пользователь будет очищать почтовый ящик после каждого контакта с провайдером и будет работать с почтой в отклю­ченном режиме, протокол IMAP предполагает, что вся почта будет оставаться в почтовых ящиках на сервере неограниченно долго. IMAP обладает широким на­бором механизмов для чтения сообщений или даже частей сообщений. Такое свой­ство полезно при использовании медленных модемов, поскольку можно про­честь только текстовую часть письма, к которому приложены большие видео- и аудиофрагменты. Поскольку основное предположение состоит в том, что пользо­ватель не будет копировать на свой компьютер письма, в IMAP входят также ин­струменты для создания, удаления и других видов управления почтовыми ящика­ми, размещающимися на сервере. Таким образом, пользователь может завести собственный почтовый ящик для каждого лица, с которым ведется переписка, и переносить сообщения из почтового ящика для всех входящих писем в эти пер­сональные ящики.

Протокол IMAP обладает разнообразными возможностями, например, способ­ностью упорядочивать почту не по порядку ее поступления, как показано в табл. 7.3, а по атрибутам писем (например, «сначала дайте мне письмо от Бобби»), В отли­чие от РОРЗ, IMAP может заниматься как доставкой исходящей почты от поль­зователя в направлении места назначения, так и доставлять входящую почту пользователя.

В целом стиль протокола IMAP подобен РОРЗ, пример работы которого по­казан в листинге 7.4. Различаются они количеством команд — в IMAP их десят­ки. Сервер IMAP прослушивает порт 143. Сравнение протоколов РОРЗ и IMAP приведено в табл. 7.8. Следует заметить, что не все провайдеры и не все програм­мы работы с электронной почтой поддерживают оба протокола. Поэтому, выби­рая программу и провайдера, следует выяснить, могут ли они работать хоть с од­ним из этих протоколов, и если да, то с какими именно протоколами.

Таблица 7.8. Сравнение протоколов РОРЗ и IMAP Свойство РОРЗ   IMAP

Где определен                                    RFC 1939                                  RFC 2060

Используемый порт TCP                  110                                             143

Место хранения почты                      ПК пользователя                      Сервер

Способ чтения почты                         В автономном режиме            В подключенном режиме

Требуемое время нахождения         Небольшое                               Большое на линии

Свойство	РОРЗ	IMAP
Использование ресурсов сервера	Минимальное	Значительное
Поддержка нескольких почтовых ящиков	Отсутствует	Есть
Кто делает резервные копии почтовых ящиков	Пользователь	Провайдер
Удобство для мобильных пользователей	Нет	Да
Контроль загружаемой почты пользователем	Низкий	Полный
Возможность частичной загрузки сообщений	Нет	Есть
Наличие проблем с нехваткой места на диске	Нет	Есть
Простота реализации	Да	Нет
Популярность	Широкая	Растет

Конфиденциальность и цензура — это те области, в которых сталкиваются техно­логические аспекты и общественные интересы. Третьей такой областью является защита авторских прав. Авторское право гарантирует свободу распоряжения ин­теллектуальной собственностью ее создателям, которыми могут быть, напри­мер, писатели, художники, композиторы, музыканты, фотографы, кинорежиссе­ры, хореографы и т. д. Авторское право выдается на определенный срок, который обычно равен сроку жизни автора плюс 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. Идея со­стоит в том, чтобы процессор и операционная система зорко наблюдали за дей­ствиями пользователя (например, за воспроизведением скопированной незакон­ным образом звукозаписи) и запрещали совершать нежелательные действия. Та­кая система могла бы даже позволить обладателям авторских прав удаленно манипулировать персональными компьютерами пользователей, изменяя при не­обходимости определенные правила. Несомненно, общественный резонанс будет огромен. Конечно, это очень здорово, что индустрия наконец обратила внимание на проблемы защиты информации, однако нельзя не заметить с прискорбием, что большинство усилий направлено на усиление законов об авторских правах, а не на борьбу с вирусами, взломщиками, мошенниками и другими проблемами, волнующими большинство пользователей.

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

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

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.

Стандарт Н.323 был разработан ITU. В Интернет-сообществе многим он показался типичным продуктом телефонной компании: громоздким, сложным и недостаточ­но гибким. Было решено организовать специальный комитет IETF для создания более простой и гибкой системы передачи речи поверх IP. Основным результа­том деятельности этого комитета стал протокол SIP (Session Initiation Protocol — протокол запуска соединения), описанный в RFC 3261. Протокол оговаривает способ установки телефонных соединений через Интернет, технологию организа­ции систем для видеоконференций и способы создания других мультимедийных приложений. В отличие от Н.323, представляющего собой целый набор протоко­лов, SIP — это единый модуль, способный взаимодействовать с разнообразными интернет-приложениями. Например, номера телефонов определяются в виде URL, то есть на веб-страницах можно размещать гиперссылки, щелкнув на которых, пользователь сможет установить телефонное соединение (примерно так же схема mailto позволяет написать электронное письмо и отправить его по указанному в ссылке адресу).

Протокол SIP позволяет устанавливать и двухсторонние соединения (то есть обычные телефонные соединения), и многосторонние (когда каждый из участ­ников может как слушать собеседников, так и говорить), и широковещательные (когда один из участников говорит, а остальные могут только слушать). Во вре­мя сеанса связи могут передаваться аудио-, видео- или другие данные. Эта воз­можность используется, например, при организации сетевых игр с большим ко­личеством участников в реальном времени. SIP занимается только установкой, управлением и разрывом соединений. Для передачи данных используются дру­гие протоколы, например, RTP/RTCP. SIP — это протокол прикладного уровня, работающий поверх TCP или UDP.

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

Телефонные номера в SIP представляются в виде URL со схемой sip. Напри­мер, sip:ilse@cs.university.edu свяжет вас с пользователем по имени Ilse, хост кото­рого определяется DNS-именем cs.university.edu. SIP URL могут содержать так­же адреса формата IPv4, IPv6 или реальные номера телефонов.

Протокол SIP является текстовым, он построен по модели HTTP. Одна из сторон посылает ASCII-сообщение, в котором первая строка содержит имя мето­да, а ниже следуют дополнительные строки, содержащие заголовки для передачи параметров. Многие заголовки взяты из стандарта MIME, что позволяет SIP взаи­модействовать с существующими интернет-приложениями. Шесть методов, оп­ределяемых базовой спецификацией, перечислены в табл. 7.18.

Таблица 7.18. Методы SIP, определяемые базовой спецификацией Метод Описание INVITE Запрос запуска сеанса связи АСК Подтверждение запуска сеанса BYE Запрос окончания сеанса OPTIONS Опрос возможностей хоста CANCEL Отмена запроса REGISTER Информирование сервера переадресации о текущем местоположении пользователя

Для установки сеанса связи звонящий должен либо создать ТСР-соединение с вызываемым абонентом и послать по нему сообщение INVITE, либо послать это же сообщение в UDP-пакете. В обоих случаях заголовки, содержащиеся во вто­рой и всех последующих строках, описывают структуру тела сообщения, содер­жащего информацию о возможностях звонящего, типах мультимедиа и форма­тах. Если вызываемый абонент принимает звонок, он посылает в качестве ответа трехразрядный код результата типа HTTP (группы этих кодов перечислены в табл. 7.13, код 200 означает прием вызова). Следом за строкой с кодом результа­та вызываемый абонент может также сообщить данные о своих возможностях, типах мультимедиа и форматах.

Соединение устанавливается путем тройного рукопожатия, звонящий высы­лает А СК как для окончания работы протокола, так и для подтверждения приема кода 200.

Любая из сторон может послать запрос окончания сеанса связи, для этого ис­пользуется метод BYE. Сеанс считается законченным после получения подтвер­ждения от противоположной стороны.

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

Метод REGISTER относится к возможности протокола SIP разыскивать поль­зователя и соединяться с ним, даже если его нет дома. Сообщение, содержащее данный метод, отправляется на поисковый сервер SIP, хранящий данные о том, кто где находится в данный момент. Впоследствии с помощью этого сервера мож­но попробовать найти абонента. Операция переадресации, используемая при этом, показана на рис. 7.35. На этом рисунке мы видим, что звонящий отправляет со­общение INVITE на прокси-сервер. Это делает возможную переадресацию неза­метной. Прокси пытается разыскать абонента и посылает INVITE по найденному адресу. Дальнейшее общение представляет собой коммутацию последовательно­сти сообщений при «тройном рукопожатии». Сообщения LOOKUP и REPLY не входят в протокол SIP; на этой стадии может использоваться любой подходящий протокол в зависимости от типа поискового сервера.

Рис. 7.35. Использование прокси и серверов переадресации в протоколе SIP

ЗВО!

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

Довольно простым способом повышения производительности является сохране­ние ранее загружавшихся страниц на случай их повторного запроса. Этот метод особенно эффективен при работе с часто посещаемыми страницами (такими как 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). Однако нам пора двигаться дальше.

Последовательность пакетов, передающихся от источника к приемнику, называ­ется потоком. При этом в сетях, ориентированных на соединение, все пакеты по­тока следуют по одному и тому же маршруту, а в сетях без установления соединения они могут идти разными путями. Каждому потоку требуются определенные усло­вия, которые можно охарактеризовать следующими четырьмя основными пара­метрами: надежность, задержка, флуктуация и пропускная способность. Все вме­сте они формируют то, что называется качеством обслуживания (QoS — Quality of Service), необходимым потоку. Некоторые общие приложения особенно строго подходят к вопросу качества обслуживания, как показано в табл. 5.3.

Первые четыре приложения предъявляют высокие требования к надежности. Некорректная доставка битов должна быть исключена. Обычно это достигается подсчетом контрольной суммы для каждого пакета и ее проверкой у получателя.

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

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

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

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

В сетях ATM принята следующая классификация потоков по требованиям к качеству обслуживания:

1. 
   Постоянная битовая скорость (например, телефония);
2. Переменная битовая скорость в реальном времени (например, сжатые видео­данные при проведении видеоконференций);
3. Переменная битовая скорость не в реальном времени (например, просмотр фильмов через Интернет);
   
4. Доступная битовая скорость (например, передача файлов).

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

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