информация

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

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

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

1. Наблюдения за системой с целью определить, где и когда произойдет пере­грузка.
2. Передачи информации о перегрузке в те места, где могут быть предприняты соответствующие действия.
3. Принятия необходимых мер при работе системы для устранения перегрузки. При наблюдении за состоянием подсети с целью обнаружения перегрузки мо­гут измеряться различные параметры. Среди них следует выделить следующие: процент пакетов, отвергаемых из-за отсутствия свободного места в буфере; сред­няя длина очереди; процент пакетов, переданных повторно по причине истекше­го времени ожидания подтверждения; среднее время задержки пакетов и средне­квадратичное отклонение задержки пакетов. Во всех случаях увеличивающиеся значения параметров являются сигналами о растущей перегрузке.

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

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

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

Все системы с обратной связью предполагают, что получившие информацию о перегрузке в сети хосты и маршрутизаторы предпримут какие-нибудь дейст­вия для устранения перегрузки. Чтобы данная схема работала, необходимо тща­тельно настроить временные параметры. Если каждый раз, когда два пакета прихо­дят одновременно, какой-нибудь нервный маршрутизатор будет кричать «Стоп1», а простояв без работы 20 мкс, он же будет давать команду «Давай!», система бу­дет находиться в состоянии постоянных незатухающих колебаний. С другой сто­роны, если маршрутизатор будет спокоен, как слон, и для большей надежности станет ждать 30 минут, прежде чем что-либо сообщить, то механизм борьбы с пе­регрузкой будет реагировать слишком медленно, чтобы приносить вообще ка­кую-либо пользу. Для правильной работы необходимо некоторое усреднение, однако правильный выбор значения постоянной времени является нетривиаль­ной задачей.

Известны различные алгоритмы борьбы с перегрузкой. Янг (Yang) и Редди (Reddy) (1995) даже разработали специальный метод классификации этих алго­ритмов. Они начали с того, что разделили все методы на алгоритмы с обратной Связью и без нее, как уже описывалось ранее. Затем они разделили алгоритмы без обратной связи на работающие у отправителя и у получателя. Алгоритмы с обратной связью также были разделены на две подкатегории: с явной и неявной обратной связью. В алгоритмах с явной обратной связью от точки возникнове­ния перегрузки в обратном направлении посылаются пакеты, предупреждающие о заторе. В алгоритмах с неявной обратной связью источник приходит к выводу о наличии перегрузки, основываясь на локальных наблюдениях, — например, по значению интервала времени, требующегося для получения подтверждения.

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

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

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

Поскольку узлы могут перемещаться и выключаться, топология сети может из­меняться совершенно спонтанно. Например, если на рис. 5.18 узел G выключит­ся, А не поймет, что путь к I (ADGI) больше не может быть реализован. Алгорит­му нужно как-то с этим бороться. Периодически все узлы рассылают сообщение приветствия Hello. Ожидается, что все узлы, будучи истинными джентльменами, ответят на него. Если ответ не приходит, значит, сосед вышел из зоны действия и больше не связан с данным узлом. Аналогичным образом, если он пытается по­слать пакет соседу, который не отвечает, он узнает, что связь с ним недоступна.

Эта информация используется для удаления нерабочих путей. Для каждого из возможных адресатов каждый узел Охранит историю о том, какие соседи снаб­жали узел пакетами для данных адресатов в течение последних ДГ секунд. Такие соседи называются активными соседями узла N для данного адресата. Узел N осуществляет сбор подобных сведений с помощью таблицы маршрутизации, ко­торая, как известно, в качестве индекса использует адрес назначения. В этой таб­лице указан тот узел, на который нужно переслать пакет, чтобы он мог дойти до адресата. Кроме того, в ней имеются сведения об оставшемся числе переходов, последнем порядковом номере получателя, а также об активных соседях данного адресата. Вид возможной таблицы маршрутизации для узла D при топологии, рассматриваемой в нашем примере, показан на рис. 5.21, а.

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

