Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый вердикт: когда виновата таблица соседей

LLM API может выглядеть «живым»: health-check проходит, GPU загружен, DNS отвечает, а новые запросы с одного узла получают секунды ожидания или No route to host. Если проблемный адрес находится в том же L2-сегменте или next hop не разрешается в MAC, проверьте neighbor table раньше, чем увеличивать таймауты приложения.

Сильный сигнал — сочетание трёх фактов: ip route get выбирает ожидаемый интерфейс и next hop; запись для него застревает в INCOMPLETE либо переходит в FAILED; packet capture видит ARP Request или IPv6 Neighbor Solicitation без корректного ответа. Четвёртый gate — пользовательский: fresh connection к LLM endpoint ломается одновременно с этим состоянием, а здоровый peer в том же тесте отвечает.

Одного списка FAILED недостаточно. В cache остаются адреса выключенных Pod, старых VIP и уже удалённых узлов. Не помогает и механическое увеличение gc_thresh3: если коммутатор режет VLAN, CNI объявляет неверный маршрут или anti-spoofing блокирует ответ, более вместительная таблица лишь хранит проблему дольше.

Эта статья — runbook для Linux-узла на bare metal, VPS или Kubernetes node. Он не заменяет диагностику Service dataplane, conntrack или очереди inference. Для широкого контекста архитектуры полезен материал о Private AI API, а здесь мы сознательно остаёмся на границе IP → link layer.

Путь пакета: четыре evidence gate вместо догадки

Начинайте из effective network namespace. Команда на host может показывать здоровую запись, пока Pod живёт в другом namespace, VRF или overlay. Сначала выясните, откуда реально выходит трафик: hostNetwork, veth Pod, CNI tunnel, egress gateway либо отдельный интерфейс storage/RDMA. Вопрос простой: чей neighbor cache участвует в отправке именно этого пакета?

Gate 1 — маршрут. ip route get с нужным destination и, при необходимости, source показывает выбранные device, gateway и table. Gate 2 — link-layer resolution: ip neigh get и ip -s neigh show dev фиксируют состояние и probes. Gate 3 — фактический peer: capture подтверждает запрос, ответ и MAC. Gate 4 — application outcome: новый TCP-сеанс или gRPC/SSE-запрос должен восстановиться вместе с L2 resolution.

Пример: Pod обращается к inference endpoint 10.40.8.21, но маршрут ведёт через 10.40.8.1. Искать ARP для конечного адреса ошибочно: сосед — gateway. В overlay соседним может быть VTEP, а Pod IP разрешается внутри dataplane CNI. Поэтому сначала маршрут, потом neighbor entry, и только затем вывод.

Такой порядок защищает от ложного совпадения. Рост TTFT может происходить одновременно с STALE, но причина окажется в GPU queue. И наоборот, TCP retransmits будут выглядеть «сетевой задержкой», хотя пакет даже не получил destination MAC.

Состояния NUD: что означают REACHABLE, STALE и FAILED

ip neigh показывает не статичный ARP-кэш, а состояние Neighbor Unreachability Detection. В Linux одинаковая модель используется для IPv4 ARP и IPv6 ND, хотя протоколы разрешения различаются. REACHABLE означает недавнее положительное подтверждение. STALE говорит лишь о том, что подтверждение устарело; запись остаётся пригодной до следующего использования.

При отправке через STALE запись обычно переходит в DELAY, затем при отсутствии upper-layer confirmation — в PROBE. Это нормальная проверка живости. INCOMPLETE принципиально другой: link-layer address ещё не получен, поэтому ядро удерживает ограниченную очередь пакетов на время разрешения. После исчерпания probes Linux показывает FAILED.

RFC 4861 определяет для IPv6 пять основных состояний neighbor cache и подчёркивает роль подтверждения прогресса от верхнего уровня. Практическое следствие: успешные ACK могут поддерживать знание о peer, а отсутствие новых соединений делает старую запись тихой. Документация ip-neighbour(8) отдельно перечисляет состояния, доступные в iproute2.

Не агрегируйте всё в один alarm «не REACHABLE». Для активного LLM gateway короткие STALE → DELAY → REACHABLE безопасны. А серия INCOMPLETE → FAILED для рабочего next hop, совпавшая с ошибками fresh connections, уже достойна page.

Снять baseline: команды, которые сохраняют контекст

Перед изменениями сохраните namespace, время, интерфейс, route decision и полный вывод neighbor table. Снимок только после инцидента слаб: вы не увидите переходов. Лучше выполнить одну и ту же короткую последовательность трижды — до пробы, во время ошибки и после восстановления.

Используйте адрес фактического next hop из первого шага. Ключ -s добавляет статистику, а фильтр по dev не смешивает management, storage и workload networks. В VRF добавьте соответствующий контекст. Для Pod namespace применяйте nsenter или ip netns exec согласно вашей runtime-модели.

date -Is
ip -br link
ip -br address
ip route get 10.40.8.21
ip neigh get 10.40.8.1 dev eth1
ip -s neigh show dev eth1
ip -6 -s neigh show dev eth1

Считайте результат как цепочку, а не как набор строк. Если маршрут неожиданно сменил interface, neighbor table другого device не объясняет сбой. Если ip neigh get здоров, но приложение подключается к иному remote peer через DNS или load balancer, повторите тест с зафиксированным адресом и fresh connection.

Обязательно сохраните negative control: соседний узел или другой peer на том же интерфейсе. Если оба адреса одновременно переходят в FAILED, граница причины ближе к interface, VLAN, switch или CNI. Если ломается один peer, проверяйте его порт, адрес и объявления. Такой контроль полезнее случайного flush всей таблицы.

Packet capture для ARP и IPv6 ND без лишнего шума

Capture отвечает на главный вопрос: запрос не ушёл, ответ не пришёл или ответ пришёл, но был отвергнут/не применён. Для IPv4 наблюдайте ARP Request и Reply. Для IPv6 — ICMPv6 Neighbor Solicitation и Neighbor Advertisement. Снимайте на интерфейсе, который выбрал маршрут; capture на any удобен для ориентира, но скрывает часть link-layer деталей.

sudo tcpdump -ni eth1 -e -vvv 'arp'
sudo tcpdump -ni eth1 -e -vvv 'icmp6 and (ip6[40] == 135 or ip6[40] == 136)'
ip neigh get 10.40.8.1 dev eth1
ping -c 2 -I eth1 10.40.8.1

В IPv6 валидность ND зависит не только от наличия пакета. RFC 4861 требует Hop Limit 255, корректную checksum и допустимые options. Ответ с другого VLAN, неверным target или неожиданным link-layer address не следует трактовать как доказательство здорового пути. Сопоставьте source/destination, target address и MAC с route decision.

В Kubernetes параллельно проверьте host и namespace workload. Модель Kubernetes даёт каждому Pod собственный IP и делегирует реализацию pod network CNI; поэтому место ARP/ND зависит от режима. В routed CNI node может знать маршруты к Pod CIDR и разрешать только соседний node. В L2/bridge-модели количество непосредственно видимых peers бывает заметно больше.

Не очищайте cache перед capture на всех узлах. Массовый flush создаёт всплеск resolution и может усилить инцидент. Для canary допустимо удалить одну динамическую запись конкретного next hop, если подготовлены negative control и rollback, но сначала сохраните исходный вывод.

Кто владеет записью в Kubernetes: host, Pod, CNI или gateway

Kubernetes описывает желаемую связность, но не диктует конкретный dataplane. Pod network реализует CNI, Service traffic может обрабатываться kube-proxy или собственным proxy CNI. Поэтому одинаковый ClusterIP на двух кластерах проходит разные hop’ы: iptables/nftables DNAT, eBPF service map, overlay VTEP, routed Pod CIDR или внешний gateway.

Начните с пары тестов: прямой Pod IP и Service IP, оба на fresh connections. Если Pod IP работает, а Service нет, neighbor table редко будет первым owner; смотрите Service dataplane и endpoint selection. Если оба ломаются только на одном node и route ведёт к одному VTEP или next hop, neighbor resolution становится сильнее кандидатом.

Проверяйте события churn. Быстрое пересоздание Pod само по себе не обязано раздувать L2 cache: всё зависит от того, являются ли Pod IP on-link для узла. В overlay cache может содержать только VTEP peers, а в большой L2-модели — тысячи конечных адресов. Считать «число Pod = число neighbors» нельзя.

Для security boundary полезен отдельный материал о Kubernetes NetworkPolicy для LLM inference. Policy deny и neighbor failure могут выглядеть похоже для приложения, но evidence различается: при policy обычно есть известный peer/MAC и verdict dataplane, а при INCOMPLETE link-layer binding ещё не построен.

Ёмкость neighbor cache: gc_thresh без магических чисел

Linux предоставляет gc_thresh1, gc_thresh2 и gc_thresh3 для управления garbage collection neighbor entries. Актуальная документация ядра описывает их как минимальный уровень хранения, порог более агрессивной очистки и максимум непостоянных записей. Значения по умолчанию зависят от документации/сборки; не переносите число из чужой статьи без чтения sysctl на собственном kernel.

gc_thresh3 стоит повышать только после доказанного capacity pressure: рабочий набор непосредственно подключённых peers легитимен, события показывают отказ выделения новых записей, а GC не успевает при нормальном churn. Сначала измерьте количество записей по family, device и state, затем оцените, почему они возникают. Часто правильное решение — уменьшить L2 failure domain, исправить on-link routes или стабилизировать IP churn.

for family in ipv4 ipv6; do
  echo "== $family =="
  sysctl "net.$family.neigh.default.gc_thresh1"
  sysctl "net.$family.neigh.default.gc_thresh2"
  sysctl "net.$family.neigh.default.gc_thresh3"
  sysctl "net.$family.neigh.default.unres_qlen_bytes"
done

ip neigh show | awk '{print $NF}' | sort | uniq -c
ip -6 neigh show | awk '{print $NF}' | sort | uniq -c

Обратите внимание на unres_qlen_bytes: это лимит байтов пакетов, ожидающих разрешения одного адреса. Старый unres_qlen помечен документацией ядра как deprecated начиная с Linux 3.3. Увеличение очереди не исправляет отсутствующий ARP/NA; оно лишь меняет объём удерживаемых данных и memory envelope.

Для GPU-кластера цена ошибки выше обычной: control request может быть мал, но за ним стоит дорогая capacity. Тем не менее dedicated node или больший VPS не устраняет неверный VLAN, CNI route или switch policy. Инфраструктурный апгрейд обоснован, когда доказан рабочий набор peers, требуется управляемый L2/VRF profile и команда готова владеть kernel, NIC и change window.

Canary A/B/A: менять один owner и проверять приложение

Хороший canary начинается с baseline A. Выберите один node и один проблемный peer, сохраните route, neighbor states, capture и application SLO. Зафиксируйте stop condition: например, рост ошибок новых запросов или распространение INCOMPLETE на healthy peer. Остальные nodes остаются control group.

В фазе B меняйте один owner. Это может быть исправление VLAN на switch port, route в CNI, адреса gateway или один sysctl на canary. Не смешивайте flush cache, перезапуск CNI и изменение порогов: положительный результат станет неинтерпретируемым. После вмешательства повторите тот же destination, source, namespace и fresh-connection probe.

Фаза A после rollback обязательна. Если возврат исходной настройки возвращает ошибку, причинность сильнее. Если эффект сохраняется, вероятно, вы случайно обновили cache, connection pool или соседнее состояние. Подождите согласованное окно и повторите, не подгоняя вывод под желаемый результат.

Application gate должен измерять то, что видел пользователь: успешность новых LLM-запросов, время до первого байта/токена, stream completion и ошибки. Сетевой cache может стать REACHABLE, пока gateway всё ещё ждёт GPU. Протокольное улучшение без application outcome не объявляйте победой.

Типичные ошибки: flush, статические записи и неверный owner

Первая ошибка — ip neigh flush all в разгар инцидента. Команда стирает доказательство и создаёт одновременное разрешение множества адресов. Если нужен эксперимент, ограничьте его одним device и адресом на canary, предварительно сохранив state и capture.

Вторая — постоянная статическая запись как «лечение». Она может временно скрыть потерю ARP/ND, но создаёт риск stale MAC после failover, замены NIC или миграции VIP. Статика уместна только как осознанная часть сетевого дизайна с владельцем lifecycle; для диагностики она плоха, потому что выключает механизм, который вы пытаетесь понять.

Третья — alarm на долю STALE. STALE является нормальным состоянием неактивных соседей. Полезнее следить за скоростью переходов в INCOMPLETE/FAILED для активных next hops, ошибками выделения entries, отсутствием replies и корреляцией с fresh-connection failures.

Четвёртая — покупка более крупного сервера до path proof. Dedicated edge полезен, когда нужны отдельные NIC, предсказуемый L2/VRF, собственный kernel profile и контролируемое окно изменений. Но он не исправит неправильный on-link prefix, конфликт IP, anti-spoofing или политику switch. Commercial decision начинается с ownership, а не с обещания меньшей latency.

Пятая — смешивание CPU network bottleneck с resolution. Если ARP/ND проходит, peer MAC стабилен, но softirq перегружен, используйте runbook по RSS, RPS и IRQ affinity. А для больших списков firewall-адресов отдельно полезны nftables sets.

Decision matrix: ничего не менять, исправить путь или изолировать сеть

Ничего не меняйте, если STALE/PROBE кратковременны, resolution завершается, healthy и problem probes одинаковы, а application SLO не коррелирует с neighbor state. Ищите очередь inference, proxy buffering, DNS selection или CPU path.

Исправьте конкретный путь, если request уходит без reply либо reply приходит на неверном interface/VLAN; route указывает неожиданный next hop; один CNI node объявляет неправильный prefix; IP конфликтует; switch или anti-spoofing отбрасывает ответ. Это конфигурационная причина, и больший cache её не лечит.

Настройте ёмкость, если доказаны легитимный большой working set, pressure GC и отказ новых entries при исправном L2. План включает memory budget, canary, per-family значения, мониторинг churn и симметричный rollback. Порог выбирается из наблюдаемой нагрузки, а не из универсального рецепта.

Изолируйте failure domain, если бизнесу нужен предсказуемый network profile: отдельные NIC/VRF/VLAN, контролируемые версии kernel/CNI, switch telemetry и окно обслуживания. VPS может быть хорош для небольшого egress/gateway, dedicated node — для плотного east-west traffic и владения NIC. Managed network снимает часть операционного долга, но уменьшает доступ к low-level evidence. Выбор делайте после canary.

Вывод: докажите L2-сбой до настройки cache

Таблица соседей — короткий, но критичный участок пути между IP route и реальным кадром в сети. Рабочий runbook держится на четырёх доказательствах: route/namespace, NUD state, ARP или IPv6 ND на проводе и application outcome на новом соединении. Если хотя бы одного звена нет, вывод остаётся гипотезой.

Начните с одного проблемного peer и здорового negative control. Сохраните baseline, сделайте capture, найдите владельца между host, CNI, switch и gateway. Меняйте один параметр на canary и возвращайтесь к baseline после проверки. Так вы отличите нормальный STALE от настоящего FAILED, capacity pressure от неверного L2-пути, а инфраструктурную потребность — от попытки купить выход из конфигурационной ошибки.

Следующий практический шаг прост: добавьте route + neighbor + capture bundle в шаблон инцидента и прогоните его на тестовом узле до следующего page. Если path proof показывает, что команде нужен отдельный контролируемый network profile, сравните VPS, dedicated node и managed edge по ownership, observability и rollback — уже на основании данных.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый вердикт: когда fq_codel действительно помогает

LLM API отвечает быстро на тестовом запросе, но под параллельной выгрузкой модели или большим числом streaming-сессий токены начинают приходить рывками. CPU gateway не упирается в потолок, GPU не заполнен, а медиана выглядит терпимо. Зато p99 RTT и паузы между токенами растут вместе с исходящим трафиком. Это характерный, но ещё не доказанный признак очереди на egress.

Рабочий default: не меняйте qdisc, пока не свяжете четыре факта на одном временном окне: фактический сетевой путь, backlog/drops конкретной qdisc, состояние транспорта и пользовательский outcome. Если backlog не растёт, а задержка уже появилась до первого байта, ищите DNS, TLS, proxy queue или GPU scheduler. fq_codel не лечит чужую очередь.

Когда bottleneck действительно находится на Linux egress, fq_codel полезен двумя свойствами: он разводит flows по очередям и применяет Controlled Delay к каждой из них. Большая передача перестаёт безоговорочно стоять впереди короткого интерактивного потока. Это не обещание «ускорить сеть», а способ ограничить стоячую очередь там, где Linux контролирует dequeue.

В этой статье мы строим проверяемый runbook для Linux gateway перед LLM inference. Он дополняет материалы про TCP buffers и HTTP/2 flow control: socket memory и protocol window находятся на других слоях и требуют собственных доказательств.

Где живёт очередь: application, qdisc, NIC или сеть

Начните с owner map. Исходящий ответ LLM проходит userspace proxy, TCP socket, qdisc, драйвер, TX ring и внешний hop. Backlog может возникнуть в любом из этих мест. Команда tc видит только слой traffic control; пустая qdisc не оправдывает приложение, а заполненная qdisc ещё не доказывает, что именно она портит SLO.

На физическом multiqueue-интерфейсе root часто представлен mq, а рабочие qdisc находятся на leaf очередях. На veth и loopback поведение и defaults отличаются; системный net.core.default_qdisc не гарантирует, что уже существующий интерфейс немедленно получил новый leaf. Поэтому вопрос «какой qdisc включён на сервере» слишком общий. Нужен ответ для конкретного egress device и namespace, через который прошёл проблемный flow.

Представьте gateway с двумя интерфейсами: клиентский трафик выходит через bond, а health checks — через management NIC. Наблюдать qdisc на management-интерфейсе удобно и совершенно бесполезно. Сначала зафиксируйте route decision и фактический peer, затем переходите к очереди. Тот же принцип использован в runbook про policy routing и rp_filter.

ip route get 203.0.113.25
ip -details link show dev eth0
tc -s -d qdisc show dev eth0
tc -s class show dev eth0

Baseline: что снять до первого tc qdisc replace

Надёжный baseline — это не один скриншот счётчиков после инцидента. Запишите состояние до нагрузки, во время воспроизводимого burst и после него. Для qdisc нужны как минимум тип и handle, backlog в байтах и пакетах, drops, overlimits, requeues и расширенные fq_codel counters. Для интерфейса добавьте TX errors/dropped и драйверные статистики. Для транспорта — RTT, retransmissions и pacing/cwnd конкретных соединений.

Снимайте дельты, а не абсолютные значения с момента boot. Миллион drops за полгода ничего не говорит о пяти минутах деградации. Практический вариант: два последовательных snapshot с timestamp и идентификатором canary-нагрузки. Если counters доступны в Prometheus, всё равно сохраните raw вывод: он поможет заметить leaf qdisc, которую агрегированный exporter пропустил.

Application gate должен жить рядом с сетевым. Для streaming LLM полезны TTFT, распределение пауз между событиями SSE/gRPC, доля оборванных ответов после headers и полезный throughput. Не сводите всё к requests per second: очередь может почти не менять RPS, но сделать диалог неприятным из-за длинного хвоста задержки.

Проверьте также ip -s -s link и ethtool -S. Если TX ring или драйвер теряет пакеты, смена AQM может изменить картину, но не устранить аппаратный или CPU bottleneck. Связь IRQ, queue и softirq разобрана отдельно в статье про RSS, RPS и IRQ affinity.

date -Is
tc -s -d qdisc show dev eth0
ip -s -s link show dev eth0
ethtool -S eth0 | sed -n '1,120p'
ss -tin dst 203.0.113.25

Четыре evidence gate: от пути до LLM outcome

Gate 1 — effective path. Подтвердите namespace, route, interface и termination point. Если TLS завершается на внешнем load balancer, qdisc backend-узла не управляет клиентским плечом. Если gateway работает в pod, проверьте host network, veth, CNI и node egress: пакет может пройти несколько qdisc.

Gate 2 — queue state. Под нагрузкой backlog должен расти на том же leaf/root, который обслуживает flow. Для fq_codel смотрите не только общий dropped, но и drop_overlimit, ecn_mark, длины new/old flows и текущую задержку, если она доступна в выводе iproute2. Стоячая очередь — это устойчивое состояние, а не короткий burst, который исчезает без заметного application effect.

Gate 3 — transport. Сопоставьте событие очереди с RTT, retransmissions, pacing и состоянием отправителя. Если sender app_limited, он не заполняет доступный путь; тюнинг qdisc вряд ли даст эффект. Если сегмент — QUIC/UDP или трафик уже сформирован upstream appliance, TCP-only интерпретация тоже неверна.

Gate 4 — application outcome. Повторите одинаковую смесь коротких и длинных ответов. Улучшение qdisc counters без снижения межтокенных пауз, tail latency или ошибок не считается успехом. И наоборот: если приложение ускорилось, но qdisc была пустой, найдите фактическое изменение — возможно, canary отличался CPU placement или connection reuse.

Для каждого gate нужен отрицательный контроль. Например, один idle gateway, один поток через другую NIC либо запрос с отключённой большой фоновой передачей. Контроль делает причинность видимой и защищает от удобной, но ложной истории.

Безопасный canary: меняем одного owner

Лучший canary — отдельный gateway-узел с той же версией kernel, iproute2, proxy и драйвера. Направьте на него небольшую репрезентативную долю новых соединений, сохранив baseline-узел неизменным. Для long-lived streaming connections переключение балансировщика не переместит уже открытые flows, поэтому маркируйте тестовые клиенты или создавайте fresh connections.

Перед заменой сохраните полный вывод tc -s -d qdisc. Команда replace удобна, но она меняет live dataplane: задайте stop condition заранее. Например, rollback при росте application errors, падении полезного throughput или неожиданном росте drops на non-ECN клиентах. Не выбирайте универсальный процент — порог должен следовать из вашего SLO и baseline.

Минимальный тест начинается с defaults fq_codel. По upstream man page defaults включают 1024 flow buckets, target 5 ms, interval 100 ms, packet limit 10240 и memory limit 32 MB; ECN включён. Это стартовая точка, не рекомендация для любого RTT или memory envelope. Особенно осторожно меняйте interval: он должен быть порядка худшего RTT через bottleneck, чтобы endpoints успевали отреагировать.

Параметры и их текущая семантика сверены с upstream tc-fq_codel(8); перед rollout всё равно проверяйте man page из версии iproute2, установленной на вашем узле.

tc -s -d qdisc show dev eth0 > /var/tmp/qdisc.before

tc qdisc replace dev eth0 root fq_codel
sleep 2
tc -s -d qdisc show dev eth0

# Rollback example: replace with the baseline captured for this host.
tc qdisc replace dev eth0 root fq

tc -s -d qdisc show dev eth0 > /var/tmp/qdisc.after-rollback

Как читать backlog, drops, ECN и requeues

В fq_codel drop — часть механизма обратной связи, а не автоматический признак поломки. CoDel отслеживает минимальную задержку пакета в очереди на интервале. Когда стоячая задержка остаётся выше target, AQM начинает сигнализировать congestion: ECN-capable packets можно маркировать, остальные — сбрасывать. Цель не нулевой drop, а короткая очередь при приемлемой утилизации.

drop_overlimit означает достижение packet или memory hard limit; это отличается от управляемых AQM drops. Устойчивый overlimit под рабочей нагрузкой требует проверить capacity и выбранный envelope. Простое увеличение limit может лишь спрятать задержку в более глубоком буфере. Снижение limit без canary, напротив, способно превратить burst tolerance в потери.

new_flow_count, new_flows_len и old_flows_len помогают понять активность scheduler, но их нельзя переводить напрямую в число пользователей. FQ использует stochastic hashing: разные потоки могут попасть в один bucket. При огромном числе flows collision risk растёт, однако увеличение flows расходует память и задаётся при создании qdisc.

Requeues — отдельный сигнал. Они могут появляться между qdisc и драйвером, например при busy TX path. Сопоставьте их с BQL, driver counters, CPU softirq и multiqueue leafs. Называть каждый requeue «packet loss» неверно: пакет мог быть возвращён в очередь и позже успешно отправлен.

ECN и drops: сигнал congestion, а не цель настройки

fq_codel включает ECN по умолчанию, но end-to-end эффект зависит от endpoints и middleboxes. Маркировка CE полезна, только если transport sender действительно получает и обрабатывает сигнал. Поэтому после включения не ограничивайтесь ростом ecn_mark: проверьте реакцию congestion control, RTT и application outcome на новых соединениях.

Параметр ce_threshold предназначен для очень мелких очередей и DCTCP-подобных алгоритмов. В обычной интернет-схеме копировать datacenter threshold рискованно: другой RTT, другая ECN negotiation и неизвестные middleboxes меняют результат. Если функция нужна лишь части трафика, upstream поддерживает selector по ECN/Diffserv byte, но это уже отдельный rollout с классификацией и контролями.

Есть и практическая ловушка: offload меняет вид пакетов в разных точках capture. Большой skb до segmentation не равен гигантскому пакету на wire. Если после qdisc change вы видите странные размеры или checksum errors в локальном tcpdump, сначала проверьте GRO/GSO/TSO. Наш отдельный runbook по Linux network offload показывает, где снимать wire-side доказательство.

Для LLM streaming сравнивайте как минимум два класса: короткие интерактивные ответы и длинные генерации рядом с bulk transfer. fq_codel должен защищать latency-sensitive flows от очереди, но не обязан улучшать GPU compute time. Если TTFT определяется scheduler модели, сетевой AQM не изменит его.

fq_codel, fq или CAKE: выбор по механизму

fq_codel — разумный canary, когда Linux контролирует bottleneck queue, flows конкурируют, а standing delay доказан. Он сочетает flow separation и AQM. При этом он не является полноценным bandwidth shaper: если реальная узкая точка находится дальше и буфер там глубокий, локальная очередь может оставаться пустой.

fq ориентирован на fair queueing и pacing локально сгенерированного traffic. Linux TCP может задавать departure time; для gateway, который в основном терминирует и заново создаёт соединения, это релевантно. Для чисто forwarded traffic socket-aware преимущества слабее, и используется fallback hash. Если симптом — burst локального sender без standing queue, fq может быть более точной гипотезой.

CAKE добавляет integrated shaper, isolation modes, Diffserv и overhead compensation. Он полезен, когда вы должны сформировать скорость немного ниже внешнего bottleneck, например канала с известной полосой. Но это большая operational surface: bandwidth, RTT profile, overhead, NAT awareness и ingress strategy должны соответствовать пути. autorate-ingress не умеет оценивать downstream links за собственной точкой наблюдения.

Default для production gateway остаётся скучным и правильным: не мигрировать без доказанной боли. Если baseline выдерживает SLO, новый qdisc создаёт ownership, persistence и on-call debt без подтверждённой выгоды. Сравнивайте механизмы, а не названия.

Для сравнения возможностей полезны upstream manuals tc-fq(8) и tc-cake(8). Они описывают разные механизмы, поэтому заменять один другим только по популярности неверно.

Когда проблема уже в границе контроля инфраструктуры

Иногда canary показывает реальный network control gap. На shared VM вы не управляете физической NIC, host qdisc, очередями гипервизора или upstream shaping; внутри гостя backlog может быть пустым, пока очередь растёт ниже. Тогда дополнительный sysctl или новый qdisc в guest не дают причинного рычага.

Сравнивайте варианты по ownership. VPS подходит, когда нужен быстрый изолированный gateway и предсказуемый guest baseline, а bottleneck контролируется внутри VM. Выделенный сервер оправдан, если нужны стабильные NIC queues, driver/firmware ownership, NUMA placement и воспроизводимый hardware profile. Managed edge снимает часть эксплуатации, но ограничивает низкоуровневую видимость и свободу эксперимента.

Коммерческий критерий здесь не «железо быстрее». Правильный вопрос: сможете ли вы наблюдать и менять тот слой, где доказана очередь, а затем откатить изменение в согласованное окно? Если проблема вызвана client read rate, proxy buffering, connection churn или GPU queue, новая платформа её не исправит. Сначала устраните disqualifier.

Для проверки гипотезы полезен отдельный canary на инфраструктуре с понятной границей контроля. KingServers может дать VPS или выделенный узел как воспроизводимый baseline, но решение о миграции стоит принимать только после A/B/A evidence bundle, а не по одному удачному графику.

Production rollout: persistence, observability и rollback

Успешный canary ещё не означает, что настройка переживёт reboot, смену interface name или пересоздание network namespace. Зафиксируйте owner конфигурации: systemd-networkd, NetworkManager, netplan, orchestration script или CNI. Не оставляйте одновременно несколько механизмов, которые соревнуются за root qdisc.

На multiqueue NIC проверьте root mq и все leaf queues после применения. Глобальный net.core.default_qdisc подходит для qdisc, не требующих параметров, но физический multiqueue обычно использует default на листьях, а virtual devices могут иметь noqueue. Документируйте фактический результат, а не только желаемый sysctl.

В мониторинг вынесите qdisc backlog/drops/ECN, interface drops, transport RTT/retransmissions и application metrics. Alert по ненулевому drop сам по себе создаст шум. Полезнее корреляция: backlog остаётся высоким несколько интервалов, tail latency растёт, а throughput или completion ухудшается. Так on-call видит механизм и ущерб одновременно.

Rollback должен быть симметричным: вернуть baseline qdisc, повторить ту же нагрузку на fresh connections и снять те же counters. Если эффект не исчез, причинность не подтверждена. Такой A/B/A тест иногда кажется избыточным, но именно он отделяет qdisc от случайного прогрева model cache, смены route или уменьшения фоновой передачи.

Поведение net.core.default_qdisc и исключения для multiqueue/virtual devices описаны в документации Linux kernel.

sysctl net.core.default_qdisc
ip -br link
tc -s -d qdisc show dev eth0

# For a multiqueue root, inspect every reported leaf and compare handles.
tc -j -s qdisc show dev eth0

Короткий incident runbook без магических параметров

Во время инцидента сначала подтвердите пользовательский симптом и ограничьте область: один регион, один gateway, один тип клиента или все flows. Затем найдите effective path проблемного соединения. Снимите qdisc/interface/transport counters в одном окне и сравните с healthy control. Не начинайте с target 1ms, увеличения limit или отключения ECN: без механизма это случайные изменения live dataplane.

Если standing queue доказана, выделите canary и примените defaults fq_codel. Повторите смесь нагрузки. Успех требует одновременно более короткой очереди, приемлемой утилизации и улучшения LLM outcome. Если tail latency снизилась ценой заметного падения полезного throughput, эксперимент не прошёл. Если drops выросли, но RTT и application SLO улучшились, это может быть нормальной работой AQM.

После положительного canary выполните rollback и убедитесь, что симптом возвращается на той же нагрузке. Затем снова примените изменение и расширяйте rollout ступенями. Для каждого шага храните before/after bundle, версию kernel/iproute2, topology и stop condition. При любом расхождении вернитесь к последнему доказанному состоянию.

