Ma compréhension de l'interrogation HTTP, de l'interrogation longue, de la diffusion HTTP et de WebSockets

Question

J'ai lu de nombreux messages sur le cas et le web pour les mots clés de ma question de titre et de beaucoup appris d'eux. Certaines des questions que j'ai lu sont liés à des difficultés de mise en œuvre tandis que d'autres se concentrent sur des concepts généraux. Je veux juste m'assurer que j'ai compris tous les concepts et les raisons pour lesquelles la technologie X a été inventé plus de la technologie Y et ainsi de suite. Donc voilà:

Http Interrogation: Fondamentalement, AJAX, à l'aide de XmlHttpRequest.

Http temps d'Interrogation: AJAX, mais le serveur tient à la réponse, sauf si le serveur a une mise à jour, dès que le serveur a une mise à jour, elle l'envoie et ensuite, le client peut envoyer une autre demande. L'inconvénient est l'en-tête supplémentaire de données qui doit être envoyé en arrière et en avant provoquant une surcharge supplémentaire.

Streaming Http: Similaires le temps d'interrogation, mais le serveur répond avec un en-tête avec "Transfert de Encoding: chunked" et nous ne sommes donc pas besoin de procéder à une nouvelle demande chaque fois que le serveur envoie des données (et donc économiser de l'en-tête supplémentaire à la verticale). L'inconvénient ici est que nous avons à "comprendre" et comprendre la structure des données de distinguer plusieurs morceaux envoyés par le serveur.

Applet Java, Flash, Silverlight: Ils offrent la possibilité de se connecter à des serveurs de socket tcp/ip, mais parce qu'ils sont des plugins, les développeurs ne veulent pas en dépendre.

Les WebSockets: ils sont la nouvelle API qui tente de répondre aux lacunes des méthodes ci-dessus de la manière suivante:

• Le seul avantage des WebSockets plus de plugins, comme les Applets Java, Flash ou Silverlight, c'est que les WebSockets sont nativement intégrées dans les navigateurs et ne pas compter sur les plugins.
• Le seul avantage des WebSockets sur streaming http, c'est que vous n'avez pas à faire un effort pour "comprendre" et d'analyser les données reçues.
• Le seul avantage des WebSockets sur une Longue Interrogation est celle de l'élimination de la taille des en-têtes supplémentaires et d'ouverture et de fermeture de la socket de connexion à la demande.

Existe-il d'autres différences significatives qui me manque? Je suis désolé si je suis re-poser des questions ou de combiner beaucoup de questions déjà sur DONC en une seule question, mais je tiens simplement à faire sens parfait de toutes les info qui est sorti il y a sur soi et sur le web au sujet de ces concepts.

Merci!

Answer 1

Il y a plus de différences que de ceux que vous avez identifiés.

Duplex/orientation:

• Uni-directionnelle: HTTP sondage, long sondage, streaming.
• Bi-direcitonal: les WebSockets, plugin de mise en réseau

Afin d'augmenter la latence (approx.):

• Les WebSockets
• Plugin de mise en réseau
• Streaming HTTP
• HTTP long-sondage
• HTTP interrogation

CORS (cross-origin support):

• Les WebSockets: oui
• Plugin de mise en réseau: Flash via la politique de la demande (pas sûr sur les autres)
• HTTP * (certains récents de soutien)

Binaire natif de données (tableaux typés, blob):

