Come abbiamo superato il Grande Firewall Cinese (Parte 3)

Hi!
Tutte le belle storie finiscono. E la nostra storia su come abbiamo trovato una soluzione per superare rapidamente il firewall cinese non fa eccezione. Pertanto, mi affretto a condividere con voi l'ultimo, la parte finale su questo argomento.

Nella parte precedente abbiamo parlato dei tanti banchi prova che abbiamo realizzato e dei risultati che hanno dato. E abbiamo deciso cosa sarebbe stato bello aggiungere CDN! per la viscosità nel nostro schema.

Ti dirò come abbiamo testato Alibaba Cloud CDN, Tencent Cloud CDN e Akamai e cosa abbiamo ottenuto. E ovviamente riassumiamo.

Come abbiamo superato il Grande Firewall Cinese (Parte 3)

CDN Alibaba Cloud

Siamo ospitati su Alibaba Cloud e utilizziamo IPSEC e CEN da loro. Sarebbe logico provare prima le loro soluzioni.

Alibaba Cloud ha due tipi di prodotti che potrebbero fare al caso nostro: CDN и DCDN. La prima opzione è una CDN classica per un dominio specifico (sottodominio). La seconda opzione sta per Percorso dinamico per CDN (Io lo chiamo CDN dinamico), può essere abilitato in modalità Sito completo (per domini jolly), inoltre memorizza nella cache i contenuti statici e accelera su se stesso i contenuti dinamici, ovvero la dinamica della pagina verrà caricata anche tramite il provider reti veloci. Questo è importante per noi, perché fondamentalmente il nostro sito è dinamico, utilizza molti sottodomini ed è più conveniente impostare un CDN una volta per l'“asterisco” - *.semrushchina.cn.

Avevamo già visto questo prodotto nelle prime fasi del nostro progetto cinese, ma allora non funzionava ancora e gli sviluppatori avevano promesso che presto il prodotto sarebbe stato disponibile per tutti i clienti. E lo ha fatto.

In DCDN puoi:

  • configurare la terminazione SSL con il tuo certificato,
  • abilitare l'accelerazione del contenuto dinamico,
  • configurare in modo flessibile la memorizzazione nella cache di file statici,
  • svuotare la cache,
  • socket web inoltrati,
  • abilitare la compressione e persino l'abbellimento HTML.

In generale, tutto è uguale a quello degli adulti e dei grandi fornitori di CDN.

Dopo aver specificato l'Origine (il luogo in cui andranno i server edge della CDN), non resta che creare un CNAME per l'asterisco, facendo riferimento all.semrushchina.cn.w.kunluncan.com (questo CNAME è stato ricevuto nella console Alibaba Cloud) e il CDN funzionerà.

Sulla base dei risultati del test, questo CDN ci ha aiutato molto. Le statistiche sono mostrate di seguito.

Soluzione
Uptime
Mediano
75 percentile
95 percentile

Cloudflare
86.6
18 secondi
30 secondi
60 secondi

IPsec
99.79
18 secondi
21 secondi
30 secondi

CEN
99.75
16 secondi
21 secondi
27 secondi

CEN/IPsec + GLB
99.79
13 secondi
16 secondi
25 secondi

Ali CDN + CEN/IPsec + GLB
99.75
10 secondi
12.8 secondi
17.3 secondi

Si tratta di risultati molto buoni, soprattutto se confrontati con quelli che erano i numeri all’inizio. Ma sapevamo che il test del browser della versione americana del nostro sito web www.semrush.com dura dagli USA in media 8.3 s (un valore molto approssimativo). C'è spazio per miglioramenti. Inoltre c’erano anche provider CDN interessanti da testare.

Quindi passiamo senza problemi a un altro gigante nel mercato cinese: Tencent.

Tencent nuvola

Tencent sta appena sviluppando il suo cloud, lo si può vedere da un piccolo numero di prodotti. Durante l'utilizzo abbiamo voluto testare non solo la loro CDN, ma anche la loro infrastruttura di rete nel suo insieme:

  • hanno qualcosa di simile al CEN?
  • Come funziona IPSEC per loro? È veloce, qual è il tempo di attività?
  • hanno Anycast?

Come abbiamo superato il Grande Firewall Cinese (Parte 3)

Esaminiamo queste domande separatamente.

CEN analogico