Наконец, проверьте соседние owners. Queue relief может перенести bottleneck в TLS CPU, upstream proxy, egress link или GPU scheduler. Победа — не исчезновение одного красного графика, а устойчивый application SLO без скрытого ухудшения другого ресурса.

Нагрузочный профиль: как воспроизвести именно свой bufferbloat

Синтетический тест должен создавать ту же конкуренцию, что production, а не просто забивать линк одним потоком. Для LLM gateway соберите смесь: короткие ответы с чувствительным TTFT, длинные streaming responses, периодический bulk transfer артефакта и health traffic. Сохраняйте одинаковые prompt lengths, output limits и connection strategy между baseline и canary. Иначе изменение model workload замаскируется под сетевой эффект.

Разделите pre-first-byte и post-first-byte. Первый интервал включает admission, model scheduling, KV-cache и первый участок транспорта. После первого события измеряйте gaps между чанками. qdisc на egress логичнее связывать с post-first-byte паузами под передачей; рост TTFT без backlog чаще ведёт к другому owner. Это не абсолютное правило, а способ быстрее отсеять слабую гипотезу.

Нагрузка должна продолжаться достаточно долго, чтобы отличить burst от standing queue, но длительность задавайте относительно вашего RTT и рабочего паттерна, а не универсальным числом. Синхронизируйте timestamps gateway, load generator и observability. Затем пометьте фазы warm-up, steady state, overload и recovery: усреднение всех фаз в одну линию уничтожит причинность.

Не забывайте о направлении. Egress qdisc gateway управляет отправкой ответов клиенту, но не очередью входящих requests и не downstream buffer за внешним shaper. Для ingress shaping нужна отдельная схема, часто через IFB или edge-устройство; это уже другой риск и другой rollback. Если узкая точка находится у клиента, серверный fq_codel лишь увидит обратную связь транспорта.

Хороший тест заканчивается recovery-фазой. После снятия bulk traffic backlog должен уйти, RTT вернуться к baseline, а streaming gaps нормализоваться. Если очередь опустела, а приложение всё ещё медленно, bottleneck мигрировал или тест обнаружил второй фактор. Зафиксируйте его, прежде чем расширять rollout.

Частые ошибки, из-за которых canary лжёт

Ошибка 1 — сравнить разные paths. Baseline идёт через один load balancer, canary через другой, но результат приписывают qdisc. Зафиксируйте remote peer, route и termination point для каждого теста. Если путь различается, эксперимент проверяет сразу несколько гипотез.

Ошибка 2 — смешать старые и новые соединения. Long-lived SSE, WebSocket или gRPC stream сохраняет прежний peer и congestion state. После изменения распределения запускайте fresh connections с тем же request mix. Старые соединения можно наблюдать отдельно: их поведение важно для drain, но не подходит для чистого A/B.

Ошибка 3 — смотреть среднее. Bufferbloat проявляется в хвосте и у latency-sensitive flows рядом с bulk transfer. Средний RTT может почти не измениться. Сравнивайте p50, p95 и p99, межтокенные паузы, completion rate и полезный throughput. Один красивый percentile тоже недостаточен: сеть и приложение должны рассказать одну историю.

Ошибка 4 — тюнить target, interval и limit одновременно. Тогда невозможно понять, какой механизм дал эффект. Начните с defaults, меняйте один параметр за шаг и повторяйте rollback. interval связан с худшим RTT bottleneck, limit ограничивает очередь, а target задаёт приемлемую standing delay — это разные рычаги.

Ошибка 5 — принять локальный capture за wire truth. GSO/TSO могут показывать крупные skb до segmentation, а checksum offload — «ошибки», которых нет на wire. Для спорной картины снимите трафик на внешнем TAP/peer или временно спроектируйте canary capture с учётом offload. Не отключайте offload во всём fleet только ради более понятного tcpdump.

Ошибка 6 — забыть про memory envelope. Packet limit и memory limit применяются вместе, причём срабатывает более низкий фактический предел. На gateway с большим числом interfaces и namespaces суммарная память очередей важнее одного значения. Проверьте cgroup/RSS, socket buffers и qdisc memory в одном capacity budget.

Вывод: qdisc меняют после доказательства, а не по привычке

fq_codel полезен, когда Linux действительно владеет узкой egress-очередью, конкурирующие flows мешают друг другу, а standing delay виден одновременно в qdisc, транспорте и LLM streaming. Он не заменяет capacity planning, не исправляет slow consumer и не сокращает GPU compute time.

Начните с owner map и baseline, проведите canary на defaults, читайте drops как сигнал AQM, а не как автоматическую аварию. Сравнивайте fq_codel, fq и CAKE только после определения механизма. И обязательно завершите A/B/A rollback: если возврат baseline не возвращает симптом, история ещё не закончена.

Практический следующий шаг прост: выберите один проблемный gateway, соберите четырёхуровневый evidence bundle и прогоните репрезентативную смесь коротких и длинных flows. Если bottleneck окажется в слое, которым текущая площадка не позволяет управлять, тогда уже имеет смысл обсуждать отдельный VPS, dedicated edge или перенос termination point — с измеримым SLO и планом возврата.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый вердикт: когда RX ring действительно виноват

Увеличивать RX ring имеет смысл только после трёх совпавших сигналов: растёт driver-level счётчик потерь на нужной receive queue, рост совпадает по времени с нагрузочным burst, а приложение видит ошибки, ретрансляции или ухудшение TTFT. Если есть лишь высокий общий RX dropped, это ещё не диагноз. Счётчик мог накапливаться неделями, принадлежать виртуальному интерфейсу или отражать другой уровень стека.

Для LLM API gateway типичный false-green выглядит так: GPU utilization нормален, HTTP health-check зелёный, но новые streaming-соединения периодически начинают ответ с задержкой или обрываются. Команда увеличивает socket buffers, затем net.core.netdev_max_backlog, но пользовательский эффект не меняется. Причина может находиться раньше: аппаратный RX descriptor ring заполняется быстрее, чем драйвер и NAPI успевают его освобождать.

Обратная ситуация встречается не реже. NIC counters стоят на месте, зато одна CPU перегружена NET_RX, растёт time_squeeze, proxy медленно читает сокеты или inference backend держит очередь. Здесь большой ring только добавит глубины и скроет симптом на несколько секунд. Procurement default простой: не меняйте платформу и не заказывайте «NIC помощнее», пока не доказан bottleneck на конкретном hop.

Граница темы важна. Настройку RSS/RPS и IRQ affinity подробно разбирает отдельный runbook KingServers по сетевому CPU, а влияние GRO/GSO/TSO — материал по network offload. Здесь фокус уже: как доказать переполнение RX ring, провести один canary и подтвердить результат через application outcome.

Где находится ring buffer в receive path

Пакет приходит в физическую NIC, карта размещает descriptor в RX ring и через interrupt сообщает драйверу о работе. NAPI poll забирает пакет, создаёт sk_buff и передаёт его выше: в softirq, IP/TCP, socket queue, proxy и наконец в процесс LLM gateway. Потеря на первом участке уже не видна приложению как «переполненный ring»; чаще она проявится таймаутом, TCP retransmission или новым соединением.

Официальная документация Red Hat описывает RX ring как общий круговой буфер NIC и драйвера: он хранит входящие пакеты, пока драйвер не обработает их через SoftIRQ. Это полезная модель, но реальная реализация зависит от драйвера, числа queues и режима устройства. Поэтому слово ring в выводе ethtool -g не следует смешивать с netdev_max_backlog, receive socket buffer или очередью запросов Envoy.

Представьте утренний burst после запуска batch-клиентов. NIC принимает десятки коротких TLS-соединений одновременно. Если CPU освобождает descriptors достаточно быстро, глубина ring почти не важна. Если один IRQ попал на занятый core, очередь заполняется и NIC начинает отбрасывать кадры ещё до TCP. Но если кадры прошли в kernel и застряли у медленного consumer, увеличение RX descriptors не решает причинную цепочку.

Для каждого инцидента рисуйте owner map: физический порт и driver, RX queue и IRQ, CPU/softirq, socket, proxy worker, backend connection и GPU queue. Переходите дальше только после доказательства предыдущего слоя. Такой порядок не самый эффектный, зато он не позволяет одному растущему counter стать универсальным объяснением.

Снимите baseline до любой настройки

Baseline нужен не как архив команд, а как синхронный снимок одной нагрузки. Запишите время в UTC, effective interface, network namespace, driver и firmware, текущие и максимальные ring parameters, channels, coalescing, offload и per-queue counters. Рядом сохраните application metrics: долю 5xx/499, connect errors, retransmissions, TTFT p50/p95/p99 и число активных streaming-соединений.

Не начинайте с фильтра по одному знакомому имени. Вывод ethtool -S driver-specific: у разных карт встречаются rx_missed_errors, rx_no_buffer_count, rx_queue_N_drops, rx_discards_phy и десятки близких полей. Снимите полный вывод дважды через контролируемый интервал, затем считайте delta. Абсолютное число после долгого uptime почти бесполезно.

На хосте с контейнерами сначала найдите реальный datapath. eth0 внутри pod может быть veth, а физическая очередь принадлежит ens5f0 на node. На bond или VLAN проверьте нижележащие устройства. На SR-IOV различайте PF и VF: возможность менять ring у VF и набор доступных counters зависят от драйвера и политики хоста.

DEV=ens5f0
date -u
ip -details link show dev "$DEV"
ethtool -i "$DEV"
ethtool -g "$DEV"
ethtool -l "$DEV"
ethtool -c "$DEV"
ethtool -k "$DEV"
ethtool -S "$DEV"
cat /proc/interrupts
cat /proc/net/softnet_stat

Повторите тот же набор на healthy-узле под сопоставимой нагрузкой. Это negative control: если одинаковый counter растёт и там без ухудшения API, он не объясняет инцидент. Если же рост локален для одной queue и совпадает с application failure, у вас появляется рабочая гипотеза.

Как отличить hardware drop от softirq и socket bottleneck

Первый evidence gate — driver/NIC. Ищите delta по queue-level drop, discard, missed или no_buffer counters и сверяйте семантику с документацией драйвера. На этом уровне важна корреляция с входящим packet rate и распределением по queues. Одна горячая queue при спокойных соседях чаще указывает на hash entropy, RSS indirection или single-flow hotspot, а не на слишком маленький ring всего интерфейса.

Второй gate — softirq/backlog. /proc/net/softnet_stat хранит данные по CPU; поля нужно декодировать с учётом версии ядра, а не читать как одну глобальную строку. Рост dropped или time_squeeze вместе с высокой %soft означает, что давление уже находится в software receive path. Тогда проверяйте IRQ placement, NAPI budget и backlog. Увеличение hardware ring может дать запас, но владелец ограничения останется CPU path.

Третий gate — socket/application. Если NIC и softirq стабильны, смотрите ss -tinm, proxy buffering, event-loop delay, worker saturation и backend queue. Особенно коварны длинные SSE-потоки: быстрый приём запроса не гарантирует быстрое чтение ответа клиентом. Для этого слоя полезен отдельный runbook по TCP buffers и backpressure.

Пример: у gateway растёт p99 TTFT, но driver drops равны нулю. softnet_stat показывает time_squeeze на CPU 14, где одновременно сидит IRQ горячей RX queue и TLS worker. Ring не виноват напрямую. Сначала разнесите ownership и повторите fresh-connection probe; только затем проверяйте глубину descriptors.

Свяжите RX queue, IRQ, softirq и NUMA

RX ring существует не в вакууме: каждая hardware queue обслуживается драйвером и обычно имеет связанный MSI-X interrupt. Linux kernel documentation рекомендует распределять receive interrupts между CPU и учитывать memory domain. Если queues меньше, чем cores, RPS может распределить дальнейшую обработку; если RSS уже даёт очередь на каждый нужный CPU, лишний RPS способен добавить IPI без пользы.

Сначала посмотрите ethtool -l, затем найдите IRQ нужного интерфейса в /proc/interrupts. Сравните configured и effective affinity. На системах с irqbalance ручная mask может быть изменена после старта сервиса или hotplug. На bare metal дополнительно сопоставьте PCI device с NUMA node и placement proxy workers. Удалённый memory access сам по себе не доказывает drop, но вместе с горячим core и queue imbalance делает гипотезу сильнее.

DEV=ens5f0
ethtool -l "$DEV"
ethtool -x "$DEV"
grep -i "$DEV" /proc/interrupts
for q in /sys/class/net/"$DEV"/queues/rx-*; do
  printf '%s rps=%s\n' "$q" "$(cat "$q/rps_cpus")"
done
devpath=$(readlink -f /sys/class/net/"$DEV"/device)
cat "$devpath/numa_node"
mpstat -P ALL 1

Проверяйте эффект на новых соединениях. Existing keepalive и streaming sessions сохраняют прежний flow-to-queue mapping, поэтому мгновенное сравнение после изменения RSS может ложно показать «ничего не изменилось». Контрольный запрос должен открыть fresh TCP/TLS connection, пройти тем же маршрутом и получить содержательный ответ inference, а не только HTTP 200 от health endpoint.

Если после выравнивания queue/IRQ исчезли driver drops, не увеличивайте ring «для надёжности». Вы уже нашли owner. И наоборот, если locality здорова, CPU имеет запас, но bursts всё равно переполняют ring, canary большей глубины становится обоснованным.

Ring size и interrupt coalescing: меняйте по одному

ethtool -g DEV показывает current и pre-set maximums, а ethtool -G DEV rx N меняет число RX ring entries, если драйвер поддерживает операцию. Максимум — ограничение устройства, а не рекомендация. Больше descriptors дают запас на burst, но требуют памяти и могут увеличить время ожидания пакета в очереди. Для latency-sensitive LLM API важен не только throughput: следите за TTFT и tail latency.

Interrupt coalescing — соседний, но отдельный рычаг. Он определяет, как долго или сколько пакетов NIC ждёт перед interrupt. Более агрессивная агрегация снижает interrupt rate и CPU cost, но может увеличить latency; слишком частые interrupts перегружают CPU. Net DIM умеет динамически менять moderation по bandwidth, packets и events, причём алгоритм отдаёт приоритет bandwidth. Это значит, что автоматический профиль не обязан оптимизировать именно ваш p99 TTFT.

Нельзя одновременно увеличить ring, изменить rx-usecs, число channels и IRQ affinity: положительный результат станет неразбираемым, а откат — рискованным. Начните с одного изменения на одном узле. Если гипотеза про короткий burst, увеличьте RX ring на один разумный шаг между current и maximum, сохранив coalescing. Если bottleneck постоянный и CPU горячий, сначала чините queue distribution.

DEV=ens5f0

# Сохраните фактический baseline из ethtool -g.
ethtool -g "$DEV"
ethtool -c "$DEV"

# Пример canary; значение выбирают из current/max и возможностей драйвера.
sudo ethtool -G "$DEV" rx 1024

# После теста верните исходное значение, например 512.
sudo ethtool -G "$DEV" rx 512
ethtool -g "$DEV"

Числа в примере не являются универсальным tuning profile. На вашей NIC current и maximum могут отличаться, а изменение способно кратко прервать связь. Официальный RHEL guide прямо предупреждает о возможном interruption при смене ring parameters. Поэтому выполняйте операцию через out-of-band доступ или на узле, который можно убрать из балансировки.

Проведите A/B/A canary с application outcome

Хороший canary отвечает не на вопрос «уменьшился ли counter», а на вопрос «исчез ли пользовательский симптом из-за этого изменения». Возьмите два одинаковых gateway: A остаётся baseline, B получает новый RX ring. Подайте сопоставимый traffic mix, включая короткие запросы, новые TLS handshakes и длинные streaming responses. Снимайте deltas counters, CPU/softirq, retransmissions, TTFT и error rate в одном временном окне.

Stop condition задают до запуска. Например: немедленный rollback при росте p99 TTFT, сбросе link, driver reset, новых errors или миграции bottleneck в socket/application queue. Не продолжайте тест только потому, что driver drops стали ниже: глубокая очередь может скрыть потери ценой задержки. Для LLM API это особенно неприятно, потому что пользователь воспринимает паузу до первого токена как отказ.

После положительного B верните старое значение A на том же узле и повторите workload. Если drops и application failure возвращаются, причинность становится намного убедительнее. Затем снова включите B и проверьте воспроизводимость. Этот A/B/A цикл защищает от случайного совпадения с уменьшившимся трафиком, прогревом caches или сменой backend pool.

Сохраните evidence bundle: timestamps, kernel и driver versions, interface/PCI identity, до/после ethtool -g/-c/-S, IRQ map, softnet deltas и application graphs. Такой пакет полезнее скриншота «ошибки пропали»: по нему другой инженер сможет повторить эксперимент или оспорить вывод.

Сделайте настройку постоянной и не потеряйте rollback

ethtool -G меняет runtime state. После reboot, driver reload, смены kernel, пересоздания VM или обновления firmware значение может вернуться к default. Способ persistence зависит от дистрибутива и владельца сети. В NetworkManager современные профили поддерживают ethtool ring properties; в RHEL официальный пример использует nmcli connection modify PROFILE ethtool.ring-rx N. В других системах применяют systemd unit или сетевой orchestrator, но он должен выполняться после появления интерфейса.

Не переносите значение между разными моделями NIC как «корпоративный стандарт». Устройства отличаются maximums, размером descriptors, количеством queues и driver behavior. Политика должна задавать условие и проверку: применить значение только к конкретным driver/device IDs, затем прочитать фактический state и поднять alert при несовпадении.

В Kubernetes node — такой же хост. DaemonSet с привилегиями может настроить NIC, но увеличивает blast radius и часто скрывает ownership. Для managed cluster часть physical settings недоступна; на SR-IOV поведение PF/VF разделено. Сначала договоритесь, кто отвечает за host networking, maintenance window и возврат node в pool. Не используйте pod lifecycle как механизм случайного изменения физической карты.

PROFILE="gateway-uplink"
DEV=ens5f0

nmcli connection modify "$PROFILE" ethtool.ring-rx 1024
nmcli connection up "$PROFILE"

# Проверка фактически применённого state
ethtool -g "$DEV"

Rollback тоже должен быть persistent. Запишите исходное значение в change record и подготовьте обратную команду для того же механизма. Если canary требует ручного доступа после link flap, считайте это частью риска до rollout, а не неприятной деталью после него.

Когда проблема действительно требует другой платформы

Инфраструктурный upgrade оправдан, когда вы доказали control gap: текущая платформа не даёт нужных NIC queues, driver/firmware ownership, NUMA placement, telemetry или безопасного change window. В таком случае dedicated server может быть ценнее не «большей скоростью», а предсказуемым physical path и правом управлять параметрами. Для виртуального gateway важны гарантии провайдера по vNIC, CPU scheduling и наблюдаемости host-level drops.

Однако новое железо не исправляет poor RSS entropy, single-flow hotspot, неверную IRQ affinity, proxy buffering, retry storm или GPU queue. Если на wire и NIC всё чисто, коммерческий bridge нужно остановить: покупка ресурса без доказанного owner только переносит инцидент. По той же причине не смешивайте эту тему с защитой handshake path; для SYN backlog и cookies есть отдельный SYN runbook.

При сравнении VPS, dedicated и managed edge задайте пять вопросов: кто владеет NIC и firmware, кто видит per-queue counters, можно ли закреплять CPU/NUMA, как проходит maintenance, и насколько быстро выполняется rollback. Эти ответы формируют operational cost. «До 40 Гбит/с» без queue telemetry и воспроизводимого baseline не является доказательством пригодности для вашего LLM gateway.

Для KingServers-проекта разумный следующий шаг — принести evidence bundle, traffic profile и требуемую границу контроля. Тогда инфраструктуру можно сопоставить с нагрузкой предметно: оставить gateway на VPS, вынести network edge на dedicated node или разделить proxy и GPU inference по failure domains.

Короткий runbook инцидента с RX drops

Сначала зафиксируйте пользовательский симптом и временное окно. Затем определите effective interface и снимите deltas driver counters. Если они не растут, не трогайте ring: переходите к softirq, socket и application. Если растут, сопоставьте конкретную queue с IRQ и CPU, проверьте RSS distribution и healthy control.

Когда queue/CPU path здоров, сравните current и maximum ring. Подготовьте canary на одном выведенном из общего пула узле, меняйте только RX ring и возвращайте трафик постепенно. Оценивайте одновременно driver drops, softnet_stat, CPU, retransmissions, TTFT и ошибки gateway. Положительный результат обязан пережить A/B/A.

Если improvement есть только в counter, но приложение не меняется, откатите настройку и продолжайте поиск. Если улучшились и low-level state, и fresh-connection outcome, закрепите значение через host network management, задокументируйте device/driver boundary и добавьте drift check. Наконец, проверьте, не мигрировал ли bottleneck в TLS, proxy, backend connection pool или GPU scheduler.

Не используйте production traffic как единственный генератор истины. Сохраните небольшой воспроизводимый workload с тем же packet/connection shape. Throughput-only тест крупными потоками может не воспроизвести burst из коротких запросов, который и заполняет RX descriptors.

Вывод: ring buffer лечит доказанный burst, а не любой timeout

RX ring — нижний и очень конкретный слой receive path. Он становится виновником только тогда, когда per-queue driver counters, queue/IRQ evidence и application outcome складываются в одну временную цепочку. Без этой цепочки увеличение descriptors превращается в удобный ритуал: потери могут временно скрыться, а latency и operational debt вырастут.

Практический порядок короткий: снимите baseline, найдите owner, выровняйте queue-to-CPU path, измените один параметр на одном узле, выполните A/B/A и закрепите только воспроизводимый результат. Сохраните rollback рядом с persistence-конфигурацией. Для следующего maintenance window начните с десятиминутного сбора deltas — он часто экономит часы слепого tuning.

Если evidence показывает, что вам не хватает контроля над физической NIC, queues или NUMA, обсуждайте платформу через эти требования. Если же bottleneck находится в proxy или GPU queue, оставьте ring в покое и чините реального владельца. Так сеть перестаёт быть общим подозреваемым и становится измеряемой частью inference path.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Почему retransmission превращается в длинный хвост latency

Симптом обычно выглядит обманчиво: средняя задержка LLM API остаётся нормальной, CPU на gateway не упирается в потолок, GPU занят полезной работой, но отдельные ответы внезапно получают паузу перед первым или последним токеном. В логах приложения это часто выглядит как «медленный backend». На проводе же может оказаться потерян последний TCP-сегмент, которому не хватает последующих пакетов для классических трёх duplicate ACK.

Для интерактивного request/response-трафика это особенно болезненно. Потеря внутри большого полёта данных быстрее даёт SACK-обратную связь, а потеря в хвосте маленького ответа может ждать таймер. Поэтому полезно смотреть не на общий процент retransmissions, а на связь конкретного recovery episode с TTFB, межтокенной паузой и завершением ответа. Один всплеск counter без временной привязки не объясняет p99.

RFC 8985 описывает RACK-TLP как time-based loss detection: RACK использует время передачи и ACK/SACK более новых данных, а Tail Loss Probe пытается получить ACK до дорогого RTO. Это не «ускоритель сети» и не замена congestion control. Механизм лишь раньше собирает доказательство потери там, где счётчика duplicate ACK недостаточно.

Практический вопрос: видите ли вы один и тот же скачок p99 одновременно в socket state и в пользовательском outcome? Если нет, не тюнингуйте kernel вслепую. Пауза может жить в proxy buffering, HTTP/2 flow control или очереди inference. Для первого соседнего слоя полезен отдельный разбор HTTP/2 flow control в LLM streaming.

Полезный способ не потерять контекст — завести единый incident timeline. Отмечайте начало и конец запроса, идентификатор gateway, peer tuple, момент первого байта, последний token и socket cookie. Рядом кладите интервалы capture и snapshots. Тогда команда приложений не спорит с сетью о разных минутах и разных соединениях. Для LLM streaming это критично: короткая пауза перед первым токеном, разрыв в середине генерации и задержка финального chunk имеют разные владельцы. Первая может быть связана с очередью scheduler, вторая — с downstream flow control, третья — с tail loss. Один агрегированный p99 смешивает эти истории и толкает к неверному fix.

RACK, TLP и RTO: три разных события

RACK отвечает на вопрос: какой ранее отправленный сегмент уже достаточно стар, если более новый сегмент подтверждён? Он работает во временной области, поэтому полезен для application-limited traffic, reordering и потерянных retransmission. Соединение должно использовать SACK, а отправитель хранит время последней передачи сегмента или TSO-агрегата.

TLP решает соседнюю задачу. Когда ACK-обратная связь иссякла у хвоста полёта, отправитель посылает один probe: новые данные, если они доступны, либо повтор последнего сегмента. Успешный probe вызывает ACK, после чего RACK может отметить ранние неполученные данные потерянными. Если probe тоже пропал, остаётся RTO. Именно поэтому TLP нельзя трактовать как бесконечный retry loop.

RTO остаётся консервативным fallback. Он нужен, когда ACK clock фактически потерян. Рост RTO или backoff говорит, что восстановление дошло до дорогого пути, но не объясняет, где потерялись пакет или ACK. Один и тот же результат возможен при policer на forward path, перегруженном reverse path, зависшем peer и firewall state.

Не смешивайте loss detection и congestion control. RFC прямо разводит эти роли: RACK определяет потерю, а retransmit допускает congestion control. Поэтому включённый RACK не означает, что CUBIC, BBR или PRR перестают управлять окном. Сначала зафиксируйте механизм, затем outcome. Иначе красивое снижение RTO episodes может скрыть рост очереди на следующем hop.

План доказательств: socket, ACK, path, application

Рабочий runbook начинается не с sysctl, а с owner map. Кто принимает клиентский TCP: cloud load balancer, dedicated edge, ingress controller или сам inference server? Где завершается TLS? Есть ли второй TCP hop между proxy и backend? Без этой карты легко смотреть не тот сокет и связывать клиентскую паузу с backend-соединением, которое в этот момент здорово.

Разделите расследование на четыре gate. Первый — per-socket state: RTT, rttvar, RTO, backoff, unacked, retrans и cwnd. Второй — ACK/SACK evidence в capture: какие sequence ranges дошли, есть ли DSACK, когда появился probe. Третий — path: NIC queues, qdisc, policer, ECMP, bonding и reverse route. Четвёртый — application outcome: TTFB, token cadence, завершение ответа и освобождение backend slot.

На каждом gate нужен healthy negative control. Возьмите соединение к тому же endpoint через другой gateway или тот же gateway к стабильному backend. Сравнивайте дельты за одинаковое окно, а не абсолютные counters с момента boot. Десять тысяч retransmissions на давно живущем узле могут быть нормальнее, чем пять новых retransmissions за одну проблемную секунду.

Связка должна быть причинной: loss evidence появляется на конкретном сокете, capture показывает соответствующий gap, а свежий запрос получает паузу в тот же момент. Если совпадает лишь один слой, диагноз преждевременный. Такая дисциплина защищает и от бессмысленной смены сервера, и от рискованного глобального sysctl.

Сразу договоритесь и о stop condition расследования. Если повторяемый socket gap не найден после нескольких проблемных запросов, не расширяйте tcpdump бесконечно: переходите к proxy и application evidence. Если capture доказывает loss до ingress, не меняйте backend. Если loss виден только после gateway, не обвиняйте клиентский ISP. Такая «граница достаточности» экономит время и уменьшает риск того, что несколько команд одновременно изменят разные слои. В отчёте оставляйте не только положительные находки, но и negative controls: они показывают, какие гипотезы уже исключены, и не дают следующей смене начать с нуля.

Снимаем baseline Linux без изменения параметров

Начните с чтения текущих значений. В актуальной документации Linux IP sysctl net.ipv4.tcp_recovery — bitmap; значение по умолчанию 0x1 включает RACK. Там же отмечено, что сброс бита 0x1 сейчас не меняет поведение, потому что RACK является единственным поддерживаемым loss detection algorithm. Бит 0x2 делает reordering window статическим, а 0x4 отключает DUPACK threshold heuristic. Это экспериментальные рычаги, а не чек-лист «включить всё».

net.ipv4.tcp_early_retrans управляет TLP: значения 3 или 4 включают его, и документация подчёркивает зависимость от RACK. tcp_sack обычно включён. tcp_reordering задаёт начальный уровень, а tcp_max_reordering — верхнюю границу динамической адаптации. На ECMP или bonding rr reordering может быть реальным свойством пути, поэтому статическое уменьшение окна способно превратить поздние пакеты в ложные потери.

Для сокета используйте ss -tinmo: -i показывает внутреннюю TCP-информацию, -o — активный timer, -m — память. По man page ss, timer on может означать retransmission, early retransmit или TLP; значит, одно слово не идентифицирует механизм. Читайте его рядом с RTO, backoff, RTT и retrans.

Полезно сопоставить baseline с материалом про TCP buffers и backpressure: большой send buffer и retransmission — разные факты. Если userspace продолжает писать, а peer медленно читает, вы можете увидеть задержку без сетевой потери.

uname -r
sysctl net.ipv4.tcp_recovery
sysctl net.ipv4.tcp_early_retrans
sysctl net.ipv4.tcp_sack
sysctl net.ipv4.tcp_reordering
sysctl net.ipv4.tcp_max_reordering
ss -tinmo dst 203.0.113.20:443

Как читать ACK, SACK и таймеры вместе

Один snapshot ss почти всегда недостаточен. Снимите серию с известным интервалом и параллельно запустите capture на owner hop. Ищите не retransmission вообще, а последовательность: исходный segment, более поздний SACK или отсутствие ACK, probe, retransmit, затем application progress. В проде capture ограничивают host, port и временем; payload для TLS всё равно зашифрован, но sequence/ACK timing остаётся полезным.

RACK делает вывод по времени последней передачи. Если сегмент, отправленный позже, подтверждён, более ранний неполученный сегмент может быть признан потерянным после reordering window. Это лучше работает с маленькими flights, но требует осторожности при reordering. DSACK особенно ценен: он может показать, что оригинал и retransmission оба достигли peer, то есть «потеря» могла быть ложной или ACK задержался.

Смотрите на reverse path отдельно. Клиент получил данные, но его ACK задержался из-за перегруженного uplink; отправитель видит неполученные подтверждения и запускает recovery. Capture только на sender оставит двусмысленность. Два capture по сторонам подозрительного hop превращают догадку в доказательство: пакет вышел, вошёл или исчез между точками.

Не забывайте об offload. GRO/GSO/TSO меняют вид пакетов на host capture, но не отменяют wire behavior. Подробная граница описана в статье про GRO, GSO и TSO. Снимок до NIC и зеркалирование на switch могут показывать разную сегментацию — это ожидаемо, а не автоматический признак corruption.

peer=203.0.113.20
port=443
for i in 1 2 3 4 5; do
  date --iso-8601=ns
  ss -tinmo dst "$peer:$port"
  sleep 1
done
timeout 30 tcpdump -ni any "host $peer and tcp port $port" -w rack-canary.pcap

Отличаем настоящую потерю от reordering и delayed ACK

Потеря и reordering дают похожий промежуточный кадр: более новый sequence range уже подтверждён, ранний ещё нет. Разница раскрывается позже. При reordering оригинальный сегмент может прийти без retransmit; при spurious retransmission DSACK сообщит о дубликате. Поэтому verdict нельзя выносить по одному SACK block.

