کلی بررسی کردیم که چرا روی سرور رسپینا با ماتریکس تانل زدیم و ترافیک از ۳۰ مگابیت بالاتر نمیره! فکر می کنید دلیل چی بود:

Crypto speeds: AES_128_GCM: 13.5 MiB/s, AES_256_GCM: 5.7 MiB/s, CHACHA20_POLY1305: 54.0 MiB/s

سرعت انکریپشن پردازنده نهایتا ۵۴ مگ در بهترین حالت بود. و چون تینک در حالت تک هسته ای اجرا میشه یک core دائم روی ۱۰۰٪. هست. پس حواستون باشه سرور آشغال بهتون نندازن!

نحوه ی تست:

openssl speed -evp chacha20-poly1305

اگر openssl بزنید انکرپیشن های موجود رو نشون میده.

✅ اگر پردازنده خوب باشه انتظار میره تا ۴۰۰ مگابیت سرعت بره.

#matrix
👁@Gozar_Xray

✅ WaterWall Project

یه پروژه جالب با زبان C مشابه ی هسته ی Xray-Core و SingBox با تمرکز بر تانلینگ و بررسی و مقابله با فایروال ایران.

در گیت هاب پروژه میخونیم:

واتروال یه هسته هست؛ هسته یعنی چی؟ در کل یعنی اینکه این برنامه فقط برای یه روش تونل خاص نیست و روش های زیادی داره که می‌تونید انتخاب کنید و اجرا کنید
درکل تمرکز اصلی این پروژه اول این بوده که بشه باهاش یه تونل خوب اجرا کرد
ولی بعد از تونل هدف این بوده که بشه باهاش کانفیگ مستقیم هم ساخت که باهاش فایروال ایران رو برسی کنیم و هرچی دستگیرمون شد روش اجرا کنیم تا جلوی فیلتر شدنش رو هم بگیریم، و با اخرین تغییرات فایروال ایران پیش بریم

یه کار باارزش و نیازمند حمایت هستش. داشتن یه هسته‌ی اختصاصی برای خودمون یه پیشرفت بزرگ و منحصر به فرد هست.


⭐️ لینک گیت هاب پروژه:

https://github.com/radkesvat/WaterWall?tab=readme-ov-file

#waterwall
👁@Gozar_Xray

✅ به زودی یه آپدیت کوچولو برای Rathole میدم که بشه TCP No_Delay رو خاموش کرد. درباره TCP NoDelay و کاربردش در شبکه و الگوریتم Nagle هم یه توضیح کوتاه میدم.

⁉️ این که در عمل چقدر تفاوت ایجاد کنه رو هم دوستان زحمت تستش رو می کشند. یه بنچمارک هایی هم البته در سطح نت براش هست. اگر کاربر بالا دارید به نظر خاموش کردنش بهتر باشه.

#rathole #TCP_NODELAY
👁@Gozar_Xray

⁉️بخش اول: الگوریتم Nagle چیست؟

یک تکنیک بهینه‌سازی برای کاهش تعداد بسته‌های کوچک داده‌ای در شبکه‌های TCP/IP است. این الگوریتم توسط جان ناگل در سال ۱۹۸۴ ابداع شد و هدف اصلی آن بهبود کارایی انتقال داده‌ها در شبکه‌های کند یا شبکه‌هایی با پهنای باند محدود است.

❓ نحوه کار الگوریتم Nagle

الگوریتم Nagle به این صورت عمل می‌کند که زمانی که داده‌های کوچکی برای ارسال وجود دارند، فرستنده این داده‌ها را تا زمانی که تاییدیه (ACK) از داده‌های قبلی دریافت نکرده باشد، جمع‌آوری و ادغام می‌کند. به عبارت دیگر، اگر فرستنده داده‌های کوچکی داشته باشد که باید ارسال شوند، منتظر می‌ماند تا یا:

تاییدیه بسته‌های قبلی دریافت شود: در این صورت، فرستنده تمام داده‌های جمع‌آوری شده را به یک بسته بزرگ‌تر ترکیب کرده و ارسال می‌کند.
داده‌های کافی برای پر کردن یک بسته کامل دریافت کند: در این صورت، بدون توجه به دریافت یا عدم دریافت تاییدیه، بسته را ارسال می‌کند.
این روش باعث می‌شود که تعداد بسته‌های کوچک ارسال شده در شبکه کاهش یابد، و در نتیجه، کارایی انتقال داده‌ها بهبود پیدا کند.

❓ مزایا و معایب الگوریتم Nagle

