{"id":319891,"date":"2014-03-03T09:30:25","date_gmt":"2014-03-03T08:30:25","guid":{"rendered":"https:\/\/wp-rocket.me\/blog\/?p=66"},"modified":"2021-04-07T10:26:41","modified_gmt":"2021-04-07T08:26:41","slug":"difference-cdn-domain-sharding","status":"publish","type":"post","link":"https:\/\/wp-rocket.me\/fr\/blog\/difference-cdn-domain-sharding\/","title":{"rendered":"Quelle est la diff\u00e9rence entre un CDN et le Domain Sharding ?"},"content":{"rendered":"

Depuis quelques temps, il est fr\u00e9quent d’entendre parler d’un CDN. Il existe pourtant un autre terme moins connu, le domain sharding, qui est r\u00e9guli\u00e8rement confondu avec un CDN alors que les techniques sont totalement diff\u00e9rentes.<\/p>\n

Qu’est-ce qu’un domain sharding ?<\/h2>\n

On lit trop souvent des tutoriels de mise en place d’un CDN alors qu’il s’agit\u00a0en r\u00e9alit\u00e9 de domain sharding.<\/p>\n

Historique<\/h3>\n

Traditionnellement, les navigateurs web limitent le nombre de requ\u00eates simultan\u00e9es vers un m\u00eame domaine. Cette restriction a \u00e9t\u00e9 d\u00e9fini dans les sp\u00e9cifications du protocole HTTP\/1.1.\u00a0Le but \u00e9tait de ne pas surcharger les serveurs de requ\u00eates.<\/p>\n

Un site Internet avec de nombreuses requ\u00eates HTTP (des images, des fichiers CSS, JS, etc.) \u00e9tait donc p\u00e9nalis\u00e9 par cette limite.<\/p>\n

D\u00e9finition<\/h3>\n

Le domain sharding a \u00e9t\u00e9 mis en place pour contourner ce syst\u00e8me : r\u00e9partir les fichiers statiques (images, CSS, JS) sur plusieurs sous-domaines. Ainsi, on multiplie le nombre de requ\u00eates simultan\u00e9es par le nombre de sous-domaines.<\/p>\n

On profite \u00e9galement pour charger les contenus sur des sous-domaines sans cookies.<\/p>\n

N\u00e9anmoins, cette solution n’est pas sans d\u00e9fauts. En effet, chaque sous-domaine rajoute une r\u00e9solution DNS suppl\u00e9mentaire, ce qui est en g\u00e9n\u00e9ral non n\u00e9gligeable en terme de performance. Une r\u00e9solution DNS fait la corr\u00e9lation entre l’adresse URL et l’adresse IP qui lui est associ\u00e9e. Cette demande prend entre 120 et 200 ms avant d’\u00eatre r\u00e9solue.<\/p>\n

Il y a quelques ann\u00e9es cette pratique \u00e9tait tr\u00e8s recommand\u00e9e. Aujourd’hui c’est assez diff\u00e9rent pour plusieurs raisons.<\/p>\n

L’\u00e9volution des navigateurs<\/h3>\n

Les navigateurs ont \u00e9norm\u00e9ment \u00e9volu\u00e9s. Ils effectuent aujourd’hui en moyenne 6 requ\u00eates simultan\u00e9es par domaine (quand IE n’en autorisait que 2). Avec un nombre peu \u00e9lev\u00e9 de requ\u00eates HTTP, la mise en place du domain sharding peut \u00eatre contre-productive.<\/p>\n

Le mobile<\/h3>\n

Sur mobile, les r\u00e9solutions DNS sont bien plus longues qu’avec une connexion classique. L’exc\u00e8s de domain sharding peut \u00eatre tr\u00e8s couteux en terme de performance.<\/p>\n

Peut-on encore faire du domain-sharding ?<\/h3>\n

Il n’y a pas de r\u00e9ponse universelle. Tout d\u00e9pend de votre site et du nombre de requ\u00eates HTTP r\u00e9alis\u00e9es. De fa\u00e7on g\u00e9n\u00e9rale, il est conseill\u00e9 de ne pas d\u00e9passer plus de deux sous domaines.<\/p>\n

\u00c0 noter que le protocole HTTP\/2.0 va tr\u00e8s certainement rendre\u00a0cette pratique obsol\u00e8te. C’est d’ailleurs d\u00e9j\u00e0 le cas pour SPDY qui est le protocole exp\u00e9rimental cr\u00e9e par Google.<\/p>\n

Pour aller plus loin, vous pouvez lire ces articles qui traitent du sujet (en anglais):<\/p>\n