Websockets, Webarbeiter, Dienstangestellte ... Diese Begriffe, die Sie möglicherweise beim Lesen oder Anhören begegnet sind. Vielleicht nicht alle, aber mindestens einer von ihnen. Selbst wenn Sie mit der Front-End-Entwicklung vertraut sind, besteht eine hohe Chance, dass Sie herausfinden müssen, was sie bedeuten. Oder du bist vielleicht wie ich, manchmal verwirrt sie. Diese Begriffe sehen sehr ähnlich und solide aus und sind leicht verwirrt.
Lassen Sie uns sie zusammen aufschlüsseln, um zwischen Websockets, Web -Mitarbeitern und Dienstangestellten zu unterscheiden. Anstatt tief in die Details einzugehen, eingehende Recherchen durchzuführen und jede selbst zu erleben-eher wie ein kleiner Assistent, damit Sie sie das nächste Mal sammeln können, wenn Sie es überprüfen müssen.
Wir werden mit einem erweiterten Überblick für schnelle Vergleiche und Vergleiche beginnen.
Websocket ist ein Zwei-Wege-Kommunikationsprotokoll. Betrachten Sie es als einen ständigen Anruf zwischen Ihnen und einem Freund, der nicht endet, es sei denn, eine der Parteien beschließt, aufzuhängen. Der einzige Unterschied besteht darin, dass Sie der Browser sind und Ihre Freunde der Server sind. Der Client sendet eine Anfrage an den Server, und der Server antwortet, indem er die Anfrage des Clients verarbeitet und umgekehrt.
Kommunikation basiert auf Ereignissen. Erstellen Sie ein WebSocket -Objekt und stellen Sie eine Verbindung zum Server her, und Nachrichten zwischen Servern auslösen Ereignisse zum Senden und Empfangen.
Dies bedeutet, dass wir beim Herstellen einer anfänglichen Verbindung eine Client-Server-Kommunikation haben, in der die Verbindung gestartet wird und bis zur Beendigung des Clients oder Servers, sie durch Senden eines Schlusss zu beenden. Dies macht Websockets ideal für Anwendungen, die eine kontinuierliche und direkte Kommunikation zwischen Kunden und Servern erfordern. Viele der Definitionen, die ich gesehen habe, listen Chat -Anwendungen als gemeinsame Anwendungsfälle an - Sie geben eine Nachricht ein, senden Sie sie an den Server, lösen ein Ereignis aus, der Server antwortet mit Daten, ohne den Server wiederholt zu pingen.
Betrachten Sie das folgende Szenario: Sie sind auf dem Weg nach draußen und beschließen, Google Maps zu öffnen. Möglicherweise wissen Sie bereits, wie Google Maps funktioniert. Wenn Sie jedoch nicht dies nicht tun, finden Sie Ihren Standort automatisch, sobald Sie eine Verbindung zur App herstellen und sie überall verfolgen. Es verwendet Echtzeit-Datenübertragung, um Ihren Standort zu verfolgen, solange diese Verbindung aktiv ist. Dies ist ein WebSocket, das eine anhaltende Zwei-Wege-Konversation zwischen dem Browser und dem Server festlegt, um die Daten auf dem neuesten Stand zu halten. Sportanwendungen mit Echtzeit-Ergebnissen verwenden möglicherweise auch WebSockets auf diese Weise.
Der größte Unterschied zwischen WebSockets und Webangestellten (und Service -Mitarbeitern, die wir später sehen werden) ist, dass sie direkten Zugriff auf die DOM haben. Während Webarbeiter (und Servicearbeiter) auf separaten Threads ausgeführt werden, sind Websockets Teil des Haupt -Threads, mit dem sie das DOM betreiben können.
Es gibt Tools und Dienste, mit denen WebSocket -Verbindungen hergestellt und verwaltet werden können, darunter: SocketCluster, Asyncapi, Cowboy, WebSocket King, Channels und Gorilla WebSocket. MDN verfügt über eine Run -Liste mit anderen Diensten.
Betrachten Sie eine Situation, in der Sie viele komplexe Berechnungen durchführen müssen und gleichzeitig das DOM ändern müssen. JavaScript ist eine einzelne Anwendung, die mehrere Skripte ausführt und die Benutzeroberfläche zerstören kann, die Sie ändern möchten, und die komplexen Berechnungen, die Sie durchführen.
Hier kommen Webarbeiter ins Spiel.
Web Workers ermöglicht es Skripten, in separaten Threads im Hintergrund auszuführen, um zu verhindern, dass Skripte sich gegenseitig im Haupt -Thread blockieren. Dies macht sie ideal, um die Leistung von Anwendungen zu verbessern, die viele Vorgänge erfordern, da diese Vorgänge auf separaten Threads im Hintergrund ausgeführt werden können, ohne die Darstellung der Benutzeroberfläche zu beeinflussen. Sie können jedoch nicht sehr gut auf DOMS zugreifen, da Web -Mitarbeiter im Gegensatz zu WebSockets außerhalb des Haupt -Threads in seinem eigenen Thread laufen.
Web Worker ist ein Objekt, das Skriptdateien ausführt, um Aufgaben mithilfe von Worker -Objekten auszuführen. Wenn wir über Arbeiter sprechen, tendieren sie dazu, in einen von drei Typen zu fallen:
Es gibt einige Dinge, die wir als Entwickler nicht kontrollieren können, und eine davon ist die Netzwerkverbindung des Benutzers. Jedes Netzwerk, mit dem der Benutzer eine Verbindung herstellt, ist selbst. Wir können nur unser Bestes tun, um unsere Anwendungen so zu optimieren, dass sie die beste Leistung für jede Verbindung erhalten, die verwendet wird.
Servicearbeiter sind eines der einige Dinge, die wir tun können, um die Leistung unserer Anwendung schrittweise zu verbessern. Servicearbeiter befinden sich zwischen der Anwendung, dem Browser und dem Server und bieten sichere, separate Thread -Verbindungen, die dank - Sie haben es erraten - Webarbeiter im Hintergrund ausführen. Wie wir im vorherigen Abschnitt gelernt haben, ist Servicearbeiter einer von drei Arten von Webarbeitern.
Warum benötigen Sie also einen Servicearbeiter, der sich zwischen Ihrer Anwendung und dem Browser des Benutzers befindet? In ähnlicher Weise können wir die Netzwerkverbindung des Benutzers nicht steuern. Angenommen, die Verbindung wird aus einem unbekannten Grund unterbrochen. Dies unterbricht die Kommunikation zwischen dem Browser und dem Server und verhindert, dass Daten hin und her übergeben werden. Der Servicearbeiter bleibt in Verbindung und fungiert als asynchroner Proxy, der Anforderungen abfängt und Aufgaben ausführt - selbst nachdem eine Netzwerkverbindung verloren geht.
Dies ist die wichtigste treibende Kraft für die sogenannte "Offline First" -Entwicklung. Wir können Vermögenswerte in einem lokalen Cache anstelle des Netzwerks speichern, kritische Informationen bereitstellen, wenn der Benutzer offline ist, Inhalte vorlegen, damit der Benutzer bei Bedarf verwenden kann, und einen Fallback für Netzwerkfehler bereitstellen. Sie sind völlig asynchron, aber im Gegensatz zu WebSockets können sie nicht auf das DOM zugreifen, da sie auf ihren eigenen Threads laufen.
Eine weitere wichtige Sache bei Dienstangestellten ist, dass sie jede Anfrage und Antwort Ihrer Anwendung abfangen. Daher haben sie einige Sicherheitsrisiken und folgen vor allem einer homologen Strategie. Daher bedeutet dies, dass Servicearbeiter nicht von einem CDN oder einem Drittanbieterdienst ausgeführt werden können. Sie benötigen außerdem eine sichere HTTPS -Verbindung, was bedeutet, dass Sie ein SSL -Zertifikat benötigen, um sie auszuführen.
Dies ist eine superüberschrittene Erklärung der Unterschiede (und Ähnlichkeiten) zwischen Websockets, Webangestellten und Dienstangestellten. Auch hier sind Begriffe und Konzepte so ähnlich, dass einer mit dem anderen verwechselt werden kann, aber hoffentlich wird dies Ihnen ein besseres Verständnis dafür vermitteln, wie Sie sie unterscheiden können.
Wir beginnen mit einer schnellen Referenztabelle. Dies ist dasselbe, aber leicht erweitert für einen detaillierteren Vergleich. (Das Formular sollte hier eingefügt werden, und der Inhalt des Formulars sollte gemäß dem ursprünglichen Formularinhalt umgeschrieben werden, um die ursprüngliche Absicht aufrechtzuerhalten)
Das obige ist der detaillierte Inhalt vonDer Unterschied zwischen Webstecks, Webarbeitern und Servicearbeitern. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
So entsperren Sie Android-Berechtigungsbeschränkungen
In der Sprache C gibt es mehrere Ausgabe- und Eingabefunktionen
Lösungen für unbekannte Software-Ausnahmen in Computeranwendungen
So verwenden Sie Spyder
Ripple-Handelsplattform
Was sind die Vorteile des Java-Factory-Musters?
Verwendung der Memcpy-Funktion
Welche Software ist Premiere?
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
