Tere!
Kõik head lood saavad otsa. Ja meie lugu sellest, kuidas leidsime lahenduse Hiina tulemüüri kiireks läbimiseks, pole erand. Seetõttu kiirustan teiega viimast, viimane osa sellel teemal.
Eelmises osas rääkisime paljudest katsestendidest, mis me välja mõtlesime ja milliseid tulemusi need andsid. Ja me otsustasime, mida oleks tore lisada CDN! viskoossuse jaoks meie skeemi.
Ma räägin teile, kuidas testisime Alibaba Cloud CDN-i, Tencent Cloud CDN-i ja Akamaid ning milleni me lõpuks jõudsime. Ja muidugi, teeme kokkuvõtte.
Alibaba pilve CDN
Meid majutatakse Alibaba Cloudis ja kasutame nende IPSEC-i ja CEN-i. Loogiline oleks enne nende lahendusi proovida.
Alibaba Cloudil on kahte tüüpi tooteid, mis võivad meile sobida: CDN и DCDN. Esimene võimalus on klassikaline CDN konkreetse domeeni (alamdomeeni) jaoks. Teine variant tähistab CDN-i dünaamiline marsruut (Ma nimetan seda dünaamiliseks CDN-iks), seda saab lubada täissaidi režiimis (metamärgiga domeenide jaoks), see salvestab ka staatilise sisu vahemällu ja kiirendab dünaamilist sisu enda peal, see tähendab, et lehe dünaamika laaditakse ka teenusepakkuja kaudu. kiired võrgud. See on meie jaoks oluline, sest põhimõtteliselt on meie sait dünaamiline, see kasutab palju alamdomeene ja mugavam on CDN-i üks kord seadistada tärniga - *.semrushchina.cn.
Olime seda toodet juba oma Hiina projekti varasemates etappides näinud, kuid siis see veel ei töötanud ning arendajad lubasid, et toode muutub peagi kättesaadavaks kõikidele klientidele. Ja ta tegigi.
DCDN-is saate:
- konfigureerige oma sertifikaadiga SSL-i lõpetamine,
- võimaldada dünaamilise sisu kiirendamist,
- paindlikult konfigureerida staatiliste failide vahemällu,
- tühjendage vahemälu,
- edasi veebipistikupesad,
- lubage tihendamine ja isegi HTML Beautifier.
Üldiselt on kõik sama, mis täiskasvanute ja suurte CDN-i pakkujate puhul.
Pärast lähtekoha (koht, kuhu CDN servaserverid lähevad) määramist jääb üle vaid luua tärnile CNAME, viidates all.semrushchina.cn.w.kunluncan.com (see CNAME võeti vastu Alibaba Cloudi konsoolis) ja CDN töötab.
Testitulemuste põhjal aitas see CDN meid palju. Statistika on näidatud allpool.
otsus
Töö kestvus
Mediaan
75 protsentiil
95 protsentiil
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
Need on väga head tulemused, eriti kui võrrelda neid algsete numbritega. Kuid teadsime, et meie veebisaidi www.semrush.com Ameerika versiooni brauseri test jookseb USA-st keskmiselt 8.3 sekundiga (väga ligikaudne väärtus). Arenguruumi on. Lisaks oli ka CDN-i pakkujaid, mida oli huvitav testida.
Nii et liigume sujuvalt edasi teise hiiglase juurde Hiina turul - Tencent.
Tencent Pilv
Tencent arendab alles oma pilve – seda on näha vähesel hulgal toodetel. Selle kasutamise ajal tahtsime testida mitte ainult nende CDN-i, vaid ka kogu võrgu infrastruktuuri:
- kas neil on midagi sarnast CENiga?
- Kuidas IPSEC nende jaoks töötab? Kas see on kiire, milline on tööaeg?
- kas neil on Anycast?
Vaatame neid küsimusi eraldi.
Analoog CEN
Tencentil on toode Cloud Connecti võrk (), mis võimaldab teil ühendada VPC-sid erinevatest piirkondadest, sealhulgas piirkondadest Hiinas ja väljaspool seda. Toode on nüüd sisemises beetaversioonis ja peate looma pileti, mis palub sellega ühenduse luua. Saime tugiteenustest teada, et globaalsed kontod (me ei räägi Hiina kodanikest ega juriidilistest isikutest) ei saa beetatestimise programmis osaleda ja üldiselt ühendavad Hiinas asuvat piirkonda väljaspool asuva piirkonnaga. 1:0 Ali Cloudi kasuks
IPSEC
Tencenti lõunapoolseim piirkond on Guangzhou. Panime kokku tunneli ja ühendasime selle GCP-s Hongkongi piirkonnaga (siis oli see piirkond juba vabaks saanud). Samal ajal tõsteti ka teine tunnel Ali Cloudis Shenzhenist Hongkongi. Selgus, et Tencenti võrgu kaudu on latentsus Hongkongi üldiselt parem (10ms) kui Shenzhenist Hongkongi Ali (120ms – mis?). Kuid see ei kiirendanud mingil moel Tencenti ja selle tunneli läbimiseks mõeldud saidi tööd, mis iseenesest oli hämmastav fakt ja tõestas taas järgmist: latentsus - Hiina jaoks pole see näitaja, mis on tõesti väärt. pöörates tähelepanu Hiina tulemüüri läbimise lahenduse väljatöötamisel.
Anycasti Interneti-kiirendus
Teine toode, mis võimaldab teil töötada Anycast IP kaudu, on . Kuid see pole saadaval ka globaalsetele kontodele, nii et ma ei räägi teile sellest, kuid teadmine, et selline toode on olemas, võib olla kasulik.
Kuid CDN-i test näitas päris huvitavaid tulemusi. Tencenti CDN-i ei saa lubada täissaidil, vaid ainult teatud domeenidel. Lõime domeenid ja saatsime neile liikluse:
Selgus, et sellel CDN-il on järgmine funktsioon: Piiriülese liikluse optimeerimine. See funktsioon peaks vähendama kulusid, kui liiklus läbib Hiina tulemüüri. Nagu päritolu Määrati Google GLB (GLB anycast) IP-aadress. Seega soovisime projekti arhitektuuri lihtsustada.
Tulemused olid väga head – Ali Cloud CDN tasemel ja kohati isegi paremad. See on üllatav, sest kui testid on edukad, võid loobuda olulisest osast infrastruktuurist, tunnelitest, CENist, virtuaalmasinatest jne.
Me ei rõõmustanud kaua, sest ilmnes probleem: Catchpointi testid ebaõnnestusid Interneti-pakkuja China Mobile'i jaoks. Mis tahes asukohast saime Tencenti CDN-i kaudu ajalõpu. Kirjavahetus tehnilise toega ei viinud millegini. Üritasime seda probleemi lahendada umbes päeva, kuid midagi ei aidanud.
Olin sel hetkel Hiinas, kuid ei leidnud selle teenusepakkuja võrgust avalikku WiFi-ühendust, et probleemi isiklikult kontrollida. Muidu tundus kõik kiire ja hea.
Kuid kuna China Mobile on üks kolmest suurimast operaatorist, olime sunnitud liikluse Ali CDN-ile tagastama.
Kuid üldiselt oli see üsna huvitav lahendus, mis väärib selle probleemi pikemat testimist ja tõrkeotsingut.
Akamai
Viimane CDN-i pakkuja, mida testisime, oli Akamai. See on tohutu pakkuja, mille võrk asub Hiinas. Muidugi ei saanud me sellest mööda.
Kohe alguses leppisime Akamaiga kokku prooviperioodi, et saaksime domeeni vahetada ja vaadata, kuidas see nende võrgus töötab. Kirjeldan kogu testimise tulemust vormis "Mis mulle meeldis" ja "Mis mulle ei meeldinud" ning annan ka testi tulemused.
Mis mulle meeldis:
- Akamai poisid olid kõigis küsimustes väga abivalmid ja saatsid meid kõikidel testimise etappidel. Püüdsime pidevalt midagi enda poolel parandada. Nad andsid head tehnilist nõu.
- Akamai on umbes 10-15% aeglasem kui meie lahendus Ali Cloud CDN-i kaudu. Muljetavaldav on see, et Origin for Akamai määrasime GLB IP-aadressi, mis tähendab, et liiklus ei läbinud meie lahendust (potentsiaalselt võime osa infrastruktuurist loobuda). Kuid siiski näitasid testi tulemused, et see lahendus on halvem kui meie praegune versioon (võrdlustulemused allpool).
- Testitud nii Origin GLB kui ka päritolu Hiinas. Mõlemad valikud on ligikaudu samad.
- On Kindel marsruut (automaatne marsruutimise optimeerimine). Saate Originis testobjekti hostida ja Akamai Edge'i serverid proovivad seda üles võtta (tavaline GET). Nende päringute puhul mõõdetakse kiirust ja muid mõõdikuid, mille põhjal Akamai võrk optimeerib marsruute nii, et liiklus meie saidi jaoks kiiremaks läheks, ja oli selge, et selle funktsiooni lubamine avaldas saidi kiirusele tõesti tugevat mõju.
- Konfiguratsiooni versioonide muutmine veebiliideses on lahe. Saate teha versioonide võrdlemise, vaadake diff. Vaata eelmisi versioone.
- Uue versiooni saate esmalt kasutusele võtta ainult Akamai Staging võrgus – see on sama võrk, mis tootmises, ainult see viis ei mõjuta tegelikke kasutajaid. Selle testi jaoks peate oma kohalikus masinas DNS-kirjeid võltsima.
- Väga kiire allalaadimiskiirus nende võrgu kaudu suurte staatiliste failide ja ilmselt ka muude failide jaoks. Fail "külmast" vahemälust hangitakse mitu korda kiiremini kui sama fail Ali CDN-i "külmast" vahemälust. "Kuumast" vahemälust on kiirus juba sama, pluss või miinus.
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/sMärkasime, et ülaltoodud näite olukord sõltub erinevatest teguritest. Selle punkti kirjutamise ajal tegin testi uuesti. Mõlema platvormi tulemused olid ligikaudu samad. See ütleb meile, et Internet käitub Hiinas isegi suurte operaatorite ja pilveteenuse pakkujate jaoks aeg-ajalt erinevalt.
Eelmisele punktile lisan Akamai jaoks suure plussi: kui Ali näitab sarnaseid suure jõudlusega ja väga madala jõudlusega sähvatusi (see kehtib Ali CDN, Ali CEN ja Ali IPSEC kohta), siis Akamai iga kord, olenemata kuidas ma nende võrku testin, siis kõik töötab stabiilselt.
Akamail on Hiinas palju leviala ja see töötab paljude pakkujate kaudu.
Mis mulle ei meeldinud:
- Mulle ei meeldi veebiliides ja selle toimimisviis – see on nii kehv. Aga põhimõtteliselt harjub ära (ilmselt).
- Testi tulemused on halvemad kui meie saidil.
- Testide ajal on rohkem vigu kui meie saidil (tööaeg allpool).
- Meil ei ole Hiinas oma DNS-servereid. Seetõttu on DNS-i lahendamise ajalõpu tõttu testides palju vigu.
- Nad ei anna oma IP-vahemikke -> pole võimalik õigeid registreerida set_real_ip_from meie serverites.
Mõõdikud (~3626 käitamist; kõik mõõdikud, välja arvatud tööaeg, ms; statistika ühe perioodi kohta):
CDN-i pakkuja
Mediaan
75%
95%
Vastus
Veebilehe vastus
Töö kestvus
DNS
Võta meiega ühendust
Oota
Koormus
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
Jaotus protsentiili järgi (ms):
Protsentuaalne
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
Järeldus on järgmine: Akamai variant on elujõuline, kuid ei taga sama stabiilsust ja kiirust kui meie enda lahendus koos Ali CDN-iga.
Väikesed märkmed
Mõned hetked jäid loo sisse panemata, aga ma tahaksin ka neist kirjutada.
Peking + Tokyo ja Hongkong
Nagu ma eespool ütlesin, katsetasime IPSECi tunnelit Hongkongi (HK). Kuid testisime ka CEN-i HK-ga. Maksab veidi vähem ja mõtlesin, et kuidas see ~100 km vahemaa linnade vahel toimiks. Huvitavaks osutus see, et nende linnade vaheline latentsusaeg on 100 ms kõrgem kui meie algses versioonis (Taiwani). Kiirus, stabiilsus oli ka Taiwanil parem. Selle tulemusena lahkusime HK-st IPSEC-i varupiirkonnaks.
Lisaks proovisime installida järgmise installi:
- klientide lõpetamine Pekingis,
- IPSEC ja CEN Tokyosse,
- Ali CDN-is märgiti lähtekohaks Pekingi server.
See skeem ei olnud nii stabiilne, kuigi kiiruse poolest ei jäänud see üldiselt meie lahendusele alla. Tunneli osas olen näinud vahelduvaid langusi isegi CENi puhul, mis oleks pidanud olema stabiilne. Seetõttu pöördusime tagasi vana skeemi juurde ja võtsime selle lavastuse laiali.
Allpool on statistika latentsuse kohta erinevate kanalite eri piirkondade vahel. Äkki keegi tunneb selle vastu huvi.
IPsec
Ali cn-peking <—> GCP Aasia kirdeosa1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms
CEN
Ali cn-peking <—> Ali ap-kirde-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong – 6 ms (!)
Ali cn-shenzhen <—> Ali us-ida1 — 216ms
Üldine teave Interneti kohta Hiinas
Täiendusena kohe alguses artikli esimeses osas kirjeldatud Interneti-probleemidele.
- Internet Hiinas on sees üsna kiire.
- Järeldus tehti avalike WiFi-võrkude testimise põhjal erinevates kohtades, kus neid võrke kasutab suur hulk inimesi.
- Hiinas asuvate serverite alla- ja üleslaadimiskiirused olid vastavalt umbes 20 Mbit/s ja 5-10 Mbit/s.
- Kiirus väljaspool Hiinat asuvatesse serveritesse on lihtsalt napp, alla 1 Mbit/s.
- Internet Hiinas ei ole kuigi stabiilne.
- Mõnikord saavad saidid avaneda kiiresti, mõnikord aeglaselt (eri päevadel samal kellaajal), eeldusel, et konfiguratsioon ei muutu. Vaatlesime seda semrushchina.cn näitel. Selle põhjuseks võib pidada Ali CDN-i, mis samuti töötab nii ja naa olenevalt kellaajast, tähtede asukohast jne.
- Mobiilne Internet on peaaegu kõikjal 4G või 4G+. Püüa seda metroos, liftides – ühesõnaga kõikjal.
- On müüt, et Hiina kasutajad usaldavad ainult cn-tsoonis olevaid domeene. Õppisime seda otse kasutajatelt.
- Näete, kuidas suunata aadressile www.baidu.com (ka Mandri-Hiinas).
- Paljud ressursid on tõepoolest blokeeritud. Primitiivne: google.com, Facebook, Twitter. Kuid paljud Google'i ressursid töötavad (muidugi mitte kõigis WiFi-võrkudes ja VPN-i ei kasutata (ka ruuteri poolel, see on kindel).
- Samuti töötavad paljud blokeeritud ettevõtete tehnilised domeenid. See tähendab, et te ei tohiks alati hoolimatult kõiki Google'i ja muid näiliselt blokeeritud ressursse välja lõigata. Peate otsima keelatud domeenide loendit.
- Neil on ainult kolm peamist Interneti-operaatorit: China Unicom, China Telecom, China Mobile. Väiksemaidki on, aga nende turuosa on tühine
Boonus: lõpplahenduse diagramm
Summaarne
Projekti algusest on möödas aasta. Alustasime sellest, et meie sait keeldus üldiselt Hiinast normaalselt töötamast ja lihtsalt GET curl võttis aega 5.5 sekundit.
Seejärel nende indikaatoritega esimeses lahenduses (Cloudflare):
otsus
Töö kestvus
Mediaan
75 protsentiil
95 protsentiil
CloudFlare
86.6
18s
30s
60s
Lõpuks jõudsime järgmiste tulemusteni (viimase kuu statistika):
otsus
Töö kestvus
Mediaan
75 protsentiil
95 protsentiil
Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s
Nagu näete, ei ole me veel suutnud 100% tööaega saavutada, kuid me mõtleme midagi välja ja siis räägime teile tulemustest uues artiklis :)
Respekt neile, kes kõik kolm osa lõpuni lugesid. Loodan, et see kõik oli teile sama huvitav kui minu jaoks, kui ma seda tegin.
PS Eelmised osad
Allikas: www.habr.com