25.Міжмережний протокол tcp. Передача даних. Розрив з’єднань.

Передача даних

Коль з'єднання встановлено, передача даних здійснюється за допомогою обміну сегментами. Т.к. сегменти можуть бути втрачені в результаті помилок (наприклад, помилки в контрольній сумі) або перевантаження мережі, то програма протоколу TCP використовує механізм повторної посилки (після закінчення певного часу) з тим, щоб переконатися в отриманні кожного сегмента. У розділі, присвяченому номерами черг, обговорювалося, як програма TCP в сегментах здійснює перевірку номі рів черг і номерів підтвердження на предмет їх коректності.

Відправник даних за допомогою значення змінної SND.NXT відстежує наступний номер у черзі, що підлягає відправці. Одержувач даних за допомогою змінної RCV.NXT відстежує наступний номер, прибуття якого він очікує. У змінну SND.UNA відправник даних поміщає значення самого старого номера, який був відправлений, але ще не отримав підтвердження. Якби потік даних моментально вичерпався, а всі відправлені дані отримали підтвердження, то тоді б всі ці при змінні містили однакове значення.

Коли відправник інформації створює і посилає якийсь сегмент, він збільшує значення змінної SND.NXT. Адресат після отримання сегмента збільшує значення змінної RCV.NXT і відправляє підтвердження. Коли програма TCP, що послала дані, отримує підтвердження, вона збільшує значення SND.UNA. Різниця в значеннях цих змінних є заходом, що характеризує затримку сегментів в мережі. Величина, на яку треба щоразу здійснювати прирощення значення цих змінних, є довжиною поля даних у сегменті. Зауважимо, що оскільки з'єднання перебувають у стані ESTABLISHED, всі сегменти, на додаток до власне даними, повинні нести якусь інформацію про підтвердження раніше відправлених сегментів.

Запит користувача про закриття з'єднання (CLOSE) увазі використання функції проштовхування, що здійснюється за допомогою контрольного прапора FIN приходить сегменті.

Установка з'єднання та його скасування

Щоб ідентифікувати окремі потоки даних, які підтримує протоколом TCP, останній визначає ідентифікатори портів. Оскільки ідентифікатори портів обираються кожною програмою протоколу TCP незалежно, то вони не будуть унікальні. Щоб забезпечити унікальність адрес для кожної програми протоколу TCP, ми об'єднуємо ідентифікує цю програму Internet адресу та ідентифікатор порту. В результаті отримуємо сокет, який буде унікальний у всіх локальних мережах, об'єднаних в єдине ціле.

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

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

З'єднання задається командою OPEN (відкрити), зробленої з локального порту і має аргументом чужий сокет. У відповідь на такий запит програма протоколу TCP надає ім'я локального (короткого) з єднання. З цього імені користувач адресується до даного з'єднання при наступних викликах. Про з'єднаннях слід пам'ятати деякі речі.

Ми припускаємо, що є якась структура даних, називана блоком управління передачею (Transmission Control Block-TCB), призначена для збереження описаної вище інформації. Можна було б реалізувати протокол таким чином, щоб локальне ім'я для з'єднання було б вказівником на структуру TCB останнього. Запит OPEN вказує також, чи здійснюється з'єднання активним чином, або ж відбувається пасивне очікування з'єднання ззовні.

Запит на пасивне відкриття з'єднання означає, що процес чекає отримання ззовні запитів на з'єднання, замість того, щоб намагатися самому встановити його. Часто процес, що зробив запит на пасивне відкриття, буде приймати запити на з'єднання від будь-якого іншого процесу. У цьому випадку чужий сокет вказується як складається цілком з нулів, що означає невизначеність. Невизначені чужі сокети можуть бути присутніми лише в командах пасивного відкриття.

Сервісний процес, що бажає обслужити інші, невідомі йому процеси, міг би здійснити запит на пасивне відкриття з зазначенням невизначеного сокета. У цьому випадку з'єднання може бути встановлене з будь-яким процесом, що запросив з'єднання з цим локальним сокетом. Така процедура буде корисна, якщо відомо, що обраний локальний сокет асоційований з певним сервісом.

