запрос

Стандарт Н.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.

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

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

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

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

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

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

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

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

Допустим, Труди может взломать систему DNS (например, ту ее часть, которая хранится в кэше DNS у провайдера Алисы) и заменить IP-адрес Боба (например, 36.1.2.3) своим IP-адресом (например, 42.9.9.9). Тогда можно провести атаку. То, как все должно работать в нормальной ситуации, показано на рис. 8.42, а: 1) Али­са запрашивает у службы DNS IP-адрес Боба; 2) получает его; 3) она запрашивает домашнюю страничку Боба; 4) получает ее. После того как Труди заменяет IP-ад­рес Боба на свой собственный, мы получаем ситуацию, показанную на рис. 8.42, б. Алиса ищет IP-адрес Боба, а получает вместо него IP-адрес злоумышленницы Труди, поэтому весь трафик Алисы, предназначенный для Боба, приходит, на са­мом деле, Труди. Та может организовать атаку типа «человек посередине», не му­чаясь с установкой «крокодилов» на телефонной линии Алисы. Вместо этого она может заменить всего одну запись на сервере имен DNS. Это, согласитесь, более просто.

Рис. 8.42. Нормальная ситуация (а); атака со взломом DNS и изменением записи,

относящейся к Бобу (б)

Как Труди удалось обмануть DNS? А это оказалось не таким уж сложным де­лом. Если не вдаваться в подробности, можно описать процесс так: Труди обман­ным путем заставляет DNS-сервер провайдера Алисы послать запрос для поиска адреса Боба. К несчастью, так как DNS использует UDP, сервер не может узнать, кто является реальным отправителем ответа. Труди использует это свойство, фальсифицируя ожидаемый ответ и тем самым занося неверные сведения об IP- адресе Боба в кэш DNS-сервера. Для простоты мы будем предполагать, что про­вайдер Алисы изначально не имеет сведений о веб-сайте Боба, bob.com. Если же такие сведения есть, злоумышленник может выждать, пока срок действия записи истечет, и попробовать еще раз (либо применить другие хитрости).

Труди начинает свою атаку с того, что посылает провайдеру Алисы запрос на поиск IP-адреса bob.com. Так как соответствующая запись отсутствует, сервер, в свою очередь, опрашивает сервер домена верхнего уровня (.com). Но Труди опе­режает этот сервер и посылает ложный ответ, в котором сообщается, что IP-ад­рес bob.com якобы 42.9.9.9. Как мы знаем, в реальности это адрес Труди. Так как этот ответ приходит первым, данные из него заносятся в кэш сервера провайде­ра, а настоящий ответ, если он приходит позже, отвергается. Установка ложного IP-адреса называется обманом DNS. А кэш, в котором хранится заведомо лож­ный IP-адрес, называется отравленным кэшем.

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

Во-вторых, для того чтобы DNS-сервер мог понять, какому запросу соответ­ствует ответ, во все запросы добавляются порядковые номера. Чтобы обмануть
провайдера Алисы, Труди должна знать текущий порядковый номер. Самый простой способ узнать его — это зарегистрировать собственный домен, напри­мер, trudy-the-intruder.com.

Предположим, что IP-адрес этого домена также 42.9.9.9. Труди создает DNS- сервер для этого домена: dns.trudy-the-intruder.com. Его IP-адрес тот же самый (42.9.9.9), поскольку оба домена расположены на одном и том же компьютере. Теперь надо заставить провайдера Алисы поинтересоваться DNS-сервером Тру­ди. Сделать это несложно. Требуется лишь запросить, например, foobar.trudy-the- intruder.com, и серверу провайдера Алисы придется опросить сервер верхнего уровня, .com, и узнать у него, кто обслуживает новый домен Труди.

И вот теперь, когда запись dns.trudy-the-intruder.com занесена в кэш провайде­ра, можно спокойно начинать атаку. Труди запрашивает у провайдера Алисы www.trudy-the-intruder.com, а тот в ответ посылает на DNS-сервер Труди соответ­ствующий запрос. Вот в этом-то запросе и содержится нужный злоумышленнице порядковый номер. Теперь Труди должна действовать без промедления: она ищет с помощью провайдера Алисы Боба и тут же отвечает на собственный вопрос, посылая фальшивку: «Адрес bob.com: 42.9.9.9». Этот подделанный ответ несет в себе порядковый номер на единицу больше только что полученного. За время атаки она может послать еще одну фальшивку, с номером, на два больше полу­ченного, а также еще около дюжины таких «ответов» с увеличивающимися но­мерами. Задача одного из них нам уже ясна. Остальные никому не нужны, их просто выкинут. После прибытия фальшивого ответа на запрос Алисы он будет помещен в кэш; к тому времени, когда доберется настоящий ответ, он будет от­вергнут, так как сервер уже ничего не ожидает.

