خط اینترنت بهتر (zev tune)

خطی ممکن است «سریع» باشد و باز هم بد حس شود: تماس تصویری هر بار که کسی عکسی آپلود می‌کند یخ می‌زند، بازی با جهش‌هایی لگ می‌زند، صفحه‌ها یک ثانیه معطل می‌مانند تا شروع شوند. تست‌های سرعت به‌ندرت دلیلش را نشان می‌دهند. دلیل‌های رایج **جیتر** است (رفت‌وبرگشت‌هایی که بالا و پایین می‌روند)، **گم‌شدن بسته** (بسته‌هایی که هرگز نمی‌رسند)، و **bufferbloat**: خطِ پر، بسته‌ها را صدها میلی‌ثانیه در مودم یا گوشی صف می‌کند و همه چیزِ دیگر پشتشان منتظر می‌ماند. اگر چیزی خراب است و نه فقط کند (اصلاً اینترنت نیست، نام‌ها پیدا نمی‌شوند، پراکسی‌ای که دیگر نیست)، با [zev doctor](/docs/fa/doctor) شروع کنید: می‌گوید کدام لایه خراب است. `zev tune check` همهٔ این‌ها را از همین رایانه اندازه می‌گیرد، می‌گوید مشکل کجاست (وای‌فای شما، همین رایانه، یا آن سوی روتر) و چه چیزی را درست می‌کند. سپس `sudo zev tune on` درستش می‌کند، **هر بار یک تغییر**: بلافاصله پس از هر تغییر بررسی می‌کند که اینترنت هنوز جواب می‌دهد (وگرنه آن تغییر برداشته می‌شود)، آنچه آن تغییر برایش است را با خطِ درست پیش از آن مقایسه می‌کند، و فقط اگر کمک کرده یا هزینه‌ای نداشته نگهش می‌دارد. در پایان کل خط را دوباره اندازه می‌گیرد و قبل و بعد را کنار هم نشان می‌دهد. فعلاً برای لینوکس. ```bash zev tune check # اندازه‌گیری کامل: بی‌تغییر، بی sudo sudo zev tune on # اندازه‌گیری ← یکی‌یکی درست کردن ← دوباره اندازه‌گیری zev tune status # چه چیزی تغییر کرده، قبل و بعد، صف زنده sudo zev tune off # همه چیز درست همان‌طور که بود ``` ```diagram type: flow title: sudo zev tune on چطور خط شما را تغییر می‌دهد --- اندازه‌گیری | رفت‌وبرگشت تا روتر و سه جا در اینترنت، در حالت بیکار و وقتی خط در هر دو جهت پر است؛ سرعت؛ DNS؛ MTU مسیر؛ IPv6؛ کارت وای‌فای | accent | 📏 ~ چه چیزی جلویش را گرفته برنامه | فقط راه‌حل‌هایی که عددها می‌خواهند، امن‌ترها اول، و فقط آنچه این کرنل و کارت شبکه می‌توانند | | 🧭 ~ یک تغییر بررسی اتصال | درست پس از تغییر: اینترنت هنوز جواب می‌دهد؟ اگر نه، تغییر بی‌درنگ برداشته می‌شود | warn | 🛟 ~ جواب می‌دهد اندازه‌گیری همان تغییر | آنچه تغییر برایش است (جیتر روتر، تأخیر زیر بار، سرعت آپلود) در برابر خطِ درست پیش از آن | | 🔬 ~ کمک کرد، یا هزینه‌ای نداشت نگه داشتن | راه‌حل بعدی از خطِ همراه این یکی شروع می‌کند؛ آنچه کمک نکرد برگردانده می‌شود | good | ✅ ~ همه امتحان شدند دوباره اندازه‌گیری | کل خط، به همان روشِ قبل؛ اگر روی‌هم‌رفته بدتر باشد، همه چیز برداشته می‌شود | accent | 📊 ``` ## در یک دقیقه شروع کنید ```diagram type: cards title: خط بهتر با سه فرمان --- 1️⃣ | نگاه | zev tune check: حدود ۲۵ ثانیه؛ عددهای خط، به چه کاری می‌آید، مشکل کجاست، و چه چیزی درست می‌شود 2️⃣ | درست کردن | sudo zev tune on: هر راه‌حل امتحان، بررسی و اندازه‌گیری می‌شود؛ فقط آنچه کمک کرد می‌ماند 3️⃣ | دیدن | zev tune status: چه تغییر کرد و چقدر؛ sudo zev tune off همه‌اش را برمی‌گرداند ``` اول هر دانلود یا پخشی را ببندید: zev tune عمداً خط را پر می‌کند، و ترافیک دیگر عددها را پرنوسان‌تر می‌کند. `--quick` در حدود نصف زمان اندازه می‌گیرد. ```bash zev tune check # اندازه‌گیری کامل، حدود ۲۵ ثانیه؛ چیزی را تغییر نمی‌دهد zev tune check --quick # حدود نصف زمان zev tune check --proxy # از راه zev proxy share هم: سرور پراکسی شما چه چیزی اضافه می‌کند zev tune check --json | jq .score # عددها برای یک اسکریپت sudo zev tune on # اندازه بگیر، یکی‌یکی درست کن، دوباره اندازه بگیر sudo zev tune on --only shaper,wifi_power # فقط این راه‌حل‌ها (اگر عددها لازمشان بدانند) sudo zev tune on --skip bbr # همه به‌جز این یکی sudo zev tune on --no-service --no-failover # تا ری‌استارت بعدی، و هیچ‌وقت عوض کردن اتصال zev tune status # چه چیزی تغییر کرد، قبل و بعد sudo zev tune off # همه‌چیز همان‌طور که بود ``` ## همهٔ فرمان‌ها | فرمان | نمونه | چه می‌کند | |---|---|---| | `check` | `zev tune check` · `zev tune check --quick` | خط را کامل اندازه می‌گیرد؛ چیزی را تغییر نمی‌دهد، sudo نمی‌خواهد | | `check --proxy` | `zev tune check --proxy` | از راه `zev proxy share` هم اندازه می‌گیرد: سرور پروکسی شما چه می‌افزاید | | `check --json` | `zev tune check --json \| jq .score` | عددها برای اسکریپت‌ها | | `on` | `sudo zev tune on` | اندازه‌گیری، یکی‌یکی درست کردن (هر کدام بررسی و اندازه‌گیری می‌شود)، دوباره اندازه‌گیری | | `on --only` | `sudo zev tune on --only wifi_power,shaper` | فقط این راه‌حل‌ها (وقتی عددها بخواهندشان) | | `on --skip` | `sudo zev tune on --skip bbr` | همه جز این‌ها | | `on --no-service` | `sudo zev tune on --no-service` | راه‌حل‌ها تا راه‌اندازی دوباره می‌مانند؛ بی سرویس zev-tune | | `on --no-failover` | `sudo zev tune on --no-failover` | سرویس هیچ‌وقت به اتصال دوم نمی‌رود | | `status` | `zev tune status` | چه چیزی تغییر کرده، قبل و بعد، نرخ زندهٔ صف هوشمند | | `networks` | `zev tune networks` · `zev tune networks --json` | هر شبکه‌ای که اندازه گرفته شده، امتیازش قبل و بعد، نرخ‌های صفش | | `forget` | `sudo zev tune forget "wlan0 via 192.168.1.1"` · `sudo zev tune forget all` | دفعهٔ بعد آن شبکه دوباره اندازه گرفته شود | | `history` | `zev tune history` · `zev tune history --days 7` · `zev tune history --json` | خط ساعت به ساعت (یا روز به روز): تأخیر، تأخیر افزوده، بی‌جواب‌ها، زمان قطعی، جابه‌جایی‌ها | | `links` | `zev tune links` · `zev tune links --json` | هر اتصال به اینترنت، که از راه دستگاه خودش بررسی می‌شود، و اینکه کدام ترافیک را می‌برد | | `off` | `sudo zev tune off` | همه چیز درست همان‌طور که بود برمی‌گردد و سرویس برداشته می‌شود | ## چه چیزهایی را اندازه می‌گیرد | | چطور | چرا مهم است | |---|---|---| | **تأخیر** | رفت‌وبرگشت تا Cloudflare، Google و Quad9، ۲۰ بار در ثانیه؛ پایدارترینشان نمایندهٔ «اینترنت» است | هر کلیک دست‌کم یک رفت‌وبرگشت منتظر می‌ماند | | **جیتر** | رفت‌وبرگشت‌های پشت‌سرهم چقدر با هم فرق دارند (و جیتر هموارشدهٔ RFC 3550)؛ بدترِ این دو | تماس و بازی رفت‌وبرگشت بی‌نوسان می‌خواهند | | **گم‌شدن بسته** | رفت‌وبرگشت‌هایی که هرگز برنگشتند | هر بستهٔ گم‌شده یک بار فرستادن دوباره می‌خواهد و TCP کند می‌شود | | **روتر** | همان رفت‌وبرگشت‌ها تا روتر شما (gateway) | اگر روتر خودش نوسان دارد، مشکل وای‌فای یا کابل شماست، نه سرویس‌دهنده | | **سرعت** | چهار جریان هم‌زمان، دانلود و آپلود، از شمارنده‌های کارت شبکه هر یک‌چهارم ثانیه پس از ۱٫۵ ثانیهٔ اول | خط چقدر می‌برد و چقدر نوسان دارد | | **Bufferbloat** | تأخیر **هنگام** دانلود و **هنگام** آپلود، منهای حالت بیکار | خطِ پر همه چیزِ دیگر را چقدر معطل می‌کند؛ نمره از A+ تا F | | **DNS** | جست‌وجوهای خودِ سیستم چقدر طول می‌کشند، نام‌های در حافظه و تازه | نام‌های کند هر سایت تازه را کند می‌کنند | | **MTU مسیر** | بزرگ‌ترین بسته‌ای که سالم می‌رسد، و آیا بزرگ‌ترها بی‌صدا گم می‌شوند | «سیاه‌چاله» اتصال‌ها را در انتقال‌های بزرگ معلق می‌کند | | **IPv6** | آیا این رایانه IPv6 دارد، و آیا به اینترنت می‌رسد | IPv6 خراب اتصال‌ها را اول منتظر خودش نگه می‌دارد | | **ارسال دوبارهٔ TCP** | بخش‌هایی که سیستم هنگام آپلود دوباره فرستاد | گم‌شدنی که در پینگ دیده نمی‌شود | | **وای‌فای** | نام شبکه، باند، قدرت سیگنال، نرخ پیوند، ذخیرهٔ انرژی | اغلب خود کارت علت است | جایی که ICMP (پینگ) بسته است، رفت‌وبرگشت با دست‌دادن TCP زمان‌گیری می‌شود؛ با دسترسی root، جایی که سوکت پینگ مجاز نیست، سوکت خام ICMP به کار می‌رود. ```diagram type: graph title: تأخیر از کجا می‌آید alt: این رایانه از وای‌فای یا کابل به روتر می‌رسد؛ روتر به سرویس‌دهنده و اینترنت. رفت‌وبرگشت تا روتر سهم وای‌فای را نشان می‌دهد؛ رفت‌وبرگشت فراتر از آن کل راه را؛ وقتی خط پر است، صف مودم یا گوشی به‌صورت bufferbloat دیده می‌شود legend: path=اندازه‌گیری در حالت بیکار; path2=اندازه‌گیری وقتی خط پر است start: این رایانه caption: مقایسهٔ عددهای روتر با عددهای اینترنت نشان می‌دهد مشکل کجاست. height: 46 --- node pc | این رایانه | 8 22 | host | accent | zev tune اینجا اجرا می‌شود: کارت، ذخیرهٔ انرژی‌اش، TCP، صف خروجی node gw | روتر / گوشی | 38 22 | router | | رفت‌وبرگشت تا اینجا فقط سهم وای‌فای است node isp | سرویس‌دهنده | 64 22 | cloud | | گم‌شدن بسته فراتر از روتر اینجاست node web | اینترنت | 92 22 | cloud | | Cloudflare، Google و Quad9 نمایندهٔ آن‌اند link pc gw | وای‌فای یا کابل | path link gw isp | صف مودم | path2 link isp web | | path note 38 40 | خطِ پر اینجا صف می‌شود: bufferbloat | warn ``` ## خواندن یک گزارش یک گزارش واقعی، از لپ‌تاپی روی هات‌اسپات گوشی: ```text zev tune check how good this internet line is, and what holds it back wlo1 Wi-Fi "Phone" 2.4 GHz, signal -55 dBm (excellent), link 72 Mbit/s, power saving on direct · zev dns off idle downloading uploading latency 90.6 ms 119 ms (+28) 181 ms (+90) jitter 5.0 ms 12.1 ms 11.3 ms loss 0.0% 0.0% 0.0% router 3.2 ms ± 1.1 ms, loss 0.0% (downloading: 160 ms) speed down 51.9 Mbit/s up 21.0 Mbit/s bufferbloat A downloading, C uploading DNS 28.6 ms path MTU 1500 IPv6 none on this network TCP resent 1.0% of what was sent Score 70/100 browsing ~ streaming ✓ video calls ~ gaming ✗ • the router answers its own pings slowly while busy (+157 ms; phones do): traffic through it waits only +28 ms, so that is not a queue • on 2.4 GHz with a strong signal: if the router has 5 GHz, it is usually faster and calmer What sudo zev tune on would do (each one measured, kept only if it helps): 1. Wi-Fi power saving off — the Wi-Fi card sleeps between packets, which adds delay and jitter on every network 2. smart queue (CAKE), adjusted live — uploading adds a lot of delay to everything else (bufferbloat) 3. small TCP send queue — apps queue a lot of unsent data in the kernel, so small replies wait behind it 4. BBR congestion control — a long line: the default TCP takes long to get up to speed ``` - **latency (+N)**: رفت‌وبرگشت وقتی خط پر است، و خطِ پر چقدر به آن افزود. اینجا یک آپلود ۹۰ میلی‌ثانیه به همه چیز می‌افزاید: تماس هر بار که عکسی همگام می‌شود تکه‌تکه می‌شود. - **bufferbloat** به تأخیر افزوده نمره می‌دهد: A+ زیر ۵ میلی‌ثانیه، A زیر ۳۰، B زیر ۶۰، C زیر ۲۰۰، D زیر ۴۰۰، F بیشتر. - **router**: ۳ میلی‌ثانیه و پایدار، پس وای‌فای در حالت بیکار سالم است. هنگام دانلود گوشی به پینگ‌های خودش در ۱۶۰ میلی‌ثانیه پاسخ می‌دهد، ولی ترافیکی که از آن می‌گذرد فقط ۲۸ میلی‌ثانیه بیشتر صبر می‌کند: گوشیِ پرکار پینگ‌های خودش را آخر از همه جواب می‌دهد و این چیز دیگری را کند نمی‌کند. صفِ واقعی در این سمت هر دو را کند می‌کرد، و آن وقت خطِ • همین را می‌گوید. - **Score** تأخیر، جیتر، گم‌شدن بسته، bufferbloat، سرعت و DNS را در یک عدد می‌گذارد؛ نشانه‌ها می‌گویند خط همین حالا به چه کاری می‌آید (✓ خوب، ~ کار می‌کند، ✗ ضعیف). - خط‌های **•** همان چیزی است که عددها به زبان ساده می‌گویند، از جمله آنچه هیچ تنظیمی درستش نمی‌کند (سیگنال ضعیف، باند شلوغ). ## sudo zev tune on چه نشان می‌دهد پس از همان گزارشِ `check` («Before»)، هر راه‌حل با آنچه کرد، سپس خطِ دوباره اندازه‌گرفته. از مودمِ با بافرهای عمیق در آزمایشگاه آزمون: ```text Trying, one at a time: 1. smart queue (CAKE), adjusted live — a full line adds a lot of delay both ways (bufferbloat) 2. small TCP send queue — apps queue a lot of unsent data in the kernel, so small replies wait behind it 3. BBR congestion control — packets get lost here, and the default TCP slows down a lot for every loss ✓ smart queue (CAKE), adjusted live uploading +437 → +1 ms, 8.8 → 7.9 Mbit/s; downloading +272 → +0 ms, 29.4 → 25.9 Mbit/s ✓ small TCP send queue costs nothing; replies no longer wait behind queued uploads ✓ BBR congestion control upload 7.9 → 7.9 Mbit/s After before after score 60/100 95/100 ▲ better latency 20.2 ms 20.3 ms jitter 0.1 ms 0.1 ms loss 0.0% 0.0% download 29.4 Mbit/s 26.0 Mbit/s −12%, the smart queue's share upload 8.8 Mbit/s 7.9 Mbit/s −10%, the smart queue's share bloat, down +272 ms D +0 ms A+ ▲ better bloat, up +437 ms F +1 ms A+ ▲ better ``` `✓` نگه داشته شد، `↺` برگردانده شد (کمک نکرد، یا اتصال دیگر جواب نداد)، `–` اینجا نمی‌شد تنظیمش کرد. هر راه‌حل فقط وقتی می‌ماند که اندازه‌گیری خودش بگوید؛ جدول آخر کل خط است، به همان روشِ قبل اندازه‌گرفته. ## راه‌حل‌ها هر کدام فقط وقتی پیشنهاد می‌شود که عددها بخواهندش، و فقط اگر این رایانه بتواند. | راه‌حل | کِی | چه تغییر می‌کند | چطور بررسی می‌شود | |---|---|---|---| | `wifi_power` | ذخیرهٔ انرژی کارت وای‌فای روشن است | `iw dev <card> set power_save off`: کارت دیگر بین بسته‌ها چرت نمی‌زند | دوباره رفت‌وبرگشت تا روتر: جیتر و میانه نباید بدتر شوند | | `shaper` | خطِ پر ۳۰ میلی‌ثانیه یا بیشتر می‌افزاید (bufferbloat نمرهٔ B یا بدتر) | **CAKE** در مسیر خروج روی ۹۰٪ آپلودِ اندازه‌گرفته، و در مسیر ورود (با یک دستگاه `ifb`) روی ۹۰٪ دانلود | دوباره آزمون زیر بار: تأخیر افزوده باید دست‌کم ۳۰٪ و ۱۰ میلی‌ثانیه پایین بیاید، و سرعت بیش از ۳۵٪ نیفتد | | `notsent_lowat` | آپلود تأخیر می‌افزاید | `net.ipv4.tcp_notsent_lowat = 131072`: برنامه‌ها دادهٔ فرستاده‌نشدهٔ کمتری در کرنل نگه می‌دارند | هزینه‌ای ندارد؛ همراه صف هوشمند بررسی می‌شود | | `bbr` | گم‌شدن بسته، ارسال دوبارهٔ زیاد، خط طولانی، یا آپلود پرنوسان | `net.ipv4.tcp_congestion_control = bbr` | دوباره آپلود: نباید کندتر شود یا تأخیر بیشتری بیفزاید | | `mtu_probing` | مسیر بسته‌های کوچک‌تری می‌پذیرد، یا بزرگ‌ترها گم می‌شوند | `net.ipv4.tcp_mtu_probing = 1`: TCP اندازه‌ای را که می‌گذرد خودش پیدا می‌کند | هزینه‌ای ندارد | | `buffers` | خط بیش از آنچه پنجره‌های TCP اجازه می‌دهند در راه نگه می‌دارد (خطی سریع و طولانی) | بیشینهٔ `tcp_rmem`/`tcp_wmem` و `rmem_max`/`wmem_max` تا دو برابرِ آنچه خط نگه می‌دارد | دوباره دانلود: نباید کندتر شود | | `prefer_v4` | این رایانه IPv6 دارد ولی به اینترنت نمی‌رسد | یک خط نشانه‌دار در `/etc/gai.conf`: نشانی‌های IPv4 اول | جست‌وجوها و اتصال‌ها | آنچه zev tune هرگز دست نمی‌زند: صفی که کس دیگری روی رابط ساخته (با شناسهٔ خودش)، فایل `/etc/gai.conf`ی که ترتیب خودش را دارد، MTU رابط، قاعده‌های دیوار آتش، یا هر چیزی روی روتر. ## Bufferbloat و صف هوشمند مودم یا گوشیِ پر، بسته‌ها را به‌جای دور ریختن در بافری عمیق نگه می‌دارد. بسته‌های کوچک تماس شما پشت یک ثانیه از آپلود کسی منتظر می‌مانند. راه‌حل این است که **همین رایانه** کندترین نقطه شود، کمی زیر سرعت واقعی خط: آن‌وقت صف اینجا ساخته می‌شود، در CAKE، که صف هر جریان را کوتاه نگه می‌دارد و بسته‌های کوچک را اول می‌فرستد. خط حدود ۱۰٪ از بیشترین سرعتش را از دست می‌دهد؛ همه چیزِ دیگر دیگر منتظر نمی‌ماند. ترافیک با شبکهٔ خودتان (روتر، NAS، چاپگر، IPv6 محلی) در هر دو جهت از صف نمی‌گذرد: فقط اینترنت شکل داده می‌شود. اندازه‌گیری‌شده در آزمایشگاه آزمون (مودمی با بافرهای عمیق، ۳۰ مگابیت دانلود، ۸ مگابیت آپلود): ```diagram type: stats title: تأخیری که خطِ پر می‌افزاید، پیش و پس از zev tune --- +438 ms | آپلود، پیش | نمرهٔ F: تماس هر بار که چیزی آپلود می‌شود یخ می‌زند | 100 | warn +1 ms | آپلود، پس | نمرهٔ A+، با CAKE روی ۹۰٪ آپلود (۸٫۸ ← ۷٫۹ مگابیت) | 1 | good +276 ms | دانلود، پیش | نمرهٔ D | 63 | warn +0 ms | دانلود، پس | نمرهٔ A+، از راه دستگاه ifb (۲۹٫۴ ← ۲۵٫۹ مگابیت) | 1 | good ``` ### صف همراه خط می‌رود نرخ ثابت روی وای‌فای، هات‌اسپات گوشی یا یک عصر شلوغ نادرست است: سرعت خط تغییر می‌کند. **سرویس zev-tune** (که `sudo zev tune on` جایی که systemd هست نصبش می‌کند) پیوسته پنج رفت‌وبرگشت در ثانیه اندازه می‌گیرد و نرخ صف را جابه‌جا می‌کند: - **تأخیر بیشتر وقتی آن جهت شلوغ است** ← نرخ زیرِ آنچه گذشت می‌آید، تا صفِ آن سو خالی شود؛ - **شلوغ و آرام** ← نرخ هر بار ۴٪ بالا می‌رود، تا ۱٫۶ برابرِ آنچه اندازه گرفته شد؛ - **ساکت** ← کم‌کم به نرخ اندازه‌گرفته برمی‌گردد. این سرویس **باز شکست می‌خورد**: روی شبکه‌ای که اندازه نگرفته، یا وقتی ۱۰ ثانیه هیچ چیز جواب نمی‌دهد، صف برداشته می‌شود؛ وقتی یک شبکهٔ اندازه‌گرفته برگردد، صف هم برمی‌گردد. راه‌حل‌های دیگر را هم پس از راه‌اندازی دوباره سر جایشان می‌گذارد، و وقتی وصل‌شدن دوبارهٔ وای‌فای ذخیرهٔ انرژی را روشن کند، دوباره خاموشش می‌کند. ```diagram type: sequence title: خط کندتر می‌شود؛ صف همراهش می‌رود lanes: خط | سرویس zev-tune | CAKE alt: خط از ۸ به ۴ مگابیت کند می‌شود؛ رفت‌وبرگشت هنگام آپلود بالا می‌رود؛ سرویس نرخ CAKE را زیرِ آنچه گذشت می‌آورد؛ رفت‌وبرگشت پایین برمی‌گردد؛ وقتی خط بیکار است نرخ کم‌کم برمی‌گردد --- خط --> سرویس zev-tune : رفت‌وبرگشت +۴۰ میلی‌ثانیه هنگام آپلود سرویس zev-tune -> CAKE : ۷٫۲ ← ۳٫۶ مگابیت note CAKE : صف دوباره اینجا ساخته می‌شود، کوتاه | good خط --> سرویس zev-tune : رفت‌وبرگشت دوباره +۵ میلی‌ثانیه == ساکت == سرویس zev-tune -> CAKE : آرام‌آرام برگشت به نرخ اندازه‌گرفته ``` ## همهٔ شبکه‌ها را به خاطر می‌سپارد هر شبکه‌ای که رویش `sudo zev tune on` را اجرا کنید با خط خودش به خاطر سپرده می‌شود: نرخ‌های صف هوشمند، آنچه نگه داشته شد، و امتیاز قبل و بعد. خانه، اداره و هات‌اسپات گوشی هر کدام مال خودشان را دارند. وقتی به یکی برمی‌گردید، سرویس zev-tune صف همان شبکه را خودش برمی‌گرداند، تا پنج ثانیه بعد از عوض شدن روتر، بی اندازه‌گیری دوباره. روی شبکه‌ای که هیچ‌وقت اندازه نگرفته، صف کنار می‌رود. ```bash zev tune networks ``` ```text Networks zev tune remembers back on one, its smart queue comes back by itself network measured score queue down/up Mbit/s kept wlan0 via 192.168.43.1 just now 44 → 86 - / 3.6 shaper, wifi_power ● wlan0 via 192.168.1.1 2 days ago 58 → 91 27.0 / 7.2 shaper, notsent_lowat ● = here. sudo zev tune forget <network> measures it again next time. ``` ```diagram type: sequence title: خانه، هات‌اسپات، دوباره خانه lanes: شما | سرویس zev-tune | CAKE alt: در خانه سرویس با نرخ‌های خانه صف را می‌سازد؛ روی هات‌اسپات به نرخ‌های به‌خاطرسپردهٔ هات‌اسپات می‌رود؛ در کافه‌ای که هیچ‌وقت اندازه نگرفته صف را برمی‌دارد؛ در خانه دوباره صف خانه را برمی‌گرداند، همه بی اندازه‌گیری دوباره --- شما -> سرویس zev-tune : در خانه سرویس zev-tune -> CAKE : صف خانه: ۲۷ / ۷٫۲ مگابیت شما -> سرویس zev-tune : روی هات‌اسپات گوشی سرویس zev-tune -> CAKE : صف هات‌اسپات: ۳٫۶ مگابیت بالا | good شما -> سرویس zev-tune : کافه‌ای که هیچ‌وقت اندازه گرفته نشده سرویس zev-tune -> CAKE : صف خاموش (نرخش حدس می‌شد) | warn شما -> سرویس zev-tune : دوباره خانه سرویس zev-tune -> CAKE : صف خانه برمی‌گردد، بی اندازه‌گیری | good ``` ## تاریخچهٔ خط سرویس هر دقیقه یک نمونه می‌نویسد: تأخیر در حال آرام، تأخیری که ترافیک افزود، بدترین لحظه، آنچه بی‌جواب ماند، زمانی که اصلاً جوابی نیامد، و اینکه روی کدام شبکه و اتصال بود. دو هفته نگه داشته می‌شود. می‌گوید خط **کِی** بد است، چیزی که تست سرعت هیچ‌وقت نمی‌گوید، و چیزی است که می‌توانید به سرویس‌دهنده‌تان نشان بدهید. ```bash zev tune history # ۲۴ ساعت گذشته، ساعت به ساعت zev tune history --days 7 # روز به روز zev tune history --json # همهٔ نمونه‌ها، برای صفحه‌گسترده یا یک تیکت ``` ```text The line, hour by hour latency at rest + delay added by traffic; worst; unanswered; time without any answer 10-29 18:00 ▃ 24 ms + 4 worst 61 ms 0.2% unanswered wlan0 via 192.168.1.1 10-29 19:00 ▆ 25 ms + 31 worst 212 ms 1.4% unanswered wlan0 via 192.168.1.1 10-29 20:00 █ 26 ms + 58 worst 480 ms 6.1% unanswered 95 s down 1 event wlan0 via 192.168.1.1 10-29 21:00 ▃ 24 ms + 5 worst 70 ms 0.1% unanswered wlan0 via 192.168.1.1 trend ····················▃▆█▃ events 66 min ago back on wlan0 (it answered for 30 s; usb0 rests) 67 min ago switched to usb0: wlan0 stopped answering ``` یک `·` در روند، ساعتی است که نمونه‌ای ندارد: کامپیوتر خاموش یا در خواب بود. ```diagram type: cards title: خواندن یک ردیف --- 24 ms | در حال آرام | رفت‌وبرگشت وقتی خط آرام است: فاصله و سرویس‌دهنده | +31 | افزودهٔ ترافیک | وقتی خط شلوغ بود چقدر بیشتر شد. زیر ۱۰ خوب است؛ صف هوشمند آن را آنجا نگه می‌دارد | accent worst | بدترین لحظه | طولانی‌ترین رفت‌وبرگشت آن ساعت: همانی که تماس تصویری حس کرد | unanswered، down | گم‌شده و قطع | جواب‌هایی که هیچ‌وقت نیامدند، و ثانیه‌هایی که اصلاً جوابی نبود | warn ``` ## دو اتصال: وقتی یکی قطع شد، دیگری کار را می‌گیرد وقتی بیش از یک اتصال به اینترنت دارید (وای‌فای و کابل، یا وای‌فای و گوشی از راه USB)، سرویس zev-tune هر پنج ثانیه **هر کدام را از راه دستگاه خودش** بررسی می‌کند، پس پیش از آنکه لازمش شود می‌داند دومی کار می‌کند. وقتی اتصال اصلی سه بار پشت سر هم (۱۵ ثانیه) به اینترنت نرسد، ترافیک از بهترین اتصال دیگری که جواب می‌دهد می‌رود. وقتی اتصال اصلی ۳۰ ثانیه جواب داد برمی‌گردد، تا اتصالی که مدام قطع‌ووصل می‌شود آن را عقب‌وجلو نکند. ```bash zev tune links ``` ```text Connections to the internet each checked through its own device wlan0 via 192.168.1.1 metric 600 doesn't answer ▶ usb0 via 192.168.42.129 metric 100 answers 48 ms ⇄ usb0 carries traffic now: the main connection stopped answering. Back on the main one after it answers for 30 s. ``` ```diagram type: flow title: جابه‌جایی، و برگشت --- پاییدن | هر اتصال هر ۵ ثانیه از راه دستگاه خودش بررسی می‌شود | | 👀 ~ اتصال اصلی ۳ بار جواب نمی‌دهد جابه‌جایی | ترافیک از بهترین اتصال دیگری که جواب می‌دهد می‌رود؛ صف هوشمند استراحت می‌کند | warn | ⇄ ~ اتصال اصلی ۳۰ ثانیه جواب می‌دهد برگشت | دوباره اتصال اصلی، با صف خودش | good | ✓ ``` فقط از اتصال‌هایی استفاده می‌کند که این کامپیوتر از قبل دارد: اتصالی که خودتان وصل کرده‌اید. جابه‌جایی یک مسیر مخصوص خودش است (با نشان `proto 177`) که وقتی برمی‌گردد یا متوقف می‌شود برش می‌دارد، پس به تنظیمات مدیر شبکهٔ شما هیچ‌وقت دست نمی‌خورد. هر جابه‌جایی در `zev tune history` هست. برای اینکه جابه‌جا نشود، `sudo zev tune on --no-failover` را به کار ببرید. ## هیچ‌وقت بی‌اتصال - **هر بار یک تغییر**، و درست پس از هر کدام بررسی اتصال (دست‌دادن TCP، سپس پینگ، به سه جا، سه بار): اگر هیچ چیز جواب ندهد، آن تغییر بی‌درنگ برداشته می‌شود و سراغ بعدی می‌رود. - **یک فرایند نگهبان** همراه `sudo zev tune on` شروع می‌شود. اگر zev tune on در میانه بایستد (کشته شود، ترمینال بسته شود، نشست SSH قطع شود)، نگهبان می‌بیند و همه چیز را برمی‌گرداند. - **اندازه‌گیری، نه فرض**: راه‌حلی که کمک نکرد برگردانده می‌شود، و اگر کل خط در پایان بدتر اندازه گرفته شود، همهٔ تغییرها برداشته می‌شوند. - **فقط مال خودش**: هر صفی که zev می‌افزاید شناسهٔ `7701:` دارد؛ `off` فقط همان‌ها را برمی‌دارد، و هر تنظیم را فقط اگر هنوز مقدار zev را دارد برمی‌گرداند. - **باز شکست می‌خورد**، در حالت زنده، همان‌طور که بالا آمد. ```bash sudo zev tune off # همه چیز برمی‌گردد؛ سرویس zev-tune برداشته می‌شود ``` ## همراه zev dns، zev proxy و zev vpn - **zev dns**: گزارش نشان می‌دهد `zev dns` روشن است یا نه و نام‌ها چقدر طول می‌کشند؛ وقتی کند هستند یا جواب نمی‌گیرند، به `sudo zev dns on` اشاره می‌کند. - **zev proxy**: `zev tune check --proxy` رفت‌وبرگشت و یک دانلود را از راه `zev proxy share` کنار خط مستقیم اندازه می‌گیرد، تا ببینید سرورتان چه می‌افزاید؛ سروری که خیلی نوسان دارد پیشنهاد `zev proxy use auto` می‌گیرد. - **zev vpn**: وقتی VPN روشن است، `sudo zev tune` خودِ خط را، از کنار تونل، اندازه می‌گیرد (چون راه‌حل‌ها همان را تغییر می‌دهند) و این را می‌گوید؛ بدون sudo اندازه‌گیری از تونل می‌گذرد. ## پرسش‌ها **اینترنتم را کند می‌کند؟** صف هوشمند حدود ۱۰٪ از بیشترین سرعت را می‌گیرد، و فقط وقتی می‌ماند که تأخیر را خیلی پایین آورده باشد. بقیه هزینهٔ اندازه‌پذیری ندارند، و بررسی می‌شوند. **اگر به شبکهٔ دیگری بروم؟** تنظیم‌ها (ذخیرهٔ انرژی، TCP) می‌مانند. روی شبکه‌ای که zev tune اندازه گرفته، صف هوشمند خودش خودبه‌خود برمی‌گردد. روی شبکه‌ای که اندازه نگرفته، صف کنار می‌رود، چون نرخش روی خط دیگری اندازه گرفته شده: آنجا هم `sudo zev tune on` را اجرا کنید، و از آن به بعد به خاطر سپرده می‌شود. **چرا هیچ چیز را نگه نداشت؟** یعنی اینجا هیچ چیز بهتر اندازه گرفته نشد. خط ممکن است به چیزهایی محدود باشد که هیچ تنظیم رایانه‌ای به آن‌ها نمی‌رسد: سیگنال، سرویس‌دهنده، فاصله تا سرور. **سرور تست سرعت جواب نمی‌دهد.** zev tune از تست سرعت Cloudflare استفاده می‌کند. `ZEV_TUNE_DOWN_URL` و `ZEV_TUNE_UP_URL` آن را به سرور دیگری می‌برند (یک GET که بایت‌های زیادی برمی‌گرداند، یک POST که آن‌ها را می‌گیرد). **فایل‌هایش کجاست؟** `/var/lib/zev/tune` (`state.json`: چه چیزی تغییر کرد و مقدارهای قبلی؛ `live.json`: صف و اتصال‌ها در همین لحظه؛ `networks/`: برای هر شبکهٔ اندازه‌گرفته یک فایل؛ `history.jsonl`: هر دقیقه یک نمونه، دو هفته نگه داشته می‌شود)، و `/etc/systemd/system/zev-tune.service`. **وقتی نمی‌خواهم، به اینترنت گوشی‌ام می‌رود؟** فقط وقتی اتصال اصلی ۱۵ ثانیه به اینترنت نرسد، و فقط به اتصالی که این کامپیوتر از قبل برایش مسیر دارد (اتصالی که خودتان وصل کرده‌اید). به‌محض اینکه اتصال اصلی ۳۰ ثانیه جواب بدهد برمی‌گردد. برای اینکه هیچ‌وقت جابه‌جا نشود، `sudo zev tune on --no-failover` را اجرا کنید. **خط من خوب است. سرویس کاری می‌کند؟** بله. `sudo zev tune on` حتی وقتی چیزی برای درست کردن نیست سرویس را نصب می‌کند، تا تاریخچه را بنویسد و اگر اتصال اصلی قطع شد اتصال را عوض کند (`zev tune status` می‌گوید «watches this line»).