Загальновідомі сокети представляють собою зручний механізм апріорного прив'язування адреси сокету з яких-небудь стандартним сервісом. Наприклад, процес "сервер для програми Telnet" жорстко пов'язаний з конкретним сокетом. Інші сокети можуть бути зарезервовані за передавачем файлів, Remote Job Entry, текстовим генератором, луна-сервером, а також Sink-процесами (останні три пункти пов'язані з обробкою текстів). Адреса сокету може бути зарезервована для доступу до процедури "перегляду", яка могла б вказувати сокет, через який можна було б отримати новоутворені послуги. Концепція загальновідомого сокета є частиною TCP специфікації, однак власне асоціірованіе сокетів з послугами виходить за рамки даного опису протоколу.

Процеси можуть здійснювати пасивні відкриття з'єднань і чекати, поки від інших процесів прийдуть відповідні запити на активне відкриття, а протокол TCP проінформує їх про встановлення з'єднання. Два процеси, що зробили один одному одночасно запити на активне відкриття, отримають коректне з'єднання. Гнучкість такого підходу стає критичною при підтримці розподілених обчислень, коли компоненти системи взаємодіють один з одним асинхронним чином.

Коли здійснюється підбір сокетів для локального запиту пасивного відкриття та чужого запиту на активне відкриття, то принципове значення мають два випадки. У першому випадку місцеве пасивне відкриття повністю визначає чужий сокет. При цьому підбір має здійснюватись дуже акуратно. У другому випадку під час місцевого пасивного відкриття чужий сокет не вказується. Тоді в принципі може бути встановлене з'єднання з будь-яких чужих сокетів. У всіх інших випадках підбір сокетів має часткові обмеження.

Якщо на один і той же місцевий сокет здійснено декілька чекають пасивних запитів на відкриття (записаних в блоки TCB), і здійснюється ззовні активний запит на відкриття, то чужий активний сокет буде зв'язуватись з тим блоком TCB, де була вказівка ​​саме на цей запит з'єднання сокет . І тільки якщо такого блоку TCB не існує, вибір партнера здійснюється серед блоків TCB з невизначеним чужим сокетом.

Процедура встановлення з'єднання використовує прапор управління синхронізацією (SYN) та тричі обмінюється повідомленнями. Такий обмін називається триваріантну підтвердженням.

З'єднання ініціюється при зустрічі прийшов сегмента, несучого прапор синхронізації (SYN), і чекає його записи в блоці TCB. І сегмент і запис створюються прийшли від користувачів запитами на відкриття. Відповідність місцевого і чужого сокетів встановлюється при ініціалізації з'єднання. З'єднання визнається встановленим, коли номери черг синхронізовані в обох напрямках між сокетами.

Відміна з'єднання також включає обмін сегментами, що несуть на цей раз управляючий флаг FIN.

Розрив з’єднання ТСР Для встановлення з’єднання необхідно 3 пакети, для роз’єднання – 4 пакети.

1. Одна з аплікацій перша викликає функцію close і ми у цьому випадку говоримо, що даний вузол виконує активне закриття. ТСР даного вузла відправляє сегмент FIN, який означає завершення передачі даних.

2. Другий вузол, що отримує сегмент FIN виконує пасивне закриття. Отриманий сегмент FIN підтверджує ТСР. Отриманий FIN передається аплікації, який призначає кінця файлу, оскільки отриманий FIN означає для аплікації те, що вона вже не отримує ніяких даних по цьому з’єднанню.

3. Через деякий час після того, як аплікація отримала кінець файлу, вона викликає функцію close для закриття свого сонету. При цьому його ТСР відправляється в FIN.

4. ТСР системи, яка отримала кінцевий сегмент FIN, відправляє підтвердження отриманого FIN. Сегмент FIN займає 1 байт простору користувацьких номерів, так само, як і SYN. Відповідно сегмент ACK кожного сегмента FIN – це користувацький номер FIN +1. На рисунку продемонстровано, як клієнт виконує активне закриття. Але активне закриття може виконати любий вузол як клієнт, так і сервер.