9.1. Протоколы TCP и UDP
9.1. Протоколы TCP и UDP
Транспортный уровень обеспечивает логическую связь между процессами (приложениями) на разных узлах. Адресация на транспортном уровне выполняется с помощью портов (16 бит, диапазон 0–65535).
9.1.1. Сравнение TCP и UDP
| Параметр | TCP | UDP |
|---|---|---|
| Соединение | Ориентированный на соединение | Без установления соединения |
| Надёжность | Подтверждения (ACK), повторная передача | Без гарантий доставки |
| Порядок доставки | Гарантирован (номера последовательности) | Не гарантирован |
| Контроль перегрузки | Есть (окно, slow start) | Нет |
| Накладные расходы | Выше (20+ байт заголовка) | Ниже (8 байт заголовка) |
| Типичное применение | HTTP, HTTPS, SSH, SMTP, FTP | DNS, VoIP, видеострим, DHCP |
9.1.2. Трёхстороннее рукопожатие TCP
- SYN — клиент отправляет запрос на установление соединения с начальным номером последовательности (Seq=J).
- SYN-ACK — сервер подтверждает (Ack=J+1) и отправляет свой SYN (Seq=K).
- ACK — клиент подтверждает (Ack=K+1); соединение переходит в состояние ESTABLISHED.
Рисунок 4 — Трёхстороннее рукопожатие TCP (3-way handshake)
9.1.3. Состояния TCP-соединения
| Состояние | Описание |
|---|---|
| LISTEN | Сервер ожидает входящих соединений на порту |
| SYN_SENT | Клиент отправил SYN, ждёт ответа |
| ESTABLISHED | Соединение установлено, идёт обмен данными |
| FIN_WAIT / CLOSE_WAIT | Процесс закрытия соединения |
| TIME_WAIT | Ожидание перед полным закрытием (2×MSL) |
9.1.4. Сокет
Сокет однозначно определяется кортежем (IP-адрес, порт). Пример: 192.168.1.10:52431 → 93.184.216.34:443 — HTTPS-соединение с веб-сервером.
Контрольные вопросы
- Почему DNS может использовать UDP, а HTTP — TCP?
- Опишите три шага установления TCP-соединения.
- Что означает состояние LISTEN в выводе netstat?
- Какие well-known порты используют HTTP и HTTPS?
9.1.5. Диапазоны портов
| Диапазон | Название | Примеры |
|---|---|---|
| 0–1023 | Well-known | 80 HTTP, 443 HTTPS, 22 SSH |
| 1024–49151 | Registered | 3306 MySQL, 5432 PostgreSQL |
| 49152–65535 | Dynamic / private | Эфемерные порты клиентов |
9.1.6. Контроль перегрузки TCP
Slow start — экспоненциальный рост окна после установления соединения. Congestion avoidance — линейный рост при приближении к порогу. При потере (таймаут или 3 дубликата ACK) — уменьшение окна. TCP Reno, CUBIC, BBR — разные алгоритмы; BBR (Google) ориентирован на задержку, а не только на потери.
9.1.7. Завершение соединения TCP
Четырёхстороннее закрытие: FIN → ACK → FIN → ACK. Состояние TIME_WAIT (обычно 2×MSL, 1–4 мин) на стороне, закрывшей соединение первой — защита от поздних дубликатов. Много TIME_WAIT на сервере — признак коротких соединений или нагрузочного тестирования.
9.1.8. UDP: когда отсутствие надёжности — преимущество
VoIP и видеоконференции: повторная доставка старых пакетов бесполезна. DNS-запросы — один пакет вопрос, один ответ. DHCP, SNMP, игровой трафик с низкой задержкой. Надёжность при необходимости реализуется на прикладном уровне (QUIC поверх UDP для HTTP/3).
9.1.9. Сравнение с QUIC и HTTP/3
QUIC — транспорт поверх UDP с встроенным шифрованием (TLS 1.3), мультиплексированием потоков без блокировки head-of-line, как в TCP. HTTP/3 использует QUIC вместо TCP+TLS. Снижает задержку при потере пакетов на нестабильных каналах.
9.1.10. Диагностика транспортного уровня
netstat -an / ss -tunap — состояния LISTEN, ESTABLISHED, CLOSE_WAIT (утечка — сервер не закрывает). telnet host 80 или nc -zv host 443 — проверка открытого порта. Wireshark: фильтр tcp.flags.syn==1 and tcp.flags.ack==0 для новых соединений.
Дополнительные вопросы для самопроверки
- Почему TIME_WAIT не является ошибкой сам по себе?
- Может ли DNS использовать TCP и когда?
- Чем HTTP/3 принципиально отличается от HTTP/1.1 по транспорту?