Управління потоком, контроль за перевантаженням і повільний старт у протоколі TCP 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Управління потоком, контроль за перевантаженням і повільний старт у протоколі TCP



TCP пробує здійснити найкраще можливе використання основних мереж, висилаючи дані з найвищою можливою швидкістю, яка не викликає втрату пакетів. До цього відносяться два аспекти: управління потоком та контроль за перевантаженням.

Управління потоком. Якщо два протоколи TCP включені у сполучення, то кожен з них обслуговує для сполучення приймальне вікно, пов’язане з розміром його приймального буфера. Для TCP A – це максимальна кількість байтів, яку TCP B може прийняти від A перед блокуванням та очікуванням підтвердження. Всі сегменти TCP мають поле window (вікно), яке вживається для інформування іншого TCP про розмір вікна для приймання сегментів від висилача. Це називають оголошенням розміру вікна. В будь-який момент часу, наприклад, TCP B може мати багато висланих, але не підтверджених сегментів, до заповнення вікна, оголошеного TCP A.

Уникнення перевантаження та контроль. Коли сполучення встановлене, то спочатку протоколи TCP нічого не знають про можливу швидкість або перепускну здатність мереж, які їх сполучають. Вбудований алгоритм “повільного старту” контролює швидкість, з якою початково висилаються сегменти, доки ці TCP визначать значення часу обігу петлі (Round Trip Time – RTT) та його змінність. TCP також повільно збільшує кількість висланих сегментів, бо це покращує використання мережі. Кожен TCP в Internet пробує повністю використати наявні мережі, збільшуючи кількість висланих пакетів, які ще непідтверджені. Остаточно досягається пункт, коли сумарний трафік у певній частині мережі перевищує місце в буфері одного або декількох раутерів, і тоді сегменти втрачаються. Коли TCP робить паузу і повторно висилає втрачені сегменти, він робить це як вказівку, що він та інші TCP занадто завантажили мережу. TCP негайно зменшує своє вікно перевантаження до малого значення і дуже повільно дозволяє збільшення, якщо підтвердження отримані. Управління перевантаженням досі є гострою проблемою в Internet.

Обсяги пересилання TCP. Мета цього застосування полягає в максимізації ефективності пересилання даних. Це означає, що TCP повинен досягнути пункту динамічної рівноваги максимаольної ефективності мережі, коли швидкість пересилання даних максимальна і відсутні тривалі втрати пакетів. Подальше збільшення швидкості висилання може викликати ризик перевантаження в мережі з раптовим підвищенням рівня втрати пакетів. Це, у свою чергу, може змусити протокол TCP повторно висилати втрачені пакети, що веде до зменшення ефективності пересилання даних. З другого боку, намір повністю вилучити втрати пакетів веде до того, що надавач мусить зменшити швидкість висилання даних у мережу аж до того рівня, коли не створюються навіть нетривалі перевантаження взовж шляху до приймача. При цьому наявні мережеві ресурси використовуються неефективно.

Поняття пункту динамічної рівноваги важливе, бо завданням TCP є координація дій надавача, мережі та приймача таким чином, щоб шлях у мережі мав достатньо даних, але не наступало перевантаження. Обслуга пункту динамічної рівноваги вимагає синхронізації надавача і приймача так, щоб надавач висилав пакети в мережу точно в той сам момент, коли приймач видаляє пакети з мережі. Порушення цієї вимоги веде до недовантаження або перевантаження мережі і ефективність пересилання в обидвох випадках зменшується. TCP використовує протокол ковзного вікна (sliding window protocol) для підтримки пересилання даних у великому обсязі (рис. 3.92).

 
 

Рис. 3.92. Ковзне вікно TCP.

Приймач оголошує надавачу наявний розмір буфера у приймача. Надавач може висилати дані до цього обсягу, перш ніж очікувати на подальшу модифікацію буфера від приймача. Надавач не може висилати дані в мережу понад цей обсяг. Він повинен також буферизувати вислані дані, доки вони не будуть підтверджені приймачем. Вікно висилання дорівнює мінімуму від розміру буфера надавача і оголошеного вікна приймача. У кожен момент, коли прийняте підтвердження, задній край вікна вікна пересилання просувається вперед. Мінімум від розмірів буфера надавача і оголошеного вікна приймача використовується для обчислення положення нового переднього краю вікна. Якщо вікно висилання містить невислані дані, то ці дані можна вислати негайно.

