процесс

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

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

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

В качестве содержимого спецификации потока рассмотрим пример, базирую­щийся на RFC 2210 и RFC 2211 (табл. 5.4). В спецификации содержится пять параметров, первый из которых, Скорость маркерного ведра, хранит число бай­тов, поступающих в «ведро» за секунду. Это максимум, который отправитель мо­жет поддерживать в течение длительного времени, усредненный по большому временному отрезку.Второй параметр — размер маркерного ведра в байтах. Если, к примеру, Ско­рость маркерного ведра составляет 1 Мбит/с, а размер ведра равен 500 Кбайт, то его можно будет наполнять данными в течение 4 с. Все, что будет посылаться по­сле этого, будет теряться.

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

Наконец, последние два параметра определяют минимальный и максималь­ный размеры пакетов, включая заголовки транспортного и сетевого уровней (на­пример, TCP и IP). Минимальный размер важен, поскольку обработка каждого пакета занимает какое-то, пусть даже очень малое, время. Маршрутизатор, мо­жет быть, готов принимать 10 000 пакетов в секунду по 1 Кбайт каждый, но не готов обрабатывать 100 ООО пакетов по 50 байт в секунду несмотря на то, что во втором случае скорость передачи данных меньше, чем в первом. Максимальный размер пакета не менее важен, но уже по другой причине. Дело в том, что сущест­вуют определенные внутрисетевые ограничения, которые ни в коем случае не должны быть превышены. Например, если путь потока лежит через Ethernet, то максимальный размер пакета будет ограничен 1500 байтами независимо от того, какого размера пакеты могут поддерживать другие части сети.

Интересно, каким образом маршрутизатор преобразует спецификацию пото­ка в набор определенных резервируемых ресурсов? Это отображение является специфическим и не стандартизованным действием. Допустим, маршрутизатор может обрабатывать 100 000 пакетов/с. Если ему предлагается пропустить через себя поток со скоростью 1 Мбайт/с с максимальным размером пакета, состав­ляющим 512 байт, он может легко посчитать, что такой поток дает 2048 паке­тов/с, значит, под него необходимо отвести 2 % времени работы процессора, а лучше немного больше, чтобы избежать больших задержек обслуживания. Ес­ли политика маршрутизатора не позволяет ему резервировать более 50 % про­цессорного времени (что подразумевает половинную задержку) и если 49 % уже зарезервировано, то поток будет отвергнут. Подобные вычисления необходимо производить для всех резервируемых ресурсов.

Чем строже спецификация потока, тем лучше для маршрутизаторов. Если же в спецификации говорится, что Скорость маркерного ведра составляет 5 Мбайт/с, однако пакеты могут быть размером от 50 до 1500 байт, значит, скорость переда­чи пакетов может колебаться от 3500 до 105 000 пакетов/с. Маршрутизатор, ужаснувшись при виде последнего числа, может отвергнуть такой поток. При ми­нимальном размере пакета, равном 1000 байт, 5-мегабайтный поток тем же са­мым маршрутизатором мог бы быть принят.

Шифры, основанные на методе подстановки, сохраняют порядок символов, но подменяют их. Шифры, использующие метод перестановки, меняют порядок следования символов, но не изменяют сами символы. На рис. 8.2 показан простой перестановочный шифр с колоночной перестановкой. Ключом к шифру служит слово или фраза, не содержащая повторяющихся букв. В данном примере в каче­стве ключа используется слово MEGABUCK. Цель ключа — пронумеровать ко­лонки. Первой колонкой становится колонка под буквой, расположенной ближе всего к началу алфавита, и т. д. Открытый текст записывается горизонтально в строках. Шифрованный текст читается по колонкам, начиная с колонки с млад­шей ключевой буквой.

м	Е	G	А	В	у	С	К
7	4	5	1	2	8	3	6
Р	1	е	а	s	е	t	г
а	п	s	f	е	г	0	п
е	m	1	1	1	i	о	п
d	о	1	1	а	г	S	t
0	m	У	s	w	i	S	S
b	а	п	к	а	с	с	О
u	п	t	s	i	X	t	W
О	t	W	о	а	b	с	d

Открытый текст

pleasetransferonemilliondollarsto myswissbankaccountsixtwotwo

