Developer

Модель OSI и TCP/IP, TCP и UDP

↑ 1.1 Сети и протоколы для бэкенда · → Следующая: HTTP для бэкенда

Желательно~5 мин чтенияУровень: junior

Зачем это на собесе

Бэкендер должен понимать, что происходит с запросом ниже HTTP: откуда таймауты, почему «connection reset», зачем keep-alive и пулы соединений, почему gRPC требует HTTP/2. Вопросы про OSI и TCP vs UDP задают на любом бэкенд-собесе.

Подтемы

  • Модель OSI и TCP/IP, инкапсуляция
  • TCP: handshake, надёжность, flow и congestion control, закрытие соединения
  • UDP и где его применяют (QUIC)
  • Порты, сокеты, эфемерные порты
  • Что это значит для .NET: HttpClient, пулы соединений, таймауты

Объяснение

Модель OSI (7 уровней) и TCP/IP (4 уровня)

Уровни OSIУровень TCP/IPПримеры
7 Прикладной, 6 Представления, 5 СеансовыйПрикладнойHTTP, gRPC, DNS, SMTP, TLS*
4 ТранспортныйТранспортныйTCP, UDP, QUIC
3 СетевойИнтернетIP, ICMP
2 Канальный, 1 ФизическийСетевой доступEthernet, Wi-Fi, кабель

*TLS формально между 4 и 7 уровнем. На практике оперируют моделью TCP/IP, а OSI спрашивают как теорию.

Инкапсуляция: данные приложения → сегмент TCP (порты) → пакет IP (адреса) → кадр Ethernet (MAC).

TCP

  • С установкой соединения: 3-way handshake (SYN → SYN-ACK → ACK).
  • Надёжность: нумерация байтов, подтверждения (ACK), повторная отправка, контрольные суммы.
  • Порядок: получатель собирает поток в правильной последовательности.
  • Flow control (окно получателя) и congestion control (slow start, AIMD).
  • Закрытие: FIN/ACK в обе стороны. Состояние TIME_WAIT у закрывающей стороны держит порт ~60 с.
  • Поток байтов, а не сообщений: границы сообщений определяет протокол выше (HTTP Content-Length, gRPC length-prefix).

UDP

  • Без соединения, без гарантий доставки и порядка, минимальный заголовок.
  • Быстро и без задержки на handshake.
  • Применение: DNS, видео и голос, игры, метрики (StatsD), QUIC → HTTP/3 (надёжность реализована поверх UDP).

Порты и сокеты

  • Соединение идентифицируется четвёркой: IP и порт клиента, IP и порт сервера.
  • Порты: 0–1023 системные (80 HTTP, 443 HTTPS, 5432 PostgreSQL, 8123/9000 ClickHouse, 9092 Kafka, 6379 Redis).
  • Клиент получает эфемерный порт. Их число ограничено (~28–60 тыс.), отсюда проблема исчерпания портов при создании нового соединения на каждый запрос.

Что это значит для .NET-разработчика

// ПЛОХО: новый HttpClient на каждый запрос → новые TCP-соединения, TIME_WAIT, исчерпание сокетов
using var client = new HttpClient();
var data = await client.GetStringAsync(url);
 
// ХОРОШО: IHttpClientFactory переиспользует соединения (пул обработчиков)
builder.Services.AddHttpClient<TerminologyClient>(c => c.BaseAddress = new Uri(cfg["Terminology:Url"]!));
  • Пул соединений к БД (Npgsql) — по той же причине: handshake TCP, TLS и авторизация дорогие.
  • Keep-alive и HTTP/2 мультиплексирование снижают число соединений.
  • Таймауты бывают разные: connect (установка TCP), read (ожидание данных), общий на запрос.

Нюансы и подводные камни

  • Connection refused — на порту никто не слушает (сервис не поднят, не тот порт). Connection timed out — пакеты не доходят (firewall, сеть). Connection reset — соединение оборвала другая сторона или прокси.
  • Nginx или балансировщик держит свои соединения к бэкенду: таймауты прокси (proxy_read_timeout) должны быть согласованы с таймаутами приложения.
  • NAT и балансировщики закрывают «простаивающие» соединения: долгоживущим соединениям (gRPC-стримы, WebSocket) нужны keep-alive пинги.
  • В Docker сервисы общаются по именам в общей сети compose, и localhost внутри контейнера — это сам контейнер.
  • MTU и фрагментация — редкая, но реальная причина «висящих» запросов с большими ответами через VPN.

Вопросы с ответами

Связанные темы

Вид графа

Обратные ссылки