Accélérer le chargement des pages ? Sérieusement ? Oui, vous pouvez activer le téléchargement en parallèle des ressources et spécifier le nombre maximal de requêtes/connexions que le navigateur enverra aux serveurs.

Voici ce que l'on trouve partout sur le net:

Tapez about:config dans la barre d'url et cliquez sur "Je ferai attention, promis !"
Placez network.http.pipelining et network.http.proxy.pipelining à true,
Placez network.http.pipelining.maxrequests à 8

La vitesse de la navigation dépend de la connexion de la personne mais aussi (de plus en plus souvent) de la latence du réseau. Et pour la latence on ne peut rien faire.

On trouve souvent des valeurs comme 32 connexions simultanées !!! Pourquoi pas 500 voire 21122012 pour la fin du monde ? N'importe quoi !
On ne doit pas dépasser 8 connexions, la plupart du temps 2 voire 4 suffisent !

De toute façon avec ce genre de réglages, un serveur bien configuré vous enverra promener.

Sommaire

Citations

Décrit comme "a pain in the ass" comme disent nos amis outre-manche. Cette extension permet de faire deux choses magnifiques : pré-charger (ie prefetching) des choses en avance pour que vous les ayez en cache quand vous avez éventuellement envie d'aller les voir, augmenter le nombre de connexions concurrentes (i.e. pipelining) à des valeurs dépassant largement les préconisations des RFC (jusqu'à 8 en mode "turbo"). Résultat des courses, des utilisateurs bien peu civiques qui pourrissent la bande passante, souvent pour des prunes et vous explosent vos quotas de connexions simultanées. Source: Optimisation d'apache.


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. Source: Limitations du nombre de requêtes.


La question spécifique d’un navigateur qui ouvre plusieurs connexions avec la même destination a été réglée par la [RFC2616], qui déclare au paragraphe 8.1.4 que "les clients qui utilisent des connexions persistantes DEVRAIENT limiter le nombre de connexions simultanées qu’elles entretiennent avec un serveur donné. Un client d’un seul utilisateur NE DEVRAIT PAS entretenir plus de deux connexions avec un serveur ou mandataire quelconque." Source: Principes du contrôle d’encombrement S. Floyd - RFC2914.


Ainsi, HTTP 1.1 n'autorisait que deux connexions TCP simultanées vers le même serveur (RFC 2616, section 8.1.4, mais le RFC 7230 a libéralisé cette consigne). Les navigateurs en ouvrent en général plus que cela, pour éviter l'attente due à la faible taille de la fenêtre TCP. (Voir « A Swifter Start for TCP », par Partridge, C., Rockwell, D., Allman, M., Krishnan, R. et J. Sterbenz, rapport technique n° 8339 de BBN en 2002.) C'est égoïste de leur part (cela s'oppose aux mécanismes de contrôle de congestion de TCP) et cela ne devrait logiquement plus être nécessaire avec le déploiement d'IW10. Le RFC conseille donc de réduire le nombre de connexions HTTP simultanées. Source: Increasing TCP's Initial Window.


Côté serveur, comment se débarrasser des indésirables ?

Les éléments qui suivent concernent le serveur web et proxy inverse Nginx, mais peuvent aisément être appliqués aux technologies en voie d'extinction comme Apache :p. Notez que les quelques règles présentées ici peuvent tout à fait faire partie d'une protection anti-ddos en combinaison avec iptables et/ou fail2ban.

Vérifiez que le module ngx_http_limit_req_module est bien actif:

nginx -V

Editez le bloc http{} du fichier /etc/nginx/nginx.conf:

#Connexions maximum par IP (15 par IP)
limit_conn_zone $binary_remote_addr zone=limit_per_ip:10m;
limit_conn limit_per_ip 15;

#Nombre de requêtes/s maximum par IP (150 requêtes par seconde, en moyenne et en pics)
limit_req_zone $binary_remote_addr zone=allips:10m rate=150r/s;
limit_req zone=allips burst=150 nodelay;

Adaptez évidemment les valeurs spécifiées à la configuration du serveur, la connexion utilisée, et aux pages hébergées. N'hésitez pas à redéfinir les zones selon vos besoins dans les blocs location{} des virtual hosts.

Remarque:
Toujours dans le bloc http{}, pensez à faire les includes des vhosts APRES la définition des zones ci-dessus. Sans cela vous aurez des problèmes si vous redéfinissez les zones dans des emplacements spécifiques du serveur (variables non définies).

Remarques sur quelques paramètres:
nodelay permet de ne pas reporter les requêtes excessives. Elles sont bloquées et c'est tout.
1m permet de mémoriser 16000 adresses au format binaire dans 1mb de mémoire. Si cette mémoire est remplie, le serveur passe en mode "Erreur 503" pour tout le monde.

Conclusion

Vous utilisez Firefox; c'est bien et c'est une question de bon sens. Pour des raisons de performances, de sécurité, de fonctionnalités, et d'éthique il est difficile de ne pas passer pour un guignol en prônant une autre solution.

Bref, en ce qui concerne le sujet originel, laissez vos navigateurs gérer les paramètres de connexion. Si les requêtes simultanées vous font de l'œil, activez le pipelining mais laissez les autres paramètres tranquilles.

Si vous êtes administrateur d'un serveur web, n'hésitez pas à rejeter en bloc les navigateurs égoïstes.

Références