Come abbiamo attraversato il Great Chinese Firewall (parte 3)

Ciao!
Tutte le belle storie finiscono. E la nostra storia su come abbiamo trovato una soluzione per superare rapidamente il Firewall Cinese non fa eccezione. Quindi, non vedo l'ora di condividere con voi l'ultima, parte finale su questo tema.

Nella parte precedente abbiamo parlato di numerosi stand di test che abbiamo creato e quali risultati hanno prodotto. E ci siamo fermati su cosa sarebbe stato utile aggiungere CDN! per la coesione nel nostro schema.

Vi racconterò come abbiamo testato Alibaba Cloud CDN, Tencent Cloud CDN e Akamai, e su cosa ci siamo infine concentrati. E naturalmente faremo un riassunto.

Come abbiamo attraversato il Great Chinese Firewall (parte 3)

Alibaba Cloud CDN

Siamo ospitati su Alibaba Cloud, utilizziamo IPSEC e CEN di loro. È logico provare prima le loro soluzioni.

Alibaba Cloud ha due tipi di prodotto che possono fare al caso nostro: CDN e DCDN. La prima opzione rappresenta un CDN classico su un dominio specifico (sottodominio). La seconda opzione si decifra 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, cioè la dinamica della pagina verrà caricata anche attraverso le reti veloci del fornitore. Questo è importante per noi, poiché il nostro sito è principalmente dinamico, utilizza numerosi sottodomini, ed è più comodo configurare il CDN una sola volta per il “jolly” — *.semrushchina.cn.

Abbiamo già visto questo prodotto nelle fasi più precoci del nostro progetto in Cina, ma all'epoca non era ancora operativo, e gli sviluppatori promettevano che il prodotto sarebbe stato presto disponibile per tutti i clienti. E così è stato.

In DCDN è possibile:

  • configurare il termine SSL con il proprio certificato,
  • attivare l'accelerazione del contenuto dinamico,
  • configurare in modo flessibile la cache dei file statici,
  • effettuare il purge della cache,
  • trasmettere web sockets,
  • attivare la compressione e persino HTML Beautifier.

Insomma, tutto come nei grandi e consolidati provider di CDN.

Dopo che l'Origin (il luogo dove andranno i server CDN edge) è stato specificato, resta da creare un CNAME per il jolly, che punti a all.semrushchina.cn.w.kunluncan.com (questo CNAME è stato ottenuto nella console di Alibaba Cloud), e il CDN inizierà a funzionare.

Dai risultati dei test, questo CDN ci ha aiutato molto. Le statistiche sono riportate di seguito.

Soluzione
Uptime
Mediana
75 Percentile
95 Percentile

75 Percentile
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, specialmente se li confrontiamo con i numeri di partenza. Ma sapevamo che il test del browser della versione americana del nostro sito www.semrush.com si svolge in media in 8,3 secondi (valore molto approssimativo). Abbiamo ancora margini di miglioramento. Inoltre, ci sono stati anche provider CDN che sarebbe interessante testare.

Così passiamo dolcemente a un altro gigante del mercato cinese — Tencent.

Tencent Cloud

Tencent sta ancora sviluppando il suo cloud — è evidente dal numero limitato 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 da loro? È veloce, quale uptime?
  • hanno Anycast?

Come abbiamo attraversato il Great Chinese Firewall (parte 3)

Esaminiamo queste domande separatamente.

Analogo al CEN

Tencent ha un prodotto Cloud Connect Network (CCN), che consente di connettere VPC da diverse regioni, comprese quelle all'interno e all'esterno della Cina. Il prodotto è attualmente in beta interna, e bisogna creare un ticket per richiedere di accedervi. Dal supporto abbiamo appreso che gli account globali (non per cittadini cinesi o enti legali) non possono partecipare al programma di beta testing e in generale connettere una regione interna alla Cina con una regione esterna. 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 in GCP (allora quella regione era già disponibile). Abbiamo anche creato 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 (10ms) rispetto a quella da Shenzhen a Hong Kong in Ali (120ms — cosa?). Ma questo non velocizzava affatto il funzionamento del sito orientato a lavorare tramite Tencent e questo tunnel, fatto sorprendente che dimostrava ancora una volta quanto segue: la latenza — per la Cina non è un indicatore su cui vale realmente la pena concentrarsi durante lo sviluppo di una soluzione per superare il firewall cinese.

Anycast Internet Acceleration

Un altro prodotto che consente di operare tramite IP anycast è — AIA. Ma è anch'esso non disponibile per gli account globali, quindi non ne parlerò, ma sapere che esiste un tale prodotto potrebbe essere utile.

Tuttavia, il test del CDN ha mostrato risultati piuttosto interessanti. Non è possibile attivare il CDN di Tencent su un full-site, solo su domini specifici. Abbiamo registrato i domini e abbiamo reindirizzato il traffico su di essi:

Come abbiamo attraversato il Great Chinese Firewall (parte 3)

