🥇Cum am trecut peste Marele Firewall Chinezesc (partea 3)

Bună!
Orice poveste bună se termine. Iar povestea noastră despre cum am dezvoltat o soluție pentru a trece rapid prin Firewall-ul chinezesc nu face excepție. Așadar, mă grăbesc să vă împărtășesc ultima, parte finală pe această temă.

În partea anterioară, am povestit despre numeroasele standuri de testare pe care le-am conceput și ce rezultate au avut. Ne-am oprit la idee că ar fi bine să adăugăm CDN! pentru coezivitate în schema noastră.

Voi povesti cum am testat Alibaba Cloud CDN, Tencent Cloud CDN și Akamai, și pe ce am decis în final. Și, desigur, vom trasa concluziile.

Alibaba Cloud CDN

Suntem găzduiți în Alibaba Cloud, folosind IPSEC și CEN de la ei. Este logic să încercăm mai întâi soluțiile lor.

Alibaba Cloud are două tipuri de produse care ne-ar putea interesa: CDN și DCDN. Prima opțiune reprezintă un CDN clasic pe un anumit domeniu (subdomeniu). A doua opțiune se decodifică ca Dynamic Route for CDN (pe care eu îl numesc CDN dinamic), poate fi activat în modul Full-site (pentru domenii wildcard), de asemenea, stochează statica și accelerează conținutul dinamic, ceea ce înseamnă că dinamica paginii va fi, de asemenea, încărcată prin rețele rapide ale furnizorului. Acest lucru este important pentru noi, deoarece site-ul nostru este în principal dinamic, utilizează numeroase subdomenii și este mai confortabil să configurăm CDN o singură dată pentru „steluță” — *.semrushchina.cn.

Am văzut deja acest produs în etapele anterioare ale proiectului nostru chinezesc, dar atunci acesta nu funcționa și dezvoltatorii promiteau că produsul va deveni disponibil pentru toți clienții în curând. Și a devenit.

În DCDN, putem:

configura terminarea SSL cu propriul nostru certificat,
activa accelerația conținutului dinamic,
configura flexibil caching-ul fișierelor statice,
efectua purge pe cache,
transmite websocket-uri,
activa compresia și chiar HTML Beautifier.

În general, totul este ca la marii și maturii furnizori de CDN.

După ce Origin (locul unde vor merge serverele edge CDN) este specificat, rămâne doar să creăm un CNAME pentru steluță, referitor la all.semrushchina.cn.w.kunluncan.com (acest CNAME a fost obținut din consola Alibaba Cloud), și CDN va funcționa.

Conform rezultatelor testelor, acest CDN ne-a ajutat foarte mult. Statisticile sunt prezentate mai jos.

Soluție
Uptime
Medie
Percentilă 75
Percentilă 95

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

Acestea sunt rezultate foarte bune, mai ales dacă le comparăm cu cifrele inițiale. Dar știm că testul din browser al versiunii americane a site-ului nostru www.semrush.com durează în medie 8.3s (o valoare foarte aproximativă). Avem unde să ne îmbunătățim. În plus, mai erau și furnizori CDN pe care ar fi fost interesant să-i testăm.

Astfel, trecem treptat la un alt gigant de pe piața din China — Tencent.

Tencent Cloud

Tencent își dezvoltă abia acum cloudul — acest lucru este evident din numărul redus de produse. În timpul utilizării acestuia, am dorit să testăm nu doar CDN-ul lor, ci și infrastructura lor de rețea în general:

au ceva similar cu CEN?
Cum funcționează IPSEC? Este rapid, care este uptime-ul?
Au Anycast?

Vom analiza aceste întrebări separat.

Echivalentul CEN

Tencent are un produs Cloud Connect Network (CCN), care permite conectarea între VPC-uri din diferite regiuni, inclusiv regiuni din China și din afara acesteia. Produsul este acum în beta internă, iar pentru a te conecta, trebuie să creezi un tichet de solicitare. De la suport am aflat că conturile globale (nu ne referim la cetățenii Chinei și la persoanele juridice) nu pot participa în programul de testare beta și, în general, nu pot conecta o regiune din China cu o regiune din afara acesteia. 1-0 în favoarea Ali Cloud

