Протоколи транспортного рівня

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Класичний приватний університет
РЕФЕРАТ
з дисципліни: Комп'ютерні мережі (Локальні, корпоративні, глобальні)
на тему: «Протоколи транспортного рівня»
Виконав студент групи:
ДІ-204 Шевченко М.Ю.

ВСТУП:

Додаток, що працює з Інтернет, як правило, спілкується з одним із протоколів транспортного рівня TCP / IP: протоколом управління транспортуванням (TCP) або протоколом користувальницьких датаграм (UDP). Додаток будує свою роботу на взаємодії з одним з цих протоколів.
Програми Інтернет, наприклад програма ftp, передає файли по мережі, зазвичай використовує TCP, так як він пропонує надійну потокооріентірованную службу доставки. Програми типу електронної пошти часто користуються TCP з тієї ж самої причини. Чи не вимагають особливої ​​надійності додатки типу tftp (протокол простої передачі файлів, trivial file transfer protocol) використовують UDP. Додатки на основі протоколу часу (time protocol), що зв'язуються з серверами часу Інтернет, можуть користуватися як тим, так і іншим протоколом. Прочитавши цю главу, ви будете точно знати, в якому випадку може знадобитися TCP, а в якому - UDP.
Кінцева мета мережевої взаємодії полягає в передачі інформації між додатком-клієнтом і додатком-сервером. Розуміння транспортних протоколів і транспортного рівня абсолютно необхідно для ефективного проектування додатків типу клієнт-сервер. Закінчивши читання цієї глави, ви оволодієте наступними поняттями і концепціями:
· Як транспортний протокол використовує порт протоколу для зв'язку з програмою-додатком.
· Призначення полів даних у заголовку UDP.
· Як TCP забезпечує надійну доставку даних.
· Як TCP використовує ковзне вікно для збільшення пропускної здатності мережі.
· Як модулі TCP встановлюють і закінчують з'єднання.
· Як TCP використовує повідомлення-підтвердження.
· Призначення полів даних у заголовку TCP.

