Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 120
Текст из файла (страница 120)
Например, подсеть может использовать телефонные линии с модемами, чтобы увеличить пропускную способность меж- МУ определенными точками. В спутниковых системах болыпую пропускную спо- 449 Глава б. Сетевой уровень Стратегии предотвращения перегрузки Начнем изучение методов борьбы с перегрузкой с систем без обратной связи. Эти системы разработаны в первую очередь для предотвращения перегрузки, а не для борьбы с уже имеющей место перегрузкой. Они пытаются достичь своей цели, используя соответствующие стратегии на разных уровнях. В табл. 5.2 показаны различные стратегии уровней передачи данных, сетевого и транспортного, способные влиять на перегрузку [1621.
Таблица 6.2. Стратегии предотвращения перегрузки Уровень Стратегии Транспортный Политика повторной передачи Политика кэширования пакетов, приходящих в неверном порядке Политика подтверждений Политика управления потоком Определение тайм-аутов Виртуальные каналы против дейтаграмм в составе подсети Политика очередей пакетов и обслуживания Политика игнорирования пакетов Алгоритм маршрутизации Управление временем жизни пакетов Политика повторной передачи Политика кэширования пакетов, приходящих в неверном порядке Политика подтверждений Политика управления потоком Сетевой Передачи данных собность часто дает увеличение мощности передатчика. Распределение трафика по нескольким маршрутам вместо постоянного использования одного и того же, пусть даже оптимального пути также может позволить ликвидировать местную перегрузку. Наконец, для увеличения пропускной способности сети в случае серьезных заторов могут быть задействованы запасные маршрутизаторы, которые обычно применяются для повышения устойчивости системы в случае сбоя.
Однако иногда увеличить пропускную способность бывает невозможно либо она уже увеличена до предела. В таком случае единственный способ борьбы с перегрузкой состоит в уменьшении нагрузки, Для этого существует несколько способов, включая отказ в обслуживании илн снижение уровня обслуживания некоторых или всех пользователей, а также составление более четкого расписания потребностей пользователей в обслуживании. Некоторые из этих методов, которые будут кратко рассмотрены далее, лучше всего применимы к виртуальным каналам. В подсетях, основанных на использовании виртуальных каналов, эти методы могут применяться на сетевом уровне.
В дейтаграммных подсетях они иногда также могут применяться в соединениях транспортного уровня. В данной главе основное внимание будет уделено применению методов борьбы с перегрузкой на сетевом уровне. В следующей главе мы обсудим, что можно сделать на транспортном уровне.
Алгоритмы борьбы с перегрузкой 449 Качнем рассмотрение различных стратегий с уровня передачи данных. Стратегия повторной передачи определяет, насколько быстро у отправителя истекает время ожидания подтверждения и что он передает после того как время ожидания истекло. Нетерпеливый отправитель, у которого время ожидания истекает слишком быстро и который повторно посылмт все неподтвержденные пакеты с помощью алгоритма возврата на я, окажет более сильную нагрузку на сеть, нежели ленивый отправитель, использующий выборочный повтор. Тесно связана с этим стратегия кэширования.
Если получатели просто игнорируют все пакеты, приходящие не в том порядке, то все проигнорированные пакеты придется передавать позднее еще раз, что окажет дополнительную нагрузку на сеть. Стратегия подтверждений также влияет на перегрузку. Если каждый пакет немедленно подтверждается получателем, то пакеты с подтверждениями образуют дополнительный трафик. Однако если подтверждения добираются обратно «верхом» на попутном потоке кадров, то количество графика в сети снижается, зато увеличивается среднее время получения подтверждений, что может, в свою очередь, вызвать увеличение повторно переданных пакетов вследствие истечения времени ожидания подтверждений. Более жесткая схема управления потоком (например, с небольшим размером окна) уменьшает скорость передачи данных и помогает бороться с перегрузкой.
Существует также зависимость перегрузки от того, является ли сетевой уровень дейтаграммным или он основан на виртуальных каналах, так как многие алгоритмы борьбы с перегрузкой работают только в подсетях с виртуальным каналами. Политика очередей пакетов и обслуживания определяет количество очередей у каждого маршрутизатора — например, одна общая очередь для всех линий, или по очереди для каждой линии, или какой-нибудь комбинированный вариант. Она также определяет порядок обработки пакетов (например, поочередно пли в порядке приоритетов).
Политика игнорирования пакетов является правилом, определяющим набор пакетов, подлежащих отвержению, когда не хватает памяти. Хорошо продуманная стратегия может облегчить симптомы перегрузки, тогда как неудачная политика может даже ухудшить ситуацию. Хороший алгоритм выбора маршрута может помочь избежать локальной пеРегрузки, перераспределяя трафик по всем линиям, тогда как неудачный алгоРитм может направить слишком большое количество пакетов по одной линии и вызвать затор.
Наконец, управление временем жизни пакетов, определяет, как долго пакет может перемещаться по сети, прежде чем он будет проигнорирован очередным маршрутизатором. Если зто время слишком велико, то потерянные пакеты могут засорять собою сеть, однако если время жизни пакета слишком мало то пакеты не будут успевать достичь адресата, что приведет к необходимости повторных передач. На транспортном уровне применяются те же стратегии, что и на уровне переда"н данных, но к ним добавляется еше и проблема определения времени ожидания подтверждения, что на транспортном уровне осуществить значительно сложнее, нескольку время пересечения всей сети предсказать значительно сложнее, чем время передачи пакета от какого-либо маршрутизатора до его соседа. Если этот Ж~тервал слишком короток, будут высылаться излишние повторные пакеты, 450 Глава 5.
Сетевой уровень авели слишком велик — перегрузка снизится, но увеличится задержка в случае потери пакета. Борьба с перегрузкой в подсетях виртуальных каналов Описанные ранее методы борьбы с перегрузкой в основном являются методами без обратной связи: они в первую очередь пытаются предотвратить перегрузку, а не занимаются устранением уже возникшей перегрузки. В данном разделе мы опишем несколько подходов к динамическому управлению перегрузкой в подсетях виртуальных каналов. В следующих двух разделах будут описаны методы, применимые в любой подсети, Широко применяемым методом недопущения ухудшения уже начавшейся перегрузки является управление допуском.
Идея этого метода проста: когда приходит сигнал о перегрузке, никакие новые виртуальные каналы не создаются до тех пор, пока проблема не разрешится. То есть любые попытки установить новые соединения транспортного уровня пресекаются. Понятно, что если пустить в сеть, в которой уже возникла перегрузка, дополнительных пользователей, то ситуация только ухудшится, Хотя такой метод несколько прямолинеен и не эстетичен, зато он дешев, надежен и практичен. В обычных телефонных системах этот метод тоже широко применяется: когда коммутатор оказывается перегруженным, вы поднимаете трубку и не слышите гудка, Альтернативный подход заключается в том, что создание новых виртуальных каналов разрешается, но зти каналы тщательно прокладываются в обход заторов.
Для примера рассмотрим подсеть, показанную на рис. 5.24, в которой два маршрутизатора перегружены. Перегрузка е б рно. 6.24. Перегруженная подсеть (а); та же подсеть с устраненной перегрузкой (6). Показан виртуальный канал между Я и В Предположим, что хост, соединенный с маршрутизатором А, хочет установить соединение с хостом, соединенным с маршрутизатором В. В нормальных условиях это соединение прошло бы через один из перегруженных маршрутизаторов. Чтобы этого избежать, подсеть усекается, как показано на рис. 5.24, б. При Алгоритмы борьбы с перегрузкой 451 этом из нее удаляются перегруженные маршрутизаторы и все их линии связи, Пунктирной линией показан возможный маршрут виртуального канала в обход перегруженных маршрутизаторов. Другая стратегия, связанная с виртуальными каналами, состоит в достижении соглашения между хостом и подсетью во время установки виртуального канала.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