Зашифрованный текст

AFLLSKSOSELAWAIATOOSSCTCLNMOMANT ESILYNTWRNNTSOWDPAEDOBUOERIRICXB

Рис. 8.2. Перестановочный шифр

Чтобы взломать перестановочный шифр, криптоаналитик должен вначале по­нять, что он имеет дело именно с перестановочным шифром. Если взглянуть на частоту символов Е, Т, А, 0,1, N и т. д., легко заметить, что их частоты соответст­вуют нормальным частотам открытого текста. В таком случае очевидно, что этот шифр является перестановочным, так как каждая буква в таком шифре пред­ставляет сама себя.

Затем нужно угадать число колонок. Во многих случаях по контексту сооб­щения можно угадать слово или фразу. Например, предположим, что криптоана­литик подозревает, что где-то в сообщении должно встретиться словосочетание milliondollars. Обратите внимание, что в результате того, что эти слова присутст­вуют в исходном тексте, в шифрованном тексте встречаются биграммы МО, IL, LL, LA, IR и OS. Символ О следует за символом М (то есть они стоят рядом по вертикали в колонке 4), так как они разделены в предполагаемой фразе дистан­цией, равной длине ключа. Если бы использовался ключ длиной семь, тогда вме­сто перечисленных выше биграмм встречались бы следующие: MD, Ю, LL, LL, IA, OR и NS. Таким образом, для каждой длины ключа в шифрованном тексте об­разуется различный набор биграмм. Перебрав различные варианты, криптоана­литик часто довольно легко может определить длину ключа.

Остается узнать только порядок колонок. Если число колонок k невелико, мож­но перебрать все k(k - 1) возможных комбинаций пар соседних колонок, сравнивая частоты образующихся биграмм со статистическими характеристиками англий­ского языка. Пара с лучшим соответствием считается правильно позициониро­ванной. Затем все оставшиеся колонки по очереди проверяются в сочетании с уже найденной парой. Колонка, в которой биграммы и триграммы дают макси­мальное совпадение со статистикой, предполагается правильной. Весь процесс повторяется, пока не будет восстановлен порядок всех колонок. Есть шанс, что на данном этапе текст уже будет распознаваемым (например, если вместо слова million мы увидим milloin, то сразу станет ясно, где сделана ошибка).

Некоторые перестановочные шифры принимают блок фиксированной длины на входе и выдают блок фиксированной длины на выходе. Такие шифры полно­стью определяются списком, сообщающим порядок, в котором символы попада­ют в выходной блок. Например, шифр на рис. 8.2 можно рассматривать в виде шифра с 64-символьным блоком. Его выход описывается последовательностью

чисел 4, 12, 20, 28, 36, 44, 52, 60, 5, 13....... 62. Другими словами, четвертая входная

буква, а, первой появится на выходе, за ней последует двенадцатая, /, и т. д.

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

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

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

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

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

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

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

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

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

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

Для решения этой проблемы было предложено несколько различных алго­ритмов. Мы рассмотрим метод хорды (Dabek и др., 2001а; Stoica и др., 2001). Несколько упрощенное объяснение принципа его работы таково. Пусть система состоит из п пользователей. У каждого из них есть какие-то записи, и каждый го­тов хранить биты и части индекса, которые могут быть использованы другими. У каждого узла есть IP-адрес, который может быть закодирован ш-битным номе­ром с помощью хэш-функции. В методе хорды используется алгоритм SHA-1 для вычисления значения хэш-функции. SHA-1 применяется в криптографии, и мы рассмотрим его в главе 8. А сейчас нам просто надо знать, что это некоторая функция с аргументом в виде строки переменной длины и значением — 160-бит­ным числом высокой степени случайности. Таким образом, любой IP-адрес мож­но закодировать 160-битным числом, называемым идентификатором узла.

Концепция состоит в том, что вообще все 2160 идентификаторов располагают­ся в возрастающем порядке, образуя большой круг чисел. Некоторые из иденти­фикаторов соответствуют реально существующим узлам, но это лишь малая часть из них. На рис. 5.22 показан круг идентификаторов для т = 5 (на дуги внутри круга пока внимания не обращайте). В этом примере реальным узлам соответст­вуют идентификаторы 1, 4, 7, 12, 15, 20 и 27. На рисунке кружочки с этими номе­рами закрашены. Всем остальным идентификаторам нельзя поставить в соответ­ствие какие-либо узлы.