Типичная причина reordering — per-packet load balancing или bonding round-robin. ECMP по стабильному flow hash обычно сохраняет порядок внутри одного 5-tuple, но смена пути, асимметрия или нестабильная entropy всё равно могут проявиться. Проверьте, совпадают ли проблемные соединения с конкретным next hop, NIC queue или tunnel. Сравните проблемный flow со здоровым flow на том же узле.

Delayed ACK тоже усложняет TLP recovery detection. RFC 8985 отдельно отмечает, что sender должен дать receiver достаточно времени перед probe, а ACK loss без DSACK делает алгоритм консервативным. Практически это означает: не называйте probe «лишним» только потому, что оба data packet видны на receiver. Проверьте, когда ACK вышел и когда дошёл.

Для контролируемой лаборатории допустим tc netem, но только в отдельном namespace или тестовом gateway. Не ставьте loss/reorder на production root qdisc. Сценарий должен воспроизводить один механизм: сначала loss, затем reordering, затем clean control. Иначе вы не узнаете, какое условие изменило outcome.

# LAB ONLY: use an isolated test interface
tc qdisc replace dev veth-test root netem loss 0.5%
# run fixed requests and save ss, capture, application timings
tc qdisc replace dev veth-test root netem delay 10ms reorder 10% 50%
# restore clean control
tc qdisc del dev veth-test root

Что можно менять, а что лучше оставить в покое

Без доказанного дефекта лучший default — не менять tcp_recovery. Современный Linux уже использует RACK, а TLP включён стандартным режимом tcp_early_retrans. Переключение bitmap на всём fleet создаёт новую переменную и может изменить реакцию на reordering, не устранив policer или потерю ACK.

Статический reordering window нужен только для хорошо понятного пути. На динамическом WAN или фабрике со сменой маршрутов адаптация полезнее. Отключение DUPACK heuristic также должно быть гипотезой canary, а не «рекомендованным ускорением». Документация называет эти возможности experimental; фиксируйте версию ядра, потому что детали реализации и counters меняются.

Не используйте tcp_retries2 как регулятор p99. Он управляет долгим abort behavior живого соединения при RTO retransmissions; снижение может быстрее рвать пользовательские ответы, но не ускоряет loss detection. Для half-open semantics существует per-socket TCP_USER_TIMEOUT, и у нас есть отдельный production-runbook по TCP_USER_TIMEOUT.

Ещё одна ловушка — одновременно менять qdisc, congestion control, RACK bits и proxy timeouts. Даже улучшение ничего не докажет. Один canary, один owner, один параметр. В change record сохраняйте исходное значение, kernel version, socket evidence и критерий rollback. Так следующий инженер сможет повторить наблюдение, а не верить устному «стало быстрее».

Версионная проверка обязательна ещё по одной причине: sysctl описывает глобальный default, но конкретное приложение может задавать socket options, а container может работать в другом network namespace. Читайте значение там, где живёт сокет, и проверяйте, унаследовал ли listener нужные настройки для новых соединений. Изменение host namespace не гарантирует эффект для уже открытого connection. Поэтому любой canary должен пересоздать соединение и записать kernel release, namespace inode и PID владельца. Иначе вы можете получить «нулевой эффект» просто потому, что тестировали старый socket, а затем ошибочно решить, что RACK или TLP не работает.

A/B/A canary: проверяем recovery, а не надежду

Хороший canary начинается с A: baseline на одном gateway и параллельный healthy control на другом. Используйте свежие соединения, иначе connection pooling сохранит прежние route, congestion window и socket options. Запишите распределения TTFB, межтокенных пауз и completion rate, а рядом — дельты retrans, DSACK, RTO/backoff и path counters.

На фазе B меняйте ровно одного owner. Например, закрепите трафик на одном ECMP path или примените проверяемый kernel knob только к canary-узлу. Stop condition задаётся заранее: рост completion errors, RTO episodes, CPU softirq, backend occupancy или ухудшение control. Без stop condition эксперимент легко продолжается потому, что «нужно ещё данных».

Фаза A после rollback обязательна. Верните исходное состояние и повторите те же probes на новых соединениях. Если эффект исчез вместе с изменением и вернулся после повторного B в отдельном окне, причинная связь становится сильнее. Если p99 остался лучше после rollback, возможно, вы поймали смену нагрузки или прогрев cache.

Проверяйте, куда мигрировал bottleneck. Более быстрое TCP recovery может освободить клиентский stream, но увеличить burst на proxy, TLS CPU или GPU queue. Успех — это application outcome и освобождение capacity, а не только меньшее число RTO. Именно поэтому rollback повторяет те же четыре evidence gate.

before=$(sysctl -n net.ipv4.tcp_recovery)
printf '%s
' "$before" > /var/tmp/tcp_recovery.before
# apply one reviewed canary value here, then open fresh connections
sysctl -w "net.ipv4.tcp_recovery=$(cat /var/tmp/tcp_recovery.before)"
# repeat the same ss, capture and application probes

Когда проблема действительно упирается в инфраструктуру

Смена VPS или переход на dedicated server оправданы после доказанного control gap. Примеры: вы не управляете NIC queues и driver version, noisy neighbor создаёт повторяемые jitter/loss на host boundary, NUMA placement не контролируется, у платформы нет нужной path telemetry, а rollback зависит от чужого окна. Тогда более предсказуемый kernel/NIC baseline имеет коммерческую и техническую ценность.

Но новое железо не исправит poor flow hash, внешний policer, асимметричный route, proxy buffering или очередь на GPU. Это обязательный disqualifier. Перенос такого workload просто воспроизведёт симптом на более дорогой машине, а расследование начнётся заново уже с новым набором переменных.

Сравнивайте варианты по ownership, а не по абстрактной «мощности». На VPS проще масштабировать edge horizontally и изолировать canary, но меньше контроля над physical NIC. Dedicated даёт предсказуемые queues, IRQ/NUMA placement и change window, зато требует своей операционной дисциплины. Managed load balancer снимает часть L4 ownership, но ограничивает доступ к per-socket и wire evidence.

Для соседнего слоя пригодится runbook по RSS, RPS и IRQ affinity. Если retransmissions коррелируют с RX drops и softirq saturation на одной очереди, это уже не абстрактная «сеть медленная», а проверяемый resource/control gap. Именно после такого доказательства стоит обсуждать класс инфраструктуры King Servers.

До закупки сформулируйте проверяемое требование. Не «нужна сеть быстрее», а, например, доступ к per-queue NIC counters, возможность закрепить IRQ и workload в одном NUMA node, контролируемая версия driver/firmware, packet mirror на edge и независимое окно rollback. Затем сопоставьте эти требования с VPS, dedicated или managed L4. Если текущая платформа уже даёт нужные controls, миграция не является первым шагом. Если не даёт, evidence bundle становится техническим обоснованием выбора, а не эмоциональной реакцией на p99. Это также помогает King Servers подобрать конфигурацию по ownership и failure domain, а не только по числу ядер.

Короткий runbook и вывод

Перед закрытием инцидента сохраните минимальный пакет артефактов: версии kernel и iproute2, исходные sysctl, две стороны capture, socket cookie, route/namespace context, application trace и результат rollback. Не обязательно хранить полный payload; достаточно метаданных, которые позволяют связать sequence timing с запросом. Добавьте короткий verdict в форме «наблюдение → исключённые причины → подтверждённый owner → изменение → повторная проверка». Такой формат переживает смену дежурной команды и подходит для следующего похожего эпизода. Через неделю повторите контрольный запрос без искусственной нагрузки: конфигурация могла сохраниться, а path — измениться. Если результат не воспроизводится, пометьте вывод как ограниченный конкретным маршрутом и окном, а не как универсальный tuning recipe.

Сначала подтвердите симптом на fresh connection и отметьте точный owner TCP hop. Затем снимите два и более ss -tinmo snapshot, packet capture по обе стороны подозрительного участка и application timings. Разведите RACK evidence, TLP probe и RTO fallback; не называйте общий retrans counter причиной.

Следом проверьте альтернативы: reordering, delayed или потерянный ACK, offload-границу, policer, proxy buffering, HTTP/2 flow control и GPU queue. Для каждого подозрения используйте healthy negative control. Если сеть чистая, честный вывод «не network loss» полезнее красивого sysctl.

Менять настройки можно только после evidence gate. Один canary owner, один параметр, заранее заданные stop conditions, затем симметричный A/B/A rollback. Kernel documentation показывает, что RACK и TLP обычно уже активны; поэтому задача инженера чаще состоит не во «включении RACK», а в доказательстве того, какой recovery path случился и помог ли он пользователю.

Главная мысль проста: tail latency — это цепочка, а не один counter. Свяжите сокет, ACK/SACK, фактический путь и результат приложения. После этого станет понятно, нужен ли route fix, proxy change, kernel canary или инфраструктура с более жёстким NIC/NUMA ownership. Начните с короткого evidence bundle на одном проблемном соединении — он быстро отделит потерю пакета от удобной, но дорогой догадки.

И ещё одно практическое правило: не переносите лабораторные проценты loss или reordering в production SLO. Они нужны для воспроизводимости механизма, а не для прогноза реальной сети. Production verdict строится только на фактических дельтах вашего пути, вашего kernel и вашего LLM workload.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый verdict: flowtable нужен не каждому gateway

Короткий ответ: включать nftables flowtable имеет смысл только на Linux-хосте, который действительно маршрутизирует заметный объём TCP или UDP между интерфейсами и тратит измеримый CPU на classic forwarding path. Если TLS завершается на этом же хосте, запрос попадает в локальный Envoy или Nginx, а затем уходит к GPU через другой сокет, offload не обойдёт userspace и не сократит время генерации модели. Он ускоряет конкретный L3/L4 hop, а не весь LLM request.

Типичный false green выглядит убедительно: после изменения загрузка одного ядра падает, а команда conntrack -L показывает [OFFLOAD]. Но p95 time-to-first-token остаётся прежним, streaming продолжает замирать, а очередь inference растёт. В таком случае сетевой fast path сработал технически, однако пользовательская проблема жила в TLS, buffering, retry storm или GPU scheduler. Для production это не успех, а перенос внимания.

Начинайте с procurement default: не меняйте платформу и не включайте hardware offload, пока не доказан bottleneck на routed path. Shared VM, VPS и dedicated gateway различаются контролем NIC, kernel, driver и change window, но ни один вариант не исправит неверный route, MTU black hole или медленного клиента. Если вы ещё не локализовали сетевой CPU, сначала полезнее пройти runbook по RSS, RPS и IRQ affinity.

Как flowtable меняет путь пакета

По официальной документации Linux kernel первый пакет успешно проходит обычный IP forwarding path. Правило flow add может добавить двунаправленный поток в flowtable, и последующие совпавшие пакеты уходят из ingress сразу к выходному netdevice через neigh_xmit(). Они обходят prerouting, routing decision, forward и postrouting hooks, расположенные после ingress. Именно поэтому счётчики в поздних nftables chains перестают расти: это ожидаемый эффект fast path, а не потеря трафика.

Lookup строится не только по адресам и портам. В tuple входят L2 encapsulation, L3 source/destination, L4 source/destination ports, protocol и input interface. Последний элемент важен при нескольких conntrack zones: одинаковый 5-tuple, пришедший с другого входа, не обязан разделять запись. Flowtable также кэширует выходной интерфейс и gateway address, уменьшает TTL/hop limit и хранит применённую NAT-конфигурацию.

Здесь полезна простая аналогия: classic path похож на паспортный контроль для каждого прохода, а flowtable — на временный пропуск, выданный после первой полной проверки. Пропуск действует только для уже квалифицированного маршрутизируемого потока. Новый SYN, flowtable miss, исключение протокола или изменившаяся топология возвращают пакет к обычной процедуре. Проверяли ли вы, что ваш «gateway» не является на самом деле локальным reverse proxy? Это первая граница применимости.

Сначала зафиксируйте effective path и baseline

Диагностику начинайте из того network namespace, где пакет фактически входит. На bare metal это часто root namespace, в Kubernetes или контейнерном gateway — уже не обязательно. Запишите ingress/egress interfaces, route для реального source, policy rules, соседей и место NAT. Не подменяйте доказательство схемой из CMDB: после CNI, VRF, tunnel или policy routing реальный path часто отличается от нарисованного.

Baseline должен соединять четыре уровня. Первый — path: ip route get, ip rule, namespace и интерфейсы. Второй — state: conntrack entry, NAT и будущий OFFLOAD tag. Третий — resource: per-CPU softirq, throughput, drops и нагрузка gateway process. Четвёртый — application outcome: time-to-first-token, inter-token gaps, ошибки и доля оборванных stream на новых соединениях. Абсолютный счётчик без delta и healthy control ничего не доказывает.

Снимите два профиля: обычный LLM streaming request и отрицательный контроль, который заведомо не должен попасть в выбранный fast path, например локально завершающееся health-соединение. Если обе метрики меняются одинаково, вероятен соседний фактор: warm cache, batching, смена backend или фоновой нагрузки. Для проверки offload на соседнем уровне пригодится отдельный материал про GRO, GSO и TSO: не смешивайте segmentation offload с Netfilter flowtable.

ip -br link
ip rule show
ip route get 203.0.113.20 from 10.20.0.15
nft -a list ruleset
conntrack -S
cat /proc/softirqs
ss -tin state established

Безопасная конфигурация software flowtable

Минимальный ruleset состоит из flowtable на ingress hook и строго квалифицированного flow add в forward chain. Не переносите в fast path весь TCP только потому, что пример в документации короткий. Ограничьте canary адресами gateway, backend subnet, портом и состоянием conntrack. Так вы сможете связать каждое изменение со своим владельцем и не спрячете от поздних hooks трафик, который должен логироваться, маркироваться или проходить дополнительную policy.

Приоритет ingress hook задаёт порядок с другими ingress chains. Документация ядра рекомендует располагать flowtable раньше nftables ingress chain, если оба существуют. Но это решение нельзя принимать вслепую: если ingress policy должна отбросить spoofed source до любого ускорения, порядок является частью security design. Проверьте загружаемый файл через nft --check -f, сохраните текущий ruleset и применяйте изменение атомарно.

Ниже — учебный каркас, а не готовая policy для копирования. Интерфейсы, сети и ownership NAT у вас будут другими. Для dual-stack используйте family inet, но отдельно подтвердите IPv4 и IPv6 outcome. Версия nftables на дату подготовки — 1.1.7 по официальным release notes Netfilter; доступность синтаксиса и поведения всё равно проверяйте по версии userspace и kernel конкретного хоста.

table inet llm_fastpath {
  flowtable ft_llm {
    hook ingress priority 0;
    devices = { eno1, eno2 };
    counter
  }

  chain forward {
    type filter hook forward priority filter; policy drop;

    ct state established,related
      ip saddr 10.20.0.0/24 ip daddr 10.30.0.0/24
      tcp dport 443 flow add @ft_llm

    ct state established,related accept
  }
}

Как доказать, что offload работает и приносит пользу

Первое доказательство — не падение CPU, а совпадение реального потока с policy. Создайте новое соединение после применения ruleset, найдите обе стороны tuple в conntrack и проверьте tag [OFFLOAD]. Для hardware path ожидается отдельный [HW_OFFLOAD]; эти статусы нельзя смешивать. Hardware programming выполняется асинхронной workqueue, поэтому первые пакеты могут некоторое время идти software path.

Второе доказательство — характер счётчиков. Пакеты, попавшие в fast path, не доходят до позднего counter в forward chain, однако flowtable counter при поддерживаемом kernel может синхронизировать packets/bytes с conntrack entry. Если вы видите рост обычного forward counter на каждом пакете, проверьте направление, interfaces, state и исключения. Если counter внезапно замолчал без OFFLOAD tag, ищите другую chain, drop или ошибку наблюдения.

Третье доказательство — resource delta на том же трафике: снижение softirq/forwarding CPU или рост headroom без новых drops. Четвёртое — application outcome на fresh connections. Для LLM API нас интересует не только request rate, но и TTFT, gaps внутри SSE-stream, reset rate и освобождение CPU для TLS/proxy. Результат считается причинным только после возврата к baseline: уберите flow add, повторите тот же probe и потребуйте возврата метрики. Это контрфактический A/B/A gate.

nft list flowtables
nft list flowtable inet llm_fastpath ft_llm
conntrack -L -p tcp | grep -E '\[OFFLOAD\]|\[HW_OFFLOAD\]'
nstat -az
mpstat -P ALL 1
curl --no-keepalive -sS -N https://api.example.net/v1/stream >/dev/null

Исключения fast path: NAT, MTU, fragments и закрытие TCP

Flowtable не означает, что NAT исчезает. Запись сохраняет NAT-конфигурацию, определённую первым проходом через classic path, и применяет её к последующим пакетам. Это удобно, но усиливает требования к ownership: изменение DNAT/SNAT policy в середине жизни потока не обязано немедленно переписать уже кэшированное решение. Для canary создавайте fresh connections и заранее решите, как вы будете дренировать старые.

Фрагментированный трафик возвращается в обычный forwarding path, потому что без transport header lookup может быть невозможен. Пакет, превышающий MTU, тоже идёт classic path, чтобы ядро отправило ICMP Packet Too Big. TCP FIN и RST проходят обычный путь для корректного завершения flow. Поэтому смешанный trace — часть нормальной работы. Ошибка начинается тогда, когда fallback совпадает с деградацией и вы не можете объяснить его долю.

Особое внимание уделите tunnels и PMTUD. Если streaming «подвисает» только на определённом размере ответа, не лечите это flowtable. Сначала проверьте effective MTU, ICMP delivery и retransmission. Та же дисциплина применима к асимметрии: reply должен попадать в согласованный conntrack/path. Материал про ip rule, rp_filter и fwmark помогает отделить routing control gap от offload.

A/B/A rollout без потери наблюдаемости

Canary должен менять одного owner. Выберите один gateway, одну пару интерфейсов и ограниченный набор backend addresses. До изменения сохраните ruleset, метрики и несколько pcap с внешней точки. Host-side capture после ingress не является полным wire evidence: flowtable hit обходит последующие hooks, а segmentation offload может менять вид пакета на самом хосте. SPAN-порт или соседний sensor помогает увидеть реальный wire.

Фаза A — baseline без flow add. Фаза B — тот же workload с software flowtable. Фаза A2 — удаление только canary rule и повтор на новых соединениях. Положительный результат требует симметрии: OFFLOAD появляется в B, resource/application metric улучшается в B и возвращается примерно к исходному поведению в A2. Не фиксируйте универсальный процент: он зависит от packet rate, CPU, NIC, ruleset и доли локально завершаемого трафика.

Rollback должен быть скучным. Заранее подготовьте файл, который атомарно удаляет canary rule или flowtable, проверьте его через nft --check и назовите stop conditions: рост resets, недоступность отдельной сети, потеря telemetry, расхождение NAT или отсутствие application gain. После rollback повторите path, conntrack, counter и LLM probes. Иначе «мы вернули конфиг» остаётся предположением.

delete table inet llm_fastpath

Software и hardware offload: где проходит граница инфраструктуры

Software flowtable оставляет forwarding в ядре и обычно является первым разумным canary: меньше зависимостей от конкретной NIC, driver и firmware, проще rollback. Hardware offload добавляет flags offload и переносит поддерживаемые flows в устройство. По документации ядра несколько первых пакетов всё равно могут пройти software path, пока workqueue программирует hardware. Поддержка зависит от устройства и driver; наличие синтаксиса не гарантирует реальный HW datapath.

Есть и cache risk. Flowtable хранит destination MAC и egress netdevice; при изменении topology запись может устареть. Документация отдельно отмечает риск для software режима при сочетании bridge и IP forwarding, а также для hardware offload. В HA-схеме проверьте failover neighbor, bond/team, bridge ports и смену next hop. Если после failover трафик продолжает идти к старому MAC, скорость уже не имеет значения.

Коммерческая граница появляется после доказанного control gap. VPS подходит, когда нужен изолированный kernel baseline и управляемый ruleset без владения NIC firmware. Dedicated gateway оправдан, если нужны стабильные queues, NUMA locality, driver/firmware ownership, внешний capture и предсказуемое change window. SmartNIC/DPU имеет смысл только при подтверждённом packet-processing hotspot и компетенции сопровождать offload. Новое железо не исправляет неверный selector, ECMP reordering, proxy buffering или очередь GPU.

При выборе инфраструктуры сравнивайте не обещание «меньше latency», а четыре вещи: кто владеет kernel/NIC версиями, какие counters доступны, каков failure domain и насколько быстро выполняется rollback. Для смежной проверки сетевых очередей используйте ethtool-runbook по NIC ring buffers и RX drops; flowtable не компенсирует переполненный RX ring.

Частые ошибки диагностики

Ошибка 1: считать OFFLOAD доказательством пользовательского эффекта. Tag доказывает datapath state, но не улучшение TTFT или streaming. Всегда соединяйте его с resource delta и LLM outcome. Ошибка 2: тестировать reused connection. Старый keepalive мог быть создан до policy change; для каждого этапа открывайте fresh connection.

Ошибка 3: путать локальный proxy с forwarded gateway. Если socket принадлежит Envoy/Nginx на том же хосте, этот сегмент проходит input/userspace/output, а не простой forward bypass. Ошибка 4: ждать роста поздних nft counters. При flowtable hit их молчание ожидаемо. Перенесите наблюдение к ingress, conntrack/flowtable counters и внешнему capture.

Ошибка 5: включать всё сразу. Одновременная смена flowtable, IRQ affinity, GRO, qdisc и proxy timeout делает результат неразрешимым. Меняйте одного owner. Ошибка 6: игнорировать exceptions. Fragments, MTU, FIN/RST и misses возвращаются в classic path; mixed trace не равен поломке.

Ошибка 7: переходить к hardware до software proof. Так вы добавляете driver, firmware и asynchronous programming к ещё не доказанной гипотезе. Ошибка 8: покупать dedicated gateway раньше evidence. Выделенная инфраструктура даёт контроль, но не превращает неподходящий workload в подходящий. Если bottleneck живёт в TLS storm, начните с отдельного runbook по handshake, resumption и keepalive.

Production-чеклист владельца gateway

Перед change window назначьте владельцев: network path, nftables policy, NAT, observability и LLM application metric. Один человек не должен молча владеть всеми допущениями. Согласуйте точный canary scope, fresh-connection generator, healthy negative control и stop conditions. Запишите kernel, nftables, NIC driver и firmware versions, но не превращайте список версий в доказательство совместимости — её даёт только ваш canary.

• Path подтверждён из effective namespace для обоих направлений.
• Flowtable devices совпадают с реальными ingress/egress netdevices.
• Canary policy ограничена адресами, портом и conntrack state.
• Baseline включает CPU/softirq, drops, conntrack и application outcome.
• OFFLOAD и при необходимости HW_OFFLOAD проверяются отдельно.
• Fragments, MTU, FIN/RST и failover topology входят в negative tests.
• Rollback проверен синтаксически и операционно.
• После B выполняется A2 с теми же probes.

Затем спросите неприятное, но полезное: что произойдёт, если ускорение освободит CPU gateway, а предел мигрирует в TLS, proxy worker, storage или GPU queue? План наблюдения должен продолжаться за границей fast path. Хороший runbook заканчивается не зелёным counter, а объяснимым поведением всей цепочки запроса.

Вывод: ускоряйте доказанный hop, а не архитектуру на глаз

nftables flowtable — зрелый механизм fast path для маршрутизируемых TCP/UDP flows, но его область уже, чем звучит слово «ускорение». Первый пакет проходит classic path, policy явно отбирает кандидатов, последующие hits обходят поздние Netfilter hooks, а NAT state сохраняется. Exceptions закономерно возвращаются в обычную обработку. Поэтому production-диагностика должна связывать path, OFFLOAD state, CPU/queue delta и результат LLM API.

Начните с software canary и A/B/A rollback. Hardware offload и выделенный gateway рассматривайте только после доказанного packet-processing hotspot и понятной границы контроля. Если application metric не двигается, остановитесь: новое железо не исправит TLS, buffering, retry storm или GPU queue. Зато при подтверждённом forwarding bottleneck предсказуемый kernel/NIC baseline, наблюдаемость и change window действительно становятся ценностью инфраструктуры.

Практический следующий шаг прост: возьмите один gateway, соберите baseline по чеклисту, ограничьте canary одним flow и проверьте его на fresh connections. Сохраните evidence bundle и выполните rollback даже при хорошем результате. Так вы получите не красивый tag, а воспроизводимое решение, которое можно безопасно расширять или обсудить с командой KingServers при выборе VPS либо выделенного сетевого узла.

Токены внезапно перестают идти, хотя TLS жив, TCP не теряет пакеты, а GPU ещё не упёрся в потолок. Через несколько секунд ответ догоняет клиента пачкой, и средняя latency маскирует неприятную межтокеновую паузу. Часто виноват не сокет и не модель, а исчерпанный credit HTTP/2 на одном из двух независимых участков вокруг API gateway. Разберём, как доказать эту гипотезу кадрами WINDOW_UPDATE, метриками Envoy и A/B/A canary, не превращая увеличение окон в бесконтрольный расход памяти.

Симптом: токены идут рывками, но TCP выглядит здоровым

Типичный инцидент начинается неприятно буднично: TLS установлен, retransmits не растут, GPU не загружен до предела, а потоковый ответ LLM на несколько секунд замирает между токенами. Затем данные приходят пачкой, и средняя latency в дашборде выглядит терпимо. Пользователь, однако, видит не среднее, а паузу. Если команда сразу увеличивает TCP buffers или число GPU, она меняет не тот слой.

HTTP/2 добавляет поверх TCP собственный credit-based flow control. Отправитель может передавать DATA, только пока у него есть кредит одновременно в окне конкретного stream и в окне connection. Кредит возвращает получатель кадрами WINDOW_UPDATE по мере потребления данных. Поэтому здоровый socket не гарантирует, что HTTP/2 sender сейчас имеет право отправить следующий фрагмент ответа.

Граница этой статьи узкая: мы диагностируем паузы в LLM streaming на пути клиент → Envoy → inference и доказываем, где исчерпан credit. Это не продолжение общего разбора TCP autotuning и не статья о graceful drain. Материал про то, как отделить медленного consumer, окно stream, окно connection, buffering посредника и реальную очередь модели.

Быстрый disqualifier: если inference backend не создаёт токены или очередь scheduler растёт до первого токена, настройка HTTP/2-окон не поможет. Сначала докажите наличие DATA на upstream hop. Только после этого есть смысл трогать flow control.

Для соседних уровней используйте отдельные runbook: TCP buffers и socket backpressure, HTTP/2 GOAWAY и gRPC keepalive, TLS handshake storm и HTTP/3 для AI API. Они помогают проверить смежные гипотезы, не смешивая их с credit HTTP/2.

Почему flow control нужно разбирать hop-by-hop

По RFC 9113 flow control специфичен для одного HTTP/2 connection, направлен и управляется получателем. Посредник не пересылает WINDOW_UPDATE сквозь себя. Envoy принимает downstream DATA в роли одного endpoint и отправляет upstream DATA уже по другому connection в роли другого endpoint.

Это меняет ход расследования. Представьте, что inference быстро отдаёт токены Envoy, а мобильный клиент читает редко. Upstream window может оставаться открытым, пока downstream sender упирается в кредит клиента и memory watermark шлюза. Обратная картина тоже возможна: клиент готов читать, но upstream connection застопорен приложением, которое не освобождает receive buffer.

У каждого направления два лимита: stream window и connection window. Первый локализует давление конкретного RPC, второй делится между всеми потоками одного соединения. Когда один большой ответ перестал получать stream credit, соседние stream теоретически могут продолжить. Когда исчерпан connection credit, остановка заметна шире. На практике сюда добавляются scheduling, user-space buffers и event loop, поэтому один снимок окна ещё не доказывает причину.

RFC задаёт начальное значение 65 535 октетов для новых stream и connection до последующих SETTINGS/WINDOW_UPDATE, но реализации вправе рекламировать другие значения. В актуальной документации Envoy v3 параметры initial_stream_window_size и initial_connection_window_size настраиваются отдельно для downstream и upstream. Сверяйте синтаксис с установленной версией: latest-документация может описывать более новый релиз.

Собираем evidence bundle до изменения конфигурации

Начните с одной canary-сессии и сохраните идентичность пути: клиентский IP, gateway pod или процесс, upstream endpoint, connection ID и stream ID. Без этой связки легко сравнить WINDOW_UPDATE одного соединения с TTFT другого. Для long-lived stream особенно важно создавать fresh connection: reuse скрывает SETTINGS и переносит накопленное состояние.

Сначала подтвердите negotiated protocol и время появления первых байтов. curl удобен для SSE или совместимого HTTP API; для gRPC используйте клиент, который показывает transport events, либо grpcurl для функциональной проверки. Команда ниже не доказывает flow-control stall сама по себе, но фиксирует ALPN, headers и application timeline.

curl -sv --http2 --no-keepalive \
  -H 'content-type: application/json' \
  --data @request.json \
  https://canary.example/v1/chat/completions \
  -o /tmp/stream.out 2>/tmp/curl.trace

date -Ins
wc -c /tmp/stream.out
sed -n '1,120p' /tmp/curl.trace

Затем снимите pcap одновременно на downstream и upstream интерфейсах шлюза. TLS требует session keys или capture на доверенной точке до шифрования; без расшифровки вы увидите TCP timing, но не типы HTTP/2 frames. На тестовом стенде h2c или debug build упрощает анализ, однако не переносите небезопасный режим в production.

sudo tcpdump -i eth0 -s 0 -w /tmp/downstream.pcap 'host 198.51.100.24'
sudo tcpdump -i eth1 -s 0 -w /tmp/upstream.pcap 'host 10.42.7.19'

tshark -r /tmp/downstream.pcap -Y 'http2.type == 0 || http2.type == 8'
tshark -r /tmp/upstream.pcap   -Y 'http2.type == 0 || http2.type == 8'

Ищите последовательность DATA → исчерпание доступного credit → пауза → WINDOW_UPDATE → возобновление DATA. Сопоставляйте её не со средней throughput, а с межтокеновой паузой конкретного запроса. Если пауза в приложении начинается раньше протокольной остановки, окно лишь отражает медленное чтение выше по стеку.

Четыре gate: frame, proxy, consumer и application

Расследование удобно вести четырьмя доказательствами. Frame gate отвечает на вопрос, действительно ли sender исчерпал stream или connection credit. Нужны DATA и WINDOW_UPDATE на одном connection, правильное направление и общий timeline. Само наличие WINDOW_UPDATE нормально: это механизм работы протокола, а не ошибка.

Proxy gate проверяет, где Envoy приостановил чтение и выросли ли буферы. В статистике Envoy полезны counters семейства downstream_flow_control_paused_reading_total, upstream_flow_control_paused_reading_total и upstream_flow_control_backed_up_total, если они доступны в вашей версии и конфигурации. Снимайте дельту на canary, а не абсолютное значение после месяцев работы.

