Распределённые системы взаимодействуют через подсети, маршруты, DNS, межсетевые экраны и балансировщики — ещё до того, как сработает REST или Kafka. Системный аналитик, проектирующий интеграции (03.05.01 Виды интеграции (точка-точка, ESB, API-led)), API-контракты (03.05.02 REST и OpenAPI спецификации) или нефункциональные требования (08.02 Нефункциональные требования (НФТ) — классификация и стандарты), должен понимать сетевой контур вокруг вызова: куда идёт пакет, какие порты открыты, почему из подсети A не видна подсеть B.

Заметка не готовит сетевого администратора. Она даёт минимум для диалога с сетевиками, архитекторами и ИБ — и для фиксации сетевых параметров в спецификации.

1. Суть темы

Сеть — это не «фон» интеграции, а часть контракта. Если в спецификации указан endpoint https://api.partner.ru/v1/orders, но не описаны DNS, порты, маршрут между контурами и правила firewall — команда не сможет воспроизвести доступ на стенде и в проде.

Что аналитик должен уметь после прочтения:

  • Читать CIDR и отличать частные адреса от публичных.
  • Понимать, как пакет попадает из одной подсети в другую (шлюз, таблица маршрутов, VPN/peering).
  • Задавать вопросы по TCP/UDP, DNS, TLS, firewall, балансировщику L4/L7.
  • Сопоставлять SLA по latency с физикой RTT и не смешивать сетевой rate limit с прикладным (03.06.03 Rate Limiting — управление пропускной способностью).

Детали HTTP, REST, gRPC и OpenAPI — в 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL) и 07.02 Работа с API (практика). Здесь — только сетевой слой вокруг них.

2. Ключевые понятия

2.1. Модель OSI и стек TCP/IP

Полный стек OSI аналитику не нужен, но три уровня — прикладной, транспортный, сетевой — постоянно всплывают в требованиях.

Уровень OSIНазваниеПримерыЧто важно аналитику
7Прикладной (Application)HTTP, HTTPS, DNS, MQTTREST, GraphQL, gRPC (поверх HTTP/2) — здесь. Форматы JSON, XML, Protobuf.
6Представления (Presentation)TLS, MIME, кодировкиШифрование и сериализация. TLS участвует в установке HTTPS, но рукопожатие начинается уже на этапе соединения — не привязывайте HTTPS строго к «уровню 6».
5Сеансовый (Session)NetBIOS, RPCДолгоживущие сессии на уровне ОС. gRPC stream — прикладная логика поверх HTTP/2, не «уровень 5 OSI».
4Транспортный (Transport)TCP, UDP, QUICПорты, рукопожатие, надёжность. QUIC — основа HTTP/3 (UDP/443).
3Сетевой (Network)IP, ICMP, маршрутизаторыАдресация, подсети, маршрутизация. ICMP — ping и traceroute; часто режут, см. ниже.
2–1Канальный / физическийEthernet, кабельВ спецификации аналитика почти не фигурируют.

Модель TCP/IP объединяет уровни 5–7 в «Прикладной». Для интеграций достаточно помнить:

  • gRPC требует HTTP/2 → L4-балансировщик без termination «пропускает TCP/443», но L7 LB и API gateway должны понимать HTTP/2 и ALPN — иначе соединение установится, а маршрутизация по протоколу сломается.
  • HTTP/3 (QUIC) идёт по UDP/443. Политика firewall «только TCP на 443» блокирует HTTP/3; в NFR укажите допустимые версии HTTP и протокол транспорта.

2.2. IP-адресация, подсети и NAT

Каждый хост имеет IP-адрес (IPv4, например 192.168.1.10, или IPv6). Адрес всегда принадлежит подсети (subnet) — логическому сегменту для изоляции и политик безопасности.

CIDR: запись 192.168.1.0/24 означает, что первые 24 бита — адрес сети, остальные — хосты. Диапазон хостов: 192.168.1.1–192.168.1.254 (.0 — сеть, .255 — broadcast).

