Nail/IoT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: HISTORY — итоги диагностики: платформа чиста (VM 300с/600с), обрыв только с пути станции (5/5), echo.org чист; план: тест с 3-й точки + тикет

Browse Source
This commit is contained in:
“Naeel”
2026-08-16 08:49:01 +04:00
parent 485f7c6fb1
commit f8c6b3e784
1 changed files with 43 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
HISTORY/2026-08-16-session-log.md
+43
View File
@@ -259,3 +259,46 @@ shared-sqs: «GET /ui через ingress не закрывает соедине
WS-соединений на ~150–173с происходит на краевом шлюзе Nubes.
- Для IoT это значит: wss-устройства будут переподключаться каждые ~2.5–3 мин,
пока шлюз не починят (тикет Nubes, объединить с таймаутами 31–33с и MSS).
### 9.7 Финальные результаты всех тестов
| Тест | Путь | Клиент | Результат |
|---|---|---|---|
| Тест 1 | станция → внешний wss | python | обрыв 173.1с |
| RUN1 | станция → внешний wss | python | обрыв **ровно 173.1с** |
| RUN2 | станция → внешний wss | python | обрыв 163.4с (stall на ~150с) |
| RUN3 | станция → внешний wss | python | обрыв 163.7с (stall на ~150с) |
| VM-ext | ВМ → внешний wss | node+ws | **чисто 300.2с, 29/29 echo** |
| VM-int | ВМ → port-forward → под | node+ws | **чисто 600.1с, 59/59 echo** |
| echo.org | станция → публичный WS-echo | python | **чисто 200с+ (тест 300с)** |
| proxy | станция → прокси 172.17.192.1:10808 → wss | python | обрыв 163.9с (как прямой) |
**Выводы:**
1. Под/сервис/nginx платформы — полностью здоровы (VM-ext 300с чисто,
VM-int 600с чисто; nginx request_time = полное время жизни, ошибок нет).
2. Обрыв воспроизводится ТОЛЬКО с рабочей станции, причём и напрямую, и через
локальный прокси (172.17.192.1:10808) — 5/5 обрывов, точка сбоя ~150с.
3. Публичный WS-echo (echo.websocket.org) с той же станции — ЧИСТО. Значит
сеть станции в целом здорова; страдает именно маршрут станция → Nubes
(185.247.187.151).
4. ВМ (другой маршрут до платформы, p50 6–8мс по данным shared-sqs) — чисто.
5. ⚠️ Нюанс для вывода «шлюз Nubes»: станция и ВМ ходят разными маршрутами.
Если ВМ обходит внешний шлюз Nubes (короткий путь/пиринг) — то «таймер
~150с на внешнем шлюзе Nubes» подтверждается. Если ВМ проходит тот же
шлюз — тогда проблема в маршруте станции (ISP/прокси-сеть). Точно
различить может только тест с третьей независимой точки входа
(другой ISP, мобильная сеть).
6. Взаимосвязь с shared-sqs: таймауты 31–33с (HTTP) и MSS 1448 наблюдались
с той же станции — вероятно, тот же проблемный маршрут/шлюз. Наши данные
добавляют к картине «~150с на долгоживущие соединения».
### 9.8 Следующие шаги (предложены, ждут «делай»)
1. Тест wss с третьей независимой точки (другой ISP/мобильная сеть) — решает
вопрос «шлюз Nubes vs ISP станции».
2. HTTP-цикл с той же станции на /health (запрос каждые 10с, 5 мин) — связать
с таймаутами 31–33с shared-sqs.
3. Тикет в Nubes: wss-соединения с интернета рвутся на ~150с (детерминированно),
+ таймауты 31–33с и MSS 1448 (данные shared-sqs).
4. При проектировании IoT: устройствам нужен MQTT keepalive ≤60с + автореконнект,
а до фикса шлюза — считать интернет-подключения устройств нестабильными
(~2.5–3 мин жизни).