{"id":33354,"date":"2019-11-04T01:22:21","date_gmt":"2019-11-04T09:22:21","guid":{"rendered":"https:\/\/staging.kinsta.site\/?p=56417"},"modified":"2022-11-08T14:56:26","modified_gmt":"2022-11-08T13:56:26","slug":"reseau-google-cloud","status":"publish","type":"post","link":"https:\/\/staging.kinsta.site\/fr\/blog\/reseau-google-cloud\/","title":{"rendered":"R\u00e9seau de la Plateforme Google Cloud : Niveau Premium vs Niveau Standard"},"content":{"rendered":"

Dans la course d’aujourd’hui pour acc\u00e9l\u00e9rer le temps de chargement de site Web, chaque milliseconde compte. L’\u00e9quipe de Kinsta a test\u00e9 et \u00e9tudi\u00e9 l’impact de la vitesse de site Web<\/a> sur les ventes, les conversions, l’exp\u00e9rience utilisateur et l’engagement des utilisateurs.<\/p>\n

Mais il y a une mise en garde. Bien que l’optimisation sur un site soit importante pour am\u00e9liorer la vitesse, ce n’est pas le seul aspect sur lequel nous devrions nous pencher. Le mat\u00e9riel et l’infrastructure r\u00e9seau qui prennent en charge notre site Web et qui le connectent \u00e0 nos visiteurs sont importants.<\/p>\n

Aujourd’hui, nous allons discuter des raisons pour lesquelles Google investit beaucoup d’argent dans son infrastructure r\u00e9seau, et certaines des diff\u00e9rences entre le r\u00e9seau de niveau premium de Google Cloud Platform et le r\u00e9seau de niveau standard.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Bande Passante et Latence (Crit\u00e8res Cl\u00e9s de Performance de L’infrastructure D’h\u00e9bergement)<\/h2>\n

Avant d’entrer dans les d\u00e9tails du r\u00e9seau de Google Cloud, il est important de comprendre les deux concepts suivants : la bande passante et la latence.<\/p>\n

La largeur de bande est la capacit\u00e9 de d\u00e9bit du r\u00e9seau, mesur\u00e9e en Mbps, tandis que la latence est le retard ou la somme de tous les retards que diff\u00e9rents routeurs ajoutent en cours de route \u00e0 nos requ\u00eates et r\u00e9ponses Web.<\/p>\n

Au sens figur\u00e9, la largeur de bande ou le d\u00e9bit peut \u00eatre repr\u00e9sent\u00e9 comme la capacit\u00e9 d’un tuyau \u00e0 permettre un certain volume d’eau par seconde. La latence peut \u00eatre compar\u00e9e au d\u00e9lai qui s’\u00e9coule entre le moment o\u00f9 la conduite d’eau est ouverte et celui o\u00f9 elle commence \u00e0 couler.<\/p>\n

En raison de la faible surcharge li\u00e9e \u00e0 l’\u00e9tablissement de la connexion entre les diff\u00e9rents routeurs, chaque \u00ab\u00a0saut\u00a0\u00bb en cours de route ajoute une petite quantit\u00e9 de latence aux requ\u00eates et r\u00e9ponses finales.<\/p>\n

Ainsi, plus le visiteur et le serveur sur lequel le site est h\u00e9berg\u00e9 sont \u00e9loign\u00e9s, plus la latence sera grande. De plus, plus le r\u00e9seau est fragment\u00e9, plus la latence est grande.<\/p>\n

Nous pouvons l’imaginer \u00e0 l’aide d’un outil appel\u00e9 traceroute<\/a>, ou tracert<\/a> sur Windows. Dans les captures d’\u00e9cran suivantes, nous l’avons utilis\u00e9 pour inspecter les d\u00e9lais de routage de deux requ\u00eates, en provenance d’Europe. Plus pr\u00e9cis\u00e9ment :
\nPour weibo.com :<\/p>\n

\"Weibo.com\"
Weibo.com<\/figcaption><\/figure>\n

et pour bbc.co.uk :<\/p>\n

\"Bbc.co.uk\"
Bbc.co.uk<\/figcaption><\/figure>\n

Comme nous nous y attendions, le nombre de sauts sur le site en Chine est presque 2 fois plus \u00e9lev\u00e9 qu’en Europe. C’est donc une latence suppl\u00e9mentaire par rapport \u00e0 une requ\u00eate sur un site h\u00e9berg\u00e9 au Royaume-Uni.<\/p>\n

Les trois colonnes que tracert affiche repr\u00e9sentent trois allers-retours (RTT). Chaque ligne repr\u00e9sente diff\u00e9rents routeurs ou sauts en cours de route. Ils ont souvent des URL qui nous aident \u00e0 d\u00e9terminer o\u00f9 se trouve ce routeur sp\u00e9cifique.<\/p>\n

Le temps aller-retour pour les routeurs en Chine \/ Hong Kong prend pr\u00e8s d’un tiers de seconde.<\/p>\n

Nous avons utilis\u00e9 les outils pingdom<\/a> pour charger un site web h\u00e9berg\u00e9 \u00e0 Londres \u00e0 partir de l’emplacement Pingdom en Australie, pour essayer d’\u00e9tablir la part que le r\u00e9seau a dans le temps de chargement global d’un site web.<\/p>\n

\"Exemple
Exemple de temps de chargement<\/figcaption><\/figure>\n

Ce sont les donn\u00e9es d’un petit fichier CSS charg\u00e9 dans ce sc\u00e9nario de test. La partie connexion a la part la plus \u00e9lev\u00e9e dans le chargement de cette ressource, suivie par SSL et Wait. Tout le temps jusque l\u00e0, y compris le temps d’attente, est \u00e9galement connu sous le nom de temps au premier octet (TTFB<\/a>), qui inclut la latence du r\u00e9seau.<\/p>\n

Lorsque les fournisseurs d’acc\u00e8s Internet annoncent la vitesse de la connexion Internet, ils font g\u00e9n\u00e9ralement de la publicit\u00e9 sur leur bande passante (la \u00ab\u00a0largeur du tuyau\u00a0\u00bb, vous vous souvenez ?) qui n’est pas vraiment une mesure de la vitesse<\/a>. L’augmentation de la largeur du tuyau peut augmenter la vitesse du site Web seulement dans une certaine mesure. C’est plus utile lorsque nous avons besoin d’une grande quantit\u00e9 de donn\u00e9es envoy\u00e9es par seconde, comme lorsque nous diffusons du contenu vid\u00e9o haute d\u00e9finition. Mais pour les utilisateurs qui jouent \u00e0 des jeux multijoueurs en ligne en temps r\u00e9el, la latence sera beaucoup plus importante.<\/p>\n

Mike Belshe, l’un des co-auteurs de la sp\u00e9cification HTTP\/2<\/a> et du protocole SPDY, a analys\u00e9<\/a> l\u2019impact de l’augmentation de la bande passante sur la vitesse de chargement du site Web par rapport \u00e0 l’effet de la diminution de la latence sur la vitesse de chargement du site Web.<\/p>\n

Voici les conclusions de Belshe, pr\u00e9sent\u00e9es dans un joli tableau :<\/p>\n

\"Temps
Temps de chargement\/changement de bande passante vs temps\/latence de chargement<\/figcaption><\/figure>\n

Il devrait \u00eatre clair que l’am\u00e9lioration de la vitesse du site Web en augmentant la bande passante n’est pas le moyen le plus efficace d’atteindre de meilleures performances. D’autre part, en r\u00e9duisant le RTT (round-trip-time) ou la latence, nous pouvons constater des am\u00e9liorations constantes de temps de chargement de la page<\/a>.<\/p>\n

R\u00e9seaux vs Peering Internet vs Transit<\/h2>\n

Pour mieux comprendre notre sujet, nous devons expliquer les bases de la topologie de l’internet. Au c\u0153ur de l’Internet mondial, il y a de multiples r\u00e9seaux mondiaux, r\u00e9gionaux et locaux.<\/p>\n

Depuis 2018, il y a plus de 60.000<\/a> AS (syst\u00e8mes autonomes). Ces r\u00e9seaux appartiennent aux gouvernements, aux universit\u00e9s, aux FAI.<\/p>\n

Parmi ceux-ci, on distingue les r\u00e9seaux de niveau 1, de niveau 2 et de niveau 3. Ces niveaux repr\u00e9sentent l’ind\u00e9pendance de chaque r\u00e9seau sur Internet dans son ensemble.<\/p>\n