Павликевич М.Й Телекомунікаційні мережі ч2. Мережі ІР
Подождите немного. Документ загружается.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
191
Рис. 8.14. Діаграма станів протоколу TCP.
Штрихові лінії показують нормальні переходи для сервера, а товсті лінії – нормальні стани
для клієнта.
8.3. Протокол данограм користувача (UDP).
8.3.1. Мультиплексування і де мультиплексування на базі
протокольних портів
Мультипрограмні операційні системи допускають одночасне виконання багатьох програм
застосувань (арplication programs), які прийнято називати процесами, задачами, застосуваннями і
процесами рівня користувача. Процес є кінцевим призначенням для повідомлення. Однак таке
означення незручне для практичного застосування, тому корисно уявити, що кожна станція має
множину абтрактно трактованих пунктів призначення, які називають протокольними портами
(protocol ports). Кожен протокольний порт ідентифікується цілим додатнім числом. Локальна
операційна система забезпечує механізм інтерфейсу, так що процеси використовують визначені їм
порти і доступ до них. Більшість операційних систем використовують синхронний доступ до порта.
Для забезпечення цього порти буферизуються, так що дані, які поступають тоді, коли процес
неактивний, не втрачаються.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
192
Для зв’язку з чужим портом передавач повинен знати як IP-адресу станції призначення, так і
номер протокольного порта в станції. Будь-яке повідомлення повинне передавати номер порта
призначення і номер порта джерела. Концептуально все мультиплексування і демультиплексування
між UDP-програмним забезпеченням і програмами застосувань осягається через механізм
протокольних портів із посередництвом операційної системи.
Рис. 8.15. Демультиплексування в протоколі UDP.
На рис. 8.15 показано приклад демультиплексування одного шару понад IP. UDP
використовує номер порта призначення при виборі відповідного порта призначення для прийнятої
датаграми.
8.3.2. UDP-данограма.
В комплекті протоколів TCP/IP протокол датаграм користувача (User Datagram Protocol -
UDP) здійснює первинний механізм, який використовує прикладна програма для передавання
данограми до іншої прикладної програми. UDP є прикладом транспортного протоколу і
розташований над шаром IP. UDP здійснює ненадійний безз’єднальний сервіс доручення,
використовуючи данограми IP для транспорту повідомлень між станціями, однак додає здатність до
розпізнавання серед різних призначень в даному вузлі. Будь-яке UDP-повідомлення називають UDP-
данограмою. Кожна спроба прикладного процесу передати через мережу інформацію викликає
утворення тільки однієї UDP-данограми, що інкапсулюється в одну IP-данограму (рис. 8.16).
Рис. 8.16. Інкапсуляція UDP-данограми.
IP-шар відповідальний лише за передавання даних між парою вузлів internet, тоді як UDP-шар
відповідальний лише за розрізнення серед багатьох джерел або призначень в одному вузлі. Це
повністю відмінне від потоко-орієнтованих протоколів, таких, наприклад, як TCP, де порція даних,
передана прикладною програмою, має мале відношення до того, що буде передано в одній IP-
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
193
данограмі. UDP не забезпечує високої надійності доставки інформації, UDP-рівень просто передає
дані від прикладної програми до IP-рівня, але не дає жодної гарантії , що ця інформація досягне
призначення.
Ужиткова програма також повинна звертати увагу на розмір результуючої IP-данограми, бо
якщо від буде більшим від MTU, то відбудеться фрагментація. Це стосується не тільки MTU
інтерфейса комп’ютера джерела, а і MTU інтерфейсів всіх проміжних маршрутизаторів, якщо такі є.
Концептуально UDP-данограма складається з двох частин: UDP-заголовка і області даних.
На рис. 8.17 наведено формат UDP-данограми, а на рис. 8.18 – UDP-данограма,
інкапсульована в данограмі IP.
Рис. 8.17. Формат UDP-данограми.
8.3.2.1.
UDP-заголовок.
Порт джерела і порт призначення містять 16-бітові UDP номери протокольних портів, які
ідентифікують процес прикладної програми, що надіслала UDP-данограму, і процес прикладної
програми, для якої призначена UDP-данограма; використовуються для демультиплексування
датаграм. Джерельний порт вказується опційно; якщо він використовується, то визначає порт, до
якого висилаються відповіді, якщо ні, то містить нуль.
Поле Довжина містить кількість октетів (байтів) і UDP-датаграмі включно із UDP-заголовком
(8 байтів) і даними користувача; мінімальне значення рівне 8.
Рис. 8.18. Данограма UDP, інкапсульована в данограмі IP.
Поле Контрольна сума UDP також опційне; контрольна сума охоплює всю UDP-данограму
(заголовок і дані), значення нуль вказує, що контрольна сума не обчислюється.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
194
8.3.2.2.
Контрольна сума UDP-данограми.
Особливістю є те що при обчисленні контрольної суми (як в UDP так і в TCP)
використовується 12-тибайтовий псевдо-заголовок, що включає деякі поля з IP-заголовку. Це
зроблено для того, щоб можна було подвійно перевірити, що UDP данограма прийшла точно за
призначенням.
Коли UDP данограма складається з непарної кількості байтів, то умовно додається байт
набивки (pad byte) рівний 0 (тільки для обчислення контрольної суми), який звичайно не передається.
Поля що використовуються для обчислення контрольної суми показані на рисунку 5.15.
Якщо обчислена джерелом контрольна сума получається рівна 0 то замість 0 записується 0xFFFF, а
якщо це поле на приймальній стороні всеж таки рівне 0 то це означає що джерело UDP данограми не
обчислювало контрольну суму. Насьогодні майже всі TCP/IP реалізації використовують обчислення
та перевірку UDP контрольної суми по замовчуванню.
Контрольна сума UDP обчислюється джерелом і перевіряється тільки призначенням, тобто
маршрутизатори, які просто передають UDP данограму з одного мережного інтерфейса на інший
такої перевірки не роблять. При виявленні на приймальній стороні помилки за допомогою
контрольної суми, UDP данограма простоо ігнорується (так само як і в IP), при цьому у відповідь не
відсилається ніякого повідомлення ICMP про помилки.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
195
9. МЕТОДИ ТА АЛГОРИТМИ РЕГУЛЮВАННЯ ПЕРЕВАНТАЖЕННЯ
У МЕРЕЖАХ TCP/IP
Одним з основних недоліків TCP/IP від часу його появи була нездатність гарантувати якість
послуг (QoS). Засоби QoS, базовані на TCP/IP, завжди полягали на організації черг як засобу
здійснення управління шириною смуги. Однак організації черг властиві часленні природні проблеми:
вона неефективна, неточна, реактивна і обслуговує тільки вихідний трафік. Пакети, затримані в черзі,
видаляються, вимагаючи повторного пересилання, що спричиняє втрату пакетів і відчутне зменшення
ефективності мережі. Більш нові технології регулювання темпу TCPвидаються більш ефективними і
точними для цілей виділення ширини смуги. Вони застосовують політики регулювання потоку,
базовані на регулюванні темпу TCP, як для індивідуальних потоків трафіку, так і для класів потоків.
Внаслідок цього можна отримати прогнозоване регулювання рівня послуг для справжнього QoS.
У цій роботі розглянені ряд методів регулювання перевантаження у сполученнях TCP. Перші
з них, передовсім Slow Start, трактують мережу як «чорну скриньку», для якої єдиними способами
виявлення перевантаження є втрати пакетів і зміни часу обігу петлі (RTT) або зміни перепускної
здатності. Ці явища реєструють кінцеві пункти TCP-сполучення, тобто джерела потоків. Інші методи
(Random Early Detection і Explicit Congestion Notification) залежать від роутерів, які забезпечують
виявлення перевантаження.
9.1. Методи, базовані на джерелі потоку даних
9.1.1. Метод та алгоритм повільного старту
9.1.1.1.
Метод повільного старту.
Повільний старт – це частина стратегії регулювання перевантаження, яку використовує
протокол TCP. Він вживається у поєднанні з іншими алгоритмами, щоб уникнути висилання
більшого обсягу даних, ніж мережа може переслати, тобто, для уникнення перевантаження мережі.
Повільний старт також відомий як фаза експоненціального зростання. Хоча ця стратегія названа
«повільним стартом», розмір вікна швидко збільшується.
Максимальний розмір вікна і RTT разом визначають максимальну досяжну швидкість
пересилання даних,
Розмір вікна (байт)
ширина смуги (байт/с)
RTT (с),
однак для TCP необхідний додатковий елемент управління потоком. Якщо сесія TCP починає
вводити повне вікно даних в мережу, то існує велика ймовірність того, що великий початковий обсяг
даних буде втрачений внаслідок тимчасового перевантаження, особливо при великому розмірі вікна.
Замість цього TCP використовує більш поміркований підхід, стартуючи з меншим обсягом даних, що
дає високу ймовірність упішного пересилання, а потім зондує мережу, збільшуючи обсяг даних, доки
мережа не виявить ознак перевантаження. Коли перевантаження виявиться, то швидкість
пересилання зменшується і випробування на додаткову перепускну здатність повторюється.
Динамічне оперування вікном є вирішальною компонентою продуктивності TCP при
пересиланні інформації. Механіка протоколу включає додатковий пріоритетний модифікатор вікна
надавача – вікно перевантаження (congestion window), як це було показано на рис. 1.9; модифікатор
скорочено позначають cwnd.
Метою алгоритму управління вікном є старт пересилання зі швидкістю, яка забезпечує дуже малу
ймовірність втрати пакетів, потім збільшення швидкості шляхом збільшення розміру вікна
перевантаження, доки надавач не отримає вказівку (внаслідок виявлення втрати пакетів), що
швидкість перевищила наявну перепускну здатність мережі.
Протягом фази експоненціального наростання повільний старт діє, збільшуючи вікно
перевантаження TCP кожен раз, коли прийнято підтвердження. Збільшення розміру вікна на кількість
підтверджених сегментів здійснюється доти, доки відсутність підтвердження деякого сегмента або
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
196
досягнення наперед заданого порогового значення не зупинить цей процес. Якщо наступила втрата
сегменту, TCP робить висновок, що це трапилося внаслідок перевантаження мережі і здійснює кроки
для зменшення навантаження мережі. Замість експоненційного TCP впроваджує фазу лінійного
наростання (уникнення перевантаження). Від цього моменту вікно збільшується на один сегмент для
кожного RTT. Це відбувається до появи втрати сегменту.
Таким чином швидкість висилання неперервно модифікується, коливаючись біля значення
наявної перепускної здатності мережі. Ці коливання динамічно налаштовуються відповідно до
збільшення або зменшення наявної перепускної здатності протягом тривання потоку даних.
Очікуваним наслідком є динамічне налаштування сукупного потоку даних, коли поєднання таких
потоків поводиться правильно, при чому кожен потік отримує можливість коректного спільного
використання мережі, а наявні мережеві ресурси використовуються максимально. Ця
функціональність управління потоком досягається шляхом поєднання управління вікном
перевантаження та алгоритму повторного пересилання втрачених пакетів. Регулювання потоком TCP
має три основні компоненти: режими управління потоком повільного старту, уникнення
перевантаження і реакції на втрати пакетів, які визначають, як TCP переходить від одного з цих
режимів до іншого.
9.1.1.2.
Алгоритм повільного старту.
Початкове значення вікна перевантаження cwnd встановлюється рівним максимальному
розміру сегменту надавача (Sender Maximum Segment Size – SMSS). Це значення SMSS базується на
максимальному розмірі сегменту приймача, отриманому внаслідок SYN-підтвердження, значення
MTU шляху (якщо воно використовується), значення MTU інтерфейсу надавача або, при відсутності
іншої інформації, це значення становить 536 байтів.
Вибір кількості сегментів для визначення початкового розміру вікна надавача є важливим
аспектом алгоритму повільного старту. Експерименти показують, що початкове значення у чотири
сегменти може дозволити більш ефективний початок сесії, зокрема для короткотривалих TCP-сесій,
які переважають при отриманні Web-сторінок. Спостереження за Web-трафіком показують, що
середнє значення для пересилання Web-трафіку становить 17 сегментів. Повільний старт від одного
сегменту може потребувати 5 інтервалів RTT для пересилання цих даних, тоді як початкове значення
розміру вікна у 4 сегменти може скоротити час пересилання до трьох RTT. Однак, розмір вікна у
чотири сегменти може бути занадто великим при використанні низькошвидкісних ліній з малими
буферами, так що більш стійким способом є використання не більше від двох сегментів на початку
повільного старту.
Етап експоненційного збільшення вікна. Нехай надавач висилає окремий сегмент даних.
Оскільки вікно надавача заповнене, то він очікує відповідного підтвердження (ACK). Коли ACK
прийнято, надавач збільшує своє вікно шляхом збільшення cwnd на величину SMSS. Це дозволяє
надавачу вислати два сегменти, у цей момент вікно перевантаження знову заповнене і надавач мусить
очікувати на відповідні підтвердження для цих сегментів. Алгоритм продовжує роботу, збільшуючи
значення cwnd і, відповідно, розмір вікна перевантаження на один SMSS для кожного ACK, який
підтверджує вислані дані. Якщо приймач висилає ACK для кожного пакету, то ефект цього алгоритму
полягає у подвоєнні швидкості надавача за кожен період обігу петлі (RTT). Якщо приймаються
затримані підтвердження, то темп збільшення може бути суттєво меншим, однак цей темп зростає
щонайменше на одне значення SMSS за кожен період обігу петлі.
Для алгоритму повільного старту суттєвим є припущення, що наявність непідтверджених
сегментів означає перевантаження мережі. Хоч це є прийнятним припущенням для багатьох мереж,
однак сегменти можуть бути втрачені з інших причин, наприклад, внаслідок низької якості каналу
зв’язку. Тому повільний старт може погано працювати в подібних ситуаціях.
Втрата пакетів як ознака появи перевантаження. Як вказано вище, повільний старт
передбачає поступове і неперервне збільшення темпу висилання даних. Однак TCP повинен мати
інформацію про потребу припинення цого зростання темпу внаслідок перевантаження мережі. Ця
інформація отримується внаслідок втрати пакетів, при цьому TCP повинен здійснити ряд функцій:
втрата пакетів повинна бути виявлена надавачем;
втрачені дані повинні бути вислані повторно;
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
197
темп висилання даних повинен бути відрегульований для зменшення ймовірності подальшої
втрати пакетів.
TCP може виявляти втрату пакетів двома способами.
По-перше, якщо окремий пакет втрачений всередині послідовності пакетів, то пакети, які
доручені успішно, будуть викликати генерування дублікатів ACK для кожного успішного
пакету, як це вказувалося в поясненнях до рис. 8.9 (п.8.2.2.3). Приймання таких здубльованих
підтверджень є сигналом втрати пакету.
По-друге, оскільки втрата пакету у кінці послідовності висланих пакетів не викличе появи
дублікатів ACK; але підтвердження для втраченого пакету відсутнє, таймер повторного
висилання надавача вичерпується і надавач реєструє втрату пакету.
Окреме здубльоване підтвердження не є надійним сигналом втрати пакету. Якщо приймач
TCP отримує пакет даних зі значенням номера послідовності не в потрібному порядку, то приймач
повинен негайно генерувати ACK для останнього байта, прийнятого в потрібному порядку. Це ACK
може бути дублікатом висланого раніше. Коли втрачений окремий пакет з послідовності пакетів, то
всі наступні пакети поза правильною послідовністю будуть генерувати дублікати ACK. З другого
боку, коли пакети перемаршрутовані з додатковою затримкою, то перевпорядкування потоку пакетів
на приймальній стороні буде генерувати малу кількість дублікатів ACK, які слідують за ACK цілої
послідовності даних піся того, як пакет, що заблукав, прийнятий. Приймач розрізняє ці випадки,
використовуючи три здубльовані ACK як сигнал про втрату пакетів. Три здубльовані ACK
перемикають надавача на негайне висилання сегменту, який стосується значень здубльованих ACK
(швидке повторне пересилання – fast retransmit), і починає послідовність дій, яку називають швидким
відновленням (Fast Recovery).
Іншим сигналом про втрату пакетів є повне припинення поступлення пакетів ACK до
надавача. Надавач не може безмежно очікувати на затримані підтвердження і мусить в певний
момент часу зробити висновок, що наступний непідтверджений сегмент даних повинен бути
висланий повторно. Надавач керує цим процесом, обслуговуючи таймер повторного пересилання
(Retransmission Timer). Обслуга цього таймера впливає на ефективність і характеристики. Якщо
таймер перемикається занадто повільно, то надавач може простоювати занадто довго, сповільнюючи
понад потребу висилання потоку даних. Надавач TCP використовує таймер для вимірювання
проміжку часу між висиланням сегменту даних і отриманням відповідного підтвердження.
Індивідуальне вимірювання цього інтервалу часу може виявляти значні коливання і впровадження
TCP використовують функцію згладжування, коли модифікують значення таймера повторного
пересилання для потоку при кожному вимірюванні. Поширений алгоритм Ван Якобсона (Van
Jacobsen) використовує згладжене значення RTT плюс чотирикратне значення згладженого середного
відхилення. Коли таймер повторного пересилання вичерпується, то дії подібні до таких при
дублюванні ACK. Значення ssthresh встановлюється рівним половині розміру вікна висланих і
непідтверджених даних. Однак надавач не може зробити жодного правильного висновку про стан
мережі внаслідок відсутності корисної інформації, крім значення одного інтервалу RTT. У цьому
випадку надавач зменшує вікно перевантаження до одиного сегмента і рестартує потік у режимі
повільного старту, висилаючи один сегмент. Відмінність від початкового повільного старту полягає в
тому, що у цьому випадку значення ssthresh встановлене так, що надавач буде випробовувати область
перевантаження повільніше, використовуючи лінійне зростання темпу висилання замість
експоненціального, коли розмір вікна перевантаження досягне значення ssthresh.
Швидке повторне пересилання. Коли прийняті здубльовані ACK, то надавач не може знати,
чи це трапилося тому, що сегмент втрачений, чи тому, що сегмент затримався і прийнятий не в
потрібній послідовності. Якщо приймач може перевпорядкувати сегменти, то це повинне бути
здійснено, перш ніж приймач вишле останнє очікуване підтвердження. Звичайно може бути прийнято
не більше від двох дублікатів ACK, коли існує просте порушення порядку послідовності. Однак коли
надавач приймає понад два дублікати ACK, це певна вказівка на те, що втрачено не менше від одного
сегменту. TCP-надавач може вважати, що було достатньо часу для перевпорядкування всіх сегментів,
якщо приймач мав достатньо часу для висилання трьох дублікатів ACK.
Коли прийнято три або більше дублікатів ACK, то надавач навіть не повинен очікувати
вичерпання таймера повторного пересилання перед ретрансмісією сегменту. Тому цей процес
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
198
називають алгоритмом швидкого повторного пересилання (Fast Retransmit). Безпосередньо після
швидкого повторного пересилання виконується алгоритм швидкого відновлення (Fast Recovery).
Швидке відновлення призначене для швидкого виправлення втрати окремого пакету,
дозволяючи приймачу продовжувати обслугу темпу висилання даних, синхронізованого ACK, для
нових даних, якщо виправлення втрати окремого пакету було успішним. Це можливе тому, що
послідовність ACK все ще поступає до приймача, так що мережа продовжує висилати синхронізуючі
сигнали до надавача, вказуючи темп, з яким пакети поступають до приймача. Оскільки алгоритм
швидкого повторного пересилання вживається, якщо прийнято дублікати ACK, то надавач TCP має
цілковиту певність, що дані досі пересилаються до приймача. Підставою для цього є те, що дублікат
ACK генерується тоді, коли прийнято сегмент. Це точна вказівка про відсутність серйозного
перевантаження мережі і на те, що втрата пакету є винятковою подією. Тому, замість стартувати
вікно від одного сегменту як в режимі повільного старту, надавач розпочинає пересилання з більшим
вікном.
При швидкому відновленні значення ssthresh встановлюють рівним половині поточного вікна
висилання (вікно висилання містить обсяг непідтверджених даних). Параметр вікна перевантаження
cwnd встановлюють на три сегменти більшим від ssthresh, щоб завжди дозволяти буферизувати три
сегменти у приймачі. Якщо це дозволяє вислати додаткові дані, то це висилання здійснюється. Кожне
додаткове підтвердження збільшує cwnd на величину SMSS*SMSS/cwnd, дозволяючи висилати
більше даних. Тільки коли виправлення завершене, надавач зменшує своє вікно до величини ssthresh
як крок до переходу до режиму уникнення перевантаження. Це дозволяє отримати вищу перепускну
здатність за умови поміркованого перевантаження.
Повільний старт у мережах LFT. Одним з аспектів викладеного питання є взаємодія
алгоритму повільного старту з високопродуктивними мережами з великою затримкою (Long Fat
Network – LFT). Активність TCP в LFT веде до пересилання групи пакетів у кожен період RTT з
періодом простоювання, який слідує за пересиланням даних заповненого вікна. Пакети
підтвердження від приймача поступають до надавача з проміжком між ними, еквівалентним
швидкості даних через вузьке місце у мережевому шляху. Потягом повільного старту надавач
висидає дані в темпі, подвійному відносно швидкості у вузькому місці. Функція адаптації темпу
повинна з’являтися всередині мережі і бути розміщеною в роутері на вході у вузьке місце. Пакети
надавача поступають у такий роутер у подвійному темпі, ніж виходять з нього, і роутер повинен
зберігати надлишковий потік у свому внутрішньому буфері. Якщо цей буфер переповниться, пакети
будуть втрачені і фаза повільного старту завершиться. Важливим висновком є те, що надавач може
зупинити збільшення свого темпу висилання даних, коли міскість буфера вичерпана; ця умова може
бути не еквівалентна досягненню справді можливої швидкості даних. Якщо ємність буфера роутера
порівняно менша від добутку ширина смуги-затримка вихідного кола, то ці дві величини суттєво
відрізняються. У цьому випадку алгоритм повільного старту TCP може завершитися з темпом
перевилання, який значно менший від наявної перепускної здатності. Ефективність операцій TCP,
зокрема в LFN, критично пов’язана з адекватними обсягами буферів у роутерах мережі.
Уникнення перевантаження. Порівняно з повільним стартом, уникнення
перевантаження (Congestion Avoidance) використовує експериментальне випробування мережі для
дослідження порогового пункту втрати пакетів (рис. 9.1). При появі втрат половина поточного
значення cwnd зберігається як поріг повільного старту (Slow Start Threshold - ssthresh) і повільний
старт розпочинається знову від початкового значення cwnd. Коли cwnd досягне значення ssthresh,
TCP переходить до режиму уникнення перевантаження (Congestion Avoidance), при якому кожне
ACK збільшує cwnd на величину SMSS*SMSS/cwnd. Це означає лінійне зростання cwnd. Початкове
значення ssthresh встановлюється рівним максимальному розміру вікна приймача.
Коли значення cwnd перевищує ssthresh, то надавач збільшує значення cwnd на величину
SMSSSMSS/cwnd у відповідь на кожне нездубльоване ACK, так що вікно перевантаження
вікривається на один сегмент всередині кожного інтервалу RTT. Вікно перевантаження продовжує
відкриття таким чином, доки не з’явиться втрата пакетів. Якщо втрата пакетів обмежена до одного
пакету всередині послідовності, то здубльовані ACK перемкнуть надавач на зменшення темпу вдвічі і
продовження лінійного зростання вікна перевантаження від цього нового пункту, як це описано вище
для швидкого відновлення. Поведінка cwnd в ідеалізованій конфігурації зображена на рис. 2.1, разом
з відповідними змінами темпу пересилання потоку даних.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
199
Рис. 9.1. Моделювання одного пересилання TCP.
Загальні властивості алгоритму TCP характеризуються:
початковим відносно швидким скануванням мережевої перепускної здатності для встановлення
приблизних меж максимальної ефективності;
циклічним режимом адаптивної поведінки, яка слідує за скануванням і полягає у швидкому
реагуванні на перевантаження та наступному повільному збільшенні темпу висилання через
область з максимальною ефективністю пересилання;
поверненням до режиму повільного старту, який слідує за паузою, внаслідок втрати пакетів,
сигналізованої вичерпанням таймера повторного пересилання.
Темп пересилання потоку ілюструє рис. 9.2.
Рис. 9.2. Моделювання пересилання TCP з видаленням кінця черги.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
200
Неефективність такого режиму обумовлена повним припиненням будь-яких форм сигналізації
потоку від приймача до надавача. При відсутності будь-якої інформації надавач може тільки
прийняти, що мережа дуже перевантажена і що він мусить рестартувати свої випробування мережевої
перепускної здатності з розміром вікна перевантаженння в один сегмент. Це приводить до
спостереження, що будь-яка форма управління видаленням пакетів веде до видалення кінцівки
послідовності пакетів даних (див. п. 9.1.2) і може обумовити значне погіршення характеристик TCP,
бо така поведінка щодо видалення змушує сесію TCP продовжувати паузу і знову почати
пересилання потоку від одного сегменту.
9.1.2. Алгоритм Tail Drop
Видалення кінцівки («хвоста») (Tail Drop) - це простий алгоритм управління чергою, який
вживається роутерами для вирішення питання про видалення пакетів. На відміну від більш складних
алгоритмів, як RED і WRED, тут трафік не розрізняється за видами і кожен пакет трактують
однаково. Коли черга заповнена до максимальної ємності, нові пакети, які прибувають, видаляються,
доки черга не отримає достатньо місця для приймання вхідного трафіку.
Назва алгоритму походить від впливу політики щодо данограм, які надходять. Як тільки черга
заповнена, роутер починає видалення всіх додаткових данограм, тим самим видаляючи кінцівку
(«хвіст») послідовності данограм. Втрата данограм змушує TCP-надавача започаткувати повільний
старт, який зменшує перепускну здатність цієї TCP-сесії, доки надавач знову почне приймати
підтвердження і збільшить своє вікно перевантаження. Більш серйозна проблема виникає, коли
видаляються данограми від багатьох TCP-сполучень, обумовлюючи глобальну синхронізацію, тобто
коли всі надавачі, включені в цей процес, розпочинають повільний старт. Це трапляється тому, що
замість видалення багатьох сегментів з одного сполучення, роутер видаляє по одному сегменту від
кожного сполучення.
9.1.3. Алгоритми Tahoe і Reno
TCP Tahoe і Reno. Два таких варіанти пропоновані TCP Tahoe і Reno. Для уникнення
перевантаження TCP використовує багатогранну стратегію контролю за перевантаженням. Для
кожного сполучення TCP утримує вікно перевантаження (congestion window), яке обмежує загальну
кількість непідтверджених пакетів, які можуть пересилатися між кінцевими пунктами. Це подібне до
ковзного вікна, яке вживається для регулювання потоку. TCP використовує механізм повільного
старту для збільшення вікна перевантаження після встановлення сполучення та після паузи (timeout).
Протокол стартує з вікном, удвічі більшим від максимального розміру сегменту (maximum segment
size - MSS). Хоч початковий темп пересилання низький, він наростає дуже швидко: для кожного
підтвердженого пакету вікно перевантаження збільшується на 1 MSS, так що для кожного інтервалу
обігу петлі (round trip time - RTT) вікно перевантаження збільшується удвічі. Коли розмір вікна
перевантаження перевищить порогове значення (ssthresh), алгоритм переходить в інший стан, який
називається уникненням перевантаження (congestion avoidance). Це порогове значення
модифікується після завершення кожного повільного старту і часто може викликати наступний
повільний старт, який запускається паузами.
Уникнення перевантаження. Доки приймаються нездубльовані підтвердження (ACK), вікно
перевантаження адитивно збільшується на один MSS за кожен RTT. Коли пакет втрачений, можуть
бути прийняті здубльовані підтвердження. Поведінка Tahoe і Reno відрізняється у тому, як вони
виявляють втрату пакету і реагують на неї.
Втрата пакету в Tahoe виявляється, якщо пауза закінчується перед прийняттям підтвердження.
Тоді вікно перевантаження зменшується до одного MSS і протокол переходить до режиму
повільного старту.
В алгоритмі Reno, якщо прийняті три повторні (здубльовані) підтвердження, які не
супроводжуються даними, пересланими у зворотньому напрямку, і які не змінюють оголошеного
розміру вікна приймача, то вікно перевантаження зменшується удвічі, здійснюється «швидке
повторне пересилання» і розпочинається фаза, названа швидким відновленням (Fast Recovery).
Якщо ж час отримання ACK перевищений, застосовується повільний старт, як у Tahoe.