В правилах firewall и whitelist партнёра маска критична:

  • /32 — один конкретный хост (например, 203.0.113.5/32).
  • /24 — вся подсеть (256 адресов). Ошибка маски = «открыли не то»: слишком широкий диапазон — риск ИБ; слишком узкий — часть стенда не попадает в ACL.

Типичные частные диапазоны (RFC 1918):

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

Они не маршрутизируются в Интернете. Выход «наружу» — через NAT (Network Address Translation).

SNAT и DNAT — два разных сценария для спецификации:

НаправлениеМеханизмЧто зафиксировать в интерфейсе
Исходящий (мы client → партнёр)SNAT: частный IP подменяется на публичный на шлюзеПубличный egress IP или диапазон CIDR, который партнёр вносит в whitelist. Уточните: стенд и прод используют один NAT или разные.
Входящий (партнёр → наш webhook)DNAT: публичный IP/DNS перенаправляется на LB/backendПубличный URL, порт, правило на балансировщике, сертификат, mTLS при необходимости.

Типовая ловушка: в ACL указан «правильный» внутренний IP, а на выходе SNAT подставляет другой — партнёр отклоняет запрос. Связывайте whitelist и NAT в одном абзаце спецификации, а не двумя несвязанными строками.

IPv6 и dual-stack. Запись AAAA в DNS указывает на IPv6. В облаках часто включён dual-stack (IPv4 + IPv6). В интерфейсе укажите: endpoint принимает IPv4, IPv6 или оба — иначе firewall пропустит «не тот» стек.

В облаках (AWS, Azure, Яндекс.Облако) подсети живут внутри VPC. Отдельные подсети для frontend, backend и БД — стандарт для разных Security Group. Контуры «Internet / DMZ / private» удобно показать на 03.01.02 Моделирование контекста системы (Context Diagram). Связь с контейнерами — в 07.08 Контейнеризация и оркестрация (Docker, Kubernetes): localhost и 127.0.0.1 работают только на одной машине; в K8s сервисы адресуются по DNS-имени сервиса, а не loopback.

2.3. Маршрутизация — как пакет попадает «туда, куда нужно»

Маршрутизация (routing) — выбор пути IP-пакета между сетями. Это центральная тема заголовка статьи и частый источник инцидентов «из нашей подсети партнёр не виден».

Шлюз по умолчанию (default gateway). Хост в подсети знает: «всё, что не в моей локальной сети, отправляю на шлюз» — обычно .1 в CIDR (например, 10.0.1.1 для 10.0.1.0/24). Без корректного default gateway хост «видит соседей», но не выходит за пределы подсети.

Маршрут до конкретной подсети. Если цель — другая подсеть (другая VPC, офис партнёра, DMZ), нужна запись в таблице маршрутизации: «трафик на 172.16.5.0/24 отправлять через шлюз X» или через VPN-туннель / peering.

СценарийЧто спросить у сетевиков
Две подсети в одной VPCЕсть ли маршрут между subnet A и B? Не блокирует ли NACL или Security Group?
Две VPC / два облачных контураVPC peering — кто инициатор, маршрут односторонний или двусторонний? Private Link / PrivateLink — доступ к сервису без публичного IP; нужна ли private DNS zone? Transit Gateway — хаб для нескольких VPC; кто добавляет маршрут и какие CIDR «видны» через хаб? Детали топологии согласуйте с сетевиками и архитектором.
Офис ↔ облакоSite-to-site VPN или dedicated line; какие подсети «видны» с каждой стороны?
Интеграция с внешним партнёром через ИнтернетПубличный IP или диапазон; SNAT на нашей стороне (какой IP увидит партнёр); whitelist vs маршрут — оба обязательны
Callback / webhook от партнёраВходящий маршрут + DNAT на балансировщик; асимметричная маршрутизация — ответ может уйти другим путём

NACL vs Security Group. В облаках часто работают оба слоя:

  • NACL (Network ACL) — на уровне подсети, stateless: для ответного трафика нужны явные правила в обе стороны.
  • Security Group — на интерфейсе хоста/LB, stateful: разрешили входящий запрос — ответ обратно пропускается автоматически.

«Открыли порт в SG», но NACL режет обратный пакет — типовой слепой угол. При инциденте спросите про оба.

