https://a.storyblok.com/f/270183/1368x665/6d1e177f2d/26apr_dev-blog_websockets-vs-http_1368x665_v1.jpg

Was sind WebSockets und wie unterscheiden sie sich von HTTP?

Zuletzt aktualisiert am April 30, 2026

Lesedauer: 8 Minuten

Kommunikation in Echtzeit ist für moderne Applications unverzichtbar geworden. Von Live-Chats über kollaborative Editoren bis hin zu Benachrichtigungssystemen sind sofortige Aktualisierungen im Browser ohne Seitenaktualisierung so alltäglich geworden, dass man leicht die Technologie übersieht, die dieses Kunststück möglich macht. Bei herkömmlichen HTTP-Anfrage-Antwort-Zyklen muss der Client eine Verbindung mit einem Server herstellen, und sobald eine Antwort eingegangen ist, wird diese Verbindung geschlossen - mit anderen Worten, sie ist zustandslos. Dies führt zu einer erhöhten Latenzzeit und einer ineffizienten Ressourcennutzung. Polling ist zwar eine Lösung, reicht aber immer noch nicht aus, um mit den technologischen Anforderungen des Live-Datenaustauschs über das Internet Schritt zu halten.

Dies ist der Ort, an dem WebSocket eine Lösung. WebSocket ist ein Kommunikationsprotokoll, das eine dauerhafte, bidirektionale Kommunikation zwischen einem Client und einem Server ermöglicht. WebSocket ermöglicht Funktionen wie Voice-Streaming, Messaging und die Verarbeitung von Live-Ereignissen in Vonage-Applikationen und verändert die Art und Weise, wie Entwickler alles von Tools für die Zusammenarbeit bis hin zu Live-Streaming-Anwendungen entwickeln.

In diesem Blog-Beitrag erfahren Sie, was WebSocket ist und wie es funktioniert, welche praktischen Anwendungen es gibt und wie WebSocket die Grundlage für den Live-Datenaustausch in modernen Web- und Mobilanwendungen bildet.

Wie WebSocket funktioniert

Eine der innovativsten Eigenschaften von WebSocket ist seine Kompatibilität mit HTTP. WebSocket verwendet den HTTP-Upgrade-Header, um die Protokolle von HTTP auf WebSocket umzuschalten und eine dauerhafte Verbindung zwischen Client und Server herzustellen, die es ihnen ermöglicht, kontinuierlich hin und her zu kommunizieren.

Der Händedruck

Der Übergang vom HTTP- zum WebSocket-Protokoll erfolgt während des ersten Handshakes zwischen Client und Server. Der Handshake vom Client sieht wie folgt aus:

GET /chat HTTP/1.1
        Host: server.example.com
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
        Origin: http://example.com
        Sec-WebSocket-Protocol: chat, superchat
        Sec-WebSocket-Version: 13

Beachten Sie, dass die Upgrade Kopfzeile angibt websocket.

Der Server antwortet mit dem folgenden Handshake:

HTTP/1.1 101 Switching Protocols
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
        Sec-WebSocket-Protocol: chat

Wenn der Handshake erfolgreich ist, kann der zweite Teil des WebSocket-Protokolls erfolgen.

Die Datenübertragung

Nach einem erfolgreichen Austausch von Handshakes wird eine Verbindung aufgebaut, die Vollduplex Interaktion zwischen einem Client und einem Server ermöglicht. Bei dieser Verbindung können der Client und der Server unabhängig voneinander Daten senden. Die Daten werden in "Nachrichten" gesendet, die durch ein bestimmtes binäres Rahmenprotokoll definiert sind.

Um mehr über die technischen Aspekte von WebSocket zu erfahren, lesen Sie den Request for Comments (RFC) für das Protokoll.

HTTP vs. WebSocket

Im Gegensatz zu HTTP bleibt bei WebSocket die Verbindung offen, so dass eine kontinuierliche Zwei-Wege-Kommunikation zwischen Client und Server stattfinden kann. Hier ein Vergleich von HTTP und WebSocket in Bezug auf die wichtigsten Merkmale:

Aspekt

HTTP

WebSocket

Verbindungsmodell

  • Anfrage/Antwort

  • Der Kunde initiiert jeden Austausch

  • Dauerhaft und bidirektional

  • Jede Seite kann jederzeit Nachrichten senden

Latenzzeit

  • Hohe Latenzzeit

  • Client muss nach jeder Anfrage auf die Antwort des Servers warten

  • Geringe Latenzzeit

  • Client und Server können sofort Nachrichten senden, ohne auf Anfragen oder Antworten zu warten

Datenfluss

  • Unidirektional

  • Bidirektional

Lebenszyklus der Verbindung

  • Zustandslos

  • Verbindung wird nach jeder Antwort geschlossen

  • Zustandsabhängig

  • Die Verbindung bleibt während der gesamten Dauer der Sitzung bestehen.

Sicherheit (Verschlüsselung)

  • HTTPS (TLS/SSL)

  • WSS (WebSocket Secure mit TLS/SSL)

Hafen

  • Anschluss 80 (HTTP) oder 443 (HTTPS)

  • Anschluss 80 (ws://) oder 443 (wss://)

Mit anderen Worten: Sie können sich den Unterschied zwischen HTTP und WebSocket wie folgt vorstellen:

Wenn Sie versuchen würden, mit einem Freund über das Telefon zu sprechen und dabei das HTTP-Protokoll zu imitieren, müssten Sie Ihren Freund anrufen, Ihr Freund müsste warten, bis Sie mit dem Sprechen fertig sind, um zu antworten, und Sie würden beide den Hörer auflegen. Um das Gespräch fortzusetzen, müssten Sie Ihren Freund erneut anrufen, er müsste warten, bis er antwortet, und Sie würden beide den Hörer auflegen. Außerdem würde sich Ihr Freund nicht mehr an das erinnern, was Sie in dem vorherigen Telefonat gesagt haben. Das ist keine gute Art, ein Gespräch in Echtzeit zu führen!

Mit WebSocket findet dieses metaphorische Gespräch über ein einziges Telefongespräch statt, bei dem Sie und Ihr Freund sich ausführlich unterhalten können, ohne zu warten, bis der andere fertig ist (auch wenn einer von Ihnen es als unhöflich empfinden könnte, unterbrochen zu werden), und jeder von Ihnen weiß, worüber der andere spricht. Auf diese Weise ermöglicht WebSocket eine flüssigere und natürlichere Konversation - sei es in einem Live-Chat, bei der Zusammenarbeit an einem Dokument, bei der Übertragung eines Live-Streams oder bei einem Multiplayer-Spiel.

WebSocket-Sicherheitsaspekte

Die bidirektionalen Echtzeit-Datenübertragungsmöglichkeiten von WebSocket sind Teil dessen, was das Protokoll so leistungsfähig, aber auch potenziell angreifbar macht. Wie jede andere Form der Netzwerkkommunikation ist auch WebSocket anfällig für Sicherheitsangriffe wie:

  • Man-in-the-Middle (MitM): Ein Angreifer fängt die Verbindung zwischen Client und Server ab, belauscht die Kommunikation und verändert die Daten.

  • Website-übergreifendes WebSocket-Hijacking: Bei dieser Art von Angriff wird die WebSocket-Implementierung selbst ausgenutzt, um unbefugten Zugriff zu ermöglichen und Daten zu stehlen.

  • Denial-of-Service (DoS): Dies geschieht, wenn der Server mit Verbindungsanfragen überflutet wird, so dass er nicht mehr reagiert und seine Ressourcen erschöpft.

Glücklicherweise gibt es Methoden zur Sicherung Ihrer WebSocket-Verbindungen:

  • Secure WebSocket verwenden wss://) zur Verschlüsselung von Daten, die zwischen einem Client und einem Server übertragen werden

  • Implementierung einer angemessenen Authentifizierung und Autorisierung mit Token wie JSON-Web-Tokens (JWT) um sicherzustellen, dass nur autorisierte Benutzer auf die WebSocket-Verbindung zugreifen

  • Validierung von Eingabe- und Ausgabedaten um Injektionsangriffe zu verhindern

  • Überprüfung der Herkunft die Kopfzeile der Handshake-Anfrage, um sicherzustellen, dass sie von einer vertrauenswürdigen Quelle stammt

  • Ratenbegrenzung um DoS-Angriffe zu verhindern und Ressourcen effektiv zu verwalten

  • Protokollierung und Überwachung des WebSocket-Verkehrs um ungewöhnliche Aktivitäten zu erkennen und bei potenziellen Sicherheitsbedrohungen in Echtzeit einzugreifen

Sehen wir uns in diesem Zusammenhang eine Beispielanwendung an, die die Vonage Voice API und die NCCO Connect Aktion verwendet, um eine WebSocket-Verbindung aufzubauen und zu authentifizieren.

Beispiel-Applikation: Sicheres Anrufer-Echo in Echtzeit

Diese Beispielanwendung verwendet die Voice API um einen eingehenden Anruf zu beantworten und dem Anrufer zu ermöglichen, ein Echo seiner eigenen Stimme zu hören. Sie nutzt die Leistungsfähigkeit einer WebSocket-Verbindung, die mit einer NCCO-Aktion erstellt und mit einem JWT authentifiziert wird.

Sie finden den vollständigen Code und README, um die App lokal auszuführen, in der Vonage Gemeinschaft auf GitHub.

Die App zeigt eine Stats-Webseite an, die die Anzahl der Pakete und Bytes anzeigt und veranschaulicht, wie die Daten (die Stimme des Anrufers) in Echtzeit bidirektional übertragen werden.

A screenshot of the stats web page showing an open connection and the amount of transmitted data. The packets and bytes received and sent are identical because the data being transmitted is an echo.A screenshot of the stats web page showing an open connection and the amount of transmitted data. The packets and bytes received and sent are identical because the data being transmitted is an echo.Sehen Sie sich das Repo auf GitHub um die Anwendung selbst auszuprobieren. Beachten Sie, dass Sie, um die Beispielanwendung durchgängig ausführen zu können, ein Vonage Account.

Herstellen einer sicheren WebSocket-Verbindung mit NCCO

A Objekt zur Anrufsteuerung (NCCO) verwendet JSON, um festzulegen, welche Aktionen die Voice API-Server durchführen, wenn der Webhook erreicht wird. Das folgende NCCO, das von dem /webhooks/answer Endpunkt zurückgegeben wird, der in der Beispielanwendung definiert ist, verwendet die connect Aktion zur Weiterleitung an einen websocket Typ und nicht an eine Telefonnummer oder einen SIP-Endpunkt. Dadurch wird ein roher Echtzeit-Audiostrom über eine WebSocket-Verbindung mit einer linearen PCM-Abtastrate von 24 kHz in hoher Qualität erzeugt:

    ncco = [
        {
            "action": "talk",
            "text": "We will now connect you to the echo server with advanced WebSocket features. Wait a moment then start speaking.",
        },
        {
            "action": "connect",
            "from": VONAGE_VIRTUAL_NUMBER,
            "endpoint": [
                {
                    "type": "websocket",
                    "uri": f"wss://{request.headers.get('host')}/socket",
                    "content-type": "audio/l16;rate=24000",  # 24 kHz audio
                    "headers": {"X-Custom-Header": "demo-value"},
                    # Authorization configuration
                    "authorization": {
                        "type": "vonage"  # Vonage will send JWT in Authorization header
                    },
                }
            ],
        },
    ]

Außerdem unterstützt der websocket Typ unterstützt einen authorization Header, der konfiguriert werden kann, um ein von Vonage bereitgestelltes JWT als signierten Webhook. Diese Header-Authentifizierungsoption ist Teil des anfänglichen Request-Handshake.

Das JWT wird hier vom Server validiert:

 # Get authorization header for authentication
    auth_header = websocket.headers.get("authorization", "")

    # Validate JWT if present
    if auth_header.startswith("Bearer "):
        token = auth_header.replace("Bearer ", "")
        print("JWT validation: ===> Valid JWT token received")
        verify_signature(token, VONAGE_SIGNATURE_SECRET)
        print(
            f"Valid signature: ===> token: {token} vs. signature secret: {VONAGE_SIGNATURE_SECRET}"
        )
        if not verify_signature(token, VONAGE_SIGNATURE_SECRET):
            print("JWT validation: ===> Invalid JWT token received")
            await websocket.close(code=1008, reason="Unauthorized")
            return

Dieser Validierungsschritt verhindert, dass nicht autorisierte Clients langlebige Verbindungen aufbauen. WebSockets sind langlebige Verbindungen, daher muss die Authentifizierung während des Handshakes erfolgen. Durch die Verifizierung der JWT-Signatur mit dem VONAGE_SIGNATURE_SECRETüberprüfen, stellen Sie sicher:

  • Die Anfrage stammte tatsächlich von Vonage

  • Die Nutzlast wurde nicht manipuliert.

  • Nicht autorisierte Kunden werden sofort abgewiesen

Schlägt die Validierung fehl, wird die Verbindung mit einer 1008 Richtlinienverletzunggeschlossen, wodurch eine weitere Interaktion verhindert wird.

Echtzeit-Audioverarbeitung über WebSockets

Sobald die Authentifizierung erfolgt ist, wird die Verbindung akzeptiert und die Verarbeitung von zwei Arten von Nachrichten beginnt:

  • Text-Rahmen: Verwendet für Steuerereignisse wie websocket:connected

  • Binäre Rahmen: Enthalten Audio-Rohdaten des Anrufs

In diesem Beispiel wird lediglich der Ton an den Anrufer zurückgesendet, aber genau hier würde sich normalerweise die Anwendungslogik befinden:

 if "text" in message:
                # Handle text messages (JSON commands/events)
                data = json.loads(message["text"])
                print(f"Received text: ===> {data}")

                # Handle special commands
                if data.get("event") == "websocket:connected":
                    print("WebSocket: ===> Connection established with Vonage")

            elif "bytes" in message:
                # Handle binary audio data
                audio_data = message["bytes"]
                active_connections[connection_id]["packets_received"] += 1
                active_connections[connection_id]["bytes_received"] += len(audio_data)

                # Echo audio back to caller
                await websocket.send_bytes(audio_data)
                active_connections[connection_id]["packets_sent"] += 1
                active_connections[connection_id]["bytes_sent"] += len(audio_data)

Da das NCCO das Audioformat definiert audio/l16;rate=24000), können Sie den Stream ohne zusätzliche Aushandlung zuverlässig verarbeiten oder umwandeln.

Warum dieses Muster wichtig ist

Während dieser Beispielcode nicht wirklich tun nicht viel, aber es bietet ein grundlegendes Muster für die Erstellung fortgeschrittener sicherer Streaming Voice Applications.

Sie können zum Beispiel den folgenden Codeblock erweitern, um die Logik für andere Arten von Befehlen und Ereignissen einzubeziehen. Sie könnten einen clear Befehl verwenden, wenn Sie die Wiedergabe unterbrechen müssen, um dynamisch auf einen Anrufer zu reagieren oder verwenden Sie ein notify Ereignis, um die Anwendungslogik zu synchronisieren, um die Aufnahme zu starten oder einen neuen Prompt abzuspielen, sobald der Ton endet:

                # Handle special commands
                if data.get("event") == "websocket:connected":
                    print("WebSocket: ===> Connection established with Vonage")

Erfahren Sie mehr darüber, wie Vonage WebSockets implementiert, indem Sie die die Dokumentation.

Zusammenfassung

WebSockets verändern die Art und Weise, wie wir über sofortige Aktualisierungen denken, grundlegend, indem sie dauerhafte, bidirektionale Verbindungen zwischen einem Client und einem Server ermöglichen. In diesem Blogbeitrag haben wir untersucht, wie diese Veränderung die Latenzzeit reduziert, die Effizienz verbessert und moderne Anwendungsfälle wie Live-Chat, Streaming und kollaborative Anwendungen ermöglicht.

Wir haben uns auch angeschaut, wie Vonage auf diesem Protokoll aufbaut und die Voice API und die NCCO connect Aktion aufbaut. Durch die Nutzung des websocket Endpunkts können Sie Live-Audio direkt in eine Anwendung streamen - in diesem Fall wird es an den Anrufer zurückgesendet.

Noch wichtiger ist, dass wir gezeigt haben, wie man diese langlebigen Verbindungen mit dem Vonage authorization Header zu sichern, der es dem Server ermöglicht, die WebSocket-Verbindung während des ersten Handshakes zu verifizieren und zu sichern.

Das Muster der NCCO-gesteuerten WebSocket-Verbindungen mit integrierter Authentifizierung bietet eine leistungsstarke und sichere Grundlage für die Entwicklung fortschrittlicher Spracherlebnisse - von KI-gesteuerten Assistenten bis hin zu Echtzeit-Audioverarbeitungspipelines.

Weitere Lektüre und Ressourcen

RCS Messaging mit Laravel, Livewire, Reverb und Echo: Erstellen Sie einen Echtzeit-RCS-Messenger mit Laravel, Livewire und Vonage - kein JavaScript erforderlich.

Haben Sie eine Frage oder möchten Sie uns mitteilen, was Sie gerade bauen?

Bleiben Sie auf dem Laufenden und halten Sie sich über die neuesten Nachrichten, Tipps und Veranstaltungen für Entwickler auf dem Laufenden.

Teilen Sie:

https://a.storyblok.com/f/270183/400x400/2c4345217d/liz-acosta.jpeg
Liz AcostaAdvokat für Entwickler

Liz Acosta ist Developer Advocate bei Vonage. Ihr Karriereweg von der Filmstudentin über die Marketingspezialistin und die Ingenieurin zur Developer Advocate mag zwar unkonventionell erscheinen, ist aber ziemlich typisch für Developer Relations! Liz liebt Pizza, Pflanzen, Möpse und Python.