Si è scoperto che questo CDN ha la seguente funzione: Ottimizzazione del Traffico Transfrontaliero. Questa funzionalità dovrebbe ridurre i costi per il traffico che passa attraverso il firewall cinese. Come Origine è stato indicato l'indirizzo IP del GLB di Google (GLB anycast). In questo modo, volevamo semplificare l'architettura del progetto.

I risultati sono stati molto buoni - a livello di Ali Cloud CDN, e talvolta anche migliori. È sorprendente, perché in caso di successo dei test, si potrebbe rinunciare a una parte sostanziale dell'infrastruttura, tunnel, CEN, virtual machine, ecc.

Non siamo rimasti lieti a lungo, poiché è emerso un problema: i test su Catchpoint fallivano per il provider internet China Mobile. Da qualsiasi posizione ricevevamo timeout tramite il CDN di Tencent. La corrispondenza con il supporto tecnico non ha portato a nulla. Abbiamo cercato di risolvere questo problema per circa un giorno, ma non siamo riusciti a trovare una soluzione.

Ero in Cina in quel momento, ma non sono riuscito a trovare una connessione Wi-Fi pubblica della rete di questo provider per verificare il problema di persona. Per il resto, tutto sembrava veloce e funzionante bene.
Tuttavia, dato che l'operatore China Mobile è uno dei tre operatori più grandi, siamo stati costretti a riportare il traffico su Ali CDN.
In generale, comunque, è stata una soluzione abbastanza interessante che merita test più lunghi e risoluzione di questa problematica.

Akamai

L'ultimo provider CDN che abbiamo testato è Akamai. È un grande provider che ha la sua rete in Cina. Certo, non potevamo ignorarlo.

Come abbiamo attraversato il Great Chinese Firewall (parte 3)

Sin dall'inizio, ci siamo accordati con Akamai per un periodo di prova, in modo da poter cambiare il dominio e vedere come funzionasse sulla loro rete. Riporterò i risultati di tutto il test sotto forma di “Cosa ci è piaciuto” e “Cosa non ci è piaciuto”, fornendo anche i risultati dei test.

Cosa ci è piaciuto:

  • Il team di Akamai ci ha assistito molto in tutte le questioni e ci ha accompagnato 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 della nostra soluzione tramite Ali Cloud CDN. È impressionante che, per Akamai, abbiamo indicato l'indirizzo IP del GLB, quindi il traffico non passava attraverso la nostra soluzione (potenzialmente si potrebbe rinunciare a una parte dell'infrastruttura). Tuttavia, i risultati dei test hanno mostrato che questa opzione è stata inferiore alla nostra attuale (risultati comparativi qui sotto).
  • Sono stati testati sia l'Origin GLB che l'Origin in Cina. Entrambe le opzioni sono abbastanza simili.
  • C'è Sure Route (ottimizzazione automatica del routing). È possibile posizionare un oggetto di prova su Origin, e i server Edge di Akamai proveranno a prelevarlo (una normale richiesta GET). Per queste richieste vengono misurate la velocità e altre metriche, sulla base delle quali la rete Akamai ottimizza i percorsi, affinché il traffico si muova più rapidamente per il nostro sito e sia evidente che l'attivazione di questa funzione influisce notevolmente sulla velocità del sito.
  • Il versionamento della configurazione nell'interfaccia web è fantastico. È possibile fare un confronto tra le versioni e visualizzare le differenze. Visualizza le versioni precedenti.
  • È possibile lanciare una nuova versione inizialmente solo sulla rete Staging di Akamai — una rete identica a quella di produzione, ma questo percorso non influisce sugli utenti reali. Per questo test è necessario effettuare uno spoofing dei record DNS sulla macchina locale.
  • Velocità di caricamento molto rapida attraverso la loro rete di grandi file statici e, apparentemente, di qualsiasi altro file. Un file dal cache 'fredda' viene prelevato molto 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
  % Totale    % Ricevuto % Xferd  Velocità Media   Tempo    Tempo     Tempo  Corrente
                                 Dload  Upload   Totale   Trascorso    Rimasto  Velocità
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

Test 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 % Xferd  Velocità Media   Tempo    Tempo     Tempo  Corrente
                                 Dload  Upload   Totale   Trascorso    Rimasto  Velocità
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 dell'esempio sopra dipende da diversi fattori. Al momento della redazione di questo punto, ho eseguito un test di nuovo. I risultati per entrambe le piattaforme si sono rivelati sostanzialmente identici. Questo ci dice che Internet in Cina, anche per i grandi operatori e i fornitori di servizi cloud, talvolta si comporta in modo diverso.

Aggiungo un grande vantaggio di Akamai al punto precedente: se in Ali si vedono tali picchi di alta prestazione e molto bassi (questo vale sia per Ali CDN, sia per Ali CEN, sia per Ali IPSEC), con Akamai, ogni volta che ho testato la loro rete, tutto funziona in modo stabile.
Akamai ha davvero una grande copertura in Cina e lavora con molti fornitori.