Tencent ha un prodotto Rete di connessione cloud (CCN), consentendoti di connettere VPC di diverse regioni, comprese regioni all'interno e all'esterno della Cina. Il prodotto è ora in versione beta interna ed è necessario creare un ticket chiedendo di connettersi ad esso. Abbiamo appreso dal supporto che gli account globali (non stiamo parlando di cittadini o persone giuridiche cinesi) non possono partecipare al programma di beta testing e, in generale, collegare una regione all'interno della Cina con una regione esterna. 1-0 in favore di Ali Cloud

IPsec

La regione più meridionale di Tencent è Canton. Abbiamo assemblato un tunnel e lo abbiamo collegato alla regione di Hong Kong in GCP (quindi questa regione era già diventata disponibile). Nello stesso periodo è stato costruito anche il secondo tunnel nell'Ali Cloud da Shenzhen a Hong Kong. Si è scoperto che attraverso la rete Tencent la latenza verso Hong Kong è generalmente migliore (10 ms) che da Shenzhen a Hong Kong ad Ali (120 ms - cosa?). Ma ciò non ha accelerato in alcun modo il lavoro del sito volto a lavorare attraverso Tencent e questo tunnel, il che di per sé è stato un fatto sorprendente e ha dimostrato ancora una volta quanto segue: latenza - per la Cina questo non è un indicatore che valga davvero la pena prestare attenzione quando si sviluppa una soluzione per superare il firewall cinese.

Accelerazione Internet Anycast

Un altro prodotto che ti consente di lavorare tramite IP anycast è AIA. Ma non è disponibile nemmeno per gli account globali, quindi non te ne parlerò, ma sapere che esiste un prodotto del genere può essere utile.

Ma il test CDN ha mostrato alcuni risultati piuttosto interessanti. La CDN di Tencent non può essere abilitata su un sito completo, ma solo su domini specifici. Abbiamo creato domini e inviato loro traffico:

Come abbiamo superato il Grande Firewall Cinese (Parte 3)

Si è scoperto che questo CDN ha la seguente funzione: Ottimizzazione del traffico transfrontaliero. Questa funzionalità dovrebbe ridurre i costi quando il traffico passa attraverso il firewall cinese. COME Origin È stato indicato l'indirizzo IP di Google GLB (GLB anycast). Pertanto, abbiamo voluto semplificare l'architettura del progetto.

I risultati sono stati molto buoni, al livello di Ali Cloud CDN, e in alcuni punti anche migliori. Ciò è sorprendente, perché se i test hanno esito positivo, è possibile abbandonare una parte significativa delle infrastrutture, tunnel, CEN, macchine virtuali, ecc.

Non ci siamo rallegrati a lungo perché è emerso un problema: i test in Catchpoint per il provider Internet China Mobile sono falliti. Da qualsiasi luogo abbiamo ricevuto un timeout tramite il CDN di Tencent. La corrispondenza con il supporto tecnico non ha portato a nulla. Abbiamo provato a risolvere questo problema per circa un giorno, ma non ha funzionato.

Mi trovavo in Cina in quel momento, ma non sono riuscito a trovare il Wi-Fi pubblico sulla rete di questo provider per verificare personalmente il problema. Per il resto tutto sembrava veloce e buono.
Tuttavia, poiché China Mobile è uno dei tre maggiori operatori, siamo stati costretti a restituire il traffico ad Ali CDN.
Ma nel complesso, questa è stata una soluzione piuttosto interessante che merita test e risoluzione dei problemi più lunghi.

Akamai

L'ultimo provider CDN che abbiamo testato è stato Akamai. Questo è un enorme fornitore che ha la sua rete in Cina. Ovviamente non siamo riusciti a superarlo.

Come abbiamo superato il Grande Firewall Cinese (Parte 3)

Fin dall'inizio abbiamo concordato con Akamai un periodo di prova in modo da poter cambiare dominio e vedere come avrebbe funzionato sulla loro rete. Descriverò il risultato di tutti i test sotto forma di "Cosa mi è piaciuto" e "Cosa non mi è piaciuto" e fornirò anche i risultati dei test.

Cosa ti è piaciuto

  • I ragazzi di Akamai sono stati molto disponibili a rispondere a tutte le domande e ci hanno accompagnato in tutte le fasi del test. Cercavamo costantemente di migliorare qualcosa dalla nostra parte. Hanno dato buoni consigli tecnici.
  • Akamai è circa il 10-15% più lenta della nostra soluzione tramite Ali Cloud CDN. Ciò che è impressionante è che in Origin per Akamai abbiamo specificato l’indirizzo IP del GLB, il che significa che il traffico non è passato attraverso la nostra soluzione (potenzialmente potremmo abbandonare parte dell’infrastruttura). Tuttavia, i risultati dei test hanno mostrato che questa soluzione è peggiore della nostra versione attuale (risultati comparativi di seguito).
  • Testato sia Origin GLB che Origin in Cina. Entrambe le opzioni sono più o meno le stesse.
  • C'è Certo percorso (ottimizzazione automatica del routing). Puoi ospitare un oggetto di prova su Origin e i server Akamai Edge proveranno a prelevarlo (GET normale). Per queste richieste vengono misurate la velocità e altre metriche in base alle quali la rete Akamai ottimizza i percorsi in modo che il traffico vada più veloce per il nostro sito ed era chiaro che abilitare questa funzionalità avesse davvero un forte impatto sulla velocità del sito.
  • Il controllo delle versioni della configurazione nell'interfaccia web è interessante. Puoi fare Confronta per le versioni, guarda le differenze. Visualizza le versioni precedenti.
  • Puoi implementare prima una nuova versione solo sulla rete Akamai Staging, la stessa rete di produzione, solo che in questo modo non influirà sugli utenti reali. Per questo test, devi falsificare i record DNS sul tuo computer locale.
  • Velocità di download molto elevata attraverso la loro rete per file statici di grandi dimensioni e, apparentemente, qualsiasi altro file. Un file dalla cache “fredda” viene recuperato molte volte più velocemente dello stesso file dalla cache “fredda” di Ali CDN. Dalla cache “calda”, la velocità è già la stessa, più o meno.

Test CDN Ali:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

Prova Akamai:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

Abbiamo notato che la situazione nell'esempio sopra dipende da vari fattori. Al momento di scrivere questo punto, ho eseguito nuovamente il test. I risultati per entrambe le piattaforme erano più o meno gli stessi. Questo ci dice che Internet in Cina, anche per i grandi operatori e i fornitori di servizi cloud, si comporta di volta in volta in modo diverso.

Al punto precedente, aggiungerò un grande vantaggio per Akamai: se Ali mostra lampi simili di prestazioni elevate e prestazioni molto basse (questo vale per Ali CDN, Ali CEN e Ali IPSEC), allora Akamai, ogni volta, non importa come provo la loro rete, tutto funziona stabilmente.
Akamai ha molta copertura in Cina e funziona attraverso molti fornitori.

Cosa non è piaciuto:

  • Non mi piace l'interfaccia web e il modo in cui funziona: è così scadente. Ma in fondo ci si abitua (probabilmente).
  • I risultati dei test sono peggiori di quelli del nostro sito.
  • Ci sono più errori durante i test che sul nostro sito (tempo di attività di seguito).
  • Non disponiamo di server DNS propri in Cina. Pertanto ci sono molti errori nei test dovuti al timeout di risoluzione del DNS.
  • Non forniscono i loro intervalli IP -> non c'è modo di registrare quelli corretti set_real_ip_from sui nostri server.

Metriche (~3626 esecuzioni; tutte le metriche tranne Uptime, in ms; statistiche per un periodo di tempo):

Provider CDN
Mediano
75%
95%
Risposta
Risposta della pagina Web
Uptime
DNS
Connettiti
Aspetta!
Caricare
SSL

Ali CDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

Distribuzione per percentile (in ms):

percentile
Akamai
Ali CDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

La conclusione è questa: l'opzione Akamai è fattibile, ma non fornisce la stessa stabilità e velocità della nostra soluzione abbinata ad Ali CDN.

Piccole note

Alcuni momenti non sono stati inclusi nella storia, ma vorrei scrivere anche di quelli.

Pechino + Tokio e Hong Kong

Come ho detto sopra, abbiamo testato un tunnel IPSEC per Hong Kong (HK). Ma abbiamo testato anche il CEN a Hong Kong. Costa un po' meno e mi chiedevo come funzionerebbe tra città con una distanza di ~100 km. È stato interessante notare che la latenza tra queste città è superiore di 100 ms rispetto alla nostra versione originale (verso Taiwan). Anche la velocità e la stabilità sono state migliori per Taiwan. Di conseguenza, abbiamo lasciato Hong Kong come regione IPSEC di backup.

Inoltre, abbiamo provato a installare la seguente installazione:

  • cessazione di clienti a Pechino,
  • IPSEC e CEN a Tokio,
  • in Ali CDN come origine veniva indicato il server di Pechino.

Questo schema non era così stabile, sebbene in termini di velocità generalmente non fosse inferiore alla nostra soluzione. Per quanto riguarda il tunnel ho visto cali intermittenti anche per il CEN, che dovrebbe risultare stabile. Pertanto, siamo tornati al vecchio schema e abbiamo smantellato questa messa in scena.

Di seguito sono riportate le statistiche sulla latenza tra diverse regioni per diversi canali. Magari a qualcuno interesserà.

IPsec
Ali cn-pechino <—> GCP asia-nordest1 — 193 ms
Ali cn-shenzhen <—> GCP asia-est2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

CEN
Ali cn-pechino <—> Ali ap-nordest-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-est1 — 216ms

Informazioni generali su Internet in Cina

In aggiunta ai problemi con Internet descritti all'inizio, nella prima parte dell'articolo.

  • Internet in Cina è abbastanza veloce all'interno.
    • La conclusione è stata raggiunta testando le reti Wi-Fi pubbliche in vari luoghi in cui queste reti sono utilizzate da un gran numero di persone.
    • Le velocità di download e upload sui server in Cina erano rispettivamente di circa 20 Mbit/s e 5-10 Mbit/s.
    • La velocità verso i server fuori dalla Cina è semplicemente scarsa, inferiore a 1 Mbit/s.
  • Internet in Cina non è molto stabile.
    • A volte i siti possono aprirsi rapidamente, a volte lentamente (alla stessa ora del giorno in giorni diversi), a condizione che la configurazione non cambi. Lo abbiamo osservato con l’esempio di semrushchina.cn. Ciò può essere attribuito ad Ali CDN, che funziona anche in questo modo e in base all'ora del giorno, alla posizione delle stelle, ecc.
  • Internet mobile è quasi ovunque 4G o 4G+. Prendilo nella metropolitana, negli ascensori, in breve, ovunque.
  • È un mito che gli utenti cinesi si fidino solo dei domini nella zona .cn. Lo abbiamo imparato direttamente dagli utenti.
    • Puoi vedere come http://baidu.cn reindirizzare a www.baidu.com (anche nella Cina continentale).
  • Molte risorse sono infatti bloccate. Primitivo: google.com, Facebook, Twitter. Ma molte risorse di Google funzionano (ovviamente non su tutti il ​​Wi-Fi e non viene utilizzata la VPN (anche lato router, questo è certo).
  • Funzionano anche molti domini “tecnici” di aziende bloccate. Ciò significa che non dovresti sempre eliminare incautamente tutte le risorse di Google e altre risorse apparentemente bloccate. Devi cercare un elenco di domini vietati.
  • Hanno solo tre principali operatori Internet: China Unicom, China Telecom, China Mobile. Ce ne sono anche di più piccoli, ma la loro quota di mercato è insignificante

Bonus: diagramma della soluzione finale

Come abbiamo superato il Grande Firewall Cinese (Parte 3)

risultato

È passato un anno dall'inizio del progetto. Abbiamo iniziato con il fatto che il nostro sito generalmente si rifiutava di funzionare normalmente dalla Cina e semplicemente GET curl ha richiesto 5.5 secondi.

Quindi, con questi indicatori nella prima soluzione (Cloudflare):

Soluzione
Uptime
Mediano
75 percentile
95 percentile

Cloudflare
86.6
18 secondi
30 secondi
60 secondi

Alla fine abbiamo raggiunto i seguenti risultati (statistiche dell'ultimo mese):

Soluzione
Uptime
Mediano
75 percentile
95 percentile

Ali CDN + CEN/IPsec + GLB
99.86
8.8 secondi
9.5 secondi
13.7 secondi

Come puoi vedere, non siamo ancora riusciti a raggiungere un tempo di attività del 100%, ma troveremo qualcosa e poi ti parleremo dei risultati in un nuovo articolo :)

Rispetto a chi legge tutte e tre le parti fino alla fine. Spero che tu abbia trovato tutto questo interessante quanto me quando l'ho fatto.

PS Parti precedenti

Parte 1
Parte 2

Fonte: habr.com

Aggiungi un commento