Розмір буфера (вікна) TCP у кожній станції вирішально визначає обмеження характеристик у глобальних мережах. Протокол здатний пересилати одне вікно даних за часовий інтервал обігу петлі. Наприклад, якщо вікно висилання має 4096 байтів, а інтервал обігу петлі (Round Trip Time – RTT) для шляху пересилання становить 600 мс, то сесія TCP здатна підтримувати максимальну швидкість пересилання 48 кбіт/с незалежно від ширини смуги мережевого шляху. Максимальна ефективність пересилання досягається тільки тоді, коли надавач здатний повністю заповнити мережевий шлях даними. Оскільки надавач може мати певний обсяг даних для висилання і еквівалентний обсяг даних, які очікують на підтвердження, то як буфер надавача, так і оголошене вікно приймача не повинні бути меншими, ніж це визначене такою формулою:

Розмір вікна (байт) ³ ширина смуги (байт/с) ´ RTT (с)

16-бітове поле в заголовку TCP може містити значення до 65535, визначаючи верхню межу наявного розміру вікна у 65535 байтів. Це встановлює верхню межу характеристик TCP на 64 кбайтів за період RTT, навіть якщо обидві прикінцеві системи мають довільно довгі передавальний і приймальний буфери. Це обмеження може бути модифіковане використанням опції масштабування вікна, описаної в RFC 1323, ефективно збільшуючи розмір вікна до 30-бітового поля, однак з пересиланням тільки значення перших найбільш значимих 16 бітів. Це дозволяє надавачу і приймачу використовувати розміри буферів, які дозволяють ефективно працювати зі швидкостями, що охоплюють більшість наявних високошвидкісних мережевих технологій, на відстанях масштабу наземних міжконтинентальних кабельних систем.

Хоч максимальний розмір вікна і RTT разом визначають максимальну досяжну швидкість пересилання даних, однак необхідний додатковий елемент управління потоком для TCP. Якщо сесія TCP починає вводити повне вікно даних в мережу, то існує велика ймовірність того, що великий початковий обсяг даних буде втрачений внаслідок тимчасового перевантаження, особливо при великому розмірі вікна. Замість цього TCP використовує більш поміркований підхід, стартуючи з меншим обсягом даних, що дає високу ймовірність упішного пересилання, а потім зондує мережу, збільшуючи обсяг даних, доки мережа не виявить ознак перевантаження. Коли перевантаження виявиться, то швидкість пересилання зменшується і випробування на додаткову перепускну здатність повторюється.

Динамічне оперування вікном є вирішальною компонентою продуктивності TCP при пересиланні інформації. Механіка протоколу включає додатковий пріоритетний модифікатор вікна надавача – вікно перевантаження (congestion window); модифікатор скорочено позначають cwnd. Метою алгоритму управління вікном є старт пересилання зі швидкістю, яка забезпечує дуже малу ймовірність втрати пакетів, потім збільшення швидкості шляхом збільшення розміру вікна перевантаження, доки надавач не отримає вказівку (внаслідок виявлення втрати пакетів), що швидкість перевищила наявну перепускну здатність мережі. Тоді надавач негайно зменшує вдвічі швидкість висилання, зменшуючи значення cwnd, і розпочинає поступове збільшення швидкості пересилання. Таким чином швидкість висилання неперервно модифікується, коливаючись біля значення наявної перепускної здатності мережі. Ці коливання динамічно підстроюються відповідно до збільшення або зменшення наявної перепускної здатності протягом тривання потоку даних. Очікуваним наслідком є динамічне підстроювання сукупного потоку даних, коли поєднання таких потоків поводиться правильно, при чому кожен потік отримує можливість коректного спільного використання мережі, а наявні мережеві ресурси використовуються максимально. Ця функціональність управління потоком досягається шляхом поєднання управління вікном перевантаження та алгоритму повторного пересилання втрачених пакетів. Управління потоком TCP має три основні компоненти: режими управління потоком повільного старту, уникнення перевантаження і реакції на втрати пакетів, які визначають, як TCP переходить від одного з цих режимів до іншого.

