سریعتر کردن Tailscale
آدرس مقاله: https://tailscale.com/blog/making-tailscale-faster آدرس نظرات: https://news.ycombinator.com/item?id=49819880 امتیاز: 244 # نظرات: 105
اگر اصلا Tailscale را دنبال کردهاید، میدانید که ما واقعا فقط یک دسته از افراد حرفهای هستیم که به اتصال به اینترنت اهمیت زیادی میدهند. چیزی که ما دوست داریم در مورد آن صحبت کنیم، NAT Traversal است. این یکی از ارزش افزوده های اصلی با Tailscale است: ما NAT را رام کردیم. هر شبکه ای دوستانه نیست، اما Tailscale همچنان می تواند مسیری را در طیف وسیعی از شرایط پیدا کند. این تنها چیز مهم برای یک پروتکل اینترنت نیست: صفحه داده نیز باید عملکردی داشته باشد.
در طول سال ها، ما روی ساخت سریع Tailscale سرمایه گذاری کرده ایم. ما با افزایش توان عملیاتی TCP در دستگاه های لینوکس شروع کردیم. سپس ما پیشرفت های قابل توجهی در wireguard-go به دست آوردیم تا از 10 گیگابیت بر ثانیه در فلز خالی پیشی بگیریم. ما بعدا از بارهای تقسیمبندی برای افزایش توان عملیاتی بیش از 4 برابر برای برنامههای مبتنی بر UDP استفاده کردیم. در کنار این پیشرفتها در صفحه دادهمان، ما ابزارهای اولیه مانند Relays همتای Tailscale را ساختیم که میتواند عملکرد شبکه را در شرایط دشوار بهبود بخشد.
همه اینها Tailscale را برای بارهای کاری حساس تر به عملکرد عملی کرده است. این بدان معناست که میتوانید از Tailscale برای یکپارچهسازی مداوم، گردشهای کاری عاملی، محیطهای توسعه از راه دور، دستگاههای لبه روباتیک، حجمهای کاری سنگین داده و تله متری و موارد دیگر استفاده کنید. Tailscale به آن دستگاه ها کمک می کند تا در طیف گسترده ای از شرایط شبکه متصل شوند.
بنابراین بله، ما فکر می کنیم Tailscale سریع است. اما ما همچنین فکر می کنیم که می توانیم آن را سریعتر انجام دهیم.
امروز نحوه افزایش توان عملیاتی اتصالات برنامه، روترهای زیرشبکه و گرههای خروجی را با استفاده از فناوری چند صف (در نیمه دوم سال 2026) توضیح خواهیم داد. همچنین پیشنمایش برخی از پیشرفتهای عملیاتی و سربار حافظه را که در نسخههای مشتری پایدار آتی بهکار میبریم، مشاهده خواهیم کرد. و ما به برخی از مشکلات ابزار عملکردی که میخواهیم برای مشتریان خود حل کنیم، نگاه خواهیم کرد.
اکثر بسته های شبکه کوچک هستند، مانند 1 KiB. اما برای استفاده از کارآمدترین ابزارهای خروجی لینوکس، مانند Generic Receive Offload (GRO)، Tailscale باید آماده پذیرش 64 کیلوبایت ترافیک به طور همزمان باشد. این کمی شبیه حمل و نقل کانتینری است: بنادر، کشتیها و کامیونها برای یک شکل کانتینری ساخته شدهاند، هر چقدر هم که پر باشد.
Tailscale باید آن ظروف را باز کند - هر بسته به خودی خود رمزگشایی و تحویل می شود. پیادهسازی wireguard-go که به رمزنگاری و ملزومات شبکه Tailscale اطلاع میدهد، تنها یک اندازه بافر 64 کیلوبایتی را برای باز کردن در آن ارائه میدهد. بنابراین یک بسته ۱ کیلوبایتی هر بار در بافر ۶۴ کیلوبایتی خودش کپی میشود. این یک هدف بهینه سازی غنی است.
در لینوکس و اندروید، Tailscale اکنون آن بستهها را در جایی که فرود آوردهاند، رها میکند. به جای کپی کردن آن در جایی جدید، مشخص میکند که هر کدام از آنها از کجا شروع و به پایان میرسد. بسته های کوچک در حافظه کوچک می مانند، بسیاری از آنها یک تخصیص را به اشتراک می گذارند و زمان کمتری را صرف کپی می کنند. این به خودی خود منجر به افزایش سرعت تقریبا 5 درصدی در بسیاری از تنظیمات شبکه شد.
به طور جداگانه، صف های بسته را کوتاه کردیم - بسته های خطوط در بین مراحل خط لوله منتظر می مانند. صف ها برای جذب انبوه ترافیک وجود دارد. آزمایش نشان داد که بیشتر این عمق استفاده نشده است، در حالی که صفهای کوتاهتر به معنای زمان انتظار کمتر و سربار حافظه کمتر است.
با این همه فضای حافظه آزاد شده چه کنیم؟ ما این پس انداز را به برخی از گره های سخت کار منتقل کردیم: روترهای زیر شبکه و اتصال دهنده های برنامه.
روترهای زیرشبکه می توانند در tailnet های مختلف کاملا متفاوت به نظر برسند. برای کسی که یک شبکه خانگی کوچک را اجرا می کند، یک روتر زیرشبکه به راحتی می تواند مجموعه کوچکی از دستگاه های غیر Tailscale 192.168.x.y را مدیریت کند. روتر زیرشبکه ای که در مقابل استقرار ابری قرار می گیرد، یکی با صدها همتا، به طور قابل ملاحظه ای ترافیک بیشتری را حمل می کند.
تا همین اواخر، مسیریابهای زیرشبکه، رابطهای برنامه و گرههای خروجی بستهها را برای چندین جریان مستقل در یک خط لوله منظم و تک رشته پردازش میکردند. این بدان معناست که یک خط واحد در بسیاری از اتصالات به اشتراک گذاشته شده است، زیرا یک برنامه دریافت کننده هرگز نباید بسته های خود را بدون نظم ببیند.
با کاهش ردپای حافظه خود، ظرفیت اجرای یک سیستم چند صفی را داشتیم: چندین خط به جای یک خط، به جای تعداد همتایان، به منابع دستگاه مقیاس میشد. هر جریانی از بستهها یک خط پیدا میکند و در آنجا باقی میماند، در حالی که خطوط به صورت موازی اجرا میشوند و اجازه میدهند کار در سراسر هستههای CPU پخش شود.
این منجر به ظرفیت مجموع بالاتر و تاخیر کمتر بین دریافت و ارسال بستهها برای روترهای زیرشبکه و کانکتورهای برنامه میشود. سخت افزاری که از قبل دارید کارآمدتر استفاده می شود. رابطهای برنامه و گرههای خروج، که معمولا به بسیاری از کاربران با اتصالات کوتاهمدت خدمات ارائه میکنند، بهویژه تقویت قابل توجهی دریافت میکنند.
الکس والیوشکو، عضو کارکنان فنی در Tailscale میگوید: «این به تأخیر کمتر و اساسا پردازش سریعتر دادهها از لحظه خواندن آنها از سیم تا لحظه ارسال آن به سیستمعامل ترجمه میشود».
با بهرهگیری از قابلیتهای نوشتن لینوکس در سرویس گیرنده Tailscale، Tailscale میتواند چندین قطعه از دادههای بسته را در یک عملیات به هسته لینوکس ارسال کند، نه اینکه مجبور باشد آن قطعات را قبل از ارسال به هسته کپی و ترکیب کند. v در writev مخفف "بردار" است: Tailscale میتواند قطعات جداگانهای از دادهها را که باید جابجا شوند، بدون جابجایی آنها توصیف کند. این به معنای کپی کمتر از داده های بسته در حافظه، عملیات نوشتن کمتر و توان عملیاتی بالاتر است.
در حال حاضر، این افزایشها فقط در لینوکس و در صورت لزوم، سیستمهای اندروید در دسترس هستند. اما ما همچنین روی ویژگیهایی کار کردهایم که برای سایر سیستمها کاربرد دارند. کلاینتهای Tailscale به زودی میتوانند از کش کردن نقشه شبکه برای شروع سریعتر در بسیاری از شرایط استفاده کنند.
ماشینی که به Tailscale متصل می شود معمولا با اتصال به صفحه کنترل Tailscale در چیزی حدود 100 میلی ثانیه در یک شبکه معمولی شروع می شود. دستگاه احراز هویت میکند و یک «نقشه شبکه» (نقشه شبکه) دریافت میکند که دستگاههایی را که میتواند به آن دسترسی پیدا کند و نحوه دسترسی به آنها را توصیف میکند. این فرآیند راهاندازی باید سریع و شاید آنی باشد و معمولا با یک اتصال شبکه خوب انجام میشود.
اما وقتی در هواپیمای بد وای فای هستید، یا در داخل هتلی با فیلترهای تهاجمی، یا سایر تنظیمات اتصال نه چندان عالی هستید، ممکن است مدتی طول بکشد تا دستگاه به هواپیمای کنترلی برسد — و گاهی اوقات ممکن است اصلا نتوانید به آن برسید. اغلب مشخص نیست که مشکل کجاست، اما نتیجه این است که نمیتوانید به دستگاههای دیگر دسترسی پیدا کنید.
حتی در شرایط ایده آل شبکه، 100 میلی ثانیه تأخیر راه اندازی ممکن است برای برخی از بارهای کاری حساس به تأخیر بسیار زیاد باشد.
ذخیرهسازی Netmap به ماشینها کمک میکند تا زمانی که صفحه کنترل به سرعت قابل دسترسی نیست، متصل شوند. وقتی فعال است، هر دستگاه در tailnet شما یک کپی از netmap را روی دیسک ذخیره می کند. وقتی دستگاهی راهاندازی میشود، میتواند از آن نسخه ذخیرهشده برای برقراری ارتباط با دستگاههای دیگر در tailnet استفاده کند، تا زمانی که بتواند برای دریافت آخرین اطلاعات با صفحه کنترل تماس بگیرد. (این اتصالات مستقیما بین دستگاه ها مذاکره می شود و Tailscale طبق معمول هیچ ترافیکی را مشاهده نمی کند).
Claus Lensbøl، یکی از اعضای کادر فنی، گفت: «شرایط بد شبکه - این واقعا فضایی است که مردم میتوانند از ذخیرهسازی نقشه شبکه بهرهمند شوند. «[یک مشتری دستگاه میگوید]، «میدانی چیست؟ ما هنوز با کنترل صحبت نکردهایم. احتمالا به زودی به آنجا خواهیم رسید. در این مدت، هنوز میتوانید کاری را شروع کنید.»
چند محدودیت وجود دارد. ذخیره سازی در حافظه پنهان تنها در صورتی می تواند کار کند که دستگاه قبلا حداقل یک بار به tailnet متصل شده باشد تا نقشه شبکه را از صفحه کنترل دریافت کند. علاوه بر این، کش کردن نقشه شبکه به دستگاه نیاز دارد که فضای دیسک دائمی برای ذخیره کش داشته باشد. ما دقت کردهایم تا نوشتنهای غیرضروری دیسک را به حداقل برسانیم، اما در برخی موارد ممکن است نخواهید آن را فعال کنید. برای مثال، در tailnet های بسیار بزرگ، به روز رسانی کش ممکن است به ترافیک دیسک زیادی نیاز داشته باشد. به همین ترتیب، دستگاههایی که از ذخیرهسازی کند یا حساس به سایش مانند کارتهای SD استفاده میکنند، ممکن است ترجیح دهند که کش شبکه را فعال نکنند.
با این حال، برای اکثر دستگاههای موجود در بیشتر tailnetها، این ویژگی میتواند به طور قابل توجهی سرعت برقراری ارتباط دستگاهها با یکدیگر را در هنگام راهاندازی افزایش دهد. ما دیدهایم که شبکههای عقب با قابلیت دسترسی به هواپیمای کنترلی ضعیف شروع به ارسال از طریق صفحه داده، در یک شروع حافظه پنهان «گرم»، یک تا دو مرتبه بزرگتر از شروع «سرد» کردهاند. برای دستگاههایی که با تأخیر راهاندازی متغیر مواجه هستند یا از سرور DERP یا صفحه کنترل دور هستند، مزایای آن بهویژه ملموس است.
مطمئنا، ما فکر می کنیم Tailscale سریع است. اما شما نباید در این مورد به ما اعتماد کنید. به همین دلیل است که ما در حال بررسی یک جعبه ابزار نظارت و تست Tailscale هستیم. ما میخواهیم به مشتریان خود ابزار مورد نیاز برای آزمایش، تشخیص و درک پیکربندی شبکهشان را به روشی که Tailscale-Native است ارائه دهیم.
در اینجا شکاف هایی وجود دارد که در تست عملکرد مدرن می بینیم:
ابزار موجود، مسیرها و وضعیت های بومی Tailscale را درک نمی کند. بنابراین ما در حال بررسی ابزاری هستیم که این کار را انجام می دهد. به ما کمک کنید آینده آزمایش عملکرد را در Tailscale شکل دهیم.
متن اصلی (انگلیسی)
Making Tailscale Faster
Article URL: https://tailscale.com/blog/making-tailscale-faster Comments URL: https://news.ycombinator.com/item?id=49819880 Points: 244 # Comments: 105