Определим функцию определения последователя successor{k) как идентифи­катор первого реального узла, следующего после k в описанном нами круге (по часовой стрелке). Например, successor^) = 7, successor^8) = 12, successor^22) = 27.

Названия записей (например, названия песен, имена предков и т. п.) также обрабатываются хэш-функцией hash (с помощью алгоритма SHA-1) и превраща­
ются в 160-битные числа, называемые ключами. Таким образом, чтобы получить ключ (key) из названия записи (пате), необходимо вычислить key = hash(name). Такое вычисление является просто локальной процедурой, вызовом функции hash. Если держатель генеалогической записи хочет сделать ее доступной всем, он должен построить кортеж (набор взаимосвязанных величин), состоящий из по­лей (пате, мой_1Р-адрес), и затем выполнить функцию successor(hash(name)) для сохранения кортежа в общепринятой форме. Если существует несколько запи­сей (на разных узлах) для одного и того же названия, все их кортежи будут хра­ниться на одном и том же узле. То есть индекс распределяется случайным обра­зом между узлами. Во избежание сбоев системы, для хранения кортежей на р узлах используется р различных хэш-функций, но далее мы не будем учитывать этот нюанс.

Поиск узла в равноранговых сетях" width=299 height=319 src="http://s58.radikal.ru/i161/1007/f4/be943eb71cbd.jpg" align=left hspace=12>

Поиск узла в равноранговых сетях" width=44 height=93 src="http://s58.radikal.ru/i161/1007/f4/be943eb71cbd.jpg" align=left hspace=12>

Рис. 5.22. Набор из 32 идентификаторов узлов, выстроенных по кругу (а). Закрашенные кружочки соответствуют реальным узлам. Дугами обозначены указатели с узлов 1,4 и 12. Подписи на дугах соответствуют индексам таблицы. Примеры таблиц указателей (б)

Если кто-то из пользователей затем захочет найти название записи (пате), он вычислит значение хэш-функции, получит ключ (key) и затем с помощью функ­ции successoiikey) сможет найти IP-адрес узла, хранящего кортежи индексов. Первый шаг осуществляется довольно просто, не в пример второму. Для того чтобы можно было найти IP-адрес узла, соответствующего какому-либо ключу, каждый узел должен поддерживать определенные служебные структуры данных. Одной из них является IP-адрес последователя. Например, на рис. 5.22 последо­ватель узла 4 — это узел 7, а последователь узла 7 — узел 12.

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

В качестве первой оптимизации алгоритма предлагается следующее: каждый узел должен знать IP-адрес не только последователя, но и предшественника, то­гда запрос можно будет распространять одновременно в двух направлениях — по часовой стрелке и против часовой стрелки, в зависимости от того, какой из путей кажется более коротким. Например, на рис. 5.22 узел 7 может отправить пакет по часовой стрелке, если ищется узел 10. А если ищется узел 3, то логичнее напра­вить пакет против часовой стрелки.

Даже с этой возможностью выбора направления линейный поиск остается крайне неэффективным методом для больших равноранговых сетей, поскольку среднее число узлов, которое потребуется обойти для поиска записи, равно п/2. Значительно ускорить поиск позволяет поддерживаемая каждым узлом специ­альная таблица, которая в методе хорд носит название таблицы указателей. В ней имеется т записей, пронумерованных от 0 до т - 1. Каждая запись содержит два поля: начало и IP-адрес последователя — successoristart), как показано на рис. 5.22, б. Значения полей записи i на узле k равны:

Start = k + 2' (modulo2m), IP-адрес successor (start [г]).

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