Повільний старт TCP. Початкове значення вікна перевантаження встановлюється рівним максимальному розміру сегменту надавача (Sender Maximum Segment Size – SMSS). Це значення SMSS базується на максимальному розмірі сегменту приймача, отриманому внаслідок SYN-підтвердження, значення MTU шляху (якщо воно використовується), значення MTU інтерфейсу надавача або, при відсутності іншої інформації, це значення становить 536 байтів. Надавача, який уводить режим управління потоком, називають повільний старт (Slow Start).

Надавач висилає окремий сегмент даних і, оскільки вікно заповнене, очікує відповідного підтвердження (ACK). Коли ACK прийнято, надавач збільшує своє вікно шляхом збільшення cwnd на величину SMSS. Це дозволяє надавачу вислати два сегменти, у цей момент вікно перевантаження знову заповнене і надавач мусить очікувати на відповідні підтвердження для цих сегментів. Алгоритм продовжує роботу, збільшуючи значення cwnd і, відповідно, розмір вікна перевантаження на один SMSS для кожного ACK, який підтверджує вислані дані. Якщо приймач висилає ACK для кожного пакету, то ефект цього алгоритму полягає у подвоєнні швидкості надавача за кожен період обігу петлі (RTT). Якщо приймач підтримує затримані підтвердження, то темп збільшення може бути суттєво меншим, однак темп зростає щонайменше на одне значення SMSS за кожен період обігу петлі. Однак, це не може тривати нескінченно. Якщо значення cwnd перевищить розмір оголошеного вікна приймача або вікна надавача, або перепускна здатність мережі буде перевищена, то може наступити втрата пакетів.

Існує також інше обмеження темпу зростання повільного старту, яке обслуговується змінною ssthresh або порогом повільного старту (Slow Start Threshold). Якщо, збільшуючись, значення cwnd перевищить значення ssthresh, то режим управління потоком TCP змінюється з повільного старту на уникнення перевантаження. Початкове значення ssthresh встановлюється рівним максимальному розміру вікна приймача. Однак, коли відзначено перевантаження, то ssthresh встановлюють рівним половині поточного розміру вікна, забезпечуючи TCP пам’яттю про пункт, де початок перевантаження мережі може передбачатися в майбутньому.

Одним з аспектів викладеного питання є взаємодія алгоритму повільного старту з високопродуктивними мережами з великою затримкою (Long Fat Network – LFT). Активність TCP в NFT веде до пересилання групи пакетів у кожен період RTT з періодом простоювання, який слідує за пересиланням даних заповненого вікна. Пакети підтвердження від приймача поступають до надавача з проміжком між ними, еквівалентним швидкості даних через вузьке місце у мережевому шляху. Потягом повільного старту надавач висидає дані в темпі, подвійному відносно швидкості у вузькому місці. Функція адаптації темпу повиння з’єявлятися всередині мережі і бути розміщеною в раутері на вході у вузьке місце. Пакети надавача поступають у такий раутер у подвійному темпі, ніж виходять з нього, і раутер повинен зберігати надлишковий потік у свому внутрішньому буфері. Якщо цей буфер переповниться, пакети будуть втрачені і фаза повільного старту завершиться. Важливим висновком є те, що надавач може зупинити збільшення свого темпу висилання даних, коли міскість буфера вичерпана; ця умова може бути не еквівалентна досягненню справді можливої швидкості даних. Якщо ємність буфера раутера порівняно менша від добутку ширина смуги-затримка вихідного кола, то ці дві величини суттєво відрізняються. У цьому випадку алгоритм повільного старту TCP може завершитися з темпом перевилання, який значно менший від наявної перепускної здатності. Ефективність операцій TCP, зокрема в LFN, критично пов’язана з адекватними обсягами буферів у раутерах мережі.