Рассмотрим наш предыдущий пример, предположив, что G внезапно вык­лючился. Образовавшаяся в результате этого события топология показана на рис. 5.21, б. Когда D обнаруживает, что G ушел из сети, он просматривает свою таблицу маршрутизации и видит, что G стоял на пути к Е, G и I. Объединением активных соседей для данных адресатов является множество {А, В}. Другими словами, А и В содержат записи о маршрутах, проходящих через G, поэтому их нужно проинформировать о том, что эти маршруты больше не работают. D сооб­щает им об этом, посылая специальные пакеты, заставляющие их обновить свои таблицы соответствующим образом. Сам узел D удаляет записи для адресатов Е, G и / из таблицы маршрутизации.

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

AODV, впрочем, может также заниматься широковещательной и групповой маршрутизацией. Детали см. в (Perkins and Royer, 2001). Маршрутизация в спе­циализированных сетях — чрезвычайно популярная сегодня область исследова­ний. Вопросам, связанным с ней, посвящено большое количество материалов. Например, (Chen и др., 2002; Ни and Johnson, 2001; Li и др., 2001; Raju and Garcia-Luna-Aceves, 2001; Ramanathan and Redi, 2002; Royer and Toh, 1999; Spohn and Garcia-Luna-Aceves, 2001; Tseng и др., 2001; Zadeh и др., 2002).

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

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

С этим алгоритмом связано несколько проблем, но с ними можно справить­ся. Во-первых, если последовательный номер, достигнув максимально возмож­ного значения, обнулится, возникнет путаница. Решение состоит в использова­нии 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.14. Слева изображена подсеть, посередине —входное дерево для маршру­тизатора I этой подсети. На первом транзитном участке маршрутизатор I посы­лает пакеты маршрутизаторам F, Н, J и N, являющимся вторым ярусом дерева. Все эти пакеты прибывают к I по предпочитаемым линиям (по пути, совпадаю­щему с входным деревом), что обозначается кружками вокруг символов на рис. 5.14, в. На втором этапе пересылки формируются восемь пакетов — по два каждым маршрутизатором, получившим пакет после первой пересылки. Все во­семь пакетов попадают к маршрутизаторам, не получавшим ранее пакетов, а пять из них приходят по предпочитаемым линиям. Из шести пакетов, формируемых на третьем транзитном участке, только три прибывают по предпочитаемым ли­ниям (на маршрутизаторы С, Е и К). Остальные оказываются дубликатами.

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

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

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

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

 

J	'4
2	А
3	4
5	7
9	12
17	20
м
5	7
6	7
8	12
12	12
20	20
/4
13	15
14	15
16	20
20	20
28	1

Таблица указателей узла 1

Таблица указателей узла 4

Таблица указателей узла 12

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

(18;                ......                      (14)

(31)              , . зо.; •••••■ - ц Реальный ,"2g'.                                  / узел                                                  ' (2В)                                     :

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

^Идентификатор (24)                узла (23) (22)

 

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

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

Максимальная пропускная способность подсети

Идеально

Перегрузка

Посланные пакеты

Рис. 5.23. При слишком высоком уровне трафика начинается перегрузка, и производительность сети резко снижается

/

Желательно

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

Надо признать, что форум разработчиков WAP извлек уроки из нестандартного стека протоколов, придуманного для WAP 1.0.

В отличие от первой версии, WAP 2.0 характеризуется стандартными протоколами на всех уровнях. Это каса­ется и вопросов безопасности. Базируясь на IP, он полностью поддерживает все возможности IPsec на сетевом уровне. На транспортном уровне ТСР-соединения можно защитить TLS — стандартом IETF, который мы изучим далее в этой главе. На более высоких уровнях применяется идентификация клиентов в соответст­вии с RFC 2617. Криптографическая библиотека прикладного уровня обеспечи­вает контроль целостности и обнаружение ложной информации. В конечном ито­ге, так как WAP 2.0 базируется на известных стандартах, есть шанс, что услуги защиты, в частности, секретность, идентификация и обнаружение ложной ин­формации, будут реализованы значительно лучше, чем в 802.11 и Bluetooth.