مزایا:
کاهش تعداد بسته‌های کوچک: این امر منجر به کاهش سربار پروتکل TCP و بهبود کارایی کلی شبکه می‌شود.
بهینه‌سازی استفاده از پهنای باند: با ترکیب بسته‌های کوچک به یک بسته بزرگ‌تر، استفاده بهینه‌تری از پهنای باند موجود حاصل می‌شود.

معایب:
افزایش تأخیر در برخی کاربردها: برای برنامه‌هایی که نیاز به تأخیر کم دارند (مانند برنامه‌های تعاملی بلادرنگ)، الگوریتم Nagle ممکن است باعث تأخیر‌های غیرقابل قبول شود.
مشکل در ترکیب با تأییدیه تأخیری (Delayed ACK): در برخی موارد، ترکیب الگوریتم Nagle با مکانیزم تأییدیه تأخیری ممکن است باعث تأخیر‌های بیشتر شود.

✅ برای غیرفعال کردن الگوریتم Nagle در برنامه‌نویسی، معمولاً از گزینه TCP_NODELAY استفاده می‌شود که می‌توان آن را روی سوکت TCP تنظیم کرد.


#TCP_NODELAY
👁@Gozar_Xray

⁉️ گزینه TCP_NODELAY چیست؟

یک تنظیم در پروتکل TCP است که به شما اجازه می‌دهد الگوریتم Nagle را غیرفعال کنید. با فعال کردن این گزینه، داده‌ها به محض آماده شدن ارسال می‌شوند و دیگر منتظر ترکیب شدن با داده‌های دیگر یا دریافت تاییدیه از بسته‌های قبلی نخواهند بود.

❓ تأثیر فعال کردن TCP_NODELAY

- ارسال فوری داده‌ها: داده‌ها بلافاصله پس از آماده شدن برای ارسال به شبکه فرستاده می‌شوند.
- کاهش تأخیر: در برنامه‌های بلادرنگ یا تعاملی که نیاز به حداقل تأخیر دارند، فعال کردن TCP_NODELAY می‌تواند باعث کاهش تأخیر شود.
- افزایش تعداد بسته‌های کوچک: با فعال کردن این گزینه، تعداد بسته‌های کوچکی که در شبکه ارسال می‌شوند، افزایش می‌یابد که می‌تواند سربار پروتکل TCP و استفاده از پهنای باند را افزایش دهد.
تجارت الکترونیک و تراکنش‌های مالی: برای کاهش تأخیر در تراکنش‌ها و بهبود تجربه کاربر.

❓تأثیر بر مصرف پردازنده

بسته‌های بیشتر برای پردازش: با ارسال هر داده به محض آماده شدن، تعداد بسته‌هایی که پردازنده باید مدیریت کند، افزایش می‌یابد. این باعث می‌شود پردازنده مجبور باشد تعداد بیشتری بسته را مدیریت کند، که می‌تواند منجر به افزایش بار کاری و مصرف پردازنده شود.

افزایش فراخوانی‌های سیستمی: هر بار که داده‌ای ارسال می‌شود، یک فراخوانی سیستمی به سیستم‌عامل انجام می‌شود. افزایش تعداد این فراخوانی‌ها باعث افزایش سربار پردازنده می‌شود.

❓ تأثیر بر مصرف پهنای باند

سربار بسته‌های بیشتر: هر بسته TCP شامل سرباری (header) است که شامل اطلاعات کنترلی می‌باشد. وقتی بسته‌های کوچک‌تر ارسال می‌شوند، نسبت سربار به داده‌ها بیشتر می‌شود و در نتیجه، پهنای باند بیشتری مصرف می‌شود.

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


❓ موارد کاربرد:

- بازی‌های آنلاین: برای اطمینان از اینکه حرکات و اقدامات بازیکنان بدون تأخیر به سرور بازی می‌رسد.
- برنامه‌های صوتی و تصویری بلادرنگ: برای اطمینان از انتقال بدون تأخیر داده‌های صوتی و تصویری.
- تجارت الکترونیک و تراکنش‌های مالی: برای کاهش تأخیر در تراکنش‌ها و بهبود تجربه کاربر.

#TCP_NODELAY
👁@Gozar_Xray

گزینه ی تنظیم TCP_NODELAY در رتهول فعال شد. طبق نیازی که دارید می‌تونید فعال یا غیرفعال کنید. برای استفاده شخصی به نظرم true و در صورت تعداد کاربر بالا false رو امتحان کنید.

مقدار این گزینه در سرور ایران و خارج باید یکسان باشند. مجددا باید کانفیگ کنید که گزینه نمایش داده باشه.

برای غیرفعال کردن باید مجدد کانفیگ کنید.