Що таке транспортний рівень?
На перший погляд здається, що IP, служба доставки Інтернет, і транспортні протоколи виконують однакові функції. Насправді IP модуль доставляє дані тільки між двома комп'ютерами. Транспортний рівень і його протоколи передають дані між додатками.
У багатьох випадках відповідальність транспортних протоколів за передані дані така ж, як і в протоколу Інтернет. І взагалі, більшість з того, що ви дізналися щодо IP-датаграми та IP-заголовка, повною мірою можна застосувати і до транспортних протоколів. Ви знаєте, що TCP / IP включає два транспортні протоколу: протокол управління транспортуванням (власне, транспортний протокол, TCP) і протокол користувальницьких датаграм (UDP). Орієнтований на з'єднання протокол управління транспортуванням для прийому і передачі даних використовує надійний поточно-байтовий спосіб доставки. Мережеве з'єднання встановлюється у вигляді віртуальної ланцюга. Протокол користувальницьких датаграм ненадійний, не орієнтований на з'єднання, передає і приймає дані за допомогою датаграм.
Що таке порт транспортного рівня?
Поняття «порте» у термінології TCP / IP дуже схоже на IP-адреса комп'ютера. Тільки порт позначає додаток, а IP-адреса - певний комп'ютер (вірніше, його мережевий інтерфейс). Так само як IP-датаграми містять адреси джерела і одержувача даних, транспортні протоколи зберігають номери портів джерела і одержувача. Якщо вищесказане здається вам трохи дивним, давайте розглянемо, що нам відомо про апаратні портах нашого персонального комп'ютера. Може бути, вам доводилося писати програму, посилати дані на порт комп'ютера. Якщо ні, то згадаймо процес друку через паралельний або послідовний порт. Якщо вам доводилося користуватися
модемом, концепція портів TCP / IP має здатися вам ще більш знайомої.
Примітка: У разі модему, комп'ютер приймає і посилає дані через послідовний порт. У разі принтера, дані звичайно тільки надсилаються.
Порти персональних комп'ютерів мають назву і номер. Паралельні порти комп'ютера називаються LPT1 і LPT2. Послідовні - СОМ1 і COM2. У мережі Інтернет номери портів протоколів тільки нумеруються. Паралельний порт LPT1 персональних комп'ютерів роками використовувався для друку даних. Тисячі програмних продуктів знають, що друкувати треба через LPT1. Точно так же порт протоколу Інтернет асоціюється з цілком певним додатком або функцією.
Що таке порт протоколу Інтернет?
Ми вже згадували, що Інтернет містить протоколи для деяких часто використовуваних додатків, наприклад ftp, telnet або електронної пошти. Даним додаткам Інтернет присвоєні так звані офіційні (well-known) номери портів. «Офіційність» порту полягає в тому, що його номер широко відомий і застосовується всіма комп'ютерами в Інтернет, що працюють з даними мережевим додатком або функцією.
Так само як програмісти персональних комп'ютерів користуються портом LPT1 для друку, програмісти Інтернет користуються набором номерів портів для виконання конкретних мережевих додатків. Наприклад, офіційний (загальновідомий) номер порту для простого протоколу передачі файлів (tftp) - 69. Офіційний номер порту telnet - 23. У табл. 1 наведено список широко використовуваних портів протоколів Інтернет.
Таблиця 1. Деякі офіційні номери портів протоколів Інтернет
Номери портів які існують:
Служба луна (Echo Protocol) 7
Час доби (Daytime Protocol) 13
Протокол передачі файлів (File Transfer Protocol) 21
Протокол віддаленого терміналу (Telnet Protocol) 23
Простий протокол передачі пошти 25
(Simple Mail Transfer Protocol)
Точний час (Time Protocol) 37
Хто-є-хто (Whois Protocol) 43
Протокол простої передачі файлів 69
(Trivial File Transfer Protocol)
Інформація про користувачів (Finger Protocol) 79
Як використовується порт UDP?
Протокол, не орієнтований на з'єднання (IP або UDP), можна порівняти з поштовою службою доставки. Якщо ви забули цю аналогію, перечитайте розділ «Словник термінів розширюється» в третьому розділі. Аналогія дозволяє побачити відношення між UDP, портами і додатками. Тут поштове відділення перетворюється на мережний комп'ютер, абонентські скриньки - в порти, а люди, їх орендують, - в прикладні програми.
Протокол Інтернет - це мережева служба доставки. Раніше ви думали, що IP схожий на поштового працівника. Тепер же IP більше схожий на вантажівку, що розвозять листи між поштовими відділеннями, а транспортний протокол - на поштового працівника, сортуються і розкладаються листи з абонентських скриньок.
Вантажівка (IP) розвозить листи (дані) по поштових відділеннях (мережевим комп'ютерам). Поштові працівники (UDP) сортують пошту за номерами абонентських скриньок (портів). Розсортувавши листи, поштові працівники (UDP) кладуть листи (дані) в абонентські скриньки (порти). Клієнти поштового відділення (додатки) періодично перевіряють свої ящики і забирають пошту. Поштові працівники (UDP) не повідомляють клієнтів (додатки) про прихід свіжої кореспонденції (даних), а просто розміщують її в абонентському ящику (порту).
Як використовується порт TCP?
Оскільки TCP є надійним і орієнтованим на з'єднання протоколом, його спосіб використання портів дещо відрізняється від способу UDP. Наприклад, будучи не орієнтованим на з'єднання, UDP просто доставляє дані до певного порту і не забезпечує ніякого з'єднання між передавачем і одержувачем. TCP орієнтований на з'єднання, тому доставка даних для нього - не просто передача в порт, але в першу чергу з'єднання. Наприклад, додаток TCP, що побажала кілька з'єднань одночасно на одному і тому ж порту, може без проблем зробити це - дані не загубляться.
Ми вже говорили про те, що TCP більше схожий на телефонні переговори, ніж на поштову службу. Зараз ми трохи змінимо телефонну аналогію і представимо її в наступному вигляді. Офіс стане мережевим комп'ютером, номер телефону - портом, а телефонний дзвінок - мережевим з'єднанням. Службовці в офісі будуть представляти прикладні протоколи, а їх телефонні переговори - обмін даними. Як і раніше, IP представляє телефонну компанію.
Службовці (прикладні протоколи), що працюють в офісі (мережному комп'ютері), користуються послугами телефонної компанії (IP). Кожному службовцю присвоєно певний телефонний номер (порт). Кілька телефонних ліній (портів) залишаються постійно вільними, тобто ними може скористатися будь-який бажаючий. Кожне робоче місце обладнане телефонним апаратом, з якого можна телефонувати (встановлювати з'єднання), користуючись будь-який не зайнятої в даний момент телефонною лінією (портом) в офісі (мережному комп'ютері).
Телефонна компанія (IP) передає всі вхідні дзвінки в офіс (мережевий комп'ютер), змушуючи телефонні апарати дзвонити. Певний номер (порт) відповідає певному службовцю (з додатком), тобто того, хто відповідає на дзвінок (встановлює з'єднання). На початку службовець (прикладний протокол) з певним номером (портом) завжди відповідає на дзвінок (встановлює з'єднання). Далі, якщо службовець вирішує продовжити переговори зі дзвоном, абонентом, він деякий час розмовляє з ним по телефону (проводить обмін даними).
Службовець (прикладний протокол) відповідає на дзвінки різним чином. Наприклад, він може запросити іншого службовця взяти участь у переговорах. При цьому інший службовець (прикладний протокол) піднімає трубку паралельного апарату (порту) і бере участь у переговорах (встановлює ще одне з'єднання з того ж самого порту). У деяких випадках службовець не хоче займати службову лінію зв'язку (офіційний порт) і перемикає співбесідника на одну з рідко використовуваних ліній (інший порт), щоб ніхто не переривав розмову (обмін даними).
Як номер порту використовується в програмі?
Оскільки транспортний рівень переміщує пакети даних до прикладних програм і від них, він повинен якимось чином розпізнавати ті програми, з якими має справу. І тут на сцену і виступають номери портів. Будь-який додаток, незалежно від того, сервер воно чи клієнт, має унікальний номер порту. Коли програма встановлює з'єднання з мережею, їй присвоюється певний номер порту. Розробляючи додаток-клієнт, зазвичай не треба турбуватися з приводу номера його порту. Клієнт може заздалегідь і не знати його. Але зовсім інша справа - додаток-сервер. Кожного разу, коли клієнт посилає повідомлення, транспортний рівень автоматично присвоює йому правильний номер порту в полі порту джерела повідомлення. У главі 19 описаний процес створення програми-сервера, коли ви можете запросити в мережі призначити йому певний, заздалегідь відомий номер порту. Додаток-сервер, таким чином, може обслуговувати запити, що надходять з офіційних номерів портів, перерахованих, наприклад, у табл. .1.
Що таке протокол користувальницьких датаграм?
UDP вельми схожий на IP в тому сенсі, що вони обидва ненадійні, не орієнтовані на з'єднання протоколи, що користуються датаграмами. Вони обидва переносять дані між комп'ютерами, однак тільки UDP вміє розпізнати то додаток серед багатьох, що працюють всередині комп'ютера, якому призначені дані. Як правило, мережа призначає таких додатків певний номер порту. Отже, UDP користується датаграмами для доставки даних. Точно так само, як IP причіпляють до даних IP-заголовок, UDP причіпляють до них UDP-заголовок. Структура UDP-заголовка набагато простіше. На рис. 5.1 зображена структура UDP-датаграми. UDP-заголовок містить чотири поля: "порт-джерело», «порт-одержувач», «довжина повідомлення» і «контрольна сума».
Довжина UDP-заголовка - вісім байтів. Поля портів складаються з 16-бітових цілих чисел, що представляють номери портів протоколів. Поле «порт-джерело» містить номер порту, яким користується додаток-джерело даних. Поле «порт-одержувач» відповідно вказує на номер порту програми-одержувача даних. Поле «довжина повідомлення» визначає довжину (у байтах) UDP-датаграми, включаючи UDP-заголовок. Нарешті, поле «контрольна сума», на відміну від контрольної суми IP-заголовка, містить результат підсумовування всій UDP-датаграми, включаючи її дані, область яких починається відразу після заголовка.
Примітка: Незважаючи на те, що контрольна сума UDP включає область даних, підраховувати і поміщати її в заголовок не обов'язково. Така поведінка не характерно, наприклад, для протоколів IP або TCP. Останні зобов'язані підрахувати і включити в свій заголовок контрольну суму.
Модуль UDP відстежує появу новоприбулих датаграм, сортує їх і розподіляє (демультіплексірует) відповідно до портами призначення. На рис. 5.2 показаний потік даних, наступний крізь мережевий рівень і модуль UDP до прикладних програм.

Рис .. 2. Потік даних через модуль UDP

Що таке транспортний протокол?
Транспортний протокол (Transport Control Protocol, TCP) поряд з протоколом IP - один з найбільш поширених в Інтернет. Так само, як і UDP, TCP служить для передачі даних між мережним і прикладним рівнями мережевої моделі. У порівнянні з UDP TCP влаштований набагато складніше. І це зрозуміло - адже йому доводиться забезпечувати надійну, потокову, орієнтовану на з'єднання службу доставки даних. Іншими словами, TCP сам стежить за доставкою даних, а також за правильною послідовністю переданих пакетів. На відміну від TCP протокол користувальницьких датаграм (UDP) доставки даних не гарантує. Не забезпечує він і правильної послідовності приходу датаграм.
TCP намагається оптимізувати пропускну здатність мережі, тобто збільшує продуктивність доставки пакетів в Інтернет, наскільки це взагалі можливо. Для цього він динамічно управляє потоком даних в з'єднанні. Якщо буфер приймача даних на приймаючому кінці переповнюється, TCP просить передавальну сторону знизити швидкість передачі.
Розглянемо, яким чином протокол управління транспортуванням користується послугами IP для передачі даних між двома комп'ютерами. Може здатися дивним, що TCP примудряється користуватися ненадійним IP і при цьому залишатися надійним. Також може здаватися дивним, що TCP, користуючись не орієнтованим на з'єднання IP, залишається орієнтованим на з'єднання. Нарешті, як виходить, що TCP доставляє дані у вигляді потоку байтів, тоді як IP пересилає датаграми? Наступні абзаци дадуть відповідь на всі ці питання і усунуть можливі непорозуміння. Осягаючи секрети TCP, ви повинні пам'ятати про те, що його дані завжди переносить IP. To є дані TCP завжди упаковуються в IP-датаграми.
Забезпечення надійності
Для забезпечення надійної доставки та правильної послідовності даних у потоці TCP користується підтвердженнями. Як тільки пункт призначення приймає блок даних, він передає підтвердження про прийом джерела даних. Джерела даних це повідомлення говорить: «Все в порядку. Я прийняв твої дані ». Кожного разу при передачі повідомлення модуль TCP запускає спеціальний таймер. Після закінчення заданого в ньому часу і не отриманні підтвердження TCP повторює спробу передати своє повідомлення. На рис. 5.3 схематично показано роботу такої системи.

Рис. .3. Передача даних з простим підтвердженням про доставку
До нещастя, просте підтвердження про доставку, зображене на рис. 5.3, працює виключно неефективно. Одна зі сторін з'єднання змушена весь час чекати появи підтвердження про доставку від іншої сторони. Незабаром ви дізнаєтеся, що насправді TCP не використовує таку просту схему підтвердження, при якій пакети і підтвердження слідують по черзі один за одним.
Що таке ковзне вікно?
TCP не відсилає один пакет, очікуючи приходу підтвердження, щоб послати наступний. Замість цього він використовує принцип «ковзаючого вікна». Цей принцип дозволяє послати декілька повідомлень і тільки потім очікувати підтвердження. «Ковзаюче вікно» проілюстровано на рис. 5.4.

Рис. .4. Ковзне вікно TCP
Що таке транспортний протокол?
Висловлюючись образно, TCP як би накладає вікно на потік даних, які мають бути надіслані, і передає всі дані, що потрапили у вікно. Прийнявши підтвердження про доставку всіх даних, TCP переміщує вікно далі по потоку і передає наступні потрапили в нього повідомлення. Працюючи відразу з кількома повідомленнями, TCP може одночасно «виставити» їх на мережевий канал і тільки потім чекати приходу підтвердження. Метод ковзаючого вікна значно збільшує продуктивність з'єднання, а також ефективність циклів обміну повідомленнями і підтвердженнями про їх доставку. Рис. 5.5 ілюструє цикл обміну повідомлення-підтвердження TCP.

Рис. .5. Передача повідомлень і підтверджень про доставку по схемі ковзаючого вікна
Передавач і приймач на рис. 5.5 використовують ковзне вікно шириною в три пакети. Тобто передавач спочатку висилає три пакети і тільки після чекає приходу підтвердження. Прийнявши підтвердження про доставку третій останнього пакету, передавач може посилати наступні три.
TCP регулює смугу пропускання мережі, домовляючись з іншою стороною про деякі параметри потоку даних. Причому процес регулювання відбувається протягом всього з'єднання TCP. Зокрема, регулювання полягає в зміні розмірів ковзаючого вікна. Якщо мережа завантажена не сильно і ймовірність зіткнення даних мінімальна, TCP може збільшити розмір ковзаючого вікна. При цьому швидкість видачі даних на канал збільшується і з'єднання стає більш ефективним, оскільки через мережу проходить більше даних за один і той же час.
Якщо, навпаки, ймовірність зіткнення даних велика, TCP зменшує розмір ковзаючого вікна. Якщо розмір ковзаючого вікна, зображеного на рис. 5.4, ​​прийняти рівним восьми пакетів при звичайному мережному трафіку, то в гірших умовах, коли Інтернет сильно завантажений, його розмір може зменшитися до п'яти. Навпаки, коли даних в мережі трохи, розмір вікна може збільшитися, наприклад, до 10-20 пакетів.
Майте на увазі, що представлена ​​на рис. 5.4 і описана в попередніх абзацах схема дещо спрощена. Насправді TCP задає розмір вікна в байтах. Тобто розмір вікна за замовчуванням може дорівнювати кільком тисячам байтів, а не восьми, десяти і дванадцяти байтам, як у попередньому прикладі. Як правило, модуль TCP передає кілька сегментів, перш ніж ковзне вікно заповниться цілком. Більшість систем в Інтернет встановлюють вікно рівним за замовчуванням 4096 байтам. Іноді розмір вікна дорівнює 8192 або 16384 байтам.
Повідомлення TCP
Блок даних TCP прийнято називати повідомленням або сегментом. Обидва ці терміни цілком коректні і широко вживаються в літературі, присвяченій Інтернет. Ми, однак, з причин, які обговоримо нижче, протягом всієї книги будемо вживати термін «сегмента. TCP розглядає свої дані в якості однорідного, неподільного потоку. Тим не менше для доставки даних він вимушений використовувати IP-датаграми. Прикладній програмі, однак, зовсім не обов'язково знати, що її потік даних переносять датаграми. TCP робить цей процес прозорим для всіх додатків, що працюють через нього.
Де б ви не зустріли термін «повідомленням, що відноситься до TCP, можете сміливо підставляти туди термін« сегмента. Чому? Тому, що кожне повідомлення TCP, доставлене датаграм протоколу Інтернет, є насправді ТСР-сегментом. Сегмент TCP складається з TCP-заголовку, TCP-опцій і даних, які переносяться сегментом. На рис. 5.6 зображена структура сегмента TCP. Незважаючи на те, що заголовок показаний складається як би з декількох рівнів, на самому ділі він є послідовним потоком даних, завдовжки як мінімум в 20 байтів. У табл. 5.2 коротко описано призначення кожного поля заголовка TCP. Способи застосування кожного поля будуть обговорені в наступних абзацах.
Таблиця.2. Призначення полів заголовка TCP
Поле заголовка
Призначення
Порт-передавач
Позначає порт протоколу програми-джерела даних.
Порт-приймач
Позначає порт протоколу програми-одержувача даних.
Номер послідовності
Визначає перший байт даних в області даних сегменту TCP.
Номер підтвердження
Визначає наступний байт даних, який приймач розраховує отримати з вхідного потоку.
Довжина заголовка
Довжина TCP-заголовку, виміряна в 32-розрядних словах.
Прапор URG
Якщо встановлено, сповіщає приймає модуль TCP про те, що в сегменті знаходяться дані для невідкладної обробки.
Прапор АСК
Вказівка ​​приймає модулю TCP на те, що поле номер підтвердження містить відповідні дані.
Прапор PSH
Вимога приймає модулю TCP передати дані додатку-одержувачу негайно.
Прапор RST
Запит приймає модулю TCP скинути з'єднання.
Прапор SYN
Запит приймає модулю TCP синхронізувати номера послідовності.
Прапор FIN
Повідомлення приймає модулю TCP про закінчення передачі.
Розмір вікна
Повідомлення приймає модулю TCP про кількість байтів, яке здатний прийняти модуль-передавач.
Контрольна сума TCP
Служить для виявлення ушкоджених при передачі даних.
Покажчик на невідкладні дані
Вказує на останній байт даних, що вимагають невідкладної обробки, що знаходяться в області даних сегменту TCP.
Опції
Зазвичай використовуються спільно з опцією максимальна довжина сегмента (MSS).
Встановлення TCP-з'єднання
Щоб забезпечити надійну передачу даних, а також правильний порядок проходження сегментів, TCP використовує повідомлення-підтвердження про доставку. Для виконання цих завдань потрібно якої-небудь спосіб ідентифікувати передані дані. Також мережа повинна вміти синхронізувати передача даних між обома сторонами дані. Іншими словами, кожна сторона повинна знати, коли можна починати передачу. Сторонам також слід мати уявлення, як позначити той чи інший сегмент. Припустимо, що модуль TCP прийняв пошкоджений пакет. Він повинен мати можливість сповістити модуль-передавач про те, який саме пакет даних потрібно повторити. Перед встановленням з'єднання обидві сторони повинні домовитися про таке, зрозумілою їм обом, способі відзначити кожен пакет.
Певна система обміну повідомленнями-підтверджень з'єднання TCP є частиною більш загального процесу синхронізації обміну даними. Не буде системи - з'єднання може не відбутися. У наступних абзацах описуються поля TCP-заголовку, що служать для обміну підтвердженнями. Для встановлення та припинення з'єднання, а також для відправки та отримання підтверджень TCP заголовок має поля «номер послідовності», «номер підтвердження» і поля прапорів. Кожного разу, бажаючи що-небудь передати за протоколом TCP, програма-додаток звертається до модуля TCP встановити з'єднання. Модуль TCP в свою чергу шле повідомлення TCP з встановленим прапором SYN (синхронізації) віддаленого порту, з яким програма-клієнт хоче встановити з'єднання.
Прапор синхронізації вказує приймаючій стороні (сервера, наприклад), що програма-клієнт бажає встановити з'єднання. Разом з прапором SYN, повідомлення TCP несе в собі 32-бітний номер послідовності, розміщений модулем TCP в поле «номер послідовності». TCP-модуль сервера відповідає сегментом TCP до встановлених прапором підтвердження (АСК) і номером підтвердження. Для того щоб розібратися у процедурі встановлення з'єднання TCP, необхідно розуміти сенс номерів послідовності та підтвердження. У наступному розділі процедура встановлення з'єднання і сенс відповідних номерів вивчаються більш докладно.
Що таке початковий номер послідовності?
Ми вже зазначали вище, що обидві сторони з'єднання TCP повинні ідентифікувати інформацію в потоці даних для того, щоб коректно слати і приймати підтвердження про доставку. Номер послідовності - це те, як TCP позначає дані. Мережеві комп'ютери користуються різноманітними методами для вибору початкового номера послідовності (для наших цілей, однак, ці методи несуттєві). Ви можете розглядати початковий номер послідовності як випадкове число. Значення початкового номера послідовності не грає ніякої ролі.
Початковий номер послідовності являє собою число, пересилається модулем-передавачем TCP модулю-приймачу TCP. Передаючи початковий номер, TCP-модуль як би повідомляє кореспонденту: «Гей, я хочу встановити з тобою з'єднання. Нумерація даних у потоці від мене починається з цього числа ».
Сервер-приймач повідомлення, отримавши запит на встановлення з'єднання, теж не сидить склавши руки. Він посилає назад повідомлення, що містить його власний початковий номер. Модуль TCP генерує будь-яке число, абсолютно не залежне від числа, посланого TCP-клієнтом. Іншими словами, сервер як би повідомляє: «Привіт! Я отримав твій запит на TCP-з'єднання і висилаю номер, з якого почнеться нумерація моїх власних даних ».
Всі TCP з'єднання є дуплексним. Дані слідують в обох напрямах одночасно. Потік даних в одному напрямку абсолютно не залежить від потоку даних у протилежному. У силу двостороння природи з'єднання обидва модулі TCP повинні враховувати і нумерувати дані в кожному напрямку по-різному, а значить, обробляти два початкових номера послідовності.
Підтвердження доставки даних
У TCP-заголовку самого першого, початкового, повідомлення-відповіді сервера модуль TCP встановлює два прапори: синхронізації (SYN), щоб сповістити модуль TCP клієнта про те, що в повідомленні міститься початковий номер послідовності сервера, та підтвердження (АСК), щоб змусити клієнта вивчити вміст поля «підтвердження».
TCP-модуль сервера використовує номер послідовності, прийнятий від клієнта, щоб сконструювати на його основі власний номер підтвердження. Номер підтвердження завжди вказує на номер повідомлення, яке сервер розраховує отримати наступним. Таким чином, в початковому повідомленні-відповіді сервера міститься номер послідовності клієнта, збільшений на одиницю.
Припустимо, наприклад, що модуль TCP клієнта, запитуючої з'єднання, шле номер послідовності, рівний 1000. У відповідь від сервера він отримає початкове повідомлення з числом 1001, встановленим в поле підтвердження. Для модуля-клієнта це виглядає, як ніби сервер сказав: «До речі, таке повідомлення, яке я від тебе чекаю, повинно мати номер 1001».
З'єднання встановлено!
До передачі будь-яких даних модуль TCP клієнта, що запитав з'єднання, повинен підтвердити початкове повідомлення-відповідь, що прийшов з модуля TCP сервера. Тобто, коли модуль TCP клієнта здобуває початкову повідомлення-відповідь від сервера, він повинен посилати «підтвердження підтвердження». (Насправді клієнт підтверджує запит серверу на синхронізацію обміну.)
Повідомлення, надіслане TCP-модулем клієнта, теж буде містити встановлений прапор «підтвердження». У полі «номер підтвердження» TCP-модуль клієнта розміщує початковий номер послідовності, прийнятий від сервера, збільшений на одиницю. (Тепер TCP-модуль клієнта не встановлює прапор синхронізації, так як обидві сторони з'єднання вже синхронізувалися, тобто домовилися про початкові номери своїх послідовностей.) Іншими словами, між TCP-модулями відбувається обмін даними, що складається з трьох стадій:
1. TCP-модуль клієнта намагається встановити TCP-з'єднання, посилаючи запит на синхронізацію, що містить серед іншого початковий номер послідовності.
2. TCP-модуль сервера підтверджує прийом запиту на встановлення з'єднання і в свою чергу шле клієнту запит на синхронізацію з власним початковим номером послідовності.
3. TCP-модуль клієнта підтверджує прийом запиту сервера на синхронізацію.
Що таке номер послідовності?
Номер послідовності однозначно ідентифікує байт даних у потоці даних TCP. Як випливає з назви, номера послідовності послідовні, тобто слідують один за іншим. Однак номера послідовності різних з'єднань TCP необов'язково починаються з одного й того ж числа. Номер послідовності, що встановлюється в кожному сегменті TCP, ідентифікує перший байт в повідомленні. Тобто є зсувом щодо початку потоку даних. Номер послідовності - те ж саме, що лічильник переданих байтів. Він ніби каже: «Перший байт цього пакету - це номер байта (номер послідовності) в потоці даних».
Припустимо, що програма-клієнт бажає передати 2000 байтів даних за допомогою TCP. Припустимо, що проведена синхронізація і наступний номер послідовності буде дорівнює 1251. Припустимо також, що довжина даних у сегменті дорівнює 500 байтам. Відбудуться наступні події:
1. Модуль TCP клієнта передає сегмент TCP, що містить байти з 1 по 500. Номер послідовності, записаний у полі «номер послідовності» сегмента, дорівнює 1251.
2. Модуль TCP клієнта передає сегмент TCP, що містить байти з 501 по 1000. Номер послідовності дорівнює 1751.
3. Наступний сегмент, посланий модулем TCP клієнта, містить байти з 1001 по 1500 з номером послідовності, рівним 2251.
4. Нарешті, модуль TCP клієнта передає дані з 1501 байти по 2000 і встановлює номер послідовності рівним 2751.
TCP-модуль сервера в нашому прикладі шле наступні повідомлення:
1. Прийнявши перший сегмент від клієнта, TCP-модуль сервера відповідає пакетом-підтвердженням з номером підтвердження 1751. Сервер як би говорить:
«Гей, я прийняв твої дані, і наступний сегмент, який я сподіваюся отримати, повинен містити номер послідовності 1751».
2. Прийнявши другий сегмент, TCP-модуль сервера шле номер підтвердження, встановлений у 2251.
3. Прийнявши третій сегмент, TCP-модуль сервера шле номер підтвердження, рівний 2751.
4. Прийнявши четвертий сегмент, TCP-модуль сервера шле номер підтвердження, рівний 3251. (В даний момент TCP-модуль сервера не знає, що передача даних закінчена - TCP-модуль клієнта ще не сповістив про це.)
Дуплексні мережеві служби
Як вже зазначалося, з'єднання TCP є дуплексним. Це означає, що дані випливають одночасно в обох напрямках. Дані, які прямують у одному напрямку, зовсім не залежать від даних, що слідують у протилежному. Оскільки обмін даними TCP є дуплексним, TCP-модулів необхідно підраховувати одержувані і передані дані окремо, і номери послідовності для обох потоків будуть різними.
Якщо вищесказане не справило на вас враження, давайте розглянемо потік даних з точки зору однієї зі сторін з'єднання. Припустимо, що ми розглядаємо потік даних з боку TCP-модуля клієнта. З точки зору TCP-модуля клієнта номер послідовності відраховує або ідентифікує дані, що їх посилають клієнтом у бік TCP-модуля сервера. Номер підтвердження в сегментах, посланих TCP-модулем клієнта, з його точки зору ідентифікує дані, прийняті від TCP-модуля сервера. На рис. 5.7 зображено потік даних і номера послідовності так, як вони виглядають з стопони TCP-модуля клієнта.

Рис. .7. Ідентифікація даних та їх потік з точки зору TCP-модуля клієнта 137
Закінчення з'єднання TCP
З'єднання TCP закінчується обміном пакетами, що складається з двох стадій. Кожна зі сторін, як сервер, так і клієнт, може запропонувати інший закінчити з'єднання. Для цього сторона-ініціатор обміну висилає пакет зі встановленим прапором «закінчення обміну» (FIN). У силу двостороння природи протоколу TCP обидва потоку даних незалежні, і повинні бути завершені окремо. Якщо вам доводилося програмувати в UNIX, останнє твердження попереднього абзацу може видатися підозрілим. Коли в UNIX закривається з'єднання, подальший обмін по ньому стає неможливий. З'єднання TCP працює по-іншому. Навіть після закриття з'єднання (завершення передачі даних) однієї зі сторін з'єднання вона в змозі продовжувати прийом даних від іншої сторони з'єднання.
Думка приймати дані після закриття з'єднання здається дивною на перший погляд. Насправді, встановлений в пакеті прапор FIN є сигналом, що означає, що одна сторона припинила передачу даних. Прихід повідомлення-підтвердження від іншої сторони означає, що обидві сторони домовилися припинити обмін даними в одному напрямку. Починаючи з цього моменту одна з сторін з'єднання буде мовчазно приймати дані, не роблячи ніяких зауважень з їх приводу, а інша мовчазно посилати, не чекаючи ніяких коментарів. Закінчення (закриття) TCP-з'єднання - двоступінчастий процес. Одна сторона виконує активну закриття, а інша - пасивне. Закриття активно, якщо викликано з ініціативи цієї сторони, і, навпаки, пасивно, якщо викликано протилежною стороною з'єднання. Сторона, першою висилає пакет зі встановленим прапором «закінчення з'єднання», є активною. Як правило, модуль TCP, який прийняв пакет з встановленим прапором «закінчення з'єднання», ініціює пасивне закінчення з'єднання. Це просто означає, що пасивна сторона також надсилає повідомлення зі встановленим прапором закінчення. Іншими словами, сторона, яка прийняла повідомлення про закінчення першої, відповідає: «Добре, якщо тобі нічого більше послати, то й мені теж нічого послати тобі». Після того як обидві сторони вислали один одному повідомлення про закінчення і отримали підтвердження про доставку цих повідомлень, з'єднання TCP вважається дійсно закінченим (закритим).
Що таке закриття «наполовину»?
Ви вже знаєте, що в силу двостороння природи TCP-з'єднання, в той час як потік даних в одну зі сторін закінчений, він може зберігатися у зворотному напрямку. Таке закінчення лише одного потоку називається закриттям «наполовину» (half-close). Лише дуже небагато програми TCP потребують або використовують закриття «наполовину». Однак якщо у ваші плани входить розробка додатків Інтернет, ця можливість може коли-небудь і в нагоді.
Що таке заголовок TCP?
З рис. 5.8 видно, що структура TCP-заголовку набагато складніше, ніж у UDP. У наступних абзацах вивчається призначення полів, складових TCP-заголовок.

Рис. 8. Структура сегмента (повідомлення) TCP


Порт джерела і порт одержувача
16-бітові поля джерела і одержувача однозначно визначають посилають і Приймаючі дані додатка або прикладні протоколи. Номери портів джерела і одержувача в сукупності з IP-адресами мережевих комп'ютерів (в IP-заголовку) однозначно ідентифікують будь TCP-з'єднання. Кожна зі сторін TCP-з'єднання називається сокетом (socket). \
Номер послідовності
32-бітове поле номера послідовності визначає перший байт даних з області даних сегменту TCP. Воно відповідає зсуву цього байта щодо початку потоку даних. Кожен байт в потоці даних може бути ідентифікований за допомогою номера послідовності.
Номер підтвердження
32-бітове поле номера підтвердження позначає байт даних, який приймаюча сторона розраховує отримати наступним у потоці даних. Наприклад, якщо останній прийнятий байт мав номер 500, модуль TCP встановить номер підтвердження рівним 501.
Довжина заголовка
Як і в заголовку IP, поле довжини заголовка TCP складається з чотирьох бітів, що позначають довжину заголовка, виміряну в 32-бітових словах. Як і заголовок IP, заголовок TCP зазвичай має довжину в 20 байтів. Область даних починається відразу після заголовка TCP. Таким чином, модуль TCP визначає місце, де починаються дані і закінчується заголовок, просто додаючи полі «довжина заголовка», помножене на чотири байти (32 біта), до першого байту сегменту даних.
Прапори
Тема TCP містить шість однобітних полів прапорів. З трьома з них ми вже зустрічалися. Це прапори синхронізації (SYN), підтвердження (АСК) і прапор закінчення з'єднання (FIN). Наступні абзаци описують залишилися три.
Прапор URG
Даний прапор повідомляє приймає модулю TCP про те, що. покажчик на дані, що вимагають негайної обробки, в полі «невідкладні дані» встановлено, тобто вказує на них. (Модуль TCP повинен обробити невідкладні дані до того, як обробляти що-небудь ще.)
Прапор АСК
Встановлений прапор повідомляє приймає модулю TCP, що поле «номер підтвердження» містить правильний номер підтвердження. Ви знаєте, що даний прапор слугує забезпеченню надійної передачі даних.
Прапор PSH
Встановлений прапор PUSH вимагає від приймаючого модуля TCP виштовхнути (push), тобто негайно вислати прийнятий сегмент даних додатку-одержувачу. Як правило, модуль TCP буферизует прийняті дані. Тобто він не доставляє кожен сегмент окремо, а чекає, поки його буфер наповниться, а потім доставляє всі прийняті сегменти за один раз. Прапор PSH забороняє розміщувати сегменти даних у буфері. Telnet, наприклад, встановлює цей прапор. Натискання на клавіші користувачем негайно потрапляють на сервер Telnet, з яким він працює. Така поведінка усуває можливі затримки у видачі луни від сервера - більшість користувачів Telnet бажають відразу бачити на екрані те, що вони друкують.
Прапор RST
Даний прапор запитує у приймаючої модуля TCP скидання з'єднання. TCP встановлює прапор RST, якщо з з'єднанням трапилася якась проблема. Більшість додатків просто припиняє роботу, прийнявши цей прапор. Прапор RST може застосовуватися в складних розробках для контролю ушкоджень у мережі, збоїв у роботі обладнання та мережевих програм.
Прапор SYN
Прапор SYN просить приймає модуль TCP синхронізувати номера послідовності. Ви вже знаєте, що цей прапор використовується на етапі встановлення з'єднання, щоб повідомити приймача TCP про те, що джерело готується передати новий потік даних.
Прапор FIN
Прапор повідомляє приймає модулю TCP про те, що джерело закінчив передавати дані. Ви знаєте, що цей прапор закінчує з'єднання тільки в тому напрямі, в якому був посланий. Щоб закінчити з'єднання повністю, що приймає модуль TCP повинен також надіслати повідомлення з встановленим прапором FIN.
Розмір вікна
16-бітове поле «розмір вікна» повідомляє приймає модулю TCP кількість байтів, яке збирається прийняти передавач. Ви вже знаєте, що TCP використовує ковзні вікна змінної довжини для збільшення продуктивності та оптимізації пропускної здатності мережі. Значення даного поля визначає розмір цього ковзаючого вікна. Як правило, воно дорівнює кільком тисячам байтів.
Контрольна сума TCP
Як і у випадку UDP, 16-бітове поле контрольної суми TCP містить суму, обчислену по області даних. Протокол вимагає від передавача, щоб він включив обчислену контрольну суму в полі, а від приймача - щоб він обчислив її повторно і порівняв результати.
Примітка: Контрольні суми UDP і TCP обчислюються схожим чином. Однак у випадку UDP включати контрольну суму в датаграму не обов'язково. Навпаки, протокол TCP зобов'язує вставляти контрольну суму в кожен переданий сегмент даних.
Покажчик невідкладних даних
16-бітове поле покажчика визначає положення байта даних в області даних сегменту TCP. Покажчик та прапор невідкладних даних сповіщають приймає модуль TCP про те, що деякі, що вимагають негайної обробки дані знаходяться в сегменті і вказують модулю на них. Ніхто, однак, так і не дав вичерпної відповіді на питання, що ж таке невідкладні дані. Ніхто не визначив відповідальність модуля TCP за їх обробку. Навіть питання, на що ж, власне, звертає увагу покажчик на невідкладні дані, вимагає більш грунтовного обговорення.
Дуглас Камер у другому виданні класичної праці «Межсетевое взаємодія мереж на базі TCP / IP * (Internetworking with TCP / IP, Volume 1, Prentice Hall, 1991) обговорює полі« невідкладні дані »в розділі 12.12, <Дані поза основною смуги пропускання (Out of Band Data). З іншого боку, Річард Стівенс у розділі 20.8 своєї чудової книги ^ TCP / IP в ілюстраціях ^ (TCP / IP Illustrated, Volume 1, Prentice Hall, 1994) пише наступне:
4 ... в багатьох мережевих додатках дані для невідкладної обробки TCP неправильно називаються зданими поза основною смуги пропускання,
Стивене вважає, що ці програми абсолютно невиправдано змішують різні поняття: дані поза смуги пропускання і дані для невідкладної обробки. І він намагається пояснити причину виникнення такої ситуації:
^ Плутанина у зв'язку з невідкладними даними TCP і даними поза основною смуги пропускання виникає через те, що бажаний більшістю інтерфейс прикладного програмування (API) сам по собі відносить дані ^ для невідкладної обробки до категорії даних <поза основним діапазонів,
Щодо точного місця розташування даних для невідкладної обробки Стивене робить наступний коментар:
<Йде тривалий суперечка про те, чи повинен покажчик невідкладних даних вказувати на останній байт цих даних або на байт, наступний за останнім. Початковий стандарт TCP дозволяв тлумачити це двояким чином, однак RFC, присвячений обов'язковим рекомендацій для мережевих комп'ютерів, вносить ясність у цю справу, стверджуючи, що покажчик все-таки вказує на останній байт даних для негайної обробки.
Проблема, однак, у тому, що більшість реалізації мережевих операційних систем (т. зв. Похідні операційної системи Берклі) продовжують використовувати невірне уявлення. Виходить, що цілком лояльне стосовно стандарту TCP мережевий додаток не зможе працювати з більшістю інших мережевих комп'ютерів ^.
Стивене і Камер згодні один з одним у тому, що покажчик невідкладних даних вказує на їх останній байт. Також Стивене підкреслює, що не існує способу, що дозволяє визначити місцезнаходження початку невідкладних даних. Практично одноголосно стверджується, що додатку Telnet необхідно передавати невідкладні дані, оскільки йому доводиться обробляти різного роду керівники послідовності. В даний час очевидно, що від вживання режиму невідкладних даних TCP слід утримуватися. Потрібно або бути впевненим, що всі програми, що працюють з вашим застосуванням, ведуть себе коректно, або взагалі не використовувати цей режим при роботі в Інтернет.
Так само як і у IP, заголовок TCP містить необов'язкове поле «опції» (options). У ході встановлення з'єднання модулі TCP домовляються про максимальну довжину сегмента (MSS) і встановлюють відповідну опцію. Сенс максимальної довжини сегмента той же, що і у максимальної довжини передаваного блоку (MTU) фізичного рівня мережі. Максимальна довжина сегмента визначає максимальний розмір сегмента, який може бути переданий по з'єднанню TCP. TCP оптимізує пропускну здатність мережі, збільшуючи її продуктивність. Опція максимальної довжини сегмента дозволяє скористатися самим великим розміром блоку даних, який ще можна передати. Опція MSS встановлюється тільки в тих повідомленнях, в яких вже встановлено прапор SYN. Однак опція MSS не є предметом обговорення між обома модулями. Кожен з модулів TCP просто повідомляє іншому той MSS, який він в змозі прийняти. Якщо модуль TCP з яких-небудь причин не передає MSS, його партнер вважає, що потрібно користуватися MSS, рівним за замовчуванням 536 байтам.
Що таке інкапсуляція?
Як вже зазначалося, розробка програмного забезпечення для Інтернет в цілому не набагато відрізняється від розробки звичайного програмного забезпечення. Багаторівнева структура мережі і наявність протоколів TCP / IP дозволяє приховати від розробника непотрібні деталі функціонування мережевих програм. Мережеві протоколи беруть більшість рутинної роботи на себе. Вся складність процесу доставки даних в Інтернет укладена в досить простій мережевий інтерфейс. Прикладні дані просто передаються з програми в стек протоколів, цей протокол передає їх наступного і т. д. Ви знаєте, що дуже корисно уявляти, як відбувається весь цей процес. Однак для того, щоб програмувати додатки, досить знати деталі, що стосуються тільки взаємодії програми з верхніми протоколами стека TCP / IP, що переносять дані, тобто інтерфейс мережевого програмування.
Ця і дві попередні голови познайомили вас з різними рівнями мережі на базі TCP / IP. У цих розділах також визначення інтерфейсів між мережевими рівнями і протоколами TCP / IP. Процес переміщення даних крізь стек протоколів насправді являє собою їх інкапсуляцію. Інкапсуляція даних - це їхнє форматування таким чином, щоб вони задовольняли того чи іншого протоколу. У міру проходження крізь стек протоколів дані інкапсулюються в той формат, з яким вміє працювати черговий мережевий рівень. На рис. 5.9 процес проходження даних крізь стек протоколів зображений цілком.
Розробка структури та функцій програми Інтернет практично не відрізняється від розробки будь-якого іншого застосування. Вирішивши передати інформацію з Інтернет, ви спочатку вирішуєте, яким протоколом зручніше скористатися. Дані будуть вміщені в обраний протокол, який відповідає вашим вимогам. Для правильного вибору протоколу необхідно знати, які з них є у вашому розпорядженні і якими особливостями вони володіють. Щоб правильно інкапсулювати дані, необхідно представляти структуру даних обраного протоколу. Сподіваємося, що три останні прочитані глави допоможуть вам зрозуміти цей процес і всі деталі, необхідні для виконання поставлених завдань.

Рис. .9 - Інкапсуляція даних по мірі їх проходження крізь стек протоколів
Що таке прикладний рівень?
Вам напевно вже зрозуміло, що саме відбувається на прикладному мережному рівні. Він включає в себе все, що стосується безпосередньо розв'язуваної прикладної задачі. Іншими словами, в якості програміста додатків Ін-тернет ви, розробляючи програму, разом з тим конструюєте і прикладний рівень.
Будучи прикладним програмістом, ви, за визначенням, займаєтеся розробкою прикладних програм. Конструювання програми тісно пов'язане з виконуваними функціями. Наприклад, якщо вам необхідно написати мережеву програму, вам потрібно обмінятися даними з іншим додатком Інтернет. Для успішної розробки програми Інтернет необхідно знати, як приймати і посилати мережеві дані. Приступаючи до написання, задайте собі питання: «Яким чином моя програма буде обмінюватися даними з Інтернет?» І ви вже знаєте відповідь: просто посилаючи інформацію вниз по стеку протоколів.
Ваша відповідальність за доставку даних закінчується, як тільки прикладна програма передасть їх низлежащего протоколу. Далі кожний наступний рівень у стеці протоколів, крізь який підуть дані, буде виконувати свою власну функцію: визначати адресу, маршрут і транспортувати дані по Інтернет. Щоб задіяти певний протокол, необхідно для початку знати, які з них доступні у вашій системі. Також необхідно знати, де саме в стеку вони знаходяться і розуміти виконувані ними функції. Як правило, прикладні програми взаємодіють з протоколами UDP і TCP.
Додати в блог або на сайт

Цей текст може містити помилки.

Комунікації, зв'язок, цифрові прилади і радіоелектроніка | Реферат
94.9кб. | скачати


Схожі роботи:
Протоколи передачі даних нижнього рівня
Інтернет протоколи
Захищені протоколи
Протоколи і стандарти
Протоколи TCPIP
Алгоритми та протоколи маршрутизації
Протоколи мережної взаємодії
Протоколи маршрутизації RIP і OSPF
Протоколи і методи реалізації VPN мереж
© Усі права захищені
написати до нас