Cum funcționează un transfer peer-to-peer, de la browser la browser
Într-un transfer instant, fișierul pleacă din browserul tău direct în browserul destinatarului. Nu e încărcat mai întâi și nu este stocat niciodată pe serverele noastre. Serviciul nostru doar le face cunoștință celor două browsere. Pe drum, fișierul e criptat de două ori și circulă pe mai multe conexiuni deodată, pentru viteză, iar browserul destinatarului stabilește ritmul, ca niciuna dintre părți să nu rămână fără memorie.
Articolul acesta explică fiecare dintre acești pași. Pentru comparația cu transferurile găzduite, vezi peer-to-peer și transferurile găzduite.
Pasul 1: linkul e gata înainte să se trimită ceva
Când alegi un transfer instant, browserul tău înregistrează transferul la serviciul nostru: detaliile fișierelor și opțiunile pe care le-ai ales. Nu se trimite niciun octet din fișiere. După ce serviciul răspunde, browserul tău creează o cheie AES-256 nouă pentru acest transfer și o adaugă în linkul de partajare, după „#”. Browserele nu trimit acea parte a unui link niciunui server, așa că cheia nu ajunge niciodată la serviciul nostru.
Linkul funcționează imediat. Fila ta păstrează acum fișierele și așteaptă destinatarii.
Pasul 2: cele două browsere se găsesc
Când destinatarul deschide linkul, browserul lui întreabă mai întâi serviciul nostru despre transfer. Serviciul verifică linkul: că nu a expirat, că parola e corectă, dacă ai setat una, și că limita lui de descărcări nu e consumată. Abia după aceste verificări îi spune browserului destinatarului ce browser să contacteze.
Două browsere din rețele diferite nu se pot apela pur și simplu unul pe altul. Ele își schimbă detaliile de conexiune prin serviciul nostru de semnalizare, care transmite mesaje scurte între ele printr-un WebSocket. Mesajele descriu cum să se conecteze. Nu conțin date din fișier și nici cheia. Apoi fiecare browser află cum poate fi contactat:
- STUN. Servere STUN publice îi spun fiecărui browser adresa lui așa cum o vede internetul, ceea ce ajunge pentru majoritatea rețelelor de acasă și de birou.
- TURN, la nevoie. Unele rețele blochează conexiunile directe. Pentru ele, serviciul nostru creează la cerere date de acces la un releu, valabile doar 24 de ore, iar conexiunea trece atunci printr-un releu TURN.
Obținerea datelor de acces la releu nu ține niciodată un transfer pe loc prea mult: dacă durează mai mult de două secunde, browserele pornesc doar cu STUN, iar datele de acces sunt folosite la următoarea încercare de conectare.
Un releu retransmite fluxul criptat. Nu îl poate citi.
Pasul 3: criptat de două ori
Fiecare canal de date WebRTC e criptat cu DTLS între cele două browsere. Doar asta protejează deja fișierul de oricine urmărește rețeaua, inclusiv de releu.
DTLS are totuși o dependență. Fiecare browser își dovedește identitatea cu amprenta unui certificat, iar aceste amprente trec prin serviciul de semnalizare. Un server de semnalizare compromis le-ar putea schimba și s-ar putea pune la mijloc, iar DTLS nu ar observa.
De aceea Transferify adaugă propriul strat. Browserul tău sigilează fiecare bucată a fișierului cu AES-256-GCM, cu cheia din link, înainte ca bucata să intre în conexiune. Serviciul de semnalizare nu vede niciodată această cheie. Un server pus la mijloc ar vedea doar bucăți criptate, iar orice modificare făcută de el ar pica verificarea destinatarului. Fiecare bucată e legată și de acest transfer, de acest fișier și de poziția ei, așa că bucățile nu pot fi reordonate, eliminate sau schimbate cu ale altui fișier. Detaliile sunt în cum criptează Transferify fișierele în browserul tău.
Acest strat nu poate fi dezactivat. Dacă browserul tău nu îl poate configura, transferul nu pornește, iar browserul unui destinatar acceptă doar bucăți criptate.
Pasul 4: mai multe conexiuni deodată
O singură conexiune WebRTC folosește rareori din plin o linie rapidă, pentru că fiecare conexiune își crește viteza de trimitere cu prudență, de una singură. De aceea browserul destinatarului îi cere browserului tău să ruleze transferul pe patru conexiuni în paralel, fiecare cu traseul și viteza ei. Cele două browsere folosesc cel mai mic dintre numerele pe care le permite fiecare parte, niciodată mai mult de opt.
Browserul tău împarte bucățile pe conexiuni, pe rând, iar browserul destinatarului le pune înapoi în ordine. Conexiunile reușesc sau eșuează împreună: dacă una cade, transferul către acel destinatar se oprește cu totul.
Pasul 5: destinatarul stabilește ritmul
O rețea poate livra bucăți mai repede decât le poate salva un disc lent. Fără o limită, bucățile în așteptare s-ar aduna în memoria destinatarului până când browserul ar ceda.
În schimb, browserul destinatarului îi acordă browserului tău un buget de 32 MiB de date criptate deodată și îl reîncarcă pe măsură ce bucățile sunt decriptate și scrise. Browserul tău trimite doar cât mai are buget. Dacă destinatarul pune descărcarea pe pauză, browserul tău pur și simplu așteaptă și continuă în clipa în care descărcarea pornește din nou.
Pe partea destinatarului, fiecare bucată e decriptată și verificată pe măsură ce sosește și e scrisă direct într-o descărcare obișnuită de browser, prin funcția de descărcare proprie a site-ului, care rulează în browserul destinatarului, așa că nici un fișier foarte mare nu trebuie să încapă în memorie. Dacă o verificare eșuează, descărcarea e anulată în loc să fie salvată. Într-un browser în care funcția de descărcare nu e disponibilă, fișierele de până la 1 GiB sunt asamblate în memorie, iar cele mai mari nu pot fi primite acolo.
Pasul 6: vezi cine are fișierul
Când browserul destinatarului are un fișier întreg, îi trimite browserului tău o confirmare pentru el. Pagina ta listează fiecare destinatar care a deschis linkul și cât a primit până acum, și consideră un fișier livrat atunci când confirmarea destinatarului spune că a ajuns întreg.
Mai mulți destinatari pot descărca în același timp, fiecare pe propriile conexiuni către browserul tău.
Ce încheie un transfer
- Închizi fila. Fișierul e servit din browserul tău, așa că transferul se oprește.
- Ștergi transferul. Serviciul nostru îi spune filei tale, care închide deodată conexiunile tuturor destinatarilor. Fișierul circulă din browserul tău, nu din serviciul nostru, așa că instrucțiunea trebuie să ajungă la browserul tău, și ajunge. La fel se întâmplă dacă suspendăm un transfer după raportări de abuz.
- Linkul ajunge la data expirării. Destinatarii noi nu îl mai pot deschide.
Când să îl folosești
Transferurile instant se potrivesc fișierelor mari atunci când poți ține fila deschisă până când destinatarul le are. Dacă nu poți, un transfer găzduit păstrează online o copie criptată.
Încearcă
Alege un fișier, alege un transfer instant și trimite linkul pe un al doilea dispozitiv al tău: vei vedea cum apare pe pagina ta și cum trece fișierul dincolo. Pornește un transfer instant.
Întrebări frecvente
Trece un fișier peer-to-peer prin serverele Transferify?
Nu este stocat niciodată pe serverele noastre. Serviciul nostru înregistrează transferul și transmite mesajele scurte de care cele două browsere au nevoie ca să se găsească, iar apoi fișierul circulă între browsere. Când o rețea blochează o conexiune directă, fluxul criptat trece printr-un releu TURN, care retransmite octeți pe care nu îi poate citi.
De ce să criptezi un transfer WebRTC, dacă WebRTC e deja criptat?
WebRTC criptează conexiunea cu DTLS, dar cele două browsere își confirmă una alteia identitatea DTLS prin mesaje pe care le transmite serviciul nostru de semnalizare. Un server de semnalizare necinstit s-ar putea pune la mijloc. De aceea fișierul e criptat și cu AES-256-GCM, cu o cheie care călătorește doar în link și pe care niciun server nu o primește.
Pot mai multe persoane să descarce același link instant în același timp?
Da. Fiecare destinatar care deschide linkul primește propriile conexiuni către browserul tău, iar pagina ta îi listează pe fiecare, cu cât a primit până acum.
Ce se întâmplă dacă închid fila?
Transferul se încheie, pentru că fișierul e servit din browserul tău. Pentru un link care funcționează și după ce închizi fila, trimite în schimb un transfer găzduit.