تقنيات الرفع المتوازي: تعظيم عرض نطاق النقل

الرفع المتوازي يقسّم الملف إلى أجزاء (عادةً من 5 إلى 100 ميجابايت) ويدفعها عبر اتصالات TCP متزامنة متعددة، متجاوزاً سقف الإنتاجية الذي يصله التدفق الواحد على الروابط ذات زمن الاستجابة العالي. Amazon S3 multipart upload وGoogle Cloud Storage resumable uploads وtus.io تُطبّق هذا جميعها. على خط جيجابت مع 80 ميلي ثانية زمن استجابة إلى الخادم المقصود، يتشبع HTTP PUT الواحد عادةً عند 150 ميجابت/ث، بينما تدفع 8 تدفقات متوازية ما يتجاوز 900 ميجابت/ث. المكسب حقيقي ومتوقع متى فهمت سببه.

لماذا لا يكفي تدفق واحد

تستخدم آلية TCP لضبط الازدحام نافذة منزلقة لتحديد كمية البيانات غير المُؤكَّدة التي تبقى "في الهواء". على أنبوب ضخم ذي زمن استجابة عالٍ، يمتلئ حجم النافذة الافتراضي (نحو 16 ميجابايت على Linux 5.x، وأقل على النوى القديمة) قبل عودة ACKs، فيبقى المُرسِل خاملاً منتظراً. هذه هي مشكلة "حاصل ضرب عرض النطاق وزمن التأخير"، وهي سبب توقف نقل FTP واحد إلى خادم في سنغافورة من باريس عند نحو 30 ميجابت/ث حتى على خط جيجابت.

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

التجزئة: الحجم والعدد

النقطة المثالية تعتمد على زمن الاستجابة وفقدان الحزم. لنقلات داخل القارة ذاتها بأقل من 50 ميلي ثانية زمن رحلة، تُشبع أجزاء 10 ميجابايت مع 4 عمال متوازيين معظم خطوط المستهلكين. للروابط عبر القارات أو الجوالة ذات الفقد العالي (أكثر من 100 ميلي ثانية زمن رحلة وأكثر من 0.5% فقدان حزم)، انزل إلى أجزاء 5 ميجابايت مع 8 إلى 16 عاملاً.

واجهة برمجة S3 multipart تشترط حداً أدنى 5 ميجابايت لكل جزء (عدا الأخير)، وحداً أقصى 5 جيجابايت لكل جزء، وما يصل إلى 10,000 جزء لكل رفع. يضع هذا السقف النظري عند نحو 48.8 تيرابايت لكل كائن. Google Cloud Storage يسمح بـ 32 جزءاً مركّباً ويدعم URIs لجلسات قابلة للاستئناف تبقى صالحة لأسبوع واحد. Azure Blob block blobs تقبل ما يصل إلى 50,000 كتلة بـ 4000 ميبابايت لكل منها.

للنقلات القائمة على المتصفح، الأجزاء التي تتجاوز 100 ميجابايت تبدأ في إرهاق RAM في التبويبات المُحمَّلة أصلاً، لذا تبقى معظم واجهات الويب بين 5 و20 ميجابايت.

كيف تعمل خدمات النقل الحديثة فعلاً

WeTransfer تقسّم الملفات إلى أجزاء 6 ميجابايت وتشغّل 3 إلى 5 طلبات XHR متوازية. Smash تُجزّئ بعدوانية أكبر، مع أجزاء 4 ميجابايت عبر ما يصل إلى 8 عمال. SwissTransfer تستخدم أجزاء 50 ميجابايت مع 4 تدفقات متوازية، مما يُفضّل الإنتاجية على خطوط الألياف السويسرية لكن يُؤدي بشكل أسوأ على الاتصالات غير المستقرة لأن جزءاً واحداً فاشلاً يعني إعادة إرسال 50 ميجابايت. Dropbox Transfer تعتمد على واجهة API للرفع المجزأ بأجزاء 8 ميجابايت.

تظهر الفوارق في الاختبارات الفعلية: ملف 5 جيجابايت على رفع 500 ميجابت/ث إلى WeTransfer ينتهي في نحو 95 ثانية؛ SwissTransfer بإنتاجية مماثلة تستغرق نحو 105 ثوانٍ بسبب تكلفة إعادة محاولة الأجزاء أحياناً.

الرفع القابل للاستئناف: القدرة الخفية

الرفع المجزأ يُتيح الاستئناف. إذا انقطع Wi-Fi عند الجزء 47 من 120، لا تبدأ من الصفر بل تستأنف من الجزء 48. بروتوكول tus.io (معيار مفتوح في إصداره 2.0) يُرسّخ هذا بطلبات HEAD للاستعلام عن إزاحة الرفع وطلبات PATCH للإلحاق، باستخدام رأسيات Upload-Offset وUpload-Length.

واجهة API للرفع القابل للاستئناف في Google Drive تستخدم URIs للجلسات تبقى صالحة 7 أيام. يمكنك أن يتعطل حاسوبك، وتُعيد التشغيل، وتُعيد فتح التبويب، وتُكمل من حيث توقفت تماماً. هذا الفارق بين نقل 10 جيجابايت قابل للاستخدام ونقل على المقامرة.

التشفير من جانب العميل يُغيّر المعادلة

خدمات النقل المشفّرة من طرف إلى طرف تُشفّر كل جزء على العميل قبل الإرسال. AES-256-GCM بسرعة 500 ميجابايت/ث على معالج حاسوب محمول حديث ليست العنق الزجاجي، لكن الترتيب مهم: شفّر الجزء، ارفع الجزء، شفّر الجزء التالي. الأنابيب مع مجموعة عمال مهمة هنا. التطبيقات البسيطة تُسلسل التشفير والرفع، مما يخفض الإنتاجية الفعلية للنصف. التطبيقات الصحيحة تُبقي 2 إلى 4 عمال تشفير تُغذّي 4 إلى 8 عمال رفع عبر قائمة انتظار محدودة.

هذا لماذا تُشغّل HexaTransfer تشفير AES-256-GCM في Web Workers بجانب مجموعة XHR متوازية، حتى يكون سقف 10 جيجابايت قابلاً للوصول فعلاً عبر المتصفح دون توقف على التشفير.

الضغط العكسي وحدود جانب الخادم

المزيد من التوازي ليس دائماً أسرع. إذا كانت الخدمة المستقبِلة تُقيّد المعدل لكل IP (شائع مع CloudFront عند 25,000 طلب في الثانية لكل توزيع)، فدفع 32 جزءاً متزامناً قد يُثير استجابات 503 Slow Down. HTTP/2 يُساعد لأنه يُعدّد عبر اتصال TCP واحد، لكن كثيراً من شبكات CDN تُنهي HTTP/2 عند الحافة وتُوزّع HTTP/1.1 على الأصل، فالتوازي الفعلي يعتمد على إعداد الحافة.

اختبر قبل الإفراط في التوازي. 8 عمال آمن دائماً تقريباً؛ 16 هو الحد الأعلى لما تقبله مخازن الكائنات السحابية بنظافة؛ 32 يبدأ في إنتاج إعادات محاولة تُكلّف أكثر مما توفر.

حدود المتصفح التي يجب معرفتها

Chrome وFirefox يحدّان الاتصالات المتزامنة لكل أصل بـ 6 عبر HTTP/1.1، وعدداً غير محدود عملياً عبر HTTP/2. إذا كانت خدمة النقل لا تزال على HTTP/1.1 (نادر، لكن بعض بوابات FTP-over-HTTP القديمة)، سقف توازيك هو 6 بصرف النظر عن كمية العمال. تحقق عبر DevTools: عمود "Waterfall" في لوحة Network يُظهر الطلبات المتراكمة في قائمة الانتظار.

Safari على iOS 17 وما بعده يتعامل مع 6 طلبات XHR متوازية بنظافة لكن يبدأ في طرد التبويبات الخلفية عند ضغط RAM نحو 1.5 جيجابايت، مما يهم لمخازن أجزاء الرفع المجزأ.

متى لا يُفيد الرفع المتوازي

على الاتصالات السكنية غير المتماثلة (النموذجية: 1 جيجابت تنزيل، 40 ميجابت/ث رفع)، رفعك هو العنق الزجاجي، لا استيعاب الخادم. دفع 8 تدفقات متوازية بـ 5 ميجابايت لكل منها عبر أنبوب 40 ميجابت/ث لا يكون أسرع من تدفق واحد بـ 40 ميجابت/ث. التوازي يُساعد حين يكون سقف التدفق الواحد أقل من طاقة الأنبوب، لا حين تُشبع الرابط أصلاً.

القصة ذاتها على الهاتف الخلوي: إذا كان لديك شريط LTE واحد، عمال إضافيون ينتجون في الغالب إعادات إرسال.

ما تبحث عنه في خدمة

إذا كنت تختار أداة نقل للملفات الكبيرة المتكررة، تحقق من ثلاثة أشياء: هل تدعم الرفع المجزأ القابل للاستئناف، وكم عاملاً متوازياً تُشغّل واجهة الويب، وهل تستخدم HTTP/2 أو HTTP/3 إلى الحافة. الخدمات التي تحقق الثلاثة ستنقل ملف 10 جيجابايت في دقائق على اتصال لائق.

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