Optimisation des requêtes HTTP: quelle est la limite?

Question

Il est maintenant de notoriété publique de combiner des feuilles de style et des scripts afin de réduire les requêtes HTTP. J'ai 2 questions:

1. Combien coûtent-ils, vraiment?
2. Quand une requête est-elle trop importante, doit-elle être scindée?

Je ne peux pas trouver les réponses à ces deux questions dans toutes les lectures en ligne je l'ai fait, comme Yahoo! Best Practices qui indique un certain nombre de fois que les requêtes HTTP sont coûteuses, mais jamais citer ni pourquoi ni comment.

Merci d'avance.

Answer 1

Une requête HTTP nécessite une connexion TCP/IP à effectuer (Pensez, à 3 voies handshake handshake) avant de pouvoir traiter la requête HTTP elle-même

Cela implique au moins un retard d'envoyer le message SYN le serveur et en récupérant le SYN/ACK (Il envoie ensuite l'ACK pour OUVRIR le socket). Donc, disons que le délai entre le client et le serveur est uniforme dans les deux sens et 50 ms, ce qui entraîne un délai de 100 ms avant de pouvoir envoyer la requête HTTP. Il faut alors 100 ms de plus avant de commencer à récupérer la requête (Envoie la requête, puis les réponses du serveur).

Bien entendu, vous devez également prendre en compte qu'un navigateur Web standard limite le nombre de requêtes HTTP simultanées qu'il traite en même temps. Si vos demandes doivent attendre, vous n'obtenez pas ce temps de prise en charge gratuitement (pour ainsi dire), car vous devez attendre qu'une autre connexion se termine également. Les serveurs jouent également un rôle, en fonction de la façon dont ils gèrent les requêtes.

Answer 2

Je n'ai pas de réponse sur le coût de la requête HTTP, mais c'est toujours une bonne idée de réduire les allers-retours entre le client et le serveur. Si vous avez une quantité fixe de données à transmettre, il sera toujours préférable de le faire en moins de demandes.

Answer 3

1. Chaque fois qu'une demande est faite, elle est soumise aux dures réalités de la fiabilité du réseau. Deux demandes faites en succession rapide à partir du même emplacement peuvent prendre des routes entièrement différentes, donc avec chaque demande, vous ajoutez un élément d'imprévisibilité en termes de performance. Une seule demande consolidée peut aider à atténuer ce risque. @Dan McG a écrit un point sonore sur la surcharge de la prise de contact TCP.
2. HTTP ne se soucie pas de la taille de la demande , car il sert de protocole de couche d'application sur la pile IP (Internet Protocol Suite). C'est pour le TCP/IP de s'inquiéter, ce qui serait préoccupant pour l'éditeur est de garder les tailles de document/fichier aussi petit que possible, et assez petit pour que leur application soit suffisamment performante.

Espérons que cela a du sens.