https://github.com/Musixal/rathole-tunnel/tree/main

#TCP_NODELAY
👁@Gozar_Xray

✅ پروژه ماتریکس رو که من استارت زدم، طبق تست های اولیه که در سیستم خودم داشتم پرفورمنس قابل قبولی داشت. از همون ابتدا هم میدونستم هسته ی Tinc که استفاده شده Single Thread هست و بهینه سازی های کافی روش انجام نشده و برنامه زمان زیادی رو در کرنل تلف میکنه اما پهناباند حدود ۳۰۰ مگابیت قابل قبول بود. مخصوصا این که تینک نسبت به رتهول بهتر از فایروال عبور میکنه.

احتمالا دلیل این که تینک در بعضی سیستم ها بسیار کند هست هم همینه و مربوط به کرنل هست اما این که چه ورژن هایی بهتره رو هنوز اطلاع ندارم و نیازمند تحقیق بیشتره. فعلا یه آپدیت کوچیک دادم و امکان حذف Encryption در گزینه های Expert رو فراهم کردم این کار کمی پهناباند رو بیش تر و مصرف پردازنده رو پایین تر میاره.

⁉️ همین الان هم میتونم جایگزین بهتر و قابل قبول تری برای هسته ی ماتریکس استفاده کنم اما مشغله ی کاری زیاد متاسفانه اجازه این کار و بازنویسی کدها رو نمیده. ممکنه در قالب پروژه دیگری ارائه بدم یا به یک آموزش ویدئویی بسنده کنم. قطعا آموزش ویدئویی با توجه به این که وقت گیر نیست برای من هم بهتره.

#matrix
👁@Gozar_Xray

✅ به زودی جایگزین اسکریپت ماتریکس رو معرفی می کنم. پروتکل های بیشتر، ساده تر، استیبل تر و سریع تر...

#easymesh
👁@Gozar_Xray

⁉️ ویژگی ها:

👾 پهناباند بالای ۴۰۰ مگابیت
👾 مالتی ترد
👾 پشتیبانی از udp, tcp, ws, wss
👾 استیبل تا اینجای کار
👾 فول مش
👾 انکریپشن دیتا
👾 عبور بهتر از فایروال نسبت به رتهول
👾 ارتباط بای دایرکشنال


🚀 فعلا کرنل Xanmod + BBRv3 رو نصب کنید. ممکنه باعث اختلال در سرورتون بشه. پس روی سرور اصلی‌تون تست نکنید.

😤 حوصله doc نوشتن ندارم، اگر موافق هستید تو گروه بگید به صورت ویدئویی توضیح بدم.


#easymesh
👁@Gozar_Xray

🌍 اسکریپت Easy Mesh


🌀 لینک پروژه در گیت هاب


#easymesh
👁@Gozar_Xray

🌀 توضیحاتی چند درباره تانل ها

۱) در مورد رتهول اون هایی که مشکل قطعی داشتند هیچ اطلاعات بیشتری ندادند که من بتونم مشکل رو reproduce کنم. بنابراین میذارم به حساب مشکلات دیتاسنتر و کانفیگ کردن اشتباه و اوپتیمایز نبودن OS. بارها هم گفتم رتهول در کانکشن های بالا معمولا ۲۰ هزار (بسته به سخت افزار سرورتون) دچار افزایش Latency میشه و نیاز به کرون جاب داره. پس بهتره کانفیگ هاتون رو با Mux به مشتری بدید. نصب اوپتیمایزر هم تاثیر داره.

- این که کرون جاب روی چه ساعتی تنظیم باشه رو با نصب Uptime Kuma میتونید متوجه بشید.
- قسمت Port Monitor هم باعث سردرگمی شده و به نظرم آپدیت بعدی حذفش میکنم.
- پیشنهاد این که پورت تانل و کانفیگ ها رو توی اسکریپت نشون بده جالب بود و ممکنه اضافه ش کنم.
- به نظرم وب سوکت مشکلات خودش رو داره و نیاز نیست به تانل اضافه بشه.
- مشکلات اتصال چند سرور خارج به یک سرور ایران اگر خیلی ریپورت شه اصلاحش میکنم.

۲) اسکریپت ماتریکس برای فروش نیست و برای استفاده شخصی کاربرد داره. اگر سرعت خوبی بهتون میده کاملا استیبل هست. هسته ی تینک آپدیت نمیشه و خیلی نمیشه روش حساب کرد که در آینده تغییر بزرگی کنه.

