Une explication technique du processus de transfert pair-à-pair
File Transfer utilise WebRTC (Web Real-Time Communication) pour établir un canal de données direct et chiffré entre deux navigateurs. Une fois connecté, le fichier est découpé en petits blocs binaires et diffusé depuis le navigateur de l’expéditeur vers celui du destinataire en temps réel — sans passer par aucun serveur intermédiaire.
Le processus comporte cinq phases distinctes :
Lorsque l’expéditeur sélectionne un fichier, l’application génère un UUID v4 aléatoire (Universally Unique Identifier), par exemple :
Cet UUID devient l’identifiant pair de l’expéditeur dans le réseau PeerJS. Le navigateur de l’expéditeur enregistre cet identifiant auprès d’un serveur de signalisation public opéré par PeerJS. Le lien partagé par l’expéditeur est simplement l’adresse de la page suivie de ?receive= et de cet UUID.
Le seul rôle du serveur de signalisation est d’aider les deux navigateurs à se trouver et à échanger les métadonnées de connexion WebRTC (appelées offres et réponses SDP). Il ne voit jamais les données des fichiers.
Le serveur de signalisation échange uniquement deux types de messages :
Une fois que les deux navigateurs ont échangé ces informations, le serveur de signalisation n’est plus impliqué. Toute communication ultérieure est pair-à-pair.
La plupart des appareils se trouvent derrière un routeur utilisant la NAT (Network Address Translation), ce qui signifie qu’ils n’ont pas d’adresse IP publique à laquelle un autre appareil peut se connecter directement. WebRTC résout ce problème via un processus appelé ICE (Interactive Connectivity Establishment).
Chaque navigateur contacte un serveur STUN (Session Traversal Utilities for NAT) pour découvrir sa propre adresse IP publique et son port tels qu’ils apparaissent depuis internet. Cette adresse publique est incluse dans les candidats ICE envoyés à l’autre pair.
Les deux navigateurs collectent toutes leurs adresses réseau possibles (adresses réseau local, adresses publiques mappées par NAT) et tentent de se connecter à chacune des adresses de l’autre pair en parallèle. La première paire qui réussit devient le chemin de connexion actif.
Dans certaines configurations réseau (pare-feux stricts, NAT symétrique), les connexions directes ne sont pas possibles. Dans ce cas, WebRTC utilise un serveur TURN (Traversal Using Relays around NAT) comme relais. Même via un relais TURN, les données restent chiffrées DTLS et le serveur relais ne peut pas en lire le contenu.
Une fois la négociation ICE terminée, WebRTC ouvre un RTCDataChannel entre les deux navigateurs. Ce canal est :
Avant que le fichier commence à être diffusé, l’application effectue une brève négociation au niveau applicatif :
file-info (nom, taille, type MIME, nombre total de blocs)start (identifiant de transfert, premier bloc attendu)Transférer un fichier volumineux en un seul message binaire surchargerait le tampon d’envoi du navigateur et bloquerait l’interface. Le fichier est donc lu et diffusé en blocs de 64 Ko.
Le RTCDataChannel de WebRTC dispose d’un tampon d’envoi configurable. L’envoi de blocs trop grands peut provoquer un débordement du tampon, entraînant des erreurs ou des coupures. 64 Ko est une taille de bloc conservatrice qui maintient le tampon en dessous de la saturation sur les réseaux typiques tout en offrant un bon débit.
Deux limites maintiennent une consommation mémoire constante. L’expéditeur n’a jamais plus de 16 Mo de blocs non encore confirmés par le destinataire (un bloc est confirmé une fois confié au module d’écriture du destinataire, qui en garde au plus quelques mégaoctets en mémoire avant de les écrire), et il fait une pause dès que la propriété bufferedAmount du canal dépasse 4 Mo, pour reprendre sur l’événement bufferedamountlow. Un réseau ou un disque lent ralentit donc simplement l’expéditeur au lieu de remplir la mémoire.
L’expéditeur et le destinataire suivent la progression en termes de nombre de blocs. Le pourcentage de transfert, la vitesse actuelle (en Ko/s ou Mo/s) et le temps restant estimé sont mis à jour en temps réel à chaque bloc traité.
Le destinataire ne garde jamais le fichier entier en mémoire. Les blocs sont regroupés par 4 Mo et écrits sur le disque au fur et à mesure : dans Chrome et Edge, directement dans le fichier choisi via une boîte de dialogue affichée avant le début du transfert ; dans Firefox, via un service worker qui les transmet au gestionnaire de téléchargements du navigateur. Les navigateurs ne prenant en charge aucune de ces méthodes (comme Safari) reconstituent le fichier en mémoire et le téléchargent à la fin.
Les connexions réseau ne sont pas toujours fiables — un téléphone passant du Wi-Fi au réseau cellulaire, un ordinateur portable se mettant en veille, ou une brève panne de routeur peut couper la connexion WebRTC en cours de transfert. File Transfer gère cela automatiquement.
Une connexion coupée ne se ferme pas toujours proprement : WebRTC peut rester indéfiniment dans l’état « disconnected ». Les deux côtés envoient donc un signal de vie toutes les 5 secondes, et une connexion silencieuse pendant 20 secondes est considérée comme perdue, au même titre qu’une connexion fermée. La connexion au serveur de signalisation, nécessaire pour se reconnecter, est elle aussi rétablie automatiquement si elle tombe.
Un compte à rebours de 60 secondes commence. Pendant cette fenêtre :
Lorsque le destinataire se reconnecte, il envoie un message start avec son identifiant de transfert et le nombre exact de blocs déjà reçus. L’expéditeur reconnaît le transfert, même s’il n’avait pas encore remarqué la coupure de son côté, et reprend la diffusion à partir de cet index. Aucune donnée n’a besoin d’être retransférée depuis le début.
{ type: "start", rxId: "…", from: 1450 }Comme toutes les données de fichiers circulent directement entre les navigateurs dans un canal chiffré, les informations suivantes ne sont jamais accessibles par nous ni par le serveur de signalisation PeerJS :
Les seules données qui passent par les serveurs PeerJS sont les messages initiaux de négociation SDP et ICE, qui contiennent des adresses réseau mais aucune donnée de fichier. Ces messages sont éphémères et ne sont pas journalisés.
Dans de rares cas où une connexion directe ne peut pas être établie, les données peuvent transiter par un serveur relais TURN. Les serveurs TURN voient des paquets chiffrés mais ne peuvent pas les déchiffrer — le chiffrement DTLS est de bout en bout entre les deux navigateurs, indépendamment du chemin relayé.
Voici la séquence complète du début à la fin :
Pour plus de contexte sur les objectifs du projet et la philosophie de confidentialité, consultez la page à propos.