Управління потоком

Управління потоком – визначення кількості даних, яке може послати джерело, перш ніж отримати підтвердження від пункту призначення. В крайньому випадку, протокол транспортного рівня міг би послати 1 байт даних і чекати підтвердження, перш ніж послати наступний байт. Але це надзвичайно повільний процес. Якщо дані проходять велику відстань, джерело вільне, поки він чекає підтвердження. Інший крайній випадок – транспортний протокол посилає всі дані без підтвердження. Це найбільш швидкий процес, але він може порушити роботу приймача. Крім того, що деяка частина даних втрачається, дублюється, виходить невпорядкованою або спотворюється, джерело не буде знати про це, поки все не буде перевірено пунктом призначення. Для TCP вибрано рішення, яке лежить між цими крайнощами. Протокол визначає вікно, яке встановлює обмеження на буфер доставки даних від прикладних програм і готовність до посилки. TCP посилає стільки даних, скільки визначено протоколом «ковзного вікна» (sliding window).

Протокол "ковзного вікна"

Для досягнення управління потоком TCP використовує протокол "ковзного вікна". При такому методі обидва хости використовують вікно для кожного з'єднання. Вікно виділяє невелику частину буфера, що містить байти, які буфер може передати, перш ніж турбуватися про підтвердження від іншого хоста. Вікно називається "ковзним вікном", тому що воно може ковзати як по буферу даних, так і по буферу підтвердження – змінюючи при цьому величину байтів, які можна посилати і приймати без прийняття або посилки сигналу підтвердження. Рис. 5.4 показує буфер передачі, визначений раніше на Рис. 5.1 і 5.2. Однак замість буфера зі зворотним зв'язком для спрощення показаний простий буфер.

На рис. 5.4 байти перед 200 послані і підтверджені. Передавач може знову використати ці місця. Байти з 200 до 202 послані, але не підтверджені. Передавач повинен зберегти ці байти в буфері, на випадок якщо вони втрачені або спотворені. Байти з 203 до 211 – в буфері (поставлені процедурою), але ще не передані. Давайте проаналізуємо ситуацію, в якій є протокол без ковзного вікна. У цьому випадку передавач може просуватися вперед і посилати всі байти (до 211 в його буфері), не зважаючи на стан приймача. Якщо процес прийому йде не достатньо швидко, буфер приймача з його обмеженим розміром може остаточно заповнитися. Надлишкові байти видаляються приймачем, після чого приймач запросить повторну передачу. Тому передавач повинен сам регулювати число доступних місць в приймачі.

Рис. 5.4.  Буфер передатчика

Вікно приймача

Рис. 5.5 показує буфер приймача. Зауважимо, що наступний байт, який буде прийнятий процесом, – 194. Приймач очікує отримання від передавача байта 200 (який посланий, але не отриманий). Скільки байт може накопичити приймач? Якщо загальний розмір буфера приймача N, а M місць вже зайнято, то може бути отримано не тільки NM байт. Наприклад, на Рис. 5.5 N = 13, а M = 6, це означає, що може бути отримано ще 7 байт. Це значення називається поточним вікном приймача.

Рис. 5.5.  Вікно приймача

Створимо вікно передавача з розміром менше і рівним розміру вікна приймача. Вікно включає послані байти і байти не підтверджені, а також ті, які можуть бути послані. Рис. 5.6 показує буфер передавача з вікном передавача, рівним розміру вікна приймача. На малюнку показано, що це вікно дорівнює 7. Сірим кольором показані передані байти, на які не надійшло підтвердження.

Рис. 5.6.  Буфер передачи и окно передатчика

Передавач не може послати кількість байтів, рівне розміру вікна, оскільки він вже послав 3 байти. Він може посилати тільки 4 байти. Зауважимо також, що хоча байти від 207 до 211 знаходяться в буфері передачі, вони також не можуть бути послані, поки ще не прибуло від приймача підтвердження вже посланих байтів.