पीयर-टू-पीयर एन्क्रिप्टेड फ़ाइल ट्रांसफर: तकनीकी गाइड

पीयर-टू-पीयर फ़ाइल ट्रांसफर bytes को सीधे दो browsers या devices के बीच भेजता है — फ़ाइल कभी किसी server को नहीं छूती। WebRTC, RFC 8825 से 8837 में standardize किया गया, transport प्रदान करता है: UDP पर DTLS 1.3 के साथ encrypted data channels, ICE, STUN और TURN के माध्यम से NAT traversal, और WebSocket या HTTP पर signaling। Snapdrop, Wormhole.app, और Magic Wormhole जैसे tools यह साबित करते हैं कि यह model काम करता है। यहाँ बताया गया है कि इसे कैसे बनाएं: signaling handshake, NAT traversal की समस्याएं, encryption layering, और cloud-relay transfer services की तुलना में क्या मिलता और खोता है।

P2P फ़ाइल ट्रांसफर क्यों

आकर्षण सरल है: कोई server आपकी फ़ाइल store नहीं करता, transfer service का कोई bandwidth bill नहीं, और sender का upload ही recipient का download है बिना किसी intermediate copy के। एक gigabit LAN पर दो users के बीच 10 GB transfer के लिए, P2P 80 seconds में complete हो सकता है जबकि cloud relay एक distant server पर upload और फिर download करेगा — bandwidth usage और latency दोगुनी हो जाएगी। Privacy भी एक बड़ा फायदा है: file bytes केवल sender और recipient devices पर मौजूद रहते हैं। Tradeoffs: दोनों parties को एक साथ online होना होगा, NAT traversal कभी-कभी विफल होता है, और connection speed धीमे participant के upload link जितनी ही होगी।

Transport के रूप में WebRTC Data Channels

WebRTC video/audio protocol के रूप में शुरू हुआ लेकिन RTCDataChannel reliable ordered (TCP जैसा) या unreliable unordered (UDP जैसा) delivery के साथ arbitrary binary message transport देता है। Data channels SCTP over DTLS 1.3 over UDP पर चलते हैं। DTLS layer handshake के दौरान negotiate किए गए AES-128-GCM या ChaCha20-Poly1305 के माध्यम से confidentiality और authenticated integrity प्रदान करता है। फ़ाइल transfer के लिए, एक reliable ordered channel बनाएं, फ़ाइल को 16 KB या 64 KB messages में chunk करें (Chrome ने ऐतिहासिक रूप से message size को 256 KB तक सीमित किया है), और buffered amount threshold के माध्यम से flow control के साथ sequentially भेजें।

Signaling Server की भूमिका

WebRTC को peers के बीच connection info (SDP offers और answers, ICE candidates) exchange करने के लिए signaling server चाहिए। Signaling server file bytes relay नहीं करता — केवल ~5 KB connection metadata। Node.js, Python, या Go में एक WebSocket-based signaling service कुछ सौ lines of code में यह handle करती है। Firebase Realtime Database, Supabase Realtime, और Pusher signaling backends के रूप में काम करते हैं। Signaling server देखता है कि कौन किससे बात कर रहा है और कब, लेकिन file contents कभी नहीं। अधिकांश P2P file transfer services अपना signaling free चलाती हैं क्योंकि bandwidth trivial है।

NAT Traversal: STUN, TURN, और ICE

अधिकांश devices NAT के पीछे बैठती हैं, जिससे direct IP connections असंभव हो जाते हैं। ICE (Interactive Connectivity Establishment, RFC 8445) multiple connection paths try करता है। STUN (RFC 8489) peer को public STUN server के माध्यम से अपना public IP और port discover करने देता है; Google stun.l.google.com मुफ्त चलाता है। यदि दोनों peers के reasonable NATs हैं (full-cone या restricted-cone), direct UDP connection काम करता है — शायद 70 प्रतिशत attempts में। Symmetric NATs, corporate firewalls, और CGNAT के लिए, TURN (RFC 8656) एक server के माध्यम से traffic relay करता है। TURN servers महंगे होते हैं क्योंकि वे actual file bytes carry करते हैं। Self-hosted coturn, twilio.com/stun, या Cloudflare Calls विकल्प प्रदान करते हैं। Wild में 10 से 30 प्रतिशत P2P transfers TURN पर fall back करने की उम्मीद करें।

DTLS के ऊपर Encryption Layering

DTLS पहले से WebRTC data encrypt करता है, इसलिए additional application-layer encryption belt-and-suspenders है। DTLS handshake peer certificates authenticate करता है, लेकिन WebRTC आमतौर पर self-signed certificates उपयोग करता है जो identity verify नहीं करते — वे verify करते हैं कि connection उसी peer से है जिसने SDP sign किया। AES-256-GCM और signaling rendezvous से derived shared secret के साथ application-layer encryption identity assurance जोड़ता है। Magic Wormhole का SPAKE2 PAKE (Password-Authenticated Key Exchange) एक short human-readable phrase से strong key derive करता है, इसलिए compromised signaling server भी decrypt नहीं कर सकता।

P2P फ़ाइल Transfer के लिए Chunking Strategy

WebRTC data channels की message size limit होती है (अधिकांश browsers में 256 KB, larger messages का fragmentation काम करता है लेकिन unreliable है)। Compatibility के लिए files को 16 KB से 64 KB प्रति message पर chunk करें। Backpressure implement करने के लिए bufferedAmount और bufferedAmountLowThreshold के माध्यम से buffered amount track करें — buffer 1 MB से अधिक होने पर sending pause करें, 256 KB से कम होने पर resume करें। Integrity के लिए, प्रत्येक chunk को SHA-256 से hash करें और hash को पहले भेजे गए manifest में शामिल करें। Receiver reassemble करता है, hashes verify करता है, और File System Access API या Blob download के माध्यम से disk पर लिखता है।

Mobile और Cross-Device विचार

Desktop-to-desktop P2P अच्छी तरह काम करता है। Mobile-to-desktop जटिलताएं लाता है: mobile browsers aggressive tab suspension enforce करते हैं, इसलिए sender को browser tab foreground में रखना होगा। iOS Safari का data channel implementation historically Chromium से कम reliable रहा है। Mobile पर background uploads के लिए app-backed implementations (Snapdrop Relay, ShareDrop) चाहिए। Battery impact भी मायने रखता है — sustained WebRTC sessions HTTPS downloads से faster batteries drain करते हैं। Android पर Nearby Share और iOS/macOS पर AirDrop same Wi-Fi पर mobile-to-mobile transfers के लिए browser P2P को direct device protocols से outperform करते हैं।

Central Accounts के बिना Peer Discovery

दो अजनबी account-based system के बिना कैसे connect करते हैं? कई patterns काम करते हैं। Magic Wormhole का "4-truck-roger" जैसा short code rendezvous address और password दोनों के रूप में serve करता है; signaling server codes को sessions पर map करता है। In-person transfers के लिए session URL encode करने वाले QR codes काम करते हैं। Android पर NFC tap-to-connect proximity से connect होता है। बड़े networks के लिए, BitTorrent's Mainline DHT जैसा DHT central server के बिना peer discovery bootstrap कर सकता है, लेकिन DHT lookups में seconds लगते हैं और casual file sharing के लिए उपयुक्त नहीं हैं।

P2P के लिए विशिष्ट Security Threats

P2P cloud relays जो नहीं करते वे threats लाता है। IP address disclosure: direct connections प्रत्येक peer का public IP दूसरे को reveal करते हैं — privacy-sensitive contexts में (whistleblowing, activism) यह doxxing का risk है। कुछ P2P services performance की कीमत पर IPs छुपाने के लिए TURN relay force करती हैं। Malware distribution को moderate करना कठिन है क्योंकि service operator कभी file contents नहीं देखता। Signaling server पर connection exhaustion के माध्यम से denial-of-service के लिए rate limiting जरूरी है। Extra-sensitive transfers के लिए, एक Tor onion service signaling के सामने दोनों IPs भारी latency cost पर छुपा सकती है।

वास्तविक Performance

P2P speed धीमे peer के upload bandwidth और round-trip latency से bounded है। Residential connections पर, upload caps अक्सर 20 से 50 Mbps होते हैं भले ही download gigabit हो। 20 Mbps home upload से gigabit recipient को 10 GB P2P transfer minimum 68 minutes लेगा। Fast uplink और CDN-backed download वाला cloud relay उससे बेहतर कर सकता है एक well-connected server पर एक बार upload करके। P2P same-LAN transfers (gigabit या faster), sensitive data जहाँ कोई server-side copy acceptable नहीं, और cost optimization जब bandwidth bills painful होंगे — इन्हीं के लिए जीतता है।

Cloud Relay कब जीतता है

Async transfers के लिए जहाँ sender और recipient एक साथ online नहीं हैं, P2P पूरी तरह fail होता है — receive करने के लिए कोई peer नहीं है। Large transfers जो session window से अधिक हों (mobile browser tabs बंद हो जाते हैं, laptops sleep होते हैं) के लिए cloud relay का "upload and share a link" model बहुत अधिक practical है। One-to-many distribution के लिए, एक single upload plus CDN fanout N simultaneous P2P sessions से बेहतर है। HexaTransfer client-side AES-256-GCM encryption के साथ cloud relay model उपयोग करता है — P2P का अधिकांश privacy benefit async और multi-recipient support के साथ मिलता है।

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