📦 چطور یک فایل چندگیگابایتی را Upload می‌کنیم و اگر اینترنت قطع شد، از همان‌جا ادامه می‌دهیم؟

فرض کن داری یک فایل 8GB آپلود می‌کنی.
۵۰٪ آپلود شده...

Upload: 4.0 GB / 8.0 GB

بعد اینترنت قطع می‌شود. 😐
اگر Upload به‌صورت یک درخواست ساده انجام شده باشد، ممکن است مجبور شوی دوباره از ابتدا شروع کنی.
یعنی:

8 GB
↓
Connection Lost
↓
💀
↓
Upload again

اما سیستم‌های Resumable Upload دقیقاً برای حل همین مشکل طراحی شده‌اند.
ایده‌ی اصلی خیلی ساده است:

فایل بزرگ را طوری منتقل کن که بتوانیم بدانیم تا کجای آن با موفقیت دریافت شده و بعداً از همان نقطه ادامه دهیم.

📌 به‌جای یک Upload بزرگ، انتقال را قابل ادامه می‌کنیم
در یک Upload معمولی ممکن است کل فایل در یک درخواست ارسال شود:

Client
   |
   |------ 8GB ------> Server

اگر ارتباط وسط انتقال قطع شود، درخواست شکست می‌خورد و ادامه‌دادن آن دشوار است.
یک مثال واقعی از پروتکل tus
فرض کنیم Upload تا byte شماره‌ی 70 پیش رفته است. Client وضعیت Upload را می‌پرسد:

HEAD /files/abc123

Server پاسخ می‌دهد:

Upload-Offset: 70

یعنی:

تا byte 70

قبلاً دریافت شده.
حالا Client ادامه‌ی فایل را می‌فرستد:

PATCH /files/abc123

Upload-Offset: 70
Content-Type: application/offset+octet-stream

[remaining bytes]

ءServer بعد از دریافت آن بخش پاسخ می‌دهد:

Upload-Offset: 100

یعنی Upload حالا تا byte شماره‌ی 100 پیش رفته است.
این رفتار در specification رسمی tus تعریف شده و صرفاً یک الگوی پیشنهادی نیست.
در Resumable Upload، انتقال در چند درخواست انجام می‌شود:

Client
   |
   |--- Part 1 ---> Server
   |
   |--- Part 2 ---> Server
   |
   |--- Part 3 ---> Server
   |
   |--- Part 4 ---> Server
   |
   ...

در مستندات رسمی Google Cloud نیز Resumable Upload دقیقاً به‌عنوان روشی برای ادامه‌دادن انتقال بعد از اختلال ارتباط معرفی شده است؛ هر درخواست می‌تواند بخشی از Object را منتقل کند.

📌ءPause هم در اصل یعنی چه؟
یک نکته‌ی مهم:
ءPause و Resume الزاماً دو قابلیت کاملاً جدا نیستند.
وقتی Upload قابل Resume باشد، Client می‌تواند ارسال داده را متوقف کند و بعداً با همان Upload Session ادامه دهد؛ به شرط اینکه Session هنوز معتبر باشد.
مثلاً:

10:00
Upload → 2GB

10:05
Pause ⏸️

10:30
Resume ▶️

Continue → 2GB

در Google Cloud Storage، یک Resumable Upload با یک session URI انجام می‌شود و همان session برای ادامه‌ی انتقال استفاده می‌شود. مستندات Google می‌گوید این session می‌تواند تا یک هفته فعال بماند.
پس یک نکته‌ی مهم داریم:

ءResume به وجود یک state/session قابل ادامه وابسته است.

آیا همیشه باید فایل را به Chunkهای کوچک تقسیم کنیم؟
نه.
این یکی از جاهایی است که خیلی از توضیحات ساده، بیش از حد کلی‌گویی می‌کنند. Resumable Upload الزاماً به معنی این نیست که:

8GB
↓
8000 × 1MB

حتماً باید چنین کاری انجام دهیم.
ءGoogle Cloud صراحتاً اشاره می‌کند که در بعضی شرایط بهتر است انتقال در یک chunk بزرگ انجام شود و chunkهای کوچک‌تر هزینه و latency بیشتری ایجاد می‌کنند. Chunking زمانی می‌تواند مفید باشد که مثلاً محدودیت اندازه‌ی درخواست وجود داشته باشد یا بخواهیم مقدار داده‌ای که در صورت شکست دوباره باید ارسال شود را محدود کنیم.
پس:

ءChunking یک تکنیک برای پیاده‌سازی و کنترل Upload است؛ Resumability مفهوم بزرگ‌تری است.

ءIntegrity Check هم مهم است
فرض کن فایل 8GB است.
ما فقط نمی‌خواهیم بگوییم:

8GB received ✅

باید مطمئن شویم:

چیزی که دریافت کرده‌ایم همان چیزی است که Client قصد ارسالش را داشته.

برای همین، سیستم‌های Storage می‌توانند از checksum / hash برای بررسی integrity استفاده کنند.
ءGoogle Cloud در مستندات Resumable Upload توصیه می‌کند برای Object نهایی integrity check انجام شود؛ از جمله استفاده از Content-MD5 برای بررسی اینکه Object نهایی با فایل اصلی مطابقت دارد.
این موضوع مخصوصاً برای فایل‌های بزرگ اهمیت بیشتری پیدا می‌کند، چون انتقال آن‌ها زمان بیشتری طول می‌کشد.