номер

Допустим, Труди может взломать систему 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. Этих способов действительно много.

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

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

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

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

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

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

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.

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

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

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

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

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

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

В-третьих, может произойти искажение порядкового номера — например, вмес­то номера 4 будет принято число 65 540 (ошибка в 1-м бите); в этом случае паке­ты с 5-го по 65 540-й будут игнорироваться некоторыми маршрутизаторами как устаревшие.

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

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

Структура данных, используемая маршрутизатором В для работы с подсетью, изображенной на рис. 5.11, а, показана на рис. 5.12. Каждый ряд здесь соответству­ет недавно полученному, но еще не полностью обработанному пакету состояния линий. В таблице записываются адрес отправителя, порядковый номер, возраст и данные. Кроме того, в таблице содержатся флаги рассылки и подтверждений для каждой из трех линий маршрутизатора В (к А, С и F соответственно). Флаги отсылки означают, что этот пакет следует отослать по соответствующей линии. Флаги подтверждений означают, что нужно подтвердить получение этого пакета по данной линии.

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

Однако ситуация с третьим пакетом, полученным от маршрутизатора Е, отли­чается. Он был получен дважды, по линиям ЕАВ и EFB, Следовательно, его нуж­но отослать только С, но подтверждения выслать и А, и jF, как указывают биты.

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

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

Модель мира, обычно используемая разработчиками сетей, показана на рис. 5.16. Здесь мы видим глобальную сеть, состоящую из маршрутизаторов и хостов. С глобальной сетью соединены локальные и региональные сети и беспроводные соты, которые рассматривались в главе 2.

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

Предполагается, что у всех хостов есть постоянное домашнее местоположе­ние, которое никогда не меняется. Кроме того, у хостов есть постоянный домаш­ний адрес, которым можно воспользоваться для определения домашнего место­положения, аналогично тому, как телефонный номер 1-212-5551212 обозначает США (страна с кодом 1) и Манхэттен (212). Целью маршрутизации в системах с мобильными хостами является обеспечение возможности передачи пакетов мо­бильным пользователям с помощью их домашних адресов. При этом пакеты долж­ны эффективно достигать пользователей, независимо от их расположения. Са­мое сложное здесь, конечно, — найти пользователя.

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

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

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

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

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

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

5.    Получив подтверждение от внутреннего агента, внешний агент заносит сведения о мобильном хосте в свою таблицу и сообщает ему, что он зарегистрирован.

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

Когда пакет посылается мобильному пользователю, он направляется в его до­машнюю локальную сеть на домашний адрес пользователя. На рис. 5,17 это дей­ствие показано как этап 1. Здесь отправитель из северо-западного города Сиэтла хочет отправить пакет хосту, который обычно находится по другую сторону США, в Нью-Йорке. Пакеты, посланные в домашнюю локальную сеть мобильного хос­та (Нью-Йорк), перехватываются внутренним агентом, который узнает новое (временное) расположение мобильной станции (например, Лос-Анджелес) и ад­рес внешнего агента локальной сети, в которой она в данный момент находится.

Затем внутренний агент выполняет два действия. Во-первых, он помещает па­кет, предназначающийся мобильному пользователю, в поле данных внешнего па­кета, который посылается внешнему агенту (этап 2 на рис. 5.17). Такой прием называется туннелированием. Позднее мы обсудим ее подробнее. Получив па­кет, внешний агент извлекает из поля данных оригинальный пакет, который пе­ресылает мобильному пользователю в виде кадра уровня передачи данных.

Затем внутренний агент сообщает отправителю, что в дальнейшем следует не посылать пакеты мобильному хосту на домашний адрес, а вкладывать их в поле данных пакетов, явно адресованных внешнему агенту (этап 3 на рис. 5.17). По­следующие пакеты теперь могут направляться напрямую пользователю через внеш­него агента (этап 4), полностью минуя домашний адрес мобильного пользователя.

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

В-четвертых, схемы различаются способами переадресации пакетов. Один из способов заключается в изменении поля адреса получателя в пакете и передаче измененного пакета. Есть системы, в которых весь пакет, включая домашний ад­рес, может быть помещен внутрь другого пакета, посылаемого по временному ад­ресу. В любом случае, когда хост или маршрутизатор получает сообщение вида «Начиная с этого момента, пожалуйста, пересылайте мне всю почту, адресуемую Стефани», у него могут возникнуть вопросы — например, с кем он разговаривал, соглашаться или нет на данное предложение. Несколько протоколов мобильных хостов обсуждаются и сравниваются в (Нас and Guo, 2000; Perkins, 1998а; Snoe- ren and Balakrishnah, 2000; Solomon, 1998; Wang and Chen, 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, и т. д. Таким образом, поиск, начавшийся в ка­кой-то локальной области, все больше расширяет свой охват.

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

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

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

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

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

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

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

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

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

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

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