⚔️ TCP против UDP: Главная битва транспортного уровня

На транспортном уровне (4-й уровень модели OSI или 2-й уровень стека TCP/IP) данные подготавливаются к отправке по сети. За этот процесс отвечают два ключевых протокола: TCP и UDP. Они решают одну и ту же задачу, но принципиально разными путями.

Если говорить кратко: TCP — это надежное заказное письмо с уведомлением о вручении, а UDP — это быстрая рекламная листовка, брошенная в почтовый ящик.

🛡️ TCP (Transmission Control Protocol) — Надежность и контроль

TCP — это протокол с установлением соединения. Перед тем как отправить любой полезный байт данных, он выполняет процедуру «трехстороннего рукопожатия» (Three-way handshake), чтобы убедиться, что принимающее устройство на связи и готово к работе.

⚙️ Как это работает на практике:

1. Установление связи: Клиент отправляет запрос (SYN), сервер отвечает согласием (SYN-ACK), клиент подтверждает готовность (ACK). Соединение создано.
2. Нумерация пакетов: TCP делит данные на сегменты и нумерует каждый из них. Если пакеты придут к получателю в неверном порядке (например, 1, 3, 2), протокол сам соберет их правильно (1, 2, 3).
3. Подтверждение доставки: Получатель обязан отправить отчет о каждом успешно дошедшем пакете. Если отчет не пришел вовремя, TCP автоматически отправляет этот пакет заново.

• Плюсы: Идеальная точность. Данные гарантированно дойдут без потерь и искажений.
• Минусы: Низкая скорость. Постоянные проверки, повторные отправки и подтверждения создают задержки (высокий пинг).
• Где применяется: Просмотр веб-страниц (HTTP/HTTPS), скачивание файлов (FTP), электронная почта (SMTP), доступ к базам данных. В этих сферах важен каждый бит: если потеряется кусочек кода, картинка не откроется, а архив выдаст ошибку.

🤝 Глубокий разбор: Как работает трехсторонняя команда «Приветствий» (TCP 3-way Handshake)

Перед тем как два устройства начнут обмениваться полезной информацией по протоколу TCP, они должны «договориться на берегу». Этот процесс называется трехсторонним рукопожатием (Three-way handshake).

Его задача — убедиться, что оба устройства готовы к приему/передаче данных, и синхронизировать порядковые номера пакетов (Sequence Numbers), чтобы данные не перепутались.

Для управления процессом используются специальные служебные отметки в заголовках пакетов — флаги:

• SYN (Synchronize) — запрос на синхронизацию (начало связи).
• ACK (Acknowledgment) — подтверждение получения.

📋 Схема рукопожатия по шагам

Представим, что ваш Браузер (Клиент) хочет подключиться к Серверу сайта.

Шаг 1: Клиент -> Сервер (Запрос на связь)

Клиент отправляет серверу пустой пакет, в котором активирован флаг SYN.

• Этим пакетом клиент говорит: «Привет! Я хочу установить с тобой надежное соединение. Мой стартовый номер пакета будет X».
• Номер X (случайное число) записывается в поле Sequence Number (Seq=X).
• Состояние клиента меняется на SYN-SENT (ожидание ответа).

Шаг 2: Сервер -> Клиент (Ответ и взаимный запрос)

Сервер получает пакет, соглашается на подключение и отправляет ответный пакет, в котором активированы сразу два флага: SYN и ACK.

• Флагом ACK сервер говорит: «Привет! Твой запрос получил, жду от тебя пакет номер X+1». В поле Acknowledgment Number записывается значение Ack=X+1.
• Флагом SYN сервер добавляет: «Я тоже хочу синхронизироваться с тобой. Мой стартовый номер пакета будет Y». В поле Sequence Number записывается его случайное число Seq=Y.
• Состояние сервера меняется на SYN-RECEIVED.

Шаг 3: Клиент -> Сервер (Финальное подтверждение)

Клиент получает ответ сервера и отправляет последнее подтверждение с флагом ACK.

• Клиент говорит: «Отлично, твой ответ принял! Начинаем работу, я жду от тебя пакет Y+1».
• В поле Ack клиент записывает Ack=Y+1, а в поле Seq ставит Seq=X+1.
• Состояние обоих устройств меняется на ESTABLISHED (Соединение установлено).

