Hallo!
Oan alle goede ferhalen komt in ein. En ús ferhaal oer hoe't wy in oplossing kamen om de Sineeske Firewall fluch troch te jaan is gjin útsûndering. Dêrom ha ik my de lêste mei jo te dielen, it lêste diel oer dit ûnderwerp.
Yn it foarige diel hawwe wy it oer in protte testbanken dêr't wy mei kamen en hokker resultaten se joegen. En wy beslute wat soe moai wêze om ta te foegjen CDN! foar viskositeit yn ús skema.
Ik sil jo fertelle hoe't wy Alibaba Cloud CDN, Tencent Cloud CDN en Akamai testen, en wêr't wy mei einigje. En fansels, lit ús gearfetsje.
Alibaba Cloud CDN
Wy wurde hosted op Alibaba Cloud en brûke IPSEC en CEN fan har. It soe logysk wêze om har oplossingen earst te besykjen.
Alibaba Cloud hat twa soarten produkten dy't by ús passe kinne: CDN и DCDN. De earste opsje is in klassike CDN foar in spesifyk domein (subdomein). De twadde opsje stiet foar Dynamyske rûte foar CDN (Ik neam it dynamyske CDN), it kin ynskeakele wurde yn Folsleine side-modus (foar jokertekendomeinen), it cache ek statyske ynhâld en fersnelt dynamyske ynhâld op himsels, dat is, de dynamyk fan 'e side sil ek wurde laden fia de provider snelle netwurken. Dit is wichtich foar ús, om't ús side yn prinsipe dynamysk is, it brûkt in protte subdomeinen, en it is handiger om ienris in CDN op te stellen foar de "asterisk" - *.semrushchina.cn.
Wy hiene dit produkt al sjoen yn 'e eardere stadia fan ús Sineeske projekt, mar doe wurke it noch net, en de ûntwikkelders tasein dat it produkt gau beskikber wêze soe foar alle klanten. En hy die.
Yn DCDN kinne jo:
- konfigurearje SSL-beëiniging mei jo sertifikaat,
- ynskeakelje fersnelling fan dynamyske ynhâld,
- fleksibel konfigurearje caching fan statyske bestannen,
- skjinmeitsje de cache,
- foarút web sockets,
- ynskeakelje kompresje en sels HTML Beautifier.
Yn 't algemien is alles itselde as by folwoeksenen en grutte CDN-oanbieders.
Nei't de oarsprong (it plak wêr't de CDN-rântsjinners sille gean) is oantsjutte, bliuwt allinich in CNAME foar it asterisk oan te meitsjen, ferwizing all.semrushchina.cn.w.kunluncan.com (dizze CNAME waard ûntfongen yn 'e Alibaba Cloud-konsole) en de CDN sil wurkje.
Op grûn fan de testresultaten hat dizze CDN ús in protte holpen. De statistiken wurde hjirûnder werjûn.
beslút
Uptime
Median
75 Persintyl
95 Persintyl
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
Dit binne heul goede resultaten, benammen as jo se fergelykje mei wat de sifers oan it begjin wiene. Mar wy wisten dat de browsertest fan 'e Amerikaanske ferzje fan ús webside www.semrush.com rint fan' e FS yn in gemiddelde fan 8.3s (in heul ûngefear wearde). Der is romte foar ferbettering. Boppedat wiene d'r ek CDN-oanbieders dy't ynteressant wiene om te testen.
Dat wy geane soepel troch nei in oare reus op 'e Sineeske merk - Tencent.
Tencent Cloud
Tencent ûntwikkelet gewoan syn wolk - dit kin sjoen wurde út in lyts oantal produkten. Wylst wy it brûke, woene wy net allinich har CDN testen, mar ek har netwurkynfrastruktuer as gehiel:
- hawwe se wat ferlykber mei CEN?
- Hoe wurket IPSEC foar har? Is it fluch, wat is de uptime?
- hawwe se Anycast?
Litte wy dizze fragen apart besjen.
Analooch CEN
Tencent hat in produkt Cloud Connect Network (), wêrtroch jo VPC's kinne ferbine fan ferskate regio's, ynklusyf regio's binnen en bûten Sina. It produkt is no yn ynterne beta, en jo moatte in kaartsje oanmeitsje dy't freget om dêrmei te ferbinen. Wy learden fan stipe dat globale akkounts (wy prate net oer Sineeske boargers of juridyske entiteiten) kinne net meidwaan oan it beta-testprogramma en, yn 't algemien, in regio yn Sina ferbine mei in regio bûten. 1-0 yn it foardiel fan Ali Cloud
IPSEC
De súdlikste regio fan Tencent is Guangzhou. Wy hawwe in tunnel gearstald en ferbûn mei de Hong Kong-regio yn GCP (doe wie dizze regio al beskikber wurden). De twadde tunnel yn Ali Cloud fan Shenzhen nei Hong Kong waard tagelyk ek ferhege. It die bliken dat troch it Tencent-netwurk de latency nei Hong Kong oer it algemien better is (10ms) as fan Shenzhen nei Hong Kong nei Ali (120ms - wat?). Mar dit hat op gjin inkelde manier it wurk fan 'e side fersnelle om troch Tencent en dizze tunnel te wurkjen, wat op himsels in geweldich feit wie en nochris it folgjende bewiisde: latency - foar Sina is dit gjin yndikator dy't echt wurdich is omtinken jaan oan by it ûntwikkeljen fan in oplossing foar it trochjaan fan de Sineeske firewall.
Anycast Internet Acceleration
In oar produkt wêrmei jo kinne wurkje fia anycast IP is . Mar it is ek net beskikber foar globale akkounts, dus ik sil jo der net oer fertelle, mar witten dat sa'n produkt bestiet kin nuttich wêze.
Mar de CDN-test liet wat aardich nijsgjirrige resultaten sjen. Tencent's CDN kin net ynskeakele wurde op in folsleine side, allinich op spesifike domeinen. Wy hawwe domeinen makke en ferkear nei har stjoerd:
It die bliken dat dizze CDN de folgjende funksje hat: Cross Border Traffic Optimization. Dizze funksje moat de kosten ferminderje as ferkear troch de Sineeske firewall giet. As Oarsprong It IP-adres fan Google GLB (GLB anycast) is opjûn. Sa woenen wy de projektarsjitektuer ferienfâldigje.
De resultaten wiene heul goed - op it nivo fan Ali Cloud CDN, en op guon plakken noch better. Dit is ferrassend, om't as de tests suksesfol binne, kinne jo in signifikant diel fan 'e ynfrastruktuer, tunnels, CEN, firtuele masines, ensfh.
Wy wiene net lang bliid, want in probleem waard ûntdutsen: testen yn Catchpoint mislearre foar de ynternetprovider China Mobile. Fan elke lokaasje krigen wy in time-out fia Tencent's CDN. Korrespondinsje mei technyske stipe hat net liede ta neat. Wy hawwe besocht dit probleem foar sawat in dei op te lossen, mar neat wurke.
Ik wie op dat stuit yn Sina, mar koe gjin iepenbiere Wi-Fi fine op it netwurk fan dizze provider om it probleem persoanlik te ferifiearjen. Oars seach alles der fluch en goed út.
Troch it feit dat China Mobile ien fan 'e trije grutste operators is, waarden wy lykwols twongen om ferkear werom te jaan nei Ali CDN.
Mar oer it algemien wie dit in nochal nijsgjirrige oplossing dy't langere testen en probleemoplossing fan dit probleem fertsjinnet.
Akamai
De lêste CDN-provider dy't wy testen wie Akamai. Dit is in enoarme provider dy't syn netwurk hat yn Sina. Dêr koene wy fansels net foarby.
Fan it begjin ôf hawwe wy mei Akamai ôfpraat foar in proefperioade, sadat wy it domein kinne wikselje en sjen hoe't it soe wurkje op har netwurk. Ik sil beskriuwe it resultaat fan alle testen yn 'e foarm fan "Wat ik leuk" en "Wat ik net leuk,"En ik sil ek jou de test resultaten.
Wat ik leuk vond:
- De jonges fan Akamai wiene tige behelpsum yn alle fragen en begelieden ús yn alle stadia fan testen. Wy besochten hieltyd wat oan ús kant te ferbetterjen. Se joegen goed technysk advys.
- Akamai is sawat 10-15% stadiger dan ús oplossing fia Ali Cloud CDN. Wat yndrukwekkend is, is dat wy yn Origin foar Akamai it IP-adres fan de GLB spesifisearje, wat betsjuttet dat it ferkear net troch ús oplossing gie (potinsjeel kinne wy in diel fan 'e ynfrastruktuer ferlitte). Mar dochs lieten de testresultaten sjen dat dizze oplossing slimmer is dan ús hjoeddeistige ferzje (fergelykjende resultaten hjirûnder).
- Teste sawol Origin GLB as Origin yn Sina. Beide opsjes binne sawat itselde.
- der binne Wis Rûte (automatyske rûteoptimalisaasje). Jo kinne in testobjekt op Origin hostje, en de Akamai Edge-tsjinners sille besykje it op te heljen (gewoane GET). Foar dizze oanfragen wurde snelheid en oare metriken mjitten, basearre op hokker it Akamai-netwurk de rûtes optimalisearret, sadat ferkear flugger giet foar ús side en it wie dúdlik dat it ynskeakeljen fan dizze funksje echt in sterke ynfloed hie op 'e snelheid fan' e side.
- Ferzje fan de konfiguraasje yn 'e webynterface is cool. Jo kinne dwaan Ferlykje foar ferzjes, sjoch diff. Besjoch eardere ferzjes.
- Jo kinne earst in nije ferzje útrolje allinich op it Akamai Staging-netwurk - itselde netwurk as produksje, allinich dizze manier sil gjin echte brûkers beynfloedzje. Foar dizze test moatte jo DNS-records spoofje op jo lokale masine.
- Hiel rappe downloadsnelheid fia har netwurk foar grutte statyske bestannen, en, blykber, alle oare bestannen. In bestân út 'e "kâlde" cache wurdt in protte kearen rapper ophelle as itselde bestân út 'e "kâlde" cache fan Ali CDN. Fanút de "hot" cache is de snelheid al itselde, plus of min.
Ali CDN test:
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/sAkamai test:
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/sWy hawwe opmurken dat de situaasje yn it foarbyld hjirboppe hinget fan ferskate faktoaren. Op it momint fan it skriuwen fan dit punt, rûn ik de test opnij. De resultaten foar beide platfoarms wiene sawat itselde. Dit fertelt ús dat it ynternet yn Sina, sels foar grutte operators en wolkproviders, fan tiid ta tiid oars gedraacht.
Oan it foarige punt sil ik in grut pluspunt tafoegje foar Akamai: as Ali ferlykbere flitsen fan hege prestaasjes en heul lege prestaasjes toant (dit jildt foar Ali CDN, Ali CEN en Ali IPSEC), dan Akamai, elke kear, gjin saak hoe't ik test harren netwurk, alles wurket stabyl.
Akamai hat wol in protte dekking yn Sina en wurket fia in protte providers.
Wat ik net leuk:
- Ik hâld net fan de webynterface en de manier wêrop it wurket - it is sa min. Mar yn prinsipe wurde jo der (wierskynlik) oan wend.
- Testresultaten binne slimmer dan ús side.
- D'r binne mear flaters tidens tests dan op ús side (uptime hjirûnder).
- Wy hawwe gjin eigen DNS-tsjinners yn Sina. Dêrtroch binne d'r in protte flaters yn tests fanwegen DNS-oplossing time-out.
- Se leverje har IP-beriken net -> d'r is gjin manier om de juste te registrearjen set_real_ip_from op ús servers.
Metriken (~ 3626 runs; alle metriken útsein Uptime, yn ms; statistiken foar ien tiidperioade):
CDN Provider
Median
75%
95%
Antwurd
Webside antwurd
Uptime
DNS
Ferbine
Wachtsje
Lade
SSL
AliCDN
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
Ferdieling per persintaazje (yn ms):
Persintaazje
Akamai
AliCDN
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
De konklúzje is dit: de Akamai-opsje is leefber, mar leveret net deselde stabiliteit en snelheid as ús eigen oplossing keppele oan Ali CDN.
Lytse notysjes
Guon mominten wiene net yn it ferhaal opnommen, mar dêr soe ik ek graach oer skriuwe wolle.
Peking + Tokio en Hong Kong
Lykas ik hjirboppe sei, testen wy in IPSEC-tunnel nei Hong Kong (HK). Mar wy testen ek CEN oan HK. It kostet wat minder, en ik frege my ôf hoe't it soe wurkje tusken stêden mei in ôfstân fan ~100 km. It die bliken ynteressant te wêzen dat de latency tusken dizze stêden 100ms heger is as yn ús oarspronklike ferzje (nei Taiwan). Faasje, stabiliteit wie ek better foar Taiwan. As gefolch hawwe wy HK ferlitten as in reservekopy IPSEC-regio.
Derneist hawwe wy besocht de folgjende ynstallaasje te ynstallearjen:
- beëiniging fan kliïnten yn Peking,
- IPSEC en CEN nei Tokio,
- yn Ali CDN waard de tsjinner yn Peking oanjûn as de oarsprong.
Dit skema wie net sa stabyl, al wie it yn termen fan snelheid oer it algemien net minder as ús oplossing. Oangeande de tunnel haw ik yntermitterende drippen sjoen, sels foar CEN, dy't stabyl moatte wêze moatte. Dêrom, wy werom nei it âlde skema en ûntmantele dizze staging.
Hjirûnder binne statistiken oer latency tusken ferskate regio's foar ferskate kanalen. Miskien hat immen der belangstelling foar.
IPsec
Ali cn-beijing GCP asia-noardeast1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms
CEN
Ali cn-beijing Ali ap-noordeast-1 — 54ms (!)
Ali cn-shenzhen Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen Ali us-east1 — 216ms
Algemiene ynformaasje oer it ynternet yn Sina
As oanfolling op de problemen mei it ynternet beskreaun oan it begjin, yn it earste diel fan it artikel.
- Ynternet yn Sina is frij rap binnen.
- De konklúzje waard makke op basis fan testen fan iepenbiere Wi-Fi-netwurken op ferskate lokaasjes dêr't dizze netwurken wurde brûkt troch in grut oantal minsken.
- De download- en uploadsnelheden nei servers yn Sina wiene respektivelik sawat 20 Mbit / s en 5-10 Mbit / s.
- De snelheid nei servers bûten Sina is gewoan mager, minder dan 1 Mbit / s.
- It ynternet yn Sina is net heul stabyl.
- Soms kinne siden fluch iepenje, soms stadich (op deselde tiid fan 'e dei op ferskate dagen), op betingst dat de konfiguraasje net feroaret. Wy observearre dit mei it foarbyld fan semrushchina.cn. Dit kin wurde taskreaun oan Ali CDN, dy't ek sa wurket en dat ôfhinklik fan 'e tiid fan' e dei, de posysje fan 'e stjerren, ensfh.
- Mobyl ynternet is hast oeral 4G of 4G+. Fang it yn 'e metro, liften - koartsein, oeral.
- It is in myte dat Sineeske brûkers allinich domeinen fertrouwe yn 'e .cn-sône. Wy learden dit direkt fan brûkers.
- Jo kinne sjen hoe trochferwize nei www.baidu.com (ek op it fêstelân fan Sina).
- In protte boarnen binne yndie blokkearre. Primitive: google.com, Facebook, Twitter. Mar in protte Google-boarnen wurkje (fansels, net op alle Wi-Fi en VPN wurdt net brûkt (ek oan 'e routerkant, dat is wis).
- In protte "technyske" domeinen fan blokkearre bedriuwen wurkje ek. Dit betsjut dat jo net altyd alle Google en oare skynber blokkearde boarnen moatte útsnije. Jo moatte sykje nei wat list mei ferbeane domeinen.
- Se hawwe mar trije haad ynternetoperators: China Unicom, China Telecom, China Mobile. D'r binne noch lytsere, mar har merkoandiel is net folle
Bonus: definitive oplossing diagram
It resultaat
In jier is ferrûn sûnt de start fan it projekt. Wy begûnen mei it feit dat ús side oer it algemien wegere om normaal te wurkjen út Sina, en gewoan GET curl naam 5.5 sekonden.
Dan, mei dizze yndikatoaren yn 'e earste oplossing (Cloudflare):
beslút
Uptime
Median
75 Persintyl
95 Persintyl
Cloudflare
86.6
18s
30s
60s
Wy berikten úteinlik de folgjende resultaten (statistyk foar de lêste moanne):
beslút
Uptime
Median
75 Persintyl
95 Persintyl
Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s
Sa't jo sjen kinne, binne wy noch net yn steat west om 100% uptime te berikken, mar wy sille wat betinke, en dan sille wy jo fertelle oer de resultaten yn in nij artikel :)
Respekt foar dyjingen dy't alle trije dielen oant it ein lêze. Ik hoopje dat jo dit alles sa ynteressant fûnen as ik doe't ik it die.
P.S. Foarige dielen
Boarne: www.habr.com