Accelerazione CDN autocostruita: associazione inversa Nginx, accelerazione della cache, aggiornamento automatico della cache e acquisizione di IP reale

Sebbene il blog sia ora posizionato sull'host VPS Alibaba Cloud Hong Kong CN2, Telecom utilizza la linea CN2, quindi la velocità di accesso sarà più veloce (ma ho ricevuto feedback anche da amici di Telecom che l'accesso è lento (⊙﹏⊙)) . Tuttavia, China Unicom e gli utenti mobili avranno un accesso più lento, soprattutto durante il periodo di punta serale. Molti amici hanno affermato di non poterlo aprire affatto.

A giudicare dall'annuncio ufficiale, Alibaba Cloud Hong Kong CN2 VPS ha effettivamente riscontrato problemi con le linee China Unicom o i nodi delle linee di telecomunicazioni, con conseguenti problemi di accesso all'intera sala computer. Naturalmente, Alibaba Cloud lascerà naturalmente il “pentola” agli operatori. Qualche tempo fa, gli utenti China Unicom dovevano bypassare il Giappone o altri luoghi per accedere al VPS Alibaba Cloud Hong Kong.

Quando sono passato da Kdatacenter Korea VPS ad Alibaba Cloud Hong Kong VPS, in primo luogo, ho sentito che Alibaba Cloud Hong Kong VPS era davvero economico e abbastanza attraente, e in secondo luogo, ho sentito che la linea CN2 poteva essere buona, almeno molto più veloce di quella americana; linea. Ora sembra che, fatta eccezione per gli utenti delle telecomunicazioni, l'accesso sarà più agevole, mentre gli utenti di altri operatori avranno di tanto in tanto problemi.

Per risolvere questo problema, la cosa naturale a cui pensare è accelerare la CDN per il sito web. Naturalmente, il VPS domestico non può essere utilizzato senza un numero BA, quindi ho trovato un metodo VPS coreano che utilizza il proxy inverso Nginx per trasferire le richieste di accesso degli utenti China Mobile e China Unicom al server CDN, che può massimizzare la velocità di accesso al sito web.

Accelerazione CDN autocostruita: associazione inversa Nginx, accelerazione della cache, aggiornamento automatico della cache e acquisizione di IP reale

Questo articolo spiegherà in dettaglio come creare una CDN per il sito Web per accelerare e memorizzare nella cache le pagine e i file corrispondenti. Allo stesso tempo, quando il contenuto del sito Web viene aggiornato, utilizzare ngx_cache_purge per aggiornare tempestivamente la cache sul server CDN. risolvere il problema dell’acquisizione del server sorgente durante l’utilizzo. Il problema dell’IP reale dell’utente. Altri strumenti di accelerazione CDN e di creazione di siti Web includono:

  1. Unisciti a Cloudflare Partner per fornire gratuitamente il servizio di accelerazione CDN CloudFlare: non è necessario modificare NS per supportare SSL
  2. Utilizza Fikker per creare la tua CDN personalizzata: supporta HTTPS, memorizzazione nella cache delle pagine, monitoraggio in tempo reale, statistiche sul traffico e prevenzione degli attacchi CC
  3. Due eccellenti strumenti di monitoraggio del traffico di rete del server: Ntopng e Munin: potenti e intuitivi

PS: aggiornato il 27 aprile 2018. Attualmente, Youpaiyun CDN viene utilizzato per immagini e file statici come JS e CSS sul sito Web Articolo di revisione: Youpaiyun CDN accelerato sull'applicazione e sull'utilizzo tutorial-1 Key mirroring,. CDN dinamico statico e SSL gratuito.

PS: aggiornato il 6 marzo 2018, Se non vuoi creare una CDN da solo, puoi provare un servizio di accelerazione CDN di terze parti Il familiare CloudFlare è un'ottima scelta: Dieci cose potresti non conoscere il suggerimento per l'accelerazione CDN gratuita di CloudFlare-SSLDDOSCache.

1. Installa Nginx

È possibile installare e configurare manualmente Nginx oppure utilizzare il pacchetto di installazione con un clic LNMP per installare Nginx. Quelli più utili sono: Oneinstack e LNMP. Se non vuoi usarlo, puoi provare il pacchetto di installazione Nginx con un clic di xiaoz (applicabile a Centos 7 e Deebian 8).

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

Linux installa Nginx con un clic e attiva CDN (proxy inverso). Basta eseguire il seguente comando per installarlo.

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

2. Configurazione relativa a Nginx

Qui utilizzo wzfou.com per l'accelerazione come esempio. C'è un VPS di origine e un VPS utilizzato come proxy inverso CDN. Gli IP corrispondenti dei due sono i seguenti:

1. Sito di origine: 192.168.1.100, che è dove sono effettivamente archiviati i dati del sito web wzfou.com.

2. CDN:192.168.1.101  Nodo CDN, se sono presenti più nodi CDN, il metodo operativo è lo stesso

Modificare innanzitutto gli Host sul nodo CDN Lo scopo è indicare al nodo CDN dove ottenere i dati del sito Web, ovvero l'indirizzo di ritorno all'origine. Modificare come segue:


vi /etc/hosts
192.168.1.100	www.wzfou.com

