اگر در حال توسعه کلاینتهای شبکه هستید که باید با استانداردهای سختگیرانه سازمانهای بزرگ سازگار باشند، دیگر نیازی به کدنویسی دستی برای مدیریت مسیرهای ترافیکی ندارید. Rama در نسخه ۰.۴ خود، مدیریت پروکسیهای سیستمی را به یک قابلیت پیشفرض تبدیل کرد تا توسعهدهندگان از شر متغیرهای محیطی تکراری خلاص شوند. کلاینتهای شبکهای که با Rama ساخته میشوند، اکنون میتوانند تنظیمات پروکسی در سطح سیستم را شناسایی کرده و اسکریپتهای مسیریابی پویا را به صورت پیشفرض اجرا کنند.
به نقل از مستندات رسمی این پروژه، تنها شش هفته پس از انتشار نسخه ۰.۳ — که دقیقاً در بازه زمانی وعده داده شده برای چرخه انتشار (دو تا هشت هفته) قرار داشت — تیم توسعه Rama 0.4 را منتشر کرد تا یکی از قدیمیترین نیازهای کاربران، یعنی یکپارچگی با منطق پیچیده پروکسیها را برطرف کند. این نسخه با ادغام یک محیط اجرای جاوااسکریپت (JS Runtime)، مشکلاتی را که مدتها در لیست کارهای معوقه (backlog) بود، حل کرده است.
برای توسعهدهندگان، مدیریت ترافیک شبکه اغلب به معنای کلنجار رفتن با متغیرهای محیطی یا سختکد کردن (hardcoding) مسیرهاست. Rama از دیرباز از پروکسیهای HTTP، HTTPS (HTTP over TLS) و SOCKS5 پشتیبانی میکرد. سادهترین روش پیکربندی، استفاده مستقیم از ProxyRoute(s) است که جایگزین ProxyAddress در نسخههای قبلی شده است. این مسیرها میتوانند به صورت سختافزاری در برنامهها تعریف شوند یا از طریق یک رابط کاربری (GUI) یا فایل تنظیمات — مشابه آنچه در اکثر مرورگرها یا ویرایشگرهای کد میبینیم — در دسترس قرار گیرند.
زمینه: پروکسیهای محیطی و سیستمی
برنامهها به طور مکرر به متغیر محیطی HTTP_PROXY متکی هستند. Rama اکنون از کنوانسیونی پیروی میکند که در ابزار curl دیده میشود؛ به این معنا که هنگام استفاده از ProxyEnvLayer، نسخه حروف کوچک یعنی http_proxy را (به دلایل مربوط به CGI) به عنوان پیشفرض در نظر میگیرد.
فراتر از پروکسیهای ساده HTTP، نسخه ۰.۴ Rama پشتیبانی از چندین متغیر محیطی رایج دیگر را از طریق ProxyEnvLayer و NoProxyEnvLayer اضافه کرده است:
ALL_PROXY: برای مسیریابی کلی پروکسی.HTTPS_PROXY: به طور خاص برای ترافیکهای امن.NO_PROXY: برای تعریف قوانین بایپس (Bypass)، تا اطمینان حاصل شود که دامنهها یا زیردامنههای خاص از طریق پروکسی هدایت نمیشوند.
در حالی که این متغیرها مفید هستند، سیستمعاملها اجازه میدهند پیکربندی پروکسیهای HTTP، HTTPS و SOCKS5 و همچنین قوانین بایپس جهانی در سطح کل سیستم تعریف شوند. پیش از این، کلاینتهای شبکهای ساخته شده با Rama فاقد ظرفیت داخلی برای رعایت این تنظیمات سیستمعامل بودند. Rama 0.4 این شکاف را با معرفی SystemProxyLayer پر میکند و به برنامهها اجازه میدهد به طور خودکار پیکربندیهای سطح سیستم را به ارث ببرند.
مکانیسم WASM-JS
یکی از فنیترین چالشها در این انتشار، پشتیبانی از پیکربندی خودکار پروکسی (PAC) بود. فایلهای PAC در واقع اسکریپتهای جاوااسکریپتی هستند که به صورت پویا به برنامه میگویند برای یک URL خاص از کدام پروکسی استفاده کند. برای اجرای این اسکریپتها بدون به خطر انداختن پایداری کل برنامه، Rama یک استراتژی جداسازی (Isolation) خاص را پیاده کرد:
- تیم توسعه rama-js را ایجاد کرد که یک محیط اجرای جاوااسکریپت را درون محیط وباسمبلی (WASM) با استفاده از wasmtime اجرا میکند (همین محیط اجرا برای بیلد آینده
rama-wasmنیز در نظر گرفته شده است). - این معماری تضمین میکند که اگر یک اسکریپت PAC کرش کند، باعث سقوط کل فرآیند (Process) برنامه نشود.
- این رویکرد مشابه روش گوگل کروم در جداسازی موتورهای جاوااسکریپت در پردازشهای مجزای سیستمعامل است، اما Rama این کار را در یک پردازش واحد و از طریق WASM به دست آورده است تا نیازی به باندل کردن یک پردازش مجزا در سطح OS نباشد.
اکنون Rama پشتیبانی از PAC را از طریق کریت rama-pac فراهم میکند. این قابلیت به توسعهدهندگان اجازه میدهد یک محیط اجرای PAC برای ارزیابی اسکریپتها نگه دارند یا به راحتی اسکریپتهایی تولید کنند که دامنههای خاص (X) را به قوانین پروکسی خاص (Y) هدایت کند.
گسترش پشتیبانی از پروتکلها
فراتر از پروکسی، نسخه ۰.۴ قابلیتهای ارتباطی فریمورک را گسترش داده است. کریت جدید rama-ttrpc پشتیبانی از ttRPC را معرفی میکند. این پروتکل به عنوان جایگزینی سبک برای gRPC معرفی شده که مستقیماً روی پروتکلهای انتقال مانند TCP اجرا میشود، در حالی که همچنان از قراردادهای پروتوباف (protobuf) بهره میبرد.
برای کسانی که gRPC را ترجیح میدهند اما نمیخواهند فایلهای .proto را به صورت دستی بنویسند، کریت rama-grpc-macros اکنون امکان تولید خودکار کدهای کلاینت و سمت سرور gRPC را فراهم کرده است. این قابلیت بر روی کدکهای (codecs) خود کاربر متکی است که میتواند به صورت اختیاری از طریق define_service توسط Serde مدیریت شود. این موضوع به ویژه برای تیمهایی که کنترل کامل استک شبکه خود را در دست دارند، بسیار مفید است.
بهبودهای HAR و WebSocket
Rama 0.4 همچنین به یک نیاز تخصصی اما حیاتی برای عیبیابی شبکه پاسخ داده است: پشتیبانی از HAR (آرشیو HTTP) برای وبساکتها. این ویژگی توسط یک شریک تجاری به تیم پیشنهاد شد. از آنجایی که این یک قابلیت مبهم است — که سالها پیش به کروم اضافه شد اما توسط اکثر برنامههای دیگر نادیده گرفته شد — تیم Rama از کروم به عنوان «اوراکل» یا مرجع برای هدایت پیادهسازی استفاده کرد.
این پیادهسازی منجر به بازنویسی کامل منطق خروجی HAR شد. پیش از این، Rama برای تضمین ترتیب و سازگاری، دادههای زیادی را در حافظه نگه میداشت. نسخه جدید، دادههای HTTP و وبساکت را مستقیماً روی دیسک استریم میکند و از سرریز حافظه (Memory Overflow) در زمان ثبت ترافیکهای حجیم جلوگیری میکند. کاربران اکنون میتوانند از آرگومان --har در CLI رام برای استخراج این گفتگوها استفاده کنند.
بهینهسازیهای عملکردی و ابزاری
چندین بهبود زیرساختی با هدف افزایش قابلیت اطمینان در بازرسی پروتکلها اعمال شده است. «Peekers» (بررسیکنندههایی که پروتکلهای در حال جریان را شناسایی میکنند) اکنون به محض اینکه یک بایت دیگر با اکتشافات (heuristics) مطابقت نداشته باشد، سریعتر شکست میخورند و متوقف میشوند که این امر باعث کاهش تأخیر میشود.
بهبودهای خاص عبارتند از:
- HTTP Peek Router: اکنون اجازه میدهد کاربر به طور اختیاری از پریدن روی نامهای رایج «متدها» که ممکن است با خطوط هدر HTTP اشتباه گرفته شوند، استفاده کند. این کار از موارد خاصی مانند عملیات PING که باعث میشد منطق peeker تا زمان اتمام timeout متوقف شود، جلوگیری میکند.
- Apple Network Extension: پشتیبانی ارتقایافته برای کسانی که در حال ساخت پروکسیهای L3 و L4 روی پلتفرمهای اپل هستند.
- Connection Services: بهروزرسانی امضاهای trait (سمت کلاینت) برای تصمیمگیری هوشمندتر و مدیریت خطاهای بهتر، به ویژه در مورد اینکه چه زمانی باید اتصال مجدد (Retry) انجام شود و چه زمانی باید اتصال به عنوان شکست (Fail) ثبت شود.
- مسیریابی پروکسی: در کنار PAC، کاربران اکنون میتوانند چندین مسیر (آدرس) پروکسی را در اکستنشنهای ورودی قرار دهند. این مسیرها به ترتیب ارائه شده امتحان میشوند. در حالی که قابلیت دیتابیس پروکسی به طور پیشفرض از این روش استفاده میکند، کاربران همچنان میتوانند رفتار قدیمی انتخاب تک-پروکسی تصادفی را فعال کنند.
این انتشار نشاندهنده تغییری به سمت تبدیل Rama به یک راهکار «Drop-in» برای محیطهای سازمانی است، جایی که رعایت قوانین شبکه در سطح سیستم اجباری است. توسعهدهندگان با انتقال محیط اجرای JS به WASM، تعادلی میان نیاز به اجرای اسکریپتهای پویا و الزامات سختگیرانه امنیتی یک استک شبکه مبتنی بر Rust ایجاد کردهاند.
توسعهدهندگان اکنون میتوانند این قابلیتها را با استفاده از Rama CLI تست کنند. دستور send این ویژگیها را به صورت پیشفرض پشتیبانی میکند (مگر اینکه توسط آرگومانها یا متغیرهای محیطی بازنویسی شوند). علاوه بر این، زیردستورهای جدید rama pac به کاربران اجازه میدهد اسکریپتهای PAC تولید کنند یا آنها را از طریق یک REPL ارزیابی کنند و محیطی مدرن برای تست فایلهای PAC فراهم کنند که پیش از این تنها با برنامههای قدیمی و مبهم سازگار بودند.
گام بعدی شما
- اگر از CLI رام استفاده میکنید، دستور
sendرا با تنظیمات پروکسی سیستم خود تست کنید تا از صحت شناسایی خودکار مطمئن شوید. - برای تست فایلهای PAC، از زیردستورهای جدید
rama pacو محیط REPL آن برای ارزیابی سریع اسکریپتها استفاده کنید. - در صورتی که با حجم بالای ترافیک وبساکت سروکار دارید، آرگومان
--harرا برای استخراج دادهها بدون فشار به رم امتحان کنید.
اما داستان سختافزاری این تحول و نحوه تعامل WASM با حافظه حتی شگفتانگیزتر است — به تحلیل ما درباره بهینهسازیهای لایه انتقال مراجعه کنید.
گفتگو