Pour le problème 3), ça ne concerne pas que les équipements intermédiaires. Les serveurs (hosts) sont aussi impactés. C'est relativement coûteux en ressources de maintenir des connexions keep-alive et c'est souvent un des premiers paramètres pour optimiser un serveur web pour qu'il soit capable d'encaisser de plus fortes charges.
Pour 1), quel est l'intérêt de HTTP/1.1 si c'est pour ouvrir autant de connexions ? On se retrouve à peu de chose près dans la situation de HTTP/1.0. D'un coté, on se plaint que les délais de connexion sont grands et de l'autre, on s'arrange pour créer un maximum de connexions en //. C'est un peu contradictoire, non ?
Les navigateurs ont bien d'autres problèmes à traiter que juste les délais de connexion. L'un de ces problèmes est le TCP slow start. Une connexion TCP ne permet pas d'utiliser tout de suite beaucoup de bande passante, il faut attendre qu'elle "chauffe". Les navigateurs font donc appel à plusieurs connexions en parallèle pour pouvoir télécharger plus vite les différentes ressources d'une page web et donc l'afficher plus vite.
Pour le 2), cela me semble plus un problème de gestion d'architecture qu'un problème de pile TCP/IP. Le problème est la dispersion des ressources. Une page déterminée devrait être chargée au maximum via la même IP.
Si tu te places du coté client, tout pouvoir charger depuis une même adresse IP serait effectivement idéal. Mais il faut également voir l'autre coté. Quand on se place du coté serveur, il y a pas mal de bonnes (ou mauvaises) raisons de vouloir faire autrement. par exemple, on veut souvent pouvoir servir le HTML généré dynamiquement depuis nos serveurs, mais laisser des CDN s'occuper des images, css et js pour des raisons économiques.
[^] # Re: Hein ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Réduire la latence des connections TCP, enfin. Évalué à 2.
Pour le problème 3), ça ne concerne pas que les équipements intermédiaires. Les serveurs (hosts) sont aussi impactés. C'est relativement coûteux en ressources de maintenir des connexions keep-alive et c'est souvent un des premiers paramètres pour optimiser un serveur web pour qu'il soit capable d'encaisser de plus fortes charges.
Les navigateurs ont bien d'autres problèmes à traiter que juste les délais de connexion. L'un de ces problèmes est le TCP slow start. Une connexion TCP ne permet pas d'utiliser tout de suite beaucoup de bande passante, il faut attendre qu'elle "chauffe". Les navigateurs font donc appel à plusieurs connexions en parallèle pour pouvoir télécharger plus vite les différentes ressources d'une page web et donc l'afficher plus vite.
Si tu te places du coté client, tout pouvoir charger depuis une même adresse IP serait effectivement idéal. Mais il faut également voir l'autre coté. Quand on se place du coté serveur, il y a pas mal de bonnes (ou mauvaises) raisons de vouloir faire autrement. par exemple, on veut souvent pouvoir servir le HTML généré dynamiquement depuis nos serveurs, mais laisser des CDN s'occuper des images, css et js pour des raisons économiques.