Limitation du nombre de requêtes

Nos navigateurs sont performants, ils savent gérer plusieurs téléchargements en parallèle. Ca nous permet de palier les serveurs lents, et d’optimiser le réseau. Le temps qu’on se connecte sur un serveur, qu’on fasse une requête DNS, le réseau reste occupé avec d’autres téléchargements.

Sans limite ?

On ne peut pas non plus tout télécharger en parallèle. Si chaque contenu met une seconde à se télécharger, il est plus intéressant de les voir arriver un à un chaque seconde séquentiellement. En parallèle ils pourraient mettre tous dix secondes et on les verrait tous arriver simultanément à la fin.

Ce serait consommateur de ressources, sur le poste du client et sur le serveur. Nos dix requêtes simultanées prendraient dix processus sur le serveur pendant dix secondes au lieu d’un processus qui traite séquentiellement les requêtes. C’est dix fois plus de mémoire par exemple.

Enfin, le nombre optimum de connexions simultanées dépend de la bande passante disponible. Pas la peine de lancer vingt connexions simultanées. C’est plus de charge sur le serveur, plus de charge sur le client, un peu plus de r&seau utilisé à cause de l’établissement des connexions, mais aucun gain.

Il faut une limite, tout en parallèle n’est intéressant pour personne.

Quelle limite ?

La RFC de HTTP 1.1 nous propose un maximum de deux requêtes persistantes simultanées par serveur. Les navigateurs jusqu’à récemment ont traduit ça en « deux requêtes persistantes simultanées par serveur qui répond en HTTP 1.1 ».

• Firefox : 2 connexions simultanées par domaine par défaut, mais Firefox 3 prévoit d’en autoriser 6.
• Internet Explorer : 2 connexions simultanées par domaine, sauf pour Internet Explorer 8 qui planifie d’en autoriser 6 aussi.
• Opera 9 et Safari 3 autorisent chacun 4 connexions simultanées par domaine.

Ces nombres sont augmentés si le serveur refuse les connexions persistantes, s’il répond en HTTP 1.0, ou si on passe par un proxy. Inversement, Microsoft Internet Explorer 8 tente de détecter si vous utilisez une connexion par modem RTC et revient alors à 2 requêtes simultanées par domaine pour ne pas saturer la ligne.

Plusieurs domaines

Jusqu’à récemment le conseil était d’étaler les ressources sur plusieurs domaines, de préférence 2. Cela permet de parallèliser les téléchargements puisque les limites sont « par domaine ». Au delà de 4 domaines l’équipe de performance Yahoo! a remarqué qu’entre une trop grande parallélisation et la multiplication des requêtes DNS, l’effet commençait à devenir négatif.

La question mérite d’être reposée sachant que Firefox et Microsoft Internet Explorer vont tripler le nombre de requêtes. Nous retrouverons par défaut dans le cas « ressources étalées sur 3 domaines » sans rien avoir à faire, et ceux qui utilisaient déjà plusieurs domaines voient leur traffic simultané multiplié d’autant.

La voie d’AOL

AOL a lui choisit une politique particulière mais pas forcément mauvaise : son serveur répond en utilisant le protocole HTTP 1.0. Cela a des implications, comme l’impossibilités d’utiliser des Etags, mais ces derniers posent presque plus de problème qu’ils n’en résolvent.

Le HTTP 1.0 leur suffit. Ils profitent alors automatiquement de plus de connexions simultanées de la part des navigateurs sans avoir à multiplier les domaines et les requêtes DNS. Ils n’auront du coup aucun problème du au changement de configuration par défaut des navigateurs : ils étaient déjà dans une configuration avec beaucoup de requêtes simultanées.

La recommandation

En attendant des mesures de performances plus concrètes prenant en compte les configuration des nouveaux navigateurs, garder la recommandation de l’équipe de performance Yahoo! est probablement le plus sage : étaler vos ressources sur deux domaines différents.

Un seul domaine, même en HTTP 1.0 comme AOL, ne vous permet pas d’utiliser un CDN pour diminuer la latence réseau. Plus de deux domaines risque de surcharger vos utilisateurs avec plus de connexions simultanées qu’il n’est bénéfique.

Le cadeau bonus c’est qu’en séparant les ressources statiques et dynamiques sur deux domaines, vous pouvez avoir une optimisation plus simple des ressources statiques : CDN, pas de cookie (c’est ça de gagné en traffic réseau), et entêtes d’expiration configurées globalement sur tout le domaine ; et une optimisation différente pour les ressources dynamiques : pas de keep-alive et entête imposant la revalidation des contenus pour éviter le cache.