ICMP и диагностика. Ping (ICMP) часто блокируют на firewall. Отсутствие ping не доказывает недоступность TCP-сервиса — проверяйте конкретный порт (nc, telnet, curl на HTTPS). Traceroute тоже может не проходить при закрытом ICMP.

Статическая vs динамическая маршрутизация. На практике аналитику достаточно различения: статический маршрут прописан вручную (типично для VPN/peering к партнёру); динамический — протоколы вроде BGP внутри ЦОДа/облака. При интеграции между контурами уточняйте: кто добавляет маршрут, срок согласования и тестовый стенд с теми же маршрутами.

Асимметричная маршрутизация. Запрос от партнёра приходит через один канал, а ответ уходит другим — firewall может отбросить «неожиданный» обратный пакет. Для двусторонних интеграций и webhook'ов это обязательный вопрос.

DMZ (demilitarized zone). Промежуточный сегмент между внешней сетью и внутренней. Публичный API часто принимает трафик в DMZ; backend в приватной подсети. В спецификации укажите: «входящий трафик → DMZ (подсеть X) → LB → backend (подсеть Y)».

2.4. TCP и UDP

TCP — соединение, трёхстороннее рукопожатие (SYN → SYN-ACK → ACK), гарантия доставки и порядка. HTTP, HTTPS, PostgreSQL, AMQP, Kafka — всё на TCP. Каждый новый вызов (или пул соединений) тратит время на handshake.

UDP — без соединения, без гарантий. DNS (чаще UDP на порту 53), VoIP, QUIC/HTTP/3. DNS по TCP исторически использовался при ответах >512 байт; с EDNS0 большинство ответов остаётся на UDP — TCP DNS всплывает при zone transfer и аномально больших записях.

Эфемерные порты (ephemeral ports). Клиент при исходящем TCP выбирает случайный высокий порт (например, 49152–65535). Если firewall партнёра или ваш исходящий фильтр режет диапазон — соединение не установится, хотя порт 443 «открыт».

Асинхронные брокеры (03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events)) тоже работают поверх TCP — учитывайте установку соединения в сценариях с частым переподключением.

2.5. DNS

DNS преобразует имя (api.partner.ru) в IP. В спецификации указывайте DNS-имя endpoint, а не жёсткий IP — IP меняется, сертификаты и балансировщики проще обслуживать.

Тип записиНазначение
AIPv4-адрес
AAAAIPv6-адрес
CNAMEПсевдоним на другое имя
TXTПодтверждение домена, SPF/DKIM
SRVХост и порт сервиса

Повторные вызовы API часто не обращаются к DNS — клиент кэширует ответ по TTL. Это объясняет «первый запрос медленнее, второй быстрее»; при смене IP балансировщика учитывайте время жизни кэша.

CDN и latency. Если статика или публичный API отдаются через CDN (Content Delivery Network), клиент ближайшего edge получает меньший RTT. В интерфейсе зафиксируйте: вызов идёт через CDN или напрямую в origin. Для НФТ по latency (08.02 Нефункциональные требования (НФТ) — классификация и стандарты) это разные сценарии измерения.

2.6. Firewall, Security Group, WAF и порты

Firewall фильтрует пакеты по правилам: источник, назначение, порт, протокол (TCP/UDP), маска CIDR, действие. В облаке аналог на уровне хоста — Security Group; на уровне подсети — NACL (см. §2.3).

WAF (Web Application Firewall) — не замена сетевому firewall. Это L7-политики: OWASP-правила, лимит размера body, блокировка SQLi/XSS. WAF часто стоит перед API gateway, заказчик политик — ИБ или платформенная команда (03.05.05 Безопасность API, 08.07 Основы кибербезопасности для системного аналитика). В спецификации разделяйте: «открыть порт 443 на SG» и «политики WAF на endpoint».

Rate limiting на сети (пакеты/соединения в секунду на firewall или WAF) — не то же самое, что прикладной rate limit API (03.06.03 Rate Limiting — управление пропускной способностью). Оба уровня фиксируйте отдельно.

