TCP vs UDP: в чём разница и когда какой протокол использовать
Детальное сравнение TCP и UDP: трёхстороннее рукопожатие, управление потоком, номера портов, примеры из реальной жизни и вопросы экзамена CCNA 200-301.
Полное руководство для подготовки к Cisco CCNA 200-301
Если вы готовитесь к экзамену CCNA 200-301 или просто хотите разобраться в сетевых технологиях, понимание разницы между TCP и UDP — один из фундаментальных навыков. Эти два протокола транспортного уровня (Layer 4 модели OSI) лежат в основе практически всего сетевого взаимодействия. Каждый раз, когда вы открываете веб-страницу, совершаете видеозвонок или отправляете электронное письмо — за кулисами работает один из этих протоколов.
В этой статье мы детально разберём механизмы работы TCP и UDP, сравним их характеристики, рассмотрим реальные сценарии применения и разберём типичные вопросы из экзамена CCNA.
Что такое транспортный уровень и зачем он нужен
Прежде чем погружаться в сравнение протоколов, важно понять место транспортного уровня в общей архитектуре сети.
Модель OSI и транспортный уровень
В семиуровневой модели OSI транспортный уровень (Layer 4) располагается между сеансовым уровнем (Layer 5) и сетевым уровнем (Layer 3). Его ключевые задачи:
- Сегментация данных — разбиение больших потоков данных от приложений на управляемые фрагменты
- Мультиплексирование — обеспечение одновременной работы множества приложений через одно сетевое соединение с помощью номеров портов
- Управление доставкой — в зависимости от протокола это может включать подтверждение получения, повторную отправку потерянных данных и контроль порядка
- Идентификация приложений — через номера портов транспортный уровень направляет данные к нужному приложению на устройстве
Стек TCP/IP
В практической модели TCP/IP, которая используется в реальных сетях, транспортный уровень представлен двумя основными протоколами — TCP и UDP. Оба протокола используют номера портов для идентификации приложений, но принципиально различаются в подходе к доставке данных.
TCP (Transmission Control Protocol) — надёжная доставка
Общая характеристика
TCP (Transmission Control Protocol) — это протокол транспортного уровня, ориентированный на соединение (connection-oriented). Он был разработан для обеспечения гарантированной, упорядоченной доставки данных между приложениями.
Ключевые свойства TCP:
- Ориентирован на соединение — перед передачей данных устанавливается логическое соединение
- Надёжная доставка — каждый сегмент данных подтверждается получателем
- Упорядоченность — данные доставляются в том порядке, в котором были отправлены
- Контроль потока — отправитель регулирует скорость передачи в зависимости от возможностей получателя
- Контроль перегрузки — скорость передачи адаптируется к состоянию сети
Структура TCP-сегмента
Заголовок TCP-сегмента имеет размер от 20 до 60 байт и содержит множество полей, обеспечивающих все функции протокола:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Разберём ключевые поля:
| Поле | Размер | Назначение |
|---|---|---|
| Source Port | 16 бит | Порт отправителя |
| Destination Port | 16 бит | Порт получателя |
| Sequence Number | 32 бит | Номер последовательности — указывает позицию первого байта данных в потоке |
| Acknowledgment Number | 32 бит | Номер подтверждения — указывает следующий ожидаемый байт |
| Data Offset | 4 бит | Длина заголовка (в 32-битных словах) |
| Flags (URG, ACK, PSH, RST, SYN, FIN) | 6 бит | Управляющие флаги |
| Window | 16 бит | Размер окна приёма (для управления потоком) |
| Checksum | 16 бит | Контрольная сумма для проверки целостности |
Трёхстороннее рукопожатие (Three-Way Handshake)
Это один из самых важных механизмов TCP и обязательная тема на экзамене CCNA. Прежде чем два устройства начнут обмениваться данными, они должны установить соединение через процесс, состоящий из трёх шагов.
Пошаговый разбор
Клиент Сервер
| |
| 1. SYN (Seq=100) |
|------------------------------------------>|
| |
| 2. SYN-ACK (Seq=300, Ack=101) |
|<------------------------------------------|
| |
| 3. ACK (Seq=101, Ack=301) |
|------------------------------------------>|
| |
| Соединение установлено |
| Передача данных |
|<==========================================>|Шаг 1 — SYN (Synchronize): Клиент отправляет серверу TCP-сегмент с установленным флагом SYN. В этом сегменте клиент указывает свой начальный номер последовательности (Initial Sequence Number, ISN). Допустим, ISN клиента = 100. Этот номер выбирается псевдослучайно — это важно для безопасности. Клиент переходит в состояние SYN-SENT.
Шаг 2 — SYN-ACK (Synchronize-Acknowledge): Сервер, получив SYN, отвечает сегментом с двумя установленными флагами — SYN и ACK. В поле Acknowledgment Number сервер указывает значение ISN клиента + 1 (то есть 101), подтверждая получение SYN клиента. Одновременно сервер указывает свой собственный ISN (например, 300). Сервер переходит в состояние SYN-RECEIVED.
Шаг 3 — ACK (Acknowledge): Клиент завершает рукопожатие, отправляя сегмент с флагом ACK. В поле Acknowledgment Number указывается ISN сервера + 1 (то есть 301). После этого оба устройства переходят в состояние ESTABLISHED, и начинается передача данных.
Зачем нужно трёхстороннее рукопожатие?
- Синхронизация номеров последовательности — обе стороны узнают начальные номера последовательности друг друга, что позволяет отслеживать порядок сегментов
- Проверка доступности — обе стороны убеждаются, что партнёр готов к обмену данными
- Согласование параметров — стороны обмениваются информацией о размере окна, поддерживаемых опциях (например, MSS — Maximum Segment Size)
- Предотвращение дублирования — случайные ISN предотвращают ситуации, когда старые сегменты от предыдущих соединений принимаются как часть нового
Надёжная доставка данных
После установления соединения TCP обеспечивает надёжную доставку через несколько механизмов:
Номера последовательности и подтверждения
Каждый байт данных в TCP-потоке имеет свой номер последовательности. Получатель подтверждает приём данных, отправляя ACK с номером следующего ожидаемого байта.
Отправитель Получатель
| |
| Seq=101, Data=100 bytes |
|--------------------------------------->|
| |
| Seq=201, Data=100 bytes |
|--------------------------------------->|
| |
| Ack=301 |
|<---------------------------------------|
| (получатель подтвердил 200 байт) |Повторная передача (Retransmission)
Если отправитель не получает подтверждение в течение определённого времени (Retransmission Timeout, RTO), он повторно отправляет сегмент. TCP использует адаптивный алгоритм расчёта RTO на основе измерения времени прохождения пакетов (Round-Trip Time, RTT).
Отправитель Получатель
| |
| Seq=101, Data=100 bytes |
|------------X (потерян) |
| |
| (таймер RTO истёк) |
| |
| Seq=101, Data=100 bytes (повтор) |
|--------------------------------------->|
| |
| Ack=201 |
|<---------------------------------------|Скользящее окно (Sliding Window)
Вместо того чтобы отправлять один сегмент и ждать подтверждения, TCP использует механизм скользящего окна. Отправитель может отправить несколько сегментов подряд, не дожидаясь подтверждения каждого. Количество данных, которые можно отправить без подтверждения, определяется размером окна.
Окно = 4 сегмента
Отправитель Получатель
| |
| Seg 1 |
|--------------------------------------->|
| Seg 2 |
|--------------------------------------->|
| Seg 3 |
|--------------------------------------->|
| Seg 4 |
|--------------------------------------->|
| (окно заполнено, ждём ACK) |
| |
| ACK (подтверждение Seg 1-2) |
|<---------------------------------------|
| (окно сдвигается, можно отправить ещё)|
| Seg 5 |
|--------------------------------------->|
| Seg 6 |
|--------------------------------------->|Управление потоком (Flow Control)
Управление потоком — это механизм, который позволяет получателю регулировать скорость отправки данных. Он необходим, когда получатель не успевает обрабатывать входящие данные так быстро, как их отправляет отправитель.
Как это работает:
Получатель в каждом ACK-сообщении указывает размер своего свободного буфера в поле Window Size. Отправитель не может отправить больше данных, чем указано в этом поле.
Отправитель Получатель
| |
| Data (1000 bytes) |
|--------------------------------------->|
| |
| ACK, Window=2000 |
|<---------------------------------------| (буфер свободен)
| |
| Data (2000 bytes) |
|--------------------------------------->|
| |
| ACK, Window=500 |
|<---------------------------------------| (буфер заполняется)
| |
| Data (500 bytes) |
|--------------------------------------->|
| |
| ACK, Window=0 |
|<---------------------------------------| (буфер полон!)
| |
| (отправитель приостанавливает |
| передачу и ждёт) |
| |
| ACK, Window=3000 |
|<---------------------------------------| (буфер освободился)
| |
| (отправитель возобновляет передачу) |Когда получатель отправляет Window=0, это означает «стоп, я не могу принять больше данных». Отправитель переходит в режим ожидания и периодически отправляет специальные зондирующие сегменты (Window Probe), чтобы узнать, когда буфер освободится.
Управление перегрузкой (Congestion Control)
Если управление потоком защищает получателя от перегрузки, то управление перегрузкой защищает сеть от перегрузки. Когда слишком много данных пытаются пройти через сеть одновременно, возникают потери пакетов, растут задержки.
TCP использует несколько алгоритмов управления перегрузкой:
1. Медленный старт (Slow Start): Соединение начинает передачу с маленького окна перегрузки (congestion window, cwnd) — обычно 1 MSS (Maximum Segment Size). После каждого успешного подтверждения окно удваивается. Это экспоненциальный рост, который позволяет быстро «нащупать» пропускную способность сети.
2. Предотвращение перегрузки (Congestion Avoidance): Когда cwnd достигает порога (ssthresh — slow start threshold), рост становится линейным — окно увеличивается на 1 MSS за каждый RTT. Это более осторожное увеличение скорости.
3. Быстрая повторная передача (Fast Retransmit): Если отправитель получает три дублирующих ACK (то есть четыре ACK с одним и тем же номером подтверждения), он понимает, что сегмент потерян, и немедленно повторяет передачу, не дожидаясь истечения таймера RTO.
4. Быстрое восстановление (Fast Recovery): После быстрой повторной передачи TCP не возвращается к медленному старту, а снижает cwnd вдвое и продолжает в режиме предотвращения перегрузки.
Скорость
передачи
^
| /\
| / \ /\ /\
| / \ / \ / \
| / \ / \ / \
| / \/ \ / \
| / Slow CA \ / Fast \
| / Start Recovery
| /
| /
| /
| /
| /
+-----------------------------------------> Время
CA = Congestion Avoidance
\ = Обнаружена потеря пакетаЗавершение соединения (Four-Way Termination)
Когда передача данных завершена, TCP корректно закрывает соединение через четырёхстороннюю процедуру:
Клиент Сервер
| |
| 1. FIN (Seq=500) |
|------------------------------------------>|
| "Я закончил отправку" |
| |
| 2. ACK (Ack=501) |
|<------------------------------------------|
| "Понял, но я ещё не закончил" |
| |
| 3. FIN (Seq=700) |
|<------------------------------------------|
| "Теперь я тоже закончил" |
| |
| 4. ACK (Ack=701) |
|------------------------------------------>|
| "Принято" |
| |
| Соединение полностью закрыто |Также соединение может быть сброшено экстренно с помощью флага RST (Reset) — это происходит при ошибках или когда приложение аварийно завершается.
UDP (User Datagram Protocol) — скорость и простота
Общая характеристика
UDP (User Datagram Protocol) — это простой протокол транспортного уровня, не ориентированный на соединение (connectionless). В отличие от TCP, UDP не устанавливает соединение перед передачей данных и не гарантирует их доставку.
Ключевые свойства UDP:
- Без установления соединения — данные отправляются немедленно, без предварительного рукопожатия
- Ненадёжная доставка — нет подтверждений, повторных передач и контроля порядка
- Минимальные накладные расходы — заголовок всего 8 байт
- Нет управления потоком и перегрузкой — отправитель передаёт данные с любой скоростью
- Поддержка многоадресной и широковещательной рассылки — в отличие от TCP
Структура UDP-датаграммы
Заголовок UDP элегантно прост — всего 8 байт и 4 поля:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Поле | Размер | Назначение |
|---|---|---|
| Source Port | 16 бит | Порт отправителя (необязательный) |
| Destination Port | 16 бит | Порт получателя |
| Length | 16 бит | Общая длина датаграммы (заголовок + данные) |
| Checksum | 16 бит | Контрольная сумма (необязательная в IPv4, обязательная в IPv6) |
Сравните: заголовок TCP — минимум 20 байт с множеством полей. Заголовок UDP — 8 байт и 4 поля. Эта простота — главное преимущество UDP.
Почему отсутствие подтверждений — это преимущество
На первый взгляд, отсутствие гарантий доставки кажется недостатком. Но в определённых сценариях именно это делает UDP незаменимым.
1. Минимальная задержка: TCP перед отправкой данных должен выполнить трёхстороннее рукопожатие — это как минимум 1,5 RTT задержки. UDP отправляет данные сразу. Для приложений реального времени (VoIP, видеоконференции, онлайн-игры) каждая миллисекунда задержки критична.
2. Нет блокировки Head-of-Line: В TCP, если один сегмент потерян, все последующие сегменты будут ждать повторной передачи потерянного, даже если они уже получены. Это называется Head-of-Line blocking. В UDP каждая датаграмма независима — потеря одной не влияет на обработку остальных.
3. Нет снижения скорости при перегрузке: TCP при обнаружении потерь снижает скорость передачи. Для потокового видео или голоса лучше потерять несколько пакетов, чем снизить общую скорость передачи.
4. Поддержка multicast и broadcast: TCP — это протокол точка-точка. UDP поддерживает отправку одних и тех же данных множеству получателей одновременно, что критически важно для IPTV, DHCP и других сервисов.
5. Приложение контролирует передачу: При использовании UDP приложение может реализовать собственные механизмы надёжности, оптимизированные под конкретную задачу. Например, протокол QUIC (используемый в HTTP/3) работает поверх UDP, но реализует собственные механизмы надёжной доставки, которые лучше оптимизированы для веб-трафика, чем TCP.
Детальное сравнение TCP и UDP
Таблица сравнения характеристик
| Характеристика | TCP | UDP |
|---|---|---|
| Тип соединения | Ориентирован на соединение (connection-oriented) | Без соединения (connectionless) |
| Надёжность | Гарантированная доставка с подтверждениями | Доставка не гарантируется (best-effort) |
| Порядок данных | Гарантирует порядок (Sequence Numbers) | Порядок не гарантируется |
| Размер заголовка | 20–60 байт | 8 байт |
| Скорость | Медленнее из-за накладных расходов | Быстрее благодаря простоте |
| Управление потоком | Да (Window Size) | Нет |
| Управление перегрузкой | Да (Slow Start, Congestion Avoidance) | Нет |
| Повторная передача | Да (автоматическая) | Нет |
| Broadcast/Multicast | Не поддерживает | Поддерживает |
| Установление соединения | Three-Way Handshake | Нет |
| Завершение соединения | Four-Way Termination | Нет |
| Единица данных | Сегмент (Segment) | Датаграмма (Datagram) |
| Контрольная сумма | Обязательная | Необязательная (IPv4) / Обязательная (IPv6) |
| Применение | Веб, email, передача файлов | VoIP, видеострим, DNS, DHCP, онлайн-игры |
Аналогия для понимания
TCP — заказное письмо с уведомлением: Вы отправляете письмо, получаете квитанцию с трек-номером. Почта уведомляет вас, когда письмо доставлено. Если письмо потерялось, его отправят повторно. Медленнее, но вы уверены, что адресат получит ваше сообщение.
UDP — открытка без уведомления: Вы бросаете открытку в почтовый ящик. Быстро, просто, дёшево. Но вы не знаете, дошла ли она. Если открытка потерялась — вы об этом не узнаете. Зато если вы отправляете сотни одинаковых открыток — потеря одной-двух не критична.
Номера портов: как приложения идентифицируются в сети
Классификация портов
Номера портов — это 16-битные числа (диапазон 0–65535), которые идентифицируют конкретные приложения или сервисы на устройстве.
| Диапазон | Название | Описание |
|---|---|---|
| 0–1023 | Well-Known Ports (Общеизвестные) | Закреплены за стандартными сервисами организацией IANA. Для использования обычно требуются права администратора |
| 1024–49151 | Registered Ports (Зарегистрированные) | Зарегистрированы за конкретными приложениями (например, 3389 — RDP) |
| 49152–65535 | Dynamic/Ephemeral Ports (Динамические) | Временные порты, назначаемые ОС клиентским приложениям для исходящих соединений |
Таблица популярных портов (обязательно для CCNA)
Эту таблицу необходимо знать наизусть для экзамена CCNA 200-301:
| Порт | Протокол | Сервис | Описание |
|---|---|---|---|
| 20 | TCP | FTP Data | Передача данных FTP |
| 21 | TCP | FTP Control | Управляющие команды FTP |
| 22 | TCP | SSH | Secure Shell — защищённый удалённый доступ |
| 23 | TCP | Telnet | Незащищённый удалённый доступ |
| 25 | TCP | SMTP | Отправка электронной почты |
| 53 | TCP и UDP | DNS | Разрешение доменных имён |
| 67 | UDP | DHCP Server | Сервер динамической конфигурации |
| 68 | UDP | DHCP Client | Клиент динамической конфигурации |
| 69 | UDP | TFTP | Простая передача файлов |
| 80 | TCP | HTTP | Веб-трафик (незашифрованный) |
| 110 | TCP | POP3 | Получение почты |
| 143 | TCP | IMAP | Получение почты (с синхронизацией) |
| 161 | UDP | SNMP | Мониторинг сетевых устройств |
| 162 | UDP | SNMP Trap | Уведомления от устройств |
| 443 | TCP | HTTPS | Веб-трафик (зашифрованный) |
| 514 | UDP | Syslog | Системные логи |
| 520 | UDP | RIP | Протокол маршрутизации RIP |
| 3389 | TCP | RDP | Удалённый рабочий стол (Windows) |
Особый случай: DNS — TCP и UDP одновременно
DNS заслуживает отдельного внимания, поскольку использует оба протокола:
- UDP порт 53 — для обычных DNS-запросов (большинство запросов). Запрос и ответ обычно помещаются в одну датаграмму, поэтому накладные расходы TCP нецелесообразны
- TCP порт 53 — для передачи зон (zone transfer) между DNS-серверами и для ответов, превышающих 512 байт. Также используется при реализации DNSSEC
Как работают порты на практике: пример веб-запроса
Когда вы открываете сайт https://example.com в браузере:
Ваш компьютер Веб-сервер
192.168.1.10 93.184.216.34
Src IP: 192.168.1.10 Dst IP: 93.184.216.34
Src Port: 52431 (ephemeral) Dst Port: 443 (HTTPS)
| |
| SYN [52431 -> 443] |
|--------------------------------------->|
| |
| SYN-ACK [443 -> 52431] |
|<---------------------------------------|
| |
| ACK [52431 -> 443] |
|--------------------------------------->|
| |
| TLS Handshake + HTTP Request |
|<======================================>|Комбинация из четырёх элементов — IP-адрес источника + порт источника + IP-адрес назначения + порт назначения — однозначно идентифицирует каждое соединение. Это позволяет одному компьютеру поддерживать сотни одновременных соединений с разными (или даже одним) сервером.
Реальные сценарии применения
Почему видеозвонки используют UDP
Представьте видеозвонок в Zoom или Microsoft Teams. Вот что происходит при использовании UDP:
Сценарий: потерян один пакет из видеопотока
Пакет 1: [Кадр 1, часть 1] ✓ Получен
Пакет 2: [Кадр 1, часть 2] ✗ Потерян
Пакет 3: [Кадр 2, часть 1] ✓ Получен
Пакет 4: [Кадр 2, часть 2] ✓ Получен
Пакет 5: [Кадр 3, часть 1] ✓ Получен
Результат с UDP: Кадр 1 слегка искажён (маленький артефакт),
но кадры 2 и 3 показаны вовремя. Пользователь может
даже не заметить проблему.Тот же сценарий, если бы использовался TCP:
Пакет 1: [Кадр 1, часть 1] ✓ Получен
Пакет 2: [Кадр 1, часть 2] ✗ Потерян
Пакет 3: [Кадр 2, часть 1] ✓ Получен (но ждёт в буфере!)
Пакет 4: [Кадр 2, часть 2] ✓ Получен (но ждёт в буфере!)
Пакет 5: [Кадр 3, часть 1] ✓ Получен (но ждёт в буфере!)
...TCP обнаруживает потерю, запрашивает повторную передачу...
...проходит ещё 1-2 RTT...
Пакет 2: [Кадр 1, часть 2] ✓ Получен повторно
Теперь все пакеты обрабатываются, но с задержкой 100-200 мс.
Результат: видео "замирает", а потом ускоренно проигрывается.
Голос прерывается. Разговор становится неудобным.Для видеозвонков и потокового видео потеря нескольких пакетов гораздо менее критична, чем задержка. Человеческий мозг легко «дорисовывает» пропущенный кадр, но крайне негативно воспринимает рассинхронизацию голоса и видео.
Именно поэтому протоколы реального времени (RTP, SIP, WebRTC) работают поверх UDP.
Почему загрузка файлов использует TCP
Теперь рассмотрим противоположный сценарий — скачивание файла (например, ISO-образа операционной системы или важного документа).
Что произойдёт, если потерять пакет при загрузке файла через UDP?
Файл: operating_system.iso (4 ГБ)
Пакет 1: [байты 0-1459] ✓ Получен
Пакет 2: [байты 1460-2919] ✗ Потерян!
Пакет 3: [байты 2920-4379] ✓ Получен
...
Пакет N: [последние байты] ✓ Получен
Результат: файл повреждён. ISO-образ не монтируется.
Контрольная сумма не совпадает. 4 ГБ скачаны впустую.Тот же сценарий с TCP:
Файл: operating_system.iso (4 ГБ)
Пакет 1: [байты 0-1459] ✓ Получен, ACK
Пакет 2: [байты 1460-2919] ✗ Потерян
Пакет 3: [байты 2920-4379] ✓ Получен (буферизирован)
TCP обнаруживает потерю → повторная передача пакета 2
Пакет 2: [байты 1460-2919] ✓ Получен повторно
Результат: файл целый, контрольная сумма совпадает.
Загрузка заняла на 50 мс дольше — незаметно для пользователя.Для передачи файлов, веб-страниц, электронной почты и любых данных, где важна целостность, TCP — единственный правильный выбор. Небольшая дополнительная задержка незаметна, а гарантия целостности критически важна.
Сводная таблица: какие приложения используют какой протокол
| Приложение | Протокол | Почему |
|---|---|---|
| Веб-браузер (HTTP/HTTPS) | TCP | Веб-страницы должны загружаться полностью и корректно |
| Электронная почта (SMTP, POP3, IMAP) | TCP | Письма должны доставляться целиком |
| Передача файлов (FTP, SFTP) | TCP | Файлы не должны быть повреждены |
| SSH (удалённое управление) | TCP | Каждая команда должна быть доставлена |
| VoIP (голосовые звонки) | UDP | Задержка критичнее, чем потеря пакетов |
| Видеоконференции (Zoom, Teams) | UDP | Задержка критичнее, чем качество отдельных кадров |
| Потоковое видео (начальная загрузка) | TCP | Для HTTPS-соединения с сервером |
| Потоковое видео (сам поток) | UDP (или TCP с буферизацией) | Зависит от реализации |
| Онлайн-игры (геймплей) | UDP | Минимальная задержка критична |
| DNS-запросы | UDP (обычно) | Быстрый запрос-ответ, помещается в одну датаграмму |
| DNS (трансфер зон) | TCP | Большие объёмы данных, нужна надёжность |
| DHCP | UDP | Broadcast-рассылка, клиент ещё не имеет IP-адреса |
| SNMP | UDP | Мониторинг, частые запросы, допустимы потери |
| TFTP | UDP | Простота (но реализует собственный механизм подтверждений) |
| Syslog | UDP | Частые сообщения, потеря отдельных записей допустима |
| NTP (синхронизация времени) | UDP | Маленькие пакеты, частые обмены |
Разбор вопросов из экзамена CCNA 200-301
Вопрос 1: Основы TCP
Вопрос: Which of the following are features of TCP? (Choose three)
A) Connection-oriented B) Connectionless C) Reliable delivery D) Best-effort delivery E) Sequencing of data F) No acknowledgments
Правильный ответ: A, C, E
Разбор: TCP — это протокол, ориентированный на соединение (A), обеспечивающий надёжную доставку с подтверждениями (C) и гарантирующий порядок данных через номера последовательности (E). Варианты B, D и F описывают характеристики UDP.
Вопрос 2: Трёхстороннее рукопожатие
Вопрос: A host is initiating a TCP connection to a server. What is the correct order of the TCP three-way handshake?
A) ACK, SYN-ACK, SYN B) SYN, ACK, SYN-ACK C) SYN, SYN-ACK, ACK D) SYN-ACK, SYN, ACK
Правильный ответ: C
Разбор: Порядок всегда один и тот же:
- Клиент → Сервер: SYN
- Сервер → Клиент: SYN-ACK
- Клиент → Сервер: ACK
Мнемоника: «Клиент начинает, сервер отвечает двойным флагом, клиент подтверждает».
Вопрос 3: Определение протокола по порту
Вопрос: A network administrator captures traffic on port 69. Which protocol and transport type is most likely being used?
A) DNS over UDP B) TFTP over UDP C) DHCP over UDP D) FTP over TCP
Правильный ответ: B
Разбор: Порт 69 — это TFTP (Trivial File Transfer Protocol), который работает поверх UDP. Важно не путать TFTP (порт 69, UDP) с FTP (порты 20/21, TCP). Несмотря на похожие названия, это совершенно разные протоколы.
Вопрос 4: Управление потоком
Вопрос: Which TCP mechanism allows the receiver to control the rate at which the sender transmits data?
A) Congestion control B) Three-way handshake C) Flow control (windowing) D) Error recovery
Правильный ответ: C
Разбор: Управление потоком (flow control) через механизм окна (windowing) позволяет получателю регулировать скорость отправителя, сообщая размер свободного буфера в поле Window Size. Управление перегрузкой (congestion control, вариант A) — это другой механизм, который защищает сеть, а не получателя.
Вопрос 5: Выбор протокола для приложения
Вопрос: Which transport layer protocol would be most appropriate for a real-time voice application?
A) TCP, because it provides reliable delivery B) UDP, because it provides lower latency C) TCP, because it provides flow control D) UDP, because it provides sequencing
Правильный ответ: B
Разбор: Для голосовых приложений реального времени UDP предпочтительнее, потому что обеспечивает минимальную задержку. В голосовой связи задержка более 150 мс уже заметна пользователю, а более 300 мс делает разговор крайне некомфортным. Потеря отдельных голосовых пакетов менее критична — кратковременные пропуски звука менее раздражают, чем задержки и эхо.
Вопрос 6: Идентификация соединения
Вопрос: Which combination of values uniquely identifies a TCP connection?
A) Source IP address and destination IP address B) Source port and destination port C) Source IP address, destination IP address, source port, and destination port D) Source MAC address and destination MAC address
Правильный ответ: C
Разбор: TCP-соединение уникально идентифицируется четвёркой значений (4-tuple): IP-адрес источника, IP-адрес назначения, порт источника, порт назначения. Одних IP-адресов недостаточно (один хост может иметь множество соединений с одним сервером), одних портов тоже (один и тот же порт может использоваться для соединений с разными серверами). MAC-адреса работают на L2 и не используются для идентификации TCP-соединений.
Вопрос 7: DNS и транспортные протоколы
Вопрос: DNS primarily uses which transport layer protocol for standard queries?
A) TCP B) UDP C) Both TCP and UDP equally D) Neither TCP nor UDP
Правильный ответ: B
Разбор: Стандартные DNS-запросы используют UDP порт 53. Типичный DNS-запрос и ответ помещаются в одну датаграмму (до 512 байт), поэтому накладные расходы TCP неоправданны. TCP используется DNS только для передачи зон (zone transfer), ответов размером более 512 байт и при использовании DNSSEC. Вариант C неверен, потому что UDP используется значительно чаще для обычных запросов.
Вопрос 8: Порты DHCP
Вопрос: Which ports are used by DHCP?
A) TCP 67 and TCP 68 B) UDP 67 and UDP 68 C) TCP 53 and UDP 53 D) UDP 67 only
Правильный ответ: B
Разбор: DHCP использует UDP: порт 67 для сервера и порт 68 для клиента. DHCP использует UDP по нескольким причинам:
- Клиент в момент DHCP Discover ещё не имеет IP-адреса, поэтому не может установить TCP-соединение
- DHCP Discover отправляется как broadcast (255.255.255.255), что не поддерживается TCP
- Процесс DORA (Discover, Offer, Request, Acknowledge) достаточно прост и не требует гарантий доставки TCP
Советы по подготовке к CCNA
Что точно нужно знать
-
Трёхстороннее рукопожатие — порядок флагов (SYN → SYN-ACK → ACK) и что происходит на каждом шаге
-
Ключевые отличия TCP от UDP — тип соединения, надёжность, размер заголовка, управление потоком
-
Номера портов наизусть — как минимум: FTP (20/21), SSH (22), Telnet (23), SMTP (25), DNS (53), DHCP (67/68), TFTP (69), HTTP (80), HTTPS (443), SNMP (161)
-
Какой протокол для какого приложения — уметь обосновать, почему конкретное приложение использует TCP или UDP
-
Разницу между управлением потоком и управлением перегрузкой — flow control защищает получателя, congestion control защищает сеть
Частые ловушки на экзамене
- TFTP ≠ FTP. TFTP использует UDP порт 69, FTP использует TCP порты 20/21
- DNS использует оба протокола, но на экзамене обычно спрашивают про стандартные запросы — это UDP
- DHCP использует UDP, не TCP — помните о broadcast
- Window Size в TCP — это механизм управления потоком (flow control), а не управления перегрузкой (congestion control)
- Ephemeral порты (49152-65535) — это временные порты клиента, а не серверные порты
Заключение
TCP и UDP — это два фундаментально разных подхода к транспортировке данных, каждый из которых оптимизирован для своего класса задач.
TCP — ваш выбор, когда данные должны быть доставлены полностью, в правильном порядке и без ошибок. Веб-страницы, файлы, электронная почта, удалённое управление — везде, где потеря даже одного байта приведёт к ошибке.
UDP — ваш выбор, когда скорость и минимальная задержка важнее гарантии доставки. Голосовая связь, видеоконференции, онлайн-игры, DNS-запросы — везде, где потеря отдельных пакетов допустима, а задержка — нет.
Понимание этих протоколов — не просто требование для сдачи CCNA 200-301. Это фундаментальное знание, которое будет полезно на протяжении всей карьеры в сетевых технологиях. Каждый раз, когда вы будете диагностировать сетевую проблему, настраивать QoS-политики, проектировать сетевую архитектуру или анализировать трафик в Wireshark — знание TCP и UDP будет вашим инструментом.
Готовитесь к CCNA 200-301? Сохраните таблицу портов из этой статьи — она пригодится и на экзамене, и в реальной работе. Тема TCP/UDP входит в раздел «IP Connectivity» экзамена и составляет значительную часть вопросов.