И вот Алиса ищет IP-адрес bob.com и узнает, что он равен 42.9.9.9. Как мы знаем, это адрес Труди, которая провела успешную атаку типа «человек посере­дине», не выходя из своей комнаты. Последовательность предпринятых ею ша­гов показана на рис. 8.43. К сожалению, это еще и не единственный способ обма­нуть DNS. Этих способов действительно много.

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

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

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

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

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

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

Для описания алгоритма воспользуемся рис. 5.18, на котором изображен про­цесс, запущенный на узле А, которому необходимо отправить пакет на узел I. Алго­ритм AODV на каждом узле ведет таблицу, доступ к которой осуществляется с помощью поля адреса. Таблица содержит информацию об адресате, в том числе адрес ближайшего соседа, которому необходимо переслать пакет, чтобы он мог достичь пункта назначения. Допустим, А просматривает эту таблицу и не нахо­дит записи для I. Значит, нужно найти маршрут, ведущий к этому узлу. Итак, ал­горитм начинает заниматься поисками маршрутов только тогда, когда они реаль­но требуются. Это и делает его алгоритмом «по требованию».

Для поиска I узел А генерирует специальный пакет запроса маршрута ROUTE REQUEST и распространяет его по сети широковещательным способом. На рис. 5.18, а показано, что этот пакет достигает узлов В и D. На самом деле, при­чиной установления именно узлами В и D соединения с А является то, что они могут получать пакеты от А. Например, F не соединен дугой с А, потому что он не может принимать радиосигнал от этого узла. То есть F не соединен с А.

Формат пакета запроса маршрута показан на рис. 5.19. В нем, как видно из Этого рисунка, содержатся адреса источника и приемника (обычно IP-адреса), с помощью которых можно понять, кто кого ищет. Также содержится поле Иденти­фикатор запроса, которое представляет собой локальный счетчик, обновляемый каждым узлом независимо и инкрементирующийся всякий раз, когда распро­страняется пакет запроса маршрута. Поля Адрес источника и Идентификатор запроса вместе единственным образом идентифицируют пакет ROUTE REQUEST, что позволяет узлам обнаруживать и отвергать любые дубликаты.

В дополнение к счетчику Идентификатор запроса каждый узел имеет второй счетчик, который инкрементируется всякий раз при отправке пакета для запроса маршрута или ответе на такой пакет. Его работа напоминает часы, и используется он для того, чтобы можно было отличить новые маршруты от старых, Четвертое поле, показанное на рис. 5.19, это счетчик узла А\ пятое — последнее значение порядкового номера пакета, полученного от / (оно равно 0, если такого пакета не было). Вскоре мы более подробно раскроем назначение этих полей Наконец, по­следнее поле — Счетчик переходов — запоминает количество пересылок, совер­шенных пакетом. В начале работы алгоритма оно равно нулю.

Когда пакет запроса маршрута прибывает на узел (например, на узлы В и D), с ним происходит следующее:

1. Пара значений полей Адрес источника и Идентификатор запроса ищется в таблице локальной истории. С их помощью можно выяснить, приходил ли уже этот запрос и обрабатывался ли он. Если обнаруживается, что пакет яв­ляется дубликатом, он отвергается и его обработка прекращается. В против­ном случае указанная пара значений заносится в таблицу истории, чтобы в будущем можно было обнаружить дубликаты. Обработка запроса продолжа­ется.
2. Приемник ищет адрес назначения в таблице маршрутов. Если известен доста­точно свежий маршрут, отправителю посылается пакет наличия маршрута ROUTE REPLY, сообщающий ему о том, как можно достичь получателя (в двух словах: «Используй меня»). Что значит «свежий маршрут»? Имеется в виду, что поле Порядковый номер получателя в таблице маршрутизации имеет зна­чение большее или равное Порядковому номеру получателя из пакета запроса маршрута. Если оно меньше, значит, хранящийся в таблице маршрут явля­ется более старым, нежели предыдущий маршрут, имевшийся у отправителя к тому же пункту назначения. В этом случае выполняется пункт 3.
3. Поскольку у приемника отсутствует свежий маршрут к адресату, он инкре- ментирует поле Счетчик переходов и вновь широковещательным образом рас­пространяет пакет запроса маршрута. Из пакета извлекаются данные и сохраня­ются в виде новой записи в таблице обратных маршрутов. Эти данные будут использоваться для построения обратного пути, по которому впоследствии необходимо будет послать ответный пакет отправителю. Стрелки на рис. 5.18 как раз показывают процесс построения обратного пути. Для записи о только чтй созданном обратном пути запускается таймер. При наступлении тайм- аута запись удаляется.