Іншим аспектом повільного старту є вибір одного сегменту як початкового розміру вікна надавача. Експерименти показують, що початкове значення у чотири сегменти може дозволити більш ефективний початок сесії, зокрема для короткотривалих TCP-сесій, які переважають при отриманні Web-сторінок. Спостереження за Web-трафіком показують, що середнє значення для пересилання Web-трафіку становить 17 сегментів. Повільний старт від одного сегменту може потребувати 5 інтервалів RTT для пересилання цих даних, тоді як початкове значення розміру вікна у 4 сегменти може скоротити час пересилання до трьох RTT. Однак, розмір вікна у чотири сегменти може бути занадто великим при використанні низькошвидкісних ліній з малими буферами, так що більш стійким способом є використання не більше від двох сегментів на початку повільного старту.

Втрата пакетів. Як вказано вище, повільний старт передбачає поступове і неперервне збільшення темпу висилання даних. Однак TCP повинен мати інформацію про потребу припинення цого зростання темпу внаслідок перевантаження мережі. Ця інформація отримується внаслідок втрати пакетів, при цьому TCP повинен здійснити ряд функцій:

q втрата пакетів повинна бути виявлена надавачем;

q втрачені дані повинні бути вислані повторно;

q темп висилання даних повинен бути відрегульований для зменшення ймовірності подальшої втрати пакетів.

TCP може виявляти втрату пакетів двома способами. По-перше, якщо окремий пакет втрачений всередині послідовності пакетів, то пакети, які доручені успішно, будуть викликати генерування дублікатів ACK для кожного успішного пакету. Приймання таких здубльованих підтверджень є сигналом втрати пакету. По-друге, оскільки втрата пакету у кінці послідовності висланих пакетів не викличе появи дублікатів ACK; але підтвердження для втраченого пакету відсутнє, таймер повторного висилання надавача вичерпується і надавач реєструє втрату пакету.

Окреме здубльоване підтвердження не є надійним сигналом втрати пакету. Якщо приймач TCP отримує пакет даних зі значенням TCP-послідовності не в потрібному порядку, то приймач повинен негайно генерувати ACK для останнього байта, прийнятого в потрібному порядку. Це ACK може бути дублікатом висланого раніше. Коли окремий пакет втрачений із послідовності пакетів, то всі наступні пакети не в послідовності будуть генерувати дублікати ACK. З другого боку, коли пакети перемаршрутовані з додатковою затримкою, то перевпорядкування потоку пакетів на приймальній стороні буде генерувати малу кількість дублікатів ACK, які слідують за ACK цілої послідовності даних піся того, як пакет, що заблукав, прийнятий. Приймач розрізняє ці випадки, використовуючи три здубльовані ACK як сигнал про втрату пакетів. Три здубльовані ACK перемикають надавача на негайне висилання сегменту, який стосується значень здубльованих ACK (швидке повторне пересилання – fast retransmit), і починає послідовність, яку називають швидким відновленням (Fast Recovery). При швидкому відновленні значення ssthresh встановлюють рівним половині поточного вікна висилання (вікно висилання містить обсяг непідтверджених даних). Параметр вікна перевантаження cwnd встановлюють на три сегменти більшим від ssthresh, щоб дозволини завжди буферизувати три сегменти у приймачі. Якщо це дозволяє вислати додаткові дані, то це висилання здійснюється. Кожне додаткове підтвердження збільшує cwnd на додатковий розмір сегменту, дозволяючи висилати більше даних. Коли поступає ACK, яке містить нові дані, то значення cwnd знову встановлюється рівним ssthresh і TCP вводить режим уникнення перевантаженння. Швидке відновлення призначене для швидкого виправлення втрати окремого пакету, дозволяючи приймачу продовжувати обслугу темпу висилання даних, синхронізованого ACK, для нових даних, якщо виправлення втрати окремого пакету було успішним. Це можливе тому, що послідовність ACK все ще поступає до приймача, так що мережа продовжує висилати синхронізуючі сигнали до надавача, вказуючи темп, з яким пакети поступають до приймача. Тільки коли виправлення завершене, надавач зменшує своє вікно до величини ssthresh як крок до переходу до режиму уникнення перевантаження.

