Qu'est-ce qui est plus rapide? Liaison à chaud (liaison intégrée) à un Absolute URI ou hébergement de la ressource vous-même et en utilisant un URI relative ?
5 Réponses :
J'imagine que les seules choses qui affectent une telle situation sont les vitesses relatives des serveurs en question (pour la vitesse) et si vous vous attendez à ce que ce code soit exécuté sur tout autre site (pour la maintenabilité).
supposer que la ressource n'est pas intégrée dans le document HTML lui-même (c'est-à-dire qu'il est lié), et la ressource est sur le même serveur avec le même nom d'hôte, le temps de récupérer la ressource via URI absolu ou relatif doit être pratiquement identique. . Une demande HTTP supplémentaire sera soumise de toute façon. Si vous souhaitez scinder le «pratiquement identique», je me pencherais vers le chemin relatif étant une quantité très, très très faible plus rapide, en raison de la plus petite quantité de HTML qui a besoin d'analyses, le parcours analysant (comme vous l'avez mentionné) potentiellement plus rapide (en raison de la chaîne Tokenizer de ne pas avoir à traiter de la partie de domaine de l'adresse / l'adresse étant plus courte). La différence ici n'est réaliste que pour la curiosité de la curiosité. Je ne peux pas imaginer un site optimisé à ce niveau (bien que cela puisse établir une bonne règle de base? Le chemin relatif vous permet de changer librement le domaine / chemin du site du site. sans avoir à réécrire toutes les URI contenues dans ..)
Une chose à considérer serait si la ressource est pas hébergé sur le même serveur, et le serveur du document HTML de référencement est activé, une autre connexion TCP devra être initialisée pour se connecter à Le deuxième serveur (ainsi qu'une requête DNS étant faite pour résoudre le nom d'hôte de l'autre serveur, en supposant que l'accès ne soit pas via une adresse IP), ce qui entraîne une surcharge supplémentaire par rapport à plusieurs ressources référencées sur le même serveur (où les demandes d'obtention de GET être émis dans la connexion TCP existante).
La même chose s'appliquerait à un serveur qui n'a pas de conserve activé; Une connexion TCP sera initialisée pour chaque ressource demandée.
Ceci est plus à voir avec des trucs de niveau inférieur comme TCP plutôt que http per-se. Si vous obtenez deux éléments du même serveur Webserver, votre navigateur est susceptible de les tirer sur la même connexion TCP. C'est deux transactions HTTP sur une connexion TCP. Cela évite les frais généraux de faire une autre connexion TCP. Cette surcharge est faible en termes de circulation, mais peut impliquer beaucoup de latence.
OTOH, faisant deux transactions HTTP où elles vont chacune à différents serveurs, peut-être plus rapidement, ou peut-être pas. True, vous avez la tête de deux connexions TCP. Dans ce cas, ils sont Serialized-One doit terminer avant que le second puisse commencer. Cependant, si vous tiriez de nombreux objets, les 2e, 3ème, 4ème ... Les connexions pourraient tous procéder en parallèle, masquant le problème de la latence. Dans ce scénario, les choses peuvent aller beaucoup plus rapidement que de petits objets peuvent ne pas être soumis à la limitation de votre bande passante de votre fournisseur de services Internet.
Les eaux sont boueuses.
Il suffit de garder un œil sur la latence et la bande passante. Dépend vraiment du nombre et de la tailles de vos ressources.
La bonne réponse est - cela dépend.
hotlinking peut être lent car -
L'hébergement sur votre serveur peut être lent car -
Si vous supposez que les deux serveurs sont identiques à tous égards, je dirais que l'hébergement sur votre serveur sera plus rapide. Cela est vrai surtout sur de nouveaux navigateurs où le nombre de connexions par hôte est de 6.
Mais malheureusement, les choses ne sont jamais aussi simples. Je recommanderais d'utiliser le hotlinking uniquement si -
Pour tous les autres cas d'utilisation, vous préférez l'hébergement sur vos propres serveurs.
Bien que "votre serveur" pourrait être res1.domain , res2.domain , c'est-à-dire par type (ou charge) sur plusieurs domaines internes (ce woul diffère de l'implicit Équilibrage de la charge où il "a l'air différent" au navigateur). La question DNS devrait être une non-existence une fois mise en cache.
L'heure dont le client doit résoudre l'URI relative est absolument négligeable.
Il ne fait aucune différence si vous avez un lien vers une ressource dans le même domaine du document en utilisant des URIS absolue ou relative.
La seule différence sera lorsque la ressource est hébergée sur un autre serveur. Ensuite, vous aurez besoin d'une connexion TCP supplémentaire sur ce serveur alors qu'une demande HTTP supplémentaire à un serveur que vous avez déjà une connexion pour pourrait utiliser cette connexion.