बाधित ट्रांसफर फिर शुरू करें: कभी शून्य से शुरू न करें
रिज़्यूमेबल फ़ाइल ट्रांसफर कैसे काम करता है जानें। रिज़्यूम सपोर्ट वाली सेवाओं से बड़े अपलोड की प्रोग्रेस कभी न खोएं।
Resumable transfers एक फ़ाइल को chunks में split करके track करते हैं कि कौन से chunks सफलतापूर्वक receive हुए; जब connection drop होती है, client अगले unsent chunk से pick up करता है बजाए byte zero से restart करने के। Web standard इसके लिए tus.io है (एक open resumable upload protocol), जिसे SwissTransfer, HexaTransfer, Vimeo, Cloudinary, और कई modern transfer services implement करती हैं। Downloads के लिए, HTTP Range requests (RFC 7233) browsers और curl या aria2 जैसे tools को interrupted downloads resume करने देते हैं। Resumability के बिना, एक 9.8 GB upload जो 9.5 GB पर fail होती है उसे पूरा फिर से करना पड़ता है — resumability के साथ, शायद 50 MB ही बर्बाद होते हैं।
Non-resumable uploads की समस्या
एक naive file upload पूरी फ़ाइल को एक HTTP POST request के रूप में भेजता है। अगर कोई भी चीज़ connection interrupt करे — Wi-Fi drop, VPN timeout, laptop sleep, ISP blip — TCP connection बंद हो जाती है और server ने जो partial data रखा था वह discard कर देता है। Client byte zero से शुरू करता है।
50 Mbps connection पर एक 5 GB upload के लिए, 13 मिनट का काम बर्बाद हो जाता है। 50 GB upload के लिए, दो घंटे से ज़्यादा। Mobile connections पर non-resumable uploads की failure rate brutal है — 4G connection पर 30 मिनट का upload पहली बार में शायद ही succeed करता है।
Resumable protocols कैसे काम करते हैं
Modern resumable uploads लगभग इस तरह काम करते हैं:
- Create: Client server को file की total size और metadata के साथ POST भेजता है। Server इस specific upload के लिए एक unique URL return करता है और storage reserve करता है।
- Chunk: Client file को chunks में slice करता है (आमतौर पर 5-64 MB प्रत्येक)।
- Upload: Client हर chunk को PATCH request के रूप में Content-Range या Upload-Offset header के साथ भेजता है।
- Acknowledge: Server chunk को storage में write करता है और नया offset confirm करता है।
- Resume: अगर connection drop होती है, client upload URL पर HEAD request भेजता है। Server current offset के साथ respond करता है। Client वहां से resume करता है।
- Complete: Final chunk acknowledge होने पर, upload पूरा।
यह model tus.io specification (version 1.0.0 widely deployed है) द्वारा defined है। अन्य variants में S3 Multipart Upload और Google Cloud Storage Resumable Uploads शामिल हैं।
Tus.io: open standard
Tus ("transloadit upload server") एक free, open protocol है जिसे Transloadit maintain करता है। Specification tus.io पर है और implemented है:
- Client libraries: tus-js-client (browser + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
- Server implementations: tusd (Go reference server), tus-node-server, और कई framework integrations
- Commercial services: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, Uppy के companion servers
Protocol deliberately minimal है: चार HTTP verbs (POST, HEAD, PATCH, OPTIONS), कुछ headers (Upload-Offset, Upload-Length, Tus-Resumable)। यह implementations को simple और interoperable रखता है।
Chunk size निर्णय
Chunk size resume granularity और HTTP overhead के बीच trade-off करती है।
| Chunk size | Failure पर recovery cost | Overhead | |---|---|---| | 1 MB | ≤ 1 MB lose | High (many requests) | | 5 MB | ≤ 5 MB lose | Moderate | | 16 MB | ≤ 16 MB lose | Low | | 64 MB | ≤ 64 MB lose | Minimal | | 256 MB | ≤ 256 MB lose | Negligible overhead, failure पर painful |
Stable connections के लिए, 32-64 MB chunks throughput maximize करते हैं। Mobile या flaky Wi-Fi के लिए, 2-5 MB chunks हर failure से तेज़ recover करते हैं। Services आमतौर पर 5-10 MB range में default चुनती हैं।
Transfers को actually क्या interrupt करता है
Failure modes समझना evaluate करने में मदद करता है कि service का resume implementation robust है या नहीं:
- Wi-Fi drops: networks switching, signal loss, router reboot। बहुत common।
- Laptop sleep: macOS/Windows पर lid बंद करना। OS network pause करता है; wake होने पर connections re-establish करनी पड़ती हैं।
- Tab suspension: modern browsers memory बचाने के लिए background tabs suspend करते हैं। Suspended tab में uploads stall हो सकते हैं।
- ISP/backhaul issues: momentary routing changes, TLS re-handshake required।
- VPN reconnection: VPN clients periodically renegotiate; TCP connection मरती है।
- Server-side restarts: transfer service नया version deploy करती है; in-flight requests fail होते हैं।
- Corporate firewall inspection: traffic inspect करने वाले corporate firewalls long-running connections kill करते हैं।
एक robust resumable implementation सभी को same mechanism से handle करता है: reconnect, offset check करने के लिए HEAD, वहां से resume।
Downloads के लिए Resume
HTTP Range requests (RFC 7233) resumable downloads power करते हैं। Server जो response headers में Accept-Ranges: bytes advertise करता है, range requests support करता है। Clients तब offset 1,000,000 से केवल bytes fetch करने के लिए Range: bytes=1000000- issue कर सकते हैं।
Browsers यह automatically "Resume" hit करने पर use करते हैं। Chrome, Firefox, और Safari सभी compliant servers से downloads के लिए resume support करते हैं।
Command-line tools ज़्यादा control देते हैं:
curl -C - -O urldownload को जहां रुका था वहां से resume करता है।wget -c urlवही करता है।aria2c -c -s 16 urlspeed के लिए 16 parallel range-request streams से download करता है।
Resume support वाली सेवाएं
Modern transfer services mostly upload resume handle करती हैं:
| Service | Upload resume | Download resume | |---|---|---| | SwissTransfer | हां (tus-based) | हां (HTTP ranges) | | HexaTransfer | हां (chunked + tus-compatible) | हां | | WeTransfer | हां (chunked uploads) | हां | | Dropbox Transfer | हां | हां | | Google Drive | हां (resumable upload API) | हां | | OneDrive | हां | हां | | Box | हां | हां |
Free tiers कभी-कभी paid upgrades encourage करने के लिए resume disable करती हैं, लेकिन यह 2026 में rare है।
क्या automatically resume नहीं होता
Plain HTTP POST uploads naive applications में resume नहीं होते। FTP transfers historically vary होते हैं। Email attachments resume नहीं हो सकते।
Torrent-based transfers inherently resume होते हैं क्योंकि torrent protocol track करता है कि कौन से pieces verified हैं।
End-to-end encryption के साथ Resume
Resumable uploads combined with client-side encryption के लिए careful chunking चाहिए। File को chunks में split किया जाता है, हर chunk को unique IV (initialization vector) के साथ AES-256-GCM से encrypt किया जाता है, और फिर upload किया जाता है। Resume पर, client को पता होना चाहिए कि कौन से chunks complete हुए।
क्योंकि हर chunk independently encrypt और authenticate होता है (GCM का AEAD mode), partial uploads से छेड़छाड़ नहीं हो सकती। Offset 5 GB पर garbage insert करने वाला malicious server decrypt करने पर authentication fail करेगा — GCM tag mismatch catch होगा।
HexaTransfer जैसी implementations per-chunk IVs master key और chunk index से deterministically derive करती हैं, इसलिए resumption के लिए IVs अलग store नहीं करने पड़ते।
DPDP Act 2023 और resumable transfers
भारत के Digital Personal Data Protection (DPDP) Act 2023 के अंतर्गत, personal data के ट्रांसफर में interruption-free delivery सुनिश्चित करना data fiduciary की ज़िम्मेदारी है। Resumable chunked uploads, जो HexaTransfer जैसी सेवाएं provide करती हैं, data loss के risk को कम करते हैं और DPDP compliance को support करते हैं।
Client-side best practices
Resume success maximize करने के लिए:
- Upload के दौरान tab active रखें। Browser tab suspension in-flight uploads kill करती है।
- जहां possible हो wired network। Wi-Fi drops अधिकांश failures cause करती हैं।
- Long uploads के दौरान power-saving sleep disable करें। macOS:
caffeinate -i। Windows: Powertoys Awake utility या power plan changes। - Upload mid-way में Wi-Fi networks न switch करें। TCP connection IP बदलती है और मरती है।
- Laptop lid बंद करने से पहले upload finish होने दें।
Server side पर verify करें
कुछ services incomplete progress bars दिखाती हैं जो server state reflect नहीं करतीं। एक-दो interruptions survive करने वाले upload के बाद, page refresh करें और link काम करता है verify करें — incognito में open करें।
Paranoia-worthy scenarios के लिए, client पर SHA-256 hash compute करें, upload करें, और downloaded file का hash match करें verify करें।
निष्कर्ष
Resumable transfer 2026 में table-stakes feature है — इसके बिना कोई भी सेवा कुछ सौ megabytes से बड़ी files के लिए immediate deal-breaker है। tus.io compliance या equivalent chunked-upload behavior देखें। यह सुनिश्चित करें कि आपकी chosen service interruptions gracefully handle करती है।
hexatransfer.com पर आज़माएं — मुफ्त, बिना अकाउंट, 10 GB तक।
एंड-टू-एंड एन्क्रिप्शन के साथ बड़ी फ़ाइलें सुरक्षित रूप से भेजें
एंड-टू-एंड एन्क्रिप्शन के साथ 10 GB तक की फ़ाइलें मुफ़्त में ट्रांसफ़र करें। अकाउंट की आवश्यकता नहीं। अपलोड से पहले आपकी फ़ाइलें ब्राउज़र में एन्क्रिप्ट की जाती हैं — कोई और उन्हें पढ़ नहीं सकता।
फ़ाइल भेजें