TCP и UDP — базовые транспортные протоколы стека TCP/IP. Оба работают поверх IP и используют порты, но предоставляют приложениям разные свойства. TCP создает логическое соединение и передает надежный упорядоченный поток байтов. UDP отправляет отдельные датаграммы без предварительного установления соединения и встроенных подтверждений. Поэтому выбирать между ними нужно не по принципу «что быстрее», а по требованиям к потерям, порядку и задержке.
Содержание:
- Что такое TCP и UDP простыми словами
- Как работает TCP
- Как работает UDP
- TCP и UDP: таблица отличий
- Порты TCP и UDP
- Где применяется TCP
- Где применяется UDP
- Почему UDP не всегда быстрее TCP
- Слабые места протоколов
- Безопасность: чем рискует каждый протокол
- Как выбрать протокол под задачу
- QUIC и HTTP/3: как новые протоколы стирают границу
- Как проверить, какой протокол использует приложение
- Главное о различиях TCP и UDP
- Частые вопросы
Что такое TCP и UDP простыми словами
TCP можно сравнить с диалогом с контролем: стороны устанавливают связь, нумеруют данные, подтверждают прием и при необходимости повторяют потерянное. UDP ближе к отправке самостоятельных сообщений без обязательного ответа: датаграмма уходит адресату, а сам протокол не проверяет, дошла ли она.
При этом UDP не означает «без надежности вообще». Подтверждения, повторную передачу и другие механизмы может реализовать приложение или протокол поверх UDP. QUIC — показательный пример такого подхода: он использует UDP как основу, но предоставляет собственные механизмы надежной передачи и управления соединением.
Транспортный уровень: за что отвечают эти протоколы
IP доставляет пакеты между сетевыми узлами, а TCP и UDP обеспечивают обмен между процессами на конечных устройствах. IP-адрес указывает узел, номер порта помогает операционной системе передать данные нужной службе или приложению.
TCP добавляет поверх IP контроль порядка, подтверждения, повторную передачу, управление потоком и перегрузкой. UDP ограничивается более простым обменом датаграммами и оставляет дополнительные функции вышестоящему уровню.
Что такое TCP
TCP (Transmission Control Protocol, протокол управления передачей) — протокол с установлением соединения. Он предоставляет приложению двунаправленный упорядоченный поток байтов. Стороны поддерживают состояние соединения, используют номера последовательности и подтверждения, реагируют на потери и регулируют объем данных в пути.
TCP не сохраняет границы прикладных сообщений. Если программа дважды записала данные в сокет — программную конечную точку сетевого обмена, — получатель не обязан получить их двумя отдельными операциями чтения. Формат сообщений определяет само приложение.
Что такое UDP
UDP (User Datagram Protocol, протокол пользовательских датаграмм) передает отдельные сообщения без TCP-подобного установления соединения. Он сохраняет границы датаграмм, но не предоставляет встроенных подтверждений, повторной передачи и упорядочивания.
Границы сообщений — практическое отличие UDP от TCP: что отправитель записал в сокет одной операцией, получатель прочитает целиком или не получит вовсе. Приложению не нужно разделять поток на блоки: это берет на себя транспортный протокол.
Как работает TCP
TCP проходит несколько логических этапов: устанавливает соединение, передает поток данных, подтверждает прием, восстанавливает потери, регулирует нагрузку и завершает соединение. Эти механизмы и позволяют TCP предоставлять приложению надежный упорядоченный поток.
Установка соединения: тройное рукопожатие
Обычное TCP-соединение начинается с тройного рукопожатия. Инициатор отправляет SYN со своим начальным номером последовательности. Вторая сторона отвечает SYN-ACK, подтверждая SYN и сообщая свой номер. Инициатор завершает процедуру сегментом ACK.
Так обе стороны синхронизируют состояние соединения. Дополнительный обмен до передачи обычных прикладных данных означает, что время прохождения сигнала туда и обратно влияет на стоимость открытия нового TCP-соединения.
Разбиение данных на сегменты и нумерация
TCP работает с потоком байтов и передает его частями в сегментах. Номера последовательности привязаны к позициям байтов в потоке. Получатель благодаря им понимает, какие данные уже пришли, какие ожидаются дальше и где возник пропуск.
Размер полезной нагрузки сегмента учитывает MSS (Maximum Segment Size, максимальный размер сегмента) и характеристики сетевого пути.
Подтверждения доставки и повторная отправка
Получатель отправляет ACK, указывая следующий ожидаемый номер. Если данные потеряны или не подтверждены, TCP может передать их повторно. Для обнаружения потерь используются таймеры и информация из подтверждений.
Транспортное ACK не означает, что удаленное приложение успешно выполнило бизнес-операцию. Например, подтверждение TCP не доказывает, что запись уже сохранена в базе данных. Такие гарантии реализуются на прикладном уровне.
Восстановление порядка пакетов
IP-пакеты могут прийти не по порядку. TCP использует номера последовательности и буферизацию, чтобы приложение увидело правильный порядок байтов. Если часть потока потеряна, последующие данные могут ждать восстановления пропуска.
Для файлов и команд это полезно, но в задачах реального времени ожидание старых данных иногда хуже их потери.
Управление потоком и контроль перегрузки
Управление потоком и контроль перегрузки — разные механизмы. Первый защищает приемник: получатель сообщает, сколько данных готов принять. Второй помогает адаптировать отправку к состоянию сети и не перегружать путь.
Именно поэтому TCP регулирует передачу не только по возможностям конечного устройства, но и по признакам сетевой перегрузки. UDP, напротив, не содержит собственного механизма контроля перегрузки, поэтому протоколы и приложения поверх него должны учитывать этот вопрос самостоятельно.
Завершение соединения
Нормальное закрытие TCP использует FIN и ACK. Поскольку соединение двунаправленное, каждое направление закрывается отдельно. Часто это показывают как четыре сегмента, но FIN и ACK могут объединяться.
Для аварийного прекращения используется RST. После закрытия конечная точка также может некоторое время оставаться в состоянии TIME-WAIT.
Из чего состоит заголовок TCP
Минимальный TCP-заголовок занимает 20 байт. В нем находятся:
- порты источника и назначения;
- номер последовательности;
- номер подтверждения;
- длина заголовка;
- управляющие флаги, включая SYN, ACK, FIN и RST;
- окно приема;
- контрольная сумма;
- срочный указатель;
- необязательные параметры.
Параметры TCP расширяют базовые возможности, например позволяют согласовать MSS или использование выборочных подтверждений.
Как работает UDP
UDP минимизирует транспортную логику. Это уменьшает базовые накладные расходы, но переносит дополнительные требования на приложение или протокол более высокого уровня.
Передача без установки соединения
Приложение формирует сообщение и отправляет его через UDP-сокет. UDP добавляет заголовок, затем датаграмма передается IP. Предварительного рукопожатия нет.
Если датаграмма потерялась, сам UDP не запрашивает ее повторно. Он также не гарантирует очередность нескольких датаграмм.
Из чего состоит заголовок UDP
Заголовок UDP занимает 8 байт и содержит четыре 16-битных поля:
- порт источника;
- порт назначения;
- длину;
- контрольную сумму.
Поле длины занимает 16 бит, поэтому максимальная полезная нагрузка одной UDP-датаграммы в IPv4 не превышает 65 507 байт. Но датаграмма больше MTU пути дробится на IP-фрагменты, и потеря любого фрагмента уничтожает всю датаграмму целиком. Поэтому прикладные протоколы поверх UDP ограничивают размер сообщения: классический DNS исторически использовал предел 512 байт, расширение EDNS0 позволяет согласовать больший размер ответа.
Компактный заголовок уменьшает объем служебных данных по сравнению с минимальным заголовком TCP, но сам по себе не гарантирует более высокую скорость приложения.
Что берет на себя приложение
Если поверх UDP нужны подтверждения, нумерация сообщений, защита от дубликатов, повторная передача, управление перегрузкой, шифрование или логика сеанса, их должен обеспечить вышестоящий протокол или само приложение. Рекомендации IETF отдельно подчеркивают необходимость контроля перегрузки для приложений, использующих UDP.
Поэтому UDP лучше рассматривать как простой транспорт датаграмм, а не как «ускоренный TCP без надежности».
TCP и UDP: таблица отличий
| Критерий | TCP | UDP |
| Соединение | Устанавливает логическое соединение | Отправляет датаграммы без установления соединения |
| Надежность | Подтверждения и повторная передача встроены | Подтверждений и повторов нет — их реализует приложение |
| Порядок | Упорядоченный поток байтов | Порядок датаграмм не гарантируется |
| Задержка | Есть затраты на установление соединения и восстановление потерь | Нет TCP-рукопожатия и встроенных подтверждений |
| Заголовок | Минимум 20 байт | 8 байт |
| Контроль перегрузки | Встроен | Сам UDP его не предоставляет |
| Широковещание | Невозможно: соединение всегда между двумя точками | Возможна IPv4-широковещательная и IP-многоадресная передача |
| Типовые задачи | HTTP/1.1, HTTP/2, SSH, SMTP, FTP | DNS, NTP, DHCP, SNMP, медиапотоки поверх RTP, QUIC как основа HTTP/3 |
Базовые свойства TCP и UDP определяются их спецификациями, а UDP также применяется для IP-многоадресной и широковещательной передачи в соответствующих сценариях.
Утверждение, что UDP не проверяет ошибки, не совсем точно: контрольная сумма есть у обоих протоколов. Разница в обязательности: TCP всегда проверяет контрольную сумму, а UDP в IPv4 допускает ее нулевое значение — тогда получатель не проверяет целостность датаграммы. В IPv6 контрольная сумма для UDP обязательна. При этом обнаружение повреждения не равно исправлению: повреждённые датаграммы UDP отбрасываются без уведомления отправителя.
Порты TCP и UDP
Порт — 16-битное число от 0 до 65535. Оно помогает определить транспортную конечную точку приложения. IANA делит пространство на системные порты 0–1023, пользовательские 1024–49151 и динамические или частные 49152–65535.
На практике работа с TCP- и UDP-портами связана не только с настройкой приложений, но и с управлением сетевой инфраструктурой. Например, в платформе виртуализации SpaceVM трафик на границе виртуальных сетей фильтрует встроенный брандмауэр — шлюз безопасности уровней L4–L7. Внутри сетей работает другой механизм: SDN Flow применяет централизованные ACL-правила на уровнях L3–L4 к отдельным ВМ, сегментам или целым проектам, разрешая или запрещая трафик по IP-адресам и портам.
Почему один и тот же номер порта бывает и TCP, и UDP
TCP и UDP используют номер порта вместе с идентификатором транспортного протокола. Поэтому TCP-порт 53 и UDP-порт 53 — разные транспортные конечные точки, хотя номер совпадает.
Классический DNS использует 53-й порт и по UDP, и по TCP. Порт 443 зарегистрирован для TCP и UDP: HTTP/2 работает поверх TCP, а HTTP/3 использует QUIC, который передает свои пакеты в UDP-датаграммах.
Частые порты обоих протоколов
| Служба | Порт | Типичный транспорт | Назначение |
| FTP | 21 | TCP | Команды управления; данные идут отдельным соединением |
| SSH | 22 | TCP | Защищённый удаленный доступ |
| SMTP | 25 | TCP | Передача электронной почты |
| DNS | 53 | UDP и TCP | Разрешение имен; по TCP — зонные передачи и длинные ответы |
| DHCPv4 | 67/ 68 | UDP | Выдача сетевых параметров; 67 — сервер, 68 — клиент |
| HTTP | 80 | TCP | Традиционный веб-трафик |
| NTP | 123 | UDP | Синхронизация времени |
| SNMP | 161 | UDP | Мониторинг и управление |
| HTTPS / HTTP/3 | 443 | TCP и UDP | Веб-трафик с шифрованием |
Реестр портов ведет IANA.
При этом номер порта — соглашение, а не доказательство того, какое приложение действительно передает трафик. На это отдельно указывает и IANA.
Где применяется TCP
TCP выбирают, когда критичны полнота и порядок данных.
- Сайты и API. HTTP/1.1 и HTTP/2 в традиционном стеке используют TCP. При HTTPS к обмену добавляется криптографическая защита TLS. HTTP/3 применяет другую схему — QUIC поверх UDP.
- Передача файлов. Классический FTP использует TCP, поскольку его управляющие и передающие соединения построены на надежном потоковом транспорте.
- SSH. Протокол защищенного удаленного доступа работает поверх TCP/IP. Команды и ответы передаются в рамках защищенного соединения.
- Почта. SMTP использует TCP для передачи сообщений между почтовыми системами. Требования к SMTP прямо предполагают прием входящих TCP-соединений.
- Базы данных. Многие клиент-серверные СУБД используют TCP, когда необходим устойчивый упорядоченный обмен. Прикладной протокол базы данных при этом самостоятельно определяет запросы, транзакции, аутентификацию и обработку ошибок.
Где применяется UDP
UDP удобен там, где приложение хочет само управлять обменом или где своевременность важнее позднего восстановления старых данных.
- DNS. Обычные запросы часто передаются по UDP, однако DNS поддерживает и TCP. Современные требования предусматривают полноценную поддержку DNS поверх TCP, поэтому формула «DNS работает только по UDP» неверна.
- Голосовая связь. Медиаданные реального времени часто передают поверх UDP через RTP. UDP доставляет датаграммы в произвольной последовательности и о перестановках не сообщает. RTP нумерует пакеты и проставляет метки времени, а приемный буфер по этим номерам выстраивает порции звука в исходной последовательности. Пакет, опоздавший к моменту воспроизведения своего участка, буфер отбрасывает. RTCP параллельно собирает статистику потерь и джиттера, по которой отправитель снижает битрейт.
- Видео и потоковая передача. Для интерактивного видео и прямых трансляций могут применяться технологии поверх UDP. Однако нельзя утверждать, что все потоковое видео работает через UDP: веб-доставка также может идти через HTTP поверх TCP или через HTTP/3 и QUIC.
- Онлайн-игры. Координаты игроков и быстро устаревающее состояние игрового мира часто подходят для передачи датаграммами. Авторизация, платежи, загрузка ресурсов и другие подсистемы игры могут использовать TCP или HTTPS.
- Сетевые службы. SNMP традиционно применяет UDP для мониторинга, NTP — для синхронизации времени, DHCPv4 — для выдачи сетевой конфигурации. Практический пример использования SNMP можно увидеть и в инфраструктуре виртуализации: SpaceVM поддерживает мониторинг по SNMP наряду с собственными средствами наблюдения за ресурсами виртуальных машин, серверов и кластеров.
Почему UDP не всегда быстрее TCP
У UDP меньше встроенных механизмов, поэтому отдельную датаграмму можно отправить без TCP-рукопожатия. Но если приложению нужна надежность, оно должно само или через вышестоящий протокол добавить подтверждения, повторы и контроль перегрузки. Поэтому меньшие накладные расходы базового UDP еще не означают лучшую итоговую производительность.
Кроме того, слово «быстрее» может означать разные показатели: меньшую задержку одного сообщения, большую пропускную способность или более быстрое завершение всей прикладной операции. В каждом случае результат зависит от условий сети и архитектуры приложения.
QUIC показывает эту разницу. Он использует UDP как основу, но сам реализует сложный транспорт с соединениями, управляемыми потоками и механизмами восстановления потерь.
Слабые места протоколов
Различия TCP и UDP становятся преимуществами или ограничениями только в контексте конкретной задачи.
Ограничения TCP
TCP хранит состояние соединения, обычно требует предварительного установления связи и восстанавливает потерянные данные. Это создает дополнительные накладные расходы и при потерях может увеличивать задержку.
Кроме того, TCP предоставляет поток байтов, а не готовые сообщения. Прикладной протокол должен самостоятельно определять границы команд, записей или других логических блоков.
Ограничения UDP
UDP не предоставляет встроенных подтверждений, повторов, упорядочивания и контроля перегрузки. Если они нужны, их приходится реализовывать выше.
Особенно опасен собственный UDP-протокол без контроля перегрузки. IETF прямо указывает, что приложения и протоколы поверх UDP должны обеспечивать поведение, не создающее неконтролируемую перегрузку сети.
Поведение на NAT и межсетевых экранах
Шлюз отслеживает TCP-сессию по флагам: SYN открывает запись трансляции, FIN или RST ее закрывает. У UDP признаков начала и конца обмена нет, поэтому шлюз удаляет запись по таймауту неактивности. Из-за этого приложения поверх UDP отправляют keepalive-пакеты — иначе обратный трафик после паузы перестает доходить до клиента. Это одна из причин, по которой UDP-туннели ведут себя по-разному в корпоративной сети и через мобильного оператора.
Безопасность: чем рискует каждый протокол
TCP и UDP не обеспечивают шифрование полезной нагрузки сами по себе. Поэтому выбор одного из двух транспортов не заменяет криптографическую защиту, аутентификацию и правильную настройку сетевой инфраструктуры.
SYN-флуд и атаки на TCP
SYN-флуд использует этап установки TCP-соединения. Атакующий отправляет множество SYN и заставляет сервер обрабатывать большое количество незавершенных соединений. При достаточной нагрузке ресурсов для легитимных клиентов может не хватить. RFC 4987 описывает эту атаку и распространенные способы противодействия ей.
Меры защиты включают SYN cookies, управление очередями соединений, фильтрацию и ограничение нежелательного трафика. Конкретный набор зависит от операционной системы и архитектуры сервиса.
UDP-амплификация и подмена адреса
При отраженной UDP-атаке злоумышленник может подделать исходный IP-адрес и отправить запрос открытой службе от имени жертвы. Если ответ существенно больше запроса, сервер-отражатель увеличивает поток в сторону цели.
Один из известных примеров — злоупотребление неправильно настроенными открытыми рекурсивными DNS-серверами. RFC 5358 посвящен предотвращению использования таких серверов в отраженных атаках типа «отказ в обслуживании».
TCP или UDP в VPN
Единого правила для всех VPN нет. OpenVPN поддерживает транспорт туннеля и через UDP, и через TCP. UDP часто используется как основной вариант, тогда как TCP может быть полезен в сетях, где UDP ограничен. TCP-транспорт туннеля включают, когда UDP блокируют промежуточные фильтры. Платой за это служит наложение двух механизмов повторной передачи: внешний TCP восстанавливает потерю, а внутренний TCP приложения в это же время передает те же данные по своему таймауту. При росте потерь пропускная способность туннеля падает быстрее, чем в UDP-режиме, поэтому TCP выбирают как обходной вариант, а не как основной.
WireGuard работает иначе: он инкапсулирует IP-пакеты в UDP и собственного TCP-режима не предоставляет. Поэтому сначала следует определить VPN-технологию, а уже затем оценивать доступные ей транспортные режимы.
Как выбрать протокол под задачу
Сначала нужно определить требования к потерям, порядку, задержке и уже выбранному прикладному протоколу. Само название приложения еще не определяет оптимальный транспорт.
Когда нужен TCP
TCP подходит, если:
- данные должны поступать в правильном порядке;
- потерянные данные необходимо автоматически передавать повторно;
- приложению удобна модель непрерывного потока байтов;
- нужны встроенные управление потоком и контроль перегрузки;
- выбранный прикладной протокол рассчитан на TCP.
Типичные примеры — SSH, SMTP, FTP, многие подключения к базам данных, HTTP/1.1 и HTTP/2.
Когда нужен UDP
UDP подходит, если:
- данные состоят из самостоятельных сообщений;
- критична небольшая задержка;
- устаревшее сообщение иногда лучше пропустить, чем доставить поздно;
- вышестоящий протокол уже реализует необходимые гарантии;
- требуется поддерживаемая сетью широковещательная или многоадресная доставка.
Примеры — NTP, DHCP, часть игрового и мультимедийного трафика, а также транспортная основа QUIC.
Чек-лист выбора
- Допустима ли потеря отдельного сообщения?
- Обязателен ли строгий порядок данных?
- Что важнее при потере: повтор старых данных или получение актуальных?
- Кто отвечает за контроль перегрузки и восстановление?
- Какой транспорт уже предусмотрен прикладным протоколом?
В корпоративной виртуальной инфраструктуре выбор TCP или UDP — только часть сетевой настройки. Необходимо также определить, какие виртуальные машины и сегменты могут взаимодействовать между собой, какие порты разрешены и как трафик проходит между сетями. В SpaceVM эти задачи связаны с управлением виртуальными сетями: платформа позволяет создавать и администрировать виртуальные машины и сети, а SDN Flow поддерживает L2- и L3-сети, маршрутизацию, NAT, микросегментацию и централизованную фильтрацию трафика.
Частые ошибки при выборе
Не стоит выбирать UDP только из-за репутации «быстрого» протокола. Не менее рискованно использовать TCP для чувствительных ко времени данных, не оценив влияние восстановления потерь на задержку.
Еще одна ошибка — писать собственную надежность поверх UDP без контроля перегрузки, таймеров и обработки дубликатов. И наконец, TCP-подтверждение нельзя путать с подтверждением бизнес-операции приложения.
QUIC и HTTP/3: как новые протоколы стирают границу
QUIC — транспортный протокол, пакеты которого передаются внутри UDP-датаграмм. Он создает соединения, поддерживает управляемые потоки, предусматривает обнаружение и восстановление потерь и использует TLS 1.3 для криптографической защиты.
HTTP/3 работает поверх QUIC. Существенное отличие от HTTP/2 поверх TCP связано с независимыми потоками QUIC: потеря пакета с данными одного потока не должна заставлять остальные потоки ждать восстановления этого участка на транспортном уровне. Таким образом, UDP может служить основой для надежного современного транспорта, если необходимые механизмы реализованы выше самого UDP.
Как проверить, какой протокол использует приложение
В Linux сокеты можно посмотреть через ss:
ss -t -a
ss -u -a
Первая команда выводит TCP-сокеты, вторая — UDP. Утилита ss предназначена для исследования сокетов и позволяет отдельно выбирать TCP и UDP. Похожую информацию дает netstat, но ss предоставляет дополнительные сведения о состоянии TCP.
Для анализа пакетов подойдет tcpdump:
tcpdump -i any tcp
tcpdump -i any udp
tcpdump -i any port 53
tcpdump позволяет захватывать сетевые пакеты и применять выражения фильтрации, в том числе по протоколу и порту.
В Wireshark можно использовать фильтры отображения:
tcp
udp
tcp.port == 443
udp.port == 443
Wireshark позволяет фильтровать пакеты по протоколам и отдельным полям. Например, фильтр tcp оставляет в списке пакеты, содержащие TCP.
Порт нужно оценивать вместе с распознанным прикладным протоколом: одинаковый номер порта может встречаться у разных транспортов и сам по себе не доказывает тип приложения.
Главное о различиях TCP и UDP
- Транспорт выбирают по трем вопросам: допустима ли потеря отдельного сообщения, обязателен ли строгий порядок, что дороже — повтор старых данных или задержка.
- TCP отвечает «нет, да, повтор»: соединение, упорядоченный поток, встроенный контроль перегрузки, заголовок от 20 байт.
- UDP отвечает «да, нет, актуальность»: самостоятельные датаграммы, заголовок 8 байт, все гарантии — на стороне приложения.
- Меньший заголовок не означает меньшую задержку прикладной операции: QUIC поверх UDP реализует полноценный надежный транспорт и по накладным расходам сопоставим с TCP.
- Ни один из двух транспортов не заменяет шифрование и аутентификацию.
Частые вопросы
Что быстрее — TCP или UDP?
У UDP меньше базовых накладных расходов и нет TCP-рукопожатия, поэтому в некоторых сценариях он позволяет уменьшить задержку. Но универсального правила нет. Если поверх UDP необходимы надежность, восстановление потерь и контроль перегрузки, эти механизмы все равно придется реализовать на другом уровне.
Можно ли передавать файлы по UDP?
Да. UDP не ограничивает тип полезных данных. Однако для гарантированной передачи целого файла протокол поверх UDP должен самостоятельно решить вопросы нумерации, подтверждений, повторной отправки и сборки. Поэтому во многих простых сценариях удобнее TCP, хотя надежные современные транспорты, например QUIC, также могут строиться поверх UDP.
DNS работает по TCP или UDP?
По обоим. Классический DNS использует порт 53 по UDP и TCP. UDP широко применяется для обычных запросов, но поддержка TCP является полноценной частью DNS и требуется современными спецификациями.
Что выбрать для API?
Для веб-API обычно выбирают версию HTTP и готовый программный стек, а не TCP или UDP напрямую. HTTP/2 работает поверх TCP, а HTTP/3 использует QUIC поверх UDP. Для собственного двоичного протокола решение зависит от требований к порядку, потерям, задержке и сложности реализации.
Какой протокол безопаснее?
Нельзя однозначно назвать TCP или UDP безопаснее. Сам транспорт не решает все задачи защиты приложения. Для TCP характерны, например, атаки на установление соединения, включая SYN-флуд, а UDP-сервисы могут использоваться в отраженных атаках с усилением. Безопасность определяется всей архитектурой: шифрованием, аутентификацией, фильтрацией, настройкой службы и защитой инфраструктуры.
Почему игры используют UDP?
Для быстро меняющегося состояния игры позднее старое обновление может быть бесполезно. UDP позволяет приложению самостоятельно решить, какие сообщения подтверждать и повторять, а какие можно пропустить ради получения более актуальных данных. При этом игра не обязана использовать только UDP: разные ее подсистемы могут работать через разные транспортные и прикладные протоколы.
