WebSocket vs HTTP pour Transfert de fichiers: A Comparison

Pour le transfert de fichiers, HTTP gagne presque à chaque fois. Il est sans état, fonctionne à travers chaque proxy d'entreprise, bénéficie du multiplexage HTTP/2 et de HTTP/3 QUIC, et s'intègre proprement avec les CDN, les URL présignées et les API de stockage d'objets comme S3. WebSocket (RFC 6455) excelle pour la messagerie bidirectionnelle en temps réel — chat, édition collaborative, tableaux de bord en direct — mais offre peu d'avantages pour le déplacement de gros fichiers et introduit de vrais inconvénients : pas de cache natif, mauvais support CDN, problèmes avec les intermédiaires et gestion mémoire côté serveur plus complexe. Voici la comparaison détaillée avec des chiffres concrets, pertinente pour toute équipe qui conçoit un service de transfert respectant les contraintes RGPD sur la durée de conservation et la traçabilité des accès.

La différence fondamentale de protocole

HTTP est requête-réponse, sans état et mis en cache. Chaque requête porte des en-têtes, atteint un serveur ou un CDN et renvoie une réponse. HTTP/2 multiplexe de nombreuses requêtes sur une seule connexion TCP ; HTTP/3 (RFC 9114) tourne sur QUIC avec une meilleure récupération des pertes et une reprise à zéro RTT. WebSocket commence par une requête HTTP Upgrade, puis bascule la connexion TCP en un protocole full-duplex basé sur des frames. Après l'upgrade, les deux côtés envoient des messages à tout moment. Ce canal bidirectionnel persistant est puissant pour les applications interactives mais architecturalement maladroit pour le transfert de fichiers en masse où le flux est écrasantement unidirectionnel.

Benchmarks de débit et de latence

Sur un lien gigabit entre un client à Tokyo et un serveur US-East, les benchmarks typiques montrent : HTTP/1.1 PUT unique à environ 40 à 80 Mbps à cause des limites de window scaling TCP, HTTP/2 multipart (8 flux parallèles, parties de 8 Mo) à 400 à 800 Mbps, HTTP/3 sur QUIC légèrement meilleur sous perte de paquets de 10 à 30 %, et WebSocket avec des frames binaires à 200 à 500 Mbps, limité par le contrôle de flux sur connexion unique. Le schéma se répète sur différentes distances. WebSocket n'est pas plus rapide — car c'est toujours TCP sous le capot — mais il utilise la connexion moins efficacement que les requêtes HTTP parallèles.

Chunking et uploads reprenables

HTTP dispose de standards d'upload par chunks bien définis. Le protocole tus.io utilise HTTP PATCH avec des en-têtes Upload-Offset. S3 Multipart Upload utilise UploadPart avec des numéros de partie et des ETags. Les deux survivent aux interruptions réseau, reprennent depuis le dernier chunk réussi et fonctionnent entre les redémarrages du client grâce à l'état persisté dans IndexedDB. Le chunking WebSocket est ad-hoc : vous définissez votre propre encadrement, vos numéros de séquence et vos accusés de réception. Chaque équipe réinvente la même logique de reprise, généralement moins bonne que les options HTTP éprouvées. SocketIO, Primus et les protocoles personnalisés réinventent chacun la même roue avec des bugs subtils.

Compatibilité CDN et edge

Les CDN comme Cloudflare, CloudFront, Fastly et Akamai mettent en cache les réponses HTTP dans des PoP en bordure, réduisant souvent les temps de téléchargement de moitié globalement. Les requêtes GET pour des objets statiques peuvent être mises en cache par URL ou URL signée. Le trafic WebSocket traverse typiquement les CDN mais n'est pas mis en cache, et de nombreux proxys d'entreprise désactivent ou limitent l'upgrade WebSocket. Les réseaux d'entreprise avec des proxys TLS interceptants cassent parfois complètement WebSocket. Pour un service de transfert de fichiers avec une audience mondiale, cela seul suffit à préférer HTTP : les 300+ PoP de Cloudflare rendent les téléchargements proches dramatiquement plus rapides pour HTTP mais n'offrent que peu pour les charges utiles WebSocket.

Utilisation des ressources côté serveur

Les serveurs HTTP gèrent des milliers de connexions simultanées avec une mémoire minimale parce que les requêtes sont de courte durée. Nginx, caddy et net/http de Go prennent chacun en charge 10 000+ connexions simultanées par nœud avec une RAM modeste. Chaque connexion WebSocket est de longue durée, maintenant un socket TCP, un tampon de lecture, un tampon d'écriture et souvent l'état de l'application. À l'échelle, les flottes WebSocket nécessitent un réglage soigneux de ulimit, du keepalive TCP et de la mémoire par connexion. Les déploiements Kubernetes rencontrent des problèmes avec les sessions sticky WebSocket et l'arrêt gracieux lors des déploiements en mode roulement. Pour un service de transfert traitant des bursts d'uploads courts, le modèle HTTP est moins douloureux.

URL présignées et uploads directs vers le stockage

La fonctionnalité décisive de HTTP dans le transfert de fichiers est les URL présignées. Votre application génère une URL signée pointant directement vers S3, R2 ou GCS, et le client uploade directement vers le stockage d'objets. Vos serveurs applicatifs ne touchent jamais les octets. Pas de bande passante proxy, pas de pression mémoire, pas d'I/O de fichiers. WebSocket n'a pas d'équivalent. Pour utiliser WebSocket pour les uploads, vous proxifiez généralement via votre serveur applicatif, qui écrit ensuite vers le stockage, doublant les coûts de bande passante et ajoutant de la latence. Un upload de 10 Go via un pipeline WebSocket-vers-application-vers-S3 utilise 20 Go de bande passante serveur ; les uploads HTTP directs vers S3 n'utilisent la bande passante de vos serveurs que pour les petits appels de métadonnées.

Quand WebSocket aide réellement

WebSocket convient bien aux workflows adjacents aux fichiers. Les notifications de progression d'upload en temps réel entre onglets ou appareils : les broadcasts WebSocket livrent instantanément. L'édition collaborative de fichiers : les bibliothèques CRDT comme yjs et Automerge utilisent WebSocket pour les petits messages delta, avec les gros actifs transférés via HTTP. La signalisation live pour les transferts pair-à-pair WebRTC : WebSocket est le transport de signalisation standard avant l'ouverture des canaux de données P2P. Les notifications poussées par le serveur qu'un destinataire de transfert a téléchargé le fichier : WebSocket notifie instantanément l'expéditeur sans polling. Le pattern est WebSocket pour les événements, HTTP pour les octets.

Avantages de HTTP/2 et HTTP/3

HTTP/2 (RFC 7540) et HTTP/3 (RFC 9114) comblent la plupart des lacunes que WebSocket avait l'habitude d'exploiter. HTTP/2 multiplexe plusieurs requêtes sur une connexion TCP, éliminant la limite de 6 connexions par origine. Server Push permet aux serveurs d'envoyer des ressources de manière proactive, réduisant les allers-retours. HTTP/3 tourne sur QUIC, qui gère la perte de paquets par flux au lieu de bloquer toute la connexion — crucial sur les réseaux mobiles sujets aux pertes. Les Server-Sent Events (EventSource) fournissent un push serveur-vers-client unidirectionnel sur HTTP, plus simple que WebSocket quand seul le serveur a besoin de pousser.

Sécurité et contrôles d'origine

L'histoire de sécurité de HTTP est mature. CORS (Cross-Origin Resource Sharing) contrôle quelles origines peuvent uploader ou télécharger. CSP (Content Security Policy) restreint où les clients peuvent récupérer. TLS 1.3 sécurise le transport. Les URL présignées incluent des signatures HMAC pour éviter l'altération et peuvent être limitées à des clés d'objet exactes avec expiration. WebSocket a des contrôles d'origine plus faibles. L'en-tête Origin peut être usurpé par des clients non-navigateur. De nombreux serveurs WebSocket ne valident pas l'origine, conduisant à des attaques de détournement WebSocket cross-site. Implémenter des protections équivalentes nécessite une validation soignée des tokens sur chaque frame.

Tableau comparatif synthétique

| Critère | HTTP | WebSocket | |---|---|---| | Uploads/téléchargements de gros fichiers | Gagne (multipart, URL présignées, CDN) | Perd (flux unique, pas de cache) | | Messages bidirectionnels en temps réel | Perd (polling coûteux) | Gagne (full-duplex natif) | | Compatibilité CDN | Gagne (cache en bordure global) | Perd (rarement mis en cache) | | Ressources serveur à l'échelle | Gagne (sans état, connexions courtes) | Perd (longue durée, RAM par connexion) | | Compatibilité proxy d'entreprise | Gagne (HTTP standard) | Perd (proxy bloque souvent l'Upgrade) | | Uploads reprenables | Gagne (tus.io, S3 multipart) | Ad-hoc (DIY requis) |

Pour un service de transfert de fichiers comme HexaTransfer, HTTP plus multipart par chunks plus uploads directs vers S3 est la bonne architecture, avec WebSocket optionnel pour la progression en direct ou les événements de notification destinataire superposés.

Essayez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.