IPSEC

Cea mai sudică regiune a Tencent este — Guangzhou. Am creat un tunel și l-am conectat cu regiunea Hong Kong din GCP (pe atunci, această regiune devenise deja disponibilă). De asemenea, am ridicat simultan un al doilea tunel în Ali Cloud din Shenzhen în Hong Kong. S-a dovedit că prin rețeaua Tencent, latența către Hong Kong este în general mai bună (10ms) decât din Shenzhen în Hong Kong în Ali (120ms — what?). Dar acest lucru nu a accelerat deloc funcționarea site-ului destinat să opereze prin Tencent și acest tunel, ceea ce era un fapt surprinzător și dovedea încă odată următorul lucru: latența — pentru China nu este un indicator la care ar trebui să ne concentrăm în timpul dezvoltării soluției de ocolire a firewall-ului chinezesc.

Anycast Internet Acceleration

Un alt produs care permite operarea prin IP anycast — AIA. Dar acesta este, de asemenea, inaccesibil pentru conturile globale, așa că nu voi vorbi despre el, dar este bine de știut că există un astfel de produs.

Testul CDN a arătat rezultate destul de interesante. CDN-ul Tencent nu poate fi activat pentru întregul site, ci doar pentru domenii specifice. Am creat domenii și am redirecționat trafic către ele:

Se pare că acest CDN are funcția următoare: Optimizarea Traficului Transfrontalier. Această caracteristică ar trebui să reducă costurile de trecere a traficului prin firewall-ul chinezesc. Ca și Origin a fost specificat adresa IP a GLB (GLB anycast) de la Google. Astfel, am dorit să simplificăm arhitectura proiectului.

Rezultatele au fost foarte bune — la nivelul Ali Cloud CDN, iar în unele cazuri chiar mai bune. Este uimitor, deoarece în cazul succesului testelor, am putea renunța la o parte semnificativă a infrastructurii, tunelurilor, CEN, mașinilor virtuale etc.

Ne-am bucurat de puțin timp, deoarece a apărut o problemă: testele în Catchpoint au eșuat pentru furnizorul de internet China Mobile. Din orice locație obțineam timeout prin CDN-ul Tencent. Corespondenta cu suportul tehnic nu a dus la nimic. Aproape o zi am încercat să rezolvăm această problemă, dar nu am reușit.

În acel moment mă aflam în China, dar nu am reușit să găsesc Wi-Fi public în rețeaua acestui furnizor pentru a verifica problema personal. În rest, totul părea rapid și bun.
Cu toate acestea, deoarece operatorul China Mobile face parte din cei trei cei mai mari operatori, am fost nevoiți să redirecționăm traficul către Ali CDN.
Dar în general, a fost o soluție destul de interesantă, care merită o testare și o rezolvare mai extinsă a acestei probleme.

Akamai

Ultimul furnizor CDN pe care l-am testat este Akamai. Este un furnizor uriaș care are propria rețea în China. Desigur, nu am putut să-l ignorăm.

De la bun început, ne-am înțeles cu Akamai pentru o perioadă de testare, astfel încât să putem schimba domeniul și să vedem cum funcționează în rețeaua lor. Voi descrie rezultatul testelor sub forma “Ce ne-a plăcut” și “Ce nu ne-a plăcut”, precum și rezultatele testelor.

Ce ne-a plăcut:

