Hysteria2

Hysteria2 کنار Xray روی نود اجرا می‌شود و سرور جداگانه‌ی خودش را دارد، روی UDP. فقط برای یک حالت است: شبکه‌ای که پروتکل‌های مبتنی بر TCP (REALITY و XHTTP روی TCP) رویش بد کار می‌کنند ولی UDP نه.

هر کاربر پنل با همان اشتراکی که دارد می‌تواند از آن استفاده کند: رمز Hysteria2 هر کاربر، همان secret اشتراکش است.

پورت همه‌چیز را تعیین می‌کند

همراه اول UDP را به‌طور کلی خفه نمی‌کند — آن را بر اساس پورت دسته‌بندی می‌کند و با دسته‌ها رفتار خیلی متفاوتی دارد. اندازه‌گیری از یک گوشی همراه اول به همین نود، در حالی که سرور و گواهی و رمز استتار و کاربر همه ثابت بودند و فقط پورت عوض می‌شد:

پورت UDP	معمولاً چه چیزی آنجاست	دانلود	آپلود	تأخیر
۴۴۳	QUIC	مطلقاً هیچ	—	—
۳۶۷۱۸	چیز خاصی نه	بد	بد
۵۳	DNS	۳ مگابیت	۱٫۵ مگابیت	خوب
۱۱۹۴ و ۵۱۸۲۰	OpenVPN و WireGuard	خوب	—	بد
۸۸۰۱	مدیای Zoom	۴۰ مگابیت	۳٫۵ مگابیت	خوب

همان سرور، همان همه‌چیز: ۳ مگابیت روی پورت ۵۳ در برابر ۴۰ مگابیت روی پورت ۸۸۰۱ — و آن ۴۰ در پرترافیک‌ترین ساعت شبانه‌روز اندازه‌گیری شد. هیچ‌چیز دیگری در این صفحه به اندازه‌ی آن یک سطر مهم نیست.

الگویی که پشتش است ارزش نگه داشتن دارد، چون می‌گوید اگر روزی ۸۸۰۱ هم خفه شد، سراغ کدام پورت برویم:

• پورتی که انتظار می‌رود ترافیکش کوچک باشد، در جهتی که بزرگ می‌شود سقف می‌خورد. پورت ۵۳ آپلود را آزاد رد کرد، چون بسته‌های بالارو آنجا شبیه پرس‌وجوی DNS‌اند — ولی دانلود را حدود ۳ مگابیت سقف زد، چون پاسخ DNS قرار است کوچک باشد، و سیل بسته‌ی بزرگ از پورت ۵۳ دقیقاً همان چیزی است که سیستم‌های تشخیص تونل DNS برای گرفتنش ساخته شده‌اند.
• پورت‌های VPN حجم را رد می‌کنند ولی از نظر تأخیر محافظت‌شده نیستند. ۱۱۹۴ و ۵۱۸۲۰ حجم را جابه‌جا کردند و باز استفاده‌شان بد بود.
• آنچه کار می‌کند، ترافیکی است که اپراتور توان خراب کردنش را ندارد. تماس تصویری هم‌زمان به پهنای باند بالا در هر دو جهت و به تأخیر کم نیاز دارد، پس اپراتوری که محدودش کند تماس تصویری مشترک خودش را می‌شکند. پورت مدیای Zoom برنده شد؛ کاندیداهای دیگر همان دسته — ۳۴۷۸ (WebRTC/STUN) و ۱۹۳۰۲ (Google Meet) — گزینه‌های بعدی‌اند و هر دو روی این سرور امتحان و تأیید شدند.

این یک برداشت غلط را هم که قبلاً در همین صفحه ثبت شده بود تصحیح می‌کند: یک تست روی یک پورت بالای تصادفی حدود ۱۰ مگابیت دانلود داد و نتیجه گرفته شد که سقف مسیر همان است. آن تست throttle همان دسته‌ی پورت را اندازه می‌گرفت، نه مسیر را. مسیر ۴۰ می‌دهد.

آپلود سقف واقعی است، و ACKهای دانلود هم از همان مسیر می‌روند

آپلود حدود ۳٫۵ مگابیت می‌نشیند و این ظرفیت واقعی است، نه محصول محدودسازی. فرض نشد، امتحان شد: گمان می‌رفت BBR بسته‌های عمداً افتاده‌ی همراه اول را ازدحام می‌خواند و خودش را زیر نرخ واقعی پارک می‌کند، پس سرور طوری تنظیم شد که نرخ اعلام‌شده‌ی کلاینت را بپذیرد (ignoreClientBandwidth: false به‌همراه سقف‌های bandwidth) و به کلاینت گفته شد ۶ مگابیت آپلود اعلام کند، که آپلودش را می‌برد روی Brutal — کنترل‌کننده‌ای که با نرخ ثابت می‌فرستد و افتادن بسته را نوفه می‌گیرد. نتیجه خیلی بدتر شد، و بدتر در هر دو جهت: ACKهای QUIC مربوط به دانلود هم از همان مسیر آپلود می‌روند، پس فشار اضافی روی آپلود دانلود را هم خراب می‌کند. برگردانده شد، و ایجنت به همین دلیل ignoreClientBandwidth: true را نگه می‌دارد.

دو چیز از این نتیجه می‌شود. Hysteria2 در جهت آپلود هنوز از یک پروتکل TCP بهتر است، چون TCP آن گم‌شدن را ازدحام می‌خواند و فرو می‌ریزد — ۰٫۱۲ مگابیت اندازه‌گیری‌شده در برابر ۱٫۲ روی یک پورت خفه‌شده؛ و هر چیزی که مرورگر می‌فرستد از مسیر آپلود می‌رود، پس همین است که صفحه‌ها شروع می‌شوند به‌جای اینکه هنگ کنند. و برای آپلود هیچ تنظیمی نمانده: جای خالی ندارد، و Hysteria2 تصحیح خطای رو‌به‌جلو (FEC) ندارد، پس بسته‌ی گم‌شده‌ی بالارو فقط دوباره فرستاده می‌شود. پروتکلی که به خود گم‌شدن حمله می‌کند FEC دارد — mKCP خود Xray — که روی این مسیر امتحان نشده و برخلاف Hysteria2 داخل همان ماشین Core و Inbound خود پنل جا می‌گیرد.

چه چیزهایی لازم است تا از داخل ایران کار کند

• استتار الزامی است. هندشیک لخت Hysteria2 یک هندشیک QUIC است و شبکه‌های ایران آن را کاملاً می‌اندازند. با obfs: salamander بسته‌ی اول شبیه هیچ پروتکل مشخصی نیست.
• پورت بزرگ‌ترین اهرم است، همان‌طور که بالا آمد. نه UDP 443 که از داخل ایران مطلقاً هیچ جوابی نداد، نه روی موبایل نه روی خط ثابت — و نه یک پورت بالای تصادفی، که اندازه‌گیری‌اش بد بود. پورتی را بردارید که اپراتور مجبور است دسته‌ی ترافیکش را سالم نگه دارد.
• پنجره‌های بزرگ QUIC، چون مسیر ایران تا سرور خارج تأخیر بالایی دارد.

راه‌اندازی

۱. هسته‌ها ← Hysteria2 ← هسته‌ی جدید. پورت UDP (طبق جدول بالا ۸۸۰۱)، رمز استتار و سقف نرخ (روی همراه اول ۱۵ مگابیت بهترین بود؛ خالی یعنی بدون سقف). ۲. روی کارت همان هسته، نودی را که باید اجرایش کند انتخاب کنید. ایجنت نود خودش hysteria server را اجرا می‌کند و سقف نرخ را روی خروجی همان پورت می‌گذارد. ۳. هاست‌ها ← هاست جدید، پروتکل Hysteria2، روی همان هسته. پورت و رمز استتار از هسته می‌آیند؛ نشانی و SNI باید با گواهی TLS نود جور باشند.

این کانفیگ را ایجنت می‌نویسد؛ کلیدهای زیر همان‌هایی‌اند که می‌گذارد.

کلیدهایی که ایجنت می‌گذارد، و چرا

ignoreClientBandwidth: true. ‏Hysteria2 دو کنترل‌کننده‌ی ازدحام دارد. BBR مسیر را اندازه می‌گیرد و خودش را تنظیم می‌کند. Brutal با نرخی که به او گفته‌اند می‌فرستد و گم‌شدن بسته را نوفه می‌گیرد نه نشانه‌ی اینکه باید آهسته‌تر برود — که روی خطی واقعاً سریع ولی پرگم‌شدن انتخاب درستی است، و وقتی نرخ اعلام‌شده غلط باشد فاجعه است. سرور به حال خود رها شود، هر نرخی که اپ کلاینت اعلام کند همان را اطاعت می‌کند؛ پس اپی که در فیلد پهنای باندش «۱۰۰ مگابیت» نوشته شده، سرور را روی Brutal می‌برد داخل هر سقفی که اپراتور برای آن دسته‌ی پورت نگه داشته، جایی که هزینه‌ی رد شدن از سقف گم‌شدن سنگین بسته است — و آن آزمایش آپلود که بالا آمد نشان داد چقدر بد تمام می‌شود. این کلید کاری می‌کند که سرور آن اعلام را نادیده بگیرد و به کلاینت هم بگوید همین کار را بکند، پس نتیجه دیگر به تنظیمات اپ یک غریبه بند نیست. روی یک سرور موقت هر دو حالت امتحان شد: با کلید خاموش، کلاینتی که ۱۰۰ مگابیت اعلام می‌کرد در لاگ client connected {"tx": 12500000} ثبت شد؛ با کلید روشن، همان کلاینت tx: 0 ثبت شد، که یعنی BBR.

لینک‌های خود تیفوسی هیچ عددی اعلام نمی‌کنند، پس همه‌ی خطوط واقعی client connected از قبل tx: 0 بودند — این یک محافظ است، نه رفع اشکالی که در حال رخ دادن بود. آن آزمایش آپلود که بالا توضیح داده شد، تنها باری بود که عمداً خاموشش کردیم، و فوراً برگشت سر جایش.

bbrProfile: conservative. گین‌های پایین‌تر از BBR استاندارد، صفی که می‌سازد را تخلیه می‌کند، و وقتی بفهمد از سقف رد شده نرخش را پایین می‌آورد. این شکل درست برای مسیری است که policing می‌کند — عمداً می‌اندازد تا نرخ را نگه دارد — نه مسیری که صف می‌کند؛ و تأخیر را پایین نگه می‌دارد، که در عمل همان چیزی است که تعیین می‌کند یوتیوب و اینستاگرام قابل استفاده باشند یا نه. این تنظیم موقع اندازه‌گیری ۴۰ مگابیت فعال بود، پس می‌ماند.

maxIdleTimeout: 60s. پیش‌فرض هستریا ۳۰ ثانیه است، و روی همراه اول هر اتصال تقریباً دقیقاً همان‌جا می‌مرد:

13:51:28  client connected     {"addr": "37.63.232.153", "tx": 0}
13:51:59  client disconnected  {"error": "accepting stream failed: timeout: no recent network activity"}
13:52:12  client connected     {"addr": "83.121.224.193", "tx": 0}
13:52:45  client disconnected  {"error": "... no recent network activity"}

شبکه مقصر نبود: همان مسیر همراه اول یک نشست UDP را از ۶۰ ثانیه سکوت زنده رد کرد و به یک جریان ۹۰ ثانیه‌ای بدون انداختن جواب داد. آن‌ها تایمر بیکاری بودند که روی مسیری زنده شلیک می‌شد، و هزینه‌ی هر بار یک هندشیک تازه است روی مسیر آپلودی که ۳۰٪ بسته را گم می‌کند — و این همان حسی است که می‌گویید «وصل می‌شود و بعد هر چند لحظه گیر می‌کند».

اما دقیق باشیم که این کلید چه می‌کند و چه نمی‌کند. QUIC کمتر از دو مقدار اعلام‌شده‌ی دو طرف را برمی‌دارد، پس بالا بردنش روی سرور برای کلاینتی که همچنان ۳۰ ثانیه اعلام می‌کند هیچ تغییری نمی‌دهد؛ و تنظیمی که واقعاً جلوی شلیک تایمر را می‌گیرد keepAlivePeriod سمت کلاینت است. آن یکی از راه اشتراک دست‌یافتنی نیست: mihomo و sing-box و لینک hysteria2:// هیچ‌کدام فیلد keepalive یا idle timeout ندارند و فقط کانفیگ YAML کلاینت رسمی دارد. پس سمت سرور اینجا بالا برده شده برای کلاینت‌هایی که همراهی کنند، و آن چرخه‌ی وصل‌و‌قطع شدن یک محدودیت باقی‌مانده‌ی شناخته‌شده است، نه چیزی که پنل بتواند تنظیمش کند.

پنل چطور کنترلش می‌کند

• احراز هویت. برای هر اتصال جدید Hysteria2 از ایجنت نود می‌پرسد، و ایجنت سؤال را با کلید API نود به پنل می‌فرستد؛ پس هیچ رازی از پنل روی نود نمی‌ماند. پنل فقط برای کاربر active که Hysteria2 جزو پروتکل‌های مجازش است جواب مثبت می‌دهد.
• شمارش حجم. در هر چرخه، پنل شمارنده‌های Hysteria2 را از طریق ایجنت نود می‌خواند (/hysteria/stats، که با خواندن صفر می‌شوند، دقیقاً مثل Xray) و به مصرف کاربر اضافه می‌کند، پس سقف حجم همه‌ی بایت‌ها را می‌بیند. روی نود واقعی سنجیده شد: ۱۰٬۰۰۰٬۰۰۰ بایت عبوری، ۱۰٬۰۰۷٬۹۸۴ بایت شمرده شد.
• قطع کردن. وقتی کاربر منقضی یا محدود یا غیرفعال می‌شود، پنل از Hysteria2 می‌خواهد قطعش کند (/hysteria/kick). Hysteria2 در اولین ترافیک بعدی آن اتصال اعمالش می‌کند — اتصال بیکار تا وقتی بایتی رد نکند باز می‌ماند، و در هر صورت کاربر دیگر نمی‌تواند وصل شود.

محدودیت‌ها

• هر نود یک هسته‌ی Hysteria2.
• رمز استتار بین همه‌ی کاربران مشترک است؛ شکل ترافیک را پنهان می‌کند و هویت کسی را نشان نمی‌دهد.
• فعلاً فقط روی ماشین خود پنل. Hysteria2 گواهی TLS متناسب با SNI لازم دارد؛ ایجنت از گواهی پنل استفاده می‌کند که از /opt/tifusi-panel/certs mount شده. نودی روی ماشین دیگر آنجا گواهی ندارد، و هسته‌ی Hysteria2 که به آن داده شود بالا نمی‌آید.
• چرخه‌ی وصل‌و‌قطع شدن روی مسیرهای موبایل پرگم‌شدن، همان‌طور که بالا توضیح داده شد: پنل از هیچ قالب اشتراکی نمی‌تواند keepalive کلاینت را تنظیم کند.