SQS-service/doc/thinking/nubes-network-bug-plan.md

План сетевых экспериментов: shared-sqs на Nubes

⚠️ ПОМЕТКА: анализ от СЛАБОГО агента — DeepSeek V4 Flash (не Соннет). Пользователь по ошибке задал вопрос DeepSeek V4 Flash вместо Соннета. План сохранён как рабочий черновик; критику основного агента см. в HISTORY (2026-08-15) и в конце беседы. Технические неточности Flash см. ниже в разделах «Поправки основного агента».

Контекст

Платформа Nubes (managed Kubernetes). Сервис shared-sqs (SQS-очередь, Go, HTTP 4100). С ВМ внутри сети p50 = 6–8 мс, таймаутов нет. С интернета — проблемы.

Два независимых явления:

1. Большие POST (>~1400 байт) виснут ~51 с — объясняется MTU/MSS 1448 (пакеты 1488 > underlay 1450, дроп).
2. Малые тела (512 байт): 49 из 888 запросов ReadTimeout 30 с, равномерно ~1 в 37 с — MTU-моделью НЕ объясняется. Второй независимый источник потерь.

Топология: клиент → 185.247.187.151:32391 (kube-vip NodePort) → shturval-ingress-controller (nginx, ns ingress) → Cilium (pod mtu=1400) → под.

---

1. Echo-сервис или сырые TCP?

Сырых TCP недостаточно (проверяют только установление). Echo нужен, но:

1. Тот же путь: тот же кластер, тот же ingress (отдельный host/path), тот же Cilium.
2. Echo должен возвращать тело запроса (не «pong»), чтобы гонять тела 1400/1500/2000 байт в обе стороны.
3. Тот же network policy/namespace.

2. Как поймать момент таймаута

tcpdump с локали (нет доступа к нодам):

• захват: tcpdump -i any -nn -s 0 'host 185.247.187.151 and port 32391' -w /tmp/cap.pcap
• смотреть: SYN/ретрасмиты/RST/DUP ACK/сегменты >1450 с DF.
• ss -ti на установленном соединении → реальный MSS.

Признаки:

Признак	Значение
SYN→SYN-ACK, потом тишина на данных	потери после установления (nginx/Cilium/под)
ретрасмиты SYN	потери на установлении (kube-vip/NodePort/шлюз)
ретрасмиты с растущим RTO (1,2,4,8,16,30+)	потеря пакета
сегменты >1450 с DF без ответа	MTU-гипотеза
RST	смотреть кто шлёт (платформа vs приложение)

Вместо tcpdump на нодах — kubectl:

• cilium monitor --type drop — дропы с причинами (MTU/policy/conntrack).
• Логи nginx-ingress.

3. kube-vip / NodePort / nginx — проверка через kubectl

Декомпозиция по access-log nginx:

• запись есть → дошло до nginx → проблема после nginx.
• записи нет → потеря до nginx (kube-vip/NodePort/шлюз).

Метрики: request_time vs upstream_response_time:

• request_time≈30с, upstream мал → задержка между nginx и клиентом (обратный путь/шлюз).
• upstream≈30с → задержка nginx→под (Cilium/наш под).

Проверки:

• kubectl -n kube-system get pods -o wide | grep kube-vip + логи.
• kubectl -n ingress get svc -o yaml — nodePort 32391, externalTrafficPolicy (Local → обслуживает только нода с VIP; Cluster → SNAT через любую ноду).
• access-log nginx с таймингами.

Дешёвый тест без приложения: GET на несуществующий путь через тот же NodePort (ответит nginx default backend) — если GET без тела стабилен, а POST теряется — потери в передаче данных.

4. План «дешевле → дороже»

1. Анализ access-log nginx за 30-мин тест (бесплатно).
2. Connect-тест 32391: 1000+ соединений, мерить connect (бесплатно).
3. GET без тела, 1000+ запросов (бесплатно).
4. tcpdump с локали + стрельба POST 512 и 1500 байт, поймать 2–3 таймаута в pcap.
5. Echo-сервис на ту же платформу (средняя стоимость).
6. cilium monitor параллельно со стрельбой.
7. Матрица размеров тел 512/1000/1400/1450/1500/2000 × 15+ мин через echo
   • контрольный канал к YMQ.
8. Тикет платформе с пачкой доказательств.

Критический вопрос: малые тела теряются ~1 раз в 37 с. Кандидаты: потери на шлюзе, ARP/leader kube-vip, conntrack GC Cilium. Шаги 4–6 должны их разделить.

---

Поправки основного агента (GitHub Copilot)

1. Ошибка Flash: kubectl exec -n kube-system deploy/cilium-operator -- cilium monitor — неверно. cilium monitor запускается на cilium-поде (DaemonSet): kubectl exec -n kube-system <cilium-pod> -- cilium monitor --type drop. И только на ноде, где живёт интересующий под.
2. Приоритеты: echo-сервис — НИЖЕ по ценности, чем кажется. Уже известно, что с ВМ таймаутов нет → проблема между интернетом и внутренней сетью (kube-vip/NodePort/шлюз), а echo сидит внутри. Сначала: nginx-логи (ш.1), tcpdump (ш.4), cilium monitor (ш.6) — они дешёвые и локализуют лучше.
3. WSL-нюанс: tcpdump на локальной WSL-машине может требовать sudo и конкретного интерфейса (-i any работает не всегда).
4. Шаг 7 дорогой: 7 размеров × 15 мин ≈ 2 часа. Достаточно 512/1400/1450/ 1500/2000 × 10 мин, порог искать бинарно.
5. Шаг 3 неточен: GET на несуществующий путь того же host может уйти в наш под (его router отдаст 400/404) — «приложение не участвует» не гарантировано.