docs: исправлены ошибки (TCP backoff, DSR, ping) + ответ Опуса

PROBLEM-AND-SOLUTION.md

@@ -41,7 +41,7 @@ flowchart LR
 - Реальный канал = **1450 байт** → пакет **1500 не влазит**
 - Роутер пытается отправить ICMP «fragmentation needed», но ICMP заблокирован
 - Отправитель не знает что пакет не дошёл, ждёт подтверждения
-- TCP включает exponential backoff: **1с → 3с → 7с → 15с → 25с = 51 секунда**
+- TCP включает exponential backoff от начального RTO 200ms: **0.2с → 0.4с → 0.8с → 1.6с → 3.2с → 6.4с → 12.8с → 25.6с = 51 секунда**
 - Через 51 секунду соединение разрывается → `ERR_TIMED_OUT`
 
 ### Почему не всегда
@@ -86,14 +86,7 @@ kubectl patch svc -n ingress shturval-ingress-controller-controller \
 
 ### Почему 1450
 
-Замер выполнен 2026-07-13:
-
-```
-ping -M do -s 1472  →  Message too large (1500 не проходит)
-ping -M do -s 1422  →  ok (1450 проходит)
-```
-
-Underlay MTU = 1450 → Geneve-туннель = 1400 → поды = 1400.
+Фактический underlay MTU определён через `ping -M do` с временного пода: пакет с флагом DF размером 1500 не проходит, 1450 проходит. Строго говоря, ping измеряет pod MTU (а не underlay напрямую), но эмпирическое подтверждение получено: фикс `mtu: 1450` устранил stall.
 
 ### Почему это безопасно
 
@@ -158,7 +151,7 @@ tcpdump -ni any 'tcp[tcpflags] & tcp-syn != 0' -vv | grep mss
 
 ### Более грамотная альтернатива на будущее
 
-Cilium **DSR + `kubeProxyReplacement`** убирает cross-node SNAT на обратном пути целиком — двойной инкапсуляции return-трафика (главная причина stall) просто не возникает. Но это меняет всю сетевую конфигурацию, для быстрого фикса — избыточно.
+Cilium **DSR + `kubeProxyReplacement`** позволяет поду отвечать клиенту напрямую, минуя обратный путь через ingress и Geneve-туннель. Это устраняет ответную часть задержки, но не решает корневую проблему (stall возникает на входящем пути, клиент → pod). Для быстрого фикса — избыточно.
 
 ### Итоговый вердикт