Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
3.10. Протокол TCP
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
Протокол TCP
Загальні відомості про протокол TCP.
Транспортний рівень. Транспортний рівень оперує наскрізно між станціями. Прийнято, що базовий мережевий рівень (тобто IP) може доручати пакети між станціями, можливо, використовуючи при цьому один або більше раутерів (рис. 3.74).
Рис. 3.74. Операції на транспортному рівні.
Транспортний рівень передбачає такі особливості:
більшість застосувань вимагають, щоб транспортний рівень був орієнтований на сполучення, тобто він мусить забезпечувати встановлення і припинення сполучення;
необхідність або можливість наскрізного контролю помилок.
Найбільш поширеним протоколом транспортного рівня є TCP, який використовується понад IP. Протокол TCP перетворює ненадійні послуги IP без встановлення сполучення у послуги пересилання, які
є надійними, орієнтованими на сполучення, повнодуплексними;
здійснюють пересилання потоків, без видимого пакетування;
є наскрізними, тобто діють безпосередньо між двома процесами.
Для забезпечення надійних послуг, орієнтованих на сполучення, TCP ділить вхідний потік байтів на сегменти. Один сегмент, включно зі заголовком і полем даних, випадковим чином поміщається в одну данограму. Останній байт у кожному сегменті ідентифікується байтом поля лічильника, розміщеним у заголовку сегменту.
Коли сегмент прийнятий коректно та непошкодженим, то приймач висилає до надавача спеціальний сегмент підтвердження, який містить байт лічильника останнього коректно прийнятого байта потоку. Якщо надавач очікує підтвердження занадто довго, то він робить паузу (timeout) і повторно висилає сегмент, припускаючи, що відповідна данограма була втрачена. Крім того, TCP буферизує сегменти, які приходять не в потрібному порядку, і знищує здубльовані сегменти, використовуючи для ідентифікації байт лічильника.
Номери портів TCP. Оскільки протокол TCP забезпечує систему доручення між процесами, то він потребує ідентифікувати конкретний процес у двох сполучених прикінцевих системах. Тому кожен процес, який потребує комунікуватися з іншим процесом, ідентифікує себе у системі протоколів TCP/IP абстрактною адресою, яку називають номером (протокольного) порта, тобто номер порта використовується для іменування процесу. Номер порта – це 16-бітове число, яке вживається протоколом станція-станція для визначення того, якому процесу (протоколу вищого рівня або програмі-застосуванню) він повинен доручати вхідні повідомлення. Два процеси можуть комунікуватися між собою, узгодивши номери портів, які вони хочуть використати для комунікації. Номер порта – це адреса для протоколу TCP, бо кожен сегмент містить номер порта для кожного з процесів, які висилають або приймають інформаційні потоки.
Деякі протоколи вищих рівнів, наприклад, SMTP, TELNET або FTP, стандартизовані в системі протоколів TCP/IP, використовують однакові (але різні для кожного протоколу) номери портів у всіх впровадженнях TCP/IP. Такі “призначені” номери портів називають “добре відомими портами” (well-known ports), а відповідні стандартні застосування – “добре відомими послугами” (well-cnown services). Призначення добре відомих портів і контроль за ними здійснюється органом Internet Assigned Number Authority (IANA). У більшості систем призначені порти можуть вживатися тільки системними процесами або програмами привілейованих користувачів. Призначені добре відомі порти охоплюють номери від 0 до 1023. Порти з номерами в діапазоні від 1024 до 65535 не контролюються IANA і можуть вживатися у більшості систем для звичайних програм користувачів.
Конфлікту між двома різними застосуваннями, які пробують використати ті самі номери портів на одній станції, уникають, приписуючи цим застосуванням висилати запит про наявний порт до локального TCP/IP. Оскільки номер порта виділяється динамічно, то ці номери портів можуть відрізнятися від одного виклику застосування до іншого. Конкретніше, для встановлення TCP-сполучення процес повідомляє програмне забезпечення TCP, що він очікує на сполучення на певному номері порта (добре відомому або ні). За означенням такий процес називають сервером. Процес-клієнт, який потребує сполучення зі сервером, запитує своє локальне програмне забезпечення TCP про виділення для нього невикористаного номера порта (в діапазоні 1024..65535) і встановлення сполучення. Як тільки сполучення встановлене, то ці два процеси можуть комунікуватися між собою. Оскільки клієнт встановлює сполучення, то він не потребує вживати добре відомий номер порта, тому програмне забезпечення TCP випадковим чином виділяє для нього один з невикористаних номерів у діапазоні 1024..65535.
Сполучення TCP. Важливою абстракцією TCP є ідея, що сполучення визначене парою кінцевих пунктів цього сполучення. Кінцевий пункт – це пара чисел <станція, порт>. Наприклад, якщо станція 149.144.21.3 (клієнт) доручає електронну пошту до станції 149.144.21.60 (сервер), то сполучення може бути визначене двома кінцевими пунктами:
<149.144.21.3, 2437> і <149.144.21.60, 25>
Зауважимо, що TCP-порт 25 є добре знаним портом для дорученняелектронної пошти.
Завдяки тому, що номери портів клієнтів виділяються випадково і що кожне сполучення визначене парою кінцевих пунктів, декілька клієнтів водночас можуть бути активними на одній станції. Наприклад, декілька повідомлень електронної пошти можуть паралельно пересилатися від станції до поштового сервера.
Ідея визначення сполучення парою кінцевих пунктів важлива також тому, що дозволяє фіксувати номери портів, які виділяються для важливих застосувань. Якщо б це було не так, то система могла б виділити новий номер порта для вхідного сполучення, коли потрібний порт вже використовується, що приводило б до незадовільних результатів.
Процеси. Існує багато означень поняття процес в комп’ютерних системах загального призначення. Найбільш типові з них такі:
програма, що виконується, включно з миттєвими значеннями всіх змінних у пам’яті та в регістрах і поточним значенням програмного лічильника;
“вікно” окремої робочої станції, наприклад, MS-Windows, тощо.
Комунікація між процесами виникає тоді, коли один процес пересилає інформацію до іншого процесу або отримує інформацію від нього, при чому обидва процеси виконуються у тій самій системі або в різних системах, сполучених через мережу. Типові приклади механізмів комунікації між процесами включають файли (обмежені до спільної файлової системи), канали (придатні тільки тоді, коли процеси спільно використовують загальний породжуючий процес), спільну пам’ять, іменовані канали, пересилання повідомлень і гнізда (sockets). Абстракція гнізда є придатним методом здійснення комунікації між процесами, базованої на мережі, в системі UNIX та багатьох інших системах. Гнізда забезпечують програмний інтерфейс до транспортного рівня – TCP (Transmission Control Protocol – протокол управління пересиланням).
Гнізда. Спочатку впровадимо таку термінологію:
Гніздо (socket) – це спеціальний тип дескриптора файлу, який використовується процесом для запиту мережевих послуг від операційної системи.
Адреса гнізда (socket address) – це трійка (3-кортеж)
<протокол, локальна адреса, локальний процес>,
наприклад, для TCP/IP це <tcp, 193.44.234.3, 12345>.
Діалог (conversation) – це комунікаційний зв’язок мідж двома процесами.
Асоціація (association) – це п’ятірка (5-кортеж)
<протокол, локальна адреса, локальний процес, віддалена адреса, віддалений процес>,
яка повністю визначає два процеси, що здійснюють сполучення. Наприклад, для TCP/IP це <tcp, 193.44.234.3, 1500, 193.44.234.5,21>.
Напівасоціація (half-assotiation) – це або <протокол, локальна адреса, локальний процес>, або <протокол,віддалена адреса, віддалений процес>, які визначають кожну половину сполучення. Напівасоціацію також називають гніздом або транспортною адресою, тобто гніздо є кінцевим пунктом комунікації, який може бути іменований та адресований в мережі.
Інтерфейс гнізд є одним з декількох інтерфейсів програмування застосувань (application programming interfaces – API), впроваджений передовсім у системах UNIX. Хоч нестандартизований, він є промисловим стандартом де-факто.
Для ілюстрації розглянемо виклики системи гнізд для протоколу, орієнтованого на сполучення, такого, як TCP (рис. 3.75).
Ініціювання гнізда:
sockfd=socket(family, type, protocol)
Тут family – сімейство адрес, наприклад, AF_UNIX для UNIX-систем; визначає метод адресації.
type - тип інтерфейсу гнізда; може приймати значення SOCK_STREAM, SOCK_DGRAM, SOCK_RAW і SOCK_SEQPACKET.
protocol - може приймати значення UDP, TCP, IP або ICMP.
sockfd - це ціле число, подібне до дескриптора файлу, яке повертається в результаті виклику socket.
Присвоєння (реєстрація) гнізда на адресі порта:
bind(sockfd, localaddr, addrlen)
Тут sockfd - це ціле число, повернене в результаті виклику socket.
localaddr – локальна адреса гнізда, 3-кортеж, який повертається в результаті виклику bind.
Зауважимо, що після виклику bind отримані значення перших трьох параметрів асоціації
<протокол, локальна адреса, локальний процес, віддалена адреса, віддалений процес>.
Вказання готовності до прийняття сполучення:
listen(sockfd, queue-size)
Тут sockfd - це ціле число, повернене в результаті виклику socket.
queue-size – вказує кількість запитів на сполучення, які можна помістити у чергу системи, доки локальний процес не видасть виклик accept.
Прийняття сполучення:
accept(sockfd, foreign-address, addrlen)
Тут sockfd - це ціле число, повернене в результаті виклику socket.
foreign-addr – віддалена адреса гнізда (процесу клієнта), 3-кортеж, який повертається в результаті виклику accept.
Рис. 3.75. Виклики системи гнізд для протоколу, орієнтованого на сполучення.
Зауважимо, що цей виклик accept видається процесом сервера, а не процесом клієнта. Якщо це запит на сполучення, який очікує в черзі на сполучення для даного гнізда, то accept здійснює перший запит до черги і створює інше гніздо з тими самими параметрами, як sockfd; в інших випадках accept затримує (блокує) процес, який здійснює виклик, доки не поступить запит на сполучення.
Запит на сполучення до сервера:
connect(sockfd, foreign-address, addrlen)
Тут sockfd - це ціле число, повернене в результаті виклику socket.
foreign-addr – віддалена адреса гнізда (процесу сервера), 3-кортеж, який повертається в результаті виклику connect.
Цей виклик видає процес клієнта, а не процес сервера.
Висилання і/або приймання даних:
read()
readv(sockfd, buffer, addrlen)
recv()
readfrom()
send(sockfd, msg, len,flags)
write()
Ці виклики можуть використовуватися для висилання або примання даних у встановленій асоціації гнізд. Вони подібні до викликів read і write для файлів у системі вводу/виводу.
Закрити гніздо:
close(sockfd)
Тут sockfd - це ціле число, повернене в результаті виклику socket.
Дещо простіше виглядає схема викликів системи гнізд для протоколу без встановлення сполучення (рис. 3.76).
Рис. 3.76. Виклики системи гнізд для протоколу без сполучення.
Виклики системи гнізд можна розглянути з позиції визначення елементів асоціації, як це показано в табл. .
Таблиця . Виклики системи гнізд та асоціації.
Протокол
Локальна адреса
Локальний процес
Віддалена адреса
Віддалений процес
Сервер, зі сполученням
socket()
bind()
listen()
accept()
Клієнт, зі сполученням
socket()
connect()
Сервер, без сполучення
socket()
bind()
recvfrom()
Клієнт, без сполучення
socket()
bind()
sendto()
Інтерфейси гнізд розрізняють за різними послугами, які вони забезпечують. Гнізда потоку, данограми та порожні гнізда визначають різні послуги, наявні для застосувань.
Інтерфейс гнізда потоку (SOCK_STREAM) визначає надійну послугу, орієнтовану на сполучення, наприклад, через TCP. Дані пересилаються без помилок або дублювання в тому ж порядку, в якому вони вислані. Вбудоване управління потоком для уникнення перевантажень. Не накладено обмежень на обмін даними, які розглядаються як потік байтів. Прикладом застосування, яке використовує гнізда потоку, є програма пересилання файлів (File Transfer Program – FTP).
Інтерфейс гнізда данограми (SOCK_DGRAM) визначає послугу без сполучення, наприклад, череж UDP. Данограми пересилаються як незалежні пакети. Послуга не передбачає жодних гарантій: дані можуть бути втрачені або здубльовані, данограми можуть поступити не в тому порядку, в якому вони висилалися. Не здійснюється дизасемблювання і реасемблювання пакетів. Прикладом застосування, яке використовує гнізда данограми, є мережева файлова система (Network File System – NFS).
Інтерфейс порожніх гнізд (SOCK_RAW) дозволяє безпосередній доступ до протоколів нижніх рівнів, таких, як IP та ICMP. Цей інтерфейс часто вживається для тестування нових впроваджень протоколів. Прикладом застосування, яке використовує порожні гнізда, є команда ping.
TCP забезпечує комунікаційний канал між процесами в будь-якій системі станцій. Канал надійний, повнодуплексний і орієнтований на потік. Для досягнення цієї функціональності драйвери TCP ділять потік даний сесії на дискретні сегменти і дадають заголовок TCP до кожного сегменту. Потім до пакету TCP додається заголовок IP і так скомпонований пакет перевилається через мережу до призначення. Заголовок TCP має численні поля, які використовуються для підтримки функціональності TCP.
Протокол TCP має такі функціональні характеристики.
Одноадресність протоколу. TCP безований на одноадресній моделі мережі і підтримує обмін даними тільки між двомасторонами. Він не підтримує багатоадресну або широкомовну моделі мережі.
Режим зі сполученням. Замість нав’язувати стани всередині мережі для підтримки сполучення, TCP використовує синхронізовані стани між двома кінцевими пунктами. Ці синхронізовані стани встановлюються як частина початкового процесу сполучення, який TCP здійснює як протокол, орієтнований на сполучення. Багато засобів у протоколі передбачені для того, щоб кожен локальний стан був повідомлений або підтверджений віддаленою частиною.
Надійність. На найнижчому рівні комп’ютерні комунікаційні мережі здійснюють ненадійну доставку пакетів. При цьому
пакети можуть бути втрачені або пошкоджені внаслідок помилок передачі, аварій обладнання, перевантаження мережі;
в мережах, які динамічно маршрутизуються, пакети можуть бути доручені в іншому порядку, ніж передавалися, із різними затримками або з дублюванням;
базові мережеві технології можуть диктувати оптимальний розмір пакету або інші обмеження, потрібні для досягнення ефективності передачі.
На найвищому рівні прикладні програми часто потребують передавати великі обсяги даних від одного комп’ютера до іншого. Використання системи ненадійної доручення без встановлення сполучення для пересилання великих обсягів даних викликає потребу вставляти в прикладні програми засоби виявлення помилок і повторної пересилання. Тому одним із основних завдань протоколів вищого рівня є вирішення проблеми здійснення надійного доручення потоків даних. Наявність таких протоколів дозволяє ізолювати прикладну програму від деталей роботи мережі та визначити однорідний інтерфейс для сервісу передавання потоків.
Застосування
Надійний потік (TCP)
Данограма користувача (UDP)
internet (IP)
Мережевий інтерфейс
Рис. 3.77. Протоколи UDP та TCP понад протоколом IP.
На рис. 3.77 зображене концептуальне розшарування UDP і TCP понад IP. TCP забезпечує надійний сервіс потоків, тоді як UDP здійснює ненадійний сервіс доставки датаграм. Прикладні програми застосовують обидва протоколи.
Так само як і UDP, протокол TCP (Transmission Control Protocol) використовує той самий мережевий протокол IP, але на відміну від UDP, забезпечує надійну передачу даних користувача. TCP відноситься до протоколів з встановленням з’єднання, та є транспортним засобом, орієнтованим на потік. “З встановленням з’єднання” означає, що два прикладні процеси, перед тим як передавати дані між собою, встановлюють логічне з’єднання (прозоре для процесів). “Орієнтований на потік” означає, що TCP працює з даними як з потоком, тому на відміну від UDP, процес на приймальній стороні не може сказати якими порціями дані передавалися. Наприклад, процес використовуючи TCP передав дані двома порціями, по 10 та 20 байт відповідно, а на приймальному кінці дані поступили до процесу однією порцією в 30 байт.
TCP забезпечує надійність передавання завдяки таким особливостям:
Дані користувача, передані з прикладного рівня розбиваються на порції, які TCP вважає оптимальними для передачі (в UDP кожна спроба процесу передати дані генерує окрему UDP данограму такого розміру, щоб вмістити всі дані користувача одразу);
Коли TCP генерує сегмент, запускається таймер та очікується підтвердження про правильний прийом сегменту. Якщо підтвердження не прийшло на протязі відведеного таймером часу, то відбувається повторна передача того самого сегмента;
Коли TCP приймає дані, то відсилає підтвердження про правильний прийом. Підтвердження не обов’язково відсилаються для кожного пакету, тобто можна підтверджувати групи з декількох пакетів;
TCP завжди рахує контрольну суму як свого заголовка так і даних користувача. Якщо прийнято TCP сегмент, і при його аналізі виявлено помилку контрольної суми, то він просто ігнорується, при цьому не відсилається ні повідомлення про помилку ні негативне підтвердження. Очікується що джерело не дочекавшись підтвердження про правильний прийом, повторно передасть пакет, що зіпсувався;
Оскільки TCP сегменти передаються як IP-данограми, а IP-данограми можуть прийти у порядку, відмінному від їх передачі, TCP при необхідності проводить сортування пакетів та передає дані користувачу у правильному порядку;
Оскільки IP данограми можуть дублюватися, TCP ігнорує продубльовані пакети;
TCP забезпечує контроль потоку даних. Кожна сторона має буфер певного розміру, тому TCP не дозволяє собі передавати даних більше ніж приймальна сторона погоджується прийняти. Це дозволяє уникати переповнення буферів в повільних комп’ютерів що працюють з набагато швидшими від них машинами.
Властивості сервісу надійного доручення.
Інтерфейс між прикладною програмою і сервісом дорученняTCP/IP може бути охарактеризований такими п’ятьома властивостями:
Орієнтація на потоки. Коли дві прикладні програми (процеси користувача) передають великі обсяги даних, то ці дані трактують як потік бітів, поділених на 8-бітові октети, які називають байтами. Надійний потоковий сервіс забезпечує на приймальній стороні таку саму послідовність октетів, яку формує передавач.
З’єднання віртуальних кіл. Модулі програмного забезпечення протоколу в двох операційних системах комунікуються, щоб передати повідомлення через internet, перевіряють, чи передача є авторизована і тоді обидві сторони готові до обміну інформацією - встановлене з’єднання. Якщо з будь-яких причин з’єднання порушується, то обидві машини виявляють обставини і повідомляють відповідні прикладні програми. Це називають віртуальним колом.
Буферизоване передавання. Щоб зробити передавання даних більш ефективном та мінімізувати мережевий трафік, відповідний інструментарій збирає достатню кількість даних з потоку, щоб заповнити датаграму доцільної довжини перед передачею через internet. При цьому передбачений механізм проштовхування (push) для випадку, коли буфер ще не заповнений, а дані повинні бути негайно передані.
Неструктурований потік. Сервіс потоків TCP/IP не підтримує структурованих потоків даних. Прикладна програма, яка використовує сервіс потоків, повинна розуміти вміст потоку і погодити формат потоку, перш ніж ініціювати з’єднання.
З’єднання з повним дуплексом. З’єднання, які здійснюються сервісом потоків TCP/IP, дозволяють узгоджену передачу даних в обидвох напрямках (повний дуплекс). З точки зору прикладного процесу повний дуплекс складається з двох незалежних потоків, які переміщаються в протилежних напрямках без видимої взаємодії. Потоковий сервіс, який дозволяє обмежити потік в одному напрямку при наявності даних для передачі в протилежному напрямку, називається півдуплекс (half-duplex). Перевага повного дуплексу полягає в тому, що програмне забезпечення протоколів нижчого рівня може висилати контрольну інформацію для одного потоку до джерела в датаграмах, які переносять інформацію в протилежному напрямку. Це зменшує трафік мережі.
Забезпечення надійності.
Операції TCP
Першою фазою сполучення TCP є встановлення сполучення. Це вимагає трьохходового підтвердження (three-way handshacke), чим досягається, що обидві сторони сполучення мають однозначне розуміння послідовності номерного простору віддаленої сторони сполучення. Операції встановлення сполучення такі:
локальна система висилає до віддаленого кінця сполучення початковий номер послідовності для віддаленого порта, використовуючи пакет SYN;
віддалена система відповідає підтвердженням (ACK) початкового номеру послідовності та початковим номером послідовності віддаленого кінця у пакеті SYN відповіді;
локальний кінець відповідає підтвердженням (ACK) цього віддаленого номера послідовності - сполучення встановлене.
Операції цього алгоритму зображені на рис. 3.78.
Рис. 3.78. Трьохходове встановлення сполучення TCP.
Вплив цього протокольного обміну на характеристики полягає в тому, що дві системи потребують півтори періоду обігу петлі (RTT) для синхронізації станів перед висиланням даних.
Після встановлення сполучення протокол TCP керує надійним пересиланням даних між двома системами. Алгоритми, які визначають різні таймери повторного пересилання, можуть бути переозначені багато разів. TCP – це протокол з ковзним вікном і загальний принцип управління потоком базується на управлінні розміром оголошеного вікна та управлінні паузами повторного пересилання з метою оптимізації характеристик протоколу при відомих затримках і втратах пакетів у сполученні. Настроювання стеку протоколів TCP для отримання оптимальних характеристик у високошвидкісних локальних мережах з малою затримкою вимагає інших встановлень, ніж для оптимальних характеристик сполучення через комутовані телефонні лінії, і ще інших встановлень для відповідності вимогам високошвидкісних глобальних мереж. Хоч TCP пробує дослідити значення добутку затримка ( ширина_смуги для сполучення і пробує автоматично оптимізувати швидкості потоків для оцінених параметрів мережевого шляху, однак окремі оцінки неточні і відповідні зусилля TCP оптимізувати поведінку можуть бути не цілком успішними.
Іншим критичним аспектом є те, що TCP є адаптивним протоколом управління потоком. TCP використовує основний алгоритм управління потоком для збільшення швидкості потоку даних, доки мережа не просигналізує про досягнення певного рівня насичення (звичайно пов’язаного з втратою пакетів). Тоді темп пересилання даних зменшується. Коли ж надійне пересилання встановиться знову, темп пересилання знову повільно зростає. Якщо ж надійність потоку не відновлена, то темп пересилання зменшується аж до висилання одного пакету і цілий адаптивний процес управління потоком стартує від початку.
Цей процес має ряд наслідків, пов’язаних з якістю послуг. По-перше, TCP поводиться адаптивно, а не прогнозовано. Алгоритм управління потоком побудований для збільшення темпу пересилання потоку аж до заповнення наявної мережевої перепускної здатності, а також для швидкого зменшення цього темпу, коли наявна перепускна здатність зменшується, наприклад, внаслідок взаємодії з іншим трафіком. Практично завжди існує протиріччя між ефективністю використання мережі та забезпеченням прогнозованих характеристик сесії. TCP має низький рівень прогнозованості перепускної здатності, але забезпечує ефективне використання мережевих ресурсів.
Інтерактивність у TCP. Інтерактивні протоколи звичайно скеровані на забезпечення взаємодії на рівні окремих символів, при чому кожен символ пересилається окремим пакетом, наприклад, echo. Взаємодія протоколів, яка це підтримує, показана на рис. 3.79.
Рис. 3.79. Інтерактивний обмін.
Це становить 2 байти даних, згенерованих чотирма пакетами TCP/IP, або 160 байтів службового навантаження протоколу. У TCP зроблено невеликі вдосконалення цього обміну шляхом використання вкладеності (piggybacking), коли ACK переноситься у тому самому пакеті, що й дані, і затриманого підтрвердження, коли ACK затримується на час до 200 мс перед висиланням, що дає застосуванням сервера можливість згенерувати дані, в які може бути вкладене підтвердження. Результуючий обмін протоколу зображено на рис. 3.80.
Рис. 3.80. Інтерактивний обмін з використанням затриманого підтвердження.
Для локальних мереж з малою затримкою цей протокольний обмін забезпечує прийнятні характеристики. Такий обмін окремим символом даних і його ехо виникає кожних 16 мс в мережі Ethernet, що відповідає інтерактивному темпу в 60 символів за секунду. Коли мережева затримка зростає (наприклад, у WAN), ці малі пакети можуть бути джерелом перевантажень.
Рис. 3.81. Інтерактивний обмін у WAN.
Механізм TCP, адресований до цих перевантажень малими пакетами, описаний в документі RFC 896 і відомий як алгоритм Nagle. Він забороняє надавачу пересилати будь-який додатковий малий сегмент, доки сполучення TCP має вислані непідтверджені малі сегменти. Для LAN ця модифікація алгоритму має незначний вплив, однак для WAN вприв дуже суттєвий, бо кількість малих пакетів зменшується у безпосередній кореляції з рівнем перевантаженості мережевого шляху. За це збільшуються варіації тривалості сесії (jitter) протягом періоду обігу петлі (RTT). Тому застосування, чутливі до цих варіацій, не використовують цей алгоритм.
Рис. 3.82. Інтерактивний обмін з використанням алгоритму Nagle.
TCP не є ефективним алгоритмом для пересилання інтерактивного трафіку. Типовими для протоколу в LAN є витрати 120 байтів службового навантаження на 2 байти корисного вмісту. При роботі через WAN алгоритм Nagle може помітно покращити цю ефективність, збільшуючи кількість байтів корисного навантаження у кожній транзакції, хоч це і приводить до певного збільшення варіацій тривалості сесії.
-------
Сервіс надійного доручення гарантує доручення потоку даних, висланих від однієї машини до іншої без повторів або втрат даних. При цьому програмне забезпечення протоколу, який здійснює таку передачу, базується на комунікаційній системі, яка пропонує лише ненадійну доставку пакетів.
Більшість надійних протоколів застосовує фундаментальну техніку, відому як позитивне підтвердження з ретрансмісією (positive acknowledgement with retransmission). Ця техніка передбачає, що приймач, який комунікується із джерелом, висилає назад підтвердження (acknowledgement, скорочення - ACK) - повідомлення про прийом даних. Передавач запускає таймер, коли він передає пакет, очікує підтвердження перед передачею наступного пакету, і , якщо час очікування завершився без отримання підтвердження, повторно передає (ретрансмітує) пакет.
Рис. 3.83. Функціонування протоколу передавання з підтвердженням та ретрансмісією.
На рис. 3.83 проілюстровано роботу найпростішого протоколу передавання даних з використанням позитивного підтвердження і з ретрансмісією, в якому передавач очікує підтвердження для будь-якого переданого пакету. Вертикальні стрілки вниз представляють зростання часу і діагональні лінії між ними позначають передавання пакетів. На рис. 3.84 показано ситуацію, коли пакет втрачений або пошкоджений. Штрихові лінії показують , що відбувалося б, якби пакет не був втрачений.
Рис. 3.84. Функціонування протоколу при втраті пакету.
Остання проблема надійної доставки - усунення дублювання пакетів. Дублювання виникає при занадто великій затримці при передачі, внаслідок чого наступає ретрансмісія. Усунення дублювання можливе, бо сам пакет і його підтвердження будуть здубльовані. Надійні протоколи виявляють здубльований пакет через присвоєння кожному пакету номера в послідовності та запам’ятовування на приймальній стороні, які номери псслідовності вже прийняті.
Повнодуплексність. TCP є протоколом з повним дуплексом. Він дозволяє обидвом сторонам сполучення висилати і приймати дані в контексті одного сполучення TCP.
Орієнтація на потоки. Хоч TCP використовує пакетну структуру для пересилання в мережі, однак TCP є справжнім потоковим протоколом і операції рівня застосувань мережі не є прозорими. Певні протоколи застосувань у явному вигляді інкапсулюють кожну транзакцію, для кожної операції висилання мусить бути узгоджена операція читання. Таким чином Сегментація потоку даних від застосування в логічній структурі потоку даних зберігається у всій мережі. На відміну від цього, протокол TCP не зберігає таку структуру в потоці даних. Наприклад, застосування TCP можуть послідовно вислати три блоки даних у мережеве сполучення, які можуть бути об’єднані у віддаленому приймачі однією операцією читання. Розмір блоку даних (сегменту), який використовується у TCP-сесії, повинен бути узгоджений на початку сесії. Висилач має намір використовувати найбільшу довжину сегменту для пересилання даних у рамках обмежень на розмір сегменту у приймача, максимальної довжини сегменту, сконфігурованої в надавача і максимальної довжини нефрагментованого пакету, яку підтримує шлях в мережі (Maximum Transfer Unit – MTU). Значення MTU для шляху періодично оновлюється для корекції всіх змін, які могли виникнути в мережі під час активності сполучення TCP.
Адаптація швидкості пересилання. TCP є протоколом з адаптацією швидкості пересилання даних для того, щоб швидкість пересилання даних була пристосована до умов завантаженості мережі і до здатності обробки даних приймачем. Швидкість пересилання даних не визначена наперед. Якщо приймач і мережа мають додаткову ємність, то надавач TCP може вислати більше даних у мережу, використовуючи наявну перепускну здатність. Навпаки, якщо мережа перевантажена, то надавач TCP може зменшити швидкість пересилання до зменшення завантаженості мережі. Це дозволяє досягнути максимально можливої швидкості пересилання даних без порушення цілісності даних та їх втрати.
Ідея ковзного вікна.
Як видно з повищих рисунків, час простою мережі між передачею пакету і отриманням підтвердження може бути значним. Для підвищення ефективності передачі потоків даних використовується ідея ковзного вікна. Протокол ковзного вікна використовує смугу мережі краще, бо передавач може передати багато пакетів перед очікуванням підтвердження. Протокол розміщає мале вікно фіксованого розміру над послідовністю пакетів і передає всі пакети, розміщені всередині вікна. Пакет називають непідтвердженим (unacknowledged), якщо він висланий, але підтвердження не отримане. Практично число непідтверджених пакетів обмежене розміром вікна. Властивості протоколу ковзного вікна залежать від розміру вікна і швидкості, з якою мережа приймає пакети. Ключова ідея полягає в тому, що всі пакети у вікні передаються, перш ніж буде отримане будь-яке підтвердження. На рис. 5.20 показано, що після отримання підтвердження для пакету 1 вікно “ковзає” і передається наступний пакет (9-й). Рис. 3.85 ілюструє операції протоколу з ковзним вікном, який передає три пакети.
Початкове вікно
1
2
3
4
5
6
7
8
9
10
...
(а)
Вікно ковзнуло (
1
2
3
4
5
6
7
8
9
10
...
(б)
Рис. 3.85. Ковзне вікно.
Порти, з’єднання і кінцеві точки.
Як і UDP, протокол TCP застосовує поняття номера протокольного порта для ідентифікації остаточного призначення в машині. Порту відповідає мале ціле число, яке ідентифікує його. Однак, фундаментальною абстракцією для TCP є з’єднання (connection), а не порт; з’єднання ідентифікується парою кінцевих точок. TCP визначає кінцеву точку (endpoint) як пару цілих <вузол, порт>, де вузол є IP-адреса вузла і порт - TCP-порт цього вузла. Наприклад, кінцева точка <128.10.2.3,25> визначає порт 25 на машині з IP-адресою 128.10.2.3. З’єднання може бути виражене як <18.26.0.36, 1069>&<128.10.2.3,25>. Зауважимо, що даний номер TCP-порта може бути розділений серед багатьох з’єднпнь на тій самій машині, бо з’єднання в TCP ідентифікується парою кінцевих точок.
Пасивні та активні відкриття.
Оскільки TCP є протоколом, орієнтованим на з’єднання, то прикладна програма на обидвох кінцевих точках з’єднання мусить узгодити, що з’єднання є бажане. На одному кінці з’єднання прикладна програма здійсює функцію пасивного відкриття, контактуючи з операційною системою та відзначаючи, чи вона може погодитися на майбутнє з’єднання. При цьому операційна система виділяє номер TCP-порта для кінцевої точки. Прикладна програма на другому кінці здійснює запит активного відкриття для встановлення з’єднання. Ці два програмні модулі TCP повинні скомунікуватися, щоб встановити і перевірити з’єднання.
Рис. 3.86. Приклад операції протоколу з ковзним вікном, який передає три пакети.
Сегменти, потоки і номери послідовностей.
TCP розглядає потік даних як послідовність октетів (байтів), які для передачі поділені на сегменти. Звичайно один сегмент передається однією данограмою. TCP застосовує спеціалізований механізм ковзного вікна для вирішення двох важливих задач: ефективність передавання (описано вище) та управління потоком. Управління потоком дозволяє обмежити передавання, доки не буде достатньо місця в буфері для нагромадження більшої кількості даних.
Поточне вікно
1
2
3
4
5
6
7
8
9
10
11
...
(
(
(
Рис. 3.87. Управління потоком через механізм ковзного вікна.
Механізм ковзного вікна TCP оперує рівнем октетів, а не сегментів чи пакетів. Октети потоку даних пронумеровані послідовно і передавач утримує три показники, асоційовані з деяким з’єднанням (див. рис. 3.87).
На рисунку зображений приклад ковзного вікна. Октети до 2 передані і підтверджені; октети від 3 до 6 передані, але не підтверджені; октети від 7 до 9 не передані, але можуть бути передані без затримки; октети від 10 і вище не можуть бути передані, доки вікно не переміститься.
Змінний розмір вікна і управління потоком.
Одна різниця між протоколом ковзного вікна TCP/IP та простим протоколом ковзного вікна, описаним вище, полягає в тому, що TCP дозволяє змінювани розмір вікна в часі. Кожне підтвердження, яке визначає, скільки октетів буде передано, містить оголошення вікна (window advertisement), яке визначає, скільки додаткових октетів даних приймач підготований прийняти. Можна розглядати оголошення вікна як визначення поточного розміру буфера. Відповідно до збільшення оголошеного розміру вікна передавач збільшує розмір свого ковзного вікна і приступає до передачі октетів, які не були підтверджені. У відповідь на зменшення оголошеного розміру вікна передавач зменшує розмір свого вікна і зупиняє передачу октетів поза границями вікна.
Перевагою використання змінного розміру вікна є те, що воно передбачає здійснення управління потоком. Якщо буфер приймача стає заповненим настільки, що не може сприйняти більше пакетів, то він висилає оголошення меншого вікна. В екстремальному випадку приймач оголошує розмір вікна, рівний ную, і тим зупиняє передачу. Пізніше, коли місце у буфері з’явилося, приймач оголошує ненульовий розмір вікна і знову вмикає потік даних.
Наявність механізму управління потоком є важливе в internet-оточенні, оскільки комп’ютери з різними швидкостями і розмрами зв’язуються між собою через мережі і раутери з різними швидкостями і ємностями. При цьому існує дві проблеми:
internet-протоколи потребують наскрізного управління потоком між джерелом і призначенням;
internet-протоколи потребують механізму управління потоком, який дозволяє проміжним системам (напр., раутерам) управляти джерелом, яке висилає більший трафік, ніж ця проміжна система може допустити.
Коли проміжна машина перевантажена, то ця проблема називається переповнення (congestion) і механізм, який дозволяє вирішити проблему, відомий як управління переповненням. TCP/IP не має чіткого механізму управління переповненням.
Формат сегменту TCP.
Одиниця передавання між програмним забезпеченням TCP на двох машинах називається сегментом. Сегментами обмінюються для встановлення з’єднання, для передавання даних, для пересилання підтвердження, для оголошення розміру вікна і для закриття зв’язку. Обмін сегментами TCP відбувається шляхом їх інкапсуляції в IP-данограму (рис. 3.88). Оскільки переміщення підтвердження від станції A до станції B може здійснюватися в тому самому сегменті, що й передавання даних від машини A до машини B, то підтверджнення відноситься до даних, переданих від B до A. Подальший рис. 3.89 показує формат TCP-сегменту.
Рис. 3.89. Формат TCP-сегменту.
Будь-який сегмент ділиться на дві частини: заголовок і дані. TCP-заголовок переносить інформацію, потрібну для ідентифікації та управління. Звичайно розмір TCP-заголовку становить 20 байтів (при відсутності опцій). В TCP-сегменті як опції так і дані можуть бути відсутні.
Значення полів в TCP заголовку:
Номер порта джерела (source port number)
ідентифікатор процесу, що передав пакет;
Номер порта призначення (destination port_number)
ідентифікатор процесу, для якого пакет призначений;
Номер послідовності (sequence number)
ідентифікатор першого байта в пакеті з потоку даних від передаючого TCP модуля до приймаючого TCP модуля, тобто кожен байт в потоці має свій номер. Він не обов’язково починається з 0. Оскільки TCP забезпечує дуплексний зв’язок, дані незалежно можуть передаватися в обох напрямках, кожна сторона веде свій незалежний ідентифікатор послідовності. Ідентифікатор послідовності наступного пакету збільшується на число рівне кількості байтів даних присутніх в попередньому пакеті;
Номер підтвердження (acknowledgment number)
номер наступного ідентифікатора послідовності (sequence) який очікується на приймальній стороні, тим самим підтверджує, що всі попередньо передані дані прийнято правильно;
Довжина заголовку (header length - HLEN)
довжина TCP заголовку в 32-х розрядних словах. Оскільки поле займає 4 біти, максимально можлива довжина заголовку становить 15(4=60 байт. Нормально (коли TCP опції не присутні) тут записано значення 5, тобто заголовок займає 20 байт;
Резерв (reserved)
зарезервовано для майбутнього використання;
Коди прапорців (flags)
поле, що займає 6 біт які розглядаються як 6 прапорців, один або більше з яких можуть бути встановлені в 1.
URG - в даному TCP сегменті присутні термінові дані;
ACK - поле acknowledgment використано для підтвердження прийнятих даних, тобто пакет являється підтвердженням, що не обмежує можливості даного пакету одночасно нести і дані користувача;
PSH - передати прийняті TCP модулем дані пакету якомога швидше до процесу користувача;
RST - ініціатива в розриві або відмова встановлення зв’язку;
SYN - синхронізувати ідентифікатор послідовності, проводиться при встановленні зв’язку;
FIN - джерело пакета повідомляє що воно завершило передавати свою інформацію в данїй TCP сесії, хоча не відмовляється від приймання даних від призначення;
Коли в пакеті встановлений SYN, або FIN прапорець, то наступний ідентифікатор послідовності додатково збільшується на 1.
Розмір вікна (windows size)
кількість байт, яку може (погоджується) прийняти джерело TCP сегменту. Саме за допомогою windows size (збільшуючи чи зменшуючи його значення) проводиться контроль потоку інформації на обох сторонах зв’язку;
Контрольна сума (checksum)
контрольна сума сегменту, що покриває як TCP заголовок так і дані. Вона рахується так само як для UDP, використовуючи псевдо-заголовок. На відміну від UDP, в TCP використння контрольної суми завжди є обов’язковим;
Показник терміновості (urgent pointer)
це поле має зміст (аналізується) коли в пакеті встановлено URG прапорець. Число записане тут є позитивним зміщенням, яке треба додати до ідентифікатора послідовності пакету, для того щоб можна було визначити останній байт термінових даних в пакеті;
Опції (options)
додаткові поля заголовку, які розширюють можливості TCP. Вони мають змінну довжину але завжди вирівнюються на 32-х розрядне слово за допомогою поля Набивка. Одна з найчастіше використовуваних опцій це MSS (maximum segment size) - максимальний розмір TCP сегмента який TCP модуль погоджується приймати (передається на фазі встановлення зв’язку);
Дані (data)
дані користувача, кількість байт може бути некратна 32-х розрядним словам.
Поля Порт джерела та Порт призначення містять номери портів TCP, які ідентифікують прикладну програму і кінцеву ...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора