установка з'єднання
встановлення з'єднання
"Підтвердження трьох шляхів" - це процедура, яка використовується при встановленні з'єднання. Ця процедура зазвичай ініціюється програмою протоколу TCP у відповідь на запит іншої програми TCP. Дана процедура також працює, якщо дві програми TCP ініціюють її одночасно. Коли спроба ініціалізації здійснюється з обох кінців одночасно, кожна програма протоколу TCP отримує сегмент "SYN", який не несе підтвердження для вже відправленого нею "SYN". Звичайно, прибуття старих дублікатів сегмента "SYN" може справити враження на одержувача, ніби здійснюється одночасне відкриття з'єднання. Коректне застосування сегментів "перезавантаження" може запобігти двозначність таких ситуацій.
Нижче наведено кілька прикладів ініціалізації з'єднань. Хоча ці приклади не показують синхронізації з'єднання за допомогою сегментів, які несуть дані, це абсолютно правомірно, оскільки програма TCP, яка отримує сегменти, не передасть дані свого клієнта, поки не стане очевидним коректність даних (тобто дані повинні "складуватися" користувачем до тих пір, поки з'єднання не перейде в стан ESTABLISHED). Підтвердження трьох шляхів зменшує ймовірність появи помилкових з'єднань. Отримання інформації для такої перевірки досягається за допомогою реалізації обміну між пам'яттю комп'ютера і циркулюючими в мережі повідомленнями.
Тут "стану" програми протоколу TCP відповідають моменту відразу після посилки або одержання сегмента (вміст цього сегмента показано в середній колонці кожного рядка). Вміст сегмента в приводиться в скороченій формі і являє собою номер черги, прапори управління і поле ACK. Решта поля сегмента, такі як вікно, довжина і поле даних залишаються за рамками нашого інтересу.
Мал. 7 Отримання старого дубліката сигналу SYN
Як простий приклад розглянемо ситуацію з отриманням старих дублікатів на малюнку 7. На рядку 3 старий дублікат сигналу SYN досягає програму TCP B. Остання не може визначити, що це старий дублікат, і тому відповідає звичайним чином (рядок 4).
Програма TCP A виявляє помилкове значення в поле ACK і тому повертає сигнал RST (перезавантаження). При цьому значення поля SEQ вибирається таким чином, щоб зробити сегмент правдоподібним. Про грама TCP B після отримання сигналу RST переходить в стан LISTEN. Коли на рядку 6 сигнал SYN, дійсний, а не застарілий, досягає програму TCP B, процес синхронізації відбувається нормально. Якщо ж сигнал SYN на рядку 6 досягає програму TCP B перш сигналу RST, може виникнути більше складна комбінація обміну з посилкою RST в обох напрямках.
Наполовину відкриті з'єднання та інші аномалії
Уже усталене з'єднання називається "наполовину відкритим", якщо одна з програм TCP закрила з'єднання, або відмовилася від нього. Причому зробила це на своєму кінці, не попередивши свого партнера. Також така ситуація може виникнути, якщо порушена синхронізація на кінцях лінії внаслідок збою, що призвів до втрати інформації в пам'яті. Якщо на таких з'єднаннях робиться спроба відправити дані в будь-якому напрямку, електронний блок робить перезавантаження з'єднання. Однак передбачається, що наполовину відкриті з'єднання є рідкістю, а процедура відновлення застосовується в мережі досить помірковано.
Якщо на кінці A з'єднання вважається вже неіснуючим, а клієнт на кінці B намагається послати дані, то це призведе до того, що програма TCP на кінці B отримає контрольний повідомлення про перезавантаження. Таке повідомлення показує програмою TCP на кінці B, що щось неправильно і їй пропонується ліквідувати це з'єднання.
Припустимо, що два клієнти в точках A і B спілкуються один з одним, і в цей момент відбувається крах, що приводить до втрати інформації в пам'яті у програми TCP на кінці A. Залежно від операційної системи, яка обслуговує програму TCP A, ймовірно, буде задіяний якийсь механізм виправлення помилки. Коли програма TCP A буде запущена знову, вона, ймовірно, знову почне свою роботу з самого початку або ж з інструкції подолання збою. В результаті, програма A, ймовірно, спробує відкрити (OPEN) з'єднання або надіслати інформацію (SEND) за допомогою бездротової технології, яка, як вона вважає, є відкритим. В останньому випадку від місцевої програми TCP (на кінці A) буде отримано повідомлення "з'єднання не відкрито". При спробі встановити з'єднання програма TCP A буде посилати сегмент, що містить сигнал SYN. Такий сценарій призводить до ситуації, показаної на малюнку 8. Після того, як програма TCP A потерпить крах, користувач спробує повторно відкрити з'єднання. Програма TCP B тим часом продовжує вважати, ніби з'єднання залишається відкритим.
Мал. 8 Виявлення наполовину відкритого з'єднання
Коли на рядку 3 сигнал SYN досягає програму TCP B, що знаходиться в синхронізований стані, а прийшов сегмент знаходиться за межами вікна, програма TCP B відповідає на це його підтвердженням, показує номер черги, який вона бажає отримати (ACK = 100). Програма TCP A, бачачи, що сегмент на рядку 4 не підтвердив відправлену нею інформацію, фіксує відсутність синхронізації і посилає сигнал перезавантаження (RST), оскільки виявлено, що з'єднання є відкритим наполовину. На рядку 5 програма TCP B ліквідує з'єднання. Програма TCP A буде продовжувати спроби встановити з'єднання.
Тепер виникла проблема вирішується простим підтвердженням трьох шляхів (малюнок 5).
Інший цікавий сюжет має місце, якщо програма TCP A терпить крах, а програма TCP B, вважаючи, що знаходиться в стані синхронізації, намагається послати дані. Ця ситуація показана на малюнку 9.
У цьому випадку дані, відправлені програмою TCP B, і прийшли на програму TCP A (рядок 2). будуть відкинуті, оскільки використовується ними з'єднання не існує. На підставі цього програма TCP A посилає сигнал RST. Як тільки сигнал RST прийнятий програмою TCP B, він буде розглянутий, а використане перш з'єднання буде ліквідовано.
. TCP A. TCP B 1.сбой. (Номер посилки 300, отримання - 100) 2. (??) <--
Мал. 9 Активна сторона призводить до виявлення
наполовину відкритого з'єднання
На малюнку 10 показано, що дві програми TCP - A і B -, маючи пасивний стан, чекають сигналу SYN. Старий дублікат сигналу, досягає програму TCP B (рядок 2), запускає її. Повертається сигнал SYN-ACK (рядок 3) та змушує програму TCP A генерувати сигнал RST (на рядку 3 сигнал ACK неприйнятний). Програма TCP B приймає команду перезавантаження і повертається в пасивний стан LISTEN.
Мал. 10 Старий дублікат сигналу SYN ініціює перезавантаження
на двох пасивних сокетах
Може бути безліч інших варіацій, які можуть бути пояснені нижчеописаними правилами для створення і обробки сигналів RST.
Створення сигналу перезавантаження
Згідно головному правилу, сигнал перезавантаження (RST) повинен надсилатися щоразу, коли приходить сегмент, який очевидним чином не призначений для даного з'єднання. Якщо незрозуміло, чи має місце даний випадок, слід утриматися від перезавантаження.
Можна виділити три групи станів для з'єднання:
Якщо з'єднання перебуває в якомусь або не синхронізований стані (LISTEN, SYN-SENT, SYN-RECEIVED), якщо будь-які підтвердження прийшов сегмента ще не відправлені (сегмент несе неприйнятне значення в поле ACK) або прийшов сегмент має рівень безпеки / закриті не що відповідає рівню і захисту даного з'єднання, то відправляється сигнал перезавантаження.
Якщо наш сигнал SYN не була підтверджена, а рівень пріоритету прийшов сегмента більше запитаного рівня, то або буде збільшений місцевий рівень пріоритету (якщо це прийнятно для користувача і системи), або буде посланий сигнал перезавантаження. Або ж якщо рівень пріоритету прийшов сегмента менше запитаного, то обробка буде продовжена далі, як якщо б рівень був таким же (якщо чужа програма TCP не може підвищити рівень пріоритету до нашого, то це буде відзначено в наступному відправляється нею сегменті, тоді і буде закрито з'єднання). Якщо наш сигнал SYN отримав підтвердження (можливо в який прийшов до нас сегменті), то рівень пріоритету прийшов сегмента повинен точно відповідати місць ному рівню. Якщо остання умова не виконується, надсилається сигнал перезавантаження.
Якщо приходить сегмент несе сигнал ACK, то сигнал перезавантаження буде мати номер в черзі, що відповідає номеру сигналу ACK у отриманому сегменті. В іншому випадку сигнал перезавантаження буде мати нульовий номер черги, а сигнал ACK - номер, який дорівнює сумі номера прийшов сегмента і його ж довжини. З'єднання не змінює свого стану.
Якщо з'єднання перебуває в синхронізованому стані (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST ACK, TIME-WAIT), то будь-який неприйнятний сегмент (який не потрапляє в вікно номерів черги, що несе неправильний номер підтвердження) повинен призводити до появи сегмента з порожнім полем підтвердження, що містить поточний номер в черзі на посилку, а також підтвердження, що вказує на наступний очікуваний з цього з'єднання номер. З'єднання залишається в своєму колишньому стані. Якщо прийшов сегмент має рівень захисту, ізоляції або пріоритету, який не відповідає місцевому рівню з'єднання, то відправляється сигнал перезавантаження, а з'єднання переходить в стан CLOSED. Сигнал перезавантаження має номер черги, що відповідає номеру сигналу ACK у отриманому сегменті.
Обробка сигналу на перезавантаження
Для всіх станів, крім SYN-SENT, всі сегменти з сигналом перезавантаження (RST) проходять перевірку полів SEQ. Сигнал перезавантаження зізнається, якщо його номер черги потрапляє у вікно. У стані ж SYN SENT (сигнал RST отриманий у відповідь на посилку ініціюючого сигналу SYN), сигнал RST зізнається, якщо поле ACK підтверджує раніше зроблену посилку сигналу SYN.
Одержувач сигналу RST спершу перевіряє його, і лише потім змінює свій стан. Якщо одержувач перебував у стані LISTEN, то він ігнорує сигнал. Якщо одержувач перебував у стані SYN- RECEIVED, то він повертається знову в стан LISTEN. В інших випадках одержувач ліквідує з'єднання і переходить в стан CLOSED. Якщо одержувач знаходиться в будь-якому іншому стані, то він ліквідує з'єднання і перш ніж перейти в стан CLOSED, сповіщає про це свого клієнта.