Ciao!
Tutte le buone storie arrivano a una conclusione. E la nostra storia su come abbiamo trovato una soluzione per il passaggio veloce del Firewall cinese non fa eccezione. Ecco perché sono ansioso di condividere con voi l'ultima, parte finale su questo argomento.
Nella parte precedente abbiamo parlato di numerosi ambienti di test che abbiamo ideato e dei risultati che hanno prodotto. Ci siamo fermati dicendo che sarebbe stato utile aggiungere CDN! per fluidità nel nostro schema.
Vi racconterò come abbiamo testato Alibaba Cloud CDN, Tencent Cloud CDN e Akamai, e su quale alla fine ci siamo soffermati. E naturalmente, faremo un riepilogo.

Alibaba Cloud CDN
Noi ci ospitiamo su Alibaba Cloud, utilizziamo IPSEC e CEN da loro. È logico provare prima le loro soluzioni.
Alibaba Cloud offre due tipi di prodotto che possono fare al caso nostro: fornitore di CDN). Monitorano il loro e DCDN. La prima opzione consiste in un CDN classico per un dominio specifico (sottodominio). La seconda opzione è nota come Dynamic Route for CDN (lo chiamo CDN dinamico), può essere attivato in modalità Full-site (per domini wildcard), memorizza anche la cache della statica e accelera il contenuto dinamico, il che significa che la dinamica della pagina verrà caricata attraverso le reti veloci del provider. Questo è importante per noi, dato che il nostro sito è principalmente dinamico, utilizziamo molti sottodomini, ed è più comodo impostare il CDN una volta per la “stella” — *.semrushchina.cn.
Abbiamo già visto questo prodotto nelle fasi precedenti del nostro progetto cinese, ma allora non funzionava ancora, e gli sviluppatori hanno promesso che il prodotto sarebbe stato presto disponibile per tutti i clienti. E così è stato.
Con DCDN puoi:
- configurare la terminazione SSL con il tuo certificato,
- attivare l'accelerazione del contenuto dinamico,
- configurare in modo flessibile la cache dei file statici,
- eseguire il purge della cache,
- abilitare i websocket,
- attivare la compressione e persino l'HTML Beautifier.
Insomma, è tutto come nei grandi e importanti provider CDN.
Dopo aver specificato l'Origin (il luogo dove andranno i server edge CDN), resta solo da creare un CNAME per la stella, che punta a all.semrushchina.cn.w.kunluncan.com (questo CNAME è stato ottenuto nella console di Alibaba Cloud), e il CDN funzionerà.
Dai risultati dei test, questo CDN ci ha aiutato molto. Le statistiche sono riportate qui sotto.
Soluzione
Tempo di attività
Mediana
75° Percentile
95° Percentile
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
CEN/IPsec + GLB
99.79
13s
16s
25s
Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s
Questi sono risultati molto buoni, soprattutto se li confrontiamo con i numeri iniziali. Sapevamo, però, che il test dal browser della versione americana del nostro sito www.semrush.com impiega in media 8.3s (un valore molto vicino). C’è ancora molto da fare. Inoltre, ci sono altri fornitori di CDN che sarebbe interessante mettere alla prova.
Passiamo così a un altro gigante del mercato cinese — Tencent.
Tencent Cloud
Tencent sta ancora sviluppando il suo cloud — questo è evidente dal numero ridotto di prodotti. Durante il suo utilizzo, volevamo testare non solo il loro CDN, ma anche l'infrastruttura di rete in generale:
- hanno qualcosa di simile al CEN?
- come funziona IPSEC? È veloce, quale uptime hanno?
- hanno Anycast?

Analizziamo queste questioni separatamente.
Analogo al CEN
Tencent offre un prodotto Cloud Connect Network (), che consente di collegare VPC da diverse regioni, comprese le regioni all'interno e all'esterno della Cina. Il prodotto è attualmente in beta interna e è necessario creare un ticket per richiedere l'accesso. Dal supporto abbiamo appreso che agli account globali (non cittadini cinesi e né entità legali) non è consentito partecipare al programma di beta testing e non è possibile collegare una regione all'interno della Cina con una regione all'esterno. 1-0 a favore di Ali Cloud
IPSEC
La regione più a sud di Tencent è Guangzhou. Abbiamo creato un tunnel e lo abbiamo collegato alla regione di Hong Kong su GCP (allora questa regione era già disponibile). Abbiamo anche avviato contemporaneamente un secondo tunnel in Ali Cloud da Shenzhen a Hong Kong. Si è scoperto che attraverso la rete Tencent la latenza verso Hong Kong è complessivamente migliore (10 ms) rispetto a quella da Shenzhen a Hong Kong in Ali (120 ms — cosa?). Ma questo non accelerava in alcun modo il funzionamento del sito indirizzato a lavorare attraverso Tencent e questo tunnel, il che era un fatto sorprendente che riprovava quanto segue: la latenza — per la Cina non è un indicatore da considerare realmente nello sviluppo della soluzione per attraversare il firewall cinese.
Anycast Internet Acceleration
Un altro prodotto che consente di lavorare con IP anycast — . Tuttavia, non è disponibile per gli account globali, quindi non ne parlerò, ma sapere che esiste un prodotto del genere può essere utile.
Il test del CDN ha prodotto risultati piuttosto interessanti. Il CDN di Tencent non può essere attivato su full-site, ma solo su domini specifici. Abbiamo registrato i domini e instradato il traffico su di essi:

Si è scoperto che questo CDN ha una funzione: Ottimizzazione del traffico transfrontaliero. Questa funzione dovrebbe ridurre i costi durante il passaggio del traffico attraverso il firewall cinese. Come Origine è stato specificato l'indirizzo IP del GLB di Google (GLB anycast). In questo modo volevamo semplificare l'architettura del progetto.
I risultati sono stati molto buoni — al livello di Ali Cloud CDN, e in alcune occasioni anche migliori. È sorprendente, perché in caso di successo dei test, si potrebbe rinunciare a una parte significativa dell'infrastruttura, tunnel, CEN, virtual machine, ecc.
Non ci siamo rallegrati a lungo, poiché è emerso un problema: i test su Catchpoint fallivano per il provider di internet China Mobile. Da qualsiasi posizione ricevevamo un timeout tramite il CDN di Tencent. La corrispondenza con il supporto tecnico non ha portato a nulla. Abbiamo tentato di risolvere questo problema per circa un giorno, ma non siamo riusciti a ottenere nulla.
In quel momento mi trovavo in Cina, ma non sono riuscito a trovare Wi-Fi pubblico nella rete di questo fornitore per verificare il problema personalmente. Per il resto, tutto sembrava veloce e funzionante.
Tuttavia, poiché l'operatore China Mobile è uno dei tre principali operatori, abbiamo dovuto reindirizzare il traffico su Ali CDN.
In generale, è stata una soluzione piuttosto interessante che merita un test più lungo e una risoluzione di questa problematica.
Akamai
L'ultimo fornitore CDN che abbiamo testato è stato Akamai. È un grande fornitore con una propria rete in Cina. Certamente, non potevamo ignorarlo.

