В. Столлингс - Современные компьютерные сети (2-е издание, 2003) (1114681), страница 121
Текст из файла (страница 121)
В этом разде > Трафик в объединенных сетях Трафик в обычнон илн б й илн объединенной сети можно разделить на две болыпне категории: эластичный и неэ и неэластичный. Понимание различий между этими категориями прояс»яет и ходил>ос еоб ил>ость в усовершенствованной архитектуре объединенныхсетой 4 Паутине, обладают высокои чувствительностью к задерж ' ЦГС 16ЗЗ, 1»ген>к»> 5е>гъ е> Ь> йе!п~егпе> Анэнег>игк Л» Ове» >ее шоль 1994. Эластичный трафик Эластичным (е аз >с> называют ( 1 г' ) взывают график, способный приспосабливаться к измене- ниям задержки и про и пропускной способности в широком диапазоне значений, про- должая удовлетворять ь потребности приложения.
Это традиционный тип трафи- ка, поддерживаемыи -сетя и, " 1Р-сетями, и именно лля такого трафика рж>рабатывалнсь . П > ло>кения, создающие подобный трафик, в качестве транс- объединенные сети. р > по тного протокола, как правило, используют протокол ТСР или ППР. В случае протокола 1Л)Р приложение расхолует столь>го ресурсов, сколько имеется в нали- чии, вплоть до скорости, с которой приложение генерирует данные. В случае п ро- токола ТСР приложение расхо ~ ТСР асходует столько ресурсов, сколько имеется в наличии, вплоть до максимальной скорости, с которой оконечный получатель способен при- нимать данные. Кроме того, при использовании прото колаТСРт афик,передавар ф емыи и о отдельным соединениям, реагирует на перегрузку снижением скорости п дачи данных в сеть.
Для этого включаьэтся описывавшиеся в разделе '. е ниэмы отката и затяжного пуска, свяаанные с задержкон " ВТТ (Копн>1-Тг1о Тппе— время распространения сигнала в оба конца). К эластичным приложениям относятся обычные прилож, р ения, аботаюшие с помощью протоколов ТСР и П1)Р, включая передачу ф " файлов (РТР), электрон- (БНМР) ную почту (ЯМТР), удаленную реп>страцию (ТЕ))ч>ЕТ), управление сетью ( ) н доступ к Паутине (НТТР). Требования, предъявляемые ланными приложения- ми, различаются.
+ Электронная почта, как правило, нечувствительна к изменениям задер>кки. + К е едача файлов осуществляется в режиме подключен ия (оп-1>пе), огда пер ка б ет п опоркак это обычно бывает, пользователь ожидает, что задержка удет пр циональна размеру файла, то есть передача файлов чувствительна к скорости передачи данных. + П и п авленин сетью задержка, как правило, це представляет серьезной проблемы.
Однако если неисправности в объединенной сети являются причиной перегрузки, тогла необходимость в прохожде> ии щ " о сооб ений протокола ЯНМР с минимальной задержкой с ростом перегрузки растет. + Интерактивные приложения, такие как удаленная регистр ц а ия и доступ к ке. 530 Глава 17. Интегрированные и дифференцированные службы 17.1. Архитектура интегрированных служб 531 Важно понимать, что особый интерес представляет не задержка отдельных ца кетов. Как отмечается в [53], наблюдения за реальной задержкой в Интернете на водят на мысль о том, что изменений задержки в широком диапазоне не происк дит.
Благодаря механизмам борьбы с перегрузкой, реализованным в протоколе ТСР, когда возникает перегрузка„происходит только умеренное увеличение задеря, ки, после чего скоросп поступления данных от различных ТСР-соединений снгсчс ется. С точки зрения пользователя уровень качества обслуживания определяется и . величиной задержки отдельного пакета, а суммарным интервалом времени, необхо днмым для передачи элемента данного приложения. Для интерактивного ТГ1.~БТ приложения элементом может быть отдельный символ или одна текстовая строка Для веб-браузера элементом является веб-страница, размеры которой могут изме няться в очень широких пределах от нескольких килобайтов до нескольких десятков и сотен килобайтов для страниц с большим количеством графики.
В научных приложениях один элемент может состоять из нескольких мегабайтов данных, Для очень маленьких элементов суммарное время передачи данных в основном состоит из длительности задержки передачи данных по объединенной сети. Однако для больших элементов суммарное время передачи данных зависит от производительности алгоритма скользящего окна протокола ТСР и, следовательно, в основном определяется пропускной способностью ТСР-соединения. Таким образом, при передаче больших обьемов данных время передачи пропорционально размеру файла и степени торможения источника из-за перегрузки.
Должно быть ясно, что даже если ограничиваться голько эластичным графиком, нам была бы весьма полезна какая-нибудь служба поддержания качества обслуживания в объединенной сети. Без такой службы маршрутизаторы одинаково относятся к прибывающим пакетам, не учитывая ни тип приложения, ни то, является ли данный пакет частью большого элемента приложения илн маленького. При таких условиях в случае перегрузки маловероятно, что ресурсы будут распределены так, чтобы справедливо удовлетворить потребности приложений.
А когда к зж~- стичному трафику добавляется незластичный, ситуация еще более усложняется. Неэластичный трафик Неэластичный график Ппе1аз11с гга1йс) плохо приспосабливается, если вообще способен приспосабливаться, к изменениям задержки и пропускной способности обьединенной сети. Примером неэластичного графика является трафнк реального времени, обсуждающийся в разделе 17.5. Неэластичный график предъявляет к обьединенной сети различные требования, среди которых можно назвать следующие+ Пролускная слособность.
Может быть предъявлено требование обеспечения некоторой минимальной пропускной способности. В отличие от большей части приложений эластичного графика, способных продолжать доставку данных, возможно, со сниженным уровнем качества обслуживания, многим неэластичным приложениям абсолютно необходим определенный минимум пропускной способности. + Задержка. В качестве примера приложения, чувствительного к задержкам, можно назвать игру на бирже. Пользователь, постоянно получающий информацию с задержкой, будет постоянно запаздывать в своих действиях, и, следовательно, его действия будут менее успешными. + Флуктуачнл.
Как разъясняется в разделе 17.5, диапазон изменений задержки критически важен для приложений реального времени. Чем больше допустимое изменение задержки, тем больше будет реальная задержка доставки данных и тел» больших размеров потребуются буферы получателей. Интерактивные приложения реального времени, такие как телеконференции, могут требовать разумных ограничений на флуктуацию.
+ Потеря лакелюа. Некоторые приложения реального времени допускают потерю пакетов. Допустимое количество потерянных пакетов может быль разным для разных приложений. Эти требования трудновыполнимы в окружении, в котором имеют место вызванная очередями переменная задержка и потеря пакетов иэ-за перегрузки, Соответственно, неэластичный трафик предъявляет два новых требования к архитектуре объединенных сетей. Во-первых, необходимы определенные средства для предоставления предпочтений прилохсешияы с более высокими пожелш~иями.
Приложение должно иметь возможность заявить о своих пожеланиях либо заранее, с помощью некоторой функции, запрашивающей нужную услугу, либо <на лету», при помощи полей в заголовке 1Р-пакета. Первый подход предпочтительнее. Он предоставляет большую гибкость в пожеланиях, позволяя сети заранее о них узнавать и отказывать в обслуживании, если требуемые ресурсы недоступны.
Этот подход предполагает наличие некоторого протокола резервирования ресурсов. Второе требование, относящееся к поддержке неэластичного графика в архитектуре объединенных сетей, заключается в том, что эластичный график также должен поддерживаться. В отличие от ТСР-приложений, неэластичные приложения, как правило, не снижают требований в случае перегрузки. Поэтому при перегрузке неэластичный трафик будет продолжать оказывать высокое давление на объединенную сеть, и эластичный трафик окая<ется просто вытесненным. Протокол резервирования ресурсов может помочь справиться с ситуацией, отказывая в обслуживании запросов, если в случае их обслуживания в объединенной сети останется слишком мало ресурсов для эластичного графика.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