TLS и mTLS. TLS шифрует канал; mTLS требует клиентский сертификат — типично в B2B. В интерфейсе: минимальная версия TLS, CA, нужен ли клиентский сертификат с нашей или партнёрской стороны, срок ротации.

2.7. Балансировщики, reverse proxy и API gateway

Load Balancer (L4) — балансировка по IP и порту, без разбора HTTP. Пропускает TCP, но не маршрутизирует по URL.

Load Balancer (L7) — маршрутизация по URL, заголовкам, cookie; TLS termination на балансировщике или end-to-end шифрование до backend. Sticky sessions (привязка клиента к одному backend по cookie/IP) — зафиксируйте в интерфейсе, если состояние хранится на сервере, иначе запросы «прыгают» между инстансами.

Reverse proxy и API gateway в enterprise часто совмещают с L7 LB: маршрутизация, аутентификация, rate limit на уровне 7. В требованиях не путайте «нужен LB» и «нужен API gateway с политиками» — уточняйте роль компонента.

X-Forwarded-For / X-Real-IP. За reverse proxy и L7 LB партнёр и backend видят IP балансировщика, а не клиента. Если audit, whitelist или rate limit на backend завязаны на IP источника — укажите передачу заголовков или fixed egress IP.

Health check vs доступ клиента. LB проверяет backend на внутреннем порту (например, :8080/health), а клиент ходит на :443. «Сервис то доступен, то нет» часто означает падение backend по health check, а не проблему сети снаружи. Алгоритмы и настройки — в 03.06.04 Стратегии балансировки нагрузки.

2.8. Latency, bandwidth, таймауты

  • Latency (RTT) — время туда-обратно. Внутри ЦОДа <1 мс; между регионами — десятки мс. Синхронный REST добавляет RTT к каждому вызову (03.06.01 Архитектурные паттерны распределённых систем — когда уходить в асинхрон).
  • Bandwidth — объём данных в единицу времени; важен для файлов и стриминга.
  • Jitter — разброс задержки; критичен для real-time.

Таймауты (различайте в требованиях и при разборе инцидентов):

ТаймаутЧто измеряет
Connect timeoutУстановка TCP (SYN, SYN-ACK)
TLS handshake timeoutОбмен сертификатами после TCP
Read timeoutОжидание тела ответа после отправки запроса

«Сервис не отвечает за 200 мс» может означать недостижимый RTT между континентами — проверяйте физику до подписания SLA.

3. Как применяется в работе аналитика

3.1. Исходящий vs входящий доступ

ПаттернСетевая логика
Мы только clientИсходящий firewall → SNAT → партнёр:443. Партнёр whitelist'ит публичный egress IP, не внутренний 10.x.
Partner callback (webhook)Входящий доступ: DNAT публичного URL на LB/backend. Сертификат, mTLS, симметрия маршрута ответа.
Двусторонний обменОба направления: SNAT + DNAT, исходящие и входящие правила firewall, согласованные маршруты

Связка SNAT и whitelist — обязательный абзац в спецификации исходящей интеграции: «наш сервис из подсети 10.0.2.0/24 выходит через NAT как 203.0.113.0/28; партнёр добавляет этот диапазон в ACL». Для webhook — зеркально: «партнёр стучится на https://hooks.our.ru/callback; DNAT → LB 10.0.1.50:443 → backend :8080».

3.2. Диаграмма типового API-вызова

Логический путь (DNS → TCP → TLS → L7) и фильтрация firewall показаны раздельно: клиент не «ходит в firewall» как в отдельный сервис — правила применяются inline на пути пакета.

sequenceDiagram
    participant Client as Клиент
    participant DNS as DNS
    participant LB as L7 LB / API GW
    participant App as Backend (VPC)

    Client->>DNS: A-запрос api.example.com
    DNS-->>Client: IP балансировщика
    Note over Client,LB: TCP :443, TLS handshake<br/>(firewall/SG пропускает inline)
    Client->>LB: HTTPS GET /api/orders
    LB->>App: HTTP :8080 (TLS terminated)
    App-->>LB: 200 OK
    LB-->>Client: HTTPS ответ

