В. Столлингс - Современные компьютерные сети (2-е издание, 2003) (1114681), страница 130
Текст из файла (страница 130)
Этти пакеты пролускаготся через объединенную сеть и доставляются на мушьтимедийный персональный компьютер, воспроизводяп!ий этот аудиосигнал в режиме реального времени сразу, когда пакеты прибывают. Однако поскольку объелиненная сеть задерживает передаваемые по ней пакеты на непостоянные интервалы времени, пакеты не будут прибывать через фиксированные интервалы времени в 20 мс. Чтобы компенсировать неравнолгерность поступления данных, входящие пакеты буферизируются, слегка задерживаются, а затем с постоянной скоростью передаются программному обеспечению, воспроизводящему звук.
Возможности компенсации при помощи буфера ограничены. Чтобы понять это, нам нужно дать определение понятию флуюпуат1ии задержки (с1е!ау )йвег), под которой понимается максимальное изменение величины задержки пакетов в течение одного сеанса. Например, если минимальная сквозная задержка каждого пакета равна 1 мс, а максимальная задержка — 6 мс, тогда флуктуация задержки равна 5 мс. До тех пор пока буфер задерживает входящие пакеты, по меньшей мере, на 5 мс, в выходной поток буфера попадут все входящие пакеты. Однако если буфер задерживает пакеты только на 4 мс, тогда любой пакет, запвздываюшийг относительно остальных пакетов более чем на 4 мс (с абсолютной задержкой более 5 мс), отбрасывается, так как пакеты нельзя воспроизводить в неверном порядке.
Описание трафика реального времени подразумевает последовательность пакетов равного размера, генерируемых с постоянной частотой. Данное описание не всегда соответствует профилю графика. На рис. 17.15 показаны некоторые возможные варианты. + Источник монопюлпмх данных, Пакеты фиксированного размера генери руются через фиксированные интервалы времени. Такая характеристика соответствует приложениям, непрерывно генерирующим данные, обладающие невысокой избыточностью и слишком важные, чтобы применять к ним алгоритм сжатия с потерями. Среди примеров можно назвать данные 17.5.
Трафик реального времени 565 радара, управляющего движением самолетов, а также снмуляторы регшь- ного времени. + Двухпола1ионный истпочгпгк. Периоды активности источника, в течение которых он генерирует пакеты фиксированного размера через фиксированные интервалы времени, чередуются с периодами бездействия. Данному профилю соогветствуег такой источник, как телефонный аппарат или аудиоконференция. + Источник пакетов переменного размера. Источник генерирует пакеты переменного размера через равные интервалы времени.
Примером такого источника данных является оцифрованное видео, в котором разные пакеты могут быть сжаты с разным коэффипиентом сжатия при одном и том же уровне качества выходных данных'. Источник монотонных данных Источник голосового сигнала с паузами Источник сжатого видеосигнала 566 Глава 17. Интегрированные н дифференцированные службы Рие. 17.15. Передача пакетов рвапьнога аремени 1по [З)) Требования к взаимодействию в реальном времени В [81 перечисляются следуклцие желательные свойства взаимодействия в реальном временгк + небольшая флуктуация; + неболыпая задержка; + способность легко объединять службы реального времени с прочимп службами; + адаптируемость к динамически изменяющимся условиям сети и графика; + хорошая производительность в больших сетях, а также при большом количестве соединений; + скромные требования к размерам буферов в сети; + высокий коэффициент использования сети; + низкие накладные расходы в битах заголовка иа пакет; + низкие расходы на обработку в сети и на оконечных системах в единицах обработки на пакет.
Эти требования трудно выполнить в глобальной или объединенной 1Р-сети. Протоколы ТСР и 1Л) Р сами по себе пе соответствуют данным требованиям. Как мы увидим, разумную основу для их решения предоставляет протокол КТР. Жесткие и гибкие приложения реального времени Следует разграничить жесткие и ггтбкие приложения реального времени. Гибкие приложения реального времени могут выдержать потерю некоторой части данных, 17,6. Рекомендуемые литература и веб-оайты 667 тогда как жесткие приложения реального времени не допускают потери данных. В общем, гибкие приложения реального времени предъявляют меныпие требования к сети и поэтому допускают оптимизапию использования сети даже за счет потери некоторых пакетов или доставки некоторых пакетов в неверном порядке. В жестких приложенггях реального времени сообрзжеттгия относительно соответствия трафика ограничениям на флуктуацию и соображения относительно его высокой надежности преобладают над проблемой оптимизации использования сети.
17.6. Рекомендуемые литература и веб-сайты Возможно, самое понятное и наиболее всеобъемлющее описание материала данной главы — это [131. В [2051 содержится прекрасный анализ логического обоснования архитектуры объединенных сетей, основанной на дифференцированном обслуживании. В [241~ предоставляются обзор и общая система взглядов относительно качества обслуживания в Интернете, а также интегрированных и дифференцированных служб.
Вполне доступное для читателя обозрение многих вопросов, относящихся к предоставлению обслуживания с гарантированным качеством в Интернете, содержится в [741, КРС 1633 представляет собой определяющий для архитектуры интегрированных служб документ, в котором содержится прекрасный обзор данной темы. В [521 и [531 обсуждаются вопросы обслуживания в объединенных сетях приложений реального времени, а также эластичных приложений соответственно. [236] представляет собой подробный обзор архитектуры интегрированных служб. Книга [2461 посвящена теме дисциплин очередей, которые могут применяться в архитектуре ! БА, включая аналнз схем справедливой организации очередей ЕЯ и ЪЧЩ. В [52) имется анализ схемы ЪУЩ, а также некоторых альтернативных дисциплин. В [841 рассматривается проблема влияния на возможность перегрузки растущего трафика, обслуживаемого с максимальными усилиями (по остаточному принципу), для которого не применяются механизмы борьбы с перегрузкой протокола ТСР, а также меры, которые могут предпринимать маршрутизаторы, вклточая стратегии организации очередей и отбрасывания пакетов, обсуждавшиеся в данной главе.
В [233) содержится поучительное обсуждение дифференцированных служб, тогда как в [1421 рассматриваются дифференцированные службы и механизмы поддержки маршрутизаторов, не описанные в текущих документах КРС. Детальное обсуждение дифференцированных служб имеется в [1351.
Две статьи, в которых сравниваются интегрированные и дифференцированные службы в терминах обслуживания и производительности, — это [271 и [1121. Рекомендуемые веб-сатйты перечислены ниже: + Яо5 Готттпт. Сайт группы, производящей самое разнообразное оборудование. Посвящен продвижению стандартов качества обслуживания, относящихся к Интернету.
Включает полезные ответы на часто задаваемые вопросы и массу технической документации. Глава 17. Интегрированные и дифференцированные службы 17.7. Задания 669 17.7. Задания 1. 2. 3. 17(Оегенггагег7 эегэ1сеэ геогЫнй дгсир. Сайт рабочей группы, созланной с раз решения 1ЕТЕ для разработки сгапдартов, относящихся к дифференцнро ванным службам. Включает все относящиеся к данной теме документы ВЕС а также проекты Интернет-документов. Тпгеб агеИэетисеэ гесгй(лйроир.
Сайт рабочей группы, созданной с разреп, ния 1ЕТЕ для разработки стандартов, относящихся к интегрированным службам. Включает все относящиеся к данной теме документы ВЕС, а так же проекты Интернет-документов. Стандарт 1Рчб утверждает, что если на маршрутизатор прибывает пакет с ненулевой меткой потока, а у маршрутизатора нет информации для этой метки потока, тогда маршруп~затор должен игнорировать метку потока и переправить пакет. а) каковы недостатки обработки данного события как ошибки, отбрасывания пакета н передачи 1СМР-сообщения; б) существуют ли ситуации, в которых маршрутизация пакета, как если бы его метка потока была нулевой, приведет к неверному результату? Аргументируйте свой ответ.
Механизм управления потоком 1Рчб предполапгет, что информация о состоянии, ассоциированная с данной меткой потока, хранится на маршрутизаторах, так что маршрутизаторы знают, как обрабатывать пакеты с данной меткой потока. Стандарт требует удалять информацию о метках потока, которые более не используются (устаревшнх метках потока). а) предположим, что, заканчивая работу с потоком и удаляя метку потока, источник всегда посылает управляющее сообщение всем маршрутизаторам, которых зто касается.
Как могла бы в этом случае сохранптьгя устаревшая метка потока; б) предложите механизмы для маршрутизатора и источника, позволяющие решить проблему устаревших меток потока. Возникаег вопрос, какие пакеты, генерируемые источником, должны нести ненулевые метки протокола 1Рчб. Для некоторых приложений ответ очевиден. При обмене небольшими порциями данных пакеты должны иметь нулевые метки, так как не имеет смысла создавать потоки для нескольких пакетов.
Снабжаться метками должны потоки реального времени, для которых, в первую очередь, и создавались метки потоков. Более сложный вопрос заключается в том, что делать с хостами, посылающими большие объемы графика, обслуживаемого по остаточному принципу (нацример, ТСР-соелинений). Приведите доводы в пользу назначения каждому долгосрочному ТСР-соединению уникальной метки потока.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
