Протокол ТСР, Детальна інформація

Це означає, що в повідомленні, яке передає А, встановлений біт SYN (synchronize sequence number), а у поле Sequence Number встановлено початкове 32-бітне значення ISSa (Initial Sequence Number).

В відповідає:

2. B -> A: SYN, ACK, ISSb, ACK(ISSa+1)

У відповідь на отриманий від А запит В відповідає повідомленням, в якому встановлений біт SYN та встановлений біт ACK; у поле Sequence Number хостом В встановлюється своє початкове значення лічильника - ISSb; поле Acknowledgment Number містить значення ISSa, отримане у першому пакеті від хоста А та збільшене на одиницю.

А, завершуючи “рукостискання” (handshake), надсилає:

3. A -> B: ACK, ISSa+1, ACK(ISSb+1)

У цьому пакеті встановлений біт ACK; поле Sequence Number містить ISSa + 1; поле Acknowledgment Number містить значення ISSb + 1. Відсиланням цього пакету на хост В закінчується трьохступеневий handshake та TCP-з’єднання між

хостами А та В вважається встановленим. Тепер хост А може посилати пакети з даними на хост В по щойно свтвореному віртуальному TCP-каналу:

4. A -> B: ACK, ISSa+1, ACK(ISSb+1); DATA

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

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

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

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

з’єднання було б вказівником на структуру TCB останнього. Запит OPEN вказуває також, чи здійснюється з’єднання активним чином, чи проходить пасивне очікування з’єднання ззовні.

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

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

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

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

Процедура встановлення з’єднання використовує флаг управління синхронізацією (SYN) та тричі обмінюється повідомленнями. (Див Мал 2)

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

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

Літературні джерела

C. Золотов. Протоколи Іnternet (C-П, 1998)

RFC793 ( HYPERLINK "http://info.internet.isi.edu/in-notes/rfc/files/rfc793.txt" http://info.internet.isi.edu/in-notes/rfc/files/rfc793.txt )

TCP – hijacking HYPERLINK "http://www.ssl.stu.neva.ru" \t "_blank" Илья Медведовский

0 4 10 16 24 31

Національний університет

“Києво-Могилянська Академія”