Файлы к 3 и 5 лабораторным / Всё о TCP понятными словами
.docxTCP-соединение в протоколе TCP (Transmission Control Protocol) работает как надежный, ориентированный на соединение канал транспортного уровня модели TCP/IP. Оно обеспечивает упорядоченную доставку данных, контроль ошибок, повторную передачу потерянных пакетов и управление потоком, разбивая поток байтов на сегменты с нумерацией.
Установка соединения (TCP Three-Way Handshake)
Соединение начинается с трехэтапного “рукопожатия”, которое синхронизирует начальные номера последовательности (ISN) и подтверждает готовность обеих сторон к двустороннему обмену.
# Этап 1: SYN от клиента
Клиент (активная сторона) в состоянии SYN-SENT отправляет TCP-сегмент с флагом SYN=1.
• SEQ = ISN_client (случайное 32-битное число, например, 1000). Это номер “нулевого байта” потока клиента.
• ACK=0 (нечего подтверждать), данных нет.
Значение: “Хочу соединение, мой первый байт будет 1001”. Сервер переходит в SYN-RECEIVED. Число 1001 возникает из правила TCP: SYN-флаг “потребляет” один байт в нумерации последовательности, даже если данных в пакете нет.
# Этап 2: SYN-ACK от сервера
Сервер (в LISTEN) отвечает SYN-ACK: флаги SYN=1, ACK=1.
• SEQ = ISN_server (свое случайное, например, 5000).
• ACK = ISN_client + 1 = 1001 (подтверждаю твой SYN, жду байт 1001 и дальше).
Это синхронизирует обратный поток.
# Этап 3: ACK от клиента
Клиент подтверждает: флаг SYN=0, ACK=1.
• SEQ = 1001 (продолжаю последовательность после SYN).
• ACK = ISN_server + 1 = 5001 (подтверждаю твой SYN).
Обе стороны в ESTABLISHED — соединение готово.
Три этапа нужны для полной двусторонней синхронизации: без финального ACK сервер не знает, дошло ли его SYN-ACK.
SEQ, ACK и ISN: нумерация байтов
TCP трактует данные как непрерывный поток байтов в каждую сторону (полнодуплекс).
Sequence Number (SEQ)
32-битное поле: номер первого байта данных в сегменте.
Обматывается после 4 ГБ (2^32 байт).
Увеличивается: SEQ_новый = SEQ_старый + длина_данных_в_байтах. Пустой сегмент (как SYN) не меняет SEQ.
Initial Sequence Number (ISN)
Начальное SEQ для соединения, генерируется случайно (RFC 6528) для уникальности и защиты от атак (подбора SEQ).
Не 0, криптографически сильное в современных ОС. Старые системы инкрементировали предсказуемо.
Acknowledgment Number (ACK)
Номер следующего ожидаемого байта от собеседника (cumulative ACK подтверждает все до этого).
Увеличивается: ACK = SEQ_получателя_после_данных + длина.
Пример передачи: Клиент шлет 100 байт (SEQ=1001, len=100) → сервер ACK=1101.
Передача данных
Данные фрагментируются в сегменты (обычно до MSS ~1460 байт).
Каждый: SEQ (первый байт), длина в payload, ACK (ожидаемый от собеседника).
Получатель шлет ACK; таймаут → retransmit. Selective ACK для отдельных пакетов.
Window size регулирует поток (сколько можно слать без ACK).
Завершение соединения (Four-Way Handshake)
Двустороннее:
1. Сторона A: FIN=1 (SEQ=текущий).
2. Сторона B: ACK (ACK=SEQ_A+1), затем FIN=1 (свой SEQ).
3. Сторона A: ACK (ACK=SEQ_B+1).
Таймауты (2MSL) очищают “висящие” пакеты.
Флаги TCP (управление)
SYN (Synchronize): 1 бит, сокращение от “Synchronize Sequence Numbers” — синхронизировать нумерацию.
ACK (Acknowledgment): подтверждение.
Другие: FIN (Finish), RST (Reset), PSH (Push), URG (Urgent).
Это обеспечивает надежность: порядок, отсутствие дубликатов, потерянных байтов. В Wireshark видно: фильтр “tcp.analysis” покажет проблемы.
Про опции
Options. Поле Options может содержать несколько опций, и каждая опция может иметь длину несколько октетов. Опции используются в первую
Очередь в тестовых ситуациях. И Интернет протокол, и TCP обеспечивают поля опций (RFC7323).
Maximum Segment Size (MSS).
Максимальное количество октетов данных, которое может быть получено отправителем этого параметра TCP в сегментах TCP без параметров заголовка TCP (RFC6691).
Window Scale
Window Size определяет количество байт данных (payload), после передачи которых отправитель ожидает подтверждения от получателя, что данные получены. Иначе говоря, получатель пакета располагает для приёма данных буфером длиной “размер окна” байт. Ведь если бы мы на каждые несколько байт каждый раз требовали подтверждение получения, перед тем как отправить следующий кусочек, то скорость была бы низкой.
По умолчанию размер окна измеряется в байтах и ограничен 216 (65535) байтами. Однако благодаря TCP опции Window Scale этот размер может быть увеличен до 1 Гбайта.
Эта опция отправляется только в сегменте SYN (сегмент с включенным битом SYN), поэтому масштаб окна фиксируется в каждом направлении при открытии соединения.
• MSS — про размер одного сегмента (как «кусок»).
• Window Size — про скользящее окно приёма/передачи (сколько «кусков» можно накопить в пути без подтверждения).
MSS отвечает на вопрос «сколько данных в одном сегменте?», а Window Size — «сколько данных можно отправить вперёд, пока принимающая сторона не скажет “хватит”»
Selective Acknowledgements (SACK)
TCP был разработан как довольно надежный протокол, хотя, несмотря на это, он все еще имеет несколько недостатков, один из которых касается подтверждений, что также является причиной того, что в RFC 1072 было введено выборочное подтверждение «Selective Acknowledgements» (SACK).
Проблема со старыми подтверждениями состоит в том, что у получателя нет механизмов, чтобы заявить: «Я все еще жду байты с 20 по 25, но получил байты с 30 по 35».
Если сегменты прибывают не по порядку и в очереди получателя есть дыра, то при использовании «классических» подтверждений, поддерживаемых TCP, можно сказать только «Я получил все до байта 20».
Затем отправителю необходимо распознать, что что-то пошло не так, и продолжить отправку с этого момента (20-й байт).
Описанная выше ситуация совершенно неприемлема, поэтому пришлось создать более надежную службу, отсюда и SACK.
Когда виртуальное соединение устанавливается с использованием классического трехстороннего рукопожатия, хосты должны отправить «Разрешено выборочное подтверждение» в параметрах TCP, чтобы указать, что они могут использовать SACK. С этого момента опция SACK отправляется всякий раз, когда требуется выборочное подтверждение.
Например, если у нас есть клиент Windows98, который ожидает байта 4268, но опция SACK показывает, что клиент Windows98 также получил байты с 7080 по 8486, очевидно, что ему не хватает байтов с 4268 по 7079, поэтому сервер должен только повторно отправить недостающие 2810 байтов вместо того, чтобы перезапускать всю передачу с байта 4268.
Опция SACK передается получателем данных для информирования отправителя блока данных с разрывами о доставке данных и размещении их в приемной очереди. Получатель ждет приема данных (возможно, с использованием повторной передачи), заполняющих пропуски в пространстве порядковых номеров между полученными блоками. При получении отсутствующих сегментов получатель данных подтверждает их обычным способом, сдвигая левый край окна в поле Acknowledgement Number заголовка TCP. Опция SACK не меняет трактовки поля Acknowledgement Number.
Опция содержит список непрерывных блоков порядковых номеров попадающих в окно данных, которые были приняты и помещены в очередь.
NOP
Параметр TCP No-Operation используется для выравнивания. NOP (No-Operation) в TCP — это специальная однобайтовая опция (код 1), которая не несёт данных и не выполняет никаких операций.
Она используется исключительно для заполнения (padding) заголовка TCP, чтобы выровнять другие опции по границе в 4 байта. TCP-опции переменной длины (например, MSS, Window Scale, Timestamps) должны начинаться по 32-битной границе для упрощения парсинга процессором.
Без NOP заголовок мог бы “съехать”, что усложнило бы обработку. TCP-опции выравниваются по границе в 4 байта (32 бита), потому что базовый заголовок TCP имеет фиксированную длину 20 байт, которая кратна 4 байтам.
Timestamps
Физическое устройство может на практике иметь несколько, возможно независимых, часов. Для удаленной идентификации устройств используются несколько различных часов — часы, отвечающие за системное время устройства, и внутренние часы стека TCP/IP, которые обозначаются как TCP timestamps option clock или Tsopt.
RFC 1323 и RFC 7323 описывают опцию TCP «timestamps». Поток TCP будет использовать опцию timestamps в случае, если на обоих стеках она поддерживается и инициатор потока включит опцию в инициализационный
SYN-пакет. В Windows 10 данная опция отключена. Остальные операционные системы, с которыми мы работали, поддерживают эту опцию.
RFC четко не определяет значения, которые должно принимать время, но при этом оговаривает, что значение должно считываться с «виртуальных
Часов», которые «примерно пропорциональны реальному времени».
Также нет никакого требования к тому, чтобы часы TCP timestamps коррелировали с системными часами устройства.
Временные метки используются для двух различных механизмов:
RTTM (измерение времени кругового обхода) и PAWS (защита от ошибок при достижении верхней границы порядковых номеров / защита от перехода номеров последовательности через ноль).
Временные метки TCP имеют даже другое применение, помимо измерений PAWS и RTT. Например, становится возможным определить, была ли повторная передача ненужной. Если подтверждение содержит более старую эхо-метку времени, значит, подтверждение было для начального пакета, а не для повторно переданного.
Проще говоря, TCP Timestamps — это просто дополнительный “часы внутри” TCP‑стека, которые помогают устройству отслеживать время пакетов и лучше управлять передачей данных.
Зачем нужны TCP Timestamps
При работе TCP могут включаться отметки времени в пакеты, если обе стороны поддерживают RFC 1323 / RFC 7323. Тогда:
RTTM (измерение RTT)
• TCP вставляет время отправки пакета в поле.
• При получении ACK принимающая сторона возвращает это время назад (echo).
• Отправитель смотрит: текущее время – время из echo → это и есть примерное время кругового хода (RTT).
PAWS (защита от проблем с номерами)
Последовательные номера TCP могут “переполниться” и вернуться к нулю; без защиты можно перепутать старые пакеты с новыми.
По временным меткам TCP отбрасывает пакеты, у которых timestamp “слишком старый” по сравнению с последним — это защита от повторного использования старых номеров.