نصائح تحسين عرض النطاق لنقل ملفات أسرع

للاستفادة القصوى من عرض نطاق رفعك، افعل أربعة أشياء: وصّل بكابل Ethernet بدلاً من Wi-Fi، وفعّل QoS أو SQM على راوترك للقضاء على Bufferbloat، وحوّل اتصالك إلى IPv6 حيث يدعمه مزود الإنترنت، وأوقف المزامنات الخلفية مثل Dropbox وiCloud وGoogle Drive أثناء النقل. على رفع 500 ميجابت/ث يُوصّل فعلاً 180 ميجابت/ث خلال النقلات الحقيقية، هذه التغييرات الأربعة مجتمعةً تستعيد في الغالب 200 إلى 280 ميجابت/ث من الإنتاجية القابلة للاستخدام وتُقلّص نقل 10 جيجابايت من 45 دقيقة إلى أقل من 15.

الكابل السلكي للملفات الكبيرة وانسَ Wi-Fi

Wi-Fi 6 (802.11ax) على عميل جيد 2x2 على مسافة 1.5 متر من نقطة الوصول يصل في الواقع إلى نحو 600 ميجابت/ث إنتاجية. Wi-Fi 5 (802.11ac) يجلس أقرب إلى 300 ميجابت/ث. في الغرفة المجاورة مع جدار بينهما، تنخفض تلك الأرقام 40 إلى 60%. Ethernet بسرعة جيجابت يُوصّل 940 ميجابت/ث باستمرار مع أقل من ميلي ثانية تأخر.

محول USB-C إلى Ethernet بسرعة جيجابت بـ 15 دولاراً سيتفوق على Wi-Fi المدمج في معظم الحواسيب المحمولة لعمليات الرفع التي تتجاوز 2 جيجابايت. إذا تعذّر عليك تمديد كابل، على الأقل تحوّل إلى نطاق 5 جيجاهرتز وابقَ في مرأى مباشر من الراوتر. نطاق 2.4 جيجاهرتز يصل إلى 60-80 ميجابت/ث في الظروف الحقيقية ولا يستحق أن يحمل نقل ملفات.

QoS وSQM: علاج Bufferbloat

Bufferbloat هو السبب وراء تأخر مكالمة Zoom لحظة يبدأ أحد في المنزل بعملية رفع. تضع مخازن الراوتر التقليدية الحزم في قائمة انتظار لثوانٍ على الروابط المشبعة، مما يُدمّر زمن الاستجابة. خوارزميات Smart Queue Management (SQM) مثل CAKE وfq_codel تُبقي قوائم الانتظار قصيرة حتى تحت الحمل، فرفع 500 ميجابت/ث لا يُضيف 300 ميلي ثانية زمن استجابة لكل شيء آخر.

OpenWrt وpfSense ومعظم الراوترات الحديثة (Asus بإضافة Merlin وUbiquiti UniFi وeero Pro 6E) تدعم SQM. فعّله، اضبط رفعك على نحو 95% من سرعتك المخصصة، وشاهد اختبار DSLReports أو Waveform Bufferbloat ينتقل من درجة F إلى A+.

هذا لا يُضيف عرض نطاق، لكنه يُزيل خسارة الإنتاجية بين 40 و60% التي تحدث حين يتراجع TCP بسبب Bufferbloat مراراً.

IPv6 عادةً أسرع

على مزودي الإنترنت الذين يدعمون الـ Dual-stack، كثيراً ما يسلك IPv6 مساراً أكثر مباشرةً نحو الوجهات السحابية الكبرى. AWS وGoogle Cloud وCloudflare وAzure جميعها تعمل بـ IPv6 أصلياً، والحزمة عبر IPv6 تتجاوز عادةً قفزة NAT أو قفزتين مقارنةً بمسارات IPv4 CGNAT الشائعة على الهاتف المحمول وبعض الشبكات السكنية.

تحقق عبر ipv6-test.com أو test-ipv6.com. إذا حصلت على 10/10، أنت تستخدم IPv6 أصلاً حيث هو متاح. إذا لم يكن كذلك، فعّله في راوترك (معظم مزودي الإنترنت يدفعون الإعدادات عبر DHCPv6 أو PPPoE تلقائياً). الفارق في نقل عبر القارات قد يصل إلى 20-40%.

أوقف كل ما يُزامن في الخلفية

Dropbox وGoogle Drive وOneDrive وiCloud Photos وTime Machine عبر الشبكة وأدوات النسخ الاحتياطي مثل Backblaze جميعها تستهلك عرض نطاق الرفع بصمت. Activity Monitor على macOS (تبويب Network، مرتباً حسب "Sent Bytes") وResource Monitor على Windows يكشفان الجناة.

أوقفها قبل نقل كبير. iCloud Photos تحديداً يمكن أن يدفع جيجابايتات بهدوء بعد استيراد جلسة تصوير. حد Backblaze الافتراضي "تلقائي"، مما يعني "خذ كل ما هو متاح" على اتصال خامل.

مكالمة Zoom بدقة 1080p تستهلك نحو 3 ميجابت/ث صاعداً. مكالمة Google Meet بدقة HD تجلس عند نحو 2.5 ميجابت/ث. إذا كان أحد في المنزل في مكالمة فيديو، جدوِل النقل حولها أو اقبل خسارة 2 إلى 3 ميجابت/ث.

DNS وزمن البايت الأول

DNS سيء التهيئة يُضيف 50 إلى 200 ميلي ثانية زمن استجابة قبل أن يبدأ اتصال TCP حتى. إذا كنت لا تزال تستخدم محلل DNS الافتراضي لـ ISP، جرّب Cloudflare's 1.1.1.1 أو Google's 8.8.8.8. استخدم dig +stats transfer-service.com لمقارنة أوقات الاستجابة. للرفع المجزأ الذي يفتح اتصالات كثيرة، المحلل السريع يتراكم في إنتاجية كلية أسرع ملحوظاً.

على macOS، غيّر DNS في System Settings > Network > Details > DNS. على Windows 11: Settings > Network & Internet > (محوّلك) > Edit DNS server assignment.

ضبط MTU على الشبكات غير الاعتيادية

إذا كنت على VPN أو اتصال PPPoE DSL أو رابط خلوي، ربما يكون MTU لديك أقل من الافتراضي 1500 بايت. MTU ذو حجم خاطئ يُسبب تجزئة TCP وإعادة إرسال وانهياراً في الإنتاجية. اختبر بـ ping -s 1472 -D google.com على macOS/Linux أو ping -f -l 1472 google.com على Windows. إذا لم تعد الحزم، خفّض MTU بشرائح 10 بايتات حتى تعود، ثم اضبط تلك القيمة (زائد 28 لتكلفة ICMP) كـ MTU للواجهة.

قيم شائعة تعمل: 1500 على معظم الاتصالات العريضة، 1492 على PPPoE DSL، 1428 على بعض Wireguard VPN، 1400 على معظم شبكات الجيل الخامس.

Congestion Control: BBR مقابل Cubic

على أنظمة Linux التي ترفع إلى السحابة، التحويل من Cubic إلى BBR (Bottleneck Bandwidth and RTT) يمكن أن يُضاعف الإنتاجية على الروابط ذات زمن الاستجابة العالي والفقد الطفيف. فعّله بـ sysctl -w net.ipv4.tcp_congestion_control=bbr. macOS وWindows يستخدمان متغيرات من Cubic بشكل افتراضي ولا يُعرضان هذا الضبط بسهولة، لكن نقاط نهاية النقل السحابية تُشغّل BBR بشكل متزايد على جانبها، مما يُفيد حتى إذا لم يكن جانبك يفعل ذلك.

اختيار المتصفح يهم

المتصفحات القائمة على Chromium (Chrome وEdge وBrave وArc) تدعم HTTP/3 وQUIC افتراضياً، مما يتفوق على HTTP/2 عبر HTTPS على الروابط ذات الفقد بنسبة 15 إلى 25%. Firefox يُشحن مع QUIC أيضاً. Safari 17+ يدعم HTTP/3 لكن يُفضّل HTTP/2 لبعض الخدمات. تحقق عبر لوحة DevTools > Network، عمود "Protocol".

إذا كانت نقطة نهاية رفع الخدمة تُقدّم HTTP/3، السماح للمتصفح باختياره يعني مصافحات أقل لكل جزء، مما يهم للرفعات المتوازية التي تفتح 4 إلى 8 تدفقات متزامنة.

اختر خدمة تحترم الأنبوب

بعض خدمات النقل تُقيّد عمليات الرفع بصرف النظر عن مقدار عرض النطاق المتاح لديك. خط 50 جيجابت يمكن أن يزحف عبر أداة تحدد إنتاجية النقل بـ 30 ميجابت/ث. HexaTransfer تُدفق الأجزاء بالتوازي عبر HTTP/2 مع تشفير AES-256-GCM في Web Workers، فرفعك يُشبع ما يستطيع اتصالك تقديمه فعلاً حتى سقف 10 جيجابايت لكل نقل.

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