سرعت پایین مدل Full Tunnel

[mirbaagheri]

درود
من حالت Full Tunnel رو اجرا کردم.
کار میکنه ولی سرعت بسیار پایین هست.
با کمک ChatGPT به این نتیجه رسیدیم که الگوریم و مدل پیاده سازی AppScript و باندل VPS باعث افت سرعت میشه

چند نکته خیلی مهم:
Apps Script برای throughput طراحی نشده
هر request داخل infrastructure گوگل execute میشه
body ها Base64 میشن
JSON encode/decode میشن
UrlFetchApp.fetch انجام میشه
دوباره Base64 میشه
دوباره به کلاینت برمیگرده
یعنی برای هر packet عملا چند لایه processing داری.

خودم بایک دامین پشت SSL کلا دفلیر و بدون کلاد فلیر تست کردم. با کلادفلیر که کار نکرد. با SSL خود VPS کار کرد. ولی سرعت خیلی پایینه
دکتر GPT میگه معماری باید تغییر کنه. مثلا اون قسمت Base64 حذف بشه. این قسمت Base64 تا 33 درصد سربار تولدی میکنه و فشار سنگینی روی پردازنده وارد میکنه.
GAS حذف بشه

الان سیستم polling-based است:

**Client
→ POST
→ GAS
→ VPS

VPS
→ response
→ GAS
→ Client**

مشکل اصلی فعلی، بیشترین bottleneck این‌ها هستند:

هر packet تبدیل می‌شود به:

JSON
Base64
HTTP request

هر بار:

UrlFetchApp.fetch()

اجرا می‌شود.

این realtime نیست.(repeat forever)

باید tunnel را از حالت packet-by-packet relay تبدیل کرد به large chunk multiplexing

با کمک این متد ها سرعت بهینه میشه روی حالت Full:
gzip
chunk packing
compact encoding

بزرگ‌ترین بهبود واقعی برای حالت Ful Tunnel
به جای HTTP POST per packet باید HTTP POST per stream chunk بشود.

therealaleph

[therealaleph]

Reviewed via Anthropic Claude.

@mirbaagheri — your analysis (and ChatGPT's) is partially right, partially missing context:

Correctly identified bottlenecks:

• Base64 overhead ✅ — 33% bandwidth bloat, real cost on hot paths.
• JSON encode/decode per batch ✅ — Apps Script's V8 isolate is slow at this.
• UrlFetchApp call overhead ✅ — Google's edge adds 100-300ms per call regardless of payload.
• HTTP POST per packet ✅ — was true in v1.7 era.

What's already addressed in code (you can skip the upstream-architectural-rewrite suggestion):

1. "HTTP POST per stream chunk instead of per packet" — already done. Look at coalesce_step_ms / coalesce_max_ms in config.json. Default packs up to 1000ms of incoming ops into one batch (50 ops max). Increase coalesce_max_ms: 5000 if you want larger chunks at the cost of latency.

2. "Skip GAS for Full mode" — that's the entire point of Full mode + a VPS with cloudflared / ngrok / domain. You're routing client → Apps Script → tunnel-node, but the tunnel-node is the part that talks to internet directly. The Apps Script middleman exists because direct Iran → VPS over plain HTTPS is what gets DPI'd; Apps Script edge is what bypasses DPI. Without it, the whole project's value goes away.

3. "Base64 removal" — possible but invasive. Apps Script's UrlFetchApp requires response bodies as text or binary blob; pure-binary tunneling without base64 means changing the JSON envelope to a different wire format (e.g. MessagePack or raw multipart). PR feat: zero-copy full-tunnel mux + base64 off mux thread #881 (already merged, v1.9.18) moved base64 encoding off the single mux thread as a halfway measure — saves CPU time, not bytes. Full base64 removal would need a wire-protocol break.

4. "Large chunk multiplexing" — PR feat: per-session pipelining via seq-ordered data ops #903 (in community testing) is exactly this: per-session pipelining with seq-ordered data ops, up to 2 in-flight per session. Track that PR.

5. "H2 vs H1 efficiency" — PR perf: skip H2 for full-tunnel batch requests #1040 (just opened) skips H2 for tunnel-batch requests (where it has nothing to multiplex anyway) while keeping H2 for relay mode. Concrete A/B data: 0/30 vs 8-10/30 long-poll stalls.

v1.9.20 (just shipped) fixed the warm-up race that was costing many users 30s cold-start timeouts. Update first; baseline perf today is meaningfully better than 1 week ago.

For your specific setup (own VPS + SSL, no Cloudflare): you're already on the best Full-mode path. Speed bottleneck remaining is:

• Apps Script's UrlFetchApp 100-300ms RTT per batch (architectural, not bug)
• Plus VPS network latency

For "fast at any cost": don't use mhrv-rs Full mode. Run xray-core with Reality protocol directly on the same VPS. mhrv-rs's value is DPI-bypass + free Apps Script quota; pure speed is a different transport.

می‌بندم — perf work is ongoing (#903 + #1040 active). Update to v1.9.20 + try coalesce_max_ms: 3000 and report back if speed improved.