Павликевич М.Й Телекомунікаційні мережі ч2. Мережі ІР
Подождите немного. Документ загружается.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
181
Крім кумулятивних підтверджень, приймачі TCP можуть висилати селективні
підтвердження для забезпечення подальшої інформації.
Якщо надавач виявить, що дані втрачені в мережі, він повторно пересилає дані. На
рис. 8.7 показано діаграми найпростіших варіантів пересилання даних.
Рис. 8.7. Пересилання пакетів з підтвердженням (а) та з підтвердженням і повторним
пересиланням (б).
Як видно з рис. 8.7, час простоювання мережі між висланням пакету і отриманням
підтвердження може бути значним. Для підвищення ефективності передачі потоків даних
використовується ідея ковзного вікна. Протокол ковзного вікна використовує смугу мережі
краще, бо передавач може передати багато пакетів перед очікуванням підтвердження.
Протокол розміщає вікно фіксованого розміру над послідовністю пакетів і передає всі
пакети, розміщені всередині вікна. Кількість висланих, але непідтверджених пакетів
обмежена розміром вікна. Ключова ідея полягає в тому, що всі пакети у вікні висилаються
перш ніж буде отримане будь-яке підтвердження. Рис. 8.8 ілюструє операції протоколу з
ковзним вікном. Вікно, положення якого відносно потоку визначене вказівниками, містить
три пакети (рис. 8.8 а), які можна негайно вислати (рис. 8.8 в). Показано, що тільки після
отримання підтвердження для пакету 1 вікно “ковзає” (рис. 8.8 б) і висилається наступний
4-й пакет (рис. 8.8 в).
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
182
Рис. 8.8. Ковзне вікно та операції з ковзним вікном, яке містить три пакети: початкове
положення вікна (а), вікно ковзнуло на один пакет (б), діаграма пересилання пакетів (в).
Більш детально процедура пересилання описана нижче на прикладі. Як вже
вказувалося, для пересилання потік байтів поділяється на сегменти . Для прикладу на рис. 8.9
а прийнято, що нумерація послідовності розпочинається від нуля. Будова копії потоку байтів
на стороні приймача показана на рис. 8.9 б. Різниця між номером послідовності останнього
висланого байта і номером підтвердження визначена розміром вікна. Максимальний розмір
вікна станція оголошує як частину кожного сегменту TCP, висланого цією станцією.
Прямокутник, зображений штриховою лінієюна рис. 8.9 б, показує вікно приймача.
Рис. 8.9. Поділ фрагмента потоку на сегменти на стороні надавача (а) і заповнення буфера на
стороні приймача (б).
На рис. 8.9 показані наступні кроки.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
183
1. Сегмент 1 поступає до приймача, який підтверджує це, висилаючи сегмент ACK зі
значенням ACK=1000 і WIN=1600. Оскільки ACK+WIN=2600, надавач може вислати
сегменти 2,3 і 4. Нехай сегменти 2 і 3 вислані.
2. Сегмент 3 поступає вчасно, але сегмент 2 затриманий. Приймач висилає інший сегмент
ACK з ACK=1000 і WIN=1600. Надавач висилає сегмент 4.
3. Сегмент 4 поступив, але сегмент 2 досі відсутній. Знову приймач висилає ACK=1000,
WIN=1600. Відзначимо, що номер послідовності у підтвердженні повторюється, це
називають здубльованим ACK. Надавач не може вислати сегмент 5, бо цей сегмент
закінчується номером послідовності 2800, більшим від ACK+WIN. Тому надавач не може
зробити нічого іншого, доки сегмент 5 не буде поділений на менші сегменти, щоб
використати решту вікна. Це може призвести до синдрому недоумкуватого вікна (silly
window syndrome). Наступає пауза (timeout).
4. Сегмент 2 прибуває до приймача і приймач оголошує нове значення ACK=2400 і
WIN=1600, що дозволяє надавачу висилати до значення номера послідовності 4000.
Початкові значення номерів послідовностей з обидвох сторін сполучення пересилаються під
час його встановлення, як це показано вище (п.8.2.2.1).
Примітка. У телекомунікації та інженерних галузях, пов’язаних з нею, термін пауза (timeout або
time-out) має особливі значення:
це мережний параметр, пов’язаний з певною вимушеною подією, поява якої передбачена при
завершенні наперед визначеного терміну;
це окреслений період часу, наявний у системі перед певною подією, незалежно від того, чи
попередньо відбулася інша визначена подія; у кожному випадку цей період завершується,
коли відбувається будь-яка подія; пауза може бути припинена при прийнятті спеціального
сигналу, передбаченого для цього;
це подія, яка відбувається перед завершенням передбаченого періоду часу, який починається
при появі іншої визначеної події; пауза може починатися за сигналом, передбаченим для
цього.
Приймач не мусить детально та окремо підтверджувати кожен отриманий сегмент.
Звичайно він може очікувати приблизно 200 мс перед висланням підтвердження, це може
бути незручно для інтерактивних застосувань. До речі, підтвердження може бути включене у
зворотній потік даних.
Якщо приймач оголосив нульовий розмір вікна, то він може пізніше «відкрити» його,
виславши наступний ACK з модифікованим значенням розміру вікна. Це називають
модифікацією вікна, відповідний сегмент не мусить переносити дані. Особлива проблема
з’являється при втраті пакету модифікації вікна, її вирішують так, що надавач періодично
висилає проби, як це визначено таймером наполегливості (persist timer). Такі проби можуть
включати наступний символ, який приймач може відкинути, не підтвердивши його.
8.2.2.4.
Безпомилкове пересилання даних
Номер послідовності та підтвердження охоплюють видалення здубльованих пакетів,
повторне пересилання втрачених пакетів і впорядковане пересилання даних. Для досягнення
коректності даних використовується поле контрольної суми.
Ця контрольна сума TCP є цілком недостатнім способом перевірки в сучасних
стандартах. Канальний рівень з високим коефіцієнтом помилковості бітів може потребувати
додаткових можливостей для виявлення та корекції помилок. Якщо б TCP
перепроектовувався тепер, то для виявлення помилок ймовірно була б застосована схема 32-
бітової CRC замість чинної контрольної суми. Недоліки контрольної суми частково
компенсуються широким використанням CRC на Рівні 2 перед IP і NCP. Однак це не означає,
що 16-бітова контрольна сума TCP зайва: зауважено, що внесення помилок у пакет між
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
184
переходами, захищеними CRC, достатньо поширене, але наскрізна 16-бітова контрольна
сума TCP виявляє більшість з них.
8.2.2.5.
Регулювання потоку
TCP пробує здійснити найкраще можливе використання основних мереж, висилаючи
дані з найвищою можливою швидкістю, яка не викликає втрату пакетів. Ця проблема має два
аспекти - регулювання потоку та регулювання перевантаження.
TCP використовує наскрізний протокол регулювання потоку для уникнення ситуації,
коли передавач висилає дані швидше, ніж приймач може їх надійно прийняти та обробити.
Наявність механізму регулювання потоку суттєва у середовищах, де комунікуються станції з
різною швидкістю пересилання в мережі. Регулювання потоку пов’язане з поточним
номером послідовності байта на кожному кінці потоку даних. TCP розглядає потік даних як
послідовність октетів (байтів), які для передачі поділені на сегменти. Звичайно один сегмент
передається однією данограмою. Висланий сегмент містить номер послідовності останнього
висланого байта. Сегмент також може включати номер послідовності наступного байта,
котрого сподівається прийняти висилаюча станція, це називають номером підтвердження
(ACK). Станція, яка приймає сегмент, може вважати, що віддалена станція успішно прийняла
всі байти включно з байтом ACK-1, і локальні їх копії тепер можуть бути видалені з буфера.
Якщо два протоколи TCP включені у сполучення, то кожен з них обслуговує для
сполучення приймальне вікно, пов’язане з розміром його приймального буфера. Для TCP A –
це максимальна кількість байтів, яку TCP B може прийняти від A перед блокуванням та
очікуванням підтвердження. Всі сегменти TCP мають поле window (вікно), яке вживається
для інформування іншого TCP про розмір вікна для приймання сегментів від висилача. Це
називають оголошенням розміру вікна (window advertisement). В будь-який момент часу,
наприклад, TCP B може мати багато висланих, але не підтверджених сегментів, до
заповнення вікна, оголошеного TCP A.
Для максимальної ефективності мережі TCP повинен досягнути пункту динамічної
рівноваги, коли швидкість пересилання даних максимальна і відсутні тривалі втрати пакетів.
Подальше збільшення швидкості висилання може викликати ризик перевантаження в мережі
з раптовим підвищенням рівня втрати пакетів. Це, у свою чергу, може змусити протокол TCP
повторно висилати втрачені пакети, що веде до зменшення ефективності пересилання даних.
З другого боку, намір повністю вилучити втрати пакетів веде до того, що надавач мусить
зменшити швидкість висилання даних у мережу аж до того рівня, коли не створюються
навіть нетривалі перевантаження взовж шляху до приймача. При цьому наявні мережеві
ресурси використовуються неефективно.
Поняття пункту динамічної рівноваги важливе, бо завданням TCP є координація дій
надавача, мережі та приймача таким чином, щоб шлях у мережі мав достатньо даних, але не
наступало перевантаження. Обслуга пункту динамічної рівноваги вимагає синхронізації
надавача і приймача так, щоб надавач висилав пакети в мережу точно в той сам момент, коли
приймач видаляє пакети з мережі. Порушення цієї вимоги веде до недовантаження або
перевантаження мережі і ефективність пересилання в обидвох випадках зменшується.
8.2.2.6.
Змінний розмір ковзного вікна TCP і регулювання потоку
TCP використовує протокол регулювання потоку за допомогою ковзного вікна.
Механізм ковзного вікна TCP оперує рівнем октетів, а не сегментів чи пакетів. Октети
потоку даних пронумеровані послідовно і передавач утримує три показники, асоційовані з
конкретним сполученням (рис. 8.10). У кожному сегменті TCP приймач визначає у полі вікно
приймання обсяг даних (у байтах), які можуть бути прийняті додатково, якщо вони
підготовані у буфері для сполучення. Станція-надавач може вислати дані тільки до цього
обсягу, після чого мусить очікувати на підтвердження і модифікацію вікна станції-приймача.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
185
Рис. 8.10. Ковзне вікно TCP.
Особливість протоколу ковзного вікна TCP/IP полягає в тому, що TCP дозволяє
змінювати розмір вікна в часі. Кожне підтвердження, яке визначає, скільки октетів буде
переслано, містить оголошення вікна, яке визначає, скільки додаткових октетів даних
приймач підготований прийняти. Можна розглядати оголошення вікна як визначення
поточного розміру буфера. Відповідно до збільшення оголошеного розміру вікна передавач
збільшує розмір свого ковзного вікна і приступає до передачі октетів, які не були
підтверджені. У відповідь на зменшення оголошеного розміру вікна передавач зменшує
розмір свого вікна і зупиняє передачу октетів поза границями вікна.
Приймач оголошує надавачу наявний розмір свого буфера і надавач не може висилати
дані в мережу понад цей обсяг. Він повинен також зберігати вислані дані у своєму буфері,
доки вони не будуть підтверджені приймачем. Вікно висилання дорівнює мінімуму від
розміру буфера надавача і оголошеного вікна приймача. У кожен момент, коли прийняте
підтвердження, задній край вікна вікна пересилання просувається вперед. Мінімум від
розмірів буфера надавача і оголошеного вікна приймача використовується для обчислення
положення нового переднього краю вікна. Якщо вікно висилання містить невислані дані, то
ці дані можна вислати негайно.
Розмір буфера (вікна) TCP у кожній станції визначає обмеження характеристик у
глобальних мережах. Протокол здатний пересилати одне вікно даних за часовий інтервал
обігу петлі. Наприклад, якщо вікно висилання має 4096 байтів, а інтервал обігу петлі (Round
Trip Time – RTT) для шляху пересилання становить 600 мс, то сесія TCP здатна підтримувати
максимальну швидкість пересилання 48 кбіт/с незалежно від ширини смуги мережного
шляху. Максимальна ефективність пересилання досягається тільки тоді, коли надавач
здатний повністю заповнити мережевий шлях даними. Оскільки надавач може мати певний
обсяг даних для висилання і еквівалентний обсяг даних, які очікують на підтвердження, то як
буфер надавача, так і оголошене вікно приймача не повинні бути меншими, ніж це визначене
такою формулою:
Розмір вікна (байт)
ширина смуги (байт/с)
RTT (с)
Фактично перепускна здатність TCP-сполучення обмежена двома параметрами:
розмірами вікна перевантаження і вікна приймання. Перший розмір не повинен
перевищувати ємності мережі (регулювання перевантаження), а другий не повинен
перевищувати ємності (перепускної здатності) приймача при обробці даних (регулювання
потоку). Кожен сегмент TCP містить поточне значення вікна приймання. Наприклад, якщо
надавач приймає підтвердження байта 4 000 і визначає вікно приймання 10 000 байтів, то
надавач не повинен висилати пакети понад байт 14 000, навіть якщо вікно перевантаження це
дозволяє.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
186
Перевагою використання змінного розміру вікна є те, що воно передбачає здійснення
регулювання потоку. Якщо буфер приймача стає заповненим настільки, що не може
сприйняти більше пакетів, то приймач висилає оголошення меншого вікна. В
екстремальному випадку приймач оголошує розмір вікна, рівний нулю, і тим зупиняє
передачу. Пізніше, коли місце у буфері з’явилося, приймач оголошує ненульовий розмір
вікна і знову вмикає потік даних.
Номер послідовності TCP і вікно приймання дуже подібні до вказівника. Вікно
приймання зміщується кожен раз, коли приймач приймає і підтверджує новий сегмент даних.
Як тільки воно перевищує номер послідовності, цей номер встановлюється рівним 0.
Коли приймач оголошує розмір вікна рівним 0, надавач припиняє пересилання даних і
стартує таймер збереження (persist timer) . Цей таймер вживається для забезпечення TCP від
ситуації «смертельних обіймів», яка могла б виникнути, якщо модифікація вікна приймання
від приймача втрачена і надавач не має більше даних до пересилання, тоді як приймач очікує
на нову модифікацію розміру вікна. Коли таймер збереження вичерпується, TCP-надавач
висилає малий пакет, так що приймач повертає підтвердження з новим розміром вікна.
Якщо приймач обробляє вхідні дані з малими приростами, він може неодноразово
оголошувати мале вікно приймання. Це називають синдромом недоумкуватого вікна (silly
window syndrome), оскільки неефективно висилати тільки небагато байтів даних у TCP-
сегменті, маючи відносно велике службове навантаження TCP-заголовка. Надавачі і
приймачі TCP звичайно використовують логіку регулювання потоку для того, щоб уникнути
неодноразового висилання малих сегментів. Цю логіку називають алгоритмом Nagle.
8.2.2.7.
Регулювання перевантаження
Підтвердження пересланих даних або його відсутність використовуються надавачами
для встановлення стану мереж між надавачем і приймачем. Пов’язані таймерами, надавачі і
приймачі TCP можуть змінювати поведінку потоку даних. Більш загально це називають
регулюванням перевантаження (congestion control). і/або уникненням перевантаження
(congestion avoidance).
TCP використовує декілька механізмів для досягнення високих характеристик і
уникнення колапсу перевантаження, коли мережні характеристики можуть зменшитися на
декілька порядків. Ці механізми регулюють темп подавання даних у мережу, утримуючи
потік даних перед порогом, перевищення якого може спричинити колапс.
Сучасні впровадження TCP містять чотири взаємопов’язані алгоритми:
повільний старт,
уникнення перевантаження,
швидке повторне пересилання і
швидке відновлення (RFC2581).
Крім того, надавачі використовують таймер повторного пересилання (retransmission timer),
який базується на оцінці часу обігу петлі (round-trip time - RTT) між приймачем і надавачем,
а також на змінах цього часу. Режими роботи цього таймера описані в RFC 2988. Існують
певні особливості оцінювання RTT. Наприклад, надавач мусить визначити, коли здійснювати
обчислення RTT для пакетів, які повторно пересилаються; звичайно вони використовують
для цього алгоритм Karn’а або часові позначки TCP (TCP timestamps), як описано в RFC
1323. Звичайно окремі значення RTT усереднюються в часі для утворення згладженого RTT
(Smoothed Round Trip Time - SRTT) з використанням алгоритму Jacobson’а. Це значення SRTT
остаточно використовується як оцінка RTT.
Вдосконалення TCP для надійного опрацювання втрат, мінімізації помилок,
управління перевантаженням і збільшення швидкодії в дуже високошвидкісних середовищах
– це області для досліджень та опрацювання стандартів. Як результат, є численні варіанти
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
187
алгоритму уникнення перевантажень TCP. Найбільш важливі з них детально проаналізовані
у розділі 9 цього посібника.
8.2.2.8.
Максимальний розмір сегменту
Максимальний розмір сегменту – це найбільший обсяг даних, визначений у байтах,
який TCP може переслати в одному сегменті. Для забезпечення найкращих характеристик
MSS повинен бути достатньо малим, щоб уникнути IP-фрагментації, яка може приводити до
зайвого повторного пересилання внаслідок втрати пакета. Щоб це осягнути, звичайно MSS
погоджують з використанням MSS-опції, коли встановлюється TCP-сполучення. У цьому
випадку MSS визначене розміром максимального блоку пересилання (maximum transmission
unit - MTU) на Канальному рівні мереж, до яких безпосередньо під’єднані надавач і приймач.
Крім того, надавачі TCP можуть використовувати дослідження MTU шляху (Path MTU
discovery), щоб отримати мінімальне значення MTU вздовж мережного шляху між надавачем
і приймачем, і використати його для динамічного налаштування MSS з метою уникнення IP-
фрагментації всередині мережі.
8.2.2.9.
Селективні підтвердження
Полягання тільки на схемі кумулятивного підтвердження, застосованій в
оригінальному протоколі TCP, може спричинити неефективність, коли пакети втрачаються.
Наприклад, приймемо, що 10 000 байтів вислані у 10 різних пакетах TCP і перший пакет
втрачений пртягом пересилання. У протоколі з чисто кумулятивним підтвердженням
приймач не може ствердити, що він успішно прийняв байти від 1 000 до 9 999, хоч не
прийнятий лише перший пакет, який містить байти від 0 до 999. Тому надавач мусить
повторно переслати всі 10 000 байтів.
Для вирішення цієї проблеми TCP застосовує опцію селективного підтвердження
(selective acknowledgment - SACK), визначену в RFC 2018, яка дозволяє приймачу підтвердити
несуміжні блоки даних, прийняті успішно, додатково до номера послідовності останнього
суміжного успішно прийнятого байта, як в основному підтвердженні TCP. Це підтвердження
дозволяє визначити номер SACK-блоку, при чому кожен SACK-блок супроводжується
початковим і кінцевим номерами послідовності діапазону суміжності , яка успішно прийнята
приймачем (рис. 8.11). У повищому прикладі приймач повинен вислати SACK з номерами
послідовності 1 000 і 10 000. Тому надавач може повторно переслати тільки перший пакет з
номерами байтів від 0 до 999.
Рис. 8.11. Опція SACK.
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
188
Опція SACK необов’язкова і вживається тільки при підтримці її з обидвох сторін. Це
погоджується при встановленні сполучення. SACK використовує опційну частину заголовка
TCP. Вживання SACK дуже поширене – всі популярні стеки TCP використовують його.
Селективне підтвердження вживається також у протоколі SCTP.
8.2.2.10.
Масштабування вікна
Для більш ефективного використання широкосмугових мереж може бути
застосований більший розмір вікна. Поле розміру вікна TCP, яке дозволяє регулювати потік
даних, обмежене діапазоном від 2 до 65535 байтів (тобто до 64 Кбайтів). Оскільки розмір
цього поля не можна змінити, то використовується коефіцієнт масштабування. Опція
масштабування вікна необхідна для ефективного пересилання даних, коли добуток ширини
смуги на затримку (RTT) перевищує 64 Кбайти. Наприклад, використання каналу E1 зі
смугою 2 Мбіт/с через сателітарний зв’язок з величиною RTT=513 мс дає величину цього
добутку 2*1024*1024*0.513/8=134 479.9 байт. Використання максимального розміру буфера
64 Кбайти дозволяє використати лише 48.7% теоретично максимальної швидкості 2 Мбіт/с
або 0.975 Мбіт/с. При застосуванні опції масштабування вікна можна використати практично
повну перепускну здатність каналу. Ця опція також придатна при пересиланні великих
файлів (понад 64 Кбайти) через повільні мережі.
Опція масштабування вікна TCP, як визначено в RFC 1323, дозволяє фактичне
збільшення максимального розміру вікна від 65 535 байтів до 1 гігабайта (1,073,741,824
байтів). Ця опція використовується тільки протягом 3-етапного процесу встановлення TCP-
сполучення. Значення масштабу репрезентує кількість бітів для зсуву вліво 16-бітового поля
розміру вікна, тобто визначає збільшення розміру вікна у 2
k
, де k – значення коефіцієнта
масштабування в діапазоні 0..14.
Багато роутерів і «пожежних стінок» (firewalls) переписують масштабний коефіцієнт
вікна протягом пересилання, що спричиняє різні розміри вікна TCP на передавальній і
приймальній сторонах. Внаслідок цього трафік нестабільний і повільний. Цю проблему
видно з певних передавальних і приймальних пунктів, які розташовані за несправними
роутерами
8.2.2.11.
Часова позначка TCP
Часова позначка TCP, визначена у RFC 1323, допомагає обчислити час обігу петлі між
передавачем і приймачем. Опція часової позначки включає її 4-байтове значення у пункті, де
передавач помістив своє поточне значення таймера часової позначки, і 4-байтове значення
часової позначки відповіді-ехо у пункті, де приймач поміщає своє значення часової
позначки, звичайно, новіше від прийнятого. Передавач використовує часову позначку
відповіді-ехо у підтвердженні для обчислення повного часу, який минув від моменту
вислання сегменту підтвердження.
Часова позначка TCP також вживається у випадках, коли номер послідовності TCP
досягає своєї межі 2
32
і «зациклює» простір номерів послідовності. Ця схема відома як
забезпечення проти циклічного повторення послідовності (Protect Against Wrapped Sequence
– PAWS) номерів (див. RFC 1323).
8.2.2.12.
Позасмугові дані
Іноді необхідно перервати або відмінити потік з черги замість очікувати, доки його
пересилання завершиться. Це здійснюють, визначаючи дані як невідкладні (urgent). Слід
повідомити приймальну програму, щоб обробила їх негайно разом зрештою невідкладних
даних. Коли це завершиться, TCP інформує ужиткову програму і повертається назад до
потокової черги. Наприклад, коли TCP використовується у сесії віддаленої реєстрації (remote
login session), то користувач може вислати послідовність символів з клавіатури, яка
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
189
перериває або припиняє програму на іншому кінці. Такі сигнали часто необхідні, коли
програма на віддаленій станції працює некоректно. Такий сигнал повинен бути висланий
без очікування на завершення поточного пересилання.
На жаль дані TCP OOB не проектувалися для сучасного Internet. Вказівник негайності
тільки змінює обробку даних на віддаленій станції, але не прискорює жодних процесів у
самій мережі.
8.2.2.13.
Прискорене доручення даних
Звичайно TCP очікує перевищення обсягу даних у буфері понад максимальний розмір
сегмента, перш ніж висилає дані. Це створює суттєві затримки, коли дві сторони сполучення
висилають короткі повідомлення і очікують відповіді перед продовженням висилання.
Наприклад, ідентифікаційна послідовність перед початком сесії починається коротким
повідомленням "Login" і сесія не може продовжуватися, доки ці 5 символів не будуть вислані
і не буде отримана відповідь. Цей процес може значно сповільнити звичайну поведінку TCP.
Однак застосування може прискорити доручення октетів з вихідного потоку,
використовуючи операцію push, яку забезпечує TCP для ужиткового рівня. Ця операція
також спричиняє встановлення прапорця PSH, так що дані будуть негайно доручені до Рівня
застосувань від Транспортного рівня, який прийняв їх. У більш екстремальних ситуаціях,
наприклад, коли користувач очікує відповідь-ехо від приймальної ужиткової програми на
кожне натискання клавіші, операція push може вживатися кожного разу, коли натискається
клавіша. Більш загально, ужиткова програма використовує цю функцію для прискорення
висилання після набрання символа або рядка символів. Для прискорення негайного
висилання даних скорочують затримки та час очікування.
8.2.3. Завершення сполучення
Фаза завершення сполучення використовує щонайбільше 4-етапну схему, при чому
кожна сторона сполучення незалежно здійснює завершення (рис. 8.12). Коли кінцевий пункт
бажає завершити свою половину сполучення, то він пересилає пакет FIN, який підтверджує
інший кінцевий пункт, пересилаючи ACK. Таким чином, типове переривання сполучення
вимагає пари сегментів FIN та ACK для кожного кінцевого пункту TCP.
Рис. 8.12. Закриття сполучення TCP.
Сполучення може бути «напіввідкрите» у випадку, коли одна сторона здійснила
завершення, а друга – ні. Перша сторона не може більше висилати або приймати будь-які
дані від цього сполучення, а інша сторона може (проте загалом, якщо вона спробує це
2. Мережі IP.
_______________________________________________________________________________________
___________________________________________________________________________________________________
М. Павликевич. Телекомунікаційні мережі. Навчальний посібник для студентів спеціальності
"Інформаційні мережі зв'язку, 2009.
190
робити, то це призведе до відсутності підтвердження і внаслідок цього до паузи, або інакше
викличе позитивний RST і будь-яким чином ліквідує напіввідкрите гніздо TCP).
Також можна завершити сполучення за 3-етапною схемою, коли станція A висилає
FIN, станція B відповідає FIN та ACK (просто поєднуючи два кроки в одному) і станція A
відповідає ACK. Це найбільш поширений метод. Обидві станції можуть також одночасно
висилати FIN, тоді вони повинні їх підтвердити. Це можна розглядати як 2-етапний процес,
бо послідовність FIN/ACK реалізується паралельно в обидвох напрямках.
Деякі TCP-стеки станцій можуть впроваджувати «напівдуплексну» послідовність
закриття (наприклад, Linux або HP-UX). Якщо така станція здійснює активне закриття
сполучення, але все ще не отримала всі дані, які надходять до цього стеку потоколів з каналу,
то ця станція може вислати RST замість FIN, як це вказано у підрозділі 4.2.2.13 RFC 1122. Це
дозволяє застосуванням TCP зробити так, що віддалене застосування може читати всі дані,
вислані раніше, очікуючи FIN від віддаленого пункту, коли він активно закриє сполучення.
На жаль віддалений стек TCP не може розрізнити RST, яке перериває сполучення (Connection
Aborting RST), і це RST втрати даних (Data Loss RST)– обидва обумовлюють віддаленому
стеку підставу для щодо видалення всіх даних, прийнятих ним, але все ще не прочитаних
ужитковою програмою.
Коли фінальне підтвердження (ACK) вислане активною стороною закриття, то цей
порт або сполучення не може бути звільнені і повторно використані протягом періоду часу
2MSL (MSL - Maximum Segment Lifetime). Це обмеження на час, рівний подвійному часу
існування сегменту, потрібне на випадок, коли фінальне ACK втрачене (рис. 8.13). Тоді
станція, яка здійснює пасивне закриття, може зробити паузу, очікуючи на ACK у відповідь
на завершальний FIN, і може повторно вислати FIN. Якщо це відбувається перед
вичерпанням таймера за час 2MSL, то проблеми нема, але після цього часу цей FIN не
повинен виступати як належний до будь-якого сполучення, чинного між цими двома
клієнтами.
Рис. 8.13. Закриття сполучення TCP при втраті ACK для FIN.
RFC 793 визначає MSL тривалістю 120 с, однак окремі впровадження використовують
30 с або 60 с. Це, в основному, максимальний інтервал часу, протягом якого доцільно
очікувати сегмент, тобто, якщо сегмент не досягнув свого призначення за час MSL, то
ймовірно, що він не прибуде взагалі і можна вважати його втраченим.
На рис. 8.14 показана діаграма станів протоколу TCP.