Fin dall'inizio, abbiamo concordato con Akamai un periodo di prova, così da poter cambiare dominio e vedere come funzionerà sulla loro rete. Descriverò i risultati di tutti i test sotto 'Cosa mi è piaciuto' e 'Cosa non mi è piaciuto', con i risultati dei test.
Cosa mi è piaciuto:
- Il team di Akamai è stato molto disponibile in tutte le questioni e ci ha supportato in tutte le fasi del test. Hanno costantemente cercato di migliorare qualcosa dalla loro parte. Hanno fornito buoni consigli tecnici.
- Akamai funziona circa il 10-15% più lentamente rispetto alla nostra soluzione attraverso Ali Cloud CDN. È interessante notare che nell'Origin per Akamai abbiamo indicato l'indirizzo IP GLB, quindi il traffico non passava attraverso la nostra soluzione (potenzialmente si potrebbe rinunciare a parte dell'infrastruttura). Tuttavia, i risultati dei test hanno mostrato che questa opzione è inferiore alla nostra attuale (risultati comparativi qui sotto).
- Sono stati testati sia Origin GLB che Origin in Cina. Entrambe le opzioni sono molto simili.
- Sì Sure Route (ottimizzazione automatica del routing). È possibile posizionare un oggetto di test su Origin, e i server Edge di Akamai proveranno a prelevarlo (normale GET). Per queste richieste viene misurata la velocità e altre metriche, sulla base delle quali la rete Akamai ottimizza i percorsi, in modo che il traffico sia più veloce per il nostro sito e si possa vedere che l'attivazione di questa funzionalità ha avuto un notevole impatto sulla velocità del sito.
- Il versioning della configurazione nell'interfaccia web è fantastico. È possibile eseguire un confronto tra le versioni, visualizzare le differenze. Consultare le versioni precedenti.
- È possibile rilasciare una nuova versione inizialmente solo sulla rete Staging di Akamai, che è la stessa rete della produzione, ma tale percorso non influisce sugli utenti reali. Per questo test è necessario effettuare uno spoofing dei record DNS sulla macchina locale.
- La velocità di caricamento attraverso la loro rete di grandi statici è estremamente rapida e, apparentemente, per qualsiasi altro file. Un file dal cache 'fredda' viene recuperato di gran lunga più velocemente rispetto allo stesso file dal cache 'fredda' di Ali CDN. Dalla cache 'calda' la velocità è già più o meno la stessa.
Test di Ali CDN:
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/sTest di Akamai:
root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
% Totale % Ricevuto % Trasferito Velocità Media Tempo Tempo Tempo Corrente
Scarico Carico Totale Trascorso Rimanente Velocità
100 5757k 0 5757k 0 0 1824k 0 --:--:-- 0:00:03 --:--:-- 1825k
tempo_risoluzione_nomi: 0.509005
tempo_connessione: 0.528261
tempo_appconnect: 0.577235
tempo_pretransfer: 0.577324
tempo_reindirizzamento: 0.000000
tempo_inizio_trasferimento: 1.327013
----------
tempo_totale: 3.154850
----------
dimensione_download: 5895467 Bytes
velocità_download: 1868699.000B/sAbbiamo notato che la situazione nell'esempio sopra dipende da diversi fattori. Al momento della redazione di questo punto, ho effettuato di nuovo il test. I risultati per entrambe le piattaforme sono stati approssimativamente equivalenti. Ciò indica che Internet in Cina si comporta in modo variabile anche per i grandi operatori e i fornitori di servizi cloud.
Aggiungo un grande vantaggio ad Akamai rispetto al punto precedente: se su Ali si notano picchi di elevate prestazioni e molto bassi (riguardanti sia Ali CDN, Ali CEN che Ali IPSEC), su Akamai ogni volta, indipendentemente da come testassi la loro rete, tutto funziona in modo stabile.
Akamai ha effettivamente una vasta copertura in Cina e opera tramite molti fornitori.
Cosa non mi è piaciuto:
- Non mi piace l'interfaccia web e il modo in cui funziona — sono piuttosto scadenti. Ma in effetti ci si abitua (probabilmente).
- I risultati dei test sono peggiori rispetto al nostro sito.
- Ci sono più errori nei test rispetto al nostro sito (uptime inferiore).
- Non ci sono server DNS propri in Cina. Questo porta a molti errori nei test a causa del timeout di risoluzione DNS.
- Non forniscono i propri range di IP -> non è possibile configurare correttamente set_real_ip_from sui nostri server.
Metriche (~3626 esecuzioni; tutte le metriche, eccetto Uptime, in ms; statistiche per un singolo intervallo di tempo):
Fornitore CDN
Mediana
75%
95%
Risposta
Risposta della pagina web
Tempo di attività
DNS
Connect
Attendere
Load
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 percentuale (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 è che l'opzione con Akamai è sostenibile, ma non offre gli stessi livelli di stabilità e velocità della nostra soluzione congiunta con Ali CDN.
Piccole note
Alcuni aspetti non sono stati inclusi nel racconto, ma mi piacerebbe parlarne anch'essi.
Pechino + Tokyo e Hong Kong
Come ho già accennato sopra, abbiamo testato il tunnel IPSEC verso Hong Kong (HK). Ma abbiamo anche testato CEN verso HK. È leggermente più economico, ed era interessante capire come funzionerebbe tra città a una distanza di ~100 km. È stato sorprendente scoprire che la latenza tra queste città è di 100 ms superiore rispetto alla nostra configurazione iniziale (verso Taiwan). La velocità e la stabilità erano anche migliori per Taiwan. Alla fine, abbiamo mantenuto HK come regione di riserva per IPSEC.
Inoltre, abbiamo provato a impostare una tale installazione:
- terminazione dei clienti a Pechino,
- IPSEC e CEN verso Tokyo,
- in Ali CDN è stato indicato come server origin a Pechino.
Questo schema non era così stabile, sebbene in termini di velocità non fosse inferiore alla nostra soluzione. Per quanto riguarda il tunnel, ho notato cadute periodiche anche per CEN, che avrebbe dovuto essere stabile. Pertanto, siamo tornati al vecchio schema e abbiamo smontato questo ambiente di staging.
Di seguito è riportata la statistica sulla latenza tra diverse regioni su vari canali. Potrebbe interessare a qualcuno.
IPsec
Ali cn-beijing GCP asia-northeast1 — 193ms
Ali cn-shenzhen GCP asia-east2 — 91ms
Ali cn-shenzhen GCP us-east4 — 200ms
CEN
Ali cn-beijing Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen Ali us-east1 — 216ms
Informazioni generali su Internet in Cina
Come supplemento ai problemi di Internet descritti all'inizio, nella prima parte dell'articolo.
- Internet in Cina funziona piuttosto rapidamente all'interno.
- La valutazione è stata effettuata sulla base di test di reti Wi-Fi pubbliche in diverse località, dove queste reti sono utilizzate da un gran numero di persone.
- La velocità di download e upload sui server all'interno della Cina era di circa 20 Mbit/s e 5-10 Mbit/s rispettivamente.
- La velocità verso i server al di fuori della Cina è semplicemente miserabile, meno di 1 Mbit/s.
- Internet in Cina non è molto stabile.
- A volte i siti possono aprirsi rapidamente, altre volte lentamente (alla stessa ora in giorni diversi), a condizione che la configurazione non cambi. Lo abbiamo osservato con semrushchina.cn. Questo può essere attribuito ad Ali CDN, che funziona anch'esso in modo variabile a seconda dell'ora del giorno, della posizione delle stelle, ecc.
- Internet mobile è praticamente ovunque 4G o 4G+. Riceve anche in metropolitana, negli ascensori — insomma, ovunque.
- Il mito che gli utenti cinesi credano solo ai domini in zona .cn è falso. Lo abbiamo verificato direttamente con gli utenti.
- Si può vedere come reindirizza a www.baidu.com (anche in mainland China).
- Molti servizi sono davvero bloccati. In modo primitivo: google.com, Facebook, Twitter. Ma molti servizi di Google funzionano (certo, non su tutte le reti Wi-Fi e non viene utilizzato VPN (anche a livello del router, questo è certo).
- Molti domini 'tecnici' delle aziende bloccate funzionano anche. Questo significa che non sempre è saggio eliminare senza pensarci tutti i servizi di Google e altri domini apparentemente bloccati. È necessario 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: schema finale della soluzione.

Risultato
È passato un anno dall'inizio del progetto. Abbiamo iniziato con il fatto che il nostro sito rifiutava completamente di funzionare normalmente dalla Cina, e una semplice richiesta GET con curl impiegava 5,5 secondi.
Poi, con tali risultati dalla prima soluzione (Cloudflare):
Soluzione
Tempo di attività
Mediana
75° Percentile
95° Percentile
Cloudflare
86.6
18s
30s
60s
Alla fine, siamo arrivati a risultati simili (statistiche dell'ultimo mese):
Soluzione
Tempo di attività
Mediana
75° Percentile
95° Percentile
Ali CDN + CEN/IPsec + GLB
99.86
8,8s
9,5s
13,7s
Come si può vedere, finora non siamo riusciti a raggiungere il 100% di uptime, ma troveremo una soluzione e poi vi racconteremo dei risultati in un nuovo articolo :)
A chi è arrivato fino in fondo a queste tre parti — rispetto. Spero che tutto ciò sia stato interessante per voi quanto lo è stato per me mentre lo scrivevo.
P.S. Parti precedenti
Fonte: habr.com
