3.5. TCP и UDP: надёжность против скорости

Опубликовано: 11.04.2026

TCP и UDP: надёжность против скорости

Как данные гарантированно доходят до цели - и почему иногда надёжность специально отключают

В предыдущих статьях мы разобрались, как пакеты режутся на кусочки, как IP-адреса позволяют пакету найти получателя через тысячи маршрутизаторов. Но у IP есть один принципиальный изъян: он ничего не гарантирует. Пакет отправлен - дошёл ли он? IP не знает. Пришли ли все части файла? IP не считает. Пришли ли они в правильном порядке? IP безразлично.

Именно поэтому поверх IP работают два протокола транспортного уровня: TCP и UDP. Один одержимо следит за каждым пакетом и требует подтверждения. Другой просто стреляет данными в эфир и не оглядывается. У обоих есть своя область применения - и понять, почему, важно для понимания того, как вообще работает интернет.

📬 Проблема, которую решает транспортный уровень

Представьте, что IP — это почтальон, который развозит письма. Он знает адреса и умеет ориентироваться на улицах. Но он не фиксирует, дошло ли письмо. Не складывает многотомное письмо в правильном порядке. Не звонит, если потерял конверт. Просто берёт и везёт.

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

Для многих задач этого мало. Если вы скачиваете браузером страницу сайта, вам нужны все её части и именно в том порядке, в котором сервер их отправил. Пропустите один фрагмент - страница сломается или отобразится неправильно. Здесь нужна гарантия.

Для других задач гарантия вредна. Если вы разговариваете по видеосвязи, и один пакет с изображением потерялся - проще пропустить этот кадр, чем ждать пересылки, которая придёт уже через полсекунды и окажется совершенно бесполезной. Здесь нужна скорость.

TCP решает первую задачу. UDP - вторую.

🤝 TCP: протокол с рукопожатием

TCP расшифровывается как Transmission Control Protocol - протокол управления передачей. Его ключевые слова: «управление» и «контроль». TCP не просто отправляет данные - он организует целый ритуал из трёх шагов перед тем, как передача начнётся.

Тройное рукопожатие

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

Порядковые номера и подтверждения

Каждый байт данных в TCP-соединении имеет порядковый номер. Отправив пакет, отправитель ждёт подтверждения - пакет ACK с номером следующего ожидаемого байта. Если подтверждение не пришло за определённое время - пакет отправляется заново.

Именно это делает TCP надёжным: потеря пакета не остаётся незамеченной. Отправитель не двигается вперёд, пока не убедится, что предыдущие данные дошли. Получатель не передаёт данные приложению в неправильном порядке: если пришли пакеты 1, 3, 4, а пакет 2 ещё в пути - TCP буферизует 3 и 4 и ждёт 2. Важная оговорка: «гарантия» доставки работает, пока связь физически возможна. Если пакеты теряются слишком долго - TCP в итоге «сдаётся» и разрывает соединение по таймауту. Именно поэтому при очень плохом интернете загрузка файла обрывается, а не ждёт бесконечно.

Управление потоком и перегрузкой

TCP делает ещё кое-что умное: он регулирует скорость передачи. Если получатель не успевает обрабатывать данные, он сообщает об этом через поле «размер окна» - и отправитель притормаживает. Это называется управлением потоком.

Есть и более тонкий механизм - управление перегрузкой. Если пакеты начинают теряться (что говорит о перегруженности маршрутизатора где-то на пути), TCP самостоятельно снижает скорость, не дожидаясь команды. TCP ведёт себя как вежливый участник дорожного движения: видит пробку - сбавляет ход, не давит на клаксон.

Закрытие соединения

Завершение TCP-соединения тоже не мгновенное. Используется четырёхшаговый обмен: каждая сторона по очереди говорит «я закончил отправку» (FIN) и получает подтверждение (ACK). Это нужно, чтобы обе стороны убедились: все данные переданы и приняты, можно освобождать ресурсы.

📡 UDP: быстро и без гарантий

UDP - User Datagram Protocol, протокол пользовательских дейтаграмм. Его философия противоположна TCP: никакого рукопожатия, никаких подтверждений, никакого отслеживания порядка. Отправил - забыл.

Заголовок UDP занимает всего 8 байт против минимум 20 у TCP. В нём только четыре поля: порт отправителя, порт получателя, длина и контрольная сумма. Всё. Никаких порядковых номеров, никаких флагов, никакого состояния соединения.

Зачем нужен протокол без гарантий?

Казалось бы, зачем использовать ненадёжный протокол? Ответ: потому что «надёжность» TCP стоит времени. Рукопожатие добавляет задержку ещё до начала передачи. Ожидание подтверждений тормозит поток. Повторная отправка потерянных пакетов — это дополнительные циклы ожидания.

Для потоковых приложений - видеозвонков, онлайн-игр, стриминга - задержка важнее потери нескольких пакетов.

Возьмём видеозвонок. Видео передаётся со скоростью 30 кадров в секунду. Каждый кадр разбивается на UDP-пакеты и летит к собеседнику. Если один пакет потерялся - он уже неактуален: к моменту, когда его удалось бы переслать, на экране должен быть уже следующий кадр. Ждать его бессмысленно. Приложение просто пропустит этот кадр или воспроизведёт предыдущий. Вы заметите лёгкое «замерзание» картинки на долю секунды - но разговор продолжится.

Если бы видеозвонок работал через TCP, любая потеря пакета останавливала бы поток - всё замирало бы на несколько сотен миллисекунд до получения повторного пакета. Именно такой эффект вы видите, когда YouTube «буферизует»: он использует TCP, и при потере пакетов видео встаёт.

