Dans ce billet, nous allons soulever les problèmes liés à la mise en place du mécanisme de Server Push dans une application web.
En reprenant le même exemple abordé dans l’article (http://www.jdkcodingclub.net/2008/11/definition-principe-polling-scrutation/), notre client envoie une requête pour récupérer sa nouvelle ligne :
http://mon.chat.app/getChatLine?idx=200
Cependant, au lieu de retourner « n’existe pas » (si la ligne n’existe pas), le serveur ne répond pas volontairement. Cela a pour effet de donner l’impression que le serveur est lent étant donné qu’il ne répond pas. Mais, cela fait parti du mécanisme. Je m’explique. Lorsque la 200éme ligne est envoyée par son interlocuteur, cela réveille le serveur, il complète la requête (en y insérant le message) et fini par envoyer la 200éme ligne au client.
Avec ce mécanisme, le client n’a pas besoin de continuellement demander à récupérer la dernière ligne. Il la demande 1 fois et il attend que le serveur lui donne.
L’idée est pourtant simple, mais malheureusement le protocole HTTP n’a pas été pensé de cette manière. Cela va donc nous poser un certains nombres de problèmes.
Flush
Le protocole HTTP ne supporte pas bien le flush. Inutile donc de vouloir garder la connexion ouverte et de « pousser » les données. Ce n’est pas du streaming, pourtant cela marche, mais pas très bien lorsque le client est derrière un routeur qui passe par un proxy qui lui-même passe par un autre chemin. Bref, HTTP ne supporte pas le flush.
Timeout
Lorsqu’un navigateur attend une ressource d’un serveur et que celle-ci tarde à venir, le navigateur affiche la page du « timeout » au bout d’un certain temps. Pour lui, le serveur ne répond pas (pour diverses raisons). Mais il n’y a pas que le client et le serveur… Entre les deux, les proxy, les routeurs et autres passerelles ne savent pas faire la différence entre une connexion lente (où le timeout est justifié) et une connexion maintenue (gelée ou freezed) volontairement par un serveur (rappelons qu’il ne répond pas intentionnellement). Il faut donc prendre en compte qu’une connexion gelée ne peut pas l’être éternellement.
2 connexions maximum
La majorité des navigateurs ne peuvent établir que 2 connexions simultanées vers un domaine (exemple : « www.chat.app ». S’il y en a 3, alors la troisième requête est placée en file d’attente jusqu’à ce que le serveur est fini de traiter l’une des 2 premières.
Une requête maintenue en server push consomme déjà la moitié des connexions possibles… Dans l’exemple d’un chat, on utilise à 100% les 2 connexions possibles (une pour le mécanisme de server push et l’autre pour envoyer un message). A noter que s’il y a 2 requêtes gelées simultanées sur le même serveur, le client sera bloqué et ne pourra plus dialoguer avec le serveur. Il devra donc attendre la notification d’un événement ou que le serveur relâche un des 2 requêtes gelés s’il n’y en a pas.
Google Maps fonctionne de cette manière pour récupérer plus vite les images d’une carte satellite. Pour pouvoir bénéficier de plus de 2 connexions, il se connecte à khm1.google.com, khm2.google.com, mt1.google.com etc… Il cumule donc les connexions. La limitation est donc un faux problème car des solutions simples existent.
Sur notre application, on pourra donc avoir un sous domaine « serverpush.chat.app » gérant les requêtes de type Server Push afin d’éviter le blocage de requêtes entre le client et le serveur et d’assurer ainsi une meilleure performance et robustesse de l’application.
Résumé
Pour résumer, on peut dire que le protocole HTTP ne favorise pas vraiment l’implémentation du mécanisme de server push dans une application web. Bien heureusement, nous verrons que des solutions existent. Cependant, elles se contentent essentiellement de contourner les problèmes (flush, timeout et limitation du nombre de connexions). L’utilisation du web change, le web change, en attendant une nouvelle version du protocole HTTP, il faudra bien bricoler !
Romain LAFOND
