Bonjour Nal,
Aucun rapport avec le sujet de ce journal, mais Barack Opama (tout du moins son équipe de campagne) a lancé récemment une page « The Life of Julia » (la vie de Julia). La page montre les moments de la vie d'une femme si Obama est réélu en opposition à si Mitt Romney le remplaçait.
Pour ceux qui vivent dans une cave, la course pour le poste de président bas son plein aux outre-atlantique. Ayant entendu parlé de ce site, je me rend dessus en me disant « ça doit être du flash », ça ne marchera pas. (Juste pour mettre dans le contexte, je n'ai pas flash et utilise NoScript pour assainir le web.)
Et je découvre une page avec des animations entièrement faites en JavaScript (« en HTML5 » comme diraient les marketeux, il y a 5 ans, le terme était « DHTML »). Je commence à autoriser le JavaScript pour la page, et je me rend compte qu'il faut autoriser « bostatic.com ».
Ceci n'est pas une pratique isolée. Beaucoup de sites utilisent cette technique qui consiste à mettre le JavaScript, images ou css sur un autre domaine (pas un autre sous domaine, mais vraiment un autre domaine à part). Google utilise gstatic.com, Facebook utilise fbcdn.net, et je n'en ai pas d'autre à l'esprit mais je sais qu'il y en a.
Quelqu'un peut-il m'expliquer pourquoi les webmaster/administrateurs systèmes font ça ? Parce que j'ai vraiment l'impression que c'est juste de la pure connerie.
- Des développeurs qui utilisent l'achat de plein de domaine supplémentaire en falsifiant les prix pour avoir un plus gros budget ?
- Un patron qui veux facturer plusieurs domaines, pour facturer plus cher ?
- Des adminsys incompétents qui n'ont jamais entendu parlé des sous domaines ? (Peut-être viennent ils de l'équipe qui gère voyage-sncf.com, ter-sncf.com, 12-25-sncf.com, senior-sncf.com ?)
- Des gens du marketing qui trouvent que ça en jette ?
Pour ceux qui s'en foutent ou n'ont pas la réponse, voici une Nimage dont la lecture en diagonale est intéressante.
# Réponse
Posté par niconoe . Évalué à 10.
C'est principalement pour une question de performances. Les (beaucoup de?) browsers ont ne limite du genre: X téléchargements simultanés du même serveur. En faisant ça, tu contournes donc cette limite. Et coté serveur aussi, ça te permets de répartir ta charge vers différentes machines (configurées aux petits oignons selon le type de contenu), ce qui ne parait pas complètement stupide quand on s'appelle Google ou Facebook.
Je suis bien d'accord que ces techniques pourraient être utilisées sous un domaine unique (avec des proxys reverse et compagnie si nécessaire), mais le fait est que ça ne dérange que les types comme toi qui regardent partir les requêtes HTTP unes par unes.
[^] # Re: Réponse
Posté par vjm . Évalué à 8.
En fait ça vient carrément de HTTP/1.1 qui encourage (c'est un SHOULD et pas un MUST) à limiter le nombre de sessions qu'un client doit maintenir vers un serveur. A mon avis, le but était d'encourager l'usage des nouvelles fonctionnalités de HTTP/1.1 soit les connexions persistentes et le pipelining. Ça n'a pas empêché plein de navigateurs de dépasser la limite recommandée de 2 connexions et de continuer à augmenter la limite régulièrement (on doit être à 16 dans IE9).
C'est une astuce qui est devenu particulièrement populaire après les différentes conférences (et le livre) de Steve Souders, spécialiste des performances chez Yahoo! puis Google.
http://yuiblog.com/blog/2007/04/11/performance-research-part-4/
http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/
[^] # Re: Réponse
Posté par netsurfeur . Évalué à 10.
Vos deux réponses expliquent l'intérêt d'utiliser des noms d'hôtes différents.
Ça n'explique pas pourquoi les domaines sont différents (google.com/gstatic.com, facebook.com/fbcdn.com), ce qui est la question de ce journal.
Pourquoi xyz.gstatic.com plutôt que xyz.gstatic.google.com ?
[^] # Re: Réponse
Posté par saimn . Évalué à 10.
[^] # Re: Réponse
Posté par ribwund . Évalué à 3.
Ça limite aussi potentiellement les XSS et autre non ?
[^] # Re: Réponse
Posté par GG (site web personnel) . Évalué à 2.
Les cookies peuvent être spécifiques pour un domaines, ou des sous-domaines.
C'est certain qu'il y a forcément un mélange impossible à éviter?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Utilisation de CDN ou Content Delivery Network
Posté par Framasky (site web personnel) . Évalué à 10.
En gros, t'as tout une chaîne de serveurs de contenus statiques répartis sur la planête et c'est le plus proche de toi en terme de réseau qui te répondra (https://en.wikipedia.org/wiki/Content_delivery_network). Bien sûr, optimisé, load balancé, toussa…
Personnellement, comme je n'ai pas de sous et que je ne fais pas confiance aux grosses boîtes, je délivre mes Nimages depuis mon seul petit serveur.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Utilisation de CDN ou Content Delivery Network
Posté par Niniryoku . Évalué à 1.
Parce que le site de campagne de barack obama sera visité dans le monde entier ? Je reconnais que les exemples que j'ai pris sont des gros sites avec des grosses charges. Mais j'ai déjà remarqué cette pratique sur plein de petit sites.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Utilisation de CDN ou Content Delivery Network
Posté par claudex . Évalué à 5.
Il y a pas mal d'américains à l'étranger, donc c'est bien possible. De plus, il y a des chances que le CDN aient même des serveurs à différents endroits des USA pour bien répartir la charge.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Utilisation de CDN ou Content Delivery Network
Posté par Pierre Carrier . Évalué à 3.
— Réponse d'un résident français à un autre résident français, telle que lue par un résident suédois.
Par ailleurs, il faut se souvenir que les États-Unis c'est grand, et leurs architectures réseau sont relativement décentralisées. Si tu veux couvrir tout leur territoire avec des faibles latences et/ou bons débits, un CDN vaut le coup. http://www.datacentermap.com/ixps.html
# Mauvaise utilisation des cookies ?
Posté par Kioob (site web personnel) . Évalué à 4.
Je me retrouve à conseiller la même chose à certains de mes clients : en effet ils arrivent que ces développeurs collent leurs cookies en *.domaine.tld, et quand ce n'est pas eux les outils publicitaires ou encore Google Analytics s'en chargent.
Au final on se retrouve avec le sous domaine "static.domaine.tld"/"cdn.domaine.tld" aussi pollué que les sous domaines principaux, et la solution la plus simple est alors d'utiliser un domaine différent.
alf.life
# CDN
Posté par ckyl . Évalué à 10.
Par ce que ceux que tu prends pour des cons savent de temps en temps de quoi ils parlent. Le contenu statique qui est sur bostatic est délégué à un CDN, un simple traceroute te montrera que tu ne traverse pas l'atlantique pour accéder au contenu de ce domaine et que c'est akamai qui s'en charge.
Maintenant pourquoi utiliser un domaine dédié plutôt qu'un sous domaine ? Deux raisons principalement. La première a déjà été évoquée; pour dépasser le nombre maximum de connexion parallèles vers un domaine. C'est un hack pour contourner les problèmes d'HTTP qui devraient finir par se résoudre avec SPDY/HTTP 2.0/autre. La deuxième raison est qu'on ne veut pas de cookies pour ce domaine. Ca gâche de la bande passante pour rien, ça peut foutre le bordel au niveau des caches, et on veut pas forcément les balancer sur un autre réseau. Si des cookies ont été défini pour example.com ils seront envoyés pour cdn.example.com donc on utilise un domaine distinct.
[^] # Re: CDN
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Ça, il me semble que c'est faux, que cette limite est par serveur. D'autant plus que ce que vous appelez nom de domaine dédié, ça n'a pas vraiment de définition précise. On pourrait en imaginer deux, mais qui ne collent pas vraiment :
[^] # Re: CDN
Posté par ckyl . Évalué à 2.
Tu as raison. De mémoire il y avait un navigateur qui avait un hack crado plûtot qu'un per server mais après une recherche rapide je l'ai pas retrouvé donc je dois avoir tord.
# CDN, latence, etc.
Posté par Pierre Carrier . Évalué à 10.
Même pratique chez mon employeur.
L'intérêt des noms de domaine de niveau 2 par rapport à un niveau 3 ou 4 comme tu le suggères est la vitesse de résolution par les serveurs de nom. Dans des cas particuliers cela permet aussi d'éviter de surcharger les serveurs de nom de l'entreprise (les changements dans les zones dédiées aux CDNs sont rares). Une autre énorme avancée est pour garder des réponses tenant dans UDP ; dès qu'il y a des CNAME et/ou du round robin sur enregistrement A, ou CNAME et/ou enregistrements SRV, on peut se retrouver avec ces noms reproduits plusieurs (dizaines de) fois et devoir utiliser TCP. L'effet du passage d'UDP à TCP sur la charge côté serveurs de noms et latence de la résolution côté client sont impressionnants. Il vaut mieux effectuer 2 requêtes DNS passant sur UDP qu'une sur TCP.
Utiliser un domaine de domaine court (quelques lettres) permet aussi de le réutiliser pour offrir des URLs courtes, ce qui peut alléger les pages, E-mails, parfois significativement.
Les en-têtes des requêtes HTTP sont aussi plus courts, ce qui est utile vu qu'ils ne sont jamais compressés et affectent significativement la latence (doivent être entièrement servis avant que quoi que ce soit ne revienne, souvent sur des connexions TCP fraîchement créées donc avec de petites fenêtres les rendant très sensibles au roundtrip des paquets IP).
L'effet réel est peut-être faible au final, mais vu que ça ne coûte pas plus cher d'avoir un nom court (ton journal est rigolo : le coût annuel d'un domaine est complètement ridicule pour ce genre d'entreprises), ce n'est pas vraiment la peine de trop y réfléchir.
[^] # Re: CDN, latence, etc.
Posté par dj_ (site web personnel) . Évalué à 3.
Oui, a titre informatif ça répond a une campagne vidéo (titré Basketball) avec un budget de 10 millions$
[^] # Re: CDN, latence, etc.
Posté par Niniryoku . Évalué à 0.
Pas si tu l'achète 9 euros par ans et que tu le facture 50 € par mois. (Je parle pour des petits projets, comme je l'ai dis plus haut, les exemples qui me sont venu à l'esprit étaient google, wikipedia et facebook, mais j'ai déjà vu cette pratique sur plein de petit sites.)
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: CDN, latence, etc.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Le coût est faible, c'est sûr, même pour un particulier quelconque, mais il ne s'agit pas seulement de coût mais aussi de gestion. Plus de noms de domaines achetés à des dates non synchronisées, c'est plus de risques d'oublier d'en renouveler un par exemple.
[^] # Re: CDN, latence, etc.
Posté par claudex . Évalué à 4.
Bof, pas mal de registrar de permettent de renouveler longtemps à l'avance. Tu peux te permettre de faire ça une ou deux fois par an pour tous tes domaines. De plus, il y a des renouvelements automatique avec débit direct de la carte de crédit.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: CDN, latence, etc.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Certains n'apprécient pas l'idée de laisser à un créancier l'accès à sa carte de crédit. C'est une solution très nettement inférieure à une autorisation de prélèvement par exemple.
[^] # Re: CDN, latence, etc.
Posté par ribwund . Évalué à 2.
Quand t'es gros tu passes un contrat avec quelqu'un comme Markmonitor, et ça fait partie de la prestation. C'est pas un chèque un blanc mais un contrat entre deux sociétés.
[^] # Re: CDN, latence, etc.
Posté par dj_ (site web personnel) . Évalué à 2.
Ovh propose un système de "prépayé", tu vire l'argent et quand y a besoin ils utilisent ça pour renouveler un domaine.
Pas besoin de leur donner ta carte de crédit
(alors oui en attendant ils peuvent placer l'argent etc mais bon)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: CDN, latence, etc.
Posté par Pierre Carrier . Évalué à 2.
Désolé, mais visiblement tu ne sais pas comment "ce genre d'entreprises" fonctionne en la matière.
Elles ont souvent des prestataires qui s'occupent de la maintenance, de gérer des listes de domaine, alerter pour l'arrivée de nouveaux TLDs, etc. La facture est peut-être gonflée par rapport à une gestion interne et des registars low cost, mais encore une fois les coûts sont ridicules par rapport au reste de la production, et les risques largement amoindris.
Même sans ça :
À ma connaissance tous les registars d'autorisent à acheter pour 5 ou 10 ans et à renouveller à l'avance. En achetant toujours pour 5 ans, tu peux faire une revue de ta liste tous les 2 ans et être tranquille. Pas exactement un problème difficile.
# Un peu de recherche
Posté par Artefact2 (site web personnel) . Évalué à 1.
Un peu de recherche ne fait pas de mal:
http://webmasters.stackexchange.com/questions/25087/what-is-the-advantage-to-hosting-static-resources-on-a-separate-domain
(Pour les anglophones, désolé…)
# Cache
Posté par niclone (site web personnel) . Évalué à 3.
Il me semble qu'un des intérêts est pour les scripts connu et souvent utilisé (comme jquery, mootools, etc.), ils se retrouvent ainsi en cache du navigateur qui du coup devient partagé avec de nombreux autres sites qui utilisent ces mêmes scripts.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.