страница

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

Допустим, Труди может взломать систему 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). Однако нам пора двигаться дальше.

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

Маршрутизатор, заваленный пакетами, может -выбирать пакеты просто слу­чайным образом, но обычно имеются более оптимальные варианты. Выбор пакета, который будет отвергнут, может зависеть от приложения, пересылающего этот пакет. Для передачи файла более старый пакет ценится выше нового, так как от­вержение пакета номер б и сохранение пакетов с номерами с 7-го по 10-й может привести к тому, что получатель запросит еще раз пакеты с 6-го по 10-й (если полу­чатель просто отвергает все пакеты, приходящие не в том порядке). В файле, со­стоящем из 12 пакетов, выбрасывание 6-го пакета может потребовать повторной передачи пакетов с 7-го по 12-й, тогда как выбрасывание пакета номер 10 может потребовать повторной передачи только пакетов с 10-го по 12-й. Для мультиме­дийных приложений, напротив, новый пакет важнее старого. Первую стратегию (старое лучше нового) часто называют винной стратегией, а вторую (новое луч­ше старого) — молочной стратегией.

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

Для реализации интеллектуальной стратегии выбрасывания части информа­ции приложения должны помечать свои пакеты классами приоритетов, соответ­ствующими их важности. В этом случае маршрутизаторы смогут сначала выбросить пакеты нижнего класса, затем следующего за ним и т. д. Конечно, при отсутствии стимула все будут помечать свои пакеты не иначе как ОЧЕНЬ ВАЖНО — НИ В КОЕМ СЛУЧАЕ НЕ ВЫБРАСЫВАТЬ.

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