С использованием таблицы указателей процесс поиска ключа на узле k выгля­дит следующим образом. Если ключ попадает в диапазон между k и successor(k), значит, он находится, на самом деле, на узле successor(k), и поиск прекращается. В противном случае таблица указателей просматривается на предмет поиска за­писи, поле начало которой является ближайшим предшественником ключа. За­прос посылается напрямую по IP-адресу из таблицы указателей. Узел с этим ад­ресом просят перенять инициативу поиска. Поскольку искомый ключ находится где-то рядом, но идентификатор имеет меньшее значение, велика вероятность того, что конечный ответ будет дан очень скоро, спустя всего несколько допол­нительных запросов. Поскольку каждая итерация при поиске вдвое уменьшает последующую область рассмотрения (то есть оставшееся расстояние до цели), то можно доказать, что среднее число итераций равно log2 п.

В качестве первого примера рассмотрим поиск ключа key = 3 на узле 1. Узел с идентификатором 1 знает, что 3 лежит где-то между ним самим и его последова­телем — узлом 4. Он делает вывод о том, что ключ находится на узле 4, и поиск прекращается. Результатом является IP-адрес узла 4.

Второй пример. Пусть узлу 1 теперь понадобилось найти ключ key = 14. Чис­ло 14 не находится между 1 и 4, поэтому необходимо заглянуть в таблицу указа­телей. Ближайшим предшественником 14 является 9, поэтому запрос направля­ется на IP-адрес, хранящийся в записи с полем начало, равным 9. Конкретно, это узел 12. Последний видит, что 14 находится между ним самим и последовате­лем — узлом 15, поэтому результатом поиска является IP-адрес узла 15.

Третий пример. Допустим, узлу 1 нужно найти ключ key =16. Запрос, как и в предыдущем примере, отправляется на узел 12. Но на этот раз узел не может са­мостоятельно ответить на него. Он пытается найти тот узел, который находится ближе всего к 16, но имеет меньший идентификатор. Им является узел 14, кото­рый ссылается, в свою очередь, на узел 15. Запрос туда и посылается. Узел 15 ви­дит, что 16 находится между ним самим и его последователем (20), поэтому он возвращает IP-адрес 20 просителю. Ответ возвращается сразу на узел 1.

Поскольку узлы могут появляться в сети и исчезать из нее в любое время, в ме­тоде хорд необходимо как-то обрабатывать подобные ситуации. Мы предполага­ем, что когда система начинала работать, она была достаточно небольшой, и узлы могли обмениваться информацией напрямую, выстраивая первичный круг иден­тификаторов и таблицы указателей. После этого уже необходима автоматизиро­ванная процедура. Когда новый узел г собирается войти в сеть, он должен войти в контакт с какой-либо из уже находящихся в сети станций и попросить ее поис­кать для него IP-адрес successor(r). Затем новый узел выясняет, кто будет его предшественником (successor(r) для предшественника). Все это нужно для того, чтобы можно было определить свое место в круге идентификаторов. Например, если узел 24 на рис. 5.22 захочет войти в сеть, он может поинтересоваться у лю­бого узла, чему равно значение successor(24). Выясняется, что оно равно 27. За­тем у узла 27 надо узнать, кто является его предшественником (20). После того как обоим этим узлам сообщается о существовании нового узла, узел 20 помеча­ет себе, что его последователем становится узел 24, а узел 27 — что этот узел ста­новится его предшественником. Кроме того, узел 27 передает ключи диапазона 21-24 новичку. С этого момента последний считается зарегистрированным в рав- норанговой сети.

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

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

Метод хорд используется для создания распределенных файловых систем (Dabek и др., 2001b) и других приложений; научные изыскания в этой области идут и сейчас. Одна из равноранговых систем, Pastry, и ее приложения описаны в (Rowston and Druschel, 2001а; Rowston and Druschel, 2001b). Еще одна система, Freenet, обсуждается в (Clarke и др., 2002). Наконец, четвертая система этого ти­па описана в (Ratnasamy и др., 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, и т. д. Таким образом, поиск, начавшийся в ка­кой-то локальной области, все больше расширяет свой охват.

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

Передача сообщения членам такой группы называется многоадресной рассыл­кой, а алгоритм маршрутизации этой операции — многоадресной маршрути­зацией. В этом разделе будет описан один из способов реализации многоадресной маршрутизации. Дополнительные сведения см. в (Chu и др., 2000; Costa и др., 2001; Kasera и др., 2000; Madruga and Garcia-Luna-Aceves, 2001; Zhang and Ryu, 2001).

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

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

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

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

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

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