Echipa de la Akamai ne-a ajutat foarte mult cu toate întrebările și ne-a însoțit în toate etapele testării. În mod constant încercau să îmbunătățească ceva de partea lor. Ne-au oferit sfaturi tehnice bune.
Akamai funcționează cu aproximativ 10-15% mai încet decât soluția noastră prin Ali Cloud CDN. Impresionant este că pentru Akamai am specificat adresa IP a GLB, deci traficul nu trecea prin soluția noastră (potențial putem renunța la o parte din infrastructură). Dar totuși, rezultatele testelor au arătat că această soluție este mai slabă decât varianta noastră actuală (rezultatele comparative sunt mai jos).
A fost testat atât ca Origin GLB, cât și ca Origin în China. Ambele variante sunt aproximativ aceeași.
Există Sure Route (optimizarea automată a rutelor). Poți plasa un obiect de test pe Origin, iar serverele Edge Akamai vor încerca să-l preia (GET obișnuit). Pentru aceste cereri, se măsoară viteza și alte metrici, pe baza cărora rețeaua Akamai își optimizează rutele, astfel încât traficul să ruleze mai repede pentru site-ul nostru și să se observe că activarea acestei funcții a avut un impact semnificativ asupra vitezei de funcționare a site-ului.
Versionarea configurației în interfața web este grozavă. Poți face Comparare pentru versiuni, poți vizualiza diferențele. Poți consulta versiunile anterioare.
Poți lansa o nouă versiune inițial doar pe rețeaua de staging Akamai — aceeași rețea ca și producția, doar că acest drum nu afectează utilizatorii reali. Pentru acest test, trebuie să faci o simulare a înregistrărilor DNS pe mașina locală.
Viteză de încărcare foarte rapidă prin rețeaua lor de fișiere statice mari, dar și a altor fișiere. Fișierul din cache-ul „rece” este preluat de câteva ori mai repede decât același fișier din cache-ul „rece” Ali CDN. Din cache-ul „cald”, viteza este deja cam la fel.

Test 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/s

Test 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

Am observat că situația din exemplul de mai sus depinde de diferite factori. La momentul redactării acestui punct, am efectuat testul din nou. Rezultatele pentru ambele platforme s-au dovedit a fi cam identice. Acest lucru ne spune că internetul în China, chiar și pentru marii operatori și furnizorii de cloud, se comportă din când în când diferit.

La punctul anterior adaug un mare plus pentru Akamai: dacă la Ali se observă astfel de izbucniri de performanță înaltă și foarte scăzută (acest lucru se referă atât la Ali CDN, cât și la Ali CEN, și Ali IPSEC), la Akamai, de fiecare dată când am testat rețeaua lor, totul funcționează stabil.
Akamai are într-adevăr o acoperire mare în China și colaborează cu mulți furnizori.

Ce nu mi-a plăcut:

Nu-mi place interfața web și schema de funcționare – sunt oarecum dezorganizate. Dar, în principiu, te obișnuiești (probabil).
Rezultatele testelor sunt mai slabe decât ale site-ului nostru.
Erorile în teste sunt mai frecvente decât pe site-ul nostru (uptime mai scăzut).
Nu au servere DNS proprii în China. Din această cauză, există multe erori în teste din cauza timeout-ului la rezolvarea DNS.
Nu oferă propriile range-uri IP -> nu există posibilitatea de a configura corect set_real_ip_from pe serverele noastre.

Metrici (~3626 execuții; toate metricile, cu excepția Uptime, în ms; statistici pentru un singur interval de timp):

Provider CDN
Medie
75%
95%
Response
Răspunsul paginii web
Uptime
DNS
Conectare
Wait
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

Distribuția pe Percentilă (în ms):

Percentilă
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

Concluzia este că opțiunea cu Akamai este viabilă, dar nu oferă aceleași niveluri de stabilitate și viteză ca soluția noastră proprie împreună cu Ali CDN.

Note mici

Anumite aspecte nu au fost incluse în narațiune, dar mi-ar plăcea să scriu și despre ele.

Peking + Tokyo și Hong Kong

