چرا VPN من اینقدر کند است؟ این چهار بخش را آزمایش کنید

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

ترتیب زیر از وظیفه به سمت بیرون حرکت می‌کند، زیرا تونل نمی‌تواند پهنای باندی را فراهم کند که در زیر آن کم است.

پیش از اندازه‌گیری مشخص کنید کند یعنی چه

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

بدون آن سابقه، هر مقایسه بعدی به بحثی درباره برداشت‌ها تبدیل می‌شود.

نخست شبکه دسترسی را بررسی کنید

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

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

اگر خط پایه از قبل بد است، کار به Wi-Fi، تقاضای روتر یا سرویس دسترسی مربوط است. آزمون با کابل یا موقعیت ثابت نزدیک نقطه دسترسی، پیوند رادیویی ضعیف را از پیوند بالادستی شلوغ جدا می‌کند. هیچ کاری که تونل انجام دهد ظرفیتی را که خط دسترسی ارائه نمی‌دهد اضافه نمی‌کند.

خروجی را عوض کنید، سپس انتقال

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

هر جا سرویس هر دو پروفایل را ارائه می‌دهد، OpenVPN روی UDP را با OpenVPN روی TCP مقایسه کنید. UDP نقطه شروع معمول برای کار تعاملی است، در حالی که TCP می‌تواند در شبکه دسترسی‌ای که ترافیک UDP را به کلی عبور نمی‌دهد کمک کند. تونل TCP افت را با ارسال دوباره درون جریان جبران می‌کند، و همین باعث می‌شود روی پیوندی که بسته می‌ریزد کندتر حس شود، و یادداشت‌های عیب‌یابی کارایی OpenVPN همین بده‌بستان را پیش از تنظیم هر چیز دیگری پوشش می‌دهند. تغییر کلمه "udp" به "tcp" در یک پروفایل نمی‌تواند شنودکننده‌ای بسازد که سرور هرگز باز نکرده است.

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

دستگاه و نشانه را با هم بخوانید

بار پردازنده را در طول انتقال تماشا کنید نه بعد از آن، زیرا هزینه رمزنگاری با ترافیک زیاد می‌شود و روتر کوچکی که به یک خانواده خدمت می‌کند ماشینی متفاوت از لپ‌تاپی است که مشتری خودش را اجرا می‌کند. یک VPN دیگر، یک ماشین مجازی یا یک فیلتر شبکه می‌توانند در همان مسیر بنشینند و سهمی از ترافیک را بگیرند. نرم‌افزار را به‌روز نگه دارید بدون حذف بررسی‌های احراز هویت یا کلید قطع اضطراری برای بهتر نشان دادن یک محک. اگر درخواست‌های کوچک موفق شوند و آپلودهای بزرگ در اندازه‌ای یکنواخت بایستند، بررسی MTU ایستگاه بعدی است.

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

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