🗣️ Наглядный диалог устройств

Если перевести этот технический процесс на человеческий язык, он выглядит так:

1. Клиент: «Привет, Сервер! Ты меня слышишь? Давай общаться, моя точка отсчета — 100». (SYN, Seq=100)
2. Сервер: «Привет, Клиент! Да, отлично слышу. Я принял твои 100, жду 101. А у меня точка отсчета — 500, ты меня слышишь?» (SYN-ACK, Seq=500, Ack=101)
3. Клиент: «Да, слышу тебя хорошо! Принял твои 500, жду 501. Поехали!» (ACK, Seq=101, Ack=501)

Только после этого третьего шага начинается реальная передача содержимого веб-страницы или файла.

❓ Почему именно три шага, а не два?

Двух шагов (запрос-ответ) недостаточно для защиты от старых или зависших пакетов в сети.

Представьте, что первый запрос клиента (SYN) задержался в каком-то роутере. Клиент подумал, что пакет потерялся, и отправил новый. По новому запросу связь установилась, данные передались, и соединение закрылось. И тут до сервера долетает тот самый первый, старый, задержавшийся пакет SYN.

Если бы соединение устанавливалось за два шага, сервер сразу бы открыл новую сессию и тратил свои ресурсы на ожидание данных, которые клиент даже не собирался отправлять. Но благодаря третьему шагу, сервер ждет финального подтверждения (ACK) от клиента. Клиент, зная, что это старый дубликат, просто проигнорирует ответ сервера, и ложное соединение не откроется.

🛑 Глубокий разбор: Как закрывается TCP-соединение (TCP 4-way Teardown)

Если для открытия надежного соединения требуется три шага, то для его корректного закрытия необходимо четыре шага (Four-way teardown).

Для этого процесса используется служебный флаг FIN (Finish) — сигнал о том, что у устройства больше нет данных для отправки. При этом закрытие происходит асимметрично: каждая сторона должна закрыть свой поток данных независимо друг от друга.

📋 Схема закрытия по шагам

Представим, что Браузер (Клиент) полностью скачал веб-страницу и инициирует закрытие сессии с Сервером.

Шаг 1: Клиент -> Сервер (Я закончил передачу)

Клиент отправляет серверу пакет с активированным флагом FIN.

• Этим пакетом клиент говорит: «Я передал тебе всё, что хотел, и закрываю свой канал на отправку. Больше от меня данных не будет».
• Состояние клиента меняется на FIN-WAIT-1.

Шаг 2: Сервер -> Клиент (Принял, но мне нужно время)

Сервер получает пакет FIN и тут же отвечает обычным подтверждением с флагом ACK.

• Сервер говорит: «Твое уведомление получил. Пока я его обрабатываю, ты переходишь в режим ожидания».
• Состояние клиента меняется на FIN-WAIT-2, а сервера — на CLOSE-WAIT.
• На этом этапе соединение становится полузакрытым: клиент больше ничего слать не может, но сервер всё еще имеет право доотправить клиенту те данные, которые остались у него в буфере.

Шаг 3: Сервер -> Клиент (Я тоже закончил)

Когда сервер отправил абсолютно все оставшиеся файлы и готов полностью освободить ресурсы, он посылает свой собственный пакет с флагом FIN.

• Сервер говорит: «Я тоже закончил отправку данных и готов закрыть соединение со своей стороны».
• Состояние сервера меняется на LAST-ACK.

Шаг 4: Клиент -> Сервер (Финальное подтверждение)

Клиент получает FIN от сервера и отправляет последнее подтверждение с флагом ACK.

• Клиент говорит: «Твой FIN принял, подтверждаю полное закрытие связи».
• Сервер сразу переходит в состояние CLOSED.
• Клиент не закрывается мгновенно, а переходит в состояние TIME-WAIT. Он запускает таймер (обычно на 2-4 минуты) и ждет. Это нужно для того, чтобы убедиться, что его финальный пакет ACK точно дошел до сервера, и в сети не осталось «заблудившихся» пакетов из этой сессии. После истечения таймера клиент окончательно переходит в состояние CLOSED.

🗣️ Наглядный диалог устройств

В человеческом формате этот четырехшаговый процесс выглядит так:

1. Клиент: «Сервер, я всё сказал, больше мне отправлять нечего!» (FIN)
2. Сервер: «Понял тебя, твой канал закрываем. Подожди секунду, я сейчас допишу последнее предложение...» (ACK)
3. Сервер: «...всё, я тоже всё отправил и закончил работу!» (FIN)
4. Клиент: «Отлично, подтверждаю. Связь полностью окончена. Пока!» (ACK)

⚡ Зачем нужен флаг RST (Reset)?

В реальной жизни бывают экстренные ситуации, когда соединение нужно разорвать мгновенно, не тратя время на четыре шага вежливых приветствий. Для этого используется флаг RST.

Если на роутере произошел сбой, компьютер внезапно выключился или сервер получил пакет от неизвестного/несуществующего соединения, отправляется пакет с флагом RST. Он жестко и мгновенно обрывает связь, заставляя приложение на другой стороне сразу очистить буфер и закрыть сокет.

⏰ Когда именно происходит закрытие TCP-соединения?

Процесс закрытия соединения запускается в тот момент, когда приложение завершает свою работу, либо когда в сети происходит сбой. Инициатором закрытия может выступать как клиент, так и сервер.

Выделяют 4 основных сценария:

1. 🏁 Успешное завершение работы (Штатный режим)

Когда все данные переданы. Например, в старых версиях HTTP соединение закрывалось сразу после отправки одной картинки. В современных версиях (HTTP/1.1 и HTTP/2) соединение удерживается открытым для загрузки всех стилей и скриптов, но закрывается сервером, как только пользователь перестает кликать по страницам и истекает таймаут активности (Keep-Alive timeout).

2. ✖️ Действия пользователя

Когда вы принудительно прерываете процесс. Например, закрываете вкладку браузера посреди загрузки файла, нажимаете кнопку «Обновить страницу» или полностью закрываете программу. Операционная система сразу перехватывает это действие и посылает серверу сигнал о закрытии сокета.

3. 💤 Таймаут по неактивности

Если данные долго не передаются, устройства начинают отправлять друг другу пустые проверочные пакеты (Keep-Alive probes). Если одна из сторон (например, ушедший в спящий режим смартфон) долго не отвечает на эти проверки, вторая сторона закрывает соединение в одностороннем порядке.

4. 💥 Экстренный разрыв (Сбои и ошибки)

Ситуации, когда стандартные 4 шага закрытия невозможны и отправляется жесткий флаг RST. Это происходит при внезапной перезагрузке сервера, падении питания, блокировке трафика файрволом или при смене IP-адреса на клиенте (например, когда телефон мгновенно переключился с домашнего Wi-Fi на мобильную сеть LTE).

🚀 UDP (User Datagram Protocol) — Скорость и минимальная задержка

UDP — это протокол без установления соединения. Он не тратит время на рукопожатия и проверки. Как только у приложения появляются данные, UDP мгновенно упаковывает их в датаграммы и «выстреливает» в сеть.

⚙️ Как это работает на практике:

Протокол работает по принципу «отправил и забыл». Ему безразлично, дошли ли данные до получателя, не перепутались ли они по дороге и существует ли принимающий компьютер вообще. Вся ответственность за обработку потерь перекладывается на само приложение, если ему это необходимо.

• Плюсы: Максимальная скорость работы. Нет накладных расходов на проверки, данные передаются с минимально возможной задержкой.
• Минусы: Нет никакой гарантии доставки. Пакеты могут легко потеряться в сети или прийти в хаотичном порядке.
• Где применяется: Онлайн-игры, видеозвонки (Zoom, Telegram), прямые трансляции (YouTube Live, Twitch), IP-телефония, DNS-запросы. Если во время разговора потеряется пара пакетов, звук на долю секунды прервется или на экране проскочит пара битых пикселей. Но это не критично — пользователю важнее слышать собеседника в реальном времени, чем ждать, пока сеть дошлет потерянный кадр из прошлого.

📊 Сравнительная таблица: TCP vs UDP

📝 Резюме

Выбор протокола всегда зависит от конкретной бизнес-задачи. Если приложению жизненно необходима целостность данных — выбирают TCP. Если на первом месте стоит скорость передачи в реальном времени, а потеря пары кадров или букв не критична — выбирают UDP.