Ни В, ни D не знают, где находится узел I, поэтому каждый из них создает об­ратный путь к А, как показано стрелками на рис. 5.18, и широковещательным способом распространяет пакет со Счетчиком переходов, установленным в еди­ницу. Этот пакет от В достигает С и D. Узел С делает запись в таблице обратных путей и, в свою очередь, тоже широковещательным способом распространяет па­кет далее. Что касается Д то он отвергает пакет: для него это дубликат. Разуме­ется, и В отвергает пакеты, полученные от D. Тем не менее, F и G принимают ши­роковещательное сообщение от D и сохраняют его, как показано на рис. 5.18, в. После того как Е, Н и I получают широковещательный пакет, запрос маршрута наконец достигает узла назначения (Г). Этот счастливый миг запечатлен на рис. 5.18, г. Обратите внимание: несмотря на то, что мы показали распростране­ние широковещательного пакета в виде трех стадий, на самом деле рассылка это­го пакета разными узлами никак не координируется.

В ответ на пришедший запрос узел I генерирует пакет наличия маршрута ROUTE REPLY, показанный на рис. 5.20. Поля Адрес отправителя, Адрес получателя и Счетчик переходов копируются из ROUTE REQUEST, а Порядковый номер получателя берется из собственного счетчика, хранящегося в памяти. Поле Счетчик перехо­дов устанавливается в 0. Поле Время существования используется для управле­ния реализуемостью маршрута. Данный пакет распространяется методом одно­адресной передачи на тот узел, с которого пришел запрос маршрута. В данном случае он уходит на узел G. Затем, в соответствии с установленным обратным путем, он попадет на D и наконец на А. При проходе каждого узла Счетчик пере­ходов инкрементируется, так что узел-отправитель может увидеть, насколько да­леко от него находится узел-получатель (7).

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

1. Не известен ни один маршрут.
2. Последовательный номер для I в пакете ROUTE REPLY больше, чем значение в таблице маршрутизации.
3. Последовательные номера равны, но новый путь короче.

Таким образом, все узлы, стоящие на обратном пути к А, совершенно бес­платно получают информацию о маршруте к узлу I. Это как бы побочный про­дукт построения маршрута для А. Узлы, получившие исходный пакет запроса маршрута, но не стоящие на обратном пути (узлы В, С, Е, Fn Н в данном примере) удаляют запись в таблице обратных маршрутов, когда ассоциированный с ней таймер достигает тайм-аута.

В больших сетях алгоритмом генерируется много широковещательных паке­тов даже для адресатов, расположенных довольно близко друг к другу. Число этих пакетов может быть уменьшено следующим образом. Время жизни 1Р-паке- та устанавливается отправителем в значение, соответствующее ожидаемому диа­метру сети, и декрементируется при каждой пересылке. Когда его значение ста­новится равным 0, пакет отвергается, а не распространяется дальше.

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

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

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

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

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

Обычно при запуске пользовательский агент просматривает содержимое почто­вого ящика пользователя на предмет наличия новой почты. Затем он может объя­вить пользователю число новых сообщений в почтовом ящике или отобразить по одной строке сведений о каждом письме, после чего перейти в режим ожидания команды пользователя.

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

Каждая отображаемая строка содержит несколько полей, извлеченных из кон­верта или заголовка соответствующего сообщения. В простой системе электрон­ной почты список отображаемых полей встроен в программу. В более сложных системах пользователь может выбрать отображаемые поля, а настройки пользо­вателя будут храниться в специальном файле, называющемся профилем пользо­вателя. В данном примере первое отображаемое поле — номер сообщения. Вто­рое поле, Flags (флаги) может содержать флаг К, означающий, что сообщение не является новым, уже было прочитано и хранится в почтовом ящике; флаг А, означающий, что на данное сообщение уже был отправлен ответ; и/или флаг F, означающий, что сообщение было переадресовано кому-то еще. Возможно также использование и других флагов.

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

После того как программа отобразила заголовки, пользователь может выпол­нить одну из нескольких команд: чтение, удаление письма и т. д. Старые систе­мы с текстовым интерфейсом обычно управлялись с помощью односимвольных команд, таких как Т (вывести сообщение), А (создать ответ), D (удалить сообще­ние) и F (переслать). Более современные системы имеют графический интер­фейс. Обычно пользователь выбирает сообщение с помощью мыши, затем щел­кает на значке, соответствующем определенному действию (выводу сообщения, созданию ответа, удалению и переадресации).

Электронная почта сильно изменилась с тех пор, когда она представляла со­бой простую передачу файлов. Пользовательские агенты с развитым набором ус­луг позволяют управляться с огромными потоками почты. Для всех, кому прихо­дится получать и отправлять тысячи писем в год, такие программы просто незаменимы.