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

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

Реферат з курсу

“Інтелектуальні мережі”

студентки IV курсу ДКТ

Пархоменко Олени

Київ, 1999

Вступ

Протокол TCP (Transmission Control Protocol) є одним з базових протоколів транспортного рівня мережі Internet. Цей протокол дозволяє виправляти помилки, які можуть виникнути в процесі передачі пакетів, та є протоколом зі встановленням логічного з’єднання - віртуального каналу. По цьому каналу передаются и приймаются пакети з реєстрацією їх послідовності, здійснюється управління потоком пакетів, организовуєтся повторна передача спотворених пакетів; наприкінці сеансу канал розриваєтся. При цьому протокол TCP є єдиним базовим протоколом з сімейства TCP/IP, який має додаткову систему ідентифікації повідомлень та з’єднання. Саме цьому протоколи прикладного рівня FTP та TELNET, що надають користувачам віддалений доступ на хости Internet, реалізовані на базі протокола TCP.

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

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

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

Інтерфейси

Протокол TCP взаємодіє з одного боку з користувачем чи прикладною програмою, а з іншого - з протоколом більш низького рівня, таким як протокол Internet.

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

Дія

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

• базова передача даних

• достовірність

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

• розподілення каналів

• работа зі з’єднаннями

• приорітет та безпека

Основні дії протокола TCP у кожній з цих областей описані у наступних параграфах.

Базова передача даних

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

Достовірність

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

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

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

Протокол TCP надає отримувачу засоби, щоб керувати кількістю даних, які посилає йому відправник. Це досягається викликом так званого "вікна" (window) разом с кожним підтвердженням, яке вказує діапазон прийнятних номерів, що йдуть за номером останнього успішно прийнятого сегменту. Вікно визначає кількість октетів, яку відправник може послати до отримання подальших вказівок.

Розподілення каналів

Щоб дозволити багатьом процесам на окремо взятому комп’ютері одночасно використовувати комунікаційні можливості рівня TCP, протокол TCP надає на кожному хост-комп’юторі набір адрес чи портів. Разом з адресами мереж та хост-компьютерів на комунікаційному рівні Internet вони утворюють сокет (socket – роз’єм).

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

Співвіднесення портів та процесів здійснюється кожним хост-комп’ютером самостійно. Проте виявляється корисним зв’язувати часто використовувані процеси (такі як "logger" чи сервіс з розподіленням часу) з фіксованими документованими сокетами.

Робота зі з’єднаннями

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

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

Приорітет та безпека

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

Склад та призначення полів заголовку

TCP-сегменти відправляються як IP-датаграми. Заголовок TCP, який йде за IP-заголовком, містить інформацію TCP-протоколу.

0 4 10 16 24 31

Source Port								Destionation Port
Sequence Number
Acknowlegement Number
Data Offset

	Reserved	URG	ACK	PSH	RST	SYN	FIN	Window
Checksum								Urgent Pointer
Options									Padding
Data

Мал. 1 Заголовок TCP-пакета

Source Port (16 біт). Порт відправника.

Destination Port (16 біт). Порт отримувача.

Acknowlegement Number (32 біта). Поле номера кадру підтвердженого отримання. Якщо пакет містить встановлений контрольний біт ACK, то це поле містить номер наступного пакета даних відправника, який очікує отримувач. При встановленому з’єднанні пакет підтвердження відправляється завжди.

Data Offset (4 біта). Поле величини зміщення даних. Воно містить кількість 32-бітних слів заголовку TCP-пакету. Це число визначає зміщення розташування даних у пакеті.

Reserved (6 біт). Резервне поле.

Прапори управління:

URG: Прапор терміновості

ACK: Прапор пакету, що містить підтвердження отримання

PSH: Прапор форсованої відправки

RST: Перевстановлення з’єднання

SYN: Синхронізація чисел послідовності

FIN: Прапор закінчення передачі з боку відправника

Window (16 біт). Це поле містить кількість байт даних, яку відправник даного сегменту може прийняти, відраховану від номеру байту, зазначеного в полі Acknowlegement Number.

Checksum (16 біт). Поле контрольної суми. Це поле містить 16 біт суми побітних додатків 16-бітних слів заголовку та даних. Якщо сегмент містить в заголовку та тексті непарну кількість октетів, що мають бути враховані в контольній сумі, останній октет буде доповнений нулями зправа с тим, щоби утворити для надання контрольній сумі 16-бітне слово. Октет, що виникає при такому виравнюванні, не передається разом з сегментом по мережі. Перед вирахуванням контрольної суми поле цієї суми заповнюється нулями.

Контрольна сума, окрім всього іншого, враховує 96 біт псевдозаголовку, який для внутрішнього використання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу отримувача, протокол та довжину TCP сегменту. Такий підхід забезпечує захист протоколу TCP від сегментів, що помилились у маршруті .Цю інформацію обробляє Internet протокол. Вона передається крізь інтерфейс протокол TCP/локальна мережа у якості аргументів чи результатів запитів від протоколу TCP до протоколу IP.

Адреса відправника
Адреса отримувача
Нулі	PTCL	Довжина TCP

Довжина TCP сегменту - это довжина TCP заголовку та поля даних, виміряна в октетах. Це не є точним вказівником кількості октетів, що передаються по мережі, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметру всеж проводиться.

Urgent Pointer (16 біт). Поле вказівника термінових даних. Це поле містить значення лічильника пакетів, починаючи з якого йдуть пакети підвищеної терміновості. Це поле береться до уваги лише в сегментах з встаносленим флагом URG.

Options. Поле додаткових параметрів: може бути змінної довжини.

Padding. Заповнення: змінна довжина. Заповнення (нулями) TCP-заголовку використовується для вирівнювання його по 32-бітному слову.

Встановлення з’єднання та його відміна

Розглянемо схему створення TCP-з’єднання (Мал 2).

Мал.2

Припустимо, що хосту А необхідно створити TCP-з’єднання з хостом В. Тоді А посилає на В наступне повідомлення:

1. A -> B: SYN, ISSa

Це означає, що в повідомленні, яке передає А, встановлений біт 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 (http://info.internet.isi.edu/in-notes/rfc/files/rfc793.txt)

• TCP – hijacking Илья Медведовский

Ссылки (links):

http://www.ssl.stu.neva.ru/