Quindi crea il file di configurazione nginx wzfou.com.conf sul nodo 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

Aggiungi il seguente contenuto a wzfou.com.conf Modifica la directory/tempo della cache in base alla situazione reale. Il significato di ciascun parametro verrà spiegato in dettaglio in seguito.

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;
    }
}

Le relative istruzioni sono le seguenti:

1. /data/wwwroot/caches/wzfou.com: è la directory della cache

2. livelli: specifica che lo spazio della cache ha due livelli di directory hash, la directory di primo livello è di 1 lettera e il secondo livello è di 2 lettere.

3. keys_zone=wzfou:50m: assegna un nome allo spazio cache, qui si chiama "wzfou" e i successivi 50m si riferiscono allo spazio cache di memoria.

4. inactive=30m: se non si accede alla risorsa entro 30 minuti, verrà eliminata.

5. max_size=50m: si riferisce alla dimensione della cache del disco rigido di 50 MB

6. proxy_cache_valid: specificare il tempo di cache del codice di stato nella parte anteriore e il tempo di cache nella parte posteriore.

Infine, ricarica nginx per rendere effettiva la configurazione. Se stai utilizzando oneinstack, inserisci direttamente il comando: service nginx reload Se è lo script con un clic di xiaoz, inserisci: /usr/local /nginx/sbin/nginx -s ricarica .  

3. Proxy inverso del sito HTTPS

Ciò che è condiviso sopra sono le impostazioni del proxy inverso Nginx per i siti HTTP Se desideri eseguire il proxy inverso dei siti HTTPS, devi prima richiedere un certificato SSL per il tuo nome di dominio , quindi devi solo impostarlo. Per un buon percorso del certificato SSL, fare riferimento alla seguente configurazione per regolarlo:

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 cancella la cache degli aggiornamenti

La pulizia della cache Nginx richiede l'aiuto del modulo ngx_cache_purge È possibile immettere il comando nginx -V per visualizzare i moduli compilati. Se non è presente ngx_cache_purge, significa che il modulo è. non installato ed è necessario ricompilare Nginx.

4.1  Configura ngx_cache_purge

Aggiungi la seguente configurazione alla sezione server e ricarica Nginx. Mantieni il seguente wzfou coerente con il valore definito da keys_zone, altrimenti nginx non si avvierà.

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

Se desideri svuotare la cache, aggiungi semplicemente il parametro purge, ad esempio https://www.xiaoz.me/purge/xxx.png Se il file esiste nel file cache, ti verrà richiesto il seguente screenshot. Se non è presente cache, verrà restituito 404. Se viene restituito 404, qualunque cosa accada, la configurazione potrebbe non avere successo.

4.2  WordPress aggiorna automaticamente la cache

Per i blog WordPress, se la pagina viene memorizzata nella cache dopo l'attivazione della CDN e non può essere visualizzata immediatamente dopo che l'utente ha inviato un commento, è possibile utilizzare l'interfaccia della richiesta asincrona Ajax ngx_cache_purge per svuotare la cache della pagina quando l'utente invia un commento. Basta aggiungere il seguente js a 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>

Quella che segue è la configurazione completa di Xiaoz Blog CDN, solo come riferimento. È necessario sostituire Keys_zone, percorso SSL, nome di dominio, ecc.:

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. Fai un buon lavoro nella risoluzione dei nomi di dominio DNS

Utilizzando le funzioni di risoluzione DNS come linee, regioni e client fornite dalla risoluzione dei nomi di dominio DNS, possiamo risolvere diversi utenti a banda larga, utenti provinciali e utenti client su nodi CDN.

Utilizza il test dello strumento webmaster per verificare che gli utenti provenienti da luoghi diversi su wzfou.com accedano a diversi nodi CDN, il che significa che la nostra implementazione dell'accelerazione CDN ha avuto successo.

6. Impossibile ottenere un IP reale dopo aver abilitato la CDN

Se sei un utente WordPress, quando abiliti l'accelerazione CDN Nginx, scoprirai che gli IP dei commenti degli utenti ottenuti dal backend WP sono diventati nodi CDN. Anche risolvere questo problema è molto semplice. Devi solo aggiungere il seguente codice a wp - Nel file config.php:

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

7. Riepilogo

Nginx collega in modo inverso i nomi di dominio per creare un server di accelerazione CDN a basso costo e semplice installazione e configurazione. È particolarmente adatto per gli amici che non vogliono utilizzare un CDN a pagamento. Infatti, molti acceleratori CDN professionali utilizzano anche il proxy inverso Nginx per accelerare accesso al sito web Si può dire che Nginx CDN è un metodo di accelerazione molto efficace.

Ci sono due problemi a cui prestare attenzione quando si utilizza l'accelerazione CDN Nginx. Il primo è il problema dell'aggiornamento della cache. Se la tua pagina web viene aggiornata frequentemente, puoi impostare un intervallo di tempo per l'aggiornamento. Il secondo è il problema dell'IP reale dell'utente Possiamo usare PHP o Nginx, ecc. Possiamo ottenere direttamente l'indirizzo IP reale.

Anonimo (non verificato) , 01.07.2024 | Inserito in 0 commenti

lascia un commento