Consumer gate доказывает, что получатель действительно читает stream. В gRPC запись сообщения означает передачу framework, а не гарантированную отправку по сети; официальное руководство gRPC по flow control отдельно предупреждает о взаимной блокировке при ручном управлении, если обе стороны много пишут и не читают. Для SSE проверьте, не буферизует ли клиентский SDK, reverse proxy или UI-слой.

Application gate связывает транспорт с результатом: TTFT, распределение межтокеновых пауз, число завершённых stream, время освобождения inference slot и доля отменённых запросов. Положительный frame gate без изменения этих метрик доказывает механизм, но не бизнес-эффект.

Настройка Envoy: меняем одно окно и считаем память

В Envoy downstream и upstream HTTP/2 options принадлежат разным объектам конфигурации. Это полезно: можно изменить receive window только на проблемном hop. Одновременно это ловушка: правка upstream параметра не исправит клиента, который перестал читать downstream response.

Ниже показан фрагмент v3 API для upstream cluster. Он демонстрирует структуру, а не универсальные числа. Актуальная документация Envoy указывает допустимый диапазон до 2³¹−1 и предупреждает, что window связан с buffering. Перед rollout проверьте config dump и документацию именно вашей версии; legacy поле http2_protocol_options на уровне cluster заменяется typed extension options.

typed_extension_protocol_options:
  envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
    "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
    explicit_http_config:
      http2_protocol_options:
        initial_stream_window_size: 1048576
        initial_connection_window_size: 4194304

Не копируйте эти значения как «оптимальные». Оцените верхнюю границу памяти: число активных connections × connection budget плюс число активных streams × stream budget, затем добавьте реальные L7 buffers, фильтры, TLS и allocator overhead. Window не всегда равен фактически выделенной памяти байт в байт, но рост лимитов расширяет возможный memory envelope и blast radius.

Канареечная правка должна иметь владельца, лимит RSS и stop condition. Например: откатить профиль, если RSS растёт без улучшения p95 межтокеновой паузы, увеличиваются resets или gateway начинает задерживать соседние короткие запросы. Это важнее красивого графика throughput на одном stream.

A/B/A canary: доказываем причинность, а не совпадение

Baseline A собирайте на неизменной конфигурации с двумя классами трафика: обычным быстрым consumer и контролируемо медленным. Фиксируйте advertised SETTINGS, частоту и размер WINDOW_UPDATE, paused-reading counters, RSS, CPU event loop, TTFT и межтокеновые паузы. Медленный consumer нужен как отрицательный контроль: увеличение окна способно только отложить его backpressure, а не устранить.

В фазе B меняйте один owner. Если гипотеза про upstream stream window, не трогайте одновременно connection window, число connections, TCP rmem и worker count. Иначе вы не поймёте, что сработало. Нагрузочный профиль, model revision, prompt и sampling parameters должны оставаться одинаковыми.

После положительного результата верните baseline A. Если протокольная пауза и application metric воспроизводимо возвращаются, причинность стала заметно сильнее. Если эффект остался после rollback, вероятно, изменилась нагрузка, прогрелся cache, мигрировал endpoint или рассосалась GPU queue.

Отдельно проверьте новые и существующие connections. SETTINGS_INITIAL_WINDOW_SIZE влияет на новые stream и может скорректировать активные stream, а connection-level credit меняется WINDOW_UPDATE. Поэтому часть клиентов продолжит жить со старым negotiated state до переподключения. Rollout-план должен явно сказать, нужен ли drain, и не смешивать его с аварийным reset.

Медленный consumer: окно покупает время за память

Большое окно не делает медленного клиента быстрым. Оно позволяет sender дольше передавать данные до остановки и перемещает очередь между слоями. Для короткого burst это может сгладить паузу. Для клиента, который стабильно потребляет медленнее генерации, накопление продолжится, пока не сработает watermark, лимит буфера, timeout или cancellation.

Здесь полезно рассуждать через конечный budget. Допустим, у вас тысячи долгих LLM stream, часть проходит через мобильные сети. Даже умеренный per-stream запас, умноженный на concurrency, превращается в заметный memory envelope. Добавьте connection window: слишком маленький способен связать судьбу соседних stream, слишком большой ослабляет ранний сигнал перегрузки.

Проверяйте три режима отдельно: быстрый consumer, consumer с ограниченной скоростью чтения и consumer, который перестал читать совсем. В третьем случае корректный outcome часто не «дождаться когда-нибудь», а отменить stream, освободить backend capacity и записать понятную причину. Иначе gateway удерживает память, а inference продолжает работу, результат которой никто не забирает.

Если приложение использует gRPC manual flow control, согласуйте read/write loop. Официальная документация gRPC подчёркивает, что framework может приостановить write и что обе стороны должны продолжать чтение. В SSE проверьте flush на backend и фильтры посредника: application buffering может выглядеть как transport stall, хотя credit ещё доступен.

Что обычно принимают за HTTP/2 flow-control stall

Первая ложная причина — TCP backpressure. HTTP/2 работает поверх TCP, поэтому loss, congestion window, zero window на сокете и медленный receiver остаются значимыми. Сопоставьте ss -tinm, retransmits и pcap с HTTP/2 frames. Если sender имеет HTTP/2 credit, но socket write не продвигается, увеличение protocol window не лечит transport path.

Вторая — L7 buffering. Некоторые filters требуют тело целиком или имеют собственные лимиты. Envoy flow-control FAQ прямо разделяет listener, cluster и HTTP/2 stream limits и отмечает, что non-streaming filters меняют поведение больших body. Проверьте transcoder, buffer filter, ext_authz body capture и пользовательские extensions.

Третья — concurrency queue. Один HTTP/2 connection имеет negotiated предел одновременных streams. В gRPC performance guidance отмечено, что новые RPC могут ждать, когда лимит достигнут; для long-lived streaming это особенно заметно. Такая очередь возникает до отправки DATA и не равна исчерпанию flow-control window.

curl -fsS http://127.0.0.1:9901/stats?filter=flow_control
curl -fsS http://127.0.0.1:9901/stats?filter='upstream_rq_(pending|active|tx_reset|rx_reset)'
curl -fsS http://127.0.0.1:9901/config_dump > /tmp/envoy-config-dump.json
sha256sum /tmp/envoy-config-dump.json

Четвёртая — сама модель. Если upstream не отправляет DATA, смотрите scheduler delay, prefill, KV-cache pressure, batch composition и cancellation. Бывает и смешанный случай: медленный downstream клиент удерживает stream, cancellation не доходит до inference, и GPU продолжает ненужную генерацию. Тогда лечить нужно propagation отмены и ownership capacity, а не только окно.

VPS, dedicated edge или managed gateway: решение после path proof

Покупать новую платформу до доказательства hop — плохой procurement default. Если причина в клиентском SDK, фильтре buffering или GPU queue, более мощный сервер лишь сделает ошибку дороже. Сначала покажите, что canary окна меняет application metric и что эффект возвращается после rollback.

VPS подходит, когда нужен изолированный gateway с умеренным трафиком, а команда контролирует Envoy config, telemetry и rollout. Проверьте, насколько предсказуемы CPU scheduling, memory guarantee и network path. Для flow-control расследования важна не вывеска виртуализации, а возможность получить стабильный baseline и повторить тест.

Dedicated edge становится оправданным, когда доказан CPU/NIC/memory control gap: нужна фиксированная NUMA-топология, управляемые NIC queues, большой предсказуемый memory envelope или отдельный failure domain. Ценность здесь — ownership версии, kernel, окна изменений и rollback, а не обещание универсально меньшей latency.

Managed gateway снимает часть on-call и lifecycle работы, но может скрывать negotiated SETTINGS, connection pooling и внутренние buffers. Перед выбором спросите, доступны ли per-hop metrics, packet evidence, config versioning и контролируемый canary. Если ответов нет, сервис может быть удобным, но диагностическая граница останется у провайдера.

KingServers уместен в этой схеме после доказанного resource/control gap: можно вынести gateway на VPS или выделенный сервер, отделить его failure domain от inference и зафиксировать воспроизводимый профиль. Но новое железо не исправит медленный consumer, неверный L7 filter или очередь модели.

Production-runbook: от алерта до безопасного rollback

Шаг первый — квалифицировать симптом. Разделите TTFT и межтокеновую паузу, отметьте client class, connection reuse и backend endpoint. Сохраните healthy negative control: короткий unary или streaming request через тот же gateway, который не воспроизводит паузу.

Шаг второй — построить owner map. Для каждого hop запишите sender, receiver, stream ID, advertised window, кто читает данные и кто может изменить конфигурацию. Снимите frame trace и Envoy counters в одном временном окне. Не делайте вывод по старому pcap и текущему дашборду.

Шаг третий — локализовать gate. Flow-control гипотеза требует трёх совпадений: credit достигает нуля, DATA прекращается на том же hop, после WINDOW_UPDATE DATA возобновляется. Затем нужен четвёртый элемент — совпадение с пользовательской паузой. Без него это нормальная работа механизма.

Шаг четвёртый — провести B-canary одним параметром и с конечным memory budget. Stop condition должен быть автоматизируемым: рост RSS, resets, downstream errors или деградация соседнего класса запросов. Если окно помогает только синтетическому stream, а production distribution не меняется, rollout не обоснован.

Шаг пятый — вернуть A и повторить те же probes. Симметричный rollback важен не меньше rollout: fresh connection, те же prompt и consumer profile, те же counters и application metrics. После подтверждения документируйте effective config и version lock, иначе следующий deploy незаметно вернёт старые окна.

Наконец, проверьте миграцию bottleneck. Убрав flow-control stall, можно открыть следующий предел: TCP, event loop, TLS, L7 filter, GPU scheduler или storage. Успешный тюнинг — это не «все графики зелёные», а объяснимая причинная цепочка от frame до результата пользователя.

Вывод: увеличивайте окно только после доказательства

HTTP/2 flow control защищает получателя и разделяет ресурсы между stream, но на LLM streaming он способен проявиться как длинная пауза между токенами. Ключ к диагностике — не размер окна сам по себе, а четыре связанных доказательства: кадры на конкретном hop, состояние gateway, поведение consumer и application outcome.

Начните с fresh-connection baseline, снимите downstream и upstream отдельно, проведите A/B/A canary и посчитайте конечный memory envelope. Увеличение окна допустимо, когда оно воспроизводимо убирает протокольную остановку и улучшает пользовательскую метрику без роста resets и давления на память. Во всех остальных случаях ищите владельца в TCP, фильтрах, concurrency queue или inference.

Практический следующий шаг прост: возьмите один проблемный stream, соберите evidence bundle по runbook и докажите место остановки до следующего change window. Если path proof укажет на нехватку управляемого CPU, NIC или memory budget, тогда уже имеет смысл переносить gateway на отдельный VPS или dedicated edge и закреплять воспроизводимый baseline.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый вывод: большой buffer не равен быстрому streaming

У TCP-буферов простая задача: сгладить разницу между скоростью сети и темпом, с которым приложение читает или пишет данные. У LLM API эта разница особенно заметна. Запрос может быть коротким, а ответ живёт десятки секунд; токены идут маленькими порциями, клиент читает их неравномерно, gateway параллельно обслуживает тысячи таких потоков. Поэтому один и тот же симптом — пауза в выдаче — появляется и при тесном receive window, и при медленном клиенте, и при остановившемся event loop.

Главное правило: не начинайте с увеличения tcp_rmem и tcp_wmem. Сначала докажите, что ограничение находится в socket memory и влияет на пользовательский outcome: time to first token, межтокенные паузы, долю оборванных streams или успешное завершение ответа. Если сокет свободен, а очередь inference растёт, новый sysctl только увеличит доступный запас памяти.

Практический default — сохранить autotuning, собрать данные на конкретных соединениях и изменить один слой на canary. Ручной размер полезен лишь после локализации владельца. Для gateway на VPS или выделенном сервере коммерческая ценность железа начинается не с «больше RAM», а с воспроизводимого kernel/NIC baseline, контролируемого лимита соединений и понятного rollback.

Как данные проходят через rmem, приложение и wmem

Входящий пакет сначала проходит NIC и сетевой стек, затем полезные данные оказываются в receive buffer сокета. Пока приложение не вызвало чтение, память остаётся занятой, а TCP регулирует advertised window. На исходящем направлении приложение записывает данные в socket; часть ещё ждёт передачи или подтверждения peer. Это не единая «сетевая очередь», а несколько состояний с разными владельцами.

tcp_rmem и tcp_wmem задают тройки min/default/max для автоматического подбора. По актуальной документации Linux kernel, receive autotuning ограничивается максимумом tcp_rmem[2]; явный SO_RCVBUF для конкретного сокета отключает autotuning его receive buffer. Это важная ловушка: «точечная оптимизация» в библиотеке может незаметно отменить более разумное поведение ядра.

Представьте медленного SSE-клиента. Gateway получает токены от backend быстро, но браузер или корпоративный proxy читает ответ рывками. Растёт очередь отправки downstream-сокета. Увеличив wmem, вы не ускорите клиента — лишь разрешите gateway дольше хранить его отставание. Поэтому направление потока и конкретный socket owner важнее среднего числа байтов на хосте.

Снимите baseline: sysctl, socket memory и TCP_INFO

Начните с неизменяемого снимка. Нужны значения sysctl, число соединений, распределение RTT, retransmissions и память конкретных сокетов. Команда ss -tinm удобна тем, что объединяет TCP internal info и skmem. В выводе rb и tb означают доступные receive/send limits, r — занятую receive memory, w — queued send memory, bl — socket backlog, d — drops. Эти поля описаны в ss(8).

Не снимайте один «красивый» сокет. Возьмите выборку здоровых и проблемных streams на одном route, с сопоставимым размером prompt и моделью. Если у зависших соединений стабильно заполнен wmem_queued, а у контрольных нет, появляется рабочая гипотеза. Если различий нет, TCP buffer пока остаётся отрицательным контролем.

sysctl net.ipv4.tcp_moderate_rcvbuf \
       net.ipv4.tcp_rmem net.ipv4.tcp_wmem \
       net.core.rmem_max net.core.wmem_max
ss -tinm state established '( sport = :443 )'
nstat -az | egrep 'TcpRetransSegs|TcpExtTCPRcvQDrop|TcpExtTCPMemoryPressures'
cat /proc/net/sockstat

Сопоставляйте socket evidence со временем на уровне приложения. Для LLM streaming полезно логировать accept time, отправку upstream, первый байт от inference backend, первый байт клиенту и завершение response. Так видно, образовалась пауза до модели, внутри proxy или уже на downstream. Без этой временной линии заполненный buffer легко принять за причину, хотя он лишь следствие остановившегося consumer.

Как читать ss -tinm без ложных выводов

Одно высокое значение rb не доказывает проблему: это capacity, а не фактическая очередь. Смотрите пары. Если r приближается к rb и одновременно приложение редко читает, причина, вероятно, в scheduler, блокирующем фильтре или CPU throttling. Если w растёт рядом с ухудшением delivery rate, исследуйте peer и путь ACK. Если d меняется, локализуйте drops до изменения лимитов.

Поля cwnd, rtt, rto, delivery rate и retransmissions отвечают на другой вопрос: способен ли путь унести данные. Маленький congestion window после loss не лечится большим wmem. Точно так же большое bandwidth-delay product может требовать достаточного window, но для токенов по несколько десятков байтов throughput редко является единственной границей. Проверьте это фактом, а не предположением.

Типичная ловушка — агрегировать все соединения к одному среднему. Один медленный клиент может держать мегабайты очереди, пока тысячи streams здоровы. Группируйте по route, ASN или классу клиента, версии gateway и backend pool. В инциденте спросите: «Это один socket с необычным peer или весь canary-процесс?» Ответ определяет, нужен ли сетевой fix, ограничение per-connection или изоляция медленных потребителей.

Autotuning и bandwidth-delay product: когда потолок действительно мал

Receive autotuning пытается подобрать окно под путь, не превышая tcp_rmem[2]. Для bulk transfer ориентиром служит bandwidth-delay product: сколько данных должно находиться «в полёте», чтобы канал не простаивал. Но LLM streaming не похож на непрерывную передачу большого файла. После первого токена приложение часто выдаёт небольшие chunks, поэтому ограничителем становятся scheduling, flush semantics, proxy buffering или медленный consumer.

Проверка должна разделять режимы. Возьмите один и тот же gateway и сравните небольшой streaming response, длинный ответ и контролируемую bulk-передачу по тому же пути. Если только bulk упирается в окно, а межтокенные паузы одинаковы, увеличение TCP max не исправит LLM latency. Если и stream на большом RTT показывает закрывающееся receive window, причина выглядит убедительнее.

Не копируйте sysctl из чужого benchmark. Значения зависят от RAM, concurrency, kernel, приложения и того, выставляет ли библиотека собственные socket options. tcp(7) также напоминает, что kernel учитывает служебный overhead и может показывать размер, отличающийся от запрошенного через setsockopt(). План capacity должен опираться на фактический skmem, а не на умножение max на число соединений как на гарантированное выделение.

Memory pressure: почему большие maxima могут ухудшить инцидент

Maxima — не бесплатный резерв. Ядро выделяет socket memory по потребности, однако при тысячах долгоживущих соединений совокупный рост становится заметным. tcp_mem задаёт системные пороги в страницах памяти; при pressure TCP начинает умерять потребление. Одновременно процесс gateway держит userspace buffers, TLS state, HTTP/2 streams и очереди фильтров. В контейнере всё это конкурирует внутри memory limit.

Плохой сценарий выглядит так: команда увеличивает tcp_rmem[2] и tcp_wmem[2], streams переживают более долгие паузы клиентов, RSS процесса растёт, Pod попадает под memory pressure, event loop получает меньше CPU или контейнер завершается по OOM. На графике сеть сначала кажется стабильнее, но application outcome становится хуже. Поэтому canary обязан включать socket memory, RSS/cgroup memory, CPU throttling и завершение streams.

Поставьте budget, а не «большое значение». Например, определите допустимую память gateway при целевой concurrency и abort criterion по working set. Число берите из собственного canary, а не из статьи. Если медленные клиенты способны удерживать буферы бесконечно, добавьте backpressure, per-connection limits и timeout policy на уровне приложения. Выделенный сервер даёт более предсказуемый запас и kernel baseline, но не отменяет необходимость ограничивать очередь.

Отделите TCP от proxy buffering и application backpressure

Между inference backend и клиентом обычно есть несколько буферов: библиотека HTTP, TLS record layer, reverse proxy, L7-фильтры и TCP. NGINX при включённом proxy_buffering читает ответ upstream как можно быстрее и сохраняет его в настроенных buffers; для streaming route это может менять видимую клиенту подачу. Envoy отдельно управляет L4/L7 limits и HTTP/2 flow control. Увеличение kernel buffers не отменяет паузу фильтра, которому нужен полный body.

Проверяйте слои по очереди. Если backend выдаёт токены ровно, а gateway отправляет их клиенту пачками при пустом wmem, ищите flush и buffering. Если userspace пишет регулярно, но wmem_queued растёт, тогда peer или transport сдерживает поток. Если backend сам молчит, возвращайтесь к GPU queue и scheduler. В материале про Envoy overload manager мы разбирали защиту proxy от перегрузки; здесь socket evidence помогает не перепутать overload с транспортным запасом.

Для negative control отправьте тот же stream в локальный быстрый consumer, минуя внешний медленный путь, но сохранив gateway и backend. Затем сравните удалённого клиента через production route. Исчезновение очереди на локальном consumer связывает проблему с downstream; сохранение пауз указывает на gateway или backend. Это гораздо сильнее, чем переключить sysctl и увидеть случайное улучшение.

curl -Nsv --http1.1 https://gateway.example/v1/stream \
  -H 'Authorization: Bearer REDACTED' \
  -o /dev/null 2>client-timing.log

while true; do
  date --iso-8601=seconds
  ss -tinm state established '( sport = :443 )'
  sleep 2
done

Kubernetes: Pod sysctl, hostNetwork и граница ответственности

В Kubernetes важно понять, где живёт gateway socket. Для обычного Pod network namespace часть net.* sysctl может быть namespaced. В актуальной документации Kubernetes net.ipv4.tcp_rmem и net.ipv4.tcp_wmem входят в safe set начиная с Kubernetes 1.32 при Linux kernel 4.15 или новее. Для Pod с hostNetwork: true сетевые sysctl через security context не разрешены: изменение уже затрагивает node boundary.

Это не приглашение задать одинаковые maxima каждому Pod. Сначала подтвердите версию control plane, kubelet и kernel, затем примените настройку к отдельному Deployment или node pool. Сохраните обычный Pod без sysctl как negative control. Метрики должны включать cgroup memory, restarts, throttling, connection completion и socket fields на fresh connections: уже открытый socket не всегда отражает новый baseline.

Разделите ownership. Platform team отвечает за node-wide limits и admission policy; команда gateway — за socket options, buffering и concurrency; команда модели — за выдачу токенов. Если все три слоя меняются одним rollout, доказать причину невозможно. Похожий принцип effective path мы использовали в разборе NodeLocal DNSCache для LLM inference: проверяется не декларация, а реальный namespace и результат приложения.

apiVersion: v1
kind: Pod
metadata:
  name: llm-gateway-buffer-canary
spec:
  securityContext:
    sysctls:
      - name: net.ipv4.tcp_rmem
        value: "4096 131072 4194304"
      - name: net.ipv4.tcp_wmem
        value: "4096 16384 4194304"
  containers:
    - name: gateway
      image: example/llm-gateway:tested
      resources:
        requests:
          memory: "512Mi"
        limits:
          memory: "1Gi"

Числа в примере — демонстрационная форма manifest, не рекомендация для production. Подставьте значения из baseline и проверьте их в вашей версии. Если приложение выставляет SO_RCVBUF, изменение tcp_rmem может не дать ожидаемого эффекта; зафиксируйте socket options через документацию runtime или eBPF/tracepoint-инструменты, доступные вашей команде.

Canary и rollback: меняйте один owner за раз

Хороший canary воспроизводит проблему, а не просто принимает часть трафика. Выберите клиентов с тем же RTT и темпом чтения, одинаковый route, модель и payload class. На baseline зафиксируйте распределения, а не только среднее: TTFT, максимальную межтокенную паузу, долю завершённых streams, retransmissions, r/rb, w/tb и память процесса. После этого измените один параметр.

Success criterion должен связывать низкий уровень с приложением. Например: проблемные sockets перестали упираться в receive limit, а completion rate и межтокенные паузы улучшились без роста memory pressure. Увеличившийся advertised window без изменения user experience — не успех. Аналогично уменьшение очереди при одновременном росте resets означает перенос проблемы.

Rollback делайте симметричным. Верните исходный sysctl или socket option, создайте fresh connections и повторите те же probes. Если эффект исчез, причинность усиливается. Если остался, ищите одновременное изменение маршрута, нагрузки backend или клиента. Для долгоживущих streams важен отдельный drain plan; опубликованный runbook про HTTP/2 GOAWAY и graceful drain помогает не обрывать активные запросы во время смены gateway.

# baseline
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem > /var/tmp/tcp-buffer.baseline

# apply only after recording approved values
sysctl -w net.ipv4.tcp_rmem='MIN DEFAULT MAX'
sysctl -w net.ipv4.tcp_wmem='MIN DEFAULT MAX'

# rollback from the captured baseline values
while read -r key _ value1 value2 value3; do
  sysctl -w "$key=$value1 $value2 $value3"
done < /var/tmp/tcp-buffer.baseline

Когда оставить autotuning, настроить socket или масштабировать gateway

Оставьте autotuning, если socket limits не насыщаются, RTT и delivery rate нормальны, а задержка возникает в proxy или inference queue. Это самый частый и самый дешёвый verdict: параметр не является owner проблемы. Не меняйте инфраструктуру без доказанного socket-memory bottleneck.

Настройте конкретный socket, если один класс соединений имеет особый путь и приложение может безопасно управлять buffer. Например, отдельный upstream к удалённому GPU pool на большом RTT отличается от локальных downstream streams. Учитывайте, что ручной SO_RCVBUF меняет семантику autotuning. Документируйте библиотеку, момент вызова относительно connect()/listen() и память на соединение.

Измените node-wide ceiling, если множество сокетов на одном gateway упираются в доказанный системный потолок и canary показывает улучшение application outcome. Делайте это на отдельном node pool с memory budget. Масштабируйте gateway, когда bottleneck связан с совокупной памятью, CPU или failure domain: горизонтальное распределение connections часто безопаснее огромных per-socket maxima.

VPS подходит для небольшого controlled edge и воспроизводимого canary; выделенный сервер полезен, когда важны NIC queues, стабильный kernel/driver baseline и предсказуемый запас RAM. Disqualifier обязателен: новое железо не исправит медленного клиента, включённый proxy buffering, блокирующий L7 filter или GPU queue. Сначала path proof, затем procurement.

Production-runbook: от симптома до проверенного исправления

Сведите расследование к короткой цепочке доказательств. Первое: path — какой client, gateway instance и backend фактически обслуживали stream. Второе: socket — что происходило с rmem, wmem, RTT, cwnd, retransmissions и drops. Третье: application — когда читали и писали userspace, работал ли buffering. Четвёртое: outcome — изменились ли TTFT, паузы и завершение ответа.

1. Зафиксируйте affected и healthy stream с одинаковым payload class.
2. Снимите ss -tinm, nstat, sockstat и cgroup memory.
3. Проверьте proxy buffering, L7 filters и backend token cadence.
4. Сформулируйте один owner и один параметр.
5. Запустите canary на fresh connections с negative control.
6. Проверьте memory budget и failure signals.
7. Выполните rollback и повторите те же probes.

Если проблема воспроизводится только на одном сетевом пути, дополните проверку route и loss. Если она появляется на одном process instance, смотрите event loop, CPU affinity и scheduling; статья про RSS, RPS и IRQ affinity разграничивает сетевой CPU и приложение. Если паузы коррелируют с исчерпанием backend capacity, вернитесь к overload control, а не расширяйте TCP queues.

Рабочий результат — не «мы увеличили буфер», а проверенная причинная связь и ограниченный blast radius. Сохраните baseline, change window, owner и условия возврата. Так следующий инцидент начинается с фактов, а не с ещё одного sysctl из истории команд.

Итог: буфер должен подтверждать поток, а не скрывать очередь

TCP autotuning в Linux уже умеет подстраивать receive и send buffers, поэтому ручное увеличение maxima не должно быть первым шагом. Для LLM streaming важнее связать четыре слоя: реальный путь, состояние socket, поведение gateway и пользовательский результат. Заполненный wmem при медленном клиенте, пустые buffers при proxy batching и memory pressure у тысяч streams требуют разных решений.

Начните с ss -tinm и временной линии одного проблемного ответа. Сохраните healthy negative control, измените один owner на canary и обязательно верните настройку к baseline. Только улучшение application outcome при контролируемой памяти даёт право закрепить change.

Если доказан node-wide bottleneck, перенесите gateway на предсказуемый VPS или выделенный edge с понятным kernel/NIC baseline и отдельным failure domain. Но сначала примените checklist из runbook к своему трафику: он быстро покажет, нужен ли новый ceiling, точечный socket option или исправление совсем другого слоя.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Сначала симптом, потом offload

Шлюз LLM API принимает привычный объём запросов, но одно ядро внезапно уходит в softirq, растёт число пакетов в секунду, а время до первого токена становится рваным. На графике CPU всё выглядит как «сеть не справляется», и рука тянется выключить GRO или TSO. Это опасная догадка: похожую картину дают плохое распределение RX-очередей, короткие соединения, туннель без нужного offload, TLS termination и медленный backend.

GRO, GSO, TSO и checksum offload уменьшают количество операций, которые CPU выполняет на каждый пакет. Они не добавляют пропускную способность сами по себе и не исправляют очередь в inference-сервисе. Поэтому рабочий вопрос звучит не «какой флаг быстрее», а «на каком участке packet path изменилась работа и улучшился ли пользовательский outcome».

Для LLM gateway особенно важно разделять две фазы. До первого байта нас интересуют accept, TLS, маршрутизация и TTFT. После начала SSE-потока важны progress, стабильность соединения и отсутствие длинных пауз. Если p99 TTFT не меняется, а CPU proxy падает, это полезный результат, но его нельзя выдавать за ускорение модели.

Дальше используем четыре evidence gate: фактический путь интерфейсов, состояние offload на каждом hop, kernel/NIC counters и application outcome на новых соединениях. Такой порядок продолжает подход из материалов про RSS, RPS и IRQ affinity и SO_REUSEPORT: сначала локализуем owner, затем меняем ровно один механизм.

Что именно делают GRO, GSO, TSO и checksum offload

GSO позволяет стеку Linux передавать вниз крупный socket buffer, который позже будет разрезан на сегменты. TSO выполняет TCP-сегментацию в сетевой карте, а программный GSO остаётся страховкой для пути, где железо не умеет нужный вариант. На приёме GRO объединяет совместимые пакеты в более крупные skb, чтобы верхние слои обрабатывали меньше объектов.

Связка симметрична по смыслу, но не по месту исполнения. TSO относится к передаче и зависит от возможностей NIC и TX checksum offload. GRO работает на receive path и может выполняться программно. Официальная документация Linux по segmentation offloads подчёркивает: собранная GRO последовательность в идеале должна снова корректно сегментироваться через GSO.

Checksum offload тоже не означает «контрольная сумма отсутствует». При TX стек оставляет устройству описание того, где лежат данные для вычисления; на RX драйвер сообщает, проверена ли сумма. В туннелях появляются внутренний и внешний заголовки, поэтому поддержка обычного TCP checksum ещё не доказывает корректную обработку VXLAN или Geneve. Состояния CHECKSUM_PARTIAL и CHECKSUM_UNNECESSARY описаны в документации ядра.

Практический пример: proxy пишет крупную TLS-запись, стек держит её как большой skb, а NIC формирует wire-sized TCP segments. Если снять tcpdump на хосте до NIC, можно увидеть «пакет» больше MTU. Это не доказательство, что такой Ethernet frame ушёл в сеть. Проверяли ли вы тот же поток с внешнего TAP или на соседнем узле?

Постройте owner map реального packet path

На выделенном сервере путь может быть коротким: физический NIC → Linux TCP → NGINX или Envoy → upstream. На VPS он часто длиннее: NIC хоста → vhost/virtio → интерфейс гостя → bridge или overlay → контейнерный veth → proxy. У каждого hop свой набор feature flags, свои counters и собственный owner. Проверка только eth0 внутри VM даёт кусок картины, а не картину.

Начните с адреса назначения и фактического peer. Для входящего запроса зафиксируйте интерфейс, RX queue, CPU, namespace, место TLS termination и interface до upstream. Для исходящего потока добавьте route lookup и туннель. Один gateway может принимать клиента по физическому NIC, а ходить к GPU через VXLAN; успешный TSO на первом пути ничего не говорит о втором.

Разделите owner по слоям: провайдер или hypervisor управляет physical NIC и vhost; ваша команда — guest kernel, CNI, proxy и systemd units; приложение — connection pool и streaming semantics. Эта граница важна для решения о VPS или dedicated gateway. Новое железо полезно, когда нужен контроль драйвера, очередей, firmware и change window. Оно не исправляет ошибочный route, single-flow hotspot или очередь vLLM.

Мини-кейс: после миграции в VM растёт CPU при той же нагрузке. В госте TSO включён, но host-side tap не принимает нужный tunnel GSO и выполняет software segmentation. Лечить guest sysctl бессмысленно. Evidence должен дойти до границы, которой вы реально управляете.

ip -br link
ip route get 203.0.113.20
ethtool -i eth0
ethtool -k eth0
ethtool -S eth0 | head -n 80
ip -s -s link show dev eth0

Снимите baseline: features, counters и workload

ethtool -k показывает requested и effective features. Пометка [fixed] означает, что драйвер не разрешает переключить опцию обычной командой. Не превращайте список флагов в чеклист «всё должно быть on»: набор зависит от драйвера, типа устройства, инкапсуляции и kernel version. Актуальный ethtool остаётся стандартным интерфейсом управления драйвером и hardware features; его возможности перечислены на странице проекта.

Baseline нужен одновременно на трёх уровнях. На NIC смотрите drops, missed errors, queue counters и driver-specific fallback. В ядре — softirq по CPU, backlog/drop, retransmits и packet rate. В приложении — request rate, TTFT, долю 5xx, resets, длину активных SSE-соединений и utilisation inference backend. Запись только среднего CPU скрывает миграцию bottleneck между ядрами.

Снимайте состояние под репрезентативным трафиком и сохраняйте распределение размеров ответов. Короткий health check почти не создаёт полезной нагрузки для TSO/GRO, а один долгий SSE stream плохо показывает параллелизм. Нужны и короткие fresh connections, и потоковые ответы, причём на одной версии proxy и модели.

Документация ядра по RSS/RPS/RFS/XPS объясняет, как потоки распределяются по очередям и CPU. Это соседний механизм: GRO может снизить число skb, но не вылечит очередь, прибитую к одному перегруженному CPU. Если после изменения offload нагрузка просто переехала, application gate не пройден.

Почему tcpdump показывает странные размеры и bad checksum

Захват внутри хоста происходит в точке, где пакет ещё может быть большим skb или иметь незаполненную аппаратную checksum. Поэтому Wireshark способен подсветить checksum как неверную, хотя на wire она корректна. Это нормальный эффект точки наблюдения, а не автоматическое доказательство повреждения трафика.

Сравните минимум две точки: capture на gateway и capture после физического NIC — например, на TAP, SPAN или соседнем узле. Для виртуального пути добавьте capture в guest namespace и на host-side tap. Если «гигантские пакеты» есть только до segmentation, а внешний capture укладывается в MTU, TSO/GSO выполняют ожидаемую работу.

Не отключайте checksum offload глобально ради красивого capture. Сначала используйте анализатор, который умеет учитывать offload, или проверяйте wire-side. Временное выключение допустимо на canary-интерфейсе с коротким change window и явным rollback. На production gateway такая команда меняет CPU-cost всего трафика и может сама создать перегрузку.

Типичная ловушка: инженер видит bad checksum на loopback или veth, выключает TX checksum, CPU растёт, а жалоба клиента остаётся. Правильный negative control — тот же запрос через другой capture point или внешний probe. Если пользовательский outcome не меняется, причина была в наблюдении, а не в пакетах.

sudo tcpdump -ni eth0 -s 0 -w /tmp/gateway-eth0.pcap 'tcp port 443'
sudo nsenter -t "$(pgrep -n nginx)" -n tcpdump -ni any -s 0 -w /tmp/proxy-ns.pcap 'tcp port 443'
ethtool -k eth0 | grep -E 'checksum|segmentation|generic-receive'

Виртуализация и туннели: проверяйте inner и outer path

В overlay-сети один логический пакет несёт внутренние TCP/IP headers и внешний UDP/VXLAN или Geneve header. NIC может уметь обычный TSO, но не конкретный tunnel offload. Тогда часть работы возвращается в software GSO, а CPU host или guest растёт. По одному флагу tcp-segmentation-offload: on это не видно.

Проверьте features на physical NIC, bridge/tap, virtio и veth. Сопоставьте их с реальным encapsulation. Ядро поддерживает отдельные GSO-типы для GRE и UDP tunnels, а также ограничивает глубину вложенных headers. Не переносите поведение bare metal на VPS без измерения: effective path и драйвер здесь другие.

Для Kubernetes добавьте CNI owner: кто создаёт tunnel device, где работает eBPF или iptables, кто меняет MTU. Если после включения overlay появились retransmits, сначала исключите PMTU и MTU mismatch. Offload не компенсирует фрагментацию, потерю ICMP Packet Too Big или слишком большой inner packet.

Нужен понятный procurement default: оставайтесь на текущей платформе, пока не доказан control gap. Dedicated edge оправдан, если canary связывает проблему с недоступным вам host NIC, драйвером, queue layout или tunnel feature. Для общей архитектуры private inference полезен материал про Private AI API, но здесь решение принимается по packet-path evidence.

Canary: меняйте один флаг и требуйте application outcome

Безопасный canary начинается с неизменного baseline-узла и одного узла-кандидата. На них должны идти сопоставимые fresh connections, размеры prompts и режим streaming. Измените только один effective feature: например, GRO на receive path или TSO на transmit path. Одновременное переключение GRO, GSO, TSO и checksum превращает тест в лотерею.

Собирайте механизм и результат в одном окне. Mechanism gate: effective flag действительно изменился, packet rate или skb processing изменились ожидаемо, counters не показывают ошибки. Resource gate: softirq, system CPU и queue pressure не ухудшились. Application gate: TTFT, error rate, resets и скорость выдачи токенов не деградировали. Backend gate: GPU queue и model latency остались сопоставимыми.

После положительного результата выполните контрфакт: верните флаг в baseline и проверьте, вернулась ли метрика. Затем повторите изменение. Такой A/B/A цикл защищает от совпадения с изменением нагрузки. Отдельно смотрите существующие соединения: offload и routing changes могут влиять на новые flows иначе, чем на уже открытые SSE streams.

Canary должен иметь лимит времени и автоматический stop по ошибкам. Не оставляйте ручную команду единственным знанием команды. После принятия решения закрепите setting в NetworkManager, systemd-networkd, udev или конфигурации orchestration, но только способом, соответствующим вашей ОС и драйверу.

#!/usr/bin/env bash
set -euo pipefail
dev=eth0
before="$(ethtool -k "$dev")"
trap 'ethtool -K eth0 gro on; logger -t offload-canary "rollback gro=on"' EXIT
ethtool -K "$dev" gro off
ethtool -k "$dev" | grep 'generic-receive-offload'
# Запустите штатный load probe и сбор NIC/softirq/application metrics.
sleep 60
ethtool -K "$dev" gro on
trap - EXIT
printf '%s\n' "$before" > /var/tmp/offload-baseline.txt

Как читать результат и не принять миграцию bottleneck за успех

Если отключение GRO снижает tail latency, но резко поднимает softirq и не меняет TTFT, вы нашли trade-off, а не готовую настройку. Возможно, coalescing увеличивал burst в proxy, но проблема лежит в scheduler или user-space queue. Проверьте размер batching и wakeups, затем повторите тест. Локальное улучшение одной метрики не должно покупать более хрупкий gateway.

Если TSO off снижает retransmits, найдите точный hop. Возможны driver/firmware defect, несовместимость туннеля или ошибка внешнего устройства. Зафиксируйте kernel, driver и firmware, проверьте release notes и воспроизведите на одном хосте. Постоянно держать TSO off допустимо как осознанный workaround, но его CPU-стоимость должна быть измерена.

Если offload меняет gateway CPU, а application outcome не двигается, bottleneck находится дальше: TLS, proxy, network egress или GPU queue. Это полезный disqualifier для закупки. Материал про TLS handshake storm поможет отделить криптографическую нагрузку, а сравнение Nginx, Caddy и Traefik — проверить границу reverse proxy.

Наконец, не сравнивайте только throughput. Для LLM API важны стабильный first byte, progress после него, отсутствие обрывов и предсказуемая цена CPU на соединение. Иногда лучший результат — тот же latency при меньшем system CPU: он оставляет capacity для пика и делает failure domain менее нервным.

Когда VPS достаточно, а когда нужен dedicated gateway

VPS подходит, если provider даёт стабильный virtio path, вы видите нужные counters, а canary подтверждает application SLO при разумном CPU reserve. Для небольшого private LLM API это часто лучший старт: меньше операционного долга, быстрее rollout, проще резервирование. Требовать physical NIC только потому, что существует TSO, нет смысла.

Dedicated gateway становится рациональным, когда доказана зависимость от конкретного NIC, driver или firmware, нужна предсказуемая queue topology, NUMA locality, аппаратные tunnel features или отдельное change window. Коммерческая ценность здесь не в обещании «меньше latency», а в воспроизводимом baseline и контроле failure domain. Это особенно важно, когда один edge обслуживает много GPU workers.

Managed load balancer снимает часть ownership, но может скрывать offload и queue details. Выбирайте его, если его SLO и telemetry достаточны, а не если хочется избежать диагностики. Если нужен точный контроль packet path, VPS или dedicated edge могут быть прозрачнее — ценой поддержки kernel, drivers и rollback вашей командой.

Перед закупкой сформулируйте disqualifiers. Новая платформа не исправит плохую hash entropy, один горячий flow, неверный MTU, retry storm, proxy buffering или очередь модели. Сначала докажите, что bottleneck проходит через слой, который вы собираетесь купить. Иначе вы просто перенесёте ту же проблему на более дорогой сервер.

Production-runbook и вывод

Сведите решение к короткому operational contract. Для каждого gateway храните kernel, driver, firmware, effective offload features, queue layout и владельца конфигурации. В мониторинге рядом должны жить NIC errors, drops, per-CPU softirq, packet rate, proxy CPU, TTFT, resets и backend latency. Тогда после обновления kernel или миграции VM вы увидите не просто «CPU вырос», а участок, где изменился механизм.

Rollout выполняйте ступенчато: один canary, затем малая доля fresh connections, затем один failure domain. Длинные SSE streams дренируйте отдельно; не используйте mid-stream retry как универсальную HA-функцию. После каждого шага сравнивайте с неизменным baseline и сохраняйте возможность вернуть прежние features без перезагрузки.

Отдельно проверяйте обновления. Feature, показанный как on, может работать иначе после смены driver или виртуальной платформы. Повторите внешний capture, negative control и application probe. Для UDP-based tunnels помните, что устаревший UFO не является современной стратегией: актуальный путь строится на GSO и tunnel-specific offloads.

Главный вывод простой: GRO, GSO, TSO и checksum offload — это способы уменьшить packet-processing work, а не магические ускорители LLM. Оставляйте настройку, только если связали effective mechanism с resource budget и пользовательским outcome, а затем подтвердили причинность rollback. Начните с owner map и baseline на одном gateway; если evidence упрётся в чужой hypervisor или закрытый NIC, тогда уже выбирайте инфраструктуру с нужной границей контроля.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Snapshot Qdrant — не вся стратегия восстановления

У snapshot есть сильная сторона: он сохраняет данные коллекции вместе с конфигурацией и готовым индексом. После восстановления не приходится заново строить HNSW, а это особенно заметно на большой RAG-базе. Но архив относится к конкретной коллекции и конкретному узлу. Он не включает collection aliases, не описывает балансировщик, API-ключи, DNS, объектное хранилище и порядок возврата приложения.

Поэтому быстрый verdict такой: для single-node Qdrant snapshot — хороший переносимый recovery artifact; для распределённого кластера нужен комплект копий по узлам и отдельный runbook; в Qdrant Cloud для полного disaster recovery разумнее использовать backups. Официальная документация прямо разделяет snapshots и cloud backups. Это та же граница, что подробно разобрана в материале KingServers «Backup vs Snapshot».

Disqualifier важен сразу: snapshot не лечит ошибочную embedding-модель, неверный chunking или потерю исходных документов. Если после восстановления векторы формально доступны, но retrieval выбирает не те фрагменты, проблема находится выше storage layer. Не покупайте дополнительный сервер до того, как локализовали слой отказа.

Начните с RPO и RTO, а не с команды curl

RPO отвечает на вопрос, сколько последних изменений допустимо потерять. RTO — сколько времени сервис может оставаться без нормального поиска. Для каталога, который переиндексируется из PostgreSQL или object storage, RPO Qdrant может быть мягче: источником истины остаётся документная база. Для пользовательской памяти ассистента потеря последних часов может быть уже бизнес-инцидентом.

Соберите resource budget восстановления: объём snapshot, свободное место на target, пропускную способность между failure domains, RAM для открытия сегментов и окно, в котором GPU-инференс будет получать неполный контекст. По актуальной документации Qdrant target во время миграции или восстановления может требовать дополнительное дисковое пространство: одновременно существуют архив и восстановленная коллекция. Проверяйте это на своей версии и фактическом размере, а не переносите чужую оценку.

Практический пример: snapshot создаётся каждые шесть часов, но выгружается с узла только раз в сутки. Формальный RPO равен не шести часам, а возрасту последней копии, пережившей отказ узла. Owner должен уметь назвать эту дату без входа на уже умерший сервер. Более широкий процесс удобно сверить с планом Disaster Recovery.

Зафиксируйте baseline до создания snapshot

До первой команды сохраните идентичность среды: точную версию Qdrant, режим single-node или cluster, список коллекций и aliases, vector size и distance, shard_number, replication_factor, write_consistency_factor, quantization и on_disk параметры. Snapshot, созданный Qdrant 1.18.1, по текущему правилу совместимости восстанавливается в ту же minor-ветку не ниже patch-версии источника либо в следующую minor-ветку. Для 1.18.1 это 1.18.1+ или 1.19.x; не превращайте пример в вечное правило — перед restore сверяйтесь с документацией вашей версии.

Снимите data baseline отдельно от конфигурации: число points, несколько известных IDs с payload, результаты десяти-пятидесяти golden queries и негативный набор. Golden query должен иметь ожидаемый документ или допустимый набор документов; negative control — документ, который обязан отсекаться tenant/filter политикой. Так вы отделите «архив распаковался» от «RAG снова отвечает правильно».

Наконец, запишите owner каждого gate. Platform team отвечает за узлы и диски, database owner — за коллекции и aliases, ML/RAG owner — за embedding identity и retrieval outcome. Если один человек отвечает за всё только на бумаге, во время инцидента три слоя снова сольются в одну фразу «Qdrant поднялся».

curl -fsS http://127.0.0.1:6333/\ncurl -fsS http://127.0.0.1:6333/collections/knowledge\ncurl -fsS 'http://127.0.0.1:6333/collections/knowledge/points/count?exact=true'

Создайте snapshot и сразу вынесите его из failure domain

Collection snapshot создаётся API-запросом к конкретному узлу. Ответ возвращает имя файла; затем файл нужно скачать, посчитать checksum и отправить в независимое хранилище. Копия на том же NVMe защищает от неудачного UPDATE, но не от потери диска, узла или стойки. Объектное хранилище, отдельный backup-сервер или другой регион выбираются по вашему threat model.

Не считайте HTTP 200 доказательством backup. Минимальный evidence bundle включает JSON-ответ создания, размер файла, SHA-256, версию Qdrant, collection config, timestamp и результат чтения архива из целевого хранилища. Шифрование и retention задаются вне Qdrant, а ключ восстановления не должен находиться только в том же кластере.

Для хранения больших коллекций полезна отдельная I/O-квота: snapshot не должен вытеснить рабочие сегменты или забить диск временными файлами. Qdrant позволяет указать snapshots_path и отдельный путь для временных файлов. Если storage budget не выдерживает одновременно рабочие данные и создание архива, это уже qualifying condition для выделенного backup path или отдельного узла, а не повод запускать cron чаще.

QDRANT=http://127.0.0.1:6333\nCOLLECTION=knowledge\nSNAPSHOT=$(curl -fsS -X POST "$QDRANT/collections/$COLLECTION/snapshots" | jq -r '.result.name')\ncurl -fsS -o "$SNAPSHOT" "$QDRANT/collections/$COLLECTION/snapshots/$SNAPSHOT"\nsha256sum "$SNAPSHOT" > "$SNAPSHOT.sha256"\nsha256sum -c "$SNAPSHOT.sha256"

В распределённом Qdrant снимайте каждый узел

В cluster mode одна collection snapshot содержит только данные, размещённые на узле, который её создал. Значит, запрос к случайному endpoint не даёт полную копию распределённой коллекции. Runbook обязан перечислить peers, запросить snapshot на каждом узле и связать файлы общим manifest: cluster ID, peer ID, collection, shard inventory, версия, время и checksum.

Репликация остаётся первым механизмом высокой доступности. При кратком выпадении узла Qdrant может восстановить пропущенные операции через WAL delta; если разница недоступна, возможен fallback к полному переносу records. Snapshot transfer переносит готовый индекс и quantized data, но требует дополнительного места. Эти методы решают восстановление replica внутри живого кластера, тогда как внешний snapshot нужен против удаления коллекции, повреждения данных или потери failure domain.

Типичная ловушка: три узла размещены на одном физическом сервере или одном сетевом томе. Формально replication_factor равен трём, фактически failure domain один. Перед покупкой большего кластера нарисуйте physical placement: питание, гипервизор, NVMe, стойка, регион. Выделенная инфраструктура полезна здесь не «ускорением векторов», а контролем размещения, I/O budget и окна восстановления. Для выбора backend пригодится сравнение Ceph, MinIO и NAS.

Восстанавливайте сначала в изолированное окружение

Никогда не проверяйте новый runbook первым restore поверх production. Поднимите target той же или совместимой версии, ограничьте входящий трафик и убедитесь, что приложение не может случайно писать туда до завершения проверки. Для новой коллекции официальный API поддерживает recover по доступному URL, file URI или загрузку файла. В Qdrant Cloud outbound URL restore ограничен, поэтому используйте поддерживаемый upload или cloud backup flow.

Для пустой target-коллекции задавайте priority=snapshot. Оставленный по умолчанию priority=replica предпочитает существующее состояние, и в новом кластере это может означать пустой источник. Режим no_sync предназначен для специальных ручных сценариев; без точного shard map он способен оставить систему в сломанном состоянии. Это не «быстрый restore», а инструмент для оператора, который управляет синхронизацией сам.

После запроса дождитесь завершения, но не переключайте alias. Сначала инфраструктурный gate: collection status green, все shards active, replica count соответствует плану, vector configuration совпала. Затем data gate: count, контрольные IDs и payload. Только после них открывается application gate. Порядок важен: если point отсутствует, обсуждать качество ответа LLM рано.

curl -fsS -X PUT 'http://restore-qdrant:6333/collections/knowledge_restore/snapshots/recover' \\\n  -H 'Content-Type: application/json' \\\n  -d '{"location":"file:///qdrant/snapshots/knowledge.snapshot","priority":"snapshot"}'\n\ncurl -fsS http://restore-qdrant:6333/collections/knowledge_restore

Докажите восстановление на уровне RAG-приложения

Зелёная коллекция подтверждает storage mechanism, но не пользовательский результат. Запустите golden queries тем же embedding pipeline и теми же search parameters, что использует production: vector name, limit, filters, score threshold, hybrid dense/sparse fusion. Сравнивайте не только top-1. Для RAG важны presence ожидаемого источника в top-k, соблюдение tenant boundaries и возможность собрать ответ с корректными citations.

Добавьте отрицательную проверку. Например, запрос от tenant A не должен вернуть документ tenant B, удалённый документ не должен снова появиться, а заведомо нерелевантный corpus не должен пройти threshold. Именно negative control ловит опасный restore: данные доступны, latency приемлема, но старая payload-схема отключила фильтр доступа.

Метрики держите раздельно: infrastructure — shard state, disk и process errors; retrieval — latency, empty result rate, expected-document hit rate; application — доля успешных ответов, корректность ссылок и cancellations. Не обещайте, что snapshot восстановит изменения после точки создания. Если ingestion продолжался, отставание должно проявляться как измеримый RPO gap, а не как сюрприз пользователей.

./rag_probe --collection knowledge_restore --suite golden.json --expect-source\n./rag_probe --collection knowledge_restore --suite tenant-boundary.json --expect-deny\n./rag_probe --collection knowledge_restore --suite deleted-docs.json --expect-absent

Переключайте трафик через alias и сохраняйте rollback

Безопасный cutover меняет один управляемый указатель, а не конфигурацию десятка сервисов. Если приложение использует alias, подготовьте восстановленную коллекцию под новым именем, завершите gates, затем атомарно переключите alias. Старую коллекцию не удаляйте до окончания observation window и подтверждения, что новые записи идут в правильный target.

Canary может направлять малую долю read-only запросов на восстановленную коллекцию. Сравнивайте одинаковые query IDs, embedding hash и фильтры; иначе различие результатов нельзя приписать restore. Stop condition задайте заранее: рост ошибок, нарушение tenant filter, неожиданный empty result или несовместимая схема payload означает возврат alias на baseline.

Rollback должен повторять те же доказательства в обратном порядке: application probe после возврата alias, data probe на baseline и проверка, что writer больше не пишет в rejected target. Если команда умеет переключить alias вперёд, но не репетировала обратное движение, это ещё не recovery plan.

Автоматизируйте копии, но проверяйте restore вручную и на game day

Автоматизация должна создавать snapshot по расписанию, выгружать его, проверять checksum, применять retention и сообщать возраст последней успешной внешней копии. Алерт «job failed» слабее, чем метрика backup_age_seconds: cron может завершаться успешно, пока upload годами пишет в неверный bucket. Добавьте capacity alert на snapshots_path и target storage.

Раз в квартал или с частотой, соответствующей риску, проводите restore drill на изолированном сервере. Засекайте реальные RTO-фазы: доставка архива, распаковка, старт коллекции, data validation, application probes и cutover preparation. Эти числа принадлежат вашей системе; в статье честно нельзя обещать универсальные минуты.

Game day должен начинаться не с удаления production-коллекции, а с заранее описанного сценария. Выберите свежий snapshot, запретите target исходящий доступ к боевому приложению, выдайте временные credentials и назначьте наблюдателя, который не выполнял backup. Если только автор скрипта способен восстановить данные, runbook ещё не передаваем. После проверки удалите временные ключи и сам тестовый target согласно retention policy.

Проверьте и «неудобные» границы: истёкший API key, недоступный object storage, недостаток свободного места, несовместимую minor-версию и прерванную загрузку архива. Ожидаемый результат здесь — ранний, понятный отказ без частичного cutover. Для каждого сбоя запишите owner, безопасный способ очистки и точку, с которой процедуру можно повторить. Так резервная копия превращается в операционную способность, а не в файл с хорошим именем.

Для production RAG полезен manifest, связывающий snapshot с embedding model, revision corpus и схемой payload. Если база восстановилась, но embedding service уже перешёл на другую размерность или нормализацию, поиск либо упадёт, либо даст несопоставимые оценки. Храните model identity рядом с recovery evidence, даже если сами веса живут в другом registry. Команды с rag_probe выше — намеренный каркас локального тестового harness, а не штатная CLI Qdrant; реализуйте его через официальный Query API и правила своего приложения.

Добавьте один человеческий вопрос в итоговый отчёт: сможет ли дежурный, не участвовавший в настройке, восстановить поиск в допустимый RTO и объяснить, какие данные потеряны по RPO? Если ответ требует устных подсказок, следующий шаг — улучшить manifest и probes, а не увеличивать частоту snapshot. Проверяемость важнее количества архивов.

В журнале учений сохраняйте дату snapshot, фактическое время каждой фазы, объём перенесённых данных и причину любого ручного шага. На следующем game day ручных исключений должно стать меньше, иначе автоматизация только скрывает зависимость от конкретного инженера.

Итог простой: хороший Qdrant snapshot — это не файл, а доказанный путь от конкретной точки данных до корректного ответа RAG. Начните с одной коллекции, выполните изолированный restore, добавьте negative control и измерьте собственные RPO/RTO. Если для этого нужен отдельный NVMe budget, независимое хранилище и контролируемое окно переключения, тогда VPS или dedicated-сервер становятся частью проверяемого плана, а не магической страховкой.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Быстрый диагноз: когда виноват обратный маршрут

Главный признак асимметрии прост: SYN или HTTP-запрос приходит через один uplink, а Linux выбирает для ответа другой. Интернет допускает разные пути туда и обратно, но в реальном gateway между ними стоят reverse path validation, stateful firewall, NAT, балансировщик провайдера и антиспуфинг. Любой владелец состояния может отбросить пакет, хотя LLM API и GPU обслуживают соседние запросы.

Правильный default — не менять сервер и не выключать фильтрацию наугад. Сначала докажите четыре факта: на каком интерфейсе виден входящий пакет; какое решение принимает RPDB/FIB; проходит ли source validation; получает ли клиент ответ на новом соединении. Если один факт неизвестен, увеличение timeout или количества proxy workers лишь растягивает инцидент.

Типичный кейс: у gateway два публичных адреса, но в таблице main один preferred default route. Запрос к адресу uplink B приходит нормально, приложение отвечает с тем же source IP, однако маршрут до клиента выбирается через A. Ответ может потеряться у провайдера из-за source filtering или раньше — на локальном rp_filter. Симптом плавающий, потому что для части клиентов best path случайно совпадает.

Здесь мы не строим универсальную BGP-схему. Задача уже: локализовать owner асимметрии на multihomed Linux gateway, исправить policy routing минимальным изменением и проверить результат A/B/A canary. В Kubernetes сначала выясните, где живут адрес, NAT и route decision: на node, host-network proxy, внешнем балансировщике или в CNI dataplane.

Нарисуйте effective path, а не желаемую архитектуру

Возьмите одну проблемную сессию и разложите её по hop: client → provider edge → NIC gateway → nftables/conntrack → proxy → backend → обратный путь. Не подменяйте эту карту диаграммой из документации. После failover, миграции адреса или изменения CNI фактический owner route decision часто оказывается не там, где его ожидает дежурный.

Снимайте evidence одновременно на обоих внешних интерфейсах. Если входящий SYN виден на wan_b, а SYN-ACK уходит через wan_a, приложение уже оправдано: проблема ниже L7. Если SYN-ACK не появляется нигде, проверяйте локальную доставку, firewall, listen socket и source validation. Если оба направления видны на правильном интерфейсе, переносите точку наблюдения к провайдеру или клиенту.

Для LLM streaming есть ловушка. Уже установленный HTTP/2, WebSocket или SSE-сеанс может продолжать работать после смены маршрута, пока новые подключения падают. И наоборот, короткий health check зелёный, а длинный stream обрывается при state timeout. Baseline должен включать fresh connection, первый полезный байт, несколько фрагментов ответа и корректное закрытие.

Сохраните время, 5-tuple, входной интерфейс, source address и ожидаемый uplink. Полезно сверить материал о PROXY protocol и реальном IP клиента: адрес в L7-заголовке не доказывает peer, увиденный ядром.

ip -br -4 address
ip -4 rule show
ip -4 route show table all
ip -4 route get 192.0.2.44 from 203.0.113.10
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.wan_a.rp_filter
sysctl net.ipv4.conf.wan_b.rp_filter
tcpdump -ni wan_a 'host 192.0.2.44 and tcp port 443'
tcpdump -ni wan_b 'host 192.0.2.44 and tcp port 443'

Как Linux выбирает таблицу и next hop

Обычная таблица отвечает на вопрос «куда отправить пакет к destination». Policy routing добавляет предыдущий уровень: какую таблицу спросить. По ip-rule(8), RPDB последовательно проверяет rules; меньшее число priority означает более высокий приоритет. Селектор может учитывать source prefix, incoming interface, fwmark, протокол и порты.

По умолчанию Linux создаёт rules для local, main и default. Ошибка начинается, когда команда добавляет вторую таблицу, но забывает уникальный priority, connected route или явный source. ip route show table 200 может выглядеть убедительно, а реальный lookup до клиента всё равно заканчивается в main.

Используйте ip route get, а не только show. Руководство ip-route(8) поясняет: get разрешает маршрут так, как будто ядро отправляет пакет. Передавайте destination, source, mark и при необходимости iif. Так фраза «таблицы вроде правильные» превращается в проверяемое решение.

Для локально терминированного TLS простой шаблон — source-based rule: ответы с публичного адреса B ищут маршрут в таблице B. Для транзитного proxy или NAT этого мало: исходный source на обратном пакете другой, а ingress придётся помнить через mark и conntrack. Не смешивайте два кейса в одном change.

ip route replace 198.51.100.0/24 dev wan_a src 198.51.100.10 table 100
ip route replace default via 198.51.100.1 dev wan_a table 100
ip rule add priority 100 from 198.51.100.10/32 lookup 100

ip route replace 203.0.113.0/24 dev wan_b src 203.0.113.10 table 200
ip route replace default via 203.0.113.1 dev wan_b table 200
ip rule add priority 110 from 203.0.113.10/32 lookup 200

ip route get 192.0.2.44 from 203.0.113.10

rp_filter: защита от spoofing, которая раскрывает асимметрию

rp_filter проверяет достижимость source входящего IPv4-пакета. Strict mode 1 требует, чтобы входной интерфейс совпадал с лучшим обратным путём. Loose mode 2 достаточно маршрута к source через любой интерфейс. Значение 0 отключает проверку. Определения и правило выбора максимума между conf/all и conf/interface приведены в документации Linux kernel.

Отсюда частая ошибка: инженер выставляет wan_b.rp_filter=0, но all.rp_filter=1 оставляет effective strict mode. Вторая ошибка — глобально выключить проверку, получить зелёный тест и объявить проблему решённой. Так доказана связь с reverse-path validation, но одновременно расширена trust boundary.

RFC 3704 объясняет trade-off: strict RPF подходит для симметричного пути, а при неизбежной асимметрии применяют loose RPF или более полный фильтр. Loose mode не равноценен: он проверяет наличие маршрута, но не направление. Нужны ingress ACL, anti-spoofing у провайдера и наблюдаемость martian drops.

Сначала почините RPDB, если ответ должен возвращаться через тот же uplink. Переводите конкретный multihomed interface в loose mode лишь когда асимметрия задумана. Проверяли ли вы effective значение после загрузки sysctl-профилей дистрибутива?

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.wan_a.rp_filter
sysctl net.ipv4.conf.wan_b.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark
sysctl net.ipv4.conf.wan_a.src_valid_mark
sysctl net.ipv4.conf.wan_b.src_valid_mark
nstat -az | grep -E 'IPReversePathFilter|InNoRoutes|InDiscards'
journalctl -k --since '-15 min' | grep -Ei 'martian|reverse path'

fwmark и conntrack: как помнить входной uplink

Когда gateway пересылает трафик, source-based rule часто не выражает нужную политику. Требование иное: «ответ этой сессии должен уйти тем uplink, через который она пришла». Новый ingress flow получает ct mark, последующие пакеты восстанавливают её в packet mark, а ip rule fwmark выбирает таблицу. Mark переносит контекст между netfilter и RPDB.

Порядок hooks критичен. Mark восстанавливают до route lookup обратного пакета. Для локально созданного ответа nftables chain с hook output и type route позволяет повторить lookup; для forwarded traffic mark обычно восстанавливают в prerouting. Схема зависит от того, где заканчивается TLS и где применяется NAT.

src_valid_mark=1 включает fwmark в reverse-path lookup. Это нужно, когда одна mark-политика участвует в обоих направлениях и strict source validation должна видеть соответствующую таблицу. Не включайте параметр «на всякий случай»: сначала покажите ip route get ... mark ..., иначе появится ещё одна скрытая зависимость.

Conntrack хранит выбор пути, но не доказывает здоровье приложения. Запись ESTABLISHED не означает, что клиент получил токены. Для длинного stream проверяйте цепочку: mark восстановлена, route совпал, пакет ушёл, remote peer подтвердил получение, application SLO сохранён.

table inet route_policy {
  chain prerouting {
    type filter hook prerouting priority mangle; policy accept;
    iifname "wan_b" ct state new ct mark set 0x2
    ct mark != 0 meta mark set ct mark
  }
  chain output {
    type route hook output priority mangle; policy accept;
    ct mark != 0 meta mark set ct mark
  }
}
ip rule add priority 90 fwmark 0x2/0xff lookup 200
ip route get 192.0.2.44 from 203.0.113.10 mark 0x2

Kubernetes меняет owner, но не физику пути

В Kubernetes тот же симптом возникает на разных слоях. Service с externalTrafficPolicy: Local сохраняет client source IP и направляет внешний трафик только на nodes с local endpoint, но обратный маршрут всё равно выбирает node network stack или CNI. Host-network ingress, eBPF dataplane и iptables kube-proxy оставляют разный evidence.

Не начинайте с массового sysctl change. Выберите один адрес, одну node и один endpoint; зафиксируйте, где пакет входит в physical NIC, появляется ли в pod namespace и какой peer видит приложение. Сравните node с локальным endpoint и node без него как negative control. Разбор MetalLB, BGP и ECMP полезен уровнем выше: route advertisement не заменяет проверку обратного FIB.

Отдельно смотрите на CNI marks и rules. Dataplane может резервировать диапазоны fwmark, собственные RPDB priorities и tables. Случайный 0x2 из лаборатории способен конфликтовать с production policy. Экспортируйте state до canary, найдите владельца каждой mark и применяйте маску, согласованную с документацией вашей версии CNI.

Связь с AI здесь операционная. Один streaming request удерживает connection дольше REST-вызова; после route churn старые и новые sessions ведут себя по-разному. Проверка включает короткий запрос, streaming response и повтор после drain. Зелёный readiness probe не доказывает устойчивый inference path.

Evidence ladder: от пакета к ответу модели

Хороший runbook не прыгает от ошибки клиента к sysctl. Gate 1 — ingress: SYN пришёл на ожидаемый интерфейс. Gate 2 — policy: ip rule выбрала нужную таблицу, а ip route get вернул правильные device, gateway и source. Gate 3 — state: firewall, conntrack и source validation не уничтожили пакет. Gate 4 — outcome: новый клиент получил прикладной ответ.

Для каждого gate нужен negative control. Сравните здоровый клиентский prefix, второй публичный адрес или baseline через один uplink. Если оба пути ломаются одинаково, асимметрия не объясняет симптом. Если проблема следует за адресом B, но не за node, проверяйте policy и upstream. Если следует за node при любом адресе, owner, вероятно, локален.

Снимайте capture ближе к провалу. Захват на any удобен сначала, но скрывает направление и offload-агрегацию. Нужны отдельные interface captures с одинаковым filter. Материал о RSS, RPS и IRQ affinity поможет, если путь верен, а потери связаны с RX queue или CPU; это соседний класс причин.

Не добивайтесь симметрии любой ценой. Иногда requirement — принимать через любой edge и отвечать через preferred egress. Тогда проверяется contract: upstream принимает source prefix, stateful middleboxes видят обе стороны либо не зависят от состояния, а ingress filtering остаётся полным.

Canary и rollback без потери управления

Canary должен менять одного owner. Если одновременно добавить table, переключить rp_filter, обновить CNI и перенести VIP, зелёный результат не объяснит причину. Начните с временной rule для одного source address или fwmark, направьте synthetic traffic и сохраните baseline через старый путь.

Перед изменением запишите ip rule save, затронутые tables, nftables ruleset и sysctl. Но rollback — не просто удаление. После возврата повторите те же probes: route lookup, capture на interfaces, fresh application request. Если симптом не вернулся в A/B/A, связь вероятна, но не доказана.

Stop condition задайте заранее: connection errors, неожиданный egress, отсутствие client response, martian drops или конфликт mark. Не ждите массового SLO breach. Для streaming API canary проходит handshake, первый token, несколько chunks и normal close; не используйте production prompts с чувствительными данными.

После успеха закрепите configuration в network manager или automation. Ручные ip rule add исчезнут после reboot или пересоздания namespace. Проверяйте cold boot, failover каждого uplink и возврат primary path. Самый неприятный вариант — схема работает после ручного вмешательства, но пропадает при плановом обновлении.

Что мониторить после исправления

Маршрут может быть правильным во время canary и снова сломаться после DHCP renewal, cloud-init, network manager reload или смены BGP next hop. Проверяйте effective state, а не файл конфигурации. Собирайте snapshot rules и tables после каждого change event; сравнивайте priority, default route, preferred source и fwmark masks.

Полезны counters nftables rules, martian logs в ограниченном режиме, conntrack insert/drop, interface drops и доля новых соединений без application response. Метрики связывайте временем и адресом. Рост InDiscards без проблемного flow — слабое evidence; capture конкретного SYN и отсутствующего SYN-ACK сильнее.

На L7 отделяйте connect failure, TLS failure, time to first byte, межфрагментный timeout и premature close. Асимметричный path чаще поражает создание соединения или state transition, тогда как inference queue ухудшает time to first token при здоровом transport. Routing change не лечит backend queue, proxy buffering, retry storm или перегруженный GPU.

Проверяйте dual-stack раздельно. IPv4 rp_filter ничего не говорит о IPv6 path. Happy Eyeballs может маскировать отказ одной семьи fallback-ом; подробный подход есть в статье про IPv6 и Happy Eyeballs.

Когда нужен отдельный VPS или dedicated edge

Procurement default консервативен: не меняйте платформу, пока не доказан control gap. Ошибочный priority в RPDB одинаково ломает VM и dedicated server. Loose rp_filter без ingress policy не становится безопаснее от дополнительного CPU.

VPS подходит, когда нужен отдельный software edge с двумя логическими uplink, воспроизводимой ОС и независимым change window, а физический NIC ownership не критичен. Dedicated edge оправдан, когда команда контролирует NIC, queue/NUMA placement, driver/firmware, upstream sessions и failure domain. Managed load balancer снимает часть on-call, но оставляет меньше packet evidence.

Ценность — не обещание меньшей latency. Это возможность закрепить route tables, sysctl, firewall, telemetry и rollback за одним владельцем, проверить reboot/failover и сохранить baseline между узлами. Если workload упирается в inference queue, исправляйте scheduler или capacity. Если проблема в route ownership, отдельный edge сокращает число скрытых участников.

Общий контекст архитектуры есть в руководстве по Private AI API на своих серверах. Оно отвечает, где разместить gateway и observability; этот runbook закрывает более узкий вопрос — как доказать правильный обратный путь.

Итог: симметрия — не цель, цель — доказуемый path contract

Асимметричная маршрутизация сама по себе не ошибка. Ошибка появляется, когда Linux, firewall, provider filtering и приложение по-разному понимают допустимый путь. Исправление начинается с одного flow: ingress interface → RPDB/FIB → source validation и state → application outcome.

Для локального proxy часто достаточно source-based tables с явными priorities. Для forwarded/NAT path понадобится сохранение mark в conntrack и восстановление до route lookup. rp_filter выбирайте как часть threat model: strict для симметричного edge, loose только для доказанной асимметрии с компенсирующей ingress-защитой.

Следующий шаг — взять один проблемный клиентский адрес, выполнить baseline, провести A/B/A canary и записать owner каждого решения. Если control gap остаётся в общей инфраструктуре, перенос gateway на VPS или dedicated edge становится инженерным решением с понятной причиной, а не дорогой попыткой угадать.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

SYN flood или обычная перегрузка: начните с симптома, а не с названия атаки

У LLM API gateway есть неприятный режим отказа: GPU заняты не полностью, процесс inference жив, health check зелёный, но новые клиенты внезапно получают timeout ещё до первого HTTP-запроса. На графике приложения при этом может не быть всплеска 5xx — TCP-соединение просто не дошло до accept(). Команда видит сообщения о possible SYN flooding и сразу включает всё, что звучит как защита. Это понятная реакция, но она легко маскирует настоящую причину.

Одинаковый пользовательский симптом дают как минимум четыре разных механизма: переполненный SYN backlog, медленный accept loop, исчерпанный conntrack, перегруженный сетевой CPU. Настоящий spoofed SYN flood — только один вариант. Поэтому рабочий verdict должен звучать не «нас атакуют», а точнее: «на таком-то listener растут half-open запросы, ядро отправляет cookies, а доля успешных fresh connections падает».

Для LLM-сервиса это особенно важно. Длинные streaming-соединения могут оставаться здоровыми, пока новые запросы уже не проходят handshake. Средняя загрузка GPU и latency существующих сессий создают false green. Проверять нужно новый connection path: клиент → edge → handshake → accept → TLS/HTTP → очередь модели → первый токен.

Граница безопасности проста: далее речь только о диагностике и защите собственной инфраструктуры. Генерировать атакующий трафик из интернета не требуется; достаточно контролируемого canary из разрешённой сети и сохранённого baseline.

Две очереди Linux TCP, которые нельзя смешивать

После входящего SYN ядро создаёт request socket и хранит незавершённый handshake в SYN backlog. Его верхняя граница связана с net.ipv4.tcp_max_syn_backlog и действует на listener. После финального ACK полностью установленное соединение попадает в accept queue и ждёт, пока процесс вызовет accept(). Аргумент listen(backlog) ограничивается net.core.somaxconn; в Linux 5.4 значение somaxconn по умолчанию увеличили с 128 до 4096, но приложение всё равно может запросить меньший backlog.

Разделение принципиально. Рост SYN_RECV при стабильной accept queue указывает на проблему handshake или входного потока. Рост ListenOverflows/ListenDrops при занятых workers больше похож на задержку userspace accept. Простое увеличение обоих лимитов меняет ёмкость буфера, но не ускоряет CPU, не чинит single listener и не освобождает conntrack.

Представьте турникет и зал ожидания. SYN backlog — люди, которые ещё подтверждают билет у турникета. Accept queue — уже проверенные посетители, которых не успевает забрать сотрудник. Расширить зал полезно при коротком всплеске, но бесполезно, если сотрудник остановился.

Официальные man-pages для listen(2) отдельно фиксируют эту семантику, а документация ядра по IP sysctl предупреждает: syncookies не предназначены для лечения легальной перегрузки.

Evidence bundle: что собрать до первого sysctl

До изменения параметров зафиксируйте одну и ту же временную точку на edge и в приложении. Минимальный bundle включает значения sysctl, состояние listener, количество SYN_RECV, дельты TcpExt counters, packet capture с небольшим snaplen и результат свежего клиентского запроса. Снимок нужен в baseline, во время симптома и после восстановления.

TcpExtSyncookiesSent показывает отправленные cookies, SyncookiesRecv — ответы клиентов на них, а SyncookiesFailed — невалидное декодирование MSS. Сами по себе cookies не доказывают атаку: они доказывают, что конкретный listener дошёл до fallback. ListenOverflows и ListenDrops относятся к проблемам при помещении установленного соединения в очередь; их нужно читать как дельту, а не как накопившееся за месяцы число.

Команда ниже ничего не меняет. Запускайте её в effective network namespace gateway: host, container или pod могут видеть разные counters. Если nftables/conntrack стоят на отдельном edge, снимайте evidence и там, и на backend.

date -Is
uname -r
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn
ss -lntp
ss -n state syn-recv '( sport = :443 )'
nstat -az | grep -E 'TcpExt(Syncookies|Listen|TCPReqQFull|TCPSynRetrans)'
timeout 20 tcpdump -ni any -s 128 -w /tmp/syn-evidence.pcap 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'

Добавьте application probe: DNS lookup, TCP connect, TLS handshake, HTTP status и time to first token должны иметь отдельные timestamps. Иначе улучшение packet counters можно ошибочно принять за восстановление LLM API.

SYN cookies: аварийный fallback с ограниченной областью действия

При net.ipv4.tcp_syncookies=1 Linux начинает отправлять SYN cookies, когда SYN backlog переполнен, если ядро собрано с CONFIG_SYN_COOKIES. Вместо хранения полноценного request state сервер кодирует часть параметров в sequence number SYN-ACK и восстанавливает состояние после корректного ACK. Это позволяет пережить поток half-open соединений с меньшим расходом памяти на backlog.

Но cookie не создаёт дополнительный CPU, не ускоряет accept loop и не защищает L7. Документация ядра называет механизм fallback facility и прямо запрещает использовать его как tuning для легальной нагрузки. В старых реализациях cookies ограничивали TCP options; современные ядра умеют больше, но выбор MSS и восстановление расширений всё равно следует проверять на вашей версии и реальном клиентском профиле.

Значение 2 включает безусловную генерацию cookies и предназначено для тестирования эффекта. Это не production default. Если включить его постоянно, можно потерять сигнал о реальном состоянии backlog и принять ухудшение path за норму.

Практический критерий: cookies полезны, когда входящий SYN rate временно выше способности listener хранить незавершённые handshake, а established path после ACK остаётся здоровым. Если одновременно растут ListenDrops, CPU softirq, TLS latency и queue модели, проблема шире.

SYNPROXY в nftables: вынести проверку handshake на edge

SYNPROXY отвечает на initial SYN в netfilter context и пропускает соединение к локальному listener или backend только после корректного ACK. Backend не хранит half-open state для каждого неподтверждённого клиента. В отличие от обычных cookies на endpoint, здесь граница контроля переносится на edge. Это полезно, когда вы действительно хотите изолировать дорогой L7 gateway и его conntrack/accept path.

Цена — новая stateful dependency. SYNPROXY требует connection tracking, переводит sequence numbers и должен объявлять клиенту параметры, совместимые с backend: MSS, window scale, SACK и timestamps. Ошибка в MSS способна создать PMTU-подобные black holes; неверный wscale — странную производительность уже после успешного handshake. Поэтому параметры не угадывают. Их снимают с SYN-ACK backend из внешней тестовой точки.

Актуальный manpage nftables указывает, что statement synproxy сам завершает обработку как drop-verdict с побочным эффектом, а sequence translation требует conntrack. Это влияет на порядок chains и приоритеты: соседний accept в другой base chain не должен случайно обходить задуманный path.

Ниже — лабораторный каркас, не готовая политика. Адреса, интерфейсы, hook priority и backend options должны соответствовать вашей топологии. Загружайте ruleset через nft -c и out-of-band доступ.

table inet llm_synproxy {
  chain raw_prerouting {
    type filter hook prerouting priority raw; policy accept;
    tcp dport 443 tcp flags syn notrack
  }

  chain input {
    type filter hook input priority filter; policy accept;
    ct state invalid,untracked tcp dport 443 synproxy mss 1460 wscale 7 timestamp sack-perm
    ct state invalid drop
  }
}

nft -c -f synproxy-lab.nft
nft list ruleset
conntrack -S
nstat -az | grep -E 'TcpExt(Syncookies|Listen|TCPReqQFull)'

Backlog, cookies или SYNPROXY: выбирайте по owner проблемы

Увеличение tcp_max_syn_backlog оправдано, когда всплеск легальный, короткий, память рассчитана, а listener после него быстро разгребает очередь. Один request socket SYN_RECV расходует память; ядро документирует ориентир около 304 байт, но реальный бюджет включает slab, conntrack, packet queues и namespace overhead. Лимит нельзя выбирать из чужого рецепта.

Cookies оставляют owner на backend kernel и дают аварийный запас без предварительного state на каждый SYN. SYNPROXY добавляет отдельный edge owner и имеет смысл, когда вы готовы владеть conntrack capacity, nftables lifecycle, параметрами TCP options, observability и failover. Managed L4 DDoS/LB может быть проще, если команде не нужен собственный stateful control plane.

Default для buyer decision: не менять платформу до доказанного handshake bottleneck. Dedicated edge ценен воспроизводимыми NIC queues, kernel/nftables version, отдельным failure domain и change window. Но новое железо не исправит медленный accept loop, retry storm, неверный MSS, proxy buffering или очередь GPU inference.

Этот принцип дополняет материалы KingServers про SO_REUSEPORT и accept-очереди, TLS handshake storm и RSS/RPS/IRQ affinity: каждый из них отвечает за свой участок path.

Canary без самообмана: A/B/A на свежих соединениях

Rollout начинайте с одного edge IP, одного listener или небольшой доли разрешённого synthetic traffic. Baseline A должен быть снят теми же probes, что и canary B: SYN/SYN-ACK/ACK, TcpExt deltas, conntrack, accept counters, TLS success, HTTP status, TTFT и доля завершённых streams. Сравнение средних за час размоет короткий отказ.

Healthy negative control нужен обязательно. Отправьте обычный запрос без flood-like burst через неизменённый path. Если после SYNPROXY растёт TCP connect time и одновременно падает negotiated window у здоровых клиентов, это regression, даже если backend SYN_RECV уменьшился. Другой negative control — прямой закрытый backend path из management сети: он помогает отделить edge от приложения.

После положительного B вернитесь к A. Если симптом не возвращается, причинность не доказана: возможно, закончился внешний burst или освободилась queue модели. Затем повторите B. Такой A/B/A кажется медленным, зато спасает от ложного успеха во время инцидента.

Перед изменением сохраните atomic ruleset, sysctl snapshot и команду rollback. Не удаляйте старый path раньше, чем established streaming sessions корректно drain. Для LLM API обрыв через двадцать минут после «успешного» handshake заметнее клиенту, чем лишние миллисекунды canary.

Наблюдаемость: связать packets, kernel и первый токен

Один counter не отвечает на вопрос «пользователь получил ответ?». Постройте четыре независимых evidence gate. Packet gate показывает входящие SYN, ответы SYN-ACK и финальные ACK. Kernel gate — SYN_RECV, cookies, listen drops, conntrack и softirq. Application gate — accept rate, TLS/HTTP errors, active streams и queueing gateway. LLM gate — admitted requests, очередь scheduler, TTFT и успешное завершение.

Алерт на абсолютный SyncookiesSent будет шуметь после перезагрузки или не шуметь месяцами из-за накопленного значения. Используйте rate/delta и привязывайте его к fresh connection success. То же относится к ListenDrops. Для нескольких listeners собирайте socket-level backlog через ss и данные процесса, иначе системный total скроет один горячий порт.

Отдельно маркируйте место TLS termination. Если SYNPROXY стоит перед внешним L4 load balancer, backend видит соединения от LB, а не исходных клиентов; packet и application identity расходятся. Если TLS termination на том же edge, CPU handshake storm способен стать следующим bottleneck сразу после успешного SYN mitigation.

Не смешивайте этот runbook с L7 abuse. Rate limits и quotas защищают дорогие запросы после HTTP parsing; SYNPROXY не знает tenant, token budget или стоимость prompt. Слой должен отвечать только за доказанный риск.

Типичные ошибки, которые превращают защиту в новый инцидент

Первая ошибка — считать строку SYN flood в kernel log достаточным доказательством злонамеренного трафика. Легальный reconnect storm после DNS failover выглядит похоже. Вторая — поднять tcp_max_syn_backlog без memory budget и наблюдения за softirq: потери просто смещаются дальше по path.

Третья — копировать MSS 1460 и wscale 7 из примера. Tunnel, VLAN, IPv6 и provider edge меняют effective MTU; backend может объявлять другие options. Четвёртая — включить SYNPROXY на одном направлении асимметричного path. Stateful translation требует видеть нужные пакеты соединения; ECMP или policy routing могут разрушить предположение.

Пятая — забыть про persistence. Ручной nft add rule исчезает после reboot или конфликтует с конфиг-менеджментом. Ruleset должен иметь owner, version, review, atomic deploy и проверенный restore. Материал про nftables sets полезен для организации изменяемых списков, но sets сами по себе не заменяют handshake validation.

Шестая — объявить успех по снижению SYN_RECV. Если TTFT ухудшился, established sessions рвутся, а retry rate вырос, вы лишь перенесли bottleneck. В production итог всегда application outcome на свежем соединении и после повторного запроса.

Production checklist и граница инфраструктурного решения

Перед rollout назначьте владельцев: сеть отвечает за ingress и symmetric path, platform team — за nftables/conntrack lifecycle, команда gateway — за listener и TLS, inference team — за admission и очередь модели. Один человек не обязан владеть всем, но incident commander должен видеть карту owner’ов.

Зафиксируйте stop conditions заранее: рост connect errors здорового canary, потеря management access, conntrack pressure, нарушение MSS/PMTU, рост CPU edge или деградация TTFT. Автоматический rollback допустим только по устойчивому сигналу; одиночный packet loss не должен запускать oscillation.

Когда доказано, что bottleneck именно на shared network edge и команде нужен полный контроль kernel, NIC, conntrack и change window, отдельный VPS или выделенный gateway становится рациональным. Сравнивайте варианты по failure domain, доступу к packet capture, фиксированной версии kernel, capacity headroom и времени восстановления. Обещание «будет быстрее» без canary ничего не стоит.

Если bottleneck в accept loop, сначала исправьте workers, SO_REUSEPORT и drain. Если причина в TLS, используйте resumption/keepalive и управляйте reconnect. Если очередь на GPU, SYNPROXY только сделает путь до перегруженной модели аккуратнее. Инфраструктура должна закрывать доказанный control gap, а не заменять расследование.

Итог: защищайте handshake, но измеряйте сервис

SYN cookies и SYNPROXY решают разные задачи. Cookies — аварийный механизм endpoint kernel при переполнении SYN backlog. SYNPROXY — перенос проверки handshake на stateful edge с собственной ценой владения. Ни один вариант не лечит медленный accept, TLS storm, retry loop или очередь inference.

Начните с evidence bundle: packet trace, TcpExt deltas, состояние двух очередей и fresh-connection probe до первого токена. Затем меняйте одного owner через A/B/A canary и повторяйте те же проверки после rollback. Такой порядок немного строже привычного «поднять sysctl», зато оставляет команде доказательство, которое переживёт следующий инцидент.

Практический следующий шаг — сегодня снять baseline на одном production listener без изменений: sysctl, ss, nstat и контролируемый запрос. Если обнаружится реальный control gap на edge, его уже можно обсуждать как отдельный VPS, dedicated gateway или managed L4-защиту с понятным owner и rollback.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Когда SPIFFE/SPIRE действительно нужен LLM-платформе

Короткий вердикт: SPIFFE/SPIRE стоит внедрять, когда обычной сетевой доступности уже недостаточно и вам нужно доказуемо отвечать на вопрос «какой workload вызвал модель». Это особенно заметно в Kubernetes-кластере, где gateway, RAG-оркестратор, vector database и inference-сервис масштабируются независимо, а IP-адрес пода живёт меньше, чем сертификат, выписанный вручную.

SPIFFE задаёт формат идентичности и API получения удостоверений, а SPIRE реализует control plane: аттестует узлы и процессы, сопоставляет selectors с registration entries и выдаёт короткоживущие SVID. В актуальном на дату запуска релизном ряду SPIRE последней стабильной версией является 1.15.3; перед production-rollout всё равно сверяйте release notes и совместимость chart с вашей версией Kubernetes. Официальный Kubernetes quickstart проверен авторами документации на версиях 1.29–1.34, поэтому за пределами этого диапазона нужен отдельный compatibility test.

Не путайте это с «включить service mesh». Mesh может потреблять workload identity, но не заменяет модель доверия. У KingServers уже есть отдельный обзор service mesh; здесь задача уже: построить evidence chain от Kubernetes ServiceAccount до успешного LLM-запроса и безопасно откатить изменение.

Есть и честный disqualifier. Если у вас один сервис, один namespace и нет требования различать вызывающие workload, SPIRE добавит control plane, state, мониторинг и on-call обязанности без соразмерной пользы. Сначала зафиксируйте threat model и owner, затем выбирайте технологию.

Trust domain, SPIFFE ID и SVID: что именно мы доверяем

Trust domain — административная граница доверия, а не красивый DNS-суффикс. Идентификатор вида spiffe://ai.example/ns/inference/sa/model-gateway должен выражать стабильную роль workload, а не имя конкретного пода. Тогда replica replacement не меняет policy, но чужой ServiceAccount не получает тот же доступ автоматически.

X509-SVID содержит SPIFFE ID в URI SAN и проверяется по bundle соответствующего trust domain. Важно сохранить пару «trust domain → bundle»: объединять все корни в один безымянный пул опасно, потому что один домен тогда может начать выдавать идентичности за другой. Это требование прямо закреплено в SPIFFE Trust Domain and Bundle.

Для LLM-платформы удобно разделить роли: gateway вызывает inference, RAG worker читает vector storage, telemetry collector принимает метрики, batch evaluator ходит в отдельный endpoint. Не выдавайте одну универсальную identity всему namespace. Реальный сбой здесь выглядит прозаично: новый debug-под запускают под общим ServiceAccount, и он неожиданно получает доступ к model endpoint. Negative control с «чужим» ServiceAccount должен закончиться отказом mTLS или authorization policy, а не HTTP 200.

Архитектура SPIRE в Kubernetes без скрытой магии

Базовая топология состоит из SPIRE Server, SPIRE Agent на каждом worker node и способа доставки Workload API workload. Server хранит registration entries и подписывает SVID; Agent проходит node attestation, получает разрешённые entries, а затем локально аттестует вызывающий процесс. Согласно SPIRE Concepts, Agent определяет PID клиента локального Unix-сокета и через workload attestor получает Kubernetes selectors, включая namespace и ServiceAccount.

Для production Kubernetes официальный hardened Helm stack включает Server, Agent, Controller Manager, OIDC Discovery Provider и CSI Driver. Не включайте всё машинально: JWT-SVID и OIDC bridge нужны не каждому. Зафиксируйте владельца datastore, резервное копирование Server state, anti-affinity и поведение при недоступности signer. Agent обычно DaemonSet, но его доступ к hostPath socket и kubelet API — часть security boundary, а не техническая мелочь.

Сначала разверните control plane без перевода application traffic. Проверьте health, readiness, server quorum, node attestation и наличие Agent на нужных GPU-узлах. Если GPU node tainted, DaemonSet без подходящего toleration оставит именно критичные inference-поды без Workload API. Знакомо? Control plane формально зелёный, а нужный узел выпал из identity coverage.

kubectl -n spire get pods -o wide
kubectl -n spire get statefulset,daemonset
kubectl -n spire logs statefulset/spire-server --tail=100
kubectl -n spire get pods -l app.kubernetes.io/name=spire-agent   -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,READY:.status.containerStatuses[0].ready

Registration entries и attestation: привязываем identity к workload

Registration entry связывает SPIFFE ID, parent ID агента и selectors. Для Kubernetes минимальная полезная пара selectors — namespace и ServiceAccount. Добавлять pod label можно, но тогда жизненный цикл label становится частью security policy: кто имеет право его поставить, проверяется ли admission policy, что случится при rename?

Не создавайте entry по принципу «пока заработало». Сначала выпишите таблицу: caller, callee, разрешённый метод или endpoint, ожидаемый SPIFFE ID, selectors, owner. Для model gateway это может быть только ns:ai-serving и sa:model-gateway. RAG worker получает другую identity, даже если оба вызывают один inference endpoint. Так authorization layer сможет различать online traffic и batch.

Kubernetes projected ServiceAccount token полезен для attestation: он имеет audience и срок действия, а kubelet обновляет его. Возможность projection стабильна с Kubernetes 1.20; приложение или интеграция должны перечитывать ротируемый token. Документация Kubernetes подчёркивает, что token bound к Pod/ServiceAccount и становится недействительным после удаления объекта. Это лучше долгоживущего Secret, но audience и issuer всё равно надо проверять.

kubectl exec -n spire statefulset/spire-server --   /opt/spire/bin/spire-server entry create   -spiffeID spiffe://ai.example/ns/ai-serving/sa/model-gateway   -parentID spiffe://ai.example/spire/agent/k8s_psat/cluster-a/REPLACE_NODE_UID   -selector k8s:ns:ai-serving   -selector k8s:sa:model-gateway

kubectl exec -n spire statefulset/spire-server --   /opt/spire/bin/spire-server entry show

Workload API, CSI и SDS: как доставить SVID приложению

Есть три типовых потребителя. SPIFFE-aware приложение подключается к Workload API и получает поток X509-SVID плюс bundles. Proxy вроде Envoy может получать секреты через SDS. Legacy-приложение иногда требует файлы сертификата и ключа; для него используют CSI или вспомогательный процесс, но нужно доказать корректную reload-семантику.

SPIFFE Workload API стримит обновления, поэтому правильный клиент меняет credential без рестарта. Это важнее короткого TTL: если библиотека прочитала сертификат один раз при старте, ротация превратится в отложенный outage. Для Envoy SDS позволяет принять новый secret без redeploy, но listener или upstream cluster зависит от доступности SDS и валидности ответа. Наблюдайте не только expiration SVID, но и последнее успешное обновление.

CSI socket нельзя монтировать во все pod «для удобства». Доступ к Workload API даёт возможность запросить identity, разрешённую selectors конкретного процесса; ошибка в isolation или selectors расширяет blast radius. В threat model отдельно рассмотрите privileged pod, hostPID и доступ к hostPath.

mTLS для LLM inference: authentication ещё не authorization

Успешная проверка X509-SVID отвечает на вопрос «кто подключился», но не «что ему разрешено». После TLS handshake gateway должен сопоставить SPIFFE ID с policy: model-gateway может вызвать streaming inference, evaluator — batch endpoint, telemetry collector — только metrics. Иначе вы замените общий сертификат общим allow rule.

Для streaming LLM особенно важно не смешивать identity rollout с timeout, retry и buffering. Длинное соединение может продолжать жить на старом SVID до закрытия, хотя новый уже выдан. Проверяйте отдельно новые и существующие connections. Материал про HTTP/2 GOAWAY и gRPC keepalive помогает отделить graceful drain от identity failure.

Application gate должен измерять не только TLS. Отправьте небольшой детерминированный inference-запрос, подтвердите first token и завершение stream, а затем повторите его с чужой identity. Если оба проходят, криптография работает, но authorization нет. Если оба падают, сначала смотрите bundle, SAN и time sync, а не GPU utilization.

openssl x509 -in /run/spiffe/svid.pem -noout   -subject -issuer -dates -ext subjectAltName

openssl verify -CAfile /run/spiffe/bundle.pem /run/spiffe/svid.pem

# Выполняйте из canary workload с ожидаемым ServiceAccount
curl --cert /run/spiffe/svid.pem --key /run/spiffe/svid-key.pem   --cacert /run/spiffe/bundle.pem   https://model-gateway.ai-serving.svc/v1/models

