Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Управление потоком данных




Контроль за перегрузками

Контроль за перегрузками в сетях IP достаточно сложно реализовать по целому ряду причин. К ним можно отнести следующие:

q Протокол IP не ориентирован на установление соединения. Он не обеспе­чивает обнаружение перегрузки и по этой причине не может быть исполь­зован для контроля за перезагрузками.

q Протокол TCP осуществляет контроль потока из конца в конец соедине­ния и может лишь по косвенным признакам определить перегрузку в сети. Более того, так как задержки в распределенных сетях постоянно изменя­ются, то информация, полученная на основании косвенных признаков (на­пример, размер окна), не является достоверной.

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

Сообщение «Подавление источника» (Source Quench) протокола ICMP мож­но рассматривать в качестве грубого инструмента, предназначенного для сдер­живания потока трафика от отправителя, но его нельзя назвать эффективным методом контроля за перегрузками.

Задачу контроля за перегрузками можно возложить на протокол RSVP, но его широкое распространение — еще вопрос времени.

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

 

Управление потоком данных использует механизм плавающего окна, но кроме этого, применяется также более гибкая схема приема/передачи данных и отсыл­ки подтверждений на успешный прием данных. Управление потоком протокола TCP использует так называемую схему с выделением лимита на передачу дан­ных. По этой схеме каждый передаваемый байт имеет свой собственный номер в последовательности (SN). Когда протокол TCP посылает сегмент, он выстав­ляет в поле номера в последовательности номер первого байта в поле данных этого сегмента. На принимающей стороне пришедший сегмент подтверждается сообщением, в котором указывается (А = i, W=j). Такая запись имеет следующее значение: если величина А (АСК) равна г, это значит, что сообщение подтверж­дает получение всех байтов, вплоть до номера в последовательности i—1; сле­дующие ожидаемые байты имеют номер в последовательности i. Кроме того, выдается разрешение на посылку дополнительного окна W (Window) из j байтов; то есть байтов с номерами в последовательности от i до i +j - 1. На рис. 7.10 иллюстрируется работа этого механизма. В отличие от рис. 7.9, окна передачи и приема указывают количество байтов данных.

 

 

Для большей наглядности покажем поток данных, идущий только в одном направлении, и предположим, что в каждом сегменте посылаются 200 байт дан­ных. Во время установления соединения номера в последовательностях отпра­вителя и получателя синхронизированы и станция А имеет начальный лимит на отсылку данных 1400 байт, начиная с номера байта 1001. После посылки 600 байт в трех сегментах станция А уменьшает свое окно отсылки до 800 байт (номера с 1601 до 2400). После получения этого сегмента станция В подтверж­дает получение всех байтов, вплоть до 1601, и формирует свое окно приема на 1000 байт. Это означает, что станция А может посылать байты, начиная с номера 1601 и заканчивая номером 2600, то есть пять сегментов. Однако к тому момен­ту, когда сообщение от станции В доходит до станции А, последняя уже успела выслать два сегмента, содержащие байты 1601-2000, что позволял начальный лимит. Следовательно, оставшийся лимит станции А на этот момент составляет всего 400 байт или два сегмента. Во время обмена станция А продвигает левую границу своего окна каждый раз, когда осуществляет передачу. Правая граница передвигается только тогда, когда станция получает новый лимит.

На практике обе стороны одновременно задействуют режимы передачи и приема, так как данные могут передаваться в обоих направлениях (происходит полнодуплексная передача). Механизм выделения лимита является достаточно гибким. Например, рассмотрим ситуацию, при которой последнее сообщение, посланное станцией В, было (A=i, W=j). Последним байтом данных, получен­ным станцией В, был байт с номером i -1. Для увеличения лимита до значения k, при условии, что kj и дополнительные данные не поступали, станция В фор­мирует сообщение (A= i, W= k). Для подтверждения входящего сегмента, содер­жащего т байт данных (т) без выделения дополнительного лимита, станция В формирует сообщение (A =i+m, W =j-m).

Следует отметить, что от получателя не требуется немедленного подтвержде­ния приходящих сегментов. Он может ожидать некоторое время, а затем сфор­мировать подтверждение сразу на несколько сегментов. Получатель должен проводить какую-то политику, регулирующую количество данных, которое он позволяет передавать отправителю. Можно выделить две политики получателя: консервативную и оптимистическую. Консервативная схема управления пото­ком основана на том, что лимит выделяется в соответствии с имеющимся до­ступным буферным пространством. Если это правило применить к ситуации, показанной на рис. 7.10, то первое лимитирующее сообщение говорит о том, что станция В может разместить 1000 байт в своем буфере, а второе — о том, что станция В может разместить 1400 байт. Консервативная схема управления пото­ком может ограничить пропускную способность логического соединения в ситу­ации, когда в сети возникают большие задержки.

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

 




Поделиться с друзьями:


Дата добавления: 2015-07-13; Просмотров: 731; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.008 сек.