هندسة الرفع القائم على الأجزاء: دليل التصميم

هندسة الرفع القائمة على الأجزاء تُقسِّم الملف إلى قطع ثابتة أو متغيرة الحجم وترسلها باستقلالية، حتى لا يُجبر أي انقطاع في الشبكة على إعادة البدء من الصفر في ملف بـ10 جيجابايت. المعياران المفتوحان السائدان هما AWS S3 Multipart Upload (أجزاء بحد أدنى 5 ميغابايت، بحد أقصى 10,000 جزء) وبروتوكول tus.io القابل للاستئناف (مسودة RFC، مُطبَّق على نطاق واسع). حين يُصمَّم بالشكل الصحيح، يُحقق الرفع المُجزَّأ إنتاجية أعلى 5-10 مرات على الروابط ذات التأخير العالي، ويتحمل الانقطاعات القصيرة، ويُتيح فك تشفير متوازيًا في جهة الاستقبال. إليك كيفية تصميم نظام يصمد فعلًا في الإنتاج.

لماذا تفشل الرفعات الكاملة عند الحجم الكبير

طلب HTTP PUT واحد لملف بـ5 جيجابايت يصطدم بنصف دزينة من طرق الفشل. نوافذ تدفق TCP تستغرق وقتًا طويلًا للارتفاع، مما يحدُّ الإنتاجية دون سعة الرابط على المسارات ذات التأخير العالي. المتصفحات تحدُّ الاتصالات المتزامنة بـ6 لكل أصل، تاركةً معظم النطاق الترددي خاملًا. مهل الطلب من جانب الخادم (nginx افتراضيًا 60 ثانية، CloudFront 30 ثانية لغير الدفق) تُنهي الرفعات الطويلة. شبكات الجوال التي تتنقل بين أبراج الخلايا تقطع الاتصال كل بضع دقائق. وانعكاس بت واحد يُجبر على إعادة النقل كله. الرفع المُجزَّأ يحل جميع هذه المشاكل بجعل وحدة العمل صغيرة وقابلة للإعادة باستقلالية وصديقة للتوازي.

اختيار حجم الجزء

حجم الجزء مقايضة. الأجزاء الأصغر تتعافى أسرع من الإخفاقات وتُوفِّر دقة أفضل في تقدم الإنجاز، لكنها تُضيف عبء HTTP أكبر. الأجزاء الأكبر تُستهلَك تكاليف المصافحة وTLS لكنها تُهدر النطاق الترددي حين يفشل جزء ويجب إعادة إرساله. النطاقات الاعتيادية: 1-5 ميغابايت لرفعات الجوال على شبكات متقطعة، و5-16 ميغابايت لرفعات ويب سطح المكتب، و16-64 ميغابايت لنقل من خادم لخادم على روابط موثوقة، و100 ميغابايت أو أكثر لـS3 Multipart حيث يُجبر سقف 10,000 جزء على أجزاء أكبر لملفات بتيرابايت. بعض الأنظمة تتكيَّف ديناميكيًا، تبدأ صغيرًا وتتوسع مع ثبات الاتصال.

التجزئة ثابتة الحجم مقابل المُعرَّفة بالمحتوى

التجزئة ثابتة الحجم (كل 8 ميغابايت مثلًا) بسيطة التطبيق وصديقة للتوازي وتدعم إزاحات استئناف دقيقة. التجزئة المُعرَّفة بالمحتوى، المستخدمة في rsync وrestic، تختار الحدود بناءً على هاش متدحرج مثل بصمات Rabin حتى لا تُزيح عمليات الإدراج في منتصف الملف حدودَ الأجزاء اللاحقة. CDC رائعة للإزالة التكرارية في أدوات النسخ الاحتياطي لكنها تُضيف تعقيدًا وتكلفة معالجة غير مكافأة لنقل الملفات البحت. لهندسات الرفع، التجزئة ثابتة الحجم تكسب بالبساطة وتتوافق بوضوح مع أجزاء S3 multipart أو إزاحات tus.io.

بروتوكولات الرفع القابلة للاستئناف

بروتوكول tus.io، المُطبَّق في tusd (Go) وtus-js-client وUppy وأطر خوادم عديدة، يستخدم HTTP PATCH مع ترويسة Upload-Offset لإلحاق الأجزاء. طلب HEAD يُعيد الإزاحة الحالية على الخادم، فيعرف العميل من أين يستأنف بعد انقطاع الشبكة. S3 Multipart Upload يستخدم نموذجًا مختلفًا: ابدأ الرفع للحصول على UploadId، ارفع كل جزء (مُفهرَس بدءًا من 1)، ثم أرسل طلب CompleteMultipartUpload مع قائمة ETags. يستطيع العملاء الاستعلام عبر ListParts لرؤية ما رُفِع. كلا البروتوكولين يحفظان الحالة عبر إعادة تشغيل العميل ويتحملان انقطاعات الاتصال بأناقة.

تزامن الرفع المتوازي

