WebSocket

Websocket
Websocket connection.png
Ein Diagramm, das eine Verbindung mit WebSocket beschreibt
Internationaler Standard RFC 6455
Entwickelt von Ietf
Industrie Informatik
Anschlusstyp TCP
Webseite Offizielle Website

Websocket ist ein Computer KommunikationsprotokollBereitstellung Vollduplex Kommunikationskanäle über einem einzigen TCP Verbindung. Das Websocket -Protokoll wurde durch die standardisiert Ietf wie RFC 6455 Im Jahr 2011. Die aktuelle API -Spezifikation, mit der Webanwendungen dieses Protokoll verwenden können Websockets.[1] Es ist ein lebendiger Standard, der von der gepflegt wird Waswg und ein Nachfolger zu Die Websocket -API von dem W3c.[2]

Websocket unterscheidet sich von Http. Beide Protokolle befinden sich bei Schicht 7 in dem OSI -Modell und abhängig von TCP in Schicht 4. Obwohl sie unterschiedlich sind, RFC 6455 gibt an, dass WebSocket "so konzipiert ist, dass sie über HTTP -Ports 443 und 80 arbeiten und HTTP -Proxies und -Intermediäre unterstützen", wodurch es mit HTTP kompatibel ist. Um Kompatibilität zu erreichen, das Websocket Handschlag verwendet die HTTP -Upgrade -Header[3] Um das HTTP -Protokoll zum WebSocket -Protokoll zu ändern.

Das WebSocket -Protokoll ermöglicht die Interaktion zwischen a Webbrowser (oder eine andere Clientanwendung) und a Webserver mit niedrigerem Overhead als halbe Duplexalternativen wie HTTP UmfragenErleichterung der Echtzeit-Datenübertragung vom und zum Server. Dies wird ermöglicht, indem der Server einen standardisierten Weg bereitstellt, um Inhalte an den Client zu senden, ohne zuerst vom Client angefordert zu werden, und die Übergabe von Nachrichten während der Öffnung der Verbindung hin und her übergeben zu lassen. Auf diese Weise kann zwischen dem Client und dem Server ein wechselseitiges kontinuierliches Gespräch stattfinden. Die Kommunikation wird normalerweise über TCP durchgeführt Hafen Nummer 443 (oder 80 bei ungesicherten Verbindungen), was für Umgebungen von Vorteil ist, die nicht-Web-Internetverbindungen mit a blockieren Firewall. Ähnliche Zwei-Wege-Browser-Server-Kommunikation wurde auf nicht standardisierte Weise mit Stopgap Komet oder Adobe Flash Player.[4]

Die meisten Browser unterstützen das Protokoll, einschließlich Google Chrome, Feuerfuchs, Microsoft Edge, Internet Explorer, Safari und Oper.[5]

Im Gegensatz zu HTTP bietet WebSocket eine Full-Duplex-Kommunikation.[6][7] Darüber hinaus ermöglicht WebSocket über TCP -Nachrichten Streams. Allein TCP befasst sich mit Streams von Bytes ohne inhärentes Konzept einer Nachricht. Vor WebSocket war die Full-Duplex-Kommunikation von Port 80 mit Verwendung erreichbar Komet Kanäle; Die Comet -Implementierung ist jedoch nicht trivial, und aufgrund des TCP -Handshakes und des HTTP -Header -Overheads ist es für kleine Nachrichten ineffizient. Das WebSocket -Protokoll zielt darauf ab, diese Probleme zu lösen, ohne die Sicherheitsannahmen des Web zu beeinträchtigen.

Die WebSocket -Protokollspezifikation definiert WS (Websocket) und WSS (Websocket sicher) als zwei neue Einheitliche Ressourcenkennung (URI) Schemata[8] die für unverschlüsselte bzw. verschlüsselte Verbindungen verwendet werden. Abgesehen vom Namen des Schemas und Fragment (d.h. # wird nicht unterstützt), der Rest der URI -Komponenten wird definiert, um sie zu verwenden URI Generische Syntax.[9]

Mithilfe von Browser -Entwickler -Tools können Entwickler sowohl den WebSocket -Handshake als auch die WebSocket -Frames inspizieren.[10]

Geschichte

Websocket wurde zuerst als tcpconnection in der bezeichnet HTML5 Spezifikation als Platzhalter für eine TCP-basierte Socket-API.[11] Im Juni 2008 wurde eine Reihe von Diskussionen von geleitet von Michael Carter Dies führte zu der ersten Version des als Websocket bekannten Protokolls.[12]

Der Name "Websocket" wurde von geprägt von Ian Hickson und Michael Carter kurz danach durch Zusammenarbeit im #Whatwg IRC -Chatraum,[13] und anschließend zur Aufnahme in die HTML5 -Spezifikation von Ian Hickson verfasst. Im Dezember 2009 war Google Chrome 4 der erste Browser, der die vollständige Unterstützung für den Standard versendete, wobei WebSocket standardmäßig aktiviert war.[14] Die Entwicklung des Websocket -Protokolls wurde anschließend aus dem W3C und bewegt Waswg Gruppe im IETF im Februar 2010 und für zwei Überarbeitungen unter Ian Hickson verfasst.[15]

Nachdem das Protokoll versendet und standardmäßig in mehreren Browsern aktiviert wurde, ist die RFC 6455 wurde im Dezember 2011 unter Ian Fette abgeschlossen.

RFC 7692 eingeführte Komprimierungserweiterung auf WebSocket mit dem Deflate Algorithmus pro Message.

Browser -Implementierung

Eine sichere Version des WebSocket -Protokolls ist in Firefox 6 implementiert.[16] Safari 6, Google Chrome 14,[17] Oper 12.10 und Internet Explorer 10.[18] Ein detaillierter Protokoll -Testsuite -Bericht[19] Listet die Konformität dieser Browser mit bestimmten Protokollaspekten auf.

Eine ältere, weniger sichere Version des Protokolls wurde in Opera 11 und implementiert Safari 5 sowie die mobile Version von Safari in iOS 4.2.[20] Der Blackberry -Browser in OS7 implementiert Websockets.[21] Aufgrund von Schwachstellen wurde es in Firefox 4 und 5 deaktiviert.[22] und Opera 11.[23]

Implementierungsstatus
Protokoll, Version Datum des Entwurfs Internet Explorer Feuerfuchs[24] (PC) Firefox (Android) Chrom (PC, Mobile) Safari (Mac, iOS) Opera (PC, Mobile) Android -Browser
Hixie-75 4. Februar 2010 4 5.0.0
Hixie-76
Hybi-00 		6. Mai 2010
23. Mai 2010		 4.0 (deaktiviert) 6 5.0.1 11.00 (deaktiviert)
Hybi-07, v7 22. April 2011 6[25][a]
Hybi-10, v8 11. Juli 2011 7[27][a] 7 14[28]
RFC 6455, v13 Dezember 2011 10[29] 11 11 16[30] 6 12.10[31] 4.4

Beispiel für JavaScript -Client 

// Erstellt ein neues WebSocket -Objekt mit einem WSS -URI als Parameter Const Steckdose = Neu Websocket('WSS: //game.example.com/ws/updates' '); // gefeuert, wenn eine Verbindung mit einem Websocket geöffnet wird Steckdose.Onopen = Funktion () {  setInterval(Funktion() {  wenn (Steckdose.bufferedAmount == 0)  Steckdose.senden(Getupdatedata());  }, 50); }; // gefeuert, wenn Daten über ein WebSocket empfangen werden Steckdose.OnMessage = Funktion(Veranstaltung) {  HandleUpdatedata(Veranstaltung.Daten); }; // gefeuert, wenn eine Verbindung mit einem Websocket geschlossen ist Steckdose.Onclose = Funktion(Veranstaltung) {  Onsocketclose(Veranstaltung); }; // gefeuert, wenn eine Verbindung mit einem Websocket aufgrund eines Fehlers geschlossen wurde Steckdose.onError = Funktion(Veranstaltung) {  Onsocketerror(Veranstaltung); };

Webserver -Implementierung

Nginx unterstützt Websockets seit 2013, implementiert in Version 1.3.13 [32] einschließlich der Handlung als Reverse Proxy und Lastenausgleicher von Websocket -Anwendungen.[33]

Apache HTTP Server unterstützt Websockets seit Juli 2013, implementiert in Version 2.4.5 [34][35]

Internetinformationsdienste Unterstützung für Websockets in Version 8 hinzugefügt, die mit veröffentlicht wurde Windows Server 2012.[36]

LightTpd hat WebSockets seit 2017 unterstützt, implementiert in Version 1.4.46.[37] LightTPD mod_proxy kann als Reverse Proxy und Balancer von WebSocket -Anwendungen laden. LightTPD mod_wstunnel kann WebSocket -Tunnel konstruieren, um beliebige Daten zu übertragen, einschließlich in JSON Format zu einer Backend -Anwendung.

Tempesta FW unterstützt WebSockets für HTTP/1.1- und HTTPS -Verbindungen seit 2022.[38] Websockets über http/2 von RFC 8441 wurden von den Entwicklern als nicht weit genug eingesetzt und nicht implementiert.

Protokollhandschlag

Um eine WebSocket -Verbindung herzustellen, sendet der Client eine WebSocket -Handshake -Anforderung, für die der Server eine WebSocket -Handshake -Antwort zurückgibt, wie im folgenden Beispiel gezeigt.[39]

Kundenanfrage (genau wie in Httpjede Linie endet mit \ r \ n und am Ende muss es eine extra leere Linie geben):

ERHALTEN /Plaudern Http/1.1 Gastgeber: server.example.com Aktualisierung: Websocket Verbindung: Aktualisierung Sec-Websocket-Key: x3JJHMBDL1EZLKH9GBHXDW == Sec-Websocket-Protokoll: Chat, Superchat Sec-Websocket-Version: 13 Herkunft: http://example.com

Serverantwort:

Http/1.1 101 Protokolle Schalten Aktualisierung: Websocket Verbindung: Aktualisierung Sec-Websocket-Akzept: Hsmrc0Smlyukagmm5OPPG2HAGWK = Sec-Websocket-Protokoll: Plaudern

Der Handshake beginnt mit einer HTTP -Anforderung/-Ronaktion, sodass Server HTTP -Verbindungen sowie WebSocket -Verbindungen auf demselben Port verarbeiten können. Sobald die Verbindung hergestellt ist, wechselt die Kommunikation zu einem bidirektionalen binären Protokoll, das dem HTTP -Protokoll nicht entspricht.

Zusätzlich zu Aktualisierung Header, der Kunde sendet a Sec-Websocket-Key Header enthalten Basis64-Codierte zufällige Bytes, und der Server antwortet mit a Hash des Schlüssels in der Sec-Websocket-Akzept Header. Dies soll a verhindern zwischengespeichert Proxy Aus dem Senden eines früheren Websocket-Gesprächs,[40] und bietet keine Authentifizierung, Privatsphäre oder Integrität. Die Hashing -Funktion findet die feste Zeichenfolge an 258AEFA5-E914-47DA-95CA-C5AB0DC85B11 (a Uuid) zum Wert von Sec-Websocket-Key Kopfzeile (der nicht von Basis 64 dekodiert ist) anwendet die SHA-1 Hashing -Funktion und codiert das Ergebnis mit Base64.[41]

Der RFC6455 erfordert, dass der Schlüssel ein Nonce sein muss, der aus einem zufällig ausgewählten 16-Byte-Wert besteht, der base 64-codiert wurde.[42] Das sind 24 Bytes in Basis64 (mit den letzten beiden Bytes zu sein ==). Obwohl einige entspannte HTTP-Server kürzere Schlüssel zulassen, lehnen viele moderne HTTP-Server die Anforderung mit Fehler "Ungültige sec-Webet-Key-Header" ab.

Sobald die Verbindung hergestellt ist Vollduplex Modus. Die Daten sind minimal gerahmt, mit einem kleinen Kopfball, gefolgt von Nutzlast.[43] WebSocket -Übertragungen werden als "Nachrichten" beschrieben, wobei eine einzige Nachricht optional über mehrere Datenrahmen aufgeteilt werden kann. Dies kann das Senden von Nachrichten ermöglichen, bei denen die Erstdaten verfügbar sind, aber die vollständige Länge der Nachricht ist unbekannt (sie sendet einen Datenrahmen nach dem anderen, bis das Ende mit dem Flossenbit erreicht und begangen wird). Mit Erweiterungen des Protokolls kann dies auch zum gleichzeitigen Multiplexen mehrerer Streams verwendet werden (zum Beispiel, um die Monopolisierung einer Steckdose für eine einzige große Nutzlast zu vermeiden).[44]

Sicherheitsüberlegungen

Im Gegensatz zu regelmäßigen Cross-Domain-HTTP-Anfragen werden WebSocket-Anfragen nicht durch die eingeschränkt gleichorientierte Politik. Daher müssen WebSocket-Server den "Ursprungs" -Header gegen die erwarteten Ursprünge während des Verbindungsbetriebs validieren, um die grenzüberschreitenden Websocket-Hijacking-Angriffe zu vermeiden (ähnlich wie Cross-Site-Anfragefälschung), was möglich sein könnte, wenn die Verbindung mit authentifiziert ist Kekse oder HTTP -Authentifizierung. Es ist besser, Token oder ähnliche Schutzmechanismen zu verwenden, um die WebSocket -Verbindung zu authentifizieren, wenn sensible (private) Daten über das WebSocket übertragen werden.[45] Ein lebendes Beispiel für Verwundbarkeit wurde 2020 in Form von Kabelspulen.

Proxy -Traversal

WebSocket -Protokoll -Client -Implementierungen versuchen zu erkennen, ob die User-Agent ist so konfiguriert, dass sie einen Proxy verwenden, wenn Sie eine Verbindung zu dem Zielhost und Port und Port herstellen, und wenn dies der Fall ist, verwendet es HTTP Connect Methode zur Einrichtung eines anhaltenden Tunnels.

Während das WebSocket-Protokoll selbst Proxy-Server und Firewalls nicht bewusst ist, verfügt es über einen HTTP-kompatiblen Handshake, sodass HTTP-Server ihre Standard-HTTP- und HTTPS-Ports (80 bzw. 443) mit einem WebSocket-Gateway oder Server teilen können. Das WebSocket -Protokoll definiert ein Präfix WS: // und WSS: //, um eine WebSocket bzw. eine WebSocket -Verbindung anzugeben. Beide Programme verwenden eine HTTP -Upgrade -Mechanismus Upgrade auf das WebSocket -Protokoll. Einige Proxy -Server sind transparent und funktionieren gut mit Websocket. Andere verhindern, dass Websocket korrekt funktioniert, was dazu führt, dass die Verbindung fehlschlägt. In einigen Fällen ist möglicherweise eine zusätzliche Proxy-Server-Konfiguration erforderlich, und bestimmte Proxy-Server müssen möglicherweise aktualisiert werden, um WebSocket zu unterstützen.

Wenn der unverschlüsselte WebSocket -Verkehr über einen expliziten oder transparenten Proxy -Server ohne WebSockets -Unterstützung fließt, wird die Verbindung wahrscheinlich fehlschlagen.[46]

Wenn eine verschlüsselte WebSocket -Verbindung verwendet wird, dann die Verwendung von Transportschichtsicherheit (TLS) In der WebSocket Secure -Verbindung stellt sicher HTTP Connect Der Befehl wird ausgestellt, wenn der Browser für einen expliziten Proxy -Server konfiguriert ist. Hierbei werden ein Tunnel eingerichtet, der über den HTTP-Proxy zwischen dem WebSocket Secure-Client und dem WebSocket-Server ein niedrigem Niveau-End-to-End-TCP-Kommunikation bietet. Bei transparenten Proxy -Servern ist sich der Browser des Proxy -Servers nicht bewusst, also nein, also nein HTTP Connect wird gesendet. Da der Drahtverkehr jedoch verschlüsselt ist, können intermediäre transparente Proxy -Server einfach den verschlüsselten Datenverkehr durchlaufen. Daher besteht eine viel bessere Wahrscheinlichkeit, dass die Websocket -Verbindung erfolgreich ist, wenn WebSocket Secure verwendet wird. Die Verwendung von Verschlüsselung ist nicht frei von Ressourcenkosten, bietet aber häufig die höchste Erfolgsquote, da sie durch einen sicheren Tunnel reisen würde.

Ein Entwurf der Mitte 2010 (Version Hixie-76) hat die Kompatibilität mit gebrochen reverse proxies und Gateways durch Einbeziehung von acht Bytes wichtiger Daten nach den Headern, aber keine Werbung für diese Daten in a Inhaltslänge: 8 Header.[47] Diese Daten wurden nicht von allen Zwischenprodukten weitergeleitet, was zu einem Protokollversagen führen könnte. Neuere Entwürfe (z. B. Hybi-09[48]) Fügen Sie die Schlüsseldaten in a ein Sec-Websocket-Key Header, dieses Problem lösen.

Siehe auch

Anmerkungen

  1. ^ a b Gecko-basierte Browserversionen 6–10 Implementieren Sie das WebSocket-Objekt als "Mozwebsocket",[26] Erfordernder zusätzlicher Code, um in den vorhandenen WebSocket-fähigen Code integriert zu werden.

Verweise

  1. ^ "Websockets Standard". Websockets.spec.whatwg.org. Abgerufen 2022-05-16.
  2. ^ "Die Websocket -API". www.w3.org. Abgerufen 2022-05-16.
  3. ^ Ian Fette; Alexey Melnikov (Dezember 2011). "Beziehung zu TCP und HTTP". RFC 6455 Das WebSocket -Protokoll. Ietf. Sek. 1.7. doi:10.17487/rfc6455. RFC 6455.
  4. ^ "Adobe Flash Platform - Sockets". help.adobe.com. Abgerufen 2021-07-28. TCP -Verbindungen erfordern einen "Client" und einen "Server". Flash Player kann Client -Sockets erstellen.{{}}: CS1 Wartung: URL-Status (Link)
  5. ^ "Websockets - Lista Web API". Mozilla Developer Network. Abgerufen 2021-07-28.
  6. ^ "Glossar: Websockets". Mozilla Developer Network. 2015.
  7. ^ "HTML5 WebSocket - Ein Quantensprung in der Skalierbarkeit für das Web". www.websocket.org.
  8. ^ Graham Klyne, hrsg. (2011-11-14). "Iana Uniform Resource Identifer (URI) -Programm". Internet zugewiesene Zahlen Autorität. Abgerufen 2011-12-10.
  9. ^ Ian Fette; Alexey Melnikov (Dezember 2011). "Websocket uris". RFC 6455 Das WebSocket -Protokoll. Ietf. Sek. 3. doi:10.17487/rfc6455. RFC 6455.
  10. ^ Wang, Vanessa; Salim, Frank; Moskovits, Peter (Februar 2013). "Anhang A: WebSocket -Frame -Inspektion mit Google Chrome Developer Tools". Die endgültige Anleitung zu HTML5 WebSocket. Apress. ISBN 978-1-4302-4740-1. Abgerufen 7. April 2013.
  11. ^ "HTML 5". www.w3.org. Abgerufen 2016-04-17.
  12. ^ "[Whatwg] TCPConnection-Feedback von Michael Carter am 2008-06-18 (Whatwg.org ab Juni 2008)". lists.w3.org. Abgerufen 2016-04-17.
  13. ^ "IRC -Protokolle: Freenode / #Whatwg / 20080618". krijnhoetmer.nl. Abgerufen 2016-04-18.
  14. ^ "Web -Sockets jetzt in Google Chrome verfügbar". Chrom -Blog. Abgerufen 2016-04-17.
  15. ^ , Ian Hickson (6 May 2010). "Das Websocket -Protokoll". Tools.ietf.org. Abgerufen 2016-04-17.
  16. ^ Dirkjan Ochtman (27. Mai 2011). "WebSocket in Firefox 6 aktiviert". Mozilla.org. Abgerufen 2011-06-30.
  17. ^ "Chromium -Webplattformstatus". Abgerufen 2011-08-03.
  18. ^ "Websockets (Windows)". Microsoft. 2012-09-28. Abgerufen 2012-11-07.
  19. ^ "WebSockets Protokoll -Testbericht". Tavendo.de. 2011-10-27. Abgerufen 2011-12-10.
  20. ^ Katie Marsal (23. November 2010). "Apple fügt Accelerometer hinzu, WebSockets -Unterstützung für Safari in iOS 4.2". AppleInsider.com. Abgerufen 2011-05-09.
  21. ^ "Web Sockets API". Brombeere. Archiviert von das Original am 10. Juni 2011. Abgerufen 8. Juli 2011.
  22. ^ Chris Heilmann (8. Dezember 2010). "Websocket in Firefox 4 deaktiviert". Hacks.mozilla.org. Abgerufen 2011-05-09.
  23. ^ Aleksander AAS (10. Dezember 2010). "In Bezug auf Websocket". Mein Oper -Blog. Archiviert von das Original Am 2010-12-15. Abgerufen 2011-05-09.
  24. ^ "Websockets (Unterstützung in Firefox)". Entwickler.mozilla.org. Mozilla Foundation. 2011-09-30. Abgerufen 2011-12-10.
  25. ^ "Bug 640003 - Websockets - Upgrade auf IETF -06". Mozilla Foundation. 2011-03-08. Abgerufen 2011-12-10.
  26. ^ "Websockets - Mdn". Entwickler.mozilla.org. Mozilla Foundation. 2011-09-30. Abgerufen 2011-12-10.
  27. ^ "Bug 640003 - Websockets - Upgrade auf IETF -07 (Kommentar 91)". Mozilla Foundation. 2011-07-22.
  28. ^ "Chromwanzen 64470". code.google.com. 2010-11-25. Abgerufen 2011-12-10.
  29. ^ "Websockets in der Windows Consumer Preview". IE Engineering Team. Microsoft. 2012-03-19. Abgerufen 2012-07-23.
  30. ^ "Webkit Changeset 97247: WebSocket: Aktualisieren Sie das WebSocket-Protokoll auf Hybi-17". Trac.Webkit.org. Abgerufen 2011-12-10.
  31. ^ "Eine heiße Oper 12.50 Sommer-Snapshot". Opera Developer News. 2012-08-03. Archiviert von das Original Am 2012-08-05. Abgerufen 2012-08-03.
  32. ^ "Archivierte Kopie". nginx.org. Archiviert von das Original am 17. Juli 2012. Abgerufen 3. Februar 2022.{{}}: CS1 Wartung: Archiviertes Kopie als Titel (Link)
  33. ^ "Verwenden von Nginx als Websocket -Proxy". Nginx. 17. Mai 2014.
  34. ^ "Überblick über neue Funktionen in Apache HTTP Server 2.4". Apache.
  35. ^ "Changelog Apache 2.4". Apache Lounge.
  36. ^ "IIS 8.0 WebSocket -Protokollunterstützung". Microsoft Docs. 28. November 2012. Abgerufen 2020-02-18.
  37. ^ "Release -1 4 46 - LightTPD - Lighty Labs".
  38. ^ "Tempesta FW Umgang mit Kunden Websockets". Tempesta FW Wiki. Abgerufen 6. Juni 2022.
  39. ^ Ian Fette; Alexey Melnikov (Dezember 2011). "Protokollübersicht". RFC 6455 Das WebSocket -Protokoll. Ietf. Sek. 1.2. doi:10.17487/rfc6455. RFC 6455.
  40. ^ "Hauptziel des Websocket -Protokolls". Ietf. Abgerufen 25. Juli 2015. Die Berechnung [...] soll verhindern, dass ein zwischengespeicherter Vermittler einen WS-Client mit einer zwischengespeicherten WS-Server-Antwort ohne tatsächliche Wechselwirkung mit dem WS-Server bereitstellt.
  41. ^ Ian Fette; Alexey Melnikov (Dezember 2011). "Handshake öffnen". RFC 6455 Das WebSocket -Protokoll. Ietf. p. 8. Sek. 1.3. doi:10.17487/rfc6455. RFC 6455.
  42. ^ Ian Fette; Alexey Melnikov (Dezember 2011). "Handshake öffnen". RFC 6455 Das WebSocket -Protokoll. Ietf. p. 21. Sek. 1.3. doi:10.17487/rfc6455. RFC 6455.
  43. ^ Ian Fette; Alexey Melnikov (Dezember 2011). "Basisrahmenprotokoll". RFC 6455 Das WebSocket -Protokoll. Ietf. Sek. 5.2. doi:10.17487/rfc6455. RFC 6455.
  44. ^ John A. Tamplin; Takeshi Yoshino (2013). Eine Multiplexing -Erweiterung für Websockets. Ietf. I-D Draft-ITF-Hybi-Websocket-Multiplexing.
  45. ^ Christian Schneider (31. August 2013). "Cross-Site WebSocket Hijacking (CSWSH)". Webanwendungssicherheitsblog.
  46. ^ Peter Lubbers (16. März 2010). "Wie HTML5 -Web -Sockets mit Proxy -Servern interagieren". Infoq.com. C4Media Inc.. Abgerufen 2011-12-10.
  47. ^ Willy Tarreau (2010-07-06). "WebSocket -76 ist mit HTTP -Reverse -Proxies unvereinbar". ietf.org (Email). Internettechnik-Arbeitsgruppe. Abgerufen 2011-12-10.
  48. ^ Ian Fette (13. Juni 2011). "Sec-Websocket-Key". Das WebSocket-Protokoll, Entwurf von Hybi-09. Sek. 11.4. Abgerufen 15. Juni, 2011.

Externe Links