WebSocket vs HTTP voor Bestandsoverdracht: A Comparison

Voor bestandsoverdracht wint HTTP vrijwel altijd. Het is stateless, werkt via elk bedrijfsproxy, profiteert van HTTP/2-multiplexing en HTTP/3 QUIC, en integreert naadloos met CDN's, presigned URLs en objectopslag-API's zoals S3. WebSocket (RFC 6455) blinkt uit voor realtime bidirectioneel berichtenverkeer — chat, collaboratieve bewerking, live dashboards — maar biedt weinig voordeel voor het verplaatsen van grote bestanden en introduceert echte nadelen: geen native caching, slechte CDN-ondersteuning, problemen met tussenliggende apparaten en complexer geheugenbeheer aan de serverzijde. Hieronder de gedetailleerde vergelijking met cijfers.

Het fundamentele protocolverschil

HTTP is verzoek-reactie, stateless en cacheerbaar. Elk verzoek draagt headers, bereikt een server of CDN en geeft een reactie terug. HTTP/2 multiplext veel verzoeken over één TCP-verbinding; HTTP/3 (RFC 9114) draait over QUIC met beter verliesverhaal en zero-RTT-hervatting. WebSocket begint als een HTTP-Upgrade-verzoek en schakelt de TCP-verbinding vervolgens om naar een full-duplex, frame-gebaseerd protocol. Na de upgrade kunnen beide zijden op elk moment berichten versturen. Dat persistente bidirectionele kanaal is krachtig voor interactieve toepassingen, maar architecturaal onhandig voor bulk bestandsoverdracht waarbij de flow overwegend eenrichtingsverkeer is.

Doorvoer- en latentiebenchmarks

Op een gigabitverbinding tussen een Tokyo-client en een US-East-server tonen typische benchmarks: HTTP/1.1 single PUT op ruwweg 40 tot 80 Mbps door TCP-vensterscaling-limieten, HTTP/2 multipart (8 parallelle streams, 8 MB onderdelen) op 400 tot 800 Mbps, HTTP/3 over QUIC iets beter bij pakketverlies met 10 tot 30 procent, en WebSocket met binaire frames op 200 tot 500 Mbps — begrensd door single-connection flow control. Het patroon herhaalt zich over afstanden. WebSocket is niet sneller, omdat het nog steeds TCP gebruikt, maar benut de verbinding minder efficiënt dan parallelle HTTP-verzoeken.

Chunking en hervatbare uploads

HTTP heeft goed gedefinieerde standaarden voor chunk-uploads. Het tus.io-protocol gebruikt HTTP PATCH met Upload-Offset-headers. S3 Multipart Upload gebruikt UploadPart met onderdeelnummers en ETags. Beide overleven netwerkonderbrekingen, hervatten bij de laatste succesvolle chunk en werken over client-herstarts dankzij IndexedDB-bewaarde staat. WebSocket-chunking is ad-hoc: je definieert je eigen framing, volgnummers en bevestigingen. Elk team bedenkt zijn eigen hervatlogica opnieuw, doorgaans slechter dan de beproefde HTTP-opties. SocketIO, Primus en aangepaste protocollen heruitvinden telkens hetzelfde wiel met subtiele bugs.

CDN- en edge-compatibiliteit

CDN's zoals Cloudflare, CloudFront, Fastly en Akamai cachen HTTP-reacties bij edge-PoP's, wat downloadtijden wereldwijd vaak halveert. GET-verzoeken voor statische objecten kunnen worden gecached op URL of ondertekende URL. WebSocket-verkeer passeert CDN's doorgaans maar wordt niet gecached, en veel bedrijfsproxy's schakelen WebSocket-upgrade uit of beperken het. Bedrijfsnetwerken met onderscheppende TLS-proxy's breken WebSocket soms volledig. Voor een bestandsoverdrachtsservice met een wereldwijd publiek is dit alleen al reden genoeg om de voorkeur aan HTTP te geven: Cloudflare's 300+ PoP's maken downloads in de buurt dramatisch sneller voor HTTP maar bieden weinig voor WebSocket-payloads.

Serverresourcegebruik

HTTP-servers verwerken duizenden gelijktijdige verbindingen met minimaal geheugen omdat verzoeken van korte duur zijn. Nginx, Caddy en Go's net/http ondersteunen elk meer dan 10.000 gelijktijdige verbindingen per node met bescheiden RAM. Elke WebSocket-verbinding is langlevend en bezet een TCP-socket, een leesbuffer, een schrijfbuffer en vaak applicatiestaat. Op schaal hebben WebSocket-fleets zorgvuldige afstemming van ulimit, TCP keepalive en geheugen per verbinding nodig. Kubernetes-implementaties kampen met WebSocket sticky sessions en soepele afsluiting tijdens rolling deploys. Voor een overdrachtsservice die burst van korte uploads verwerkt, is HTTP's model minder problematisch.

Presigned URLs en directe uploads naar opslag

De killerfunctie voor HTTP bij bestandsoverdracht zijn presigned URLs. Je app genereert een ondertekende URL die rechtstreeks naar S3, R2 of GCS wijst, en de client uploadt rechtstreeks naar objectopslag. Je appservers raken de bytes nooit aan. Geen proxy-bandbreedte, geen geheugendruk, geen bestands-I/O. WebSocket heeft geen equivalent. Om WebSocket voor uploads te gebruiken, proxy je doorgaans via je appserver die vervolgens naar opslag schrijft — dit verdubbelt de bandbreedtekosten en voegt latentie toe. Een upload van 10 GB via WebSocket-naar-app-naar-S3 gebruikt 20 GB serverbandbreede; directe HTTP-uploads naar S3 gebruiken je servers alleen voor kleine metadataoproepen.

Wanneer WebSocket daadwerkelijk helpt

WebSocket past goed bij bestandsgerelateerde workflows. Realtime upload-voortgangsnotificaties over tabbladen of apparaten: WebSocket-broadcasts leveren onmiddellijk. Collaboratieve bestandsbewerking: yjs, Automerge en vergelijkbare CRDT-bibliotheken gebruiken WebSocket voor kleine delta-berichten, met de daadwerkelijke grote assets overgedragen via HTTP. Live signalering voor WebRTC peer-to-peer overdrachten: WebSocket is het standaard signaleringstransport voordat P2P-datakanalen openen. Servergepushte notificaties dat een overdrachtsontvanger het bestand heeft gedownload: WebSocket laat je de afzender onmiddellijk informeren zonder polling. Het patroon: WebSocket voor gebeurtenissen, HTTP voor bytes.

HTTP/2 en HTTP/3 voordelen

HTTP/2 (RFC 7540) en HTTP/3 (RFC 9114) dichten de meeste gaten die WebSocket vroeger exploiteerde. HTTP/2 multiplext meerdere verzoeken over één TCP-verbinding, waardoor de limiet van 6 verbindingen per origin vervalt. Server Push laat servers resources proactief versturen en vermindert rondrips. HTTP/3 draait over QUIC, dat pakketverlies per stream afhandelt in plaats van de hele verbinding te blokkeren — cruciaal op verliesrijke mobiele netwerken. Server-Sent Events (EventSource) bieden eenrichtings-server-naar-client-push via HTTP, eenvoudiger dan WebSocket wanneer alleen de server hoeft te pushen.

Beveiliging en origin-controles

HTTP's beveiligingsverhaal is volwassen. CORS (Cross-Origin Resource Sharing) bepaalt welke origins kunnen uploaden of downloaden. CSP (Content Security Policy) beperkt waar clients van kunnen ophalen. TLS 1.3 beveiligt het transport, conform de richtlijnen van het NCSC. Presigned URLs bevatten HMAC-handtekeningen om manipulatie te voorkomen en kunnen worden beperkt tot exacte objectsleutels met vervaldatum. WebSocket heeft zwakkere origin-controles. De Origin-header kan worden vervalst door niet-browserende clients. Veel WebSocket-servers valideren de origin niet, wat leidt tot cross-site WebSocket-hijacking-aanvallen. Gelijkwaardige bescherming vereist zorgvuldige tokenvalidatie op elk frame.

Wanneer elk wint

| Criterium | HTTP | WebSocket | |---|---|---| | Grote bestanden uploaden/downloaden | Wint (multipart, presigned URLs, CDN) | Verliest (enkelvoudige stream, geen caching) | | Realtime bidirectionele berichten | Verliest (polling is verspillend) | Wint (native full-duplex) | | CDN-compatibiliteit | Wint (globale edge-caching) | Verliest (zelden gecached) | | Serverresources op schaal | Wint (stateless, korte verbindingen) | Verliest (langlevend, RAM per verbinding) | | Bedrijfsproxy-compatibiliteit | Wint (standaard HTTP) | Verliest (proxy blokkeert Upgrade vaak) | | Hervatbare uploads | Wint (tus.io, S3 multipart) | Ad-hoc (zelf bouwen vereist) |

Voor een bestandsoverdrachtsservice zoals HexaTransfer is HTTP plus chunked multipart plus directe S3-uploads de juiste architectuur, met optioneel WebSocket voor live voortgang of ontvanger-notificatiegebeurtenissen als aanvulling.

Probeer het op https://hexatransfer.com — gratis, geen account, maximaal 10 GB.