Server push

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Le Server Push est un mode de communication client-serveur dans lequel le dialogue est lancé par le serveur. Cette technique s'oppose donc au fonctionnement « classique » des transactions web où le client ouvre le dialogue, et tire vers lui l'information (pull).

Description[modifier | modifier le code]

Afin de permettre son fonctionnement, la technique push impose une autorisation préalable du client sur le modèle de l'abonnement. Le client s'abonne au service et dès qu'une nouvelle information est disponible, elle est envoyée par le serveur.

Des applications telles que la visioconférence ou la messagerie instantanée sont de parfaits exemples d'utilisation de cette technique : dès que le serveur central reçoit un message (ou n'importe quel autre type de données) de l'un des participants, il l'envoie aux autres. Les réseaux IRC et P2P fonctionnent sur le même principe.

Le protocole SMTP des courriels fonctionne aussi sur le principe du server push, bien qu'une partie de la transaction complète soit en mode pull (protocoles IMAP et POP3). Les clients de messagerie modernes simulent le push en interrogeant fréquemment le serveur sur l'arrivée éventuelle de nouveau courrier. Notons toutefois que le protocole IMAP supporte nativement le push grâce à la commande IDLE.

Techniques[modifier | modifier le code]

HTTP server push[modifier | modifier le code]

Le HTTP server push (parfois nommé HTTP streaming) est le nom donné à la technique push appliquée au protocole HTTP. Plusieurs méthodes permettent d'aboutir à un push serveur, la plus commune étant d'empêcher le serveur de clore la transaction. La connexion client-serveur reste ainsi ouverte, ce qui permet de mettre à jour instantanément les données chez les clients liés et évite de créer des queues parfois coûteuses du côté serveur. Cette fonctionnalité est disponible sur le serveur Apache via CGI.

Une autre possibilité pour réaliser le push est d'utiliser l'en-tête Mime multipart/x-mixed-replace, mis en place par le navigateur Netscape Navigator en 1995[1],[2]. Bien que la plupart des navigateurs récents soient à même d'exploiter cet en-tête, Microsoft n'envisage toujours pas de doter son navigateur de cette technique[3].

Le WHATWG travaille actuellement à la standardisation de cette technique : le Server Sent Event[4] implémentée par l'essentiel des navigateurs récents excepté Internet Explorer[5] À la différence du modèle créé par Netscape, le server sent event est basé sur la création du nouveau type Mime text/event-stream, dont les données seront directement exploitables à travers l'arbre DOM.

Java pushlet[modifier | modifier le code]

Le Java pushlet (mot-valise créé à partir de push et applet) est une technique développée pour les applications web en Java, bien qu'elle soit maintenant utilisée dans d'autres frameworks. Ici, le serveur exploite l'utilisation de connexions persistantes (voir aussi l'article sur HTTP 1.1). Comme pour les autres méthodes, le serveur ne clôt pas le dialogue avec son client, et berne ce dernier, le laissant en mode de chargement et lui envoyant régulièrement de petites instructions en JavaScript afin de rafraîchir la page. L'intérêt de cette méthode réside dans le fait que le client n'a besoin ni d'applet, ni de plugin pour garder sa connexion ouverte[6],[7]. Toutefois, cette méthode souffre d'un sérieux inconvénient qui se situe au niveau du timeout autorisé par le navigateur, qui implique un rafraîchissement manuel de la page.

Long polling[modifier | modifier le code]

Le long polling n'est pas une vraie technique de push. Long polling est une variation de la technique de polling et permet d'émuler le mécanisme de push dans certaines circonstances où le push n'est pas possible comme pour les sites avec des règles de sécurité qui requièrent le rejet des requêtes HTTP/S entrantes.

Avec le long polling, le client demande des informations au serveur exactement comme dans le fonctionnement « classique » mais en s'attendant à ce que le serveur ne réponde pas immédiatement. Si le serveur n'a pas de nouvelles informations pour le client à la réception de la requête, au lieu de renvoyer une réponse vide, il garde la requête ouverte et attend que l'information demandée soit disponible. Une fois qu'il a de nouvelles informations, le serveur envoie immédiatement une réponse HTTP/S au client, terminant ainsi la requête HTTP/S. Généralement, à la réception de la réponse du serveur, le client lance immédiatement une nouvelle requête. De cette manière, la latence (le temps entre le moment où l'information devient disponible et la prochaine requête client) qui est présente avec les techniques de polling classiques est éliminée.[8]

Par exemple, BOSH est une technique HTTP populaire fondée sur le principe du long polling qui est utilisée comme une alternative aux connexions TCP continues lorsque ce type de connexion est difficile voire impossible à employer directement (dans les navigateurs web par exemple);[9] c'est aussi une technologie sous-jacente pour le XMPP utilisé par Apple pour gérer le push dans iCloud.

Historique[modifier | modifier le code]

Permettre à un système informatique l'initiative d'agir sur un terminal avait un précédent : X-window, où toutes les actions graphiques émanent du ou des systèmes autorisés (souvent implicitement) par le terminal. Pour cette raison[10], le terminal X se nommait alors serveur X et les applications en faisant usage des clients X, ce qui, bien que logique, ne manquait pas de surprendre.

Voir aussi[modifier | modifier le code]

Références[modifier | modifier le code]

  1. « Client pull/Server push implementations » (ArchiveWikiwixArchive.isGoogleQue faire ?), consulté le 2013-04-13
  2. CGI Programming on the World Wide Web O'Reilly book explaining how to use Netscape server-push
  3. « Server-Push Documents (HTML & XHTML: The Definitive Guide) » (ArchiveWikiwixArchive.isGoogleQue faire ?), consulté le 2013-04-13 O'Reilly book explaining server-push
  4. (en) « Spécifications du HTML5 »
  5. (en) « Using server-sent events »
  6. Pushlets introduction
  7. JavaWorld article about pushlets
  8. (en) « RFC6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP » (consulté le 14 mai 2016)
  9. (en) « XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH) » (consulté le 26 juin 2012)
  10. Il était admis que le serveur était en attente des ordres de tout client

Liens externes[modifier | modifier le code]