पैरेलल अपलोड तकनीक: ट्रांसफर बैंडविड्थ अधिकतम करें

Parallel uploads एक फ़ाइल को chunks में split करते हैं (आमतौर पर 5 MB से 100 MB) और उन्हें multiple concurrent TCP connections पर push करते हैं — इससे single stream की throughput ceiling को bypass किया जाता है जो high-latency links पर आती है। Amazon S3 multipart upload, Google Cloud Storage resumable uploads, और tus.io सभी यही implement करते हैं। 1 Gbps line पर 80 ms latency के साथ destination server तक, single HTTP PUT आमतौर पर 150 Mbps पर saturate होती है, जबकि 8 parallel streams 900 Mbps से ऊपर push करती हैं। यह फ़ायदा real और predictable है — जब आप समझते हैं कि क्यों।

एक stream क्यों काफी नहीं है

TCP का congestion control एक sliding window use करता है यह decide करने के लिए कि कितना unacknowledged data in-flight रखना है। Fat, high-latency pipe पर default window size (Linux 5.x पर लगभग 16 MB) ACKs return होने से पहले भर जाती है, और sender ACKs का इंतज़ार करते हुए idle बैठता है। यह "bandwidth-delay product" problem है — यही वजह है कि gigabit line पर भी Paris से Singapore के server पर single FTP transfer लगभग 30 Mbps पर cap होती है।

Multiple parallel connections इस issue को bypass करती हैं क्योंकि हर connection को अपना window मिलता है। 8 streams of 30 Mbps = 240 Mbps — और यह CDN edge selection से पहले, जो अक्सर अलग connections को अलग ingress points के ज़रिए route करती है।

Chunk size और parallel workers: कितने सही हैं

Sweet spot latency और packet loss पर depend करता है। Same-continent transfers पर 50 ms RTT से कम: 10 MB chunks with 4 parallel workers ज़्यादातर consumer lines saturate करती है। Transcontinental या lossy mobile links पर (100 ms RTT से ज़्यादा, 0.5% से ज़्यादा packet loss): 5 MB chunks with 8 से 16 workers।

S3 के multipart API को minimum 5 MB per part चाहिए (last के अलावा), maximum 5 GB per part, और 10,000 parts तक per upload। Google Cloud Storage 32 parts per composite allow करता है और resumable session URIs support करता है जो एक हफ्ते तक persist रहती हैं। Azure Blob block blobs 50,000 blocks तक 4000 MiB each accept करते हैं।

Browser-based transfers के लिए, 100 MB से बड़े chunks already loaded tabs पर RAM stress करने लगते हैं — इसलिए ज़्यादातर web UIs 5 MB से 20 MB के बीच रहती हैं।

Modern transfer services असल में कैसे काम करती हैं

WeTransfer का web uploader फ़ाइलें 6 MB chunks में split करता है और 3 से 5 parallel XHR requests चलाता है। Smash ज़्यादा aggressively shard करता है — 4 MB chunks across up to 8 workers। SwissTransfer 50 MB chunks with 4 parallel streams use करता है, जो Swiss fibre lines पर throughput के लिए अच्छा है लेकिन unstable connections पर worse — एक failed chunk का मतलब 50 MB retransmit। Dropbox Transfer अपने chunked upload API से 8 MB chunks use करता है।

फर्क real-world tests में दिखता है: 500 Mbps upload पर 5 GB फ़ाइल WeTransfer पर roughly 95 seconds में finish होती है; SwissTransfer पर similar throughput पर लगभग 105 seconds — occasional chunk retry overhead की वजह से।

Resumable uploads: खामोश superpower

Chunked uploads resume unlock करती हैं। अगर 120 में से chunk 47 पर Wi-Fi drop हो, तो zero से restart नहीं करते — chunk 48 से resume होती है। tus.io protocol (open standard, अब version 2.0) इसे HEAD requests से upload offset query करके और PATCH requests से Upload-Offset और Upload-Length headers use करके formalize करता है।

Google Drive का resumable upload API session URIs use करता है जो 7 दिन persist रहती हैं। Laptop crash करें, reboot करें, tab reopen करें — और exactly वहीं से pick up होगा जहाँ छोड़ा था। यही फर्क है usable 10 GB transfer और coin-flip के बीच।

Client-side encryption गणित बदल देती है

End-to-end encrypted transfer services को भेजने से पहले client पर हर chunk encrypt करना होता है। Modern laptop CPU पर AES-256-GCM 500 MB/s पर bottleneck नहीं है, लेकिन order matter करता है: encrypt chunk, upload chunk, encrypt next chunk। Worker pool के साथ pipelining यहाँ matter करती है। Naive implementations encryption और upload serialize करती हैं — effective throughput आधी हो जाती है। सही implementations 2 से 4 encryption workers रखती हैं जो bounded queue के ज़रिए 4 से 8 upload workers feed करती हैं।

यही वजह है कि HexaTransfer Web Workers में AES-256-GCM encryption parallel XHR pool के साथ run करती है — ताकि browser में 10 GB ceiling crypto पर stall किए बिना actually reachable हो।

Backpressure और server-side limits

ज़्यादा parallelism हमेशा तेज़ नहीं होती। अगर receiving service per-IP rate-limit करे (CloudFront पर common — 25,000 requests per second per distribution), तो 32 concurrent chunks 503 Slow Down responses trigger कर सकते हैं। HTTP/2 मदद करती है क्योंकि यह single TCP connection पर multiplex करती है, लेकिन कई CDNs edge पर HTTP/2 terminate करके origin को HTTP/1.1 fan out करती हैं।

Test करें over-parallelise करने से पहले। 8 workers लगभग हमेशा safe है; 16 cloud object stores के लिए upper end है; 32 retries produce करने लगती है जो savings से ज़्यादा cost करती है।

Browser limits जो आपको पता होने चाहिए

Chrome और Firefox HTTP/1.1 पर per-origin 6 concurrent connections cap करते हैं — HTTP/2 पर effectively unlimited। अगर transfer service अभी HTTP/1.1 पर है (rare, कुछ legacy FTP-over-HTTP gateways), तो parallelism ceiling 6 है चाहे कितने भी workers spin up करें। DevTools Waterfall column में queued requests stacking up दिखते हैं।

Safari on iOS 17 और later 6 parallel XHR cleanly handle करता है, लेकिन roughly 1.5 GB RAM pressure पर background tabs evict करना शुरू करता है — chunked upload buffers के लिए यह matter करता है।

जब parallel uploads मदद नहीं करते

Asymmetric residential connections (typical: 1 Gbps down, 40 Mbps up) पर, upload bottleneck है — server का ingest नहीं। 40 Mbps pipe के ज़रिए 8 parallel streams of 5 MB push करना 1 stream at 40 Mbps से तेज़ नहीं होता। Parallelism तब मदद करती है जब single-stream ceiling pipe की capacity से कम हो — जब आप already link saturate कर रहे हों, तब नहीं।

Cellular पर भी यही: अगर एक bar LTE है, तो extra workers mostly retransmits produce करते हैं।

सर्विस में क्या देखें

बड़ी files के लिए frequent transfer tool चुन रहे हैं, तो तीन चीज़ें check करें: क्या resumable chunked uploads support करती है, web UI कितने parallel workers run करती है, और edge पर HTTP/2 या HTTP/3 use करती है? तीनों पर खरी उतरने वाली services एक decent connection पर 10 GB फ़ाइल मिनटों में move करेंगी।

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