۳) اسکریپت ایزی مش خیلی آینده بهتری داره. از لایبرری قدرتمند Tokio استفاده میکنه و همین لایبرری در رتهول استفاده شده. دولوپر فعالی داره و من مشکلاتی که بود رو در گیت هاب در این لینک issue کردم و پاسخ دادند. برای استفاده شخصی تا این جای کار برای من اوکی بوده ولی برای کاربر زیاد فعلا توصیه نمیکنم مگر این که طبق تست خودتون نتیجه ی خوبی گرفته باشید.

#tunnel
👁@Gozar_Xray

⁉️ چرا تانل TCP over TCP خوب نیست و TCP meltdown چیست؟ و توضیح این که چرا تانل هایی مثل رتهول در کانکشن های بالا مشکل پیدا می‌کنند.

تو شبکه‌های کامپیوتری ارتباطات TCP رو داریم، این ارتباطات طوری طراحی شدن که مطمئن بشن داده‌ها به درستی و بدون خطا به مقصد می‌رسن. حالا فرض کنید که یه تانل TCP in TCP مثل رتهول داریم، یعنی یه اتصال TCP درون یه اتصال TCP دیگه قرار داره. در حالت معمولی، TCP مکانیزم‌هایی داره که اگر داده‌ها با مشکل مواجه بشن یا از دست برن، خودش رو تنظیم کنه. این مکانیزم‌ها شامل موارد زیر هستن:

اول Congestion Control رو داریم: TCP از روش‌هایی مثل Slow Start، Congestion Avoidance و Fast Recovery استفاده می‌کنه تا ترافیک رو مدیریت کنه و از شلوغ شدن بیش از حد شبکه جلوگیری کنه.

دوم Error Detection and Retransmission (تشخیص خطا و ارسال مجدد) رو داریم: اگر یه بسته داده گم بشه یا خراب بشه، TCP دوباره اون بسته رو می‌فرسته.

حالا تصور کنید که این مکانیزم‌ها دارن هم‌زمان در دو لایه TCP (یه TCP داخل یه TCP دیگه) اجرا می‌شن. این یعنی هر بار که یه خطا یا مشکل Congestion رخ می‌ده، هر دو لایه TCP باید اقدامات خودشون رو انجام بدن و به طور موازی تلاش کنن که مشکل رو حل کنن، که این خودش منجر به پیچیدگی بیشتر و مصرف بیشتر منابع می‌شه.

وقتی ترافیک شبکه خیلی زیاد بشه (congestion)، هر دو لایه TCP سعی می‌کنن با کاهش سرعت ارسال داده و تنظیم خودشون به ترافیک زیادی که هست پاسخ بدن. این مسئله باعث موارد زیر می‌شه:

افزایش تأخیر (Latency): چون هر لایه TCP باید منتظر بمونه تا لایه‌ی دیگه کار خودش رو انجام بده.

افزایش بار پردازشی (Processing Overhead): چون پردازنده باید دو بار مکانیزم‌های TCP رو اجرا کنه.

بیشتر شدن احتمال خطا و ارسال مجدد (Increased Retransmissions): چون هر خطا ممکنه دو بار توسط هر دو لایه تشخیص داده بشه و دوباره ارسال بشه.

همچنین، پدیده‌ی جبران (Compensation) هم تو این وضعیت مطرحه. TCP سعی می‌کنه که با کاهش سرعت ارسال و تنظیم مجدد Congestion رو مدیریت کنه. این فرآیندها در لایه‌های متعدد می‌تونن باعث بشن که سرعت کلی ارتباط در کانکشن های بالا به شدت کاهش پیدا کنه، چون هر لایه به تنهایی سعی می‌کنه که خودش رو تنظیم کنه.

این لایه‌لایه شدن بسته‌ها باعث می‌شه که پردازش هر بسته خیلی زمان‌بر و پیچیده بشه و این همون مشکل TCP Meltdown هست که تو شبکه ایجاد می‌شه.

برای جلوگیری از این مشکل، بهتره که از پروتکل‌های غیر TCP مثل UDP برای تانل‌زنی استفاده بشه یا به طور کلی طراحی شبکه رو طوری انجام بدیم که از لایه‌لایه شدن ارتباطات TCP جلوگیری کنیم.

#tcp
👁@Gozar_Xray

🤖 اضافه کردن Watchdog به اسکریپت EasyMesh

با وجود این که اسکریپت EasyMesh در مرحله ی بتاست و در حال صحبت با دولوپرش برای رفع باگ هاش هستم، اما بعضی دوستان علاقه داشتند از این اسکریپت بدون مشکل قطعی استفاده کنند. بنابراین یه گزینه به اسم Watchdog یا نگهبان سرویس به اسکریپت اضافه کردم.