Іншим сигналом про втрату пакетів є повне припинення поступлення пакетів ACK до надавача. Надавач не може безмежно очікувати на затримані підтвердження і мусить в перний момент часу зробити висновок, що наступний непідтверджений сегмент даних повинен бути висланий повторно. Надавач керує цим процесом, обслуговуючи таймер повторного пересилання (Retransmission Timer). Обслуга цього таймера впливає на ефективність і характеристики. Якщо таймер перемикається занадто повільно, то надавач може простоювати занадто довго, сповільнюючи понад потребу висилання потоку даних. Надавач TCP використовує таймер для вимірювання проміжку часу між висиланням сегменту даних і отриманням відповідного підтвердження. Індивідуальне вимірювання цього інтервалу часу може виявляти значні коливання і впровадження TCP використовують функцію згладжування, коли модифікують значення таймера повторного пересилання для потоку при кожному вимірюванні. Поширений алгоритм Ван Якобсона (Van Jacobsen) використовує згладжене значення RTT плюс чотирикратне значення згладженого середного відхилення. Коли таймер повторного пересилання вичерпується, то дії подібні до таких при дублюванні ACK. Значення ssthresh встановлюється рівним половині розміру вікна висланих і непідтверджених даних. Однак надавач не може зробити жодного правильного висновку про стан мережі внаслідок відсутності корисної інформації, крім значення одного інтервалу RTT. У цьому випадку надавач зменшує вікно перевантаження на один сегмент і рестартує потік у режимі повільного старту, висилаючи один сегмент. Відмінність від початкового повільного старту полягає в тому, що у цьому випадку значення ssthresh встановлене так, що надавач буде випробовувати область перевантаження повільніше, використовуючи лінійне зростання темпу висилання замість експоненціального, коли розмір вікна перевантаження досягне значення ssthresh.

Уникнення перевантаження. Порівняно з повільним стартом, уникнення перевантаження є більш експериментальним випробуванням мережі для дослідження порогового пункту втрати пакетів. Якщо повільний старт використовує експоненційне збільшення темпу висилання для знаходження першого наближення для порогу втрат, то уникнення перевантаження використовує лінійне зростання. Коли значення cwnd перевищує ssthresh, то надавач збільшує значення cwnd на величину SMSS´SMSS/ cwnd у відповідь на кожне нездубльоване ACK, так що вікно перевантаження вікривається на один сегмент всередині кожного інтервалу RTT. Вікно перевантаження продовжує відкриття таким чином, доки не з’явиться втрата пакетів. Якщо втрата пакетів обмежена до одного пакету всередині послідовності, то здубльовані ACK перемкнуть надавач на зменшення темпу вдвічі і продовження лінійного зростання вікна перевантаження від цього нового пункту, як це описано вище для швидкого відновлення. Поведінка cwnd в ідеалізованій конфігурації зображена на рис. 3.93, разом з відповідним темпом потоку даних.

 
 

Рис. 3.93. Моделювання одного пересилання TCP.

Загальні характеристики алгоритму TCP полягають у початковому відносно швидкому скануванні мережевої перепускної здатності для встановлення приблизних меж максимальної ефективності, за яким слідує циклічний режим адаптивної поведінки, яка швидко реагує на перевантаження і тоді повільно збільшує темп висилання через область з максимальною ефективністю пересилання. Втрати пакетів, сигналізовані перемиканням таймера повторного пересилання, обумовлюють повернення ло режиму повільного старту, який слідує за паузою. Темп пересилання потоку ілюструє рис.. Неефективність такого режиму обумовлена повним припиненням будь-яких форм сигналізації потоку від приймача до надавача. При відсутності будь-якої інформації надавач може тільки прийняти, що мережа дуже перевантажена і що він мусить рестартувати свої випробування мережевої перепускної здатності з розміром вікна перевантаженння в один сегмент. Це приводить до спостереження, що будь-яка форма управління видаленням пакетів веде до відкидання кінцівки послідовності пакетів даних і може обумовити значне погіршення характеристик TCP, бо така поведінка щодо видалення змушує сесію TCP продовжувати паузу і знову почати пересилання потоку від одного сегменту.

 


Рис. 3.94. Моделювання пересилання TCP з видаленням кінця черги.

 



Поделиться:


Последнее изменение этой страницы: 2016-08-01; просмотров: 418; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.237.186.170 (0.097 с.)