Așa cum am menționat mai sus, am testat un tunel IPSEC până la Hong Kong (HK). Dar am testat și CEN până la HK. Este puțin mai ieftin și a fost interesant de văzut cum va funcționa între orașe situate la ~100 km distanță. A fost interesant că latența între aceste orașe este cu 100 ms mai mare decât în varianta noastră inițială (până în Taiwan). Viteza și stabilitatea au fost, de asemenea, mai bune pentru Taiwan. În final, am păstrat HK ca regiune de backup pentru IPSEC.

În plus, am încercat să implementăm o astfel de instalare:

terminarea clienților în Beijing,
IPSEC și CEN până în Tokyo,
unde Ali CDN a fost indicat ca server origin în Beijing.

Această schemă nu a fost atât de stabilă, deși în termeni de viteză nu a cedat soluției noastre. Cât despre tunel, am văzut că există căderi periodice chiar și pentru CEN, care ar trebui să fie stabil. Așa că ne-am întors la vechea schemă și am desființat această etapă.

Mai jos este statisticile privind latența între diferite regiuni pe diferite canale. Poate că va fi interesant pentru cineva.

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

Informații generale despre internetul din China

Ca o completare a problemelor cu internetul, descrisă la început, în prima parte a articolului.

Internetul în China funcționează destul de repede pe interior.
- Concluzia a fost făcută pe baza testării rețelelor Wi-Fi publice în diverse locații, unde aceste rețele sunt utilizate de un număr mare de oameni.
- Viteza de descărcare și încărcare pe serverele din China a fost de aproximativ 20 Mbps, respectiv 5-10 Mbps.
- Viteza către serverele din afara Chinei este pur și simplu nesemnificativă, sub 1 Mbps.
Internetul în China nu este foarte stabil.
- Uneori site-urile se pot deschide rapid, alteori încet (în aceeași perioadă a zilei, în zile diferite), cu condiția ca configurația să nu se schimbe. Acest lucru a fost observat pe semrushchina.cn. Acesta poate fi atribuit lui Ali CDN, care funcționează de asemenea variabil în funcție de ora din zi, poziția stelelor etc.
Internetul mobil este practic 4G sau 4G+ aproape peste tot. Se poate conecta în metrou, în lifturi — adică, peste tot.
Că utilizatorii chinezi cred doar în domeniile din zona .cn este un mit. Am aflat acest lucru direct de la utilizatori.
- Se poate vedea cum http://baidu.cn redirectează către www.baidu.com (și în mainland China de asemenea).
Multe resurse sunt într-adevăr blocate. Simplificat: google.com, Facebook, Twitter. Dar multe resurse Google funcționează (bineînțeles, nu pe toate Wi-Fi-urile și VPN-ul nu este folosit (de asemenea, pe partea routerului este clar)).
Multe domenii „tehnice” ale corporațiilor blocate funcționează și ele. Aceasta înseamnă că nu întotdeauna trebuie să eliminăm fără discernământ toate resursele Google și alte resurse care par blocate. Trebuie să căutăm un fel de listă cu domeniile interzise.
Au doar trei operatori principali de internet: China Unicom, China Telecom, China Mobile. Există și altele mai mici, dar cota lor pe piață este nesemnificativă.

Bonus: schema finală a soluției

Rezultatul

A trecut un an de la începutul proiectului. Am început cu faptul că site-ul nostru refuza cu totul să funcționeze normal din China, pur și simplu un GET curl dura 5.5 secunde.

Apoi, cu aceste rezultate la prima soluție (Cloudflare):

Soluție
Uptime
Medie
Percentilă 75
Percentilă 95

Cloudflare
86.6
18s
30s
60s

În final am ajuns la aceste rezultate (statisticile din ultima lună):

Soluție
Uptime
Medie
Percentilă 75
Percentilă 95

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

După cum se vede, nu am reușit încă să atingem un uptime de 100%, dar vom găsi o soluție și apoi vă vom spune despre rezultate într-un nou articol :)

Respect pentru cei care au citit toate cele trei părți până la capăt. Sper că v-a fost la fel de interesant ca și mie în timpul redactării acestora.