Перейти до вмістуHisnLabs
← TCP/IP: адреси, порти та підключення

Урок 3 з 4 · 7 хв

Рукостискання TCP і життя з’єднання

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

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

Три повідомлення перед першим словом

RFC 9293, поточна специфікація TCP, описує процес як синхронізований обмін: «синхронізація вимагає від кожної сторони надіслати свій власний початковий порядковий номер і отримати його підтвердження у вигляді підтвердження від віддаленого однорангового TCP».

  1. SYN. Пристрій, що відкриває з’єднання, надсилає сегмент із встановленим прапором SYN, який містить початковий порядковий номер.
  2. SYN-ACK. Інша сторона відповідає власним SYN, а також підтвердженням першого числа.
  3. ACK. Перший пристрій підтверджує цю відповідь. У RFC 9293 зазначено, що «оскільки кроки 2 і 3 можна поєднати в одному повідомленні, це називається тристороннім (або трьома повідомленнями) рукостисканням». Після його завершення обидві сторони вважають з’єднання ВСТАНОВЛЕНИМ і починають надсилати реальні дані.

Навчальний центр Cloudflare надає звичайну версію тієї самої ідеї, використовуючи електронний лист як приклад: "спочатку джерело надсилає пакет початкового запиту SYN на цільовий сервер, щоб розпочати діалог. Потім цільовий сервер надсилає пакет SYN-ACK, щоб погодитися з процесом. Нарешті, джерело надсилає пакет ACK цільовій особі для підтвердження процесу, після чого вміст повідомлення може бути надіслано".

Чисте завершення з’єднання

Закривати більш обдумано, ніж відкривати. RFC 9293 пояснює, що «звичайна послідовність закриття TCP надійно доставляє буферизовані дані в обох напрямках» до завершення з’єднання: кожна сторона надсилає сегмент FIN, коли більше не має даних для надсилання, інша сторона підтверджує це, і лише після завершення обох напрямків з’єднання повністю закривається. Після цього настає короткий період очікування (TIME-WAIT), щоб будь-які випадкові затримані пакети зі старого з’єднання не можна було прийняти за частину нового.

Що бачить брандмауер посередині

Брандмауеру зі збереженням стану, вбудованому в більшість маршрутизаторів і в саму macOS, не потрібно перевіряти кожен пакет, щоб прийняти рішення. Пояснення Cloudflare щодо брандмауерів описує це так: він «зберігає інформацію про відкриті з’єднання та використовує цю інформацію для аналізу вхідного та вихідного трафіку, а не для перевірки кожного пакета». На практиці це означає, що він стежить за SYN, який відкриває з’єднання, запам’ятовує, що ця програма попросила відповідь, а потім тихо дозволяє відповідний SYN-ACK назад; відповідь, яка не відповідає жодному вихідному SYN, скидається. Це також те, як брандмауер може відрізнити звичайну відповідь від небажаної спроби підключення, що надходить нізвідки, що є основою для блокування небажаного вхідного трафіку.

Жоден із цього обміну не шифрується самим TCP; SYN, SYN-ACK і ACK видимі у звичайній формі всім, хто спостерігає за мережевим шляхом, включно з вашим маршрутизатором Wi-Fi. Те, що буде приховано, залежить від рівня над TCP, наприклад TLS для сайту HTTPS, який розглядається окремо в курсі «Як працює Інтернет».

Головне

  • З’єднання TCP відкриваються за допомогою тристороннього рукостискання: SYN, потім SYN-ACK, потім ACK, відповідно до RFC 9293.
  • Лише після завершення рукостискання сторони починають обмінюватися реальними даними.
  • Закриття з’єднання — це двосторонній обмін сегментами FIN, тому буферизовані дані доставляються до завершення з’єднання.
  • Брандмауер із збереженням стану відстежує, які SYN вийшли, щоб він міг розпізнати та дозволити відповідні відповіді, а також відкинути небажані.
  • Саме рукостискання не шифрується; його видно будь-чому на мережевому шляху.

Перевірте себе

  1. 1. Який правильний порядок тристороннього рукостискання TCP?

    • ACK, SYN, SYN-ACK
    • SYN, SYN-ACK, ACK — Правильно.
    • SYN-ACK, SYN, ACK
    • FIN, SYN, ACK

    RFC 9293 описує, що сторона підключення спочатку надсилає SYN, інша сторона відповідає SYN-ACK, а сторона підключення підтверджує ACK.

  2. 2. Коли реальні дані програми починають надходити через з’єднання TCP?

    • Перед відправленням SYN
    • Тільки після завершення тристороннього рукостискання — Правильно.
    • Під час кроку SYN-ACK
    • Дані передаються безперервно без рукостискання

    Рукостискання існує для синхронізації порядкових номерів до того, як будь-яка сторона довірить з’єднанню достатньо для надсилання реальних даних.

  3. 3. Як брандмауер із визначенням стану вирішує дозволити вхідний пакет відповіді?

    • Він дозволяє всі вхідні пакети за замовчуванням
    • Він перевіряє, чи відповідає пакет з’єднанню, яке відкрив цей пристрій, запам’ятовується з попереднього вихідного SYN — Правильно.
    • Він перевіряє вміст пакета на наявність ключових слів
    • Він переглядає лише порт призначення, а не стан підключення

    Cloudflare описує брандмауер із збереженням стану як такий, що «зберігає інформацію про відкриті підключення» для розпізнавання законних відповідей, а не перевіряє кожен пакет з нуля.

  4. 4. Чи зашифровано саме рукостискання TCP?

    • Так, завжди
    • Ні, він простий і видимий будь-кому на мережевому шляху — Правильно.
    • Шифрується лише SYN
    • Лише на з’єднаннях HTTPS

    TCP забезпечує порядок і надійність, а не конфіденційність. Шифрування, якщо воно присутнє, надходить із рівня вище TCP, наприклад TLS.

Застосуйте на практиці з FireAI

Застосуйте цей урок на своєму Mac.

Джерела

Застосуйте це на своєму Mac

Усі функції безкоштовно на 17 днів, без банківської картки.

Завантажити для Mac Документація