1) Pourquoi les WebSockets protocole de mieux?
Les WebSockets est mieux pour les situations qui impliquent un faible temps de latence de communication, notamment pour de faibles temps de latence pour le client vers le serveur de messages. Pour le serveur de données de clients que vous pouvez obtenir assez faible latence à l'aide de la longue-tenue des connexions et des fragments de transfert. Cependant, cela n'aide pas avec le client pour la latence du serveur qui nécessite une nouvelle connexion pour chaque client vers le serveur de messages.
Votre 48 octets HTTP poignée de main n'est pas réaliste dans le monde réel HTTP connexions navigateur où il y a souvent plusieurs kilo-octets de données transmises dans le cadre de la demande (dans les deux sens), y compris de nombreux en-têtes et les données de cookie. Voici un exemple de requête/réponse à l'aide de google Chrome:
Exemple de demande (2800 octets, y compris les données des cookies, 490 octets sans les données de cookie):
GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]
Exemple de réponse (355 octets):
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip
HTTP et les WebSockets avoir l'équivalent de la taille initiale de la connexion des poignées de main, mais avec une connexion WebSocket la poignée de main initiale est effectuée une seule fois et puis des petits messages seulement 6 octets de surcharge (2 pour l'en-tête et de 4 pour la valeur de masque). Le temps de latence de frais généraux n'est pas tant la taille des en-têtes, mais de la logique pour analyser/gérer/stockage de ces en-têtes. En outre, la connexion TCP configuration du temps de latence est probablement un facteur plus grand que la taille ou le temps de traitement de chaque demande.
2) Pourquoi il a été mis en œuvre au lieu de la mise à jour du protocole HTTP?
Il y a des efforts à re-concevoir le protocole HTTP pour obtenir de meilleures performances et une faible latence tels que SPDY et HTTP 2.0. Cela permettra d'améliorer la situation normale pour les requêtes HTTP, mais il est probable que les WebSockets et/ou WebRTC DataChannel auront toujours un temps de latence inférieur pour le client vers le serveur de transfert de données de protocole HTTP (ou il sera utilisé dans un mode qui ressemble beaucoup à WebSockets de toute façon).
Mise à jour:
Ici, c'est un cadre de réflexion sur les protocoles web:
-
TCP: bas niveau, bi-directionnel, full-duplex, et de la garantie de l'ordre de la couche de transport. Pas de prise en charge du navigateur (sauf via un plugin ou d'un Flash).
-
HTTP 1.0: requête-réponse de protocole de transport en couches sur le protocole TCP. Le client fait une requête, le serveur donne une réponse complète, et la connexion est fermée. La demande de méthodes (GET, POST, HEAD) transactionnelle sens pour les ressources sur le serveur.
-
HTTP 1.1: maintient la requête-réponse de la nature de HTTP 1.0, mais permet la connexion à rester ouvert à de multiples requêtes complètes/réponses complètes (une seule réponse par demande). A encore plein les en-têtes de la requête et de la réponse, mais la connexion est de nouveau utilisé et ne sont pas fermées. HTTP 1.1, a également ajouté quelques autres méthodes de demande (OPTIONS, PUT, DELETE, TRACE, CONNECT) qui ont aussi spécifique transactionnelle significations. Cependant, comme mentionné dans l' introduction de la HTTP 2.0, le projet de proposition, HTTP 1.1 pipeline n'est pas largement déployé donc cela limite grandement l'utilité de HTTP 1.1 pour résoudre la latence entre les navigateurs et les serveurs.
-
Long-sondage: une sorte de "hack" pour HTTP (1.0 ou 1.1) où le serveur n'a pas de réponse immédiatement (ou n'y répond que partiellement avec les en-têtes) à la demande du client. Après une réponse du serveur, le client envoie immédiatement une nouvelle demande (en utilisant la même connexion, si plus de HTTP 1.1).
-
Streaming HTTP: une variété de techniques (multipart/fragments de réponse) qui permettent au serveur d'envoyer plus d'une réponse à une simple demande du client. Le W3C est la standardisation de ce que le Serveur a Envoyé des Événements à l'aide d'un
text/event-stream type MIME. Le navigateur de l'API (qui est assez similaire à l'API WebSocket) est appelé le EventSource API.
-
La comète/server push: c'est un terme générique qui comprend les deux long-sondage et streaming HTTP. La comète bibliothèques en général de l'aide de multiples techniques pour essayer de maximiser la croix-navigateur et de la croix-serveur.
-
Les WebSockets: une couche de transport intégré sur TCP qui utilise un HTTP amicale de Mise à niveau de la poignée de main. Contrairement à TCP, qui est un flux de transport, les WebSockets est un message en fonction du transport des messages: les messages sont délimitées sur le fil et sont ré-assemblés en complet avant la livraison de l'application. WebSocket connexions sont bidirectionnelles en duplex intégral et à long terme. Après la poignée de main initiale de demande/réponse, il n'y a pas de sémantique transactionnelle et il est très peu par message généraux. Le client et le serveur peut envoyer des messages à tout moment et doit gérer la réception de message asynchrone.
-
SPDY: Google a initié une proposition visant à étendre HTTP à l'aide plus efficace le fil de protocole, mais le maintien de tous HTTP sémantique (demande/réponse, les cookies, l'encodage). SPDY introduit un nouveau format de trame (avec la longueur de préfixe de cadres) et spécifie un moyen de superposition de requête/réponse HTTP paires sur le nouveau cadrage de la couche. Les en-têtes peuvent être compressés et de nouveaux en-têtes peuvent être envoyés après que la connexion a été établie. Il y a du monde réel implémentations de SPDY dans les navigateurs et les serveurs.
-
HTTP 2.0: a des objectifs similaires à SPDY: réduire HTTP latence et les frais généraux tout en préservant HTTP sémantique. Le projet actuel est dérivé de SPDY et définit une mise à niveau de la poignée de main et des données de cadrage, qui est très semblable à la le WebSocket standard pour l'établissement de liaisons et d'encadrement. Un autre HTTP 2.0 projet de proposition (httpbis à la vitesse de la mobilité) utilise les WebSockets pour la couche de transport et ajoute le SPDY de multiplexage et de HTTP cartographie comme un WebSocket extension (WebSocket extensions sont négociés au cours de la poignée de main).
-
WebRTC/CU-WebRTC: propositions pour permettre peer-to-peer de la connectivité entre les navigateurs. Cela peut permettre à la baisse de la moyenne et maximale de la latence de communication parce que, comme le transport sous-jacent est SDP/datagramme plutôt que TCP. Cela vous permet de commander la livraison de paquets/messages, ce qui évite de TCP problème des pics de latence causée par la perte de paquets, qui retardent la livraison de tous les paquets suivants (pour garantir la livraison dans l'ordre).
Références:
-
HTTP:
-
Le Serveur A Envoyé De L'Événement:
-
Les WebSockets:
-
SPDY:
-
HTTP 2.0:
-
WebRTC:
