Nous avons installé notre CDN sur notre domaine principal à l'adresse https://www.site.com.
Le site est en PHP.
Nous avons demandé la mise en cace des fichiers suivants dans l'interface de gestion du CDN : .woff .png .js .ico .css .jpg .ttf.
Or nous constatons que l'appel à nos pages PHP passe quand même par le CDN, même si la page elle-même n'est pas chargée via le CDN. Ceci entraîne des temps d'attente.
Peut-être ne fallait-il appliquer le CDN qu'à un sous-domaine spécifique, par exemple cdn.site.com ? Nos pages PHP appelée par le domaine principal www.site.com ne passeraient ainsi pas par le CDN. A l'intérieur de nos pages PHP et HTML, nous appellerions explicitement par le sous-domaine les fichiers que nous souhaiterions faire passer par le CDN.
Par exemple, pour appeler le fichier example.css dans notre balise , nous écririons :
Est-ce que ce système permettrait bien de faire passer le fichier example.css par le CDN et de faire passer les fichiers PHP en-dehors du CDN ?
Oui,
c'est ce qu'il faut faire pour ne faire passer que les images/ Javascript/Css par le CDN.
D'accord.<br /><br />Mais dans ce cas, pourquoi peut-on choisir les fichiers à mettre en cache dans le CDN s'il faut dans tous les cas les appeler explicitement ?<br /><br />Autre façon de formuler la question : à quoi sert de demander la mise en cache des fichiers .css si dans tous les cas, il faut appeler le fichier par le sous-domaine, comme ceci:<br /><br /> <link rel="stylesheet" href="<a href=" rel="nofollow noopener" />http://cdn.site.com/example.css" type="text/css" />
Tu as 2 solutions,
soit tu fais tout passer via le CDN et le CDN mets en cache les fichiers statiques au vol (et le CDN demande les pages php au serveur de l'hébergement). là tu n'as rien à faire.
Soit tu mets les fichiers statiques sur cdn.site.fr (les fichiers statiques sont sur le CDN) et si tu as bien configuré ton site, les pages PHPs sont directement demandées à ton cluster.
NB : tu devrais passer au HTTPS pour pouvoir bénéficier du HTTP 2.0 qui permet de charger plus vite les ressources (iamges,CSS,JS) et etc …
Merci pour tes réponses. Elles sont claires et bien précieuses !
Concernant le SSL, il est bien activé sur notre site. Je ne l'ai pas mis parce qu'il s'agissait d'un exemple. Mais l'adresse est bien au format suivant : https://www.site.com
Notre problème de départ est que nous avons constaté que les fichiers PHP appelés par le CDN ont un temps d'attente (wait time) de 700 ms lorsqu'ils sont appelés par le CDN alors qu'ils ont un temps d'attente de seulement 150 ms sans le CDN.
En revanche, le CDN fonctionne très bien pour les fichiers statiques: sans le CDN, ils ont un temps d'attente de 150 ms (comme les fichiers PHP), mais avec le CDN ils ont un temps d'attente de seulement 8 ms !
Nous avons fait de très nombreux tests et nous en sommes arrivés à la conclusion que le CDN ralentissait les pages PHP, sans raison. Nous avons averti OVH, qui nous ont dit qu'ils ne voyaient pas de problème de leur côté.
Sais-tu ce qui peut causer le problème ?
C'est simplement que les pages PHP la requête fait visiteur > cdn > serveur > cdn > visiteur…
Forcément il y'a un temps de traitement et d'attente à chaque fois…
Comme dit plus haut, l'idéal étant de faire passer les demandes dynamiques sur un domaine à part et passer en direct sur le serveur.
Puis les demandes statiques sur un autre domaine qui lui passe par le CDN.
C'est exactement ce qui a été proposé plus haut.. Ou alors j'ai mal compris ta proposition
C'est effectivement ce que tu as proposé :).
C'est pour moi la meilleure solution pour le CDN.
Oui et ici aussi.
Comme dit plus haut, l'idéal étant de faire passer les demandes dynamiques sur un domaine à part et passer en direct sur le serveur.
Puis les demandes statiques sur un autre domaine qui lui passe par le CDN.
Enfin tant que nous sommes d'accord c'est l'essentiel
ça dépend ce dont on parle déjà. On peut avoir le CDN intégré sur l'hébergement mutualisé ou un CDN à côté.
1) les pages php sont appelés via site.fr et tous les fichiers statiques passent par cdn.site.fr
site.fr pointe directement sur l'ip du serveur sur lequel le site web est installé.
cdn.site.fr pointe vers l'ip du CDN (via un champ A ou CNAME)
2) Tu peux mettre site.fr sur le même certificat HTTPS, OVH se débrouille très bien via le CDN de l'hébergement mutualisé.
Sinon, oui tu peux avoir 2 certificats distincts, ce sont des sous domaines différents, ça ne doit pas poser de problème.
3) Oui grosso modo.
4) => Uniquement les URLs vers les fichiers statiques. les pages php restent accessibles via site.fr/ma_deuxieme_page.php
5) oui.
5.bis => Mettre en cache les fichiers statiques sur une longue période et pas 10 ou 15 minutes comme c'est par défaut … Sinon le CDN est moins utile, surtout pour un site avec peu de trafic.
Je me permets de rajouter :
1 bis : Le CNAME pour pointer vers le CDN est plus propre. Ca te permet de bypasser au besoin.
Si tu indiques l'IP en champ A de ton (sous) domaine, le bypass ne fonctionnera pas.
@RageGoat, est ce que tu peux préciser ?
Dans le cas du mutualisé, OVH ne donne qu'une adresse ip pour le CDN, tu es donc obligé de mettre un champ A avec l'ip : https://docs.ovh.com/fr/fr/web/hosting/liste-des-adresses-ip-des-clusters-et-hebergements-web/#cluster-002
Sinon comment fais tu ?
J'étais resté sur le CDN Infrastructure pour ma part.
En effet le web fonctionne de manière différente, j'aurais du préciser mon point :).
https://docs.ovh.com/pages/releaseview.action?pageId=9568624
Comme le bypass modifie le CNAME dans le cas présent, c'est quand même important si tu veux conserver cette feature
Au niveau de la manière de l'implémenter, ça ne change pas grand chose.
c'est juste un peu plus compliqué pour le certificat TLS pour le HTTPS et je ne sais pas si il gère le http/2 déjà mais sinon c'est pareil
Mais jamais aucun service de CDN ne nous a jamais demandé ça et ça nous semble étrange de devoir ajouter cdn.site.tld sur un serveur alors qu'un enregistrement CNAME pointe cdn.site.tld vers l'infrastructure CDN d'OVH.
Ce n'est pas déconnant puisque si tu bypasses le CDN, les requêtes cdn.site.tld arriveront sur ton serveur et donc il doit savoir les gérer..
Après, ajouter cdn.site.tld à un vhost ça prend 3 minutes ...
Perso je suis aussi un utilisateur du CDN dedicated.
- Comme l'a dit et redit Buddy les fichiers dynamiques c'est de l'hébergement direct, rien à changer.
- Pour les fichiers statiques il faut effectivement un sous domaine distinct.
- Du coup il faut bien un vhost sur le serveur qui héberge le contenu statique… En http un simple serveralias sur le vhost principal fera le boulot.
- Pour le certificat SSL ovh propose un certificat let's encrypt. Du coup un simple certificat auto signé côté serveur pour le sous domaine statique est amplement suffisant.
- Sinon il est possible d'ajouter 1 (et 1 seul) certificat perso sur le CDN dedidcated… Perso autant rester sur let's encrypt…
- Côté DNS normalement on enregistre un champ CNAME qui pointe sur cdn.tld.web.cdn.anycast.me
Le soucis de faire pointer le site principal par le CDN c'est l'absence total de sécurité côté ovh… Sur Cloudflare il y'a des protections, et on peut bloquer une IP directement sur CF.
Côté CDN Dedicated rien de tout ça… Du coup si quelqu'un fait un brute force sur /wp-login.php c'est impossible à bloquer côté ovh, et on se retrouve à devoir le filtrer sur apache (impossible de le bloquer sur le parefeu).
Ce n'est pas un risque sur du fichier statique qui sera servit par le CDN (osef que le gus spam ovh), mais sur un fichier dynamique qui renvoie toujours sur le serveur c'est tout de même gênant de ne pas pouvoir le bloquer…
Exemple concret pour site.fr
- On crée 3 entrées DNS : @ qui pointe sur l'ip, www en CNAME qui pointe sur @ et cdn qui pointe sur cdn.site.fr.web.cdn.anycast.me (pour l'entrée dns complète faut voir le modèle sur ton panel, chez moi c'est comme ça).
- On attends 24H que le DNS soit ok.
- De là on va sur le CDN d'ovh et on crée le domaine cdn.site.fr qui pointe sur l'ip du serveur (backend)
- On crée au moins une rules du genre dossier / pour 1 semaine. (à chacun d'affiner sa config).
- On attends 24H que le CDN soit ok chez OVH et que le certificat Let's Encrypt soit ok.
- On a un vhost sur le serveur. En http c'est très simple.
- ServerName : site.fr
- ServerAlias : www.site.fr, cdn.site.fr
- DocumentRoot : /var/www/site.fr
En HTTPS si on utilise let's encrypt partout on crée 2 vhosts:
- Un pour site.fr pour lequel on va générer un certificat let's encrypt.
- Un vhost pour cdn.site.fr qui va utiliser un certificat auto signé.
- Une fois que tout est ok (dns ok, cdn ovh ok, vhosts ok) on fait les appels pour les fichiers statiques sur cdn.site.fr/mon_image.png
Avec tout ça tout va fonctionner sans soucis. Vouloir utiliser un domaine unique passant par le cdn c'est possible, mais il faut bien s'assurer de ne pas mettre en cache les fichiers dynamiques (exclure les .php voir les .html) et comme dit plus haut, aucun moyen de bloquer quelqu'un sur le pare feu si il tente un brute force ou un flood quelconque…
Pour le coup la réponse du support me semble tout à fait correcte. Pour avoir déjà traité ce sujet ce qu'ils t'ont conseillé me semble parfaitement logique et approprié.
Un hébergeur qui ne permet pas un sous domaine ??
Tu peux toujours "gruger" en mettant ton site sur site.fr et utiliser www.site.fr pour le CDN, c'est pas commun, mais si ça peut te permettre de te débrouiller avec ton "hébergeur".
Et surtout, pour les différentes raisons évoquées (sécurité, privilégier les temps d'accès pour les fichiers dynamiques), il vaut mieux faire circuler les requêtes vers le serveur d'abord puis vers le CDN ensuite.
De quoi tu parles ?
Les fichiers dynamiques sont sur site.tld et les fichiers statiques sur cdn.site.tld donc sur cdn.site.tld tu n'as en théorie, que des requêtes vers des fichiers statiques (si ton site est bien fait).
Le fait qu'ils ne te conseillent pas le champ A pour ton domaine est logique.
Comme je l'ai expliqué sur un de mes messages :
1 bis : Le CNAME pour pointer vers le CDN est plus propre. Ca te permet de bypasser au besoin.
Si tu indiques l'IP en champ A de ton (sous) domaine, le bypass ne fonctionnera pas.