إصلاح سرعة النقل البطيئة: تشخيص مشاكل الرفع وحلها

لإصلاح رفع بطيء، شخّص بالترتيب التالي: قِس الاتصال الخام بـ speedtest-cli، وقارنه بإنتاجية أداة النقل الفعلية في DevTools، وتحقق من المزامنات الخلفية التي تلتهم عرض النطاق، وتحقق من أن الخدمة لا تُقيّد لكل نقل، وتأكد من أنك متصل بأقرب نقطة نهاية إقليمية. خط 500 ميجابت/ث يُوصّل 40 ميجابت/ث إلى خدمة نقل يعني إما تنافساً على عرض النطاق، أو عدم تطابق منطقة CDN، أو تقييداً من الخادم، أو اختناقاً ذا تدفق واحد. لكل منها إصلاح مختلف، وجميعها تظهر في تبويب Network في DevTools قبل فعل أي شيء آخر.

قِس الأنبوب أولاً

قبل لوم خدمة النقل، تأكد أن اتصالك يُوصّل ما تعتقد أنه يُوصّل. شغّل speedtest-cli --json من طرفية، أو speedtest.net في المتصفح. اكتب ميجابت/ث الرفع وزمن الاستجابة والتأخر. هذا هو سقفك. إذا كان اتصالك "بـ 500 ميجابت/ث" يُوصّل فقط 80 ميجابت/ث رفعاً باختبار السرعة، لن تُحقق أي خدمة نقل أفضل.

شغّل الاختبار مرتين، مرة على Wi-Fi ومرة على Ethernet إن أمكن. الفارق يُخبرك كم يُكلّفك Wi-Fi. على Wi-Fi 5 في منزل متوسط، توقع خسارة 30 إلى 50% من سقف الاتصال السلكي.

قارن اختبار السرعة بإنتاجية النقل الفعلية

افتح خدمة النقل، ابدأ الرفع، وافتح DevTools > تبويب Network. راقب إنتاجية الطلب الفردي. إذا قال اختبار السرعة 500 ميجابت/ث والنقل يُوصّل 150 ميجابت/ث، الفجوة لها أربعة أسباب محتملة: الخدمة تستخدم تدفقاً واحداً (لا يستطيع إشباع أنبوب ذي زمن استجابة عالٍ)، أو نقطة نهاية CDN للخدمة بعيدة عنك، أو مستهلكو عرض النطاق الخلفيون يسرقون، أو الخدمة تُقيّد معدل النقل.

المُرفِعون المتوازيون المجزّأون (الخدمات القائمة على tus.io وS3 multipart وHexaTransfer) يجب أن يُشغّلوا 4 إلى 8 طلبات متزامنة. عدّها في العرض المائل. أقل من ذلك على خط سريع يعني أن الخدمة تترك عرض النطاق على الأرض.

أوقِل المزامنات الخلفية

Activity Monitor على macOS (تبويب Network، مرتباً حسب "Sent Bytes per sec") وResource Monitor على Windows (تبويب Network) يُظهران عرض نطاق كل عملية. المشتبه بهم المحتملون: Dropbox وGoogle Drive وOneDrive وiCloud Photos وBackblaze وTime Machine عبر الشبكة ومزامنة Adobe Creative Cloud. أغلقها، لا تُوقفها مؤقتاً فقط، لأن الإيقاف المؤقت أحياناً يُبقي اتصالات TCP مفتوحة.

مكالمة Zoom بدقة HD تستهلك 2.5 ميجابت/ث صاعداً. تحميل فيديو 4K من YouTube في تبويب آخر قد يستهلك 20 ميجابت/ث. حتى معاينات ملفات Slack تدفع بضع مئات كيلوبايت/ث. على الاتصالات غير المتماثلة (100 ميجابت/ث تنزيل، 10 ميجابت/ث رفع هو خط كابل شائع)، هذه تتراكم بسرعة.

تحقق من نقطة النهاية الإقليمية

كثير من خدمات النقل توجّه عبر حواف CDN. إذا كان DNS أو GeoIP لديك قديماً، ربما ترفع إلى حافة فرانكفورت من سيدني، مما يُضيف 300 ميلي ثانية زمن رحلة ويُحطم إنتاجية التدفق الواحد. تحقق من IP نقطة النهاية بلوحة DevTools > Network (انقر بالزر الأيمن على الطلب > Copy > Copy URL، ثم nslookup)، ثم ping للاطلاع على زمن الاستجابة.

زمن الاستجابة المثالي لاستيعاب خدمة نقلك: أقل من 20 ميلي ثانية لنفس المدينة، وأقل من 50 ميلي ثانية لنفس القارة، وأقل من 100 ميلي ثانية للنقل عبر القارات. إذا كنت عند 250 ميلي ثانية وأنت على القارة ذاتها التي تستضيف الخدمة، شيء ما يوجّه عبر حافة بعيدة.

بدّل DNS لاستبعاد GeoIP القديم

إذا كنت لا تزال على DNS الافتراضي لـ ISP، جرّب Cloudflare (1.1.1.1) أو Google (8.8.8.8) أو Quad9 (9.9.9.9) مؤقتاً. محللات مختلفة تُعيد حواف CDN مختلفة لأنها تُجيب على استفسارات ECS (EDNS Client Subnet) بشكل مختلف. التبديل يمكن أن يُخفّض زمن استجابة الرفع 50 ميلي ثانية ويرفع الإنتاجية 20% دون تغيير أي شيء آخر.

Bufferbloat في الراوتر

Bufferbloat غير مرئي لاختبارات السرعة العادية لكنه يُدمّر الاتصالات المختلطة الاستخدام. شغّل اختبار Waveform bufferbloat على waveform.com/tools/bufferbloat. درجة A+ تعني أن راوترك يتعامل مع قوائم الانتظار بنظافة. درجة F تعني أن راوترك يُدخل 200 إلى 2000 ميلي ثانية زمن استجابة تحت الحمل، مما لا يُضر فقط بحركة التفاعل بل يُسبّب أيضاً للتحكم في ازدحام TCP التراجع مراراً، مما يُخفض إنتاجية الرفع بشدة.

الإصلاح: فعّل SQM (Smart Queue Management) على OpenWrt أو pfSense، أو فعّل QoS على Asus/Netgear/Ubiquiti، أو اشترِ راوتراً يفعل ذلك افتراضياً (eero الحديث، وGoogle Nest Wifi Pro).

أوقف VPN إلا للضرورة

VPN يُضيف 20 إلى 80 ميلي ثانية زمن استجابة وعادةً يحدد الإنتاجية عند الرفع الصاعد لخادم VPN. خط 1 جيجابت عبر نقطة نهاية PIA أو NordVPN مزدحمة يمكن أن ينخفض إلى 50 ميجابت/ث. المزودون الجيدون (Mullvad وProtonVPN Plus) يصمدون أفضل؛ شبكات VPN المجانية تكاد دائماً تخنق عمليات الرفع.

إذا كانت خدمة النقل تستخدم أصلاً TLS 1.3 والتشفير الشامل، فالـ VPN زائد للسرية أثناء النقل. أوقفه أثناء عمليات الرفع، وأعِد تشغيله بعدها.

اختيار المتصفح والبروتوكول

Chrome وEdge وBrave وFirefox جميعها تدعم HTTP/3 (QUIC) بشكل أصلي. Safari يدعمه أيضاً لكن يُفضّل HTTP/2 لبعض المضيفين. HTTP/3 عبر UDP يتحمّل فقدان الحزم أفضل بكثير من HTTP/2 عبر TCP على الهاتف الخلوي أو Wi-Fi الفنادق أو الروابط الأخيرة ذات الفقد.

تحقق من DevTools > Network > عمود Protocol. إذا قرأ h2، أنت على HTTP/2. إذا قرأ h3، أنت على HTTP/3. الخدمات التي تُقدّم الرفعات عبر HTTP/3 ترى مكاسب إنتاجية 15 إلى 30% على الروابط ذات الفقد.

جرّب شبكة مختلفة لعزل المشكلة

أسرع تشخيص: ربط من هاتفك لدقيقة ورفع جزء اختباري. إذا كان الربط من الهاتف أسرع من Wi-Fi المنزلي، المشكلة في شبكتك المحلية (الراوتر أو ISP أو الجهاز). إذا كان ربط الهاتف بالسرعة ذاتها، العنق الزجاجي أبعد في المنبع (ازدحام العبور، أو حد جانب الخدمة).

هذا الاختبار الواحد يُزيل نصف الأسباب المحتملة في أقل من دقيقتين.

حين تكون الخدمة هي العنق الزجاجي

بعض خدمات النقل تحدد ببساطة إنتاجية كل نقل. الخطط المجانية على بعض الأدوات تُقيّد أعلى من 10 ميجابايت/ث بصرف النظر عن اتصالك. الخطط المدفوعة كثيراً ما تُزيل التقييد.

إذا استبعدت كل شيء آخر ولا يزال خطك بـ 500 ميجابت/ث يُوصّل 30 ميجابت/ث إلى خدمة بعينها، الخدمة هي الحد. بدّل. HexaTransfer لا تُقيّد النقل ولا تُشغّل الرفع المجزأ المتوازي الذي يُشبع ما يستطيع أنبوبك دفعه فعلاً حتى سقف 10 جيجابايت لكل نقل.

جرّبها على hexatransfer.com — مجاني، بدون حساب، حتى 10 جيجابايت.