В. Столлингс - Современные компьютерные сети (2-е издание, 2003) (1114681), страница 81
Текст из файла (страница 81)
Однако з 8 Э $ кк о л 4 И 1 2 3 4 5 6 7 8 9 1011121314151617181920 Время Рио. 12.5. Пример экспоненциального сглаживания 12.1. Управление потоком в протоколе ТСР 36З определенные аспекты протокола предполагают несколько возможных вариантов реализации. Хотя два разных варианта реализации протокола могут работать совместно, но возможны проблемы с производительностью. Области проектирования, для которых указаны параметры политики, следующие: + передача; + доставка; + прием; + повторная передача; + подтверждение. Политика передачи В отсутствии данных, помеченных флагом РПБН, и при закрытом окне передачи передающая ТСР-сушность может передавать данные так, как ей удобнее, Поступившие от пользователя данные накапливаются в буфере передачи.
Протокол ТСР может сформировать сегмент для каждого пакета данных, предоставляемого пользователем, или подождать, пока не накопится определенный объем данных. Применяемая политика зависит от соображений производительности. При передаче данных большими порциями накладные расходы минимнзируются. С другой стороны, если данные передаются часто и понемногу, минимизируется время отклика системы. Опасность частой передачи небольшими порциями известна как синдром «глупагоь окна (ем. задания 12.6 и 12.7).
Политика доставки В отсутствии данных, помеченных флагом РПКСН, принимаюшая ТСР-сушнасть может доставлять данные пользователю так, как ей удобнее. Она может доставлять их сразу, как только прибудет новый, поступивший в порядке очереди, сегмент данных, или накапливать полученные сегменты в приемном буфере. Применяемая политика зависит от соображений производительности. При доставке данных пользователю большими порциями пользователь получает данные с некоторым опозданием. С другой стороны, если данные доставляются пользователю часто н небольшими порциями, могут возникнуть излишние затраты на обработку данных как в самом протоколе ТСР, так и программном обеспечении пользователя, а также излишний рост числа прерываний операционной системы. Политика приема Когда все данные по ТСР-соединению прибывают в правильном порядке, протокол ТСР помещает их в буфер приема для доставки пользователю.
Однако сегменты могут прибывать в неверном порядке. В этом случае у приннмаюшей ТСР-сушности есть два варианта действий: + Прием ло порядку. Принимаются только те сегменты, которые прибывают в правильном порядке; любой сегмент, прибывающий с нарушением порядка, отбрасывается. + Прием в окне. Принимаются все сегменты, попадающие в приемное окно. 364 Глава 12.
Управление графиком в протоколе ТСР 12 2 Борьба с перегрузкой в ТСР 365 Политика приема по порядку проще в реализации, но она оказывает доно „„ тельную нагрузку на сетевос оборудование, поскольку после истечения период ожидания подтверждения отправляющая ТСР-су~цность должна повторить пере дачу сегментов, успешно доставленных, во отброшенных как прибывшие в назер ном порядке. Более того, если при передаче один из сегментов будет поврюхде придется передавать еще раз все последующие сегменты. Политика приема сегментов, попадающих в окно, может снизить количество передач, но требует более сложных алгоритмов приема и хранения данных.
Политика повторных передач Протокол ТСР поддерживает очередь сегментов, которые были переданы, но получение которых еше нс было подтверждено. В спецификации протокола ТСР утверждается, что ТСР передает сегмент повторно, если не получает подтверждения в установленный срок. В реализации протокола ТСР может использоваться одна из трех стратегий повторных передач: + Повторная передача только первого сеьвеита, Поддерживается один таймер для всей очереди. Если получается подтверждение, соответствующий сегмент или сегменты удаляются из очереди, а таймер переустанавливается. Если период ожидания истекает, сегмент в начале очереди передается повторно, а таймер переустанавливается.
+ Пакетная повторная передача. Поддерживается один таймер для всей очереди. Если приходит подтверждение, соответствующий сегмент нли сегменты удаляются иэ очереди, а таймер переустанавливается. Если период оэкидания истекает, все сегменты, стоящие в очереди, передаются повторно, а таймер переустанавливается. + Индивидуальная повторная передача. Поддерживается по одному таймеру для каждого сегмента в очереди. Если приходит подтверждение, соответствующий сегмент или сегменты удаляются из очереди и переустанавливается соответствующий таймер или таймеры. Если любой период ожидания истекает, соответствующий сегмент передается повторно, а его таймер переустанавлнвается. Политика повторной передачи только первого сегмента эффективна с точки зрения формируемого ею трафика, так как заново передаются исключительно потерянные сегменты (нли сегменты, чьи подтверждения потеряны).
Однако поскольку таймер для второго сегмента в очереди не устанавливается до тех пор, пока не будет получено подтверждение для первого сегмента, при работе данной схемы могут иметь место существенные задержки. Эта проблема решается при помошн индивидуальной политики за счет усложнения реализации. Пакетная политика также снижает вероятность появления длительных задержек, но может привести к излишним передачам. Фактическая активность политики повторных передач частично зависит от политики приема у получателя. Если получатель использует политику приема сегментов в порядке очереди, тогда он будет отбрасывать сегменты, полученные после потерянного сегмента.
Такая стратегия лучше всего соответствует пакетной политике повторных передач. Если получатель использует политику приема сег- ментов, попадающих в окно, тогда ей лучшей всего соответствует политика повторных пе ых передач. Разумеется, в смешанной компьютерной сети могут применяться обе политики приема сегментов. Политика подтверждения Когда прибывает сегмент данных, у получающей ТСР-сушности есть две возмо>кности действий, касающихся времени отправки подтверждения: + Немедленное подтверждение.
При приеме ланных сразу же передается пустой (без данных) сегмент, содержаший соответствующий номер подтверждения. + Кумуллтивяое подтверждение. При получении данных ТСР-сушность делает себе на память заметку о необходимости отправки подтверждения, но ждет, пока не будет передаваться исходяший сегмент данных, вместе с которым можно это подтверждение отправить. Во избежание долгих задержек устанавливается 'таймер окна. Если период ожидания истекает прежде, чем отправлено подтверждение, передается пустой ссгыеггг, содержащий соответствуюШий номер подтверждения.
Политика немедленного подтверждения проста в реализации, кроме того, она обеспечивает позпгую информированность отправляющей ТСР-сущности, благодгаэя чему снижается количество лишних повторных передач. Однако применение данной политики приводит к передаче дополнительных сегментов (а имешю пустых сегментов, используемых только для подтверждений). Кроме того, эта политика может привести к увеличению нагрузки на сеть. Допустим, ТСР-сушность получает сегмент и тут же передает подтверждение.
В этом случае данные в сегменте доставляются приложению, ксггорое расширяет приемное окно, генерируя другой пустой ТСР-сегмент, предоставляющий дополнительный кредит передающей ТСР-сущности. Так как политика немедленного подтверждения потенциально связана с накладными расходами, как правило, на практике используется кумулятивное подтверждение. При использовании этой политики на принимающей стороне требуется дополнительная обработка, а также усложняется задача оценки времени распространения сигнала в оба конца для передаюшей ТСР-сущности.
12.2. Борьба с перегрузкой в ТСР Перегруака в обычной или объединенной сети создает очевидные проблемы для оконечных систем: приводит к снижению коэффициента готовности и пропускной способности, а также к увеличению времени отклика. В коммутируемой сети. например в сети с коммутацией пакетов или в сети ретрансляции кадров, может использоваться динамическая марпгрутизация для уменьшения перегрузки путем ем более равномерного перераспределения нагрузки между коммутаторами и каналами.
Аналогично, применяемые в объединенных сетях алгоритмы маршрутизации могут перераспределить нагрузку между мультипропессорами и сетями, чтобы уменьшить перег уэг,у. Однако эти меры эффективны только для несбалансированной нагрузки р З66 Глава 12. Управление графиком в протоколе ТСР и кратковременных всплесков графика. Наконец, перетру кой з можно управлять, только ограничивая общий объем данных, поступаюши . б ступаюших в о ъединенную сеть В этом состоит основная цель всех механизмов борьбы с перег Бо ьбас п р ы с перегрузкои, орь а с перегрузкой в объединенной сети, основанной на прот протоколах ТОР « 1Р, представляет собой сложную проблему, исследование ~ о ~ие которои в течение не- скольких десятков лет породило множество экспериментальны ных реэлизагшй и опуб ликованных статей. Сложность этой проблемы обусловлена сл рами: ловлена следующими факто + Протокол 1Р не требует соединений и не хранит информацию о своем состоянии, а потому не имеет средств обнаружения перегр е е узки и предоставляет очень мало средств борьбы с нею.
+ Протокол ТСР обеспечивает только сквозное управление поток О отоком. н позволяет догадаться о наличии перегрузки в промежуточных объединенных сетях только с помошью косвенных средств. Кроме того, о о, поскольку время задержки в обычной или объединенной сети непостоянно и мож б иможет ытьдлительным (относительно размера сегмента), знание сост е состояния сети, которым обладает ТСР-сущность, представляется ненадежным. + Не существует кооперативного распределенного алгоритма, связывакнцего вместе различные ТСР-сущности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
