Привет!
Alle goeie stories kom tot 'n einde. En ons storie oor hoe ons vorendag gekom het met 'n Chinese Firewall-snelpasoplossing is geen uitsondering nie. Daarom haas ek my om die nuutste met jou te deel, laaste deel oor hierdie onderwerp.
In die vorige deel is vertel van die baie toetsbanke wat ons uitgevind het, en watter resultate dit opgelewer het. En ons het besluit wat lekker sou wees om by te voeg CDN! vir viskositeit in ons skema.
Ek sal jou vertel hoe ons Alibaba Cloud CDN, Tencent Cloud CDN en Akamai getoets het, en waar ons beland het. En natuurlik, kom ons som dit op.
Alibaba Wolk CDN
Ons word op Alibaba Cloud aangebied, ons gebruik IPSEC en CEN van hulle. Dit sal logies wees om eers hul oplossings te probeer.
Alibaba Cloud het twee soorte produkte wat by ons kan pas: CDN и DCDN. Die eerste opsie is 'n klassieke CDN vir 'n spesifieke domein (subdomein). Die tweede opsie word ontsyfer as Dinamiese roete vir CDN (Ek noem dit dinamiese CDN), dit kan geaktiveer word in Volledige modus (vir wildcard-domeine), dit kas ook statika en versnel dinamiese inhoud op homself, dit wil sê, bladsydinamika sal ook deur die verskaffer se vinnige netwerke gelaai word. Dit is vir ons belangrik, want basies is ons webwerf dinamies, dit gebruik baie subdomeine, en dit is geriefliker om een keer 'n CDN op te stel vir die "asterisk" - *.semrushchina.cn.
Ons het hierdie produk reeds in die vroeëre stadiums van ons Chinese projek gesien, maar toe het dit nog nie gewerk nie, en die ontwikkelaars het belowe dat die produk binnekort vir alle kliënte beskikbaar sal wees. En hy het geword.
In DCDN kan jy:
- stel SSL-beëindiging op met jou sertifikaat,
- aktiveer dinamiese inhoudversnelling,
- konfigureer die kas van statiese lêers buigsaam,
- maak kas skoon,
- vorentoe web voetstukke,
- aktiveer kompressie en selfs HTML Beautifier.
Oor die algemeen is alles soos by volwassenes en groot CDN-verskaffers.
Nadat die Oorsprong (die plek waarheen die CDN-randbedieners sal gaan) gespesifiseer is, bly dit om 'n CNAME vir die asterisk te skep, met verwysing na all.semrushchina.cn.w.kunluncan.com (hierdie CNAME is in die Alibaba Wolk-konsole ontvang), en die CDN sal werk.
Volgens die toetsuitslae het hierdie CDN ons baie gehelp. Die statistieke word hieronder getoon.
besluit
Uptime
mediaan
75 persentiel
95 persentiel
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 is baie goeie resultate, veral as ons dit vergelyk met wat die syfers aan die begin was. Maar ons het geweet dat die blaaiertoets van die Amerikaanse weergawe van ons webwerf www.semrush.com gemiddeld vanaf die VSA in 8.3s loop ('n baie benaderde waarde). Daar is iets om na te streef. Boonop was daar ook CDN-verskaffers wat interessant was om te toets.
Ons beweeg dus glad aan na 'n ander reus in die Chinese mark - Tencent.
Tencent Wolk
Tencent ontwikkel net sy wolk – dit kan in ’n klein aantal produkte gesien word. In die loop van die gebruik daarvan wou ons nie net hul CDN toets nie, maar die hele netwerkinfrastruktuur:
- het hulle iets soortgelyk aan CEN?
- hoe werk IPSEC vir hulle? Is dit vinnig, wat is die optyd?
- het hulle Anycast?
Kom ons ondersoek hierdie vrae afsonderlik.
CEN analoog
Tencent het 'n produk Wolk Connect-netwerk (), sodat jy VPC's van verskillende streke met mekaar kan verbind, insluitend streke binne China en buite. Die produk is tans in interne beta, en jy moet 'n kaartjie skep met 'n versoek om daaraan te koppel. Uit ondersteuning het ons geleer dat globale rekeninge (ons praat nie van Chinese burgers of regsentiteite nie) nie aan die beta-toetsprogram kan deelneem nie en in die algemeen die streek binne China met die streek buite kan verbind. 1-0 in die guns van Ali Cloud
IPsec
Tencent se mees suidelike streek is Guangzhou. Ons het 'n tonnel saamgestel en dit met die Hong Kong-streek in die GCP verbind (toe was hierdie streek reeds beskikbaar). Die tweede tonnel in Ali Cloud van Shenzhen na Hong Kong is ook terselfdertyd opgehef. Dit het geblyk dat deur die Tencent-netwerk, latency na Hong Kong oor die algemeen beter is (10ms) as van Shenzhen na Hong Kong tot Ali (120ms - wat?). Maar dit het op geen manier die werk van die webwerf versnel wat daarop gemik was om deur Tencent en hierdie tonnel te werk nie, wat op sigself 'n wonderlike feit was en weereens die volgende bewys het: latency vir China is nie 'n aanduiding dat jy regtig moet aandag gee nie wanneer 'n oplossing ontwikkel word om die Chinese firewall te slaag.
Anycast internetversnelling
Nog 'n produk waarmee u deur enige uitsaai-IP kan werk - . Maar dit is ook nie beskikbaar vir globale rekeninge nie, so ek sal nie daaroor praat nie, maar om te weet dat so 'n produk bestaan, kan nuttig wees.
Maar die CDN-toets het nogal interessante resultate getoon. Tencent se CDN kan nie op 'n volledige webwerf geaktiveer word nie, slegs op spesifieke domeine. Ons het domeine opgestel en verkeer na hulle gestuur:
Dit het geblyk dat hierdie CDN die volgende funksie het: Oorgrensverkeeroptimalisering. Hierdie kenmerk behoort koste te verminder wanneer verkeer deur die Chinese firewall gaan. Soos Oorsprong die IP-adres van die Google GLB (GLB anycast) is gespesifiseer. Ons wou dus die argitektuur van die projek vereenvoudig.
Die resultate was baie goed - op die vlak van Ali Cloud CDN, en op sommige plekke selfs beter. Dit is verbasend, want as die toetse suksesvol is, kan jy 'n beduidende deel van die infrastruktuur, tonnels, CEN, virtuele masjiene, ens.
Ons was nie lank bly nie, aangesien 'n probleem aan die lig gebring is: die toetse in Catchpoint het vir die internetverskaffer China Mobile misluk. Ons het 'n time-out vanaf enige plek ontvang via Tencent se CDN. Korrespondensie met tegniese ondersteuning het tot niks gelei nie. Ons het omtrent 'n dag lank probeer om hierdie probleem op te los, maar niks het daarvan gekom nie.
Ek was toe in China, maar ek kon nie publieke Wi-Fi op daardie verskaffer se netwerk vind om self te sien nie. Andersins het alles vinnig en goed gelyk.
As gevolg van die feit dat China Mobile een van die drie grootste operateurs is, was ons gedwing om verkeer terug te stuur na Ali CDN.
Maar oor die algemeen was dit nogal 'n interessante oplossing wat meer toetsing en probleemoplossing van hierdie probleem verdien.
Akamai
Die laaste CDN-verskaffer wat ons getoets het, is Akamai. Dit is 'n groot verskaffer wat sy eie netwerk in China het. Natuurlik kon ons nie verby dit kom nie.
Van die begin af het ons met Akamai ooreengekom oor 'n proeftydperk sodat ons die domein kan verander en kyk hoe dit op hul netwerk sal werk. Ek sal die resultaat van alle toetse beskryf in die vorm van "Waarvan ek gehou het" en "Waarvan ek nie gehou het nie", en ek sal ook die toetsresultate gee.
Waarvan ons gehou het:
- Die ouens van Akamai was baie behulpsaam in alle sake en het ons in alle stadiums van toetsing vergesel. Gedurig probeer om iets aan hul kant te verbeter. Hulle het goeie tegniese raad gegee.
- Akamai is ongeveer 10-15% stadiger as ons oplossing via Ali Cloud CDN. Dit is indrukwekkend dat ons in Origin for Akamai die GLB IP-adres gespesifiseer het, dit wil sê die verkeer het nie deur ons oplossing gegaan nie (dit is moontlik om 'n deel van die infrastruktuur te laat vaar). Maar tog het die toetsresultate getoon dat hierdie oplossing erger is as ons huidige weergawe (vergelykende resultate hieronder).
- Getoets deur beide Origin GLB en Origin in China. Albei opsies is omtrent dieselfde.
- Daar is Seker roete (outomatiese roeteoptimering). Jy kan 'n toetsvoorwerp op Origin aanbied, en die Edge-bedieners van Akamai sal probeer om dit op te tel (normale GET). Vir hierdie versoeke word spoed en ander maatstawwe gemeet, op grond waarvan die Akamai-netwerk roetes optimaliseer sodat verkeer vinniger vir ons webwerf gaan en dit was duidelik dat die insluiting van hierdie kenmerk werklik 'n groot impak op die spoed van die webwerf gehad het .
- Die weergawe van die konfigurasie in die webkoppelvlak is cool. Dit is moontlik om Vergelyk vir weergawes te maak, om na verskil te kyk. Bekyk vorige weergawes.
- U kan eers 'n nuwe weergawe slegs op die Akamai Staging-netwerk ontplooi - dieselfde netwerk as produksie, maar hierdie manier sal nie werklike gebruikers beïnvloed nie. Vir hierdie toets moet u DNS-rekords op die plaaslike masjien bedrieg.
- Baie vinnige aflaai spoed deur hul netwerk van groot statiese, en, blykbaar, enige ander lêers. 'n Lêer vanaf 'n "koue" kas word baie keer vinniger geneem as dieselfde lêer vanaf 'n "koue" Ali CDN-kas. Vanaf die "warm" kas is die spoed plus of minus dieselfde.
Ali CDN toets:
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 toets:
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/sOns het opgemerk dat die situasie uit die voorbeeld hierbo afhang van verskeie faktore. Ten tyde van hierdie skrywe het ek weer die toets afgelê. Die resultate vir beide platforms was omtrent dieselfde. Dit sê vir ons dat die internet in China, selfs vir groot operateurs en wolkverskaffers, van tyd tot tyd anders optree.
Ek sal Akamai se groot pluspunt by die vorige punt voeg: as Ali soortgelyke flitse van hoë werkverrigting en baie laag toon (dit geld vir Ali CDN, Ali CEN en Ali IPSEC), dan Akamai elke keer, maak nie saak hoe ek hul netwerk toets nie , alles werk stabiel.
Akamai het 'n uitstekende dekking in China en werk deur baie verskaffers.
Wat nie gehou het nie:
- Ek hou nie van die webkoppelvlak en die werkskema nie - hulle is so nul. Maar in beginsel raak jy gewoond daaraan (waarskynlik).
- Die toetsresultate is slegter as ons webwerf.
- Daar is meer foute tydens toetse as op ons webwerf (uptyd hieronder).
- Daar is geen DNS-bedieners in China nie. Vandaar baie foute in die toetse as gevolg van DNS-resolusie-time-out.
- Hulle verskaf nie hul IP-reekse nie -> daar is geen manier om die korrekte te registreer nie stel_regte_ip_van op ons bedieners.
Metrieke (~3626 lopies; alle maatstawwe, behalwe Uptime, in ms; statistieke vir een tydperk):
CDN-verskaffer
mediaan
75%
95%
reaksie
Webblad reaksie
Uptime
DNS
Skakel in
Wag
vrag
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
Verspreiding volgens Persentiel (in ms):
persentiel
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
Die gevolgtrekking is dit: die Akamai-opsie is lewensvatbaar, maar bied nie dieselfde stabiliteit en spoed-aanwysers as ons eie oplossing, tesame met Ali CDN nie.
Klein notas
Sommige oomblikke is nie in die storie ingesluit nie, maar ek wil ook graag daaroor skryf.
Beijing + Tokio en Hong Kong
Soos ek hierbo gesê het, het ons die IPSEC-tonnel na Hong Kong (HK) getoets. Maar ons het ook CEN aan HK getoets. Dit kos 'n bietjie minder, en dit was interessant hoe dit tussen stede met 'n afstand van ~100km sou werk. Dit blyk interessant te wees dat die vertraging tussen hierdie stede 100 ms hoër is as in ons oorspronklike weergawe (na Taiwan). Spoed, stabiliteit was ook beter vir Taiwan. As gevolg hiervan het ons HK verlaat as 'n rugsteun-IPSEC-streek.
Daarbenewens het ons probeer om so 'n installasie op te rig:
- beëindiging van kliënte in Beijing,
- IPSEC en CEN na Tokio,
- in Ali CDN is die bediener in Beijing as die oorsprong aangedui.
Hierdie skema was nie so stabiel nie, hoewel dit in die algemeen nie minderwaardig was as ons oplossing wat spoed betref nie. Wat die tonnel betref, het ek onderbroke dalings gesien, selfs vir CEN, wat stabiel moes gewees het. Daarom het ons na die ou skema teruggekeer en hierdie verhoogwerk afgebreek.
Hieronder is statistieke oor latensie tussen verskillende streke via verskillende kanale. Miskien sal iemand daarin belangstel.
IPsec
Ali cn-beijing <—> GCP asië-noordoos1 - 193ms
Ali cn-shenzhen <—> GCP asië-ooste2 - 91ms
Ali cn-shenzhen <—> GCP us-east4 - 200ms
CEN
Ali cn-beijing <—> Ali ap-noordooste-1 - 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong - 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 - 216ms
Algemene inligting oor die internet in China
As 'n toevoeging tot die internetprobleme wat heel aan die begin beskryf is, in die eerste deel van die artikel.
- Internet in China is redelik vinnig binne.
- Die gevolgtrekking is gemaak op grond van die toets van openbare Wi-Fi-netwerke op verskeie plekke waar netwerkdata deur 'n groot aantal mense gebruik word.
- Die aflaai- en oplaaispoed na bedieners binne China was onderskeidelik ongeveer 20 Mbps en 5-10 Mbps.
- Die spoed na bedieners buite China is net ellendig, minder as 1 Mbps.
- Die internet in China is nie baie stabiel nie.
- Soms kan werwe vinnig oopmaak, soms stadig (op dieselfde tyd van die dag op verskillende dae), mits die konfigurasie nie verander nie. Ons het dit in die voorbeeld van semrushchina.cn waargeneem. Dit kan toegeskryf word aan Ali CDN, wat ook so werk en dat, afhangende van die tyd van die dag, die posisie van die sterre, ens.
- Mobiele internet is byna oral 4G of 4G+. Vangste in die metro, hysbakke - kortom, oral.
- Dit is 'n mite dat Chinese gebruikers slegs domeine in die .cn-sone vertrou. Ons het dit direk by gebruikers geleer.
- Jy kan sien hoe herlei na www.baidu.com (ook in die vasteland van China).
- Baie hulpbronne is inderdaad geblokkeer. Primitief: google.com, Facebook, Twitter. Maar baie Google-hulpbronne werk (natuurlik word nie alle Wi-Fi en VPN nie gelyktydig gebruik nie (aan die kant van die router ook, dit is seker).
- Baie "tegniese" domeine van geblokkeerde korporasies werk ook. Dit beteken dat jy nie altyd al die Google en ander oënskynlik geblokkeerde hulpbronne roekeloos moet uitsny nie. Jy moet soek na 'n lys van verbode domeine.
- Hulle het net drie hoof internetoperateurs: China Unicom, China Telecom, China Mobile. Daar is selfs kleineres, maar hul markaandeel is onbeduidend
Bonus: finale oplossingskema
Totale
’n Jaar het verloop sedert die begin van die projek. Ons het begin met die feit dat ons webwerf oor die algemeen geweier het om normaalweg vanaf China te werk, maar bloot GET curl het 5.5 sekondes geneem.
Dan, van sulke aanwysers in die eerste besluit (Cloudflare):
besluit
Uptime
mediaan
75 persentiel
95 persentiel
Cloudflare
86.6
18s
30s
60s
Ons het met die volgende resultate (statistieke vir die afgelope maand) geëindig:
besluit
Uptime
mediaan
75 persentiel
95 persentiel
Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s
Soos u kan sien, is 100% uptyd nog nie bereik nie, maar ons sal met iets vorendag kom, en dan sal ons u in 'n nuwe artikel vertel van die resultate :)
Aan diegene wat al drie dele tot die einde gelees het – respek. Ek hoop jy het dit so geniet soos ek toe ek dit gedoen het.
PS Vorige dele
Bron: will.com