WebRTC फ़ाइल ट्रांसफ़र: Browser-to-Browser ट्यूटोरियल

WebRTC file transfer RTCDataChannel का उपयोग करके दो browsers के बीच directly bytes move करता है — initial handshake के बाद data path में कोई server नहीं बैठता। आपको जो pieces चाहिए: SDP offers और ICE candidates exchange करने के लिए signaling channel (WebSocket या कोई भी tiny relay), NAT discovery के लिए STUN servers, symmetric NATs के लिए TURN fallback, और reliable ordered delivery के लिए configured data channel। Peer connection up होने के बाद, आप 16 KB-256 KB chunks channel.send() करते हैं और bytes DTLS 1.2 encrypted SCTP association पर roughly network-line speed पर flow देखते हैं।

WebRTC Peer-to-Peer कैसे Actually होता है

WebRTC magic नहीं है — यह ICE plus SDP plus DTLS plus SCTP stacked together है। Sender RTCPeerConnection create करता है, data channel खोलता है, SDP offer generate करता है, और आपके signaling channel के माध्यम से recipient को भेजता है। Recipient answer करता है। दोनों sides फिर ICE candidates (local IP, reflexive IP via STUN, relay IP via TURN) trade करती हैं जब तक working path नहीं मिल जाता। DTLS 1.2 end-to-end handshake होता है, SCTP reliable streaming के लिए ऊपर rides करता है, और आपके bytes flow होने लगते हैं।

Encryption mandatory और built-in है। आप opt out नहीं कर सकते। यह meaningful security win है — WebSockets के unlike, network eavesdroppers से protect करने के लिए कुछ application-layer crypto में wrap करना remember नहीं पड़ता। Signaling server के खिलाफ real E2EE के लिए, ऊपर AES-256-GCM का second round layer करें, क्योंकि malicious signaling server अपना DTLS certificate swap कर सकता है।

Signaling: वह Part जो WebRTC Define नहीं करता

WebRTC जानबूझकर signaling आप पर छोड़ता है। आपके server पर WebSocket fine है; Firebase realtime DB पर posted shared room code भी; manually pasted SDP strings भी। जो matter करता है वह यह है कि दोनों peers eventually offer, answer, और ICE candidates का stream exchange करें।

Node में minimal signaling server:

const rooms = new Map();
wss.on('connection', (ws) => {
  ws.on('message', (raw) => {
    const msg = JSON.parse(raw);
    if (msg.type === 'join') {
      const room = rooms.get(msg.room) ?? new Set();
      room.add(ws); rooms.set(msg.room, room);
    } else {
      for (const peer of rooms.get(msg.room) ?? []) {
        if (peer !== ws) peer.send(raw);
      }
    }
  });
});

20 lines से कम। Server file bytes कभी नहीं देखता — केवल SDP और ICE metadata। इसे ₹400/माह VPS या Cloudflare Workers पर host करें और सैकड़ों concurrent transfers serve करें।

Peer Connection Set Up करना

Google के public STUN plus TURN fallback के साथ connection create करें:

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    { urls: 'turn:turn.example.com:3478',
      username: 'user', credential: 'pass' }
  ]
});

Residential connections का लगभग 15-25% symmetric NATs के पीछे बैठता है जिसे STUN punch through नहीं कर सकता, इसलिए TURN production service के लिए optional नहीं है। Relayed traffic handle करने के लिए पर्याप्त bandwidth के साथ VPS पर coturn run करें, या Xirsys जैसे managed TURN provider के लिए pay करें।

Offer create करने से पहले offerer's side पर data channel खोलें:

const channel = pc.createDataChannel('file', {
  ordered: true, maxRetransmits: null
});
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signaling.send({ type: 'offer', sdp: offer.sdp });

Ordered + unlimited retransmits TCP-equivalent reliability देता है। Unordered mode faster है लेकिन application-level reassembly चाहिए।

Channel के लिए File Chunk करना

SCTP का practical 256 KB per-message limit है, और पुराने browsers 16 KB से ऊपर struggle करते हैं। Safe default है 16 KB chunks File.slice() के माध्यम से file से read:

const chunkSize = 16 * 1024;
let offset = 0;
channel.bufferedAmountLowThreshold = 1024 * 1024;
function sendNext() {
  while (offset < file.size && channel.bufferedAmount < 4 * 1024 * 1024) {
    const chunk = file.slice(offset, offset + chunkSize);
    chunk.arrayBuffer().then((buf) => channel.send(buf));
    offset += chunkSize;
  }
}
channel.onbufferedamountlow = sendNext;
sendNext();

bufferedAmount watermark SCTP के send buffer में gigabytes queue करने और memory out of run करने से रोकता है। Buffer 1 MB से कम होने पर 4 MB तक refill करें। यह local networks पर 40-80 MB/s के करीब throughput और typical residential broadband पर 5-20 MB/s देता है।

Bytes Receive और Disk पर Write करना

Answering side पर, incoming channel listen करें:

pc.ondatachannel = ({ channel }) => {
  const chunks = [];
  let received = 0;
  channel.onmessage = ({ data }) => {
    chunks.push(data);
    received += data.byteLength;
    updateProgress(received);
    if (received === expectedSize) finish(chunks);
  };
};

500 MB से बड़ी files के लिए, RAM में accumulate न करें। File System Access API का उपयोग करके directly disk पर stream करें:

const handle = await window.showSaveFilePicker({ suggestedName: fileName });
const writable = await handle.createWritable();
channel.onmessage = async ({ data }) => writable.write(data);

Firefox और Safari अभी showSaveFilePicker support नहीं करते, इसलिए उन browsers के लिए Blob + URL.createObjectURL download पर fall back करें, 2 GB पर capped।

Bytes से पहले File Metadata भेजना

Receiver को byte stream शुरू होने से पहले file name, size, और MIME type जानना होगा। Data channel पर tiny JSON handshake उपयोग करें:

channel.send(JSON.stringify({
  type: 'metadata', name: file.name,
  size: file.size, mime: file.type, sha256: fileHash
}));

फिर binary mode पर switch करें। Receiver इस पर toggle करता है कि data string है या ArrayBuffer। Post-transfer integrity verification के लिए file का SHA-256 include करें, और optionally key fingerprint include करें यदि आप ऊपर application-level AES-GCM layer कर रहे हैं।

Connection Failures से Deal करना

WebRTC data channels तीन तरीकों से fail होते हैं: ICE कभी complete नहीं होता (NAT, firewall blocks), DTLS handshake fail होता है (clock skew, cert issues), या connection mid-transfer drop होता है (laptop sleep, network change)। pc.oniceconnectionstatechange listen करें और 'failed' या 'disconnected' पर act करें। Chrome कुछ seconds के लिए 'disconnected' रखता है 'failed' पर जाने से पहले; Safari कम patient है।

Mid-transfer failure पर, whole connection rebuild किए बिना ICE restart करें:

await pc.restartIce();
const offer = await pc.createOffer({ iceRestart: true });
// re-send via signaling

यदि restart fail हो, तो आपके server के माध्यम से resumable upload पर fall back करें — एक hybrid P2P + server architecture। Wormhole और justbeamit जैसे कुछ WebRTC transfer tools यह pattern उपयोग करते हैं क्योंकि यह उन 15% network conditions handle करता है जहाँ pure P2P काम नहीं कर सकता।

अपने Server के खिलाफ End-to-End Encryption Add करना

WebRTC का built-in DTLS network attackers से protect करता है लेकिन malicious या compromised signaling server से नहीं। True E2EE के लिए, दोनों peers ECDH P-256 keypair generate करें, out-of-band code (QR या 6-word passphrase) के माध्यम से public keys exchange करें, HKDF-SHA256 के माध्यम से shared secret derive करें, और send call करने से पहले प्रत्येक data channel message को AES-256-GCM के साथ encrypt करें। उस तरह यदि signaling server DTLS certs swap करे, वह आपकी files नहीं read कर सकता।

HexaTransfer hybrid architecture उपयोग करता है — client-side AES-256-GCM के साथ server-side stored ciphertext — directness के बजाय offline-tolerant sharing के लिए। hexatransfer.com पर मुफ्त में आज़माएं — कोई खाता नहीं, 10 GB अधिकतम।

WebRTC कहाँ जीतता और हारता है

WebRTC file transfer shine करता है जब दोनों peers simultaneously online हों, जब आपके server से privacy matter करे, और जब files इतनी large हों (100 MB+) कि relay bandwidth costs painful होंगी। यह हारता है जब users send करके चले जाना चाहते हैं, जब recipients घंटों बाद link खोलते हैं, या जब recipients restrictive corporate networks पर हों जो STUN और TURN block करते हैं। General-purpose transfer tool के लिए, pure P2P comfortably शायद 60% use cases cover करता है। बाकी 40% को server-backed fallback चाहिए — यही कारण है कि लगभग हर "P2P file transfer" product की architecture में कहीं relay है।