docs: HISTORY — Vultr-тест: обрыв 163.3с идентичен станции — доказано, что ~150с рвёт краевой шлюз Nubes; данные для тикета

This commit is contained in:
“Naeel”
2026-08-16 09:13:06 +04:00
parent f8c6b3e784
commit 031e71b39d
+32
View File
@@ -302,3 +302,35 @@ shared-sqs: «GET /ui через ingress не закрывает соедине
4. При проектировании IoT: устройствам нужен MQTT keepalive ≤60с + автореконнект,
а до фикса шлюза — считать интернет-подключения устройств нестабильными
(~2.5–3 мин жизни).
### 9.9 Тест с третьей точки (Vultr, 95.179.252.111) — ГИПОТЕЗА ПОДТВЕРЖДЕНА
Доступ: `root@95.179.252.111`, ключ `~/.ssh/vultr_openssh` (на ВМ-машине).
Python 3.10, websocket-client 1.9.0 установлен. Тот же скрипт, 300с.
| Тест | Результат |
|---|---|
| Vultr → testiot wss | **обрыв 163.3с** (stall ~150с) — ИДЕНТИЧНО станции |
| Vultr → echo.websocket.org | чисто (175с+, pong 150.1с) |
**ИТОГОВЫЙ ВЫВОД (доказано с трёх точек):**
- Обрыв долгоживущих WS-соединений на ~150с — **на краевом шлюзе платформы
Nubes** (внешний вход 185.247.187.151), а не в поде/ingress и не в ISP клиента:
два независимых интернет-маршрута (станция, Vultr) дают идентичный обрыв,
контрольные публичные WS-echo с обеих точек чисты.
- ВМ 5.172.178.213 ходит коротким маршрутом (p50 6–8мс) и шлюза не касается —
поэтому чиста.
- Внутри платформы (port-forward) всё идеально (600с, 59/59).
- Для IoT: wss-устройства из интернета будут отваливаться каждые ~2.5–3 мин.
Это блокер для прода; тикет Nubes обязателен (объединить с таймаутами 31–33с
и MSS 1448 из shared-sqs — тот же шлюз).
### 9.10 Рекомендации для тикета Nubes (готовы данные)
- Симптом: WS-соединение (wss через edge) детерминированно рвётся на ~150с
при активном трафике (echo каждые 10с, ping/pong 2025с). Доказано:
станция 5/5, Vultr 1/1; nginx внутри видит полную жизнь соединения
(request_time 173.85с), под чист; изнутри кластера и с ВМ — чисто.
- Воспроизведение: `wscat -c wss://testiot.containerk8s.dev.nubes.ru/ws`
(или python websocket-client, ping 25с / echo 10с) — обрыв на 150–173с.
- Связь с shared-sqs: таймауты 3133с (~5.5% HTTP-запросов), MSS=1448 при
MTU 1400 — вероятно, тот же внешний шлюз.