tcp_proxy: fix throughput (tx_queue backpressure) + connect timeout + integration test
- Router: unified service delivery format [svc_id][src][dst][payload] (end-to-end src/dst from SVC_ROUTE header) - tcp_proxy_client: replace single tx_buf drop-on-backpressure with bounded tx_queue + send_q waiter + retry timer (no data loss, bulk window reopen — removes 62.5ms delayed-ACK stall) - tcp_io: configurable connect timeout (tcp_conn_set_connect_timeout) - tcp_proxy_server: connect_timeout config option (ms, default 2000, 0=off) - check.sh: run tcp_proxy_full integration test with sudo (skip if passwordless sudo unavailable) - test_tcp_io: connect timeout unit test; docs (lwip_nuances.md)
This commit is contained in:
evgeny committed
1 parent
acfaae2801
commit
f47ad7d87f
36 files changed
+758
-269
No files matched your search
@@ -0,0 +1,115 @@
|
||||
# Задача: продолжить исправление TCP-proxy (крупные файлы через транзит)
|
||||
|
||||
Продолжение незавершённой работы. Читай целиком, прежде чем что-то менять.
|
||||
|
||||
## 1. Что уже сделано (НЕ переделывать)
|
||||
|
||||
Унифицирован формат доставки сервисных кодограмм роутером. Раньше сервисы определяли
|
||||
источник через `conn->peer_node_id`, что ломало транзит (при промежуточном узле это был
|
||||
id промежуточного, а не реального клиента).
|
||||
|
||||
Теперь роутер доставляет сервисам единый формат:
|
||||
|
||||
```
|
||||
[svc_id(1)][src_node_id(8)][dst_node_id(8)][payload...]
|
||||
```
|
||||
|
||||
где src/dst — реальные end-to-end узлы из SVC_ROUTE заголовка.
|
||||
|
||||
Ключевые константы в `src/routing_layer/etcp_router.h`:
|
||||
`ROUTER_SVC_SRC_OFF=1`, `ROUTER_SVC_DST_OFF=9`, `ROUTER_SVC_PAYLOAD_OFF=17`, `ROUTER_SVC_HDR_SIZE=17`.
|
||||
|
||||
Изменённые файлы (все в некоммиченном состоянии, `git status`):
|
||||
- `src/routing_layer/etcp_router.{h,c}` — `router_deliver` + `router_deliver_loopback` + CLOSE/RESTART
|
||||
- `src/proxy/tcp_proxy_server.{h,c}` — recv +8→+16 сдвиг, `src_node_id` из `dgram[1..8]`
|
||||
- `src/proxy/tcp_proxy_client.{h,c}` — recv сдвиг + счётчики `bytes_to_exit/from_exit/bp_count`
|
||||
- `src/proxy/udp_proxy.{h,c}`, `src/proxy/icmp_proxy.{h,c}` — сдвиг + убран встроенный node_id
|
||||
- `src/nat_transport.c` — убран встроенный node_id
|
||||
- `src/routing_layer/routing.c`, `conn_mgr_core.c` — сдвиг
|
||||
- `src/media_delivery/media_delivery.c` — сдвиг + `from_node` из `dgram[1..8]`
|
||||
- `tools/chatgui/transport/utun_node.cpp` — сдвиг
|
||||
- тесты `tests/test_etcp_router*.c`, `test_udp_proxy.c`, `test_icmp_proxy.c`, `test_nat_transport.c`
|
||||
- `tests/tcp_proxy_full/` — добавлен `intermediate.conf` (3-узловая топология), обновлены `client.conf`/`exit.conf`/`run_test.sh`
|
||||
|
||||
**Статус проверки: `./check.sh` = 73 passed, 0 failed, 1 skipped.** Форматная часть ВЕРНА.
|
||||
|
||||
## 2. Что осталось (собственно задача)
|
||||
|
||||
Интеграционный тест прокси `tests/tcp_proxy_full/run_test.sh` (нужен sudo) — крупные
|
||||
передачи НЕ проходят. Проверено: проблема **НЕ в формате и НЕ в транзите** — прямой
|
||||
2-узловой прогон падает идентично. Это предсуществующая проблема прокси/lwIP.
|
||||
|
||||
Результат `sudo ./tests/tcp_proxy_full/run_test.sh`:
|
||||
- `idle` (32 КБ) — PASS
|
||||
- `half_close` (64 КБ) — 64280/65536 (почти, теряется хвост)
|
||||
- `basic_1mb` (1 МБ), `concurrent_*`, `stress` — FAIL (timeout)
|
||||
|
||||
## 3. Диагноз (уже установлен по логам)
|
||||
|
||||
Пропускная способность ~24 КБ/с (1 пакет 1460 байт за ~60 мс). Для 1 МБ это ~43 с → таймаут 10 с.
|
||||
|
||||
Цепочка (видна в добавленных логах `PROXY BP *` и `SEND_Q_ACKED`):
|
||||
1. Клиент быстро шлёт 320 пакетов (initial burst ~33 МБ/с).
|
||||
2. Роутерный `send_q` переполняется (`router_send_q: FULL count=64`) → `etcp_route_send` возвращает -1.
|
||||
3. Прокси в `tcp_proxy_client_recv_cb` ставит одиночный `tx_buf` и **сбрасывает** дальнейшие данные
|
||||
(`if (pc->tx_buf) { pbuf_free(p); return; }`) — лог `PROXY BP drop`, без `tcp_recved` → окно lwIP схлопывается.
|
||||
4. Клиент вырождается в режим «1 пакет за ~60 мс».
|
||||
5. ~60 мс = таймер lwIP: `ctx->tmr_interval_ms = TCP_TMR_INTERVAL / 4` = 62.5 мс (`src/lwip_tcp/lwip_tcp.c:106`).
|
||||
В режиме «пакет-за-пакетом» lwIP не шлёт ACK сразу (порог `TCP_WND_UPDATE_THRESHOLD = TCP_WND/4 = 2920`
|
||||
не набирается за 1 пакет), и отложенный ACK уходит только по `tcp_fasttmr` раз в 62.5 мс.
|
||||
|
||||
Триггер — сброс данных при backpressure в прокси (`tcp_proxy_client.c`), НЕ lwIP.
|
||||
|
||||
## 4. Ограничения (ВАЖНО)
|
||||
|
||||
- **В `src/lwip_tcp/` ничего НЕ править без явного согласования пользователя. Разрешён только debug-лог.**
|
||||
- Правки исходников только через Edit tool (никакого sed для массовых замен).
|
||||
- Ошибки/нештатные ветки — обязательно `DEBUG_ERROR/DEBUG_WARN`.
|
||||
- Логи информативные, без спама. Debug-категории: `proxy`, `etcp_route`.
|
||||
- Перед сборкой `make clean`.
|
||||
|
||||
## 5. План продолжения
|
||||
|
||||
Шаг 1 (диагностика, закрыть пробел — по желанию, уже почти доказано):
|
||||
- Добавить в lwIP только DEBUG-лог (разрешено): в `tcp_fasttmr` — счётчик отложенных ACK; в `tcp_recved` — `rcv_wnd`.
|
||||
- В прокси (`tcp_proxy_client.c`, НЕ lwIP) в момент `BP drop` лог `pcb->rcv_wnd`.
|
||||
- Подтвердить, что 62.5 мс — это отложенный ACK.
|
||||
|
||||
Шаг 2 (фикс, требуется согласование — предложи пользователю):
|
||||
- **Вариант A (предпочтительно, НЕ lwIP):** в прокси заменить одиночный `tx_buf` + сброс на очередь с backpressure
|
||||
(буферизовать все пакеты во время backpressure, не сбрасывать; `tcp_recved` вызывать по мере отправки).
|
||||
Тогда окно закрывается плавно, OS TCP не сваливается в congestion avoidance, деградации нет.
|
||||
Смотри `struct tcp_proxy_client_conn` в `tcp_proxy_client.h` (сейчас: `tx_buf`/`tx_len`/`tx_waiter`).
|
||||
Для образца очереди с backpressure смотри `src/proxy/tcp_proxy_server.c` (там `read_queue` + `pause_waiter`).
|
||||
- **Вариант B (lwIP, только по согласованию):** уменьшить `tmr_interval_ms` (`TCP_TMR_INTERVAL/4` → чаще),
|
||||
либо повысить `TCP_WND_UPDATE_THRESHOLD`/`TCP_WND`, чтобы ACK слался сразу.
|
||||
|
||||
Шаг 3 (почистить тестовую обвязку):
|
||||
- В `tests/tcp_proxy_full/*.conf` сейчас включены отладочные уровни (`etcp_route=trace`, `proxy=trace`) —
|
||||
перед коммитом вернуть к разумным (`etcp_route=debug`/`proxy=debug` или `error`).
|
||||
- Решить: оставить добавленные в `tcp_proxy_client.c` счётчики/BP-логи или вычистить.
|
||||
- В `run_test.sh` тайминги `elapsed` через `date +%s%3N` дают мусор в этой среде — поправить (например `date +%s`
|
||||
без миллисекунд, или `SECONDS`). Stress-таймаут `60s` можно уменьшить до ~15-20s.
|
||||
|
||||
## 6. Сборка и тест
|
||||
|
||||
```bash
|
||||
./build.sh --full -j4 # или make -j4 (после make clean)
|
||||
./check.sh # unit-тесты: должны остаться 73 passed
|
||||
cp src/utun utun # обновить корневой бинарник для run_test.sh!
|
||||
sudo ./tests/tcp_proxy_full/run_test.sh # интеграционный (нужен root/TUN/iptables)
|
||||
```
|
||||
|
||||
Важно: `run_test.sh` использует `UTUN_BIN="$SCRIPT_DIR/../../utun"` (корневой `utun`), а `make` собирает
|
||||
`src/utun`. После каждой пересборки делать `cp src/utun utun`.
|
||||
|
||||
## 7. Как быстро убедиться, что фикс помог
|
||||
|
||||
Прогнать `basic_1mb` и смотреть лог клиента `tests/tcp_proxy_full/log/client_utun.log`:
|
||||
- ДО фикса: `PROXY BP drop` + `SEND_Q_ACKED` с интервалом ~60 мс.
|
||||
- ПОСЛЕ фикса: нет `BP drop`, интервал ACK ~10 мс, `basic_1mb` PASS.
|
||||
|
||||
Полезные grep-и по логу клиента:
|
||||
```
|
||||
grep -E "PROXY BP|SEND_Q_ACKED|PROXY FIN" client_utun.log
|
||||
```
|
||||
@@ -0,0 +1,66 @@
|
||||
# Важные нюансы работы встроенного lwIP TCP-стека
|
||||
|
||||
Краткая памятка по тонким местам `src/lwip_tcp/`, критичным для прокси.
|
||||
Полное описание модуля — в `src/lwip_tcp/lwip_tcp_doc.md`.
|
||||
|
||||
## Ключевые константы (`lwip_tcp_opts.h`)
|
||||
|
||||
| Константа | Значение | Смысл |
|
||||
|-----------|----------|-------|
|
||||
| `TCP_MSS` | 1460 | максимальный размер сегмента |
|
||||
| `TCP_WND` | 8×MSS = 11680 | окно приёма lwIP (объявляется пиру) |
|
||||
| `TCP_SND_BUF` | 16×MSS = 23360 | буфер отправки |
|
||||
| `TCP_TMR_INTERVAL` | 250 мс | базовый интервал таймера |
|
||||
| `tmr_interval_ms` | `TCP_TMR_INTERVAL/4` = 62.5 мс | фактический шаг `tcp_fasttmr` |
|
||||
| `TCP_WND_UPDATE_THRESHOLD` | `TCP_WND/4` = 2920 | порог немедленного ACK окна |
|
||||
|
||||
**Важно:** таймер uasync использует timebase 0.1 мс — `uasync_set_timeout(ua, N, …)`
|
||||
задаёт N×0.1 мс. Например, 5000 = 500 мс.
|
||||
|
||||
## Контракт recv_cb — главный источник багов
|
||||
|
||||
lwIP вызывает `recv_cb(arg, pcb, pbuf, err)` для данных, **уже извлечённых из pcb**.
|
||||
Дальше приложение само решает судьбу данных и окна:
|
||||
|
||||
| Действие | Результат |
|
||||
|----------|-----------|
|
||||
| скопировать + `tcp_recved(pcb, len)` | данные приняты, окно восстановлено (норма) |
|
||||
| `return != LERR_OK` | lwIP кладёт pbuf в `refused_data` и отдаст позже — **без потери**, окно закрывается |
|
||||
| `pbuf_free(p)` без `tcp_recved` | данные потеряны, окно не восстановлено → схлопывание окна |
|
||||
|
||||
`refused_data` — штатный backpressure lwIP: одноканальный (один pbuf), ре-доставка
|
||||
через `tcp_fasttmr` (62.5 мс) или при следующем входящем сегменте.
|
||||
|
||||
**Ошибка, из-за которой падал `tcp_proxy_full`:** при backpressure прокси делал
|
||||
`pbuf_free(p)` без `tcp_recved`. Каждый такой сброс уменьшал `rcv_wnd` на MSS; после
|
||||
~8 пакетов окно падало в 0, OS-TCP переставал слать, и передача умирала.
|
||||
|
||||
## Управление окном и «деградация 62.5 мс»
|
||||
|
||||
`tcp_recved(pcb, len)` увеличивает `rcv_wnd` и через `tcp_update_rcv_ann_wnd` решает,
|
||||
слать ли ACK окна немедленно. Немедленный ACK идёт только если прирост окна
|
||||
`wnd_inflation ≥ TCP_WND_UPDATE_THRESHOLD` (=2920 = 2×MSS); иначе ACK откладывается
|
||||
до `tcp_fasttmr` (62.5 мс).
|
||||
|
||||
Отсюда классическая ловушка: если после backpressure окно восстанавливать **по одному
|
||||
пакету** (`tcp_recved(1460)` за раз), прирост 1460 < 2920 → ACK уходит раз в 62.5 мс →
|
||||
пир шлёт 1 пакет за 62.5 мс ≈ 23 КБ/с. Это выглядит как «пропускная способность
|
||||
застряла», хотя сеть свободна.
|
||||
|
||||
**Правильно:** восстанавливать окно **пачкой** (несколько `tcp_recved` подряд либо один
|
||||
`tcp_recved(TCP_WND_MAX - rcv_wnd)`), тогда прирост ≥ 2920 → ACK немедленный → пир
|
||||
сразу возобновляет бурст.
|
||||
|
||||
## Рекомендуемый паттерн для relay-потребителя (как в `tcp_proxy_client.c`)
|
||||
|
||||
1. При получении данных — копировать в ограниченную очередь, **не вызывать**
|
||||
`tcp_recved` (окно само плавно закрывается; очередь ограничена `TCP_WND`).
|
||||
2. Дрейн очереди по сигналу освобождения нижележащего канала
|
||||
(`etcp_router_on_send_ready`) + retry-таймер (force=1) как safety-net.
|
||||
3. `tcp_recved(len)` вызывать **только после успешной отправки** — окно
|
||||
восстанавливается пачкой по мере дрена, ACK уходит немедленно.
|
||||
4. Никогда не сбрасывать pbuf без `tcp_recved`; не держать данные в `refused_data`
|
||||
дольше одного пакета (single-slot).
|
||||
|
||||
См. реализацию: `tcp_proxy_client_tx_queue_drain_cb` / `tcp_proxy_client_fin_flush`
|
||||
в `src/proxy/tcp_proxy_client.c`.
|
||||
Reference in new issue
Block a user