Приклад 1

Уявімо собі, що TCP-з'єднання передає файл об'ємом 6000 байт. Перший байт пронумерований 10010. Яким буде порядковий номер для кожного сегмента, якщо дані посилаються на п'яти сегментах, в перших чотирьох сегментах переноситься 1000 байт, а в останньому – 2000 байт?

Розв’язання
Нижченаведене показує порядкові номери всіх сегментів:

Номер підтвердження

TCP забезпечує дуплексний зв'язок. Коли з'єднання встановлено, обидві сторони можуть передавати і приймати дані одночасно. Кожна сторона нумерує байти, зазвичай з різними початковими номерами. Порядковий номер у кожному напрямку показує перший байт, який переноситься в сегменті. Кожна сторона використовує номер підтвердження, щоб підтвердити отримані їй байти. Однак номер підтвердження визначає номер наступного байта, який кожна сторона очікує отримати. Крім того, номер підтвердження є інтегральним – це означає, що сторона прийняла номер останнього байта, що він отриманий коректно, додає до нього 1 і встановлює цю суму як номер підтвердження. Термін "інтегральна" тут означає, що якщо сторона використовує 5643 як номер підтвердження, вона отримала всі байти, починаючи з 5642 і нижче. Зауважимо, що це не означає, що сторона отримала 5642 байта, тому що перший байт може не мати початкового номера 0.

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

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

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

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

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

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Нарешті, статті 608 та 609 ЦК України передбачають припинення зобов’язання смертю фізичної особи та ліквідацією юридичної особи	\|	Ковзне вікно передавача

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.