🎮 Пинг: почему одна цифра решает всё в играх

Пинг — это время, за которое пакет уходит от вас к серверу и возвращается обратно. Его измеряют в миллисекундах и обозначают RTT - Round Trip Time, время кругового путешествия.

Технически пинг измеряется отправкой крошечного ICMP-пакета с эхо-запросом и фиксацией времени до получения ответа. Команда ping google.com в командной строке покажет это время в реальности.

Почему пинг критичен для онлайн-игр

В сетевой игре каждое ваше действие - движение, выстрел, нажатие кнопки - отправляется на сервер, сервер вычисляет результат и рассылает обновлённое состояние всем игрокам. Пинг — это время между «я нажал кнопку» и «сервер это зафиксировал».

При пинге 20 мс ваш выстрел регистрируется на сервере через 10 мс после нажатия (половина RTT). При пинге 200 мс - через 100 мс. Разница в 90 мс — это пропасть: противник уже успел уйти за укрытие.

Именно поэтому игровые серверы ставят в нескольких регионах: игрок из Минска подключается к серверу в Варшаве, а не в Лос-Анджелесе. Скорость света в оптоволокне - около 200 000 км/с. Расстояние в 9000 км до американского сервера и обратно добавляет минимум 90 мс только за счёт физики, даже в идеальной сети.

Джиттер: нестабильный пинг хуже высокого

Ещё одна важная характеристика - джиттер (jitter), разброс задержки. Если пинг 50 мс стабильно — это хорошо. Если пинг скачет от 20 до 200 мс — это катастрофа, даже если среднее значение невысокое.

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

Wi-Fi в многоквартирном доме - главный источник джиттера. Десятки сетей работают в одном эфире, пакеты конкурируют за канал, задержки непредсказуемы. Кабель значительно стабильнее.

🔢 Порты: кому именно адресован пакет

IP-адрес указывает, на какой компьютер доставить пакет. Но на компьютере одновременно работают десятки программ: браузер, мессенджер, почтовый клиент, игра. Как разобраться, кому из них предназначен пакет? Для этого служат порты.

Порт — это просто число от 0 до 65535, которое указывается в заголовке TCP или UDP рядом с IP-адресом. Можно думать о нём как о номере квартиры: IP — это улица и дом, порт - квартира.

Некоторые порты закреплены за конкретными службами по стандарту:

Когда браузер открывает сайт, он создаёт соединение с портом 443 на сервере. Одновременно параллельно мессенджер поддерживает соединение с портом 5222, почтовый клиент - с портом 993. Операционная система знает, какому приложению принадлежит каждый порт, и маршрутизирует входящие пакеты нужному процессу.

🆕 QUIC: когда TCP устарел, но его не выбросить

TCP создавался в 1970-х годах. Тогда не было HTTPS, не было мобильных сетей, не было сайтов с десятками параллельных запросов. За полвека накопились проблемы.

Главная - блокировка заголовка очереди (Head-of-Line Blocking). Если один пакет теряется, весь поток TCP-данных встаёт и ждёт его повторной отправки. В HTTP/2 браузер отправляет несколько запросов через одно соединение - и потеря одного пакета тормозит все остальные запросы сразу. Представьте кафе: вы заказали суп, салат и десерт. В обычном TCP официант несёт их строго по очереди - уронил суп, стоит и ждёт нового, а салат и десерт уже готовы, но вам не отдаёт. В QUIC каждое блюдо едет на отдельном подносе: уронил суп - салат и десерт всё равно принесут, суп докинут отдельно.

В 2012 году Google начал разрабатывать протокол QUIC, который работает поверх UDP, но реализует надёжность TCP прямо внутри себя - только более умно. Каждый поток данных независим: потеря пакета в одном потоке не блокирует остальные. Рукопожатие совмещено с установкой шифрования, что сокращает задержку. QUIC лежит в основе HTTP/3 - актуальной версии протокола, по которому работает большинство современных сайтов.

🔄 Как всё работает вместе: один HTTP-запрос изнутри

Сведём всё воедино. Вы вводите адрес сайта в браузере и нажимаете Enter. Что происходит на уровне TCP/UDP?

Итого на простую загрузку страницы уходит минимум 3–4 RTT ещё до того, как сервер начал отправлять данные. При пинге 50 мс это уже 150–200 мс задержки только на «формальности». Именно поэтому скорость открытия сайтов зависит не только от пропускной способности канала, но и от физического расстояния до сервера.

📊 Итог: когда что выбирать

TCP и UDP — не конкуренты. Это инструменты для разных задач. Разработчик выбирает протокол исходя из природы приложения: нужна ли целостность данных или важнее минимальная задержка.

Транспортный уровень - невидимый слой, который мы принимаем как должное. Но именно он определяет, будет ли видеозвонок плавным, «залагает» ли игра при одном потерянном пакете и как быстро откроется сайт. Строгость TCP и легкомыслие UDP - не недостатки, а осознанные компромиссы, каждый из которых нужен на своём месте.

В следующей статье мы поднимемся ещё на уровень выше: разберём, что происходит после того, как TCP-соединение установлено, - как браузер и сервер разговаривают по протоколам DNS, HTTP и HTTPS, и что происходит за те секунды от нажатия Enter до появления страницы на экране.

© 2008–2026 ANY.BY - ремонт компьютеров и ноутбуков в Барановичах. Использование материалов сайта возможно с письменного разрешения.

📞 Мы на связи для Вас:

+375 (33) 323 7000 +375 (29) 323 7000 Написать в Telegram Написать в Viber Схема проезда к мастерской