Accélération CDN auto-construite-liaison inverse Nginx, accélération du cache, mise à jour automatique du cache et obtention d'une véritable adresse IP

Bien que le blog soit désormais placé sur l'hôte VPS CN2 d'Alibaba Cloud Hong Kong, Telecom utilise la ligne CN2, donc la vitesse d'accès sera plus rapide (mais j'ai également reçu des commentaires d'amis de Telecom selon lesquels l'accès est lent (⊙﹏⊙)) . Cependant, China Unicom et les utilisateurs mobiles auront un accès plus lent, surtout pendant la période de pointe du soir. De nombreux amis ont déclaré qu'ils ne pouvaient pas l'ouvrir du tout.

À en juger par l'annonce officielle, Alibaba Cloud Hong Kong CN2 VPS a en effet rencontré des problèmes avec les lignes China Unicom ou les nœuds de lignes de télécommunications, entraînant des problèmes d'accès à l'ensemble de la salle informatique. Bien entendu, Alibaba Cloud laissera naturellement la « marmite » aux opérateurs. Il y a quelque temps, les utilisateurs de China Unicom devaient contourner le Japon ou d'autres pays pour accéder au VPS Alibaba Cloud Hong Kong.

Lorsque je suis passé du VPS de Kdatacenter Corée au VPS d'Alibaba Cloud Hong Kong, premièrement, j'ai senti que le VPS d'Alibaba Cloud Hong Kong était en effet assez bon marché et attractif. Deuxièmement, j'ai senti que la ligne CN2 pourrait être bonne, au moins beaucoup plus rapide que la ligne américaine ; doubler. Il semble désormais qu'à l'exception des utilisateurs des télécommunications, l'accès sera plus fluide, tandis que les utilisateurs d'autres opérateurs rencontreront de temps en temps des problèmes.

Afin de résoudre ce problème, il est naturel de penser à accélérer le CDN pour le site Web. Naturellement, les VPS nationaux ne peuvent pas être utilisés sans numéro BA, j'ai donc trouvé une méthode VPS coréenne qui utilise le proxy inverse Nginx pour transférer les demandes d'accès des utilisateurs de China Mobile et China Unicom vers le serveur CDN, ce qui peut maximiser la vitesse d'accès au site Web.

Accélération CDN auto-construite-liaison inverse Nginx, accélération du cache, mise à jour automatique du cache et obtention d'une véritable adresse IP

Cet article expliquera en détail comment créer un CDN pour le site Web afin d'accélérer et de mettre en cache les pages et fichiers correspondants. En même temps, lorsque le contenu du site Web est mis à jour, utilisez ngx_cache_purge pour mettre à jour rapidement le cache sur le serveur CDN. résoudre le problème de l’acquisition du serveur source lors de l’utilisation. Le problème de l’adresse IP réelle de l’utilisateur. D'autres outils d'accélération CDN et de création de sites Web incluent :

  1. Rejoignez Cloudflare Partner pour fournir gratuitement le service d'accélération CloudFlare CDN - pas besoin de modifier NS pour prendre en charge SSL
  2. Utilisez Fikker pour créer votre propre CDN - prend en charge HTTPS, la mise en cache des pages, la surveillance en temps réel, les statistiques de trafic et la prévention des attaques CC
  3. Deux excellents outils de surveillance du trafic réseau des serveurs : Ntopng et Munin - puissants et intuitifs

PS : mis à jour le 27 avril 2018. Actuellement, Youpaiyun CDN est utilisé pour les images et les fichiers statiques tels que JS et CSS sur le site Web : application accélérée Youpaiyun CDN et tutoriel d'utilisation -1 Mise en miroir des clés, CDN dynamique statique et SSL gratuit.

PS : mis à jour le 6 mars 2018 Si vous ne souhaitez pas créer un CDN vous-même, vous pouvez essayer un service d'accélération CDN tiers. Le célèbre CloudFlare est un très bon choix : dix choses. vous ne connaissez peut-être pas l'astuce d'accélération CloudFlare Free CDN-SSLDDOSCache.

1. Installez Nginx

Vous pouvez installer et configurer Nginx manuellement, ou utiliser le package d'installation en un clic LNMP pour installer Nginx. Les plus utiles sont : Oneinstack et LNMP. Si vous ne souhaitez pas l'utiliser, vous pouvez essayer le package d'installation Nginx en un clic de xiaoz (applicable à Centos 7 et Deebian 8).

  1. https://GitHub.com/hellonow/nginx-cdn

Linux installe Nginx en un clic et active le CDN (proxy inverse). Exécutez simplement la commande suivante pour l'installer.

wget https://raw.githubusercontent.com/helloxz/nginx-cdn/master/nginx.sh
chmod +x nginx.sh && ./nginx.sh

2. Configuration liée à Nginx

Ici, j'utilise wzfou.com pour l'accélération comme exemple. Il existe un VPS d'origine et un VPS utilisé comme proxy inverse CDN. Les IP correspondantes des deux sont les suivantes :

1. Site source : 192.168.1.100, c'est là que sont effectivement stockées les données du site wzfou.com.

2. CDN : 192.168.1.101  Nœud CDN, s'il existe plusieurs nœuds CDN, la méthode de fonctionnement est la même

Modifiez d'abord les hôtes sur le nœud CDN. Le but est d'indiquer au nœud CDN où obtenir les données du site Web, c'est-à-dire l'adresse de retour à la source. La modification est la suivante :


vi /etc/hosts
192.168.1.100	www.wzfou.com

Créez ensuite le fichier de configuration nginx wzfou.com.conf sur le nœud CDN

#创建缓存目录
mkdir -p /data/wwwroot/caches/wzfou.com
#设置缓存目录权限
chown -R www:www /data/wwwroot/caches/wzfou.com
#创建wzfou.com.conf
vi /usr/local/nginx/conf/vhost/wzfou.com.conf

Ajoutez le contenu suivant à wzfou.com.conf. Veuillez ajuster le répertoire de cache/l'heure du cache en fonction de la situation réelle. La signification de chaque paramètre sera expliquée en détail plus tard.

proxy_cache_path /data/wwwroot/caches/wzfou.com levels=1:2 keys_zone=wzfou:50m inactive=30m max_size=50m;
server {
    listen 80;
    server_name wzfou.com;
    charset utf-8,gbk;
        location / {
        proxy_set_header Accept-Encoding "";
           proxy_pass https://wzfou.com;
           proxy_redirect off;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_cache wzfou;
           proxy_cache_valid  200 304  30m;
           proxy_cache_valid  301 24h;
           proxy_cache_valid  500 502 503 504 0s;
           proxy_cache_valid any 1s;
           proxy_cache_min_uses 1;
           expires 12h;
    }
}

Les instructions pertinentes sont les suivantes :

1. /data/wwwroot/caches/wzfou.com : est le répertoire du cache

2. levels : spécifiez que l'espace de cache comporte deux niveaux de répertoires de hachage, le répertoire de premier niveau comporte 1 lettre et le deuxième niveau comporte 2 lettres.

3. keys_zone=wzfou:50m : Donnez un nom à l'espace cache, ici il est nommé "wzfou", et les 50 m suivants font référence à l'espace mémoire cache.

4. inactive=30m : si la ressource n'est pas accessible dans les 30 minutes, elle sera supprimée.

5. max_size=50m : fait référence à la taille du cache du disque dur de 50 Mo.

6. proxy_cache_valid : spécifiez l'heure du cache du code d'état au recto et l'heure du cache au verso.

Enfin, rechargez nginx pour que la configuration prenne effet. Si vous utilisez oneinstack, saisissez directement la commande : service nginx reload. S'il s'agit d'un script xiaoz en un clic, saisissez : /usr/local. /nginx/sbin/nginx -s recharger .  

3. Proxy inverse du site HTTPS

Ce qui est partagé ci-dessus est le paramètre de proxy inverse Nginx pour le site HTTP. Si vous souhaitez inverser le proxy du site HTTPS, vous devez d'abord demander le certificat SSL pour votre nom de domaine , puis il vous suffit de le faire. pour le configurer Pour un bon chemin de certificat SSL, veuillez vous référer à la configuration suivante pour l'ajuster :

proxy_cache_path /data/wwwroot/caches/wzfou.com levels=1:2 keys_zone=wzfou:50m inactive=30m max_size=50m;
server {
  	listen 443 ssl http2;
	ssl_certificate	/data/ssl/wzfou/wzfou.com.crt;
	ssl_certificate_key	/data/ssl/wzfou/wzfou.com.key;
	ssl_session_timeout 1d;
	ssl_session_cache builtin:1000 shared:SSL:10m;
    #ssl_dhparam /data/ssl/dhparam.pem;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;


    ssl_stapling on;
    ssl_stapling_verify on;

    server_name wzfou.com;
    access_log /data/wwwlogs/wzfou.com_nginx.log combined;
   
    charset utf-8,gbk;
        location / {
        proxy_set_header Accept-Encoding "";
           proxy_pass https://wzfou.com;
           proxy_redirect off;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_cache wzfou;
           proxy_cache_valid  200 304  30m;
           proxy_cache_valid  301 24h;
           proxy_cache_valid  500 502 503 504 0s;
           proxy_cache_valid any 1s;
           proxy_cache_min_uses 1;
           expires 12h;
    }
}
server {
    listen 80 default_server;
    return 301 https://$host$request_uri;
}

4. ngx_cache_purge efface le cache de mise à jour

Le nettoyage du cache Nginx nécessite l'aide du module ngx_cache_purge. Vous pouvez saisir la commande nginx -V pour afficher les modules compilés. S'il n'y a pas de ngx_cache_purge, cela signifie que le module est. n'est pas installé et vous devez recompiler Nginx.