• Les WebSockets: oui
• Plugin de mise en réseau: pas de Flash (nécessite le codage d'URL à travers ExternalInterface)
• HTTP *: proposition récente pour permettre binaire type de support

La bande passante dans la diminution de l'efficacité:

• Plugin de mise en réseau: Flash sockets sont brutes sauf pour les premiers de la politique de la demande
• Les WebSockets: configuration de la connexion de la poignée de main et quelques octets par trame
• Streaming HTTP (ré-utilisation de la connexion au serveur)
• HTTP long-sondage: connexion pour chaque message
• HTTP sondage: connexion pour chaque message + pas de messages de données

Support des appareils mobiles:

• WebSocket: iOS 4.2 et. Certains Android Flash via l'émulation ou de l'utilisation de Firefox pour Android ou Google Chrome pour Android qui fournissent WebSocket natif de soutien.
• Plugin de mise en réseau: certains Android. Pas sur iOS
• HTTP *: la plupart du temps oui

Javascript utilisation de la complexité (du plus simple au plus compliqué). Certes, la complexité des mesures sont quelque peu subjective.

• Les WebSockets
• HTTP sondage
• Plugin de mise en réseau
• HTTP long sondage en streaming

Notez également qu'il existe une proposition du W3C pour la normalisation des streaming HTTP appelée Server-Sent Events. Il est actuellement assez tôt dans l'évolution et est conçu pour fournir un standard de l'API Javascript comparables, avec la simplicité pour les WebSockets.

Answer 2

Quelques grandes réponses des autres qui couvrent beaucoup de terrain. Voici un peu plus.

Le seul avantage des WebSockets plus de plugins, comme les Applets Java, Flash ou Silverlight, c'est que les WebSockets sont nativement intégrées dans les navigateurs et ne pas compter sur les plugins.

Si vous entendez par là que vous pouvez utiliser les Applets Java, Flash ou Silverlight pour établir une connexion de socket, alors oui, c'est possible. Cependant, vous ne voyez pas celui qui a été déployé dans le monde réel, trop souvent, en raison des restrictions.

Par exemple, les intermédiaires peuvent et arrêt de la circulation. Le WebSocket standard a été conçu pour être compatible avec l'existant HTTP infrastructure et est donc beaucoup moins enclin à être perturbé par des intermédiaires comme les pare-feu et les serveurs proxy.

En outre, WebSocket pouvez utiliser le port 80 et 443, sans exiger dédié ports, de nouveau grâce à la conception du protocole pour être aussi compatible que possible avec HTTP existants de l'infrastructure.

Ceux socket alternatives (Java, Flash et Silverlight) sont difficiles à utiliser en toute sécurité dans un cross-origin architecture. Ainsi, souvent, les gens de tenter de les utiliser de la croix-origine de tolérer l'insécurité plutôt que d'aller à l'effort de le faire en toute sécurité.

Ils peuvent aussi exiger d'autres "non-standard" ouverture de ports (quelque chose administrateurs sont réticents à le faire) ou de la politique de fichiers qui doivent être gérés.

En bref, à l'aide de Java, Flash ou Silverlight pour la prise de connectivité est assez problématique que vous ne le voyez pas déployé dans de graves architectures trop souvent. Flash et Java ont eu cette capacité pour probablement au moins 10 ans, et pourtant il n'est pas répandue.

Le WebSocket norme a été en mesure de commencer avec une nouvelle approche, portant les restrictions à l'esprit, et j'espère avoir appris quelques leçons.

Certains WebSocket implémentations utilisent Flash (ou, éventuellement, Silverlight et/ou Java) comme leur secours quand WebSocket connectivité ne peut pas être établie (comme lors de l'exécution dans un vieux navigateur ou lorsqu'un intermédiaire interfère).

Alors que certains sorte de stratégie de repli pour ces situations est intelligent, et même nécessaire, la plupart de ceux qui utilisent Flash et al vont souffrir les inconvénients décrits ci-dessus. Il n'a pas à être de cette façon -- il existe des solutions de contournement pour assurer la croix-origine capable de connexions à l'aide de Flash, Silverlight, etc-mais la plupart des implémentations ne le ferai pas, car il n'est pas facile.

Par exemple, si vous comptez sur WebSocket pour une croix d'origine de la connexion, qui fonctionne très bien. Mais si vous exécutez ensuite dans un vieux navigateur ou un pare-feu/proxy gêné et s'appuient sur Flash, par votre secours, vous trouverez qu'il est difficile de faire la même croix-origine de la connexion. À moins que vous ne se soucient pas de la sécurité, bien sûr.

Cela signifie qu'il est difficile d'avoir un seul architecture unifiée qui fonctionne en natif et non-natif connexions, sauf si vous êtes prêt à mettre dans un peu de travail, ou aller avec un cadre qui a fait de bien. Dans l'idéal, de l'architecture, vous ne l'auriez pas remarqué, si les connexions étaient natifs ou non; vos paramètres de sécurité serait de travailler dans les deux cas; votre de clustering paramètres fonctionne encore; votre planification de la capacité de demeurer; et ainsi de suite.

Le seul avantage des WebSockets sur streaming http, c'est que vous n'avez pas à faire un effort pour "comprendre" et d'analyser les données reçues.

Il n'est pas aussi simple que l'ouverture d'un flux HTTP et est assis à l'arrière comme votre flux de données pour les minutes, les heures, ou plus. Différents clients se comportent différemment et vous avez à gérer cela. Par exemple, certains clients ont de la mémoire tampon de données et de ne pas le publier à la demande jusqu'à un certain seuil est atteint. Pire encore, certains de ne pas transmettre les données à l'application jusqu'à ce que la connexion est fermée.

Donc, si vous envoyez plusieurs messages vers le client, il est possible que le client demande de ne pas recevoir les données jusqu'à 50 messages de données a été reçu, par exemple. Ce n'est pas trop en temps réel.

Alors que le streaming HTTP peut être une alternative viable lorsque WebSocket n'est pas disponible, il n'est pas une panacée. Il a besoin d'une bonne compréhension de travailler dans un robuste dans les badlands du Web dans des conditions réelles.

Existe-il d'autres différences significatives qui me manque?

Il y a autre chose que personne n'a encore parlé, donc je vais le mettre en place.

Le protocole WebSocket a été conçu pour être une couche de transport pour des protocoles de niveau supérieur. Alors que vous pouvez envoyer des messages JSON ou qu'est-ce-pas directement sur une connexion WebSocket, il peut également effectuer la norme ou de protocoles personnalisés.

Par exemple, vous pourriez faire AMQP ou XMPP sur WebSocket, comme les gens l'ont déjà fait. Ainsi, un client pourrait recevoir des messages à partir d'un courtier AMQP comme s'il était connecté directement au courtier lui-même (et, dans certains cas, il est).

Ou si vous avez un serveur existant avec certaines protocole personnalisé, vous pouvez transporter que plus de WebSocket, prolongeant ainsi que le serveur de back-end pour le Web. Souvent une application existante qui a été verrouillé dans l'entreprise peut élargir la portée à l'aide de WebSocket, sans avoir à modifier l'infrastructure back-end.

(Naturellement, vous voulez être capable de faire tout cela de manière sécurisée afin de vérifier avec le vendeur ou le WebSocket fournisseur.)

Certaines personnes ont mentionné WebSocket comme TCP pour le Web. Parce que, tout comme TCP transports des protocoles de niveau supérieur, WebSocket, mais d'une manière qui est compatible avec l'infrastructure Web.

Ainsi, alors que l'envoi de JSON (ou autre) des messages directement sur WebSocket est toujours possible, il faut aussi considérer les protocoles existants. Car, pour beaucoup de choses que vous voulez faire, il y a probablement un protocole qui a déjà été pensé de le faire.

Je suis désolé si je suis re-poser des questions ou de combiner beaucoup de questions déjà sur DONC en une seule question, mais je tiens simplement à faire sens parfait de toutes les info qui est sorti il y a sur soi et sur le web au sujet de ces concepts.

C'était une excellente question, et les réponses ont été très instructif!

Answer 3

Si je peut demander une autre chose: je suis tombé sur un article quelque part qui dit que, http diffusion en continu peut également être mis en cache par les fondés de pouvoir, tandis que les websockets sont pas. qu'est-ce que cela signifie?

(StackOverflow limite la taille de commenter les réponses, donc j'ai eu à répondre ici plutôt que dans la ligne.)

C'est un bon point. Pour comprendre cela, pensez à un traditionnel HTTP scénario... Imaginez un navigateur ouvert une page web, il demande http://example.com, dire. Le serveur répond avec l'adresse HTTP qui contient le code HTML de la page. Ensuite, le navigateur voit qu'il y a des ressources dans la page, donc il commence à demander les fichiers CSS, fichiers JavaScript, les images bien sûr. Ils sont tous les fichiers statiques qui seront les mêmes pour tous les clients qui le demandent.

Certains des proxy cache statique des ressources de sorte que les demandes ultérieures d'autres clients peuvent obtenir ces ressources statiques du proxy, plutôt que d'avoir à aller tout le chemin du retour à la centrale de serveur web pour les obtenir. C'est la mise en cache, et c'est une excellente stratégie pour décharger les demandes et le traitement de vos services centraux.

Si le client n ° 1 les demandes http://example.com/images/logo.gif, dire. Cette demande passe par le proxy tout le chemin à la centrale de serveur web, qui sert logo.gif. Comme logo.gif passe par le proxy, le proxy va enregistrer l'image et l'associer à l'adresse http://example.com/images/logo.gif.

Lorsque client #2 arrive et demande également à http://example.com/images/logo.gifle proxy peut retourner l'image et aucune communication n'est requise sur le serveur web dans le centre. Cela donne une réponse plus rapide à l'utilisateur final, qui est toujours grand, mais cela signifie aussi qu'il y a moins de charge sur le centre. Qui peut traduire à la réduction des coûts de matériel, réduction des coûts de réseau, etc. C'est donc une bonne chose.

Le problème se pose lorsque l'logo.gif est mis à jour sur le serveur web. Le proxy va continuer à servir la vieille image pas au courant qu'il y a une nouvelle image. Cela conduit à un ensemble de chose autour de l'expiration, de sorte que le proxy ne le cache de l'image pour un court laps de temps avant la "date d'expiration" et la prochaine demande passe par le proxy pour le serveur web, ce qui rafraîchit ensuite le cache du proxy. Il existe également des solutions les plus avancées, où un serveur central peut pousser à connus des caches, et ainsi de suite, et les choses peuvent devenir assez sophistiqués.

Comment cette cravate à votre question?

Vous m'avez demandé HTTP streaming où le serveur de streaming HTTP à un client. Mais le streaming de HTTP est exactement comme HTTP, sauf que vous n'avez pas arrêter d'envoyer des données. Si un serveur web sert d'une image, il envoie une requête HTTP au client qui finit par la suite: vous avez envoyé l'ensemble de l'image. Et si vous souhaitez envoyer des données, c'est exactement la même, mais le serveur envoie juste pour un très long moment (comme c'est massivement gigantesque image, par exemple) ou même ne se termine jamais.

À partir du proxy point de vue, il ne fait pas de distinction entre HTTP pour une ressource statique comme une image, de données ou de streaming HTTP. Dans ces deux cas, le client fait une demande de du serveur. Le proxy de rappeler que la demande et la réponse. La prochaine fois que la requête, le proxy sert la même réponse.

Donc, si votre client fait une demande pour les cours de la bourse, dire, et obtenu une réponse, alors le prochain client peut formuler la même demande et d'obtenir les données mises en cache. Probablement pas ce que vous voulez! Si vous demandez le prix des actions que vous souhaitez que les données les plus récentes, à droite?

C'est donc un problème.

Il y a des astuces et des solutions de contournement pour résoudre les problèmes comme ça, c'est vrai. Évidemment, vous pouvez obtenir le streaming HTTP travailler depuis il est il est en usage aujourd'hui. Tout est transparent pour l'utilisateur final, mais les gens qui développent et maintiennent ces architectures avoir à sauter à travers des cerceaux et un prix à payer. Il en résulte compliqué architectures, ce qui signifie plus d'entretien, plus de matériel, plus de complexité, plus le coût. Il signifie également que les développeurs ont souvent à prendre soin de quelque chose qu'ils ne devraient pas avoir à quand ils devraient l'être en se concentrant sur l'application, l'interface et la logique métier -- ils ne devraient pas avoir à se préoccuper de la communication sous-jacente.

Answer 4

HTTP limite le nombre de connexions d'un client peut avoir avec un serveur à 2 (même si cet effet peut être atténué par l'utilisation de sous-domaines) et IE a été connu pour faire respecter cela avec impatience. Firefox et Chrome permettra plus (bien que je ne me souviens pas du haut de ma tête exactement combien). Cela pourrait ne pas sembler comme un énorme problème, mais si vous utilisez 1 connexion en permanence en temps réel des mises à jour, toutes les autres demandes doivent goulot d'étranglement à travers l'autre connexion HTTP. Et il y a la question de l'ouverture de connexions des clients met plus de charge sur le serveur.

Les WebSockets sont un protocole basé sur TCP et en tant que tel ne souffrent pas de ce niveau HTTP limite de connexion (mais, bien sûr, la prise en charge du navigateur n'est pas uniforme).