From f8c6b3e78424a3e054ce72664461632e1533ec68 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CNaeel=E2=80=9D?= Date: Sun, 16 Aug 2026 08:49:01 +0400 Subject: [PATCH] =?UTF-8?q?docs:=20HISTORY=20=E2=80=94=20=D0=B8=D1=82?= =?UTF-8?q?=D0=BE=D0=B3=D0=B8=20=D0=B4=D0=B8=D0=B0=D0=B3=D0=BD=D0=BE=D1=81?= =?UTF-8?q?=D1=82=D0=B8=D0=BA=D0=B8:=20=D0=BF=D0=BB=D0=B0=D1=82=D1=84?= =?UTF-8?q?=D0=BE=D1=80=D0=BC=D0=B0=20=D1=87=D0=B8=D1=81=D1=82=D0=B0=20(VM?= =?UTF-8?q?=20300=D1=81/600=D1=81),=20=D0=BE=D0=B1=D1=80=D1=8B=D0=B2=20?= =?UTF-8?q?=D1=82=D0=BE=D0=BB=D1=8C=D0=BA=D0=BE=20=D1=81=20=D0=BF=D1=83?= =?UTF-8?q?=D1=82=D0=B8=20=D1=81=D1=82=D0=B0=D0=BD=D1=86=D0=B8=D0=B8=20(5/?= =?UTF-8?q?5),=20echo.org=20=D1=87=D0=B8=D1=81=D1=82;=20=D0=BF=D0=BB=D0=B0?= =?UTF-8?q?=D0=BD:=20=D1=82=D0=B5=D1=81=D1=82=20=D1=81=203-=D0=B9=20=D1=82?= =?UTF-8?q?=D0=BE=D1=87=D0=BA=D0=B8=20+=20=D1=82=D0=B8=D0=BA=D0=B5=D1=82?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- HISTORY/2026-08-16-session-log.md | 43 +++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/HISTORY/2026-08-16-session-log.md b/HISTORY/2026-08-16-session-log.md index 679abfe..0441c59 100644 --- a/HISTORY/2026-08-16-session-log.md +++ b/HISTORY/2026-08-16-session-log.md @@ -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 мин жизни).