Cosa non mi è piaciuto:

  • Non mi piace l'interfaccia web e il modo di lavorare — sono piuttosto scadenti. Ma in linea di massima ci si abitua (probabilmente).
  • I risultati dei test sono peggiori rispetto alla nostra piattaforma.
  • Ci sono più errori nei test rispetto alla nostra piattaforma (uptime più basso).
  • Non hanno server DNS in Cina. Da qui molti errori nei test a causa del timeout di risoluzione DNS.
  • Non forniscono i propri range di IP -> non c'è possibilità di scrivere correttamente set_real_ip_from sui nostri server.

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

Fornitore CDN
Mediana
75%
95%
Response
Risposta della pagina web
Uptime
DNS
Connessione
Aspetta
Carico
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

Il risultato è questo: l'opzione con Akamai è praticabile, ma non offre gli stessi livelli di stabilità e velocità della nostra soluzione combinata con Ali CDN.

Piccole note

Alcuni aspetti non sono stati inclusi nel racconto, ma vorrei scriverne anche.

Pechino + Tokyo e Hong Kong

Come ho già detto sopra, abbiamo testato il tunnel IPSEC fino a Hong Kong (HK). Ma abbiamo anche testato il CEN fino a HK. Costa un po' di meno ed era interessante vedere come funzionasse tra città a una distanza di ~100 km. Risulta interessante notare che la latenza tra queste città è di 100 ms superiore rispetto al nostro formato iniziale (fino a Taiwan). Velocità e stabilità erano anche migliori per Taiwan. Alla fine, abbiamo mantenuto HK come regione IPSEC di backup.

Inoltre, abbiamo provato a lanciare una tale installazione:

  • terminazione dei clienti a Pechino,
  • IPSEC e CEN fino a Tokyo,
  • in Ali CDN è stato indicato come server di origine a Pechino.

Questo schema non è stato così stabile, anche se in termini di velocità non era in fondo alla nostra soluzione. Per quanto riguarda il tunnel, ho visto cadute periodiche anche per il CEN, che avrebbe dovuto essere stabile. Pertanto, siamo tornati al vecchio schema e abbiamo smontato questo staging.

Di seguito sono statistiche sulla latenza tra diverse regioni su diversi 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

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

  • Internet in Cina funziona abbastanza velocemente all'interno.
    • La conclusione si basa su test di reti Wi-Fi pubbliche in diverse località, dove queste reti vengono utilizzate da molte 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 ridicola, meno di 1 Mbit/s.
  • Internet in Cina non è molto stabile.
    • A volte i siti possono aprirsi rapidamente, altre volte lentamente (nello stesso momento della giornata in giorni diversi), a patto che la configurazione non cambi. Lo abbiamo osservato con semrushchina.cn. Questo può essere attribuito ad Ali CDN, che funziona in modo intermittente a seconda dell'ora del giorno, della posizione delle stelle, ecc.
  • Internet mobile è praticamente ovunque 4G o 4G+. Funziona in metropolitana, negli ascensori — insomma, ovunque.
  • L'idea che gli utenti cinesi credano solo ai domini con estensione .cn è un mito. Lo abbiamo verificato direttamente con gli utenti.
    • Si può vedere come http://baidu.cn reindirizza a www.baidu.com (anche nella Cina continentale).
  • Molti risorse sono realmente bloccati. In modo semplice: google.com, Facebook, Twitter. Ma molte risorse di Google funzionano (ovviamente, non su tutte le Wi-Fi e VPN non sono utilizzate (neppure a livello di router, è certo).
  • Molti domini "tecnici" di corporazioni bloccate funzionano anch'essi. Questo significa che non sempre è necessario rimuovere impulsivamente tutte le risorse apparentemente bloccate di Google e altre. È necessario cercare una lista di domini vietati.
  • Ci sono solo tre principali operatori internet: China Unicom, China Telecom, China Mobile. Ce ne sono altri più piccoli, ma la loro quota di mercato è insignificante.

Bonus: schema finale della soluzione

Come abbiamo attraversato il Great Chinese Firewall (parte 3)

Risultato

È passato un anno dall'inizio del progetto. Siamo partiti dal fatto che il nostro sito rifiutava di funzionare normalmente dalla Cina, e una semplice richiesta GET curl impiegava 5,5 secondi.

Poi, a partire da queste statistiche con la prima soluzione (Cloudflare):

Soluzione
Uptime
Mediana
75 Percentile
95 Percentile

75 Percentile
86.6
18s
30s
60s

Alla fine siamo arrivati a questi risultati (statistiche dell'ultimo mese):

Soluzione
Uptime
Mediana
75 Percentile
95 Percentile

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

Come si può vedere, non siamo ancora riusciti a raggiungere il 100% di uptime, ma troveremo una soluzione e poi vi racconteremo i risultati in un nuovo articolo :)

A chi ha letto fino alla fine tutte e tre le parti — rispetto. Spero che tutto ciò sia stato interessante per voi tanto quanto lo è stato per me quando l'ho fatto.

P.S. Parti precedenti

Parte 1
Parte 2

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster