चंक-आधारित अपलोड आर्किटेक्चर: डिज़ाइन गाइड

Chunk-based upload architecture एक फ़ाइल को fixed- या variable-size टुकड़ों में विभाजित करती है और उन्हें स्वतंत्र रूप से भेजती है, ताकि network hiccup 10 GB को शून्य से restart करने के लिए मजबूर न करे। दो dominant open standards हैं AWS S3 Multipart Upload (5 MB minimum parts, 10,000 parts max) और tus.io resumable protocol (RFC draft, व्यापक रूप से implemented)। सही तरीके से किया जाए तो, chunked uploads high-latency links पर 5 से 10x अधिक throughput deliver करते हैं, brief disconnects tolerate करते हैं, और receive side पर parallel decryption enable करते हैं। यहाँ बताया गया है कि production में actually टिकने वाला system कैसे design करें।

Monolithic Uploads Scale पर क्यों Fail होते हैं

5 GB फ़ाइल का एक HTTP PUT आधे दर्जन तरीकों से fail हो सकता है। TCP congestion windows को ramp up करने में लंबा समय लगता है, high-latency paths पर link capacity से काफी नीचे throughput cap करता है। Browsers प्रति origin 6 concurrent connections तक सीमित हैं, जिससे अधिकांश bandwidth idle रहती है। Server-side request timeouts (nginx default 60 seconds, CloudFront 30 seconds for non-streaming) long uploads को kill करते हैं। Mobile networks cell towers के बीच switch करते समय हर कुछ मिनट में connection drop करते हैं। और एक single bit flip पूरे transfer को restart करने के लिए मजबूर करता है। Chunked uploads इन सभी को work की unit को small, independently retryable, और parallel-friendly बनाकर solve करते हैं।

Chunk Size चुनना

Chunk size एक tradeoff है। छोटे chunks failures से तेज़ recover होते हैं और finer progress granularity प्रदान करते हैं लेकिन अधिक HTTP overhead जोड़ते हैं। बड़े chunks handshake और TLS costs amortize करते हैं लेकिन जब chunk fail होता है और retransmit होना पड़ता है तो bandwidth waste होती है। विशिष्ट ranges: lossy networks पर mobile uploads के लिए 1 MB से 5 MB, desktop web uploads के लिए 5 MB से 16 MB, reliable links पर server-to-server transfers के लिए 16 MB से 64 MB, और S3 Multipart के लिए 100 MB या अधिक जहाँ 10,000-part ceiling 1 TB files पर बड़े chunks force करती है। कुछ systems dynamically adapt करते हैं, छोटे से शुरू होकर और connection prove होने पर scale up करते हैं।

Fixed-Size बनाम Content-Defined Chunking

Fixed-size chunking (हर 8 MB, मान लीजिए) implement करना trivial है, parallel-friendly है, और exact resume offsets support करता है। Content-defined chunking, rsync और restic में उपयोग किया जाता है, Rabin fingerprinting जैसे rolling hash के आधार पर boundaries चुनता है ताकि फ़ाइल के बीच में insertions सभी subsequent chunk boundaries को shift न करें। CDC backup tools में deduplication के लिए शानदार है लेकिन pure file transfer के लिए complexity और CPU cost जोड़ता है। Upload architectures के लिए, fixed-size simplicity पर जीतता है और S3 multipart parts या tus.io offsets पर cleanly map करता है।

Resumable Upload Protocols

tus.io protocol, tusd (Go), tus-js-client, Uppy, और कई server frameworks में implemented, chunks append करने के लिए Upload-Offset header के साथ HTTP PATCH उपयोग करता है। HEAD request server पर current offset return करता है, इसलिए client को पता है कि network interruption के बाद कहाँ से resume करना है। S3 Multipart Upload एक अलग model उपयोग करता है: UploadId पाने के लिए upload initiate करें, प्रत्येक part upload करें (1-indexed), फिर ETags की list के साथ CompleteMultipartUpload request भेजें। Clients देख सकते हैं क्या upload हुआ ListParts से। दोनों protocols client restarts के पार state preserve करते हैं और connection drops को gracefully survive करते हैं।

Parallel Upload Concurrency

Chunks को parallel में upload करना high-latency links पर throughput dramatically boost करता है। HTTP/1.1 browsers में प्रति origin 6 concurrent connections पर cap करता है; HTTP/2 single connection पर many streams multiplex करता है लेकिन अभी भी flow control windows के अधीन। एक विशिष्ट upload scheduler chunks queue करता है और 4 से 8 को parallel में dispatch करता है, server के 429 या 503 signal करने पर backpressure के साथ। बहुत अधिक parallelism ISP shaping और middlebox connection limits trigger करता है; बहुत कम bandwidth unused छोड़ता है। Empirically, home broadband पर 4 parallel streams और gigabit fiber पर 8 से 16 अधिकांश workloads के लिए sweet spot हैं।

Client-Side State और Resume Metadata

Resumable uploads के लिए client को browser crash या laptop shutdown के बाद resume करने के लिए पर्याप्त state याद रखने की आवश्यकता है। IndexedDB, Web Storage standard का हिस्सा, upload manifests store करता है फ़ाइल के hash, chunk count, और कौन से chunks succeeded के साथ। Manifest को फ़ाइल के SHA-256 hash से key करें ताकि same फ़ाइल फिर से जोड़ने पर वहीं से pick up हो जाए। Storage bloat से बचने के लिए 7 दिन से पुराने stale manifests clean up करें। Mobile पर, WKWebView (iOS) और Chrome Custom Tabs (Android) memory pressure में IndexedDB evict कर सकते हैं, इसलिए यदि संभव हो तो critical state को native storage में persist करें।

Server-Side Chunk Handling

Server को chunks को complete फ़ाइल में reassemble करने की आवश्यकता है या, S3 Multipart के साथ, reassembly S3 को delegate करें। एक minimal architecture: प्रत्येक chunk PATCH accept करें, upload ID और chunk index द्वारा keyed temporary blob में write करें, Redis या PostgreSQL जैसे metadata store में offset record करें, और CompletePart पर assemble या complete mark करें। Chunk blobs के लिए local disk के बजाय object storage (S3, Cloudflare R2, Backblaze B2) उपयोग करें, क्योंकि load-balanced backends आसानी से local state share नहीं कर सकते। Storage reclaim करने के लिए 24 से 72 घंटों के बाद abandoned uploads garbage-collect करें।

प्रति Chunk और End-to-End Integrity Verification

Upload पर hash से प्रत्येक chunk verify करें। S3 Multipart का ETag प्रति part MD5 hash है (या complete object के लिए composite hash)। मजबूत integrity के लिए, client-side प्रति chunk SHA-256 compute करें और इसे header में भेजें; server इसे chunk के साथ store करता है और re-read पर verify कर सकता है। सभी chunks upload होने के बाद, reassembled फ़ाइल का Merkle tree root या streaming hash compute करें और इसे client को return करें। Client इसे original फ़ाइल के अपने hash से compare करता है। कोई भी mismatch offending chunks का re-upload trigger करता है।

Chunking के साथ Encryption का Interplay

End-to-end encryption chunking को थोड़ा जटिल बनाता है। प्रत्येक chunk को AES-GCM में IV reuse से बचने के लिए अपना nonce चाहिए, और chunk boundaries authentication scheme का हिस्सा होनी चाहिए। एक विशिष्ट approach: HKDF-SHA256 के माध्यम से root file encryption key से per-chunk key derive करें, context info के रूप में chunk index का उपयोग करते हुए, फिर zero या incrementing nonce के साथ AES-256-GCM से प्रत्येक chunk encrypt करें। AAD में chunk index और total chunk count शामिल करें ताकि attackers chunks splice या reorder न कर सकें। Decryption पर, plaintext release करने से पहले verify करें कि सभी chunks present हैं और क्रम में हैं।

Chunk-Based Systems के लिए Observability

हर chunk instrument करें। Track करने के लिए Metrics: प्रति सेकंड uploaded chunks, p50/p95/p99 chunk upload latency, प्रति chunk retry rate, और abandoned upload rate। Grafana या Datadog में dashboards regressions जल्दी reveal करते हैं। OpenTelemetry के माध्यम से distributed traces एक client session को उसके server-side chunk handling से जोड़ते हैं। Structured events JSON में log करें ताकि वे Loki, Elasticsearch, या Splunk में searchable हों। जब कोई customer slow upload report करे, trace दिखाता है कि exactly कौन से chunks stall हुए और क्यों।

सब कुछ एक साथ

Production-ready chunked upload system 5 MB से 16 MB chunks, protocol के लिए tus.io या S3 Multipart, 4 से 8 parallel streams, IndexedDB-backed resume state, per-chunk SHA-256 integrity checks, और derived key के साथ optional per-chunk E2EE को combine करता है। HexaTransfer AES-256-GCM के साथ client-side chunked encryption और resumable uploads उपयोग करता है flaky connections पर 10 GB फ़ाइलें reliably handle करने के लिए।

hexatransfer.com पर आज़माएं — मुफ़्त, कोई अकाउंट नहीं, अधिकतम 10 GB।