4.1  Configurer ngx_cache_purge

Ajoutez la configuration suivante à la section serveur et rechargez Nginx. Veuillez garder le wzfou suivant cohérent avec la valeur définie par keys_zone, sinon nginx ne démarrera pas.

location ~ /purge(/.*) {
allow all;
proxy_cache_purge wzfou $proxy_host$1$is_args$args;
error_page 405 =200 /purge$1;
}

Si vous souhaitez vider le cache, ajoutez simplement le paramètre purge, tel que https://www.xiaoz.me/purge/xxx.png si le fichier existe dans le fichier. cache, vous serez invité comme suit. S'il n'y a pas de cache, 404 sera renvoyé. Si 404 est renvoyé quoi qu'il arrive, la configuration risque d'échouer.

4.2  WordPress actualise automatiquement le cache

Pour les blogs WordPress, si la page est mise en cache après l'activation du CDN et ne peut pas être affichée immédiatement après que l'utilisateur a soumis un commentaire, vous pouvez utiliser l'interface de requête asynchrone Ajax ngx_cache_purge pour vider le cache de la page lorsque l'utilisateur soumet un commentaire. Ajoutez simplement le js suivant à footer.php.

<script>
		$(document).ready(function(){
			$("#submit").click(function(){
				var uri = "https://wzfou.com/purge" + window.location.pathname;
				$.get(uri,function(data,status){
					return true;
				});
			});
		});
	</script>

Ce qui suit est la configuration complète de Xiaoz Blog CDN, pour référence uniquement. Vous devez remplacer Keys_zone, le chemin SSL, le nom de domaine, etc. :

proxy_cache_path /data/caches levels=1:2 keys_zone=xiaozcdn:100m inactive=30m max_size=100m;
server
    {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl on;
    ssl_certificate /xxx/www_xiaoz_me.crt;
    ssl_certificate_key /xxx/www_xiaoz_me.key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;
    ssl_stapling on;
    ssl_stapling_verify on;

    server_name     www.xiaoz.me;
    charset utf-8,gbk;

   #删除缓存
    location ~ /dcache(/.*) {
    allow all;
    proxy_cache_purge xiaozcdn $proxy_host$1$is_args$args;
    error_page 405 =200 /purge$1;
    }

       location / {
       #proxy_set_header Accept-Encoding "";
       proxy_pass https://www.xiaoz.me;
       proxy_redirect off;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_cache xiaozcdn;
       proxy_cache_valid  200 304  30m;
       proxy_cache_valid  301 24h;
       proxy_cache_valid  500 502 503 504 0s;
       proxy_cache_valid any 1s;
       #达到第几次被缓存？
       proxy_cache_min_uses 1;
       expires 12h;
       proxy_cache_key    $uri$is_args$args;
    }
}
server
{
    listen 80;
    server_name www.xiaoz.me;
    rewrite ^(.*) https://www.xiaoz.me$1 permanent;
}

5. Faites du bon travail dans la résolution des noms de domaine DNS

En utilisant les fonctions de résolution DNS telles que les lignes, les régions et les clients fournies par la résolution de noms de domaine DNS, nous pouvons résoudre différents utilisateurs haut débit, utilisateurs provinciaux et utilisateurs clients en nœuds CDN.

Utilisez le test de l'outil pour les webmasters pour voir que les utilisateurs de différents endroits sur wzfou.com accèdent à différents nœuds CDN, ce qui signifie que notre déploiement d'accélération CDN est réussi.

6. Impossible d'obtenir une véritable IP après avoir activé CDN

Si vous êtes un utilisateur WordPress, lorsque vous activez l'accélération Nginx CDN, vous constaterez que les adresses IP des commentaires utilisateur obtenues par le backend WP sont devenues des nœuds CDN. La résolution de ce problème est également très simple. Il vous suffit d'ajouter le code suivant à wp. - Dans le fichier config.php :

if (isset($_SERVER['HTTP_X_REAL_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
}

7. Résumé

Nginx lie les noms de domaine de manière inversée pour créer un serveur d'accélération CDN avec une installation et une configuration simples et peu coûteuses. Il est particulièrement adapté aux amis qui ne souhaitent pas utiliser un CDN payant. En fait, de nombreux accélérateurs CDN professionnels utilisent également le proxy inverse Nginx pour accélérer. accès au site Web. On peut dire que Nginx CDN est une méthode d'accélération très efficace.

Il y a deux problèmes auxquels il faut prêter attention lors de l'utilisation de l'accélération Nginx CDN. Le premier est le problème de mise à jour du cache. Si votre page Web est fréquemment mise à jour, vous pouvez définir un intervalle de temps de mise à jour. Le second est le problème de l'adresse IP réelle de l'utilisateur. .Nous pouvons utiliser PHP ou Nginx, etc. pour obtenir directement la véritable adresse IP.

Anonyme (non vérifié) , 30.06.2024 | Posté sur 0 commentaires

Laisser une réponse