Pour les applications Web générales, la plupart des développeurs ne sont pas étrangers. Dans les applications Web, le mode interactif de demande / réponse est utilisé entre le navigateur et le serveur. Le navigateur émet une demande et le serveur génère la réponse correspondante en fonction de la demande. Le navigateur est traité pour la réponse de réception aux utilisateurs. Le format de réponse peut être HTML, XML ou JSON. Avec le style d'architecture de repos et la popularité de l'Ajax, le serveur utilise davantage JSON comme format de données de réponse. L'application Web utilise l'objet XMLHTTPRequest pour envoyer la demande et mettre à jour dynamiquement le contenu de la page en fonction des données renvoyées par le serveur. De manière générale, les opérations des utilisateurs sur la page, telles que cliquer ou déplacer la souris, déclenchent les événements correspondants. Une demande est publiée par l'objet XMLHTTPRequest, et la page a une mise à jour locale après la réponse du serveur. Les lacunes de cette méthode sont que les données générées par le serveur ne peuvent pas être informées du navigateur à temps, mais il doit être obtenu par le navigateur jusqu'à ce que la prochaine demande soit envoyée. Pour certaines applications ayant des exigences de données à temps élevé, ce retard est inacceptable. Afin de répondre aux besoins de ces applications, il est nécessaire de faire pousser des données du serveur vers le navigateur pour s'assurer que les modifications des données du côté serveur peuvent être averties aux utilisateurs lors de la première fois. Il existe de nombreuses solutions courantes, qui peuvent être divisées en deux catégories. La différence entre ces deux méthodes est de savoir s'il est basé sur le protocole HTTP. La pratique de ne pas utiliser le protocole HTTP consiste à utiliser les nouvelles spécifications WebSocket de HTML 5, et la méthode d'utilisation du protocole HTTP comprend une rotation simple, une technologie COMET et l'événement de push du serveur HTML 5 décrit dans cet article. Ces technologies seront introduites ci-dessous.
Brève introductionAvant d'introduire l'événement HTML 5 Server Push, introduisez d'abord une partie du nombre de technologies de push de données de serveur mentionnées ci-dessus. Le premier est WebSocket. La spécification WebSocket est une partie importante de HTML 5. Il a été pris en charge par de nombreux navigateurs grand public, et de nombreuses applications développées sur la base de WebSocket. Tout comme son nom est exprimé, WebSocket utilise une connexion de la veste, basée sur le protocole TCP. Après avoir utilisé WebSocket, il construit en fait un ensemble de connexions de mots entre le serveur et le navigateur, qui peut être transmise en données à deux voies. La fonction de WebSocket est très puissante et elle est flexible à utiliser, ce qui peut convenir à différents scénarios. Cependant, la technologie WebSocket est également relativement compliquée, y compris la mise en œuvre du serveur et du côté navigateur différent des applications Web ordinaires.
À l'exception de WebSocket, d'autres méthodes d'implémentation sont basées sur le protocole HTTP pour réaliser l'effet de la poussée de temps réel. La première méthode est une rotation simple, c'est-à-dire que le navigateur envoie une demande au serveur de temps à autre pour savoir s'il existe des données. Cette approche est relativement simple et peut résoudre le problème dans une certaine mesure. Cependant, considérez soigneusement l'intervalle de temps de rotation. Si l'intervalle entre la rotation est trop long, il amènera les utilisateurs à ne pas recevoir les données mises à jour dans le temps;
La technologie de COMET a amélioré les lacunes de la rotation simple, en utilisant des demandes à longues roues. Chaque demande de rotation longue, le serveur conservera la connexion dans une période d'ouverture pendant une période de temps, plutôt que de la fermer immédiatement une fois la réponse terminée. L'avantage est que dans le délai où la connexion est ouverte, la mise à jour des données générée par le serveur peut être renvoyée au navigateur à temps. Lorsqu'une longue connexion est fermée, le navigateur ouvrira immédiatement une nouvelle connexion longue pour continuer la demande. Cependant, la mise en œuvre de la technologie COMET nécessite la prise en charge d'une bibliothèque de troisième partie sur le serveur et le côté navigateur. En comparaison sommaire, les quatre technologies différentes mentionnées ci-dessus ne sont pas recommandées pour une utilisation en raison de leurs défauts. La technologie COMET ne fait pas partie de la norme HTML 5. Les spécifications de WebSocket et la technologie de push du serveur font partie de la norme HTML 5. Cependant, les spécifications WebSocket sont plus compliquées et conviennent aux scènes qui doivent être compliquées et à la communication de données à deux voies. Pour les scénarios de push de données de serveur simples, il suffit d'utiliser des événements de push serveur.
En termes de prise en charge du navigateur, les événements de push serveur ont été pris en charge sur la plupart des ordinateurs de bureau et des navigateurs mobiles, sauf IE. Les navigateurs et versions de l'événement Push Push du serveur de support comprennent: Firefox 6.0+, Chrome 6.0+, Safari 5.0+, Opera 11.0+, iOS Safari 4.0+, Opera Mobile 11.1+, Chrome pour Android 25.0+, Firefox pour Andr Andr OID 19.0 + et Blackberry Browser 7.0+ et al. Le soutien de IE a une introduction détaillée dans les chapitres suivants.
Les spécifications suivantes de la spécification de l'événement push du serveur sont spécifiées.
spécificationLa spécification des événements de serveur fait partie intégrante de la spécification HTML 5. Cette spécification est relativement simple, composée principalement de deux parties: la première partie est le protocole de communication entre le serveur et le côté du navigateur, et la deuxième partie est l'objet Eventsource utilisé par le navigateur pour utiliser JavaScript. Le protocole de communication est un protocole simple basé sur du texte pur. Le contenu de la réponse sur le serveur est Text / Event-Stream. Le contenu du texte de réponse peut être considéré comme un flux d'événements, qui est composé de différents événements. Chaque événement se compose de deux parties: type et données, et chaque événement peut avoir un identifiant facultatif. Le contenu des différents événements est séparé par les lignes vides (/ r / n) qui ne comprend que la voiture Entrée et le symbole royal. Les données de chaque événement peuvent être composées de plusieurs lignes. La liste de code 1 donne un exemple de la réponse de la côté du serveur.
Exemple de réponse au serveurDonnées: First EventData: Second EventID: 100Event: MyEventData: Third EventID: 101: Ceci est un commentdata: Fouteh EventData: Fourse Event Course
Comme indiqué dans la liste 1, chaque événement est séparé par une ligne vide. Pour chaque ligne, le côlon (:) est le type de ligne avant et la valeur correspondante derrière le côlon. Les types possibles comprennent:
Dans le code ci-dessus, le premier événement contient uniquement des données de données, qui génèrent des événements par défaut; L'événement est un événement à quatre / nfouth eovent continue. Lorsqu'il existe plusieurs lignes de données, les données réelles sont connectées par les données pour le changement de ligne.
Si les données renvoyées par le serveur contient l'identifiant de l'événement, le navigateur enregistrera l'identifiant de l'événement récemment reçu. Si la connexion au serveur est interrompue, lorsque la fin du navigateur est à nouveau connectée, le logo de la dernière fois que l'événement est obtenu par le HTTP Head-Event-ID. Le serveur peut être déterminé par l'identifiant d'événement envoyé par le côté du navigateur pour déterminer quel événement commence à continuer la connexion.
Pour la réponse renvoyée par le côté serveur, le côté du navigateur doit utiliser l'objet Eventsource en JavaScript pour le traitement. Eventsource utilise une méthode de surveillance d'événements standard, qui n'a qu'à ajouter la méthode de traitement des événements correspondante à l'objet. Eventsource propose trois événements standard, comme le montre le tableau 1.
Tableau 1. Événement standard fourni par l'objet Eventsource| nom | illustrer | Méthode de traitement des événements |
| ouvrir | Lorsque la connexion avec le serveur est établie avec succès | onduler |
| Message | Lorsque l'événement envoyé par le serveur | montée |
| erreur | Lorsqu'une erreur se produit | onerror |
Comme mentionné précédemment, le serveur peut renvoyer un événement de type personnalisé. Pour ces événements, vous pouvez utiliser la méthode ADDEVENTListener pour ajouter la méthode de traitement des événements correspondante. La liste de code 2 donne un exemple de l'objet Eventsource.
Exemples de l'objet Eventsource var es = new Eventsource ('Events'); données);});Comme indiqué ci-dessus, après avoir créé l'objet Eventsource spécifiquement, la méthode de traitement des événements peut être ajoutée via les méthodes OnMessage et AddEventListener. Lorsque le serveur a de nouveaux événements, la méthode de traitement des événements correspondante sera appelée. Le rôle de la propriété OnMessage de l'objet Eventsource est similaire à celui d'AdveventListener ('Message'), mais l'attribut OnMessage ne prend en charge qu'une méthode de traitement d'événements. Après avoir introduit le contenu de spécification de l'événement de push du serveur, l'implémentation du serveur est introduite ci-dessous.
Le serveur et l'implémentation finale du navigateurOn peut voir à partir de la description du protocole de communication dans la section précédente que l'événement de poussée du serveur est un protocole plus simple. L'implémentation du côté serveur est relativement simple. Une variété de technologies différentes de serveurs se trouvent dans la communauté open source. Il n'est pas difficile de se développer. Cet article utilise Java comme langage d'implémentation du serveur. Implémentation de correspondance en conséquence du projet Open Source-EventsOrce Service, voir Resources de référence. Ce qui suit est un exemple spécifique pour illustrer comment utiliser le projet Jetty-Eventsource-Service. L'exemple est utilisé pour simuler le mouvement aléatoire d'un objet dans un espace limité. L'objet commence à partir d'une position aléatoire, puis sélectionne au hasard une direction en haut, en bas, en gauche et en droite, et déplace une distance aléatoire dans cette direction. Le serveur modifie constamment la position de l'objet et pousse les informations de localisation au navigateur, qui est affiché par le navigateur.
Implémentation du serveur服务器端的实现由两部分组成 : 一部分是用来产生数据的 org.eclipse.jetty.servlets.eventsource 接口的实现 , 另一部分是作为浏览器访问端点的继承自 org.eclipse.jetty.servlets.eventsourceservlet 类的Implémentation du servlet. Le code suivant donne une classe d'implémentation de l'interface Eventsource.
Eventsource Interface Implementation Class Movementeventsource
Classe publique Movemententsource implémente Eventsource {private Int Width = 800; Logger .getLogger (getClass (). GetName ()); .nextint (largeur); (LASTEENDID); .split (,); if (pos.length> 1) {int xpos = -1, ypos = -1; Pos [1], 10);} catch (NumberFormatexception e) {} if (isValidMove (xpos, ypos)) {x = xpos; Informations.); While (true) {emiter.com (); .DATA (ID) Selon l'emplacement; , e); Break;}} emiter.close (); move = getMove (); Juger si la position de mouvement actuelle est légale. xdir = new int}; int [] ydir = new int [] {0, -1, 0, 1}; int dir = random.nextint (4); )};}}Le MovementEventsource doit implémenter la méthode ONOPEN, ONRESUME et ONCLOSE de l'interface Eventsource. Les méthodes ONOpen et ONRESUME ont un paramètre de l'interface EventSource.Emitter, qui peut être utilisée pour envoyer des données. Les méthodes contenues dans l'interface Eventsource.Emitter comprennent les données, l'événement, le commentaire, l'identification et la fermeture, qui correspondent respectivement à divers types d'événements dans le protocole de communication. La méthode OnResume contient également un paramètre supplémentaire LaserEntid, indiquant l'identifiant du dernier événement envoyé par l'en-tête du dernier événement.
La principale logique des événements générés dans l'événement dans la classe MovementEventsource est dans la méthode de requête. Cette méthode contient un cycle illimité qui modifie la position toutes les 2 secondes et envoyez en même temps la position mise à jour à l'extrémité du navigateur via la méthode de données de la position de mise à jour via la méthode de données de l'interface Eventsource.Emitter. Chaque événement a un identifiant correspondant, et la valeur de l'identifiant est la position elle-même. Si le navigateur est lié après la déconnexion de la connexion, l'objet peut être déplacé de la dernière position.
Il est simple de mettre en œuvre le service du service -CorResponding à la classe MovementEventsource. Dans la mise en œuvre de la méthode NeweventsOrce, une classe MovementEventsource doit être retournée, comme indiqué ci-dessous. Chaque fois que le navigateur est établi, le service crée un objet d'une nouvelle classe MovementEventsource pour gérer la demande.
Implémentation du servlet de MovementServlet Classe publique Movementservlet ExtendSarcesorceservlet {@Override Protected Eventsource Newsource (httpServletRequest, String ClientId) renvoie de nouveaux mouvementsEventsource (800, 600, 20);}}Dans l'implémentation du serveur, il convient de noter que la prise en charge du filtre de serveur correspondant doit être ajoutée. Il s'agit de l'exigence du cadre de continuations de jetée sur laquelle le projet de service de jetty-eventsource s'appuie, sinon il y aura des erreurs dans le cas. La méthode d'ajout d'un filtre consiste à ajouter le contenu de configuration comme indiqué ci-dessous dans le fichier web.xml.
La configuration du filtre de service requise par les continuations de jetée<filter> <filter-name> continuation </filter-name> <filter-class> org.eclipse.jetty.continuation.continuationfilter </filter-Class> </filter> <Filter-Ma ppping> <filter-name> Continuation </filter-name> <url-potern> / sse / * </url-stern> </ filter-mapping>Implémentation de fin de navigateur
La mise en œuvre du côté du navigateur est relativement simple. Le code suivant donne l'implémentation correspondante. Utilisez un carré sur la page pour représenter un objet. Lorsqu'un nouvel événement est reçu, la position du bloc est sur la page en fonction des informations de coordonnées données dans les données de l'événement.
Code d'implémentation du côté du navigateur var es = new Eventsource ('sse / mouvement'); [1]; $ ('#box').Après avoir introduit le côté serveur de base et la fin du navigateur, la prise en charge IE plus importante est introduite ci-dessous.
IE SupportUn gros problème utilisant l'objet Eventsource natif du navigateur est que IE ne fournit pas de soutien. Afin de fournir le même soutien sur IE, il y a généralement deux façons. La première façon est d'utiliser l'objet Eventsource d'origine sur d'autres navigateurs, tout en utilisant une technologie de rotation simple ou de comète sur IE; . Cet article utilise la technologie Polyfill, en chargeant juste une troisième bibliothèque JavaScript par partie sur la page. L'application du code latéral du navigateur n'a pas besoin d'être modifiée. Il est généralement recommandé d'utiliser une deuxième méthode, car de cette manière, une seule technologie d'implémentation est requise du côté serveur.
Il n'est pas facile de fournir un objet d'événements primaires similaire sur IE. En théorie, seul l'objet XMLHTTPRequest est nécessaire pour obtenir le contenu de la réponse du côté serveur, et grâce à l'analyse de texte, les événements correspondants peuvent être extraits et la méthode de traitement des événements correspondante peut être déclenchée. Le problème est que l'objet XMLHTTPRequest sur IE ne prend pas en charge le contenu de réponse de la pièce d'obtention. Ce n'est qu'après l'obtention de la réponse de la réponse. Parce que l'événement Push Server utilise une longue connexion. Lorsque la connexion est toujours ouverte, l'événement correspondant ne peut pas être déclenché via l'objet XMLHTTPRequest et l'événement correspondant ne peut pas être déclenché. Plus précisément, lorsque le readystate de l'objet XMLHTTPRequest est 3 (ReadyState_Interactive), son attribut ResponseText ne peut pas être obtenu.
Afin de résoudre le problème des objets XMLHTTPRequest sur IE, vous devez utiliser l'objet XDomainRequest introduit dans IE 8. Le rôle de l'objet XDomainRequest est d'envoyer une demande Ajax croisée. L'objet XDomainRequest fournit l'événement OnProgress. Lorsque l'événement OnProgress se produit, un contenu de la réponse peut être obtenu via la propriété ResponseText. Il s'agit de la plus grande différence entre l'objet XDomainRequest et l'objet XMLHTTPRequest. Après avoir utilisé l'objet XDomainRequest pour ouvrir la connexion au côté du serveur, lorsque les nouvelles données sont générées sur le serveur, il peut être traité par l'événement OnProgress de l'objet XDomainRequest.
Cependant, en raison de l'objectif d'origine de l'objet XDomainRequest, consiste à émettre des demandes Ajax Cross-Domain. Ces restrictions affecteront sa mise en œuvre en tant qu'objet EventsOrce. Les restrictions et solutions spécifiques sont présentées ci-dessous:
En raison de ces restrictions sur l'objet XDomainRequest, l'implémentation du serveur doit également apporter des modifications correspondantes. Ces modifications incluent le renvoi de la tête d'accès à l'origine allocale; analyser les paramètres du type de texte / simple envoyé par le navigateur;
La bibliothèque Polyfill utilisée dans cet article est le projet Eventsource développé par Yaffle sur GitHub. Après avoir utilisé la bibliothèque Polyfill et modifié l'implémentation du côté serveur, vous pouvez utiliser le serveur pour pousser l'événement dans le navigateur, IE 8 et plus. Si vous avez besoin de prendre en charge IE 7, vous ne pouvez utiliser que une technologie simple ou une technologie de comète. Voir les ressources de référence dans l'exemple du code de cet article.
résuméSi vous devez pousser les données du serveur vers le navigateur, les technologies qui peuvent être utilisées en fonction des normes de spécification HTML 5 incluent les événements WebSocket et Server Push. Les développeurs peuvent choisir la bonne technologie en fonction des besoins spécifiques de l'application. Si vous n'avez besoin que de pousser les données du serveur, la norme de l'événement de poussée du serveur est plus simple et plus facile à réaliser. Cet article a introduit le contenu standard de l'événement de push du serveur, l'implémentation du serveur et du côté navigateur en détail, et a également analysé comment prendre en charge le navigateur IE.