✅ به این صورت عمل کنید. اسکریپت رو اجرا کنید (فقط سرور خارج) و گزینه ۷ رو انتخاب کنید. بعد گزینه اول یعنی Start watchdog رو بزنید. حالا آدرس Local IP ایران رو وارد کنید. بعد مقدار Latency رو مشخص کنید. چیزی حدود ۲۰۰ تا ۳۰۰ میلی ثانیه خوبه. بعد هم فاصله بین هر پینگ رو به ثانیه بزنید. مثلا ۵ یا ۱۰ خوبه. این یعنی هر ۵ ثانیه آدرس لوکال ایران چک میشه و اگر پینگش از عددی که تعیین کردید بالاتر بود، سرویس ریستارت میشه.
می تونید لاگ ها رو هم ببینید. گزینه ۷ و بعد گزینه ۳ برای مشاهده ی لاگ هست.

فعلا در همین حد میشه به این دوستان که قطعی دوره ای دارند کمک کرد. نصب XanMod Kernel رو هم قبلا توصیه کرده بودم. سوالی بود در گروه مطرح کنید.

#easymesh
👁@Gozar_Xray

✅ ترنسپورت جدید splithttp برای Xray Core

قراره در آینده یه ترنسپورت جدید به اسم splithttp به Xray Core اضافه بشه. به واسطه این ترنسپورت جدید میشه از همه CDN ها حتی اون هایی که وب سوکت ندارند هم برای پروکسی استفاده کرد. البته ایده ش از قبل بوده ولی این بار بهتر و کاردبردی تر پیاده سازی شده. در حالت عادی CDN ها درخواست های HTTP رو کش میکنند و مجبور بودیم برای یک ارتباط real-time از وب سوکت استفاد کنیم. در ترنسپورت splithttp با تکه تکه کردن درخواست های http جلوی بافرینگ CDN گرفته میشه و درخواست به سرور مقصد انتقال پیدا میکنه.

این ترنسپورت جدید کمک میکنه که نه تنها کلادفلر بلکه بقیه CDN ها رو هم بتونیم به راحتی استفاده کنیم.

اطلاعات بیشتر در گیت هاب
#splithttp #xray
👁@Gozar_Xray

با منتشر شدن Xray Core 1.8.15 برای iOS برنامه Streisand اولین آپدیت رو داد و از الان ترنسپورت SplitHTTP قابل استفاده است.

❌ از نظر Performance انتظار میره از وب‌سوکت پایین تر باشه ولی cdn های زیادی رو میشه استفاده کرد.

⁉️ چرا وب‌سوکت کمتر در cdn ها پشتیبانی میشه؟ چون منابع و پردازش بیشتری نیاز داره.

⁉️ چرا ترنسپورت جدید پرفورمنس کمتری داره؟ چون دیتا رو به صورت بسته‌های کوچک‌تر میفرسته. ممکنه در آینده بهینه‌سازی های بیشتری روش انجام شه.

⁉️ پنل های ایرانی x-ui هم برای هسته جدید آپدیت دادند.

✅ نتایج تستش رو در اسرع وقت میذارم.
#splithttp #xray
👁 @Gozar_Xray

✅ SplitHTTP SpeedTest

اگر بخوام مختصر و مفید بگم، دانلود در حد وب‌سوکت و قابل قبول هست ولی آپلود بسیار ضعیف تره. نتایج تست آپلود روی وب سوکت خیلی بهتره و این انتظار هم میرفت. نکاتی که باید در نظر داشت اول CDN کلادفلر هست. شاید تست روی CDN دیگه نتایج بهتری بده. دوم IP تمیز کلادفلر ممکنه آپلود رو بهتر کنه. سوم اینکه امکان بهبود ترنسپورت در‌ آینده وجود داره. اگر تونستم نتایج بهتری به دست بیارم Share میکنم.

❌ متاسفانه آپلود خیلی نوسان (fluctuation) داره، در حال حاضر همین آپلود کم رو هم نمیتونم بگیرم در صورتی که با تنظیمات یکسان وب سوکت Ok هست.

✅ دوستانی که دامنه ندارند میتونند از CDN هایی مثل Fastly با دامنه Fake استفاده کنند. این CDN برای استفاده نیاز به ست کردن Nameserver نداره. 😐

#splithttp #xray
👁@Gozar_Xray

✅ آموزش راه اندازی مش نتورک با VPNCloud

- سرعت فوق العاده بالا
- امنیت عالی
- مناسب برای تانلینگ
- امکان تانل سرور فیلتر شده
- بستر UDP

🎥 لینک آموزش در یوتیوب

🌐 لینک گروه

#vpncloud
👁@Gozar_Xray