http Keep-Alive avec plusieurs enregistrements A / AAAA
J'essaie d'estimer l'impact sur les performances de la publication de plusieurs adresses IP pour un nom d'hôte de site Web donné.
Les navigateurs choisissent-ils les adresses dans un ordre aléatoire?
Utilisent-ils la même adresse pour toutes les connexions ou multiplexent-ils les connexions entre différentes adresses en même temps pour toutes les demandes?
Comment cela affecte-t-il les requêtes Keep-Alive et Post-Keep-Alive? Par exemple, si un utilisateur effectue une recherche, je lui demanderais beaucoup d'utiliser le même serveur à partir de maintenant, car passer à la page 2 de la même requête de recherche sera probablement beaucoup plus rapide sur un serveur aussi actif. que sur un froid. Existe-t-il un moyen simple de s’assurer de cela, sans introduire de noms d’hôte à emplacement unique uniquement dans l’utilisation de www?
Les navigateurs choisissent-ils les adresses dans un ordre aléatoire?
Non. Le navigateur demande au système d’exploitation d’obtenir une adresse IP unique pour un nom d’hôte. Lorsque le navigateur effectue la demande, le système d'exploitation peut utiliser l'une des multiples stratégies pour déterminer l'adresse IP à utiliser. Ceux-ci inclus:
- Au hasard
- En alternance
- Celui qui semble être le plus proche
Utilisent-ils la même adresse pour toutes les connexions ou multiplexent-ils les connexions entre différentes adresses en même temps pour toutes les demandes?
La plupart des navigateurs mettent en cache les résultats d'une recherche DNS pendant un certain temps après leur demande par le système d'exploitation. En conséquence, un seul client ne sera généralement pas multiplexé.
Comment cela affecte-t-il les requêtes Keep-Alive et Post-Keep-Alive?
Une demande HTTP persistante est effectuée dans la même connexion que la demande précédente. En conséquence, aucune recherche DNS n'est effectuée, il utilisera le même hôte. Le délai d'expiration pour garder en vie est généralement d'environ 10 secondes. Il est donc peu probable que deux requêtes effectuées par le même utilisateur tombent dans cette fenêtre. Cependant, une demande de page puis une demande d'images et de javascript le font presque toujours.
En ce qui concerne les requêtes post-conservation, cela dépend de la durée pendant laquelle le navigateur met en cache les informations DNS. Il peut le mettre en cache pendant plusieurs minutes, mais pas nécessairement.
Vous voudrez probablement lire l'article de Wikipédia sur le DNS à tour de rôle. Il a quelques commentaires sous la section "inconvénients" que vous pouvez trouver utiles: http://en.wikipedia.org/wiki/Round-robin_DNS
Juste pour répondre à la partie de la question que Stephen Ostermiller n'a pas:
Par exemple, si un utilisateur effectue une recherche, je lui demanderais beaucoup d'utiliser le même serveur à partir de maintenant, car passer à la page 2 de la même requête de recherche sera probablement beaucoup plus rapide sur un serveur aussi actif. que sur un froid. Existe-t-il un moyen simple de s’assurer de cela, sans introduire de noms d’hôte à emplacement unique uniquement dans l’utilisation de www?
La solution évidente serait de déployer un équilibreur de charge avec persistance devant vos serveurs, de manière à ce qu'il puisse recevoir toutes les demandes des clients et les transmettre au serveur approprié.
Il y a plusieurs façons d'implémenter la persistance , y compris l'affinité IP du client, l'injection de cookies et l'apprentissage des cookies d'application. Pour votre cas d'utilisation, vous pouvez même baser simplement le choix du serveur sur le terme de recherche de l'utilisateur (probablement trouvé dans l'URL).
Selon la méthode utilisée, il peut même être possible d'avoir plusieurs équilibreurs de charge avec persistance devant le même pool de serveurs, travaillant ensemble, avec un DNS alternatif utilisé pour répartir les connexions entre les équilibreurs de charge. De cette façon, vous pouvez obtenir le meilleur des deux mondes: quel que soit l'équilibreur de charge interrogé par le client, la demande est (de préférence) transmise au même serveur principal.