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



ЗНАЕТЕ ЛИ ВЫ?

Підтвердження і ретрансмісія.

Поиск

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

Встановлення TCP-з’єднання.

Оскільки TCP відноситься до протоколів із сполученням, перед передаванням даних проводиться встановлення зв’язку. Фаза встановлення зв’язку складається з 3-х TCP-сегментів, якими обмінюються ініціатор (джерело) та призначення:

1. Ініціатор генерує SYN сегмент (TCP-сегмент, де встановлено SYN-прапорець), в якому він вказує необхідні номер порта призначення (destination port), та свій початковий ідентифікатор послідовності (initial sequence number - ISN), з якого він починає нумерувати свої дані;

2. Призначення у відповідь генерує свій SYN-сегмент, встановлюючи destination port рівний source port ’у який був у пакеті ініціатора, та вибираючи свій ISN. Додатково пакет підтверджує сегмент ініціатора, піднімаючи ACK прапорець та встановлюючи acknowledgment number рівний значенню ISN ініціатора плюс 1 (нагадуємо що SYN прапорець додатково збільшує sequence number на 1);

3. Ініціатор підтверджує SYN сегмент призначення шляхом передачі пакету, в якому встановлено ACK-прапорець, та acknowledgment number дорівнює ISN призначення.

Рис. 3. 90. Встановлення TCP-з'єднання.

Сторона, яка виступає ініціатором, тобто відсилає першою свій SYN сегмент, робить так зване “активне” відкривання (active open) зв’язку, а сторона що відповідає на цей сегмент своїм SYN пакетом, відповідно “пасивне” відкривання (passive open). В англомовній літературі фазу встановлення зв’язку часто називають “three-way handshake”. В найпростішому випадку процес відбувається так, як показано на рис 3.90.

Перший сегмент може бути ідентифікований, оскільки для нього встановлений біт SYN в полі КОД. Друге повідомлення має встановлені біти SYN і ACK, які вказують, що підтвердження першого SYN-сегменту придатне для продовження. Останнє підтвердження зв'язку є тільки підтвердженням і використовується для інформування призначення, що обидві сторони готові до встановлення з’єднання.

Тришляхове підтвердження зв'язку здійснює дві важливі функції:

· гарантує, що обидві сторони готові до передавання даних;

· що обидві сторони погодили початковий номер послідовності.

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

Щоб побачити, що комп’ютери можуть погодити номери послідовностей для двох потоків тільки після трьох підтверджень, повторимо, що будь-який сегмент містить як поле номеру послідовності, так і поле підтвердження. Комп’ютер А, який ініціює підтвердження, передає свій початковий номер послідовності x в полі послідовності першого SYN-сегменту в тришляховому підтвердженні. Другий комп’ютер, B, приймає SYN, записує номер послідовності і відповідає, висилаючи свій початковий номер послідовності в полі послідовності як підтвердження, яке визначає сподіваний від B октет x+1. В останньому повідомленні-підтвердженні А “підтверджує” прийом від В всіх октетів від початку до кінця y. У всіх випадках підтвердження дотримується угоди про використання номера наступного октету за очікуваним.

Припинення TCP-з’єднання.

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

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

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

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

4. Ініціатор підтверджує FIN пакет призначення своїм ACK пакетом, після чого зв’язок рахується повністю розірваним.

Рис. 3.91. Припинення TCP-з'єднання.

TCP-сегменти 1 і 2 являють собою так зване часткове завершення (half close) зв’язку з одного боку. Говорять що ініціатор, той хто першим послав FIN пакет, робить “активне завершення” (active close), а друга сторона відповідно “ пасивне завершення ” (passive close). На рисунку 3.91 зображено часову діаграму фаз встановлення та завершення зв’язку.

З’єднання при необхідності може бути скинене. Для цього одна сторона ініціалізує припинення з’єднання, висилаючи сегмент з встановленим бітом RST в полі КОД. Друга сторона реагує на це безпосередньо, щоб перервати з’єднання. Передавання в обидвох напрямках припиняється негайно і буфери очищаються.

 



Поделиться:


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

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