Повторные вызовы часто минуют DNS (кэш TTL). Исходящий трафик нашего backend к партнёру идёт через SNAT — партнёр видит публичный IP шлюза, а не адрес pod/VM. Оба нюанса учитывайте при диагностике latency и whitelist.

3.3. Справочник типичных портов

ПортПротоколСервис
22TCPSSH
53TCP/UDPDNS
80TCPHTTP
443TCP (и UDP для QUIC/HTTP/3)HTTPS
5432TCPPostgreSQL
3306TCPMySQL
5672TCPAMQP (RabbitMQ)
9092TCPKafka
9093TCPKafka (TLS)
6379TCPRedis
8080TCPHTTP (часто backend за прокси)

Для Kafka и очередей сетевые параметры — в 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) и 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ). REST — в 10.01.04 Шаблон спецификации REST API. Полный реестр — IANA Service Name and Port Number Registry (см. источники).

3.4. Чек-лист сетевых вопросов при старте интеграции

Каждый отмеченный пункт должен попасть в раздел интерфейса одной-двумя строками — не только в список вопросов на воркшопе.

  • DNS: имя endpoint; тип записи (A/AAAA/CNAME); dual-stack (IPv4/IPv6/both).
  • Порт и протокол: TCP/UDP; нестандартный порт → заявка на firewall; для HTTP/3 — UDP/443.
  • TLS/mTLS: минимальная версия; нужен клиентский сертификат; CA и процесс ротации.
  • NAT: egress IP/CIDR для исходящих; DNAT и публичный URL для webhook.
  • Маршрут: peering/VPN/Internet; default gateway на стенде; asymmetry для callback.
  • Firewall/SG/NACL: матрица источник → назначение → порт → протокол → CIDR; сегмент (DMZ / private).
  • LB/API GW: L4 vs L7; path routing; sticky sessions; TLS termination (где обрывается шифрование).
  • WAF: нужен ли; кто владелец политик; отличие от SG и прикладного rate limit.
  • NFR: RTT, connect/TLS/read timeouts; CDN (edge vs origin).
  • За прокси: X-Forwarded-For / X-Real-IP — если backend использует IP клиента.
  • Диагностика: dig/nslookup; проверка TCP-порта (nc, curl); ping/traceroute только если ICMP разрешён.

Собранные параметры — в раздел «Интерфейсы» (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), 03.01.04 Интерфейсы и интеграционные взаимодействия), NFR — в 10.01.12 Шаблон нефункциональных требований (NFR).

4. Типовые ошибки и ограничения

  • Путать whitelist IP с маршрутом и SNAT. Партнёр добавил IP в ACL, но пакет не доходит — нет маршрута или NAT подставляет другой egress-адрес.
  • Забыть входящий контур для webhook. Открыли исходящий 443, callback не приходит — нет DNAT и правила на LB.
  • Открыли SG, забыли NACL. Stateful SG пропустил запрос, stateless NACL отбросил ответ.
  • Считать ping доказательством недоступности API. ICMP часто закрыт; проверяйте TCP на нужном порту.
  • Ошибка маски CIDR в ACL — /32 vs /24: открыли одну машину вместо подсети или наоборот.
  • Смешать gRPC с «уровнем сеанса OSI». gRPC — прикладной протокол поверх HTTP/2; для сети важны TCP/443 и ALPN на L7, не «уровень 5».
  • L4 LB «пропускает gRPC». TCP доходит, но без HTTP/2-aware L7 маршрутизация не работает.
  • Firewall «только TCP/443» при HTTP/3. QUIC требует UDP/443.
  • Один rate limit на всё. Сетевой лимит на firewall/WAF и лимит RPS в API gateway решают разные задачи.
  • SLA 200 ms при RTT 150 ms между регионами без кэша, CDN или асинхронности.
  • Жёсткий IP вместо DNS — ломает смену балансировщика и ротацию сертификатов.
  • localhost в спецификации для K8s — на стенде работает, в кластере нет (07.08 Контейнеризация и оркестрация (Docker, Kubernetes)).
  • Чек-лист без текста в спецификации — mTLS, DMZ, sticky sessions, X-Forwarded-For должны быть описаны в интерфейсе, а не только в списке вопросов.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

Статьи и документация