Четыре evidence gate: от узла до ответа модели

Чтобы не получить false green, разделите проверку на четыре независимых gate. Первый — node attestation: Agent действительно допущен нужным Server и виден на конкретном GPU-узле. Второй — workload selectors: фактический PID/Pod сопоставлен ожидаемой entry. Третий — credential path: клиент получил SVID и bundle, peer проверил SPIFFE ID, ротация дошла без рестарта. Четвёртый — application outcome: авторизованный запрос завершился, неавторизованный был отклонён, latency и error rate остались в бюджете.

Не переносите доказательство между слоями. Наличие SVID на диске не доказывает, что Envoy использует его. Успешный handshake не доказывает, что policy проверила нужный URI SAN. HTTP 200 от health endpoint не доказывает, что streaming route видит GPU backend. Для каждого gate сохраните команду, timestamp, node, pod UID и ожидаемый результат.

NetworkPolicy остаётся отдельным слоем. SPIFFE identity не запрещает пакет, а policy сети не удостоверяет вызывающий процесс. Практический default-deny и negative controls разобраны в материале про Kubernetes NetworkPolicy для LLM inference. Эти механизмы дополняют друг друга, но имеют разных owners и разные rollback.

date -u
kubectl get pod -n ai-serving -l app=model-gateway -o wide
kubectl get pod -n ai-serving -l app=model-gateway   -o jsonpath='{range .items[*]}{.metadata.uid}{" "}{.spec.serviceAccountName}{"\n"}{end}'
kubectl -n spire logs daemonset/spire-agent --since=10m |   grep -E 'attest|selector|SVID|error'
kubectl -n ai-serving logs deploy/model-gateway --since=10m |   grep -E 'spiffe|tls|denied|upstream'

Canary и rollback: меняем одного owner за раз

Начните с одной пары caller–callee и одного route. Baseline должен включать успешный запрос штатного клиента, отказ negative-control клиента, текущий error rate и поведение долгого stream. Затем включите SVID только для canary replica или отдельного hostname, не меняя одновременно retries, proxy version и NetworkPolicy.

A/B/A полезнее красивого dashboard. В A сохраняется старый путь. В B canary использует SPIFFE identity и выдаёт ожидаемый application outcome. В финальном A вы возвращаете старый credential path и повторяете те же probes. Если симптом не возвращается или исчезает несимметрично, причинность не доказана. После этого снова включайте B и расширяйте долю.

Rollback должен быть выполним, пока команда уставшая: вернуть route weight, восстановить предыдущую TLS policy, проверить старый Secret и удалить canary entry. Но не держите общий static certificate бесконечно «на всякий случай» — назначьте срок удаления. Для каждой фазы запишите stop condition: рост handshake failures, недоступность Workload API, SVID ближе к expiry без update или ухудшение application SLO.

Federation между кластерами: когда один trust domain уже мешает

Federation нужна, когда два административно независимых trust domain должны аутентифицировать workload друг друга. Например, edge gateway в одном кластере вызывает GPU inference в другом, а команды независимо управляют signer, entries и release windows. Сливать их в один root проще только до первого incident review: граница ответственности исчезает.

SPIFFE Federation обменивает bundles через bundle endpoints. Отношение одностороннее; для взаимной аутентификации требуются отношения в обе стороны. Клиент обязан связывать endpoint, profile и trust domain, а новые signing keys публиковать заранее. Спецификация рекомендует дать получателям несколько refresh intervals до начала выдачи SVID новым ключом.

Не начинайте с federation. Сначала докажите локальный identity path в каждом кластере, затем bundle retrieval, затем server authentication, затем cross-domain application request. Negative control — SPIFFE ID из третьего или неразрешённого domain. Long chains доверия усложняют анализ компрометации; официальный SPIFFE Federation spec прямо предупреждает об этом.

Эксплуатация: метрики, ротация ключей и типовые отказы

У SPIRE есть собственный SLO. Следите за успешностью node attestation, числом активных agents, ошибками Workload API, возрастом последнего SVID update, временем до expiry, состоянием datastore и refresh federated bundles. Метрика «Server pod Ready» не ловит Agent, который потерял доступ к kubelet или не может обновить entry cache.

Отдельный failure drill — ротация signing key. Сначала новый ключ появляется в bundle, затем начинается выдача SVID, подписанных им, и только после истечения старых SVID прежний ключ удаляется. Если убрать ключ рано, вы получите выборочные handshake failures: новые клиенты работают, старые long-lived процессы падают после reconnect. Time sync на nodes и proxies тоже входит в identity SLO.

DNS остаётся bootstrap-зависимостью для Server, federation endpoint и application peers. Не диагностируйте certificate error как DNS и наоборот. Для кластерного кэша и node-dependent path пригодится runbook про NodeLocal DNSCache.

Capacity вопрос появляется позже. Выделенные узлы или серверы дают больше контроля над NIC, kernel, HSM/KMS integration, datastore latency и maintenance window. Но новое железо не исправит широкий selector, общий ServiceAccount, неверный trust bundle или приложение, которое не перечитывает credential. Инфраструктурный апгрейд оправдан после доказанного resource или control gap, а не вместо него.

Практическая матрица выбора и план внедрения

Выбирайте SPIFFE-aware library, когда вы контролируете код и хотите проверять peer ID непосредственно в приложении. Выбирайте Envoy/SDS, когда протокол уже проходит через proxy и команда готова владеть его lifecycle. CSI или файловый адаптер — переходный вариант для legacy, но он переносит риск в permissions и reload. Service mesh уместен, если помимо identity нужны routing, telemetry и policy на большом числе сервисов; для пары сервисов он может быть избыточен.

План на первый sprint: описать trust domain и пять–десять SPIFFE ID, развернуть Server/Agent без влияния на traffic, создать одну entry, получить SVID, проверить authorized и unauthorized handshake, провести rotation drill, затем canary application request. Только после этого расширяйте охват. Для общей архитектуры serving можно свериться с материалом про Kubernetes для AI inference, но identity policy держите отдельным артефактом.

Итог простой: ценность SPIFFE/SPIRE не в том, что сертификаты становятся «автоматическими». Ценность в проверяемой цепочке node → selectors → SVID → peer policy → результат LLM-запроса. Начните с одной связи, сохраните negative control и симметричный rollback. Когда этот путь воспроизводится дежурным инженером без помощи автора схемы, у вас появилась workload identity, а не ещё один сертификатный сервис.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Когда «зависший» LLM-стрим остаётся живым TCP-соединением

Клиент перестал получать токены, но API gateway всё ещё держит соединение, GPU продолжает считать, а в логах нет ни FIN, ни RST. Через несколько минут пользователь уже повторил запрос, очередь стала длиннее, а старый inference всё ещё расходует память и вычислительное время. Это типичный разрыв между состоянием приложения и состоянием TCP: для ядра сокет может оставаться ESTABLISHED, хотя end-to-end путь фактически исчез.

Угол этой статьи узкий: мы разбираем TCP_USER_TIMEOUT в Linux и только тот случай, когда отправленные данные не подтверждаются ACK либо не могут быть переданы из-за нулевого окна. Это не новая версия материала про HTTP/2 GOAWAY и gRPC keepalive, не настройка очередей из статьи про BBR и fq и не общий proxy tuning. Наша задача — доказать half-open path, выбрать границу fail-fast и проверить её canary без обещаний «ускорить LLM».

Сразу обозначим disqualifier. Если сокет ничего не отправляет, unacked не растёт, а backend просто долго формирует первый токен, TCP_USER_TIMEOUT не поможет. То же верно, когда проблему создают buffering, application deadline, исчерпанная GPU-очередь или ошибочные retries. Сначала нужна атрибуция, потом настройка.

Характерный пример: пользователь едет между сетями, NAT-состояние исчезает, но gateway уже отправил очередную порцию SSE-данных. Backend не знает, что клиент потерян; TCP повторяет сегменты, а бизнес-таймер в клиенте запускает новый запрос. Без связи между socket tuple, request_id и generation_id команда видит только рост нагрузки и ошибочно масштабирует GPU. Поэтому первичная цель — вернуть причинную цепочку, а не подобрать «магическое» число миллисекунд.

Четыре таймера, которые нельзя смешивать

У production-запроса как минимум четыре разных часовщика. Application deadline отвечает за бизнес-границу: сколько пользователь готов ждать полный ответ или следующий токен. Proxy read timeout контролирует паузу между операциями чтения. TCP keepalive проверяет давно бездействующий путь специальными пробами. TCP_USER_TIMEOUT ограничивает время, в течение которого уже переданные данные остаются неподтверждёнными или застревают при zero window.

Согласно Linux tcp(7), значение задаётся в миллисекундах, действует в синхронизированных состояниях TCP и при истечении возвращает приложению ETIMEDOUT. Параметр не меняет момент retransmission и не определяет отправку keepalive-проб. Если одновременно включён SO_KEEPALIVE, именно TCP_USER_TIMEOUT определяет, когда закрыть соединение после keepalive failure.

У NGINX proxy_read_timeout измеряется между двумя последовательными чтениями от upstream, а не для всего ответа. Поэтому поток с редкими токенами может упасть по read timeout при полностью здоровом TCP, а поток с unacked данными может долго оставаться живым несмотря на щедрый proxy timeout. В runbook эти сигналы должны храниться отдельно.

Практически полезно назначить owner каждому таймеру. Product/application owner отвечает за deadline и семантику отмены; platform owner — за proxy timeouts, retries и connection pool; network owner — за путь и packet evidence; runtime owner — за создание сокета и effective options. Если один и тот же параметр меняют две команды, rollback становится недостоверным. Карта ownership должна быть частью change request и incident timeline.

Что именно делает TCP_USER_TIMEOUT в Linux

Локальный socket option принимает беззнаковое число миллисекунд. Ноль означает использование системного поведения. Опция появилась в Linux 2.6.37 и может устанавливаться в любой момент жизни соединения, хотя влияет только на синхронизированные состояния. Если задать её на listening socket, принятые через accept() сокеты наследуют значение — это удобно для gateway, но увеличивает blast radius ошибки.

Важно не путать локальный socket option с TCP User Timeout Option из RFC 5482. RFC описывает возможность сообщить peer рекомендуемый timeout, но это не обязательное двустороннее соглашение. В Linux практическая ценность setsockopt(TCP_USER_TIMEOUT) прежде всего локальная: процесс сам ограничивает, сколько готов держать неподтверждённые данные.

Слишком короткое окно опасно на высокозадержанных, мобильных и временно перегруженных путях: ACK может прийти позже выбранной границы, и здоровое соединение будет оборвано. Слишком длинное окно сохраняет состояние и занятый inference дольше, чем полезно пользователю. Поэтому значение выводят из пользовательского deadline, измеренного RTT/RTO, допустимого recovery window и retry budget, а не копируют из чужого конфигурационного файла.

Нулевая receive window — отдельный важный сценарий. Peer может оставаться доступным и подтверждать пакеты, но сообщить, что временно не принимает новые данные; приложение на отправителе будет накапливать buffered data. Linux учитывает и эту ситуацию. Поэтому packet trace нужно читать вместе с window advertisements: отсутствие прогресса не всегда означает потерю маршрута. Слишком агрессивный timeout способен оборвать медленного, но исправного потребителя.

Системный default тоже важно понимать, но не подменять им измерение. tcp_retries2 задаёт число retransmission-моментов для живого соединения, причём effective wall-clock зависит от RTO и backoff; документация ядра прямо предупреждает о связи с tcp_rto_max_ms. Поэтому пересчёт «15 ретраев равно столько-то минут» нельзя переносить на каждый production path. Per-socket timeout выражает бизнес-граничное время точнее, но только для outstanding data и только в реализации, которая действительно ставит option.

Версионный статус здесь стабилен: TCP_USER_TIMEOUT существует в Linux много лет, однако поддержка в языковом runtime, reverse proxy или service mesh различается. Проверяйте документацию и effective state конкретной сборки. Наличие похожего поля в конфигурации не гарантирует, что оно применяется к нужному плечу соединения; source code, getsockopt, eBPF trace или controlled failure дают более сильное доказательство.

import socket

def connect_with_user_timeout(host: str, port: int, timeout_ms: int):
    sock = socket.create_connection((host, port), timeout=5)
    sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_USER_TIMEOUT, timeout_ms)
    actual = sock.getsockopt(socket.IPPROTO_TCP, socket.TCP_USER_TIMEOUT)
    if actual != timeout_ms:
        sock.close()
        raise RuntimeError(f"TCP_USER_TIMEOUT mismatch: {actual}")
    return sock

Evidence gate: доказать unacked path, а не гадать по latency

Начните с конкретного соединения и stable identity процесса. Нужны namespace, PID, локальный и удалённый адрес, transport protocol и роль: client-facing socket или upstream к inference backend. Снимок «на узле много retransmissions» слишком широкий: он не говорит, затронут ли поток пользователя и какой процесс владеет сокетом.

ss -tinp показывает расширенную TCP-информацию, включая retransmission timer, congestion state и счётчики конкретного сокета. Снимайте её серией, потому что один кадр не отличает краткий loss от устойчивого black hole. Рядом сохраняйте nstat, packet capture на разрешённом canary-пути и application trace: время первого токена, межтокенные паузы, статус завершения и отменил ли клиент запрос.

Infrastructure gate считается пройденным, когда на одном и том же tuple видны отправленные данные, отсутствие ACK и рост retransmission/возраста unacked состояния. Application gate требует, чтобы именно этот request_id перестал доставлять токены, но backend ещё не получил отмену. Отрицательный контроль — соседнее соединение через здоровый path с тем же профилем запроса.

Проверяйте направление. Для client-facing SSE gateway обычно отправляет большую часть данных, поэтому ACK loss виден на gateway. Для upstream RPC роли могут отличаться: gateway отправил небольшой request, а backend возвращает длинный stream. Снимайте evidence на стороне, у которой есть outstanding data. Симметричная проверка двух концов помогает отличить локальную очередь, middlebox и исчезнувший peer, но отсутствие доступа к клиенту не отменяет локальный per-socket proof.

# Выполняйте в effective network namespace процесса gateway
ss -tinp '( dport = :443 or sport = :443 )'
nstat -az | grep -E 'TcpRetransSegs|TcpTimeouts|TcpExtTCPAbortOnTimeout'

# Повторите снимок и сопоставьте tuple с request_id в access/trace log
date -Ins
ss -tinp dst 203.0.113.10:443

Baseline до изменения: owner, SLO и безопасные границы

До первой настройки зафиксируйте versioned evidence bundle. В него входят версия ядра, iproute2, runtime gateway, способ создания сокета, effective network namespace, значения keepalive, application deadline, proxy timeout и retry policy. Это защищает от ложной причинности: после деплоя вместе с socket option часто меняются библиотека, образ, маршрутизация или пул соединений.

Отдельно запишите три временные границы. Первая — пользовательский deadline: после неё ответ уже не имеет бизнес-ценности. Вторая — server cancellation window: когда backend гарантированно прекращает генерацию после disconnect. Третья — допустимое network recovery window для реальных клиентов. TCP_USER_TIMEOUT должен согласовываться с ними, но универсальной формулы нет: профиль корпоративной LAN, межрегионального WAN и мобильного клиента различается.

Не начинайте с глобального изменения net.ipv4.tcp_retries2. Документация Linux IP sysctl показывает, что этот параметр влияет на живые соединения во всей системе и связан с RTO. Для проверки гипотезы безопаснее per-socket option на canary-процессе: blast radius меньше, owner очевиден, rollback не затрагивает соседние сервисы.

Baseline должен охватывать хотя бы одно обычное окно и один пик. Таймер, выбранный по спокойной лаборатории, может обрывать соединения при допустимой очереди в час нагрузки. Вместо среднего используйте распределения: RTT/RTO, длительность unacked эпизодов, inter-token gaps и cancellation latency. Значение socket option документируйте как гипотезу для конкретного path class, а не как постоянный стандарт всей компании.

Canary: positive gate, negative control и контрфакт

Canary должен воспроизводить именно потерю подтверждений после установления соединения. Обычное «выключить backend» часто отправляет FIN/RST и проверяет совсем другой failure mode. Нужен изолированный client/gateway pair, где firewall или traffic control отбрасывает return ACK path для уже существующего потока. Никогда не применяйте такой эксперимент к production-интерфейсу или общему namespace.

Positive gate: после появления unacked данных сокет закрывается в ожидаемом окне, приложение получает наблюдаемую ошибку, request cancellation доходит до backend, а повтор не запускается без idempotency/budget проверки. Negative control: тот же canary выдерживает обычную паузу генерации без unacked данных и не рвёт поток только потому, что токенов некоторое время нет.

Контрфакт обязателен. Уберите fault injection и верните socket profile к baseline, затем повторите тот же запрос. Если завершение по таймауту осталось, причина не в TCP_USER_TIMEOUT или эксперимент изменил больше одной переменной. Если kernel counter улучшился, но пользовательский completion rate не изменился, доказан механизм, а не коммерческий эффект.

Fault injection должен быть узким и проверяемым. Зафиксируйте правило, namespace, interface, tuple и время начала; вторым оператором подтвердите, что production route не затронут. Перед тестом убедитесь, что запрос синтетический и не содержит пользовательских данных. После теста проверьте отсутствие qdisc/firewall rule, пустой список canary-сокетов и возврат метрик к baseline. Эти шаги делают эксперимент эксплуатационно безопасным.

# Только в заранее подготовленном изолированном canary namespace.
# veth-canary не должен обслуживать production-трафик.
ip netns exec ks-canary tc qdisc replace dev veth-canary root netem loss 100%

# Наблюдайте существующий поток и ожидайте ETIMEDOUT в приложении.
ip netns exec ks-canary ss -tinp

# Rollback fault injection.
ip netns exec ks-canary tc qdisc del dev veth-canary root

Почему proxy timeout и retries могут скрыть результат

Даже правильный socket timeout бесполезен, если верхний слой превращает его в retry storm. Для streaming-ответа повтор после частичной выдачи токенов часто не является безопасным: клиент уже увидел часть текста, а новый backend снова расходует GPU. Gateway должен знать, был ли response body начат, поддерживает ли операция idempotency key и остался ли retry budget.

Проверьте оба плеча отдельно: client → gateway и gateway → inference backend. TCP_USER_TIMEOUT на upstream socket не управляет клиентским соединением, а опция на client-facing socket не отменяет зависший backend request автоматически. Между ними нужен явный cancellation path. В противном случае gateway быстро освободит один сокет, но GPU продолжит генерацию, и capacity не вернётся.

Соседний материал про Envoy под перегрузкой LLM API полезен для circuit breakers и backpressure; здесь же stop condition другая: не расширяйте rollout, пока ошибка transport layer не связана с отменой конкретного inference и пользовательским outcome. Новый таймаут без cancellation и observability лишь делает потерю работы быстрее.

Особенно опасны промежуточные connection pools. Новый пользовательский запрос может получить давно открытый upstream socket с другим effective profile, а после reload часть соединений останется на старом значении. В canary помечайте соединения по времени создания и принудительно разделяйте пулы, иначе сравнение смешает baseline и treatment. После rollout проверяйте не только конфигурацию процесса, но и option на реально созданных сокетах.

Rollout по профилям пути, а не одним числом на весь флот

Разделите трафик по реальным классам: внутренний east-west, корпоративный VPN, межрегиональный WAN, публичный интернет и мобильные клиенты. Начните с класса, где RTT и ownership наиболее стабильны. Один процент canary соединений на выделенном gateway лучше, чем системный sysctl на всём пуле: вы видите effective option и можете вернуть старый профиль без рестарта всей платформы.

Наблюдайте не только число ETIMEDOUT. Минимальный набор включает completion rate, user cancellations, TTFT, inter-token gap, retransmissions, unacked duration, backend cancellation latency, повторные запросы и GPU active time после client disconnect. Stop condition: растёт доля ложных abort на здоровом path, ухудшается completion rate либо retries добавляют больше GPU-работы, чем освобождает fail-fast.

На выделенном сервере или отдельном network edge проще закрепить kernel/runtime profile, проводить controlled fault injection и хранить packet evidence. Но dedicated-инфраструктура — не лечение сама по себе. Она полезна только после path proof, когда ценность состоит в ownership над ядром, маршрутом, rollout window и rollback. Ошибочный application deadline, stale connection pool или backend queue новый сервер не исправит.

Расширяйте rollout ступенями и сохраняйте одинаковое окно наблюдения. Сначала synthetic traffic, затем внутренние клиенты, после этого небольшой процент внешнего path class. На каждой ступени одинаковы запрос, модель, лимит токенов и retry policy. Изменение модели или batching одновременно с network profile разрушает эксперимент. Решение о расширении принимает owner по заранее записанным stop conditions, а не по визуальному впечатлению от графика.

Для on-call добавьте timeout source в structured log: application deadline, proxy read timeout, TCP user timeout, peer reset или client cancel. Лог должен содержать request_id, generation_id, socket tuple и число уже выданных токенов, но не prompt и не чувствительные данные. Тогда один график ответит на два вопроса: освободили ли мы бесполезную capacity и не увеличили ли долю обрывов полезных ответов. Без такого различения рост ETIMEDOUT после rollout ожидаем, но сам по себе ничего не говорит о качестве решения.

# Псевдокод rollout-политики: значения приходят из versioned profile.
profile = path_profile(request.client_class)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_USER_TIMEOUT, profile.user_timeout_ms)

metrics.label(
    path_class=profile.name,
    socket_owner="llm-gateway",
    timeout_source="tcp_user_timeout",
).observe(1)

Decision helper: когда менять таймер, приложение или инфраструктуру

Если токены не идут, но unacked=0 и retransmissions не растут, TCP_USER_TIMEOUT не является рабочей гипотезой. Смотрите GPU scheduler, batching, KV cache pressure, proxy buffering и application heartbeat. Если unacked растёт только на одном маршруте, сравните next hop, MTU, firewall и connection tracking, прежде чем менять сервер.

Если одинаковый ACK failure воспроизводится на разных клиентах за одним gateway, per-socket timeout может быть разумной защитой capacity. Сначала задайте его в приложении, подтвердите effective state через getsockopt, затем свяжите ETIMEDOUT с cancellation. Если runtime не позволяет управлять socket option, рассмотрите sidecar или gateway, который действительно владеет сокетом; не имитируйте эффект чрезмерно коротким proxy timeout.

Procurement default прост: не меняйте платформу до доказанного TCP-path failure. VPS подходит для отдельного контролируемого edge с небольшим blast radius; dedicated gateway полезен, когда нужны предсказуемый kernel profile, capture, routing ownership и изолированное окно изменений. Решение принимается по воспроизводимости и SLO, а не по обещанию меньшей latency.

При выборе площадки сравнивайте контрольные границы. В managed gateway часть socket options или packet capture может быть недоступна; на VPS вы управляете гостевым ядром, но не физическим маршрутом; на dedicated edge доступны стабильный NIC/kernel profile и изолированный drain. Ни один вариант не гарантирует лучший outcome автоматически. Покупательский критерий — способен ли выбранный контур воспроизвести canary, показать evidence и выполнить rollback в пределах вашего SLO.

Частые ошибки и stop conditions

Ошибка 1: считать любой молчащий поток half-open. Пока приложение не отправило данные, ACK нечего подтверждать. Нужны unacked/retrans evidence и конкретный tuple.

Ошибка 2: ставить timeout короче нормального recovery window. Мобильный handover, временный queueing и высокий RTT превращаются в ложные abort. Canary должен включать худшие допустимые, но здоровые пути.

Ошибка 3: менять глобальный sysctl ради одного сервиса. Это расширяет blast radius и усложняет attribution. Сначала per-socket profile, stable owner и обратимый rollout.

Ошибка 4: забыть про повторную GPU-работу. Быстрый ETIMEDOUT плюс безусловный retry может удвоить нагрузку. Нужны idempotency, retry budget и запрет повтора после частичной выдачи.

Ошибка 5: принимать kernel improvement за пользовательский результат. Меньше долгоживущих сокетов — полезный механизм, но успех статьи измеряется completion rate, отменой backend и сохранённым SLO. Если application outcome не меняется, не продавайте настройку как ускорение.

Остановите rollout, если нет отрицательного контроля, fault injection затрагивает общий path, runtime не подтверждает effective option, отсутствует backend cancellation либо observability не различает application, proxy и kernel timeout. Эти условия важнее красивого графика retransmissions.

Ошибка 6: забыть о long-poll и больших паузах между токенами. TCP_USER_TIMEOUT не должен имитировать heartbeat. Если приложению нужно обнаруживать логически «молчащий» stream без outstanding data, используйте протокольный heartbeat или application deadline. Смешивание этих задач делает инцидент неразличимым: одинаковый ETIMEDOUT начинают трактовать и как network failure, и как медленную генерацию.

Вывод: таймаут должен завершать доказанно бесполезную работу

TCP_USER_TIMEOUT полезен для LLM streaming не потому, что «TCP слишком медленный», а потому, что живой с точки зрения ядра сокет может удерживать уже бесполезную inference-работу. Правильный runbook связывает один и тот же запрос через четыре слоя: unacked TCP state, наблюдаемую ошибку процесса, отмену backend и пользовательский outcome.

Начните со снимка ss -tinp и application trace, отделите idle от unacked, затем воспроизведите ACK black hole на изолированном canary. Установите per-socket option, проверьте его через getsockopt, выполните positive и negative control, а после rollback повторите те же probes. Только так можно говорить о причинности.

Практический следующий шаг — собрать baseline для одного path class и одного gateway-процесса. Если выяснится, что вам нужен отдельный управляемый edge с фиксированным kernel profile, трассировкой и безопасным окном изменений, инфраструктуру можно подобрать под доказанные требования. Если evidence указывает на приложение или GPU queue, исправьте этот слой и сохраните сеть без лишнего тюнинга.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Симптомы: когда gateway упирается в сетевое CPU

Типичная авария выглядит нелогично: суммарный CPU сервера далёк от 100%, GPU backend отвечает стабильно, а p99 и time-to-first-token на входном gateway внезапно растут. В top одно или два ядра заняты ksoftirqd, в /proc/interrupts почти весь поток NIC приходит на один CPU, а соседние ядра простаивают. Добавление worker-процессов не помогает: пакет всё равно должен пройти RX queue, IRQ и network softirq до того, как его увидит NGINX, Envoy или собственный API-процесс.

Это важно отличать от accept bottleneck. SO_REUSEPORT распределяет новые соединения между listeners, но не исправляет перекошенную аппаратную RX-очередь. И наоборот: идеальный RSS не спасёт, если TLS handshakes съедают userspace CPU или запросы стоят в inference queue. Наша задача — найти владельца задержки по пути пакета, а не подобрать красивый sysctl.

Быстрый признак сетевого перекоса — корреляция трёх рядов: interrupts одной RX queue, NET_RX softirq на том же CPU и ухудшение application SLO. Одного высокого счётчика недостаточно. Проверяли ли вы, что всплеск softirq действительно совпадает с задержкой свежих соединений, а не просто отражает нормальную работу busy gateway?

Evidence gate: докажите bottleneck до тюнинга

Снимайте baseline во время воспроизводимой нагрузки: одинаковый профиль запросов, те же TLS-настройки, тот же backend и неизменное число gateway workers. Минимальный набор — per-CPU utilisation, /proc/interrupts, /proc/softirqs, статистика NIC по очередям, drops, retransmits и application SLO. Для LLM streaming добавьте TTFT, долю оборванных SSE/gRPC streams и latency уже после первых байтов: улучшение приёма пакетов не должно маскировать partial responses.

В Linux аппаратный RSS выбирает RX queue, IRQ этой очереди будит CPU, а softirq продолжает обработку сетевого стека. RPS может перенаправить protocol processing на другой CPU позднее, уже программно. Официальная документация Linux по scaling подчёркивает: при корректном RSS с очередью на CPU RPS часто избыточен. Поэтому сначала установите фактический путь, затем меняйте только один слой.

Негативный контроль обязателен. Направьте короткий тест на тот же gateway по loopback или напрямую к userspace listener, если архитектура и безопасность это позволяют. Если задержка остаётся, NIC steering не главный владелец. Второй контроль — снизить packet rate, сохранив request concurrency: если SLO восстанавливается вместе с падением softirq, гипотеза становится сильнее. Это не benchmark, а проверка причинности.

#!/usr/bin/env bash
set -euo pipefail
iface=${1:-eth0}
date -Is
ethtool -l "$iface"
ethtool -x "$iface" 2>/dev/null || true
ethtool -S "$iface" | grep -Ei 'rx.*(queue|drop|miss|error)|tx.*(queue|drop|error)' || true
grep -E "$iface|CPU" /proc/interrupts
sed -n '1p;/NET_RX/p;/NET_TX/p' /proc/softirqs
nstat -az | grep -E 'TcpRetransSegs|IpInDiscards|TcpExtListenDrops' || true

Как пакет проходит RSS, IRQ и softirq

