На этом занятии вы переходите от прикладного уровня к транспортному уровню и разбираете протокол UDP. Мы рассмотрим, зачем транспортному уровню нужны порты, почему он называется сеть-независимым и в каких случаях отсутствие соединения и гарантий доставки оказывается преимуществом, а не недостатком.
Практическая часть построена как лабораторная работа: вы выполните запросы, увидите дейтаграммы UDP в Wireshark, найдёте порты отправителя и получателя, длину, контрольную сумму и свяжете это с приложениями, которые работают поверх UDP - в первую очередь с DNS.
Транспортный уровень в моделях OSI и TCP/IP выполняет похожие задачи. Его основная функция - передача данных между процессами на хостах. Это важный шаг: на нижних уровнях сеть доставляет пакеты до устройства, а на транспортном нужно понять, какому именно приложению на этом устройстве отдать данные.
У транспортного уровня две ключевые задачи. Первая - адресация, то есть выбор правильного процесса по номеру порта. Вторая - уровень надёжности. В зависимости от протокола транспортный уровень либо обеспечивает доставку и порядок сообщений, либо работает быстро и без лишних подтверждений.
Между двумя хостами может находиться сколько угодно маршрутизаторов, коммутаторов и других промежуточных устройств. Но транспортный уровень работает так, будто между конечными узлами есть виртуальное прямое соединение. Его не интересует каждая промежуточная коробка по пути - ему важно, что данные дошли до нужного хоста и нужного процесса.
Именно поэтому транспортный уровень называют сеть-независимым. Маршрутизация, таблицы маршрутов и физическая передача кадра происходят ниже, а здесь решают другую задачу: как двум приложениям обмениваться данными поверх любой нижележащей сети.
Адресация на транспортном уровне - это порт. Порт - это число от 0 до 65535. Каждому сетевому процессу на хосте назначается номер порта, по которому операционная система понимает, какому приложению передать полученные по сети данные.
Если записывать адрес полностью, сначала указывают IP-адрес, а затем через двоеточие порт, например
203.0.113.10:53 или 192.168.1.20:8080. IP-адрес показывает устройство, а порт -
конкретный процесс на этом устройстве.
Порты принято делить на три диапазона. Well-known ports - от 0 до 1023, это широко известные порты популярных служб: например, 80 для HTTP, 53 для DNS, 25 для SMTP. Registered ports - от 1024 до 49151, их можно зарегистрировать для приложений и сервисов. Dynamic или private ports - от 49152 до 65535, обычно их автоматически назначает операционная система клиентским приложениям.
Почему именно 65535? Номер порта в заголовках TCP и UDP кодируется полем длиной 16 бит. 16 бит дают ровно 216 = 65536 значений (от 0 до 65535) — ни больше, ни меньше: это технический предел размера такого поля в протоколе.
Под клиентскими приложениями в диапазоне 49152–65535 имеют в виду не серверы, которые
разработчик поднимает сам (например, Express.js на порту 3000 — это сервер, слушающий в диапазоне
зарегистрированных портов). Речь о процессах, которым ОС временно выдаёт исходящий порт для запроса:
браузер, curl, nslookup, dig, мессенджер, игровой клиент — у каждого
при обращении к сети будет свой динамический порт источника из 49152–65535.
Такое деление упрощает настройку и диагностику. Если вы видите порт 53 как порт назначения, почти наверняка это DNS. А если видите случайный порт из динамического диапазона как порт источника, скорее всего его автоматически выдала ОС клиентскому процессу.
Представьте два разных процесса браузера на одном хосте. Оба идут на один и тот же веб-сервер, но операционная система назначит им разные клиентские порты, например 50291 и 50324. Сервер отвечает обоим на один и тот же порт службы, например 80 или 443, но обратно отправляет данные на разные клиентские порты, чтобы ОС правильно распределила ответы между процессами.
Поэтому порт - это не просто число, а основной механизм развязки процессов на одном устройстве. Один хост может одновременно работать с десятками сетевых программ, и именно порт позволяет не перепутать их трафик.
Транспортный уровень может повышать надёжность по сравнению с нижележащей сетью. Это достигается подтверждениями получения, повторными отправками и нумерацией сообщений. Если подтверждение не пришло, данные отправляют снова. Если пакеты пришли не в том порядке, их можно переставить по номерам.
Но не всем приложениям нужен один и тот же набор свойств: одним важнее надёжность (повторные отправки, подтверждения, строгий порядок доставки), другим — минимальная задержка, даже если часть данных может потеряться. Это два противоположных приоритета, поэтому на транспортном уровне существуют два разных подхода — TCP и UDP.
UDP проще, чем TCP. В нём нет установки соединения, нет подтверждений получения, нет гарантии доставки и нет гарантии порядка следования сообщений. Поэтому на примере UDP удобно понять, что именно транспортный уровень делает в минимальном варианте: адресует процессы по портам и передаёт сообщения от одного приложения к другому.
Название UDP расшифровывается как User Datagram Protocol - протокол пользовательских дейтаграмм. Дейтаграмма - это отдельное сообщение, которое отправляют быстро и без сложной подготовки соединения.
Протокол UDP работает по схеме message-oriented: отправитель формирует дейтаграмму, указывает порты, длину и контрольную сумму, после чего сообщение сразу передают вниз по стеку. Нет отдельного этапа установления соединения, как в TCP, нет согласования параметров и нет ожидания подтверждений каждого сообщения.
Дейтаграмма — это отдельная, самостоятельная порция данных без логической связи с предыдущими или следующими; сеть доставляет её как единое сообщение. Концепция дейтаграмм появилась в ранних пакетных сетях (ARPANET и др.) в 1960–1970-х годах; для UDP она закреплена в RFC 768 (1980). У дейтаграммы есть заголовок (порты, длина, контрольная сумма) и полезные данные; подробная структура разобрана на следующем экране.
Из-за этого накладные расходы меньше, а скорость работы выше. Именно поэтому UDP хорошо подходит для коротких запросов клиент-сервер и потоковых сценариев, где важнее не идеальная надёжность, а минимальная задержка.
UDP хорошо подходит для короткого обмена данными: клиент отправляет небольшое сообщение, сервер присылает короткий ответ. В таком сценарии использование TCP могло бы оказаться неоправданно тяжёлым, потому что сначала пришлось бы устанавливать соединение, а потом уже передавать полезные данные.
Классический пример - DNS. Клиент отправляет небольшой запрос, например на получение IP-адреса домена, и ждёт короткий ответ. Для такого обмена простая дейтаграмма UDP часто оказывается эффективнее полноценной сессии TCP.
Вторая большая область применения UDP - медиа и реальное время. Если потерялся один кадр видео или несколько фрагментов звука, пользователь может этого даже не заметить. А вот если останавливать поток и ждать потерянный пакет, появится задержка, которую человек почувствует сразу.
Поэтому поверх UDP строят протоколы для голосовой связи, видеоконференций, потокового видео, телеметрии, игр и некоторых систем мониторинга. Принцип простой: лучше потерять часть данных, чем увеличить задержку настолько, что поток станет некомфортным.
UDP не обеспечивает гарантию доставки. Если пакет потерялся, сам UDP не станет пересылать его ещё раз. UDP также не гарантирует порядок следования сообщений: если несколько дейтаграмм пошли разными путями, они могут прийти в другом порядке или не прийти вовсе.
Если приложению всё же нужна надёжность, оно должно реализовать нужную логику на верхнем уровне. Например, можно использовать таймеры, повторные запросы, номера сообщений или даже собирать собственный надёжный протокол поверх UDP.
DNS - хороший пример того, как прикладной протокол сам добавляет нужную ему логику поверх UDP. Клиент DNS отправляет запрос и запускает таймер. Если ответ не пришёл вовремя, запрос отправляют повторно. Таким образом, надёжность обеспечивается не транспортным протоколом, а самим приложением.
Это важный принцип: UDP не мешает строить надёжность, он просто не делает этого автоматически. Если приложению нужна скорость и оно само готово управлять повторными запросами, UDP оказывается очень удобной основой.
Дейтаграмма UDP состоит из двух частей: заголовок и данные. Заголовок очень компактный - всего 8 байт. Это одна из причин высокой скорости UDP: служебной информации мало, и пакет легко разобрать.
В заголовке четыре поля: порт отправителя, порт получателя, длина и контрольная сумма. За счёт такой простоты UDP легко анализировать в Wireshark и удобно использовать как учебный пример транспортного протокола.
Source Port показывает, какой процесс отправил сообщение. Destination Port - какому процессу на удалённом хосте оно предназначено. Length содержит общую длину дейтаграммы UDP, включая заголовок и полезные данные. Checksum позволяет обнаружить ошибку передачи.
Минимальная длина UDP-дейтаграммы - 8 байт, если внутри только заголовок. Максимум ограничен тем, что сообщение должно уместиться в IP-пакет. В реальной сети важную роль играет MTU (Maximum Transmission Unit) — максимальный размер кадра или пакета в байтах, который можно передать по данному каналу связи без фрагментации; для Ethernet обычно 1500 байт. При превышении MTU пакет дробят (фрагментация), что усложняет передачу. Поле Length в UDP покрывает заголовок и данные целиком.
Контрольная сумма UDP помогает обнаружить ошибку при передаче данных. Получатель пересчитывает сумму и сравнивает её с той, что указана в заголовке. Если значения не совпали, считается, что пакет пришёл с ошибкой.
Но важно помнить: UDP только выявляет проблему, а не исправляет её. При ошибке дейтаграмму обычно просто отбрасывают. Повторная отправка, ожидание таймера и другие меры восстановления - это уже забота верхнего уровня.
В Wireshark дейтаграмма UDP обычно видна как часть цепочки инкапсуляции: данные прикладного протокола вложены в UDP, UDP вложен в IP, а IP - в Ethernet-кадр. На примере DNS это очень удобно: можно увидеть и сам DNS-запрос, и его транспортную оболочку.
Если выбрать пакет DNS-запроса, в секции UDP будут видны порт отправителя из динамического диапазона и порт получателя 53. В ответном пакете эти порты меняются местами: источник - 53, получатель - тот самый динамический порт клиента.
На запросе DNS в Wireshark обычно видно: порт отправителя - случайный динамический порт, назначенный клиентскому процессу; порт получателя - 53, потому что это широко известный порт DNS-сервера. На ответе всё наоборот: источник - 53, получатель - клиентский порт.
Именно по этому клиентскому порту операционная система понимает, какому приложению отдать пришедший ответ.
Если один запрос выполняет nslookup, а другой - dig, у них будут разные порты
источника, и ОС не перепутает два параллельных процесса.
UDP быстрее за счёт простоты: нет соединения, нет подтверждений, нет повторной доставки на транспортном уровне и нет сложной логики контроля порядка. TCP, наоборот, даёт гарантии доставки и последовательности, но платит за это дополнительным временем и служебным обменом.
Поэтому выбор зависит от задачи. Если данные должны дойти точно и в правильном порядке, чаще выбирают TCP. Если критична скорость, а потеря части сообщений допустима или может быть обработана на прикладном уровне, выбирают UDP.
На практике UDP встречается гораздо чаще, чем кажется. Это DNS (Domain Name System — система доменных имён), DHCP (Dynamic Host Configuration Protocol — протокол динамической настройки узла), VoIP (Voice over IP — голосовая связь поверх IP), потоковое видео, телеметрия, игровые протоколы, SNMP (Simple Network Management Protocol — протокол простого управления сетью), syslog (протокол и формат системных журналов) в некоторых режимах и современные транспортные решения вроде QUIC (Quick UDP Internet Connections — быстрые соединения поверх UDP), который строится поверх UDP, но добавляет собственные механизмы надёжности уже на верхнем уровне.
Поэтому важно уметь быстро отличать UDP-трафик от TCP-трафика и понимать его свойства. Если вы видите потерю пакетов в видеозвонке, это одна логика анализа. Если не доходит важное подтверждение транзакции в банковской системе, логика уже совершенно другая.
Перед интерактивами зафиксируйте четыре идеи. Первое: транспортный уровень адресует процессы по портам. Второе: UDP не устанавливает соединение и не гарантирует доставку. Третье: в заголовке UDP всего четыре поля, поэтому он очень прост для анализа. Четвёртое: приложения поверх UDP могут сами добавлять таймеры, повторные запросы и свою логику обработки ошибок.
Сейчас вы закрепите тему заданиями, затем пройдёте короткий тест допуска и выполните лабораторную практику: увидите UDP в Wireshark, сравните разные порты источника у разных процессов и научитесь быстро распознавать UDP-трафик в реальной сети.
Выберите верные утверждения.
Какого поля нет в заголовке UDP?
Выберите сценарии, где UDP часто оказывается уместным.
Для доступа к практике нужно набрать не менее 80% - минимум 7 правильных ответов из 8.
1. Основная задача транспортного уровня:
2. На транспортном уровне адресация выполняется по:
3. UDP расшифровывается как:
4. В UDP нет:
5. Какой порт обычно использует DNS-сервер?
6. Что делает контрольная сумма UDP?
7. Динамические порты обычно назначает:
8. В Wireshark в ответе DNS по UDP порт источника обычно:
В этой части вы выполните 20 экранов с пошаговыми действиями. Основная цель - увидеть UDP в реальном захвате трафика, научиться находить его поля, сравнить разные клиентские порты у разных процессов и понять, как UDP используется для передачи DNS-запросов и ответов.
dns, чтобы видеть DNS-трафик поверх UDP.nslookup example.com или nslookup habr.com.После этого в Wireshark должны появиться как минимум два пакета: запрос и ответ.
Убедитесь, что данные прикладного протокола DNS вложены в UDP, а UDP - в IP.
Порт получателя должен быть 53, а порт отправителя - случайный динамический порт, который ОС назначила вашему процессу.
Length и Checksum.Запишите для себя длину дейтаграммы и убедитесь, что это не только длина данных DNS, но и заголовка UDP вместе с ними.
Сравните с запросом: теперь порт источника должен быть 53, а порт получателя - тот самый динамический клиентский порт из запроса.
Подсказка: дело именно в номере порта получателя на ответном UDP-пакете.
dig example.com или dig ya.ru. Если dig нет, просто выполните второй
nslookup в новом окне терминала.Если запросы отправляли разные процессы, скорее всего, порты будут различаться.
Это хороший пример инкапсуляции: прикладной протокол вложен в транспортный.
Если она есть, это хороший повод вспомнить: надёжность и повторные запросы клиент DNS может строить сам поверх UDP, а данные нередко приходят через резолвер и его кэш.
nslookup yandex.ru или nslookup ya.ru.Снова посмотрите UDP-поля и убедитесь, что принцип работы тот же, даже если меняются домен и длина данных.
dig example.com и сравните текстовый вывод с тем, что вы видите в Wireshark.Обратите внимание: dig подробно показывает DNS-часть, а Wireshark дополнительно наглядно показывает транспортный уровень UDP.
Подумайте, почему ответ обычно длиннее запроса: в ответе чаще больше полезных данных, чем в коротком запросе.
Подсказка: соединение, гарантия доставки, порядок следования сообщений.
Подходящие варианты: голосовой трафик, потоковое видео, игровые протоколы, DHCP, телеметрия.
Ответьте себе на вопросы:
Если вы можете уверенно ответить на эти вопросы и показать нужные поля в Wireshark, значит вы действительно разобрались с транспортным уровнем и протоколом UDP.