NGINX

Qu’est-ce que NGINX? Son nom laisse présager peu de choses à vrai dire. NGINX se prononce comme Engine-X.

Il s’agit d’un logiciel qui agit comme un proxy inverse. C’est à dire qu’il va se placer en amont du ou des serveurs web et prendre, à leur place, la charge des requêtes web.

D’un point de vue de sécurité, il peut être utilisé pour abstraire totalement l’accès aux ressources web qui sont sur les serveurs. Par exemple, il est possible d’associer les requêtes du serveur A et B à des URL comme http://www.monsite.com/a/ et http://www.monsite.com/b/ sans que cela ne paraisse pour le commun des mortels.

Dans la majorité de cas, un proxy inverse comme NGINX est utilisé comme un outil permettant d’augmenter la performance d’un site web. Il est possible de répartir la charge des requêtes vers une ressource statique sur plusieurs serveurs ou même de procéder à la mise en cache localement du contenu accessible à partir du web.

Il est aussi possible d’utiliser NGINX comme un proxy de serveur courriel POP3, IMAP et SMTP.

NGIX est présent sur le web depuis maintenant huit ans et est développé sous une licence libre de style BSD. Initialement, il a été développé par un développeur Russe nommé Igor Sysoev. Les premières utilisations de NGIX ont été avec les sites de premier ordre Russes comme Yandex, Mail.ru et même Rambler.

Depuis,  l’utilisation de NGINX est en constante hausse. Des sites américains de haut niveau l’ont intégré dans leur architecture. On peut noter des sites comme Netflix, Pinterest et même Github.

Le principal point de vente de NGINX est sa capacité à prendre une charge considérable de requêtes simultanées avec une faible et prévisible trace en mémoire. Son architecture, basée sur des événements,  lui permettant, de façon asynchrone, de gérer les requêtes entrantes. Son architecture a été conçue spécifiquement pour adresser la problématique du C10k.

Qu’est-ce que le C10k? Il s’agit du nom qui a été donné à la problématique d’optimisation des serveurs applicatifs pour leur permettre de fournir plus de 10 000 connexions simultanées.

Pour les fans de statistiques, il est question d’une utilisation d’environs 2.5mo de mémoire pour chaque 10 000 connexions.

L’éventail des plateformes supportées est assez large. NGINX a été initialement développé pour les plateformes UNIX/Linux. On peut aussi noter que Windows est supporté.

NGINX n’est pas le seul de sa catégorie. Il existe d’autres solutions offrant un même genre se possibilités. Il y a notamment HAProxy qui agit un proxy inverse mais aussi et principalement comme un répartiteur de charge (Load balancer) ou même Varnish qui permet uniquement une cache HTTP.

À première vue, si j’avais l’occasion d’implémenter proxy inverse dans l’un de mes sites web, je le ferais initialement pour le contenu statique. Cela passe par les images mais aussi pour les scripts et les feuilles de style. Ils ne changent pas très souvent et ils peuvent être distribuées aux clients sans que ça ait à passer par le serveur web.

En plus de la cache, ces fichiers n’auraient l’obligation d’être distribuées sur le même serveur que celui qui en charge des pages web. Il pourrait y avoir un serveur dédié à l’hébergement du contenu statique.

La cerise sur le Sundae est l’annonce par l’équipe de développement de NGINX du support pour le protocole SPDY. Ce n’est pas déjà assez pour se laisser tenter par l’expérience?

Advertisements

SPDY – Le nouvel acronyme du web à venir

L’internet a toujours été une source d’innovation et de tentatives pour rentre l’expérience utilisateur la plus agréable possible. Cette amélioration se fait à plusieurs points. Il va d’améliorations à l’ergonomie design des pages web en passant par la façon dont les pages web sont indexées par les moteurs de recherche.

Un facteur reste, toutefois, au cœur des préoccupations lorsqu’il est temps d’améliorer l’expérience utilisateur sur le web : La vitesse. La rapidité à laquelle les données doivent être communiquées au visiteur est littéralement le nerf de la guerre. Ce constat est très analogue au concept de la saucisse Hygrade : Plus tu sers de contenu rapidement, plus tu seras capable d’en servir, plus ton site paraîtra rapide et mieux il sera référencé.

SPDY, c’est quoi?

SPDY (Comme dans l’expression Speedy) est un protocole développé par Google depuis déjà 2009. Le but de ce protocole est de remplacer directement HTTP 1.1 qui est le protocole de-facto sur Internet.

Un groupe de travail de l’IETF (Internet Engineering Task Force) a été mis en place pour définir quel sera le protocole sera utilisé pour ce qui a été nommé comme HTTP 2.0. Comme tout ce qui a trait à la standardisation des procédures et technologies entre les gros joueurs d’internet, l’enjeu est important car il est de déterminer quel protocole sera recommandé pour l’implémentation de HTTP 2.0.

Au menu, il y a trois protocoles à l’étude :

D’un point de vue technique

L’avantage proposé par SPDY est qu’il est conçu pour utiliser moins de connexions TCP que HTTP et il est aussi conçu pour utiliser TLS par défaut. Ceci veut donc dire que SPDY est par design plus rapide et surtout plus sécuritaire que HTTP.

Il faut aussi noter que SPDY est un ajout au fonctionnement actuel de HTTP. C’est à dire que SPDY modifie seulement la façon que les paquets de données sont envoyées par les serveurs aux clients. Cette modification se fait au niveau de l’ajout d’une couche Session (Bien située entre HTTP et SSL) lors d’une connexion TCP.

Comment plus rapide?

Le gain de vitesse de téléchargement est très intéressant. Selon les scénarios suggérés (Section Preliminary results), le gain de téléchargement varie entre 30% et 63%.

À titre d’exemple, un téléchargement qui prend 3111.916 millisecondes avec HTTP son équivalent avec SPDY prend environs 1695.72 millisecondes. Ici, on parle d’un gain de 45%.

Vocabulaire

La venue de ce nouveau protocole implique aussi un changement au niveau de la terminologie utilisée pour désigner les éléments faisant partie d’une connexion SPDY.

  • Stream : Représente l’équivalent d’une connexion / réponse du protocole HTTP.
  • Frame : Un Stream est divisé en Frames. Un Control Frame contient les entêtes HTTP et un Data Frame contient les données de ce frame.

L’ordre d’exécution

Le plus simple des scénarios prévoit l’exécution suivante  :

  • Le client initie une requête SYN_STREAM.
  • Le serveur envoie une réponse SYN_REPLY.
  • Le serveur envoie un ou plusieurs éléments DATA. Ceux-ci contiennent les données à retourner au client.

L’implémentation

SPDY est actuellement supporté entièrement par Google Chrome/Chromium et Firefox. Toutefois, il n’est pas activé par défaut chez Firefox. Pour l’activer, il faut aller mettre la variable network.http.spdy.enabled à true dans la section about:config.

Tout récemment, Opera a mis de l’avant le support de SPDY dans une version expérimentale de leur navigateur.

Il reste maintenant à Internet Explorer et Microsoft d’implémenter SPDY dans leur navigateur. Le chemin ne semble tout à fait clair de ce côté. Microsoft propose lui aussi un protocole visant à améliorer la vitesse de connexion au web : HTTP Speed+Mobility. Il semble donc que, tant et aussi longtemps qu’il n’y aura pas consensus sur le protocole à utiliser, Microsoft va être adepte du statut quo pour Internet Explorer.

Engagement envers SPDY

Il va de soi que Google a déjà mis de l’avant, il y a de ça un bon moment, SPDY sur ces services. SPDY est utilisé notamment chez GMail, Google+ ainsi que la recherche Google.

Des acteurs  importants du web ont signifié leur intérêt envers la bonification proposée du protocole HTTP.  Il y a notamment :

Est-ce que mon site est déjà SPDY?

Il y a actuellement deux indicateurs permettant d’identifier si un site utilise déjà SPDY.

La console interne de Google Chrome. Cet outil est accessible par l’adresse chrome://net-internals/#spdy. Dans la section « SPDY Sessions », vous pouvez voir un résumé des sites ainsi que certaines statistiques d’utilisation de SPDY du navigateur. En bonus, vous pouvez voir en temps réel le déroulement des connexions SPDY en cliquant sur le lien View live SPDY sessions.

Dans le cas où vous n’êtes pas très orienté statistiques et détails internes, je vous conseille d’installer l’extension vous permettant d’activer un témoin visuel pour indiquer la présence d’une connexion SPDY.

Ce qu’attends SPDY

SPDY / HTTP 2.0 a un bel avenir devant lui.

Le protocole livre exactement ce qu’il promet : Une amélioration de la vitesse de téléchargement du contenu qu’une page web. Le plus magique dans tout cela est que la transition à SPDY se fait sans aucun impact aux applications et aux utilisateurs. Cela veut dire que l’implémentation de SPDY se fait de façon transparente.

Le support pour SPDY est encore embryonnaire. Nous allons entendre encore plus en parler à mesure que les grands joueurs (ex: Facebook) vont le proposer à ses utilisateurs.

Do Not Track

Do Not Track (DNT) est un standard proposé par le W3C qui  permet aux utilisateurs d’internet ne désirant pas être suivi par des services de publicités ou d’analyse de visites de les notifier de leur intention de ne pas l’être. Cette intention se signifie à l’aide d’une entête HTTP ajoutée à toutes vos requêtes HTTP.

Historiquement, le suivi des visites et de l’analyse des comportements sur un site web était limité au clics et des chargements de pages. Depuis la venue des Cookies, les compagnies de publicités ont trouvé d’innombrables moyens de suivre vos tendances de visites sur internet et de vous afficher du contenu qui correspond à vos besoins potentiels.

Certaines compagnies ont clairement signifé leur intention par écrit de respecter l’affichage de l’intention de ne pas être suivi. Il n’y a actuellement pas de mécanismes permettant d’obliger une compagnie de marketing à respecter l’intention d’un utilisateur à ne pas être suivi. Le respect de DNT est principalement effectué de bonne foi par les services ayant signifé leur intention de respecter.

Il est à noter que, depuis mai 2012, Twitter a décidé d’aller de l’avant avec le respect de DNT auprès de ses utilisateurs. Il s’agit de la première compagnie d’importance à aller de l’avant avec cette décision.

La responsabilité du signalement de DNT revient entièrement au navigateur web. Il est proposé que l’activation de DNT doit se faire dans les paramètres de configuration du navigateur web.

Le support de DNT est actuellement limité selon le navigateur web. Un support natif à Do Not Track est offert dans Internet Explorer 9 et Firefox 11. Google Chrome offre un support à DNT par le moyen d’une extension à télécharger. Le support officiel par Google Chrome est à venir selon les dires de Google.

L’activation de DNT est très simple. Sous Firefox, il faut aller sous Options \ Privacy et activer l’option Tell websites I do not want to be tracked.

Dans le concret, l’activation de cette option ajoutera l’entête HTTP DNT : 1 à vos requêtes HTTP.

L’ajout de Do Not Track est un premier pas dans le respect de la vie privée des internautes. Il va falloir encore quelques temps avant que son utilisation devienne une pratique courante dans l’industrie de la publicité et du marketing internet.

À mon avis, les attentes aux promesses de DNT ne doivent pas très élevées car une partie de son succès est dans les mains des compagnies de publicités qui ont des intérêts très différents de l’utilisateur moyen. Toutefois, il ne s’agit pas d’une raison de reculer pour faire avancer le respect des de nos droits sur le web.