23.Міжмережний протокол tcp. Передача повідомлень.

Повідомлення клієнту від програми TCP

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

Надається наступна інформація:

местное имя соединения	всегда
строка отчета	всегда
адрес буфера	посылка и получение данных
количество байт (счетчик полученных байт)	получение данных
флаг проталкивания	получение данных
флаг срочности	получение данных

Інтерфейс програми TCP з протоколом більш низького рівня

Програма протоколу TCP для реальної посилки інформації з мережі, а також для її отримання робить запити до модуля протоколу нижнього рівня. Одним із прикладів такої реалізації є система ARPA Internetwork, де модулем нижнього рівня є Internet протокол (IP).

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

Тип сервісу = пріоритет: звичайний, затримка: нормальна,

пропускна здатність: нормальна, надійність: нормальна,

тобто 00000000

Час життя = одна хвилина, або 00111100

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

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

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

24.Міжмережний протокол tcp. З’єднання по протоколу tcp.

Робота з сполуками

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

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

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

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

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

Встановлення з'єднання

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

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

Найпростіша процедура підтвердження трьох шляхів показана нижче на малюнку 7. Малюнки слід інтерпретувати в такий спосіб. Для зручності кожен рядок пронумерована. Праві стрілки (->) показують виліт TCP сегмента від програми TCP A в програму TCB B, або ж отримання сегмента програмою B з програми A. Ліві стрілки (<-) показують зворотні процеси. Три крапки (...) показує сегмент, який все ще затримується в мережі. "XXX" вказує на сегмент, який втрачено або відкинутий. Коментарі з'являються в дужках.

Тут "стану" програми протоколу TCP відповідають моменту відразу після посилки або отримання сегмента (вміст цього сегмента показано в середній колонці кожного рядка). Вміст сегмента в наводиться у скороченій формі і являє собою номер черги, прапори управління і поле ACK. Інші поля сегмента, такі як вікно, довжина і поле даних залишаються за рамками нашого інтересу.

.	TCP A	.			TCP B
1	CLOSED	.			LISTEN
2	SYN-SENT	-->	<SEQ=100><CTL=SYN>	-->		SYN-RECEIVED
3	ESTABLISHED	<--	<SEQ=300><ACK=101><CTL=SYN,ACK>	<--		SYN-RECEIVED
4	ESTABLISHED	-->	<SEQ=101><ACK=301><CTL=ACK>	-->		ESTABLISHED
5	ESTABLISHED	-->	<SEQ=101><ACK=301><CTL=ACK><DATA>	-->		ESTABLISHED

Основна процедура підтвердження трьох шляхів длясинхронізації з'єднання Малюнок 7.

На рядку 2 малюнка 7 програма TCP A починає з посилки сигналу SYN, показуючи тим самим, що вона буде використовувати номери черги, починаючи з номера 100. На рядку 3 програма TCB B посилає сигнал SYN, а також підтвердження про те, що сигнал SYN з боку програми TCP A отриманий. Зауважимо, що поле підтвердження інформує про те, що програма TCP B в даний момент чекає отримання номера 101. Останнє також підтверджує, що сигнал SYN вже зайняв місце в черзі під номером 100.

На рядку 4 для відправленого програмою TCP B у рядку 3 сигналу SYN програма TCP A дає відповідь за допомогою порожнього сегмента, що містить сигнал ACK. У рядку 5 програма TCP A передає по мережі вже якусь порцію даних. Зауважимо, що сегмент у рядку 5 має той же номер черги, що був у сегмента у рядку 4, оскільки сигнал ACK в черзі місця не займає (якби це було не так, то нам слід було обзавестися підтвердженням-ACK-для самого підтвердження!) .

На малюнку 8 показана та ж ініціалізація з незначними ускладненнями. Кожна програма TCP проходить по черзі стану CLOSED, SYN-SENT, SYN-RECIEVED і нарешті, ESTABLISHED.

.	TCP A	.			TCP B
1	CLOSED	.			CLOSED
2	SYN-SENT	-->	<SEQ=100><CTL=SYN>	...
3	SYN-RECEIVED	<--	<SEQ=300><CTL=SYN>	<--	SYN-SENT
4	.	...	<SEQ=100><CTL=SYN>	-->	SYN-RECEIVED
5	SYN-RECEIVED	-->	<SEQ=100><ACK=301><CTL=SYN,ACK>	...	.
6	ESTABLISHED	<--	<SEQ=300><ACK=101><CTL=SYN,ACK>	<--	SYN-RECEIVED
7	.	...	<SEQ=101><ACK=301><CTL=ACK>	-->	ESTABLISHED

Одночасна синхронізація з'єднання малюнок 8

Головною причиною для застосування підтвердження трьох шляхів є спроба запобігти виникненню збоїв при отриманні старих дублікатів, ініціюють з'єднання. Для роботи з підтвердженням трьох шляхів придумано спеціальне контрольне повідомлення - перезавантаження (reset).

Якщо отримує сигнал програма TCP знаходиться не в синхронізованому стані (тобто в SYN-SENT, SYN-RECEIVED), то вона повертає сигнал LISTEN, показуючи, що вона отримала прийнятний сигнал перезавантаження. Якщо ж програма TCP знаходиться в одному з синхронізованих станів (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), то вона ліквідує з'єднання і проінформує про це свого клієнта. Ми обговоримо нижче таку ситуацію при розгляді "наполовину відкритих" з'єднань.

.	TCP A	.			TCP B
1	CLOSED	.			LISTEN
2.	SYN-SENT	-->	<SEQ=100><CTL=SYN>	...		.
3.	(дубликат)	...	<SEQ=90><CTL=SYN>	-->		SYN-RECEIVED
4.	SYN-SENT	<--	<SEQ=300><ACK=91><CTL=SYN,ACK>	<--		SYN-RECEIVED
5.	SYN-SENT	-->	<SEQ=91><CTL=RST>	-->		LISTEN
6.	.	...	<SEQ=100><CTL=SYN>	-->		SYN-RECEIVED
7.	SYN-SENT	<--	<SEQ=400><ACK=101><CTL=SYN,ACK>	<--		SYN-RECEIVED
8.	ESTABLISHED	-->	<SEQ=101><ACK=401><CTL=ACK>	-->		ESTABLISHED

Отримання старого дубліката сигналу SYN Рисунок 9

В якості простого прикладу розглянемо ситуацію з отриманням старих дублікатів на рисунку 9. На рядку 3 старий дублікат сигналу SYN досягає програму TCP B. Остання не може визначити, що це старий дублікат, і тому відповідає звичайним чином (рядок 4).

Програма TCP A виявляє помилкове значення в поле ACK і тому повертає сигнал RST (перезавантаження). При цьому значення поля SEQ вибирається таким чином, щоб зробити сегмент правдоподібним. Про грама TCP B після отримання сигналу RST переходить в стан LISTEN. Коли на рядку 6 сигнал SYN, дійсний, а не застарілий, досягає програму TCP B, процес синхронізації відбувається нормально. Якщо ж сигнал SYN на рядку 6 досягає програму TCP B перш сигналу RST, може виникнути більш складна комбінація обміну з посилкою RST в обох напрямках.