# План сетевых экспериментов: 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) — «приложение не участвует» не гарантировано.