RSS работает в сетевой карте: NIC вычисляет hash по полям потока и через indirection table выбирает RX queue. У multi-queue NIC каждая очередь обычно связана с MSI-X interrupt. Карта queue → IRQ → CPU видна не в одном файле, поэтому её приходится собирать: список каналов из ethtool -l, имена IRQ из /proc/interrupts, разрешённая и эффективная affinity из /proc/irq/*. Именно effective_affinity_list показывает фактический CPU, когда interrupt managed.

После NAPI polling пакет попадает в protocol processing. Если rps_cpus равен нулю, обработка остаётся на interrupting CPU. При включённом RPS ядро выбирает target CPU по flow hash и ставит пакет в backlog другого CPU, посылая IPI. Это может разгрузить горячее ядро на виртуальном NIC с одной очередью, но цена — межпроцессорные прерывания и возможная потеря cache locality.

У LLM API потоки неодинаковы: короткий health check и длинный streaming response могут иметь одинаковый вес для hash, но совершенно разную жизнь в приложении. Поэтому равномерные IRQ ещё не гарантируют равномерный userspace. Смотрите одновременно queue packets, CPU softirq и фактические worker sockets. Если один огромный поток доминирует, RSS не обязан разрезать его между ядрами: ordering внутри flow важнее красивой диаграммы.

RSS, RPS, RFS и XPS: что выбирать

Начальный выбор прост. Есть достаточно hardware RX queues и они действительно распределены по подходящим CPU — настраивайте RSS и IRQ affinity, не включайте RPS автоматически. Очередей мало или виртуальная NIC отдаёт один receive path — протестируйте RPS на CPU того же NUMA node. Хотите приблизить packet processing к потоку приложения — рассматривайте RFS, но только после стабильного worker placement. Для transmit path существует XPS; он полезен отдельно и не доказывает, что receive bottleneck устранён.

RFS использует flow table и сведения о CPU, на котором userspace читает socket. Если scheduler постоянно мигрирует gateway worker, локальность становится движущейся целью. Сначала закрепите или хотя бы наблюдайте worker placement, затем оценивайте RFS. Accelerated RFS требует поддержки драйвера и NIC, а также ntuple filtering; это capability gate, не универсальная настройка.

Ошибка серии «включим всё» особенно неприятна: RSS, RPS, irqbalance и ручная affinity начинают тянуть пакеты в разные стороны. Изменение может снизить softirq на одном CPU, но поднять IPI, LLC misses и latency. Поэтому каждое решение формулируйте как гипотезу: «две RX queue сконцентрированы на CPU 2; перенос IRQ на CPU 4 и 6 того же NUMA node снизит queue pressure без роста retransmits». Так результат можно опровергнуть.

NUMA и CPU locality на выделенном сервере

На двухсокетном сервере «размазать IRQ по всем ядрам» часто хуже, чем оставить меньше CPU рядом с NIC. PCIe-карта физически принадлежит NUMA node; пакетные buffers и DMA оказываются ближе к памяти этого узла. Если interrupt приходит на другой socket, вы платите за interconnect traffic и cache misses. Команда cat /sys/class/net/eth0/device/numa_node даёт стартовую точку, а lscpu -e=CPU,NODE,SOCKET,CORE показывает топологию.

Отделите housekeeping, network path и application workers настолько, насколько это подтверждает нагрузка. Не резервируйте половину сервера «на всякий случай»: у gateway может оказаться больше пользы от общих cache и достаточного числа workers. Практичный canary — закрепить IRQ двух горячих RX queues на свободных CPU локального NUMA node и оставить остальные очереди baseline. После этого сравнить не только softirq, но и TTFT, context switches, LLC misses и network drops.

Для shared VM физическая NUMA topology и IRQ routing частично принадлежат гипервизору. В этом случае ручная маска внутри гостя может быть нестабильна после миграции или reboot. VPS или выделенный edge даёт больше контроля над версиями kernel, NIC queues и change window, но сам по себе не исправляет неверный hash, single-flow hotspot или очередь GPU. Сначала докажите control gap; затем решайте вопрос платформы.

#!/usr/bin/env bash
set -euo pipefail
iface=${1:-eth0}
echo "NIC NUMA node: $(cat /sys/class/net/$iface/device/numa_node)"
lscpu -e=CPU,NODE,SOCKET,CORE,ONLINE
while read -r irq rest; do
  n=${irq%:}
  printf 'IRQ %s allowed=%s effective=%s\n' "$n" \
    "$(cat /proc/irq/$n/smp_affinity_list 2>/dev/null || echo n/a)" \
    "$(cat /proc/irq/$n/effective_affinity_list 2>/dev/null || echo n/a)"
done < <(grep "$iface" proc interrupts)< code>

Метрики очередей: что считать, а чему не верить

Названия counters зависят от драйвера, поэтому не стройте runbook вокруг одного rx_queue_0_drops. Сначала сохраните полный ethtool -S, затем найдите per-queue packets, bytes, drops, misses и allocation failures. Официальная kernel documentation по interface statistics напоминает, что часть стандартных counters доступна через несколько интерфейсов; vendor-specific строки требуют проверки драйвера.

/proc/net/softnet_stat полезен, но его hex-поля и семантика менялись между версиями kernel. Не копируйте парсер из случайной статьи без сверки с исходниками или документацией вашей версии. Безопаснее дополнить его sar -n DEV, per-CPU softirq, NIC drops и application metrics. Если «dropped» растёт, докажите, на каком CPU и при каком workload это происходит.

Следите за распределением, а не только суммой. Условные 200 тысяч interrupts на сервер ничего не говорят, если 190 тысяч пришли на CPU 0. Но и идеально ровная гистограмма не является SLO: иногда worker pool закреплён на меньшем CPU set, и перенос packets на удалённые cores увеличит cache traffic. Хороший dashboard связывает queue ID → IRQ → effective CPU → softirq CPU → gateway worker → request outcome. Если цепочка обрывается, вывод остаётся гипотезой.

Безопасная настройка IRQ affinity и RSS

Перед записью affinity проверьте irqbalance. Он может вернуть IRQ на другие CPU после вашего изменения; это выглядит как «настройка не работает», хотя конфликтуют два owner. Не отключайте daemon глобально вслепую. Либо задайте его policy/ban mask, либо остановите на одном canary и зафиксируйте этот факт в runbook. Для managed interrupts запись в smp_affinity_list может быть недоступна; это ограничение драйвера и IRQ core.

Используйте smp_affinity_list, когда возможно: список CPU читается легче, чем hex bitmap. Официальная документация SMP IRQ affinity описывает оба интерфейса. Меняйте одну очередь за раз. После изменения перечитайте effective_affinity_list, потому что успешный echo ещё не доказывает фактическое размещение.

RSS indirection table редактируют через ethtool -X; количество combined channels — через ethtool -L. Эти команды зависят от capability NIC и драйвера и могут переименовать IRQ. Сначала сохраните ethtool -l, -x и interrupt mapping. Никогда не вставляйте в automation фиксированные номера IRQ, полученные до reboot или изменения channel count.

#!/usr/bin/env bash
set -euo pipefail
irq=${1:?usage: $0 IRQ CPU_LIST}
cpus=${2:?usage: $0 IRQ CPU_LIST}
old=$(cat /proc/irq/$irq/smp_affinity_list)
printf '%s\n' "$old" > "/run/irq-${irq}.affinity.before"
printf '%s\n' "$cpus" > "/proc/irq/$irq/smp_affinity_list"
printf 'allowed=%s effective=%s\n' \
  "$(cat /proc/irq/$irq/smp_affinity_list)" \
  "$(cat /proc/irq/$irq/effective_affinity_list 2>/dev/null || echo n/a)"

Когда включать RPS и как не создать IPI storm

RPS нужен не потому, что сервер многопроцессорный, а потому, что текущий receive path не использует доступный CPU budget. На NIC с одной RX queue маска rps_cpus может распределить protocol processing по нескольким cores. На полноценном RSS с очередью на CPU тот же RPS часто добавляет лишний hop. Kernel docs прямо называют эти механизмы взаимодополняющими, но не требуют включать оба.

Начните с CPU того же memory domain и исключите interrupting CPU, если он уже перегружен. Затем измерьте IPI, softirq distribution и backlog drops. Большая маска не гарантирует лучший результат: пакет может пересечь NUMA boundary, а gateway worker — читать данные на третьем CPU. Для RFS отдельно задаются global rps_sock_flow_entries и per-queue rps_flow_cnt; размеры выбирают под реальное число активных flows, а не копируют из чужого 64-core сервера.

Практический failure mode: после RPS график CPU становится ровнее, но TTFT растёт. Причина — дополнительный IPI и потеря locality. Контрфактическая проверка проста: вернуть маску одной canary queue в ноль и повторить тот же workload. Если SLO возвращается к baseline, «ровный CPU» был локальным улучшением счётчика, а не end-to-end выигрышем.

#!/usr/bin/env bash
set -euo pipefail
path=${1:-/sys/class/net/eth0/queues/rx-0/rps_cpus}
mask=${2:?pass CPU bitmap, for example 0c}
old=$(cat "$path")
printf '%s\n' "$old" > /run/rps-rx0.before
printf '%s\n' "$mask" > "$path"
printf 'before=%s after=%s\n' "$old" "$(cat "$path")"

Canary: проверяем peer, fresh connections и application outcome

Canary должен менять один control: IRQ affinity одной или двух очередей, RPS одной queue либо RSS indirection weights. Не меняйте одновременно worker count, TLS configuration и kernel. Baseline и canary получают одинаковую форму нагрузки, включая короткие запросы и длительный streaming. Иначе можно улучшить handshake path и ухудшить уже установленные соединения, не заметив этого в среднем latency.

Разделите три evidence gate. Первый — kernel path: нужные IRQ действительно приходят на выбранные CPU, drops не растут. Второй — фактический peer и connection lifecycle: fresh connections попадают на ожидаемый gateway, а reused connections анализируются отдельно. Третий — outcome: TTFT, p95/p99, stream completion и error rate улучшаются или хотя бы не ухудшаются. Эта схема продолжает подход из runbook про HTTP/2 GOAWAY и graceful drain: событие transport не равно результату запроса.

Для отрицательного контроля оставьте один gateway без изменений. Для контрфактического теста временно верните canary affinity к baseline и убедитесь, что метрики движутся обратно. Если эффект сохраняется, вы, вероятно, измерили изменение трафика или backend, а не steering. Такой тест особенно полезен, когда autoscaling GPU или client retries меняются параллельно.

Типичные ошибки и миграция bottleneck

Первая ошибка — лечить softirq числом NGINX workers. Userspace появляется позже в пути; worker count может изменить socket ownership, но не исправит single RX queue. Вторая — принять высокий ksoftirqd за причину без drops и SLO correlation. Третья — отключить irqbalance и забыть про reboot persistence. Четвёртая — распределить IRQ на CPU, где уже работают TLS или compression threads.

Даже успешный steering способен передвинуть bottleneck. После разгрузки RX path может проявиться TLS CPU, lock contention proxy, conntrack, egress queue или inference backend. Поэтому после canary повторите полный owner map, а не завершайте работу на графике softirq. Если теперь растёт handshake CPU, пригодится отдельный runbook по TLS handshake storm. Если gateway быстро отдаёт 503 или рвёт stream после headers, сверяйтесь с Envoy overload и backpressure.

Не обещайте latency от покупки нового сервера. Выделенный edge оправдан, когда доказан control gap: нужны стабильные NIC queues, известная NUMA topology, управляемые kernel/driver versions и собственное change window. Он не исправит poor hash entropy, один доминирующий flow, retry storm или очередь GPU. Это и есть честный procurement default: не менять платформу до доказанного участка path.

Rollback и эксплуатационный runbook

Rollback должен быть симметричен rollout. Сохраняйте исходные smp_affinity_list, rps_cpus, RSS indirection table и channel count до каждой записи. Возврат значений — только половина процедуры: перечитайте effective state, создайте fresh connections и повторите те же SLO probes. Старые sockets могут продолжать жить на прежнем worker или TX queue, поэтому мгновенного возврата всех графиков ждать нельзя.

Опишите owner и срок действия. Кто управляет irqbalance? Где хранится persistence — systemd unit, tuned profile, NetworkManager dispatcher или provisioning? Что произойдёт после обновления kernel/driver и изменения имён интерфейсов? Ручной echo в production без ответов на эти вопросы превращается в скрытую конфигурацию.

Порог rollback задавайте через ваш baseline, не универсальными числами. Примеры условий: рост RX drops, retransmits, stream aborts, TTFT или межсокетного memory traffic; исчезновение ожидаемого improvement после контрфактического теста; конфликт с managed IRQ. После отката зафиксируйте, какой evidence gate не прошёл. Это полезнее фразы «RPS не помог».

#!/usr/bin/env bash
set -euo pipefail
irq=${1:?pass IRQ}
if [[ -r /run/irq-${irq}.affinity.before ]]; then
  cat "/run/irq-${irq}.affinity.before" > "/proc/irq/${irq}/smp_affinity_list"
fi
if [[ -r /run/rps-rx0.before ]]; then
  cat /run/rps-rx0.before > /sys/class/net/eth0/queues/rx-0/rps_cpus
fi
cat "/proc/irq/${irq}/smp_affinity_list"
cat "/proc/irq/${irq}/effective_affinity_list" 2>/dev/null || true
cat /sys/class/net/eth0/queues/rx-0/rps_cpus

Вывод: оптимизируйте доказанный путь, а не загрузку CPU

RSS, RPS и IRQ affinity полезны, когда вы доказали конкретный receive-path bottleneck: очередь NIC, interrupt CPU, softirq и application outcome связаны одной цепочкой. Начинайте с аппаратного RSS и фактической IRQ mapping, учитывайте NUMA, а RPS/RFS добавляйте только при понятном дефиците hardware queues или locality. Ровный CPU-график сам по себе не является успехом.

Практический следующий шаг — снять неизменяемый baseline, выбрать одну RX queue для canary и пройти три gate: kernel path, fresh-connection peer, SLO. Затем выполнить контрфактический возврат и проверить, что эффект исчезает вместе с настройкой. Если контроль над NIC, kernel и NUMA действительно ограничивает эксплуатацию, сравнивайте VPS и выделенный edge по ownership, telemetry и rollback window, а не по обещанию «меньше latency».

Возьмите чек-лист из статьи, проведите тест в своём maintenance window и сохраните исходные значения до первой записи. Так сетевой тюнинг останется управляемым изменением, а не новой причиной ночного инцидента.

Готовы перейти на современную серверную инфраструктуру?

В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.

• S3-совместимое хранилище для резервных копий
• Панель управления, API, масштабируемость
• Поддержку 24/7 и помощь в выборе конфигурации

Короткий вывод: когда NAT64 действительно нужен

NAT64 нужен не потому, что «IPv6 современнее», а когда workload имеет только IPv6, а обязательный внешний сервис публикует только IPv4. В этом случае DNS64 синтезирует IPv6-адрес назначения, маршрут ведёт его к translator, а stateful NAT64 создаёт IPv4 flow. Если у провайдера LLM API есть рабочая AAAA-запись, этот тракт не должен участвовать: нативный IPv6 проще, прозрачнее и не расходует pool4.

Практический default консервативный: не переводите весь egress через NAT64, пока не доказали IPv4-only dependency из namespace реального Pod. Kubernetes поддерживает single-stack IPv6, а dual-stack networking имеет статус Stable с версии 1.23, однако сама платформа не превращает IPv4-only Internet в IPv6. За эту границу отвечают DNS64, translator, маршрутизация и ваша CNI-политика, а не Service API.

Disqualifier тоже важен. NAT64 не исправит stale DNS в приложении, неправильный SNI, retry storm, сломанную PMTUD или очередь внутри inference. Он добавляет stateful control point и отдельную on-call обязанность. Выбирать его стоит только тогда, когда экономия адресного пространства и единый IPv6 dataplane перевешивают стоимость этой зависимости.

Официальная модель описана в RFC 6146 и RFC 6147. Ниже мы не строим лабораторный трюк: цель — получить цепочку доказательств, которую можно повторить во время инцидента и после rollback.

Сначала докажите симптом из effective namespace

Типичный алерт выглядит расплывчато: SDK пишет connection timeout, sidecar показывает upstream reset, а бизнес видит выросший TTFT. Начинать с установки translator рано. Зайдите в тот же network namespace, где работает клиент, и сравните A и AAAA для точного hostname. Затем создайте fresh connection, чтобы pool приложения не подменил эксперимент старым сокетом.

Разделите наблюдение на четыре gate. DNS answer отвечает лишь на вопрос, какой адрес получил клиент. Route gate проверяет, куда ядро отправит synthesized destination. Translation gate подтверждает BIB/session на NAT64 и фактический IPv4 peer. Application gate проверяет TLS, HTTP status, первый токен и корректное завершение SSE или gRPC stream. Пропуск одного gate превращает диагностику в догадку.

Мини-пример: Pod получает только A для API, но локальный ноутбук работает. Это не доказательство блокировки и не повод менять firewall. Ноутбук использует IPv4, а Pod — single-stack IPv6. Внутри Pod запрос AAAA останется пустым без DNS64, поэтому до TCP дело не дойдёт. И наоборот, synthesized AAAA без session на translator указывает уже не на DNS, а на route или policy.

kubectl exec -n ai-egress deploy/llm-client -- sh -ceu '
  getent ahosts api.example.net
  dig +short A api.example.net
  dig +short AAAA api.example.net
  ip -6 route get 64:ff9b::c000:0201
  curl -6 --connect-timeout 5 -sSvo /dev/null https://api.example.net/v1/models
'

Архитектура пути: DNS64 не является NAT64

В рабочей схеме участвуют четыре независимых владельца. Рекурсивный resolver видит запрос AAAA, получает A от authoritative DNS и, если нативного AAAA нет, синтезирует адрес с Pref64. Сеть Pod знает маршрут к этому префиксу. NAT64 gateway извлекает встроенный IPv4 destination, выбирает source address и port из pool4 и хранит состояние. Внешний API видит обычное IPv4-соединение от translator.

Эта граница полезна во время инцидента. Наличие адреса вида 64:ff9b::/96 не доказывает, что NAT64 жив. Оно доказывает только политику ответа DNS64. Запись session на translator не доказывает успешный inference: TLS может завершиться ошибкой, API вернуть 429, а streaming оборваться после headers. Поэтому метрики разных слоёв нельзя складывать в один зелёный health check.

RFC 6052 задаёт форматы IPv4-embedded IPv6 address и допускает несколько длин префикса; /96 легче читать и отлаживать. Well-Known Prefix удобен, но network-specific prefix может быть уместнее в сложной маршрутизации. Критическое правило одно: DNS64 и NAT64 должны использовать один и тот же Pref64, а маршрутизаторы должны доставлять весь этот prefix к правильному translator.

Проверьте owner map до rollout. DNS-команда отвечает за синтез и DNSSEC policy, network-команда — за route и ACL, платформа — за CNI/egress, владелец приложения — за hostname, connection reuse и retry. Когда один инженер «владеет NAT64 целиком», обычно один из этих слоёв остаётся без наблюдаемости.

Настройка DNS64: синтез только там, где он нужен

Для production удобен отдельный DNS64 resolver или чётко выделенный view, а не глобальная подмена ответов для всех клиентов. Unbound документирует модуль dns64: он включается в module-config, а dns64-prefix должен совпадать с translator. Значение по умолчанию — 64:ff9b::/96. Не включайте dns64-synthall в проде: документация прямо называет его debugging feature.

Resolver должен сохранить нативный AAAA, если он существует. Это позволяет IPv6-capable API идти напрямую, а translation использовать только для IPv4-only names. В противном случае вы искусственно тянете рабочий IPv6 через IPv4 bottleneck и усложняете атрибуцию. Отдельно проверьте CNAME chain: синтез относится к конечному A RRset, а не к красивому имени в конфиге приложения.

DNSSEC требует осознанной схемы. DNS64 меняет данные ответа, поэтому валидирующий resolver должен выполнять синтез в правильной точке pipeline согласно RFC 6147. Не лечите SERVFAIL отключением validation наугад. Сравните ответ обычного validating resolver, DNS64 resolver и authoritative data; сохраните флаг AD и логи validation. Это особенно важно для внешнего AI API, где endpoint может менять CDN и набор адресов.

TTL synthesized AAAA не является временем жизни TCP-соединения. Клиентский pool способен держать старый сокет после истечения DNS cache. Этот же принцип разобран в материале о DNS failover для LLM API: DNS answer, фактический peer и application outcome нужно наблюдать отдельно.

server:
  interface: ::0
  access-control: fd20:10:20::/48 allow
  module-config: "dns64 validator iterator"
  dns64-prefix: 64:ff9b::/96
  dns64-synthall: no

Stateful NAT64: Pref64, pool4 и цена состояния

Stateful translator похож на привычный NAPT, но соединяет разные семейства адресов. Для каждого нового flow он резервирует IPv4 transport address и port, создаёт Binding Information Base и session state. Jool называет IPv4 transport pool таблицей pool4. Именно она определяет внешний source address и доступную port capacity, а не DNS64.

В Jool NAT64 префикс задаётся при создании instance. Документация предупреждает, что для NAT64 его нельзя менять на живой instance из-за синхронизации. Значит, смена Pref64 — это миграция с новым экземпляром и маршрутом, а не безобидный update flag. Конфигурацию делайте постоянной через штатный systemd/config механизм дистрибутива; tutorial-команды сами по себе reboot не переживают.

Один IPv4 address не равен бесконечному egress. Длинные SSE/gRPC connections удерживают mapping, короткие retries создают churn, а несколько tenant могут конкурировать за один pool. Наблюдайте число BIB entries и sessions по протоколам, ошибки аллокации, drops, TCP state и использование портов на каждом pool4 address. Если exhaustion проявляется только под нагрузкой, добавление CPU не исправит дефицит transport tuples.

Начальная проверка должна включать TCP, UDP и ICMP отдельно. HTTPS использует TCP, но DNS, telemetry и диагностические инструменты могут идти иначе. PMTU и ICMP translation критичны для длинных ответов: потерянный ICMPv6 Packet Too Big способен оставить handshake рабочим, а большой streaming payload — зависшим. Это тот случай, когда «curl /health работает» даёт ложное спокойствие.

sudo modprobe jool
sudo jool instance add "ai-egress" --netfilter --pool6 64:ff9b::/96
sudo jool -i "ai-egress" pool4 add --tcp 203.0.113.10 1024-65535
sudo jool -i "ai-egress" pool4 add --udp 203.0.113.10 1024-65535

sudo jool instance display
sudo jool -i "ai-egress" pool4 display
sudo jool -i "ai-egress" bib display --tcp
sudo jool -i "ai-egress" session display --tcp

Встраивание в Kubernetes: маршрут, CNI и egress policy

Kubernetes классифицирует кластер по IP families, записанным в Pod, Service и Node objects. Дополнительный адрес на host interface сам по себе не превращает IPv6-only cluster в dual stack. Официальная документация также требует поддержки IPv6 со стороны CNI. Поэтому сначала зафиксируйте реальный Pod CIDR, Service CIDR, node addresses и поведение выбранного dataplane, а уже затем проектируйте маршрут Pref64.

Есть два распространённых размещения translator: выделенная gateway-пара или egress nodes внутри платформы. Выделенный gateway даёт ясный failure domain и независимый lifecycle. Egress node упрощает близость к Pod, но связывает translation с scheduling, upgrades и политикой CNI. В обоих случаях нужен next hop для Pref64, обратный IPv4 route к pool4 address и firewall, который различает транзитный трафик и management plane.

FQDN policy не заменяет DNS64. Она решает, какие destinations разрешены workload, но должна увидеть те адреса, которые реально использует dataplane. Если CNI кэширует DNS answers, сравните кэш endpoint с ответом resolver. Подробная схема такой проверки есть в статье о Cilium FQDN egress для LLM API. Для canary сохраните разрешённый IPv4-only hostname и запрещённый hostname как negative control.

Не завязывайте route на случайный node, который может быть drained. Используйте устойчивый next hop, ECMP только при совместимой state symmetry или state sharing, и health withdrawal, который проверяет не процесс, а способность translator создавать новые sessions. Асимметричный ответ через другой stateful gateway часто выглядит как редкий TCP reset и особенно больно проявляется на streaming.

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get svc -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,FAMILIES:.spec.ipFamilies,IPS:.spec.clusterIPs

kubectl exec -n ai-egress deploy/llm-client --   ip -6 route get 64:ff9b::c000:0201
kubectl exec -n ai-egress deploy/llm-client --   tracepath6 -n 64:ff9b::c000:0201

Runbook проверки: DNS → route → session → TLS → outcome

Проверяйте один hostname и один request id по всей цепочке. Сначала получите A и AAAA через тот resolver, который записан в /etc/resolv.conf Pod. Если AAAA synthesized, извлеките embedded IPv4 и сравните его с A. Затем проверьте route к адресу и одновременно смотрите session table на translator. Только после появления state переходите к TLS и HTTP.

TLS-тест выполняйте с исходным hostname, иначе вы меняете SNI и проверку сертификата. Соединение к synthesized IP с Host header, но без корректного SNI, не эквивалентно SDK. Для streaming endpoint фиксируйте время до headers, первый data frame и нормальное завершение. Reset после headers — отдельный failure mode, его нельзя считать обычным connect error и безусловно retry.

Нужны два отрицательных контроля. Native IPv6 endpoint должен обходить NAT64 и не создавать session. Заведомо запрещённый hostname или destination должен оставаться недоступным. Если оба теста «проходят» через один gateway, policy шире ожидаемой. Ещё один полезный контроль — fresh client без connection pool: он отделяет новый DNS/route от уже открытого transport.

Соберите evidence в один временной ряд: query/answer, selected destination, route next hop, BIB/session tuple, TLS result, HTTP status и application latency. Не пытайтесь вывести улучшение SLO из роста sessions. Translator может исправно создавать state, пока upstream возвращает 429 или GPU queue растёт.

API=api.example.net

dig +dnssec AAAA "$API"
dig +dnssec A "$API"
openssl s_client -connect "$API:443" -servername "$API" -brief 

Пять отказов, которые легко принять за «сломанный NAT64»

Первый — неправильный DNS view. Инженер проверяет корпоративный resolver, а Pod использует CoreDNS с другим upstream. Снимайте ответ внутри workload. Второй — Pref64 mismatch. DNS64 кодирует IPv4 в одном prefix, а route и Jool настроены на другой. Адрес выглядит правдоподобно, но translator его не принимает.

Третий — pool4 exhaustion. Симптом возникает на пике, новые connections timeout, а существующие streams продолжаются. Считайте transport tuples и churn. Родственная диагностика разобрана в runbook про conntrack и SNAT для LLM API, но ownership таблиц здесь другой: state живёт на NAT64.

Четвёртый — PMTU black hole. TLS может пройти на небольших пакетах, а длинный ответ зависает. Не блокируйте ICMPv6 бездумно, проверяйте Packet Too Big и effective MTU через весь path. Практика похожа на расследование WireGuard MTU и PMTUD: маленький probe не доказывает здоровье data path.

Пятый — application reuse. После изменения DNS64 клиент продолжает использовать старый connection. Перезапуск Pod кажется «магическим исправлением», хотя причина в pool lifecycle. Сравните fresh и reused connections, TTL resolver cache, SDK keepalive и drain policy. Не уменьшайте TTL до секунд без нужды: это увеличивает query load, но не закрывает открытые sockets.

Canary, capacity и rollback без смены всей сети

Начните с маленькой группы Pod и одного IPv4-only dependency. Baseline должен остаться неизменным: dual-stack или существующий IPv4 egress для сопоставимой нагрузки. На canary измеряйте DNS failures, route failures, session allocation, connect latency, TLS errors, HTTP codes, TTFT и долю завершённых streams. Сравнивайте одинаковые окна и запросы, не случайный утренний baseline с вечерним пиком.

Capacity planning строится снизу вверх. Оцените одновременные transport flows, среднюю длительность streaming connection, churn от retries и запас портов на pool4. Затем проверьте CPU, память session table и throughput translator. Не публикуйте универсальное число requests per second: оно зависит от packet size, connection lifetime, реализации, kernel и observability overhead. Нагрузочный тест должен повторять ваш mix, включая отмены и half-closed connections.

Rollback должен быть симметричен rollout. Верните canary на прежний resolver/route, дождитесь drain новых NAT64 sessions и повторите те же probes. Резкое удаление Pref64 route оборвёт активные flows и смешает сетевой rollback с application errors. Зафиксируйте, кто принимает решение, какое условие останавливает расширение и как долго хранятся диагностические логи.

Выделенный VPS или dedicated gateway оправдан, когда вам действительно нужен контроль kernel/module versions, route advertisement, pool4 addresses, telemetry и change window. Он не исправит неверный DNS view, SDK pooling или upstream throttling. Коммерческая ценность здесь — воспроизводимая граница управления и предсказуемый blast radius, а не обещание «ускорить NAT» без canary evidence.

Перед расширением оцените отказ самого translator. Потеря одного gateway не должна молча отправлять Pref64 в black hole. Routing health должен убрать next hop только после проверки data path, а восстановление возвращать его постепенно. Для active/passive заранее решите судьбу существующих sessions: без репликации state они оборвутся, поэтому приложение обязано различать безопасный retry до commitment и опасный retry после начала ответа.

Что мониторить и кому отдавать on-call

Минимальный dashboard должен быть разложен по тем же evidence gates, что и runbook. Для DNS64 нужны latency, SERVFAIL/NXDOMAIN, доля synthesized answers и validation failures. Для route — reachability Pref64 и next-hop changes. Для NAT64 — BIB, sessions, allocation failures, drops, port utilization и resource saturation. Для приложения — connect/TLS error, HTTP code, TTFT, stream completion и retries.

Алерт «NAT64 down» почти бесполезен. Лучше алертировать нарушение инварианта: DNS64 выдал synthesized AAAA, но session не появилась; sessions создаются, но TLS failures выросли; TLS успешен, но completion rate упал. Такое условие сразу сужает owner и сохраняет контекст. Health probe translator должен включать реальный translation path к контролируемому IPv4 target, а не только проверку процесса.

Обновления Jool, kernel, resolver или CNI проводите раздельно. Иначе при регрессии вы не узнаете, какой слой изменил packet handling. Для HA проверьте, что routing не отправляет обратный трафик на gateway без state. Если используете active/passive, тестируйте failover с живыми и новыми flows отдельно: сохранение IP не означает сохранение session table.

Наконец, документируйте зависимости внешнего API. Endpoint может получить native IPv6, сменить CDN или добавить новый hostname. Ежемесячная проверка A/AAAA и traffic inventory позволяет удалить NAT64 из пути там, где он больше не нужен. Лучшая stateful dependency — та, которую команда умеет безопасно обойти.

Отдельно следите за экономикой отказа. Stateful gateway может быть технически здоров, но стать общей очередью для нескольких продуктов: чат-бота, batch enrichment и фоновых evals. Разделите трафик хотя бы метками, source prefixes или отдельными pool4 ranges, чтобы один tenant не выедал port budget незаметно для остальных. Квоты должны ограничивать новые flows и retries, а не только суммарные байты. Для длинного streaming-запроса количество открытых sessions важнее мгновенного RPS.

Логи translator полезны лишь вместе с correlation data, которое не раскрывает секреты. Храните время, protocol, внутренний source prefix, выбранный pool4 tuple, destination и причину drop; API keys и содержимое prompt в сетевой журнал не попадают. Синхронизация времени на nodes, resolver и gateway обязательна: без неё DNS answer и session выглядят несвязанными событиями. Установите срок хранения, достаточный для расследования редких обрывов, и проверьте, что sampling не выкидывает именно ошибки аллокации.

Для дежурного подготовьте короткую карточку решения. Если нет synthesized AAAA, владелец resolver проверяет policy и upstream A. Если AAAA есть, но route ведёт не на gateway, инцидент у network layer. Если session создаётся, но TLS не проходит, подключается владелец trust store и endpoint configuration. Если TLS успешен, а stream не завершён, приоритет у application и PMTU evidence. Такая маршрутизация сокращает переключения между командами и не превращает NAT64 в универсального виновника.

Итог: переводите адреса, но не смешивайте доказательства

NAT64 и DNS64 дают IPv6-only Pod доступ к IPv4-only LLM API, но это не единый «сетевой переключатель». DNS64 отвечает за синтез адреса, маршрут — за доставку к Pref64, translator — за stateful mapping, а приложение — за TLS и полезный результат. Когда эти доказательства разделены, timeout перестаёт быть загадкой: видно, на каком gate оборвалась цепочка.

Начните с одного hostname и canary workload. Получите A/AAAA внутри Pod, подтвердите route и session, затем проверьте SNI, HTTP и завершение stream. Сохраните native IPv6 и запрещённый destination как negative controls, а rollback прогоните теми же командами. После этого можно обсуждать расширение pool4, HA и выделенную инфраструктуру.

Практический следующий шаг прост: возьмите чек-лист canary из статьи и выполните его на staging с реальным SDK. Если owner map, метрики или rollback пока не сходятся, не расширяйте translation на весь кластер. Сначала сделайте путь наблюдаемым — это дешевле, чем искать редкий reset уже под production-нагрузкой.