رفع الأجزاء بالتوازي يُعزِّز الإنتاجية بشكل ملحوظ على الروابط ذات التأخير العالي. HTTP/1.1 يحدُّ بـ6 اتصالات متزامنة لكل أصل في المتصفحات؛ HTTP/2 يُعدِّد تدفقات عديدة على اتصال واحد لكن مع تحكم في نوافذ التدفق. جدولة رفع اعتيادية تضع الأجزاء في قائمة انتظار وتُرسِل 4-8 بشكل متوازٍ، مع ضغط خلفي حين يشير الخادم بـ429 أو 503. كثير من التوازي يُشغِّل تشكيل ISP وحدود اتصال الوسيط؛ قليل من التوازي يترك النطاق الترددي غير مستخدم. تجريبيًا، 4 تدفقات متوازية على النطاق العريض المنزلي و8-16 على الألياف بالجيغابت تُصيب النقطة المثلى لمعظم الأحمال.

حالة جانب العميل وبيانات الاستئناف الوصفية

الرفعات القابلة للاستئناف تتطلب من العميل تذكُّر ما يكفي من الحالة للاستئناف بعد تعطل المتصفح أو إغلاق الحاسوب. IndexedDB، جزء من معيار Web Storage، يُخزِّن مانيفستات الرفع مع هاش الملف وعدد الأجزاء والأجزاء التي نجحت. أسِّس المانيفيست على هاش SHA-256 للملف حتى تُكمِّل إضافة الملف ذاته من حيث توقفت. انظِّف المانيفستات القديمة الأكثر من 7 أيام لتجنب الانتفاخ. على الجوال، قد تُخلي WKWebView (iOS) وChrome Custom Tabs (Android) IndexedDB تحت ضغط الذاكرة، لذا ثبِّت الحالة الحرجة في التخزين الأصيل إن أمكن.

معالجة الأجزاء من جانب الخادم

الخادم يحتاج إعادة تجميع الأجزاء في ملف كامل أو، مع S3 Multipart، تفويض إعادة التجميع لـS3. بنية أدنى: اقبل كل PATCH جزء، اكتب إلى blob مؤقت مُفهرَس بمعرِّف الرفع وفهرس الجزء، سجِّل الإزاحة في مخزن بيانات وصفية كـRedis أو PostgreSQL، وعند CompletePart جمِّع أو أشِر إلى الاكتمال. استخدم تخزين الكائنات (S3 أو Cloudflare R2 أو Backblaze B2) لـblobs الأجزاء بدلًا من القرص المحلي، إذ لا تستطيع الخلفيات الموزونة موازنةً حمل مشاركة الحالة المحلية بسهولة. نظِّف الرفعات المهجورة بعد 24-72 ساعة لاستعادة التخزين.

التحقق من التكامل لكل جزء ومن طرف إلى طرف

تحقق من كل جزء بهاش عند الرفع. ETag لـS3 Multipart هو هاش MD5 لكل جزء (أو هاش مركَّب للكائن الكامل). لتكامل أقوى، احسب SHA-256 لكل جزء من جانب العميل وأرسله في ترويسة؛ يُخزِّنه الخادم بجانب الجزء ويستطيع التحقق منه عند القراءة. بعد رفع جميع الأجزاء، احسب جذر شجرة Merkle أو هاشًا دفقيًا للملف المُعاد تجميعه وأعِده للعميل. العميل يقارن مع هاشه الخاص للملف الأصلي. أي عدم تطابق يُشغِّل إعادة رفع الأجزاء المُعيبة.

تشابك التشفير مع التجزئة

التشفير من طرف إلى طرف يُعقِّد التجزئة قليلًا. كل جزء يحتاج نونسًا خاصًا به لتجنب إعادة استخدام IV في AES-GCM، ويجب أن تكون حدود الأجزاء جزءًا من نظام المصادقة. نهج اعتيادي: اشتق مفتاحًا لكل جزء عبر HKDF-SHA256 من مفتاح تشفير جذري للملف، باستخدام فهرس الجزء كمعلومات سياق، ثم شفِّر كل جزء بـAES-256-GCM ونونس صفري أو متزايد. أدرج فهرس الجزء والعدد الكلي للأجزاء في AAD حتى لا يستطيع المهاجمون تشابك الأجزاء أو إعادة ترتيبها. عند فك التشفير، تحقق من وجود جميع الأجزاء وترتيبها قبل إطلاق النص الصريح.

الرصد والمتابعة لأنظمة الأجزاء

رصِّد كل جزء. مقاييس للتتبع: الأجزاء المرفوعة في الثانية، وزمن استجابة رفع الجزء p50/p95/p99، ومعدل إعادة المحاولة لكل جزء، ومعدل الرفعات المهجورة. لوحات Grafana أو Datadog تكشف التراجعات بسرعة. الآثار الموزَّعة عبر OpenTelemetry تربط جلسة العميل بمعالجة أجزائها من جانب الخادم. سجِّل أحداثًا منظَّمة بـJSON بحيث تكون قابلة للبحث في Loki أو Elasticsearch أو Splunk. حين يُبلِّغ عميل عن رفع بطيء، يُظهر الأثر أي الأجزاء توقفت ولماذا.

الجمع معًا

نظام الرفع المُجزَّأ الجاهز للإنتاج يجمع أجزاءً بـ5-16 ميغابايت وبروتوكول tus.io أو S3 Multipart و4-8 تدفقات متوازية وحالة استئناف مدعومة بـIndexedDB وفحوصات تكامل SHA-256 لكل جزء وتشفير E2EE اختياريًا لكل جزء بمفتاح مشتق. تستخدم HexaTransfer تشفيرًا مُجزَّأً من جانب العميل بـAES-256-GCM ورفعات قابلة للاستئناف للتعامل مع ملفات 10 جيجابايت بموثوقية على اتصالات متقطعة.

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