Keep-alive

De manière générale, les liaisons de communication infinies d'un réseau, maintenues en fonctionnement jusqu'à la rupture de connexion par le client ou le serveur, sont référencées comme des Keep-Alive, keep-alive ou keep alive. La caractéristique essentielle des connexions keep-alive est l'échange de messages sans contenu entre un serveur et un client. A l'aide de ses messages, un utilisateur du réseau (client ou serveur) peut contrôler si la connexion est toujours établie et empêcher que celle-ci ne cesse. Si la connexion est toujours établie, il peut l'utiliser pour un échange de données.

Les connexions keep-alive sont également connues sous les appellations HTTP keep-alive, persistante HTTP-connection et HTTP connection reuse. Le protocole HTTP 1.1 prend habituellement en charge le keep-alive et le HTTP Pipelining, afin de traiter les demandes batch. HTTP 2 étend le procédé de connexions permanentes à des caractéristiques encore supplémentaires (par exemple le procédé de multiplexage).

Informations générales sur le sujet

Le réseau de communication classique travaille selon un schéma de question-réponse : un client demande certaines informations spécifiques à un serveur ; le serveur répond en confirmant la présence de ces informations - ou rejette et renvoie un message d'erreur. Si les données sont disponibles, il les transmet au client en établissant une nouvelle connexion. Enfin, le client interprète les données et les affiche ; dans le cas où elles ne sont pas complètes, il demande des données supplémentaires afin de compléter l'affichage. Dans cette démarche également, une nouvelle connexion est utilisée, contenant parfois des données inutiles (engl. : overhead). Selon le protocole HTTP 1.0, pour chaque requête, une nouvelle connexion TCP est établie. Cela signifie que chaque requête d'un client est traitée individuellement par le serveur, et dans la mesure du possible, répondue individuellement.

Il arrive souvent qu'un site web se compose de plusieurs sources de données ; à titre d'exemple, les données HTML, attributs CSS et scripts qui tous, affectent les interactions d'utilisateur. Les images et fichiers multimédias en font aussi partie. Pour le HTTP 1.0, chaque donnée requiert une connexion séparée, qui devra être à nouveau interrompue par la suite. Pour des sites web plus importants, cette approche n’est déjà plus efficace car la charge du réseau est trop importante (en anglais network congestion). Afin d’éviter que de nombreuses connexions individuelles aient à être établies puis interrompues, la gestion du réseau est étendue à des connexions permanentes et au HTTP Pipelining. Il est ainsi possible selon le protocole HTTP 1.1 de réaliser de multiples questions et réponses par connexion. Chaque connexion envoie et reçoit des messages spéciaux keep-alive entre le client et le serveur, puis est capable de stocker les questions dans un Pipeline.

Mode de fonctionnement

La plupart des serveurs peuvent être configurés et établis pour supporter le keep-alive[1]. Côté client, les navigateurs les plus utilisés sont déjà en mesure d’établir des connexions permanentes. Côté serveur, cela dépend en revanche de la configuration : en fonction du Framework utilisé (technologie et langage de programmation), les principales différences s’observent au niveau de la syntaxe et la sémantique. Sur un serveur http Apache, le mode keep-alive est autorisé dans le fichier de configuration "httpd.conf". Trois propriétés sont ainsi particulièrement importantes[2] :

  • KeepAlive : sous ce mode, les variables peuvent prendre les valeurs on et off. Sous HTTP 1.1 la valeur par défaut est on.
  • MaxKeepAliveRequests : ce paramètre définit la valeur maximale de questions possibles par connexion. Une valeur entre 50 et 100 est la plupart du temps suffisante. Toutefois, cette valeur est dépendante de la taille du projet web et du nombre de données que le site web doit contenir.
  • KeepAliveTimeout : quand le Serveur ne reçoit pas de "request" ou demande, il connait un temps mort et maintient la connexion au ralenti, jusqu’à ce qu’elle soit rompue. Le paramètre timeout définit le temps d’attente maximum d’une nouvelle requête par un serveur, avant de rompre la connexion. Un timeout de 10 secondes est considéré comme idéal, cependant sur certains sites web connaissant un trafic important, le timeout peut être augmenté.

Lorsque les propriétés et valeurs correspondantes sont fournies dans la configuration de serveur, le serveur apache renvoie des réponses aux questions ressemblant plus ou moins à cela :

~$ curl -I https://www.domain.com/file.html
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Date: Thu, 15 Jan 2015 16:45:29 GMT
Content-Length: 1845
Keep-Alive: timeout=10, max=20
Server: Apache/2.4.9 (Unix) PHP/5.6.2

Le principe est similaire pour tous les serveurs : lesdits messages keep-alive, contenant peu d’informations, sont échangés entre serveur et Client. Ils permettent au client d’obtenir plusieurs données au sein d’une seule connexion. Un message keep-alive est transmis via le HTTP-Header. Ce dernier indique au client ou au serveur si la connexion doit être maintenue. Chaque question est ensuite traitée sur une connexion. C’est seulement une fois que la connexion est rompue par l’un des participants (serveur ou client), que l’interaction entre multiples questions et réponses n’est plus possible.

Keep-alive par .Htaccess

Quand l’opérateur du site web n’a pas accès à la configuration du serveur, alors les changements peuvent aussi être pris en charge dans le dossier .htaccess. Ce dernier remplace la configuration du serveur Apache, en ajoutant le code source suivant :

<IfModule mod_headers.c>
Header set Connection keep-alive
</IfModule>

Ainsi, chaque requête du header keep-alive peut être indiquée. Il est recommandé de faire un test pour vérifier si le changement souhaité a été implémenté par le serveur. Des définitions plus précises sur les paramètres timeout et Nombre max de requête ne peuvent en revanche qu’être modifiées dans les fichiers de configuration des serveurs correspondants.

Pertinence pour la programmation

Selon le protocole http 1.1, les connexions permanentes sont définies comme étant le standard. Le protocole http 2 élargit ce standard en un procédé Multiplex qui optimise encore plus le transfert de données. L’infrastructure technique et le client définissent si, et dans quelle mesure ces possibilités sont applicables. Cela veut dire que le protocole rend possible différentes optimisations, dont la mise en place doit avoir lieu côté serveur.

Pour certains projets spécifiques, les headers keep-alive sont particulièrement recommandés. Cela vaut pour les sites web avec beaucoup de données et un contenu multimédia important ainsi que les boutiques en ligne établies sur connexion HTTPS. Le HTTPS est très exigeant en transfert de données, puisque la connexion est assurée par SSL (Secure Socket Layer). En y annexant un header keep-alive, les vitesses de chargement du site web peuvent être massivement améliorées, car les temps de latence entre les différentes connexions sont évités. Il en résulte simplement une seule connexion, capable de prendre en charge de multiples questions et réponses que le serveur peut traiter en séquence.

De plus, lors de la mise en place de nouvelles connexions sur la couche TCP/IP (qui réside sous la couche d’application du protocole http), des ressources comme le CPU (Central Processing Unit) et la mémoire sont nécessaires. Ainsi le CPU peut être soulagé grâce à un header keep-alive : l’ordinateur peut établir beaucoup moins de connexions.

Références

  1. How to enable keep alive varvy.com. ouvert le 01.09.2017
  2. Apache Performance Tuning: KeepAlive to remove latency maanasroyy.wordpress.com. ouvert le 01.09.2017

Lien web

Catégorie