WebSocket vs HTTP für Dateiübertragung: A Comparison

Für Dateiübertragung gewinnt HTTP fast immer. Es ist zustandslos, funktioniert durch jeden Unternehmens-Proxy, profitiert von HTTP/2-Multiplexing und HTTP/3-QUIC und integriert sich nahtlos mit CDNs, presignierten URLs und Objektspeicher-APIs wie S3. WebSocket (RFC 6455) glänzt für Echtzeit-bidirektionale Nachrichten – Chat, kollaboratives Bearbeiten, Live-Dashboards – bietet aber kaum Vorteile bei der Übertragung großer Dateien und führt zu echten Nachteilen: kein natives Caching, schlechte CDN-Unterstützung, Proxy-Inkompatibilitäten und komplexeres serverseitiges Speichermanagement. Das BSI-Grundschutz-Kompendium, Baustein APP.3.1, betont zudem, dass Protokollentscheidungen die Angriffsfläche von Webanwendungen unmittelbar beeinflussen – ein weiterer Grund, bei Standard-HTTP zu bleiben.

Der grundlegende Protokollunterschied

HTTP ist Anfrage-Antwort, zustandslos und cachebar. HTTP/2 (RFC 7540) multiplext viele Anfragen auf einer TCP-Verbindung; HTTP/3 (RFC 9114) läuft über QUIC mit besserer Verlustwiederherstellung und Zero-RTT-Wiederaufnahme. WebSocket beginnt als HTTP-Upgrade-Anfrage nach RFC 6455 und schaltet dann die TCP-Verbindung in ein vollduplexes Frame-basiertes Protokoll um. Nach dem Upgrade können beide Seiten jederzeit Nachrichten senden. Dieser persistente bidirektionale Kanal ist leistungsfähig für interaktive Apps, aber architektonisch unhandlich für den Bulk-Dateitransfer, wo der Datenfluss überwiegend einseitig ist.

Durchsatz- und Latenz-Benchmarks

Auf einer Gigabit-Verbindung zwischen einem Tokyo-Client und einem US-East-Server zeigen typische Benchmarks: HTTP/1.1 Single-PUT bei ungefähr 40 bis 80 Mbps wegen TCP-Window-Scaling-Grenzen, HTTP/2 Multipart (8 parallele Streams, 8-MB-Teile) bei 400 bis 800 Mbps, HTTP/3 über QUIC bei Paketverlust um 10 bis 30 Prozent besser, und WebSocket mit binären Frames bei 200 bis 500 Mbps, begrenzt durch Single-Connection-Flusskontrolle. Das Muster wiederholt sich über Entfernungen hinweg. WebSocket ist nicht schneller – weil es immer noch TCP darunter hat – aber es nutzt die Verbindung weniger effizient als parallele HTTP-Anfragen.

Chunking und fortsetzbare Uploads

HTTP hat gut definierte Chunk-Upload-Standards. Das tus.io-Protokoll verwendet HTTP PATCH mit Upload-Offset-Headern. S3 Multipart Upload verwendet UploadPart mit Teilnummern und ETags. Beide überstehen Netzwerkunterbrechungen, starten ab dem letzten erfolgreichen Chunk neu und funktionieren über Client-Neustarts hinweg dank IndexedDB-persistiertem Zustand. WebSocket-Chunking ist ad-hoc: Sie definieren Ihr eigenes Framing, Sequenznummern und Bestätigungen. Jedes Team erfindet seine eigene Resume-Logik neu – in der Regel schlechter als die kampferprobten HTTP-Optionen. SocketIO, Primus und benutzerdefinierte Protokolle erfinden dasselbe Rad jeweils mit subtilen Bugs.

CDN- und Edge-Kompatibilität

CDNs wie Cloudflare, CloudFront, Fastly und Akamai cachen HTTP-Antworten an Edge-PoPs und halbieren oft Download-Zeiten weltweit. GET-Anfragen für statische Objekte können per URL oder presignierter URL gecacht werden. WebSocket-Datenverkehr passiert CDNs typischerweise, wird aber nicht gecacht, und viele Enterprise-Proxies deaktivieren oder drosseln WebSocket-Upgrades. Unternehmensnetze mit abfangenden TLS-Proxies brechen WebSocket manchmal vollständig. Allein das ist genug Grund, HTTP zu bevorzugen: Cloudflares 300+ PoPs machen nahegelegene Downloads für HTTP dramatisch schneller, bieten aber wenig für WebSocket-Payloads.

Serverseitige Ressourcennutzung

HTTP-Server verarbeiten Tausende gleichzeitiger Verbindungen mit minimalem Speicher, weil Anfragen kurzlebig sind. Nginx, Caddy und Gos net/http unterstützen 10.000+ gleichzeitige Verbindungen pro Knoten mit bescheidenem RAM. Jede WebSocket-Verbindung ist langlebig und hält einen TCP-Socket, einen Read-Buffer, einen Write-Buffer und oft Anwendungszustand. Bei Scale brauchen WebSocket-Flotten sorgfältige Abstimmung von ulimit, TCP-Keepalive und Speicher pro Verbindung. Kubernetes-Deployments stoßen auf Probleme mit WebSocket-Sticky-Sessions und Graceful Shutdown bei Rolling Deploys. Für einen Übertragungsdienst, der Bursts kurzer Uploads verarbeitet, ist das HTTP-Modell deutlich weniger schmerzhaft.

Presignierte URLs und direkte Uploads zum Speicher

Das Killer-Feature für HTTP bei der Dateiübertragung sind presignierte URLs. Ihre App generiert eine signierte URL, die direkt auf S3, R2 oder GCS zeigt, und der Client lädt direkt zum Objektspeicher hoch. Ihre App-Server berühren die Bytes nie. Keine Proxy-Bandbreite, kein Speicherdruck, keine Datei-I/O. WebSocket hat kein Äquivalent. Um WebSocket für Uploads zu verwenden, proxyen Sie typischerweise durch Ihren App-Server, der dann zum Speicher schreibt – das verdoppelt die Bandbreitenkosten und fügt Latenz hinzu. Ein 10-GB-Upload über eine WebSocket-zu-App-zu-S3-Pipeline verwendet 20 GB Server-Bandbreite; direkte HTTP-Uploads zu S3 nutzen Ihre Server-Bandbreite nur für kleine Metadaten-Aufrufe.

Wann WebSocket tatsächlich hilft

WebSocket passt gut zu datei-angrenzenden Workflows. Echtzeit-Upload-Fortschrittsbenachrichtigungen über Tabs oder Geräte: WebSocket-Broadcasts werden sofort zugestellt. Kollaborative Dateibearbeitung: yjs, Automerge und ähnliche CRDT-Bibliotheken verwenden WebSocket für kleine Delta-Nachrichten, während die tatsächlichen großen Assets über HTTP übertragen werden. Live-Signalisierung für WebRTC-Peer-to-Peer-Übertragungen: WebSocket ist der Standard-Signalisierungstransport, bevor P2P-Datenkanäle geöffnet werden. Server-gesendete Benachrichtigungen, dass ein Übertragungs-Empfänger eine Datei heruntergeladen hat: WebSocket ermöglicht sofortige Benachrichtigung des Senders ohne Polling. Das Muster lautet: WebSocket für Ereignisse, HTTP für Bytes.

HTTP/2 und HTTP/3 Vorteile

HTTP/2 (RFC 7540) und HTTP/3 (RFC 9114) schließen die meisten Lücken, die WebSocket früher ausnutzte. HTTP/2 multiplext mehrere Anfragen über eine TCP-Verbindung und beseitigt das 6-Verbindungen-pro-Origin-Limit. Server Push lässt Server Ressourcen proaktiv senden, was Round-Trips reduziert. HTTP/3 läuft über QUIC, das Paketverlust pro Stream behandelt statt die gesamte Verbindung zu blockieren – entscheidend auf verlustbehafteten Mobilfunknetzen. Server-Sent Events (EventSource) bieten eine einseitige Server-zu-Client-Push über HTTP, einfacher als WebSocket, wenn nur der Server pushen muss.

Sicherheit und Origin-Kontrollen

HTTPs Sicherheitsgeschichte ist ausgereift. CORS (Cross-Origin Resource Sharing) kontrolliert, welche Origins hochladen oder herunterladen können. CSP (Content Security Policy) beschränkt, woher Clients abrufen können. TLS 1.3 nach RFC 8446 sichert den Transport. Presignierte URLs enthalten HMAC-Signaturen, um Manipulation zu verhindern, und können auf genaue Objektschlüssel mit Ablauf begrenzt werden. WebSocket hat schwächere Origin-Kontrollen. Der Origin-Header kann von Nicht-Browser-Clients gefälscht werden. Viele WebSocket-Server validieren den Origin nicht und sind anfällig für Cross-Site-WebSocket-Hijacking-Angriffe. Äquivalente Schutzmaßnahmen zu implementieren erfordert sorgfältige Token-Validierung auf jedem Frame.

Wann jedes gewinnt

| Kriterium | HTTP | WebSocket | |---|---|---| | Große Datei-Uploads/Downloads | Gewinnt (Multipart, presignierte URLs, CDN) | Verliert (Single-Stream, kein Caching) | | Echtzeit-bidirektionale Nachrichten | Verliert (Polling ist verschwenderisch) | Gewinnt (natives Full-Duplex) | | CDN-Kompatibilität | Gewinnt (globales Edge-Caching) | Verliert (selten gecacht) | | Server-Ressourcen bei Scale | Gewinnt (zustandslos, kurze Verbindungen) | Verliert (langlebig, RAM pro Verbindung) | | Enterprise-Proxy-Kompatibilität | Gewinnt (Standard-HTTP) | Verliert (Proxy blockiert oft Upgrade) | | Fortsetzbare Uploads | Gewinnt (tus.io, S3 Multipart) | Ad-hoc (DIY erforderlich) |

Für einen Dateiübertragungsdienst wie HexaTransfer ist HTTP plus Chunked-Multipart plus direkte S3-Uploads die richtige Architektur – mit optionalem WebSocket für Live-Fortschritt oder empfänger-benachrichtigte Ereignisse darüber.

Kostenlos ausprobieren auf hexatransfer.com — kein Konto erforderlich, bis zu 10 GB.