🥇Kuidas me ületasime Suure Hiina Tulemüüri (osa 3)

Tere!
Iga hea lugu tuleb lõpule. Ja meie lugu sellest, kuidas me leiutasime lahenduse Hiina tulemüüri kiireks ületamiseks, ei ole erand. Seetõttu kiirustan jagama teiega viimast, lõppt osa sel teemal.

Eelmisel osal rääkisime paljusid katseplatvorme, mille me ise välja mõtlesime, ja milliseid tulemusi need andsid. Jõudsime sinna, et oleks hea idee lisada CDN! meie skeemi elujõudmiseks.

Räägin teile, kuidas me testisime Alibaba Cloud CDN-i, Tencent Cloud CDN-i ja Akamai, ning millel me lõpuks peatusime. Ja muidugi teeme kokkuvõtte.

Alibaba Cloud CDN

Me oleme majutatud Alibaba Cloudis, kasutame IPSEC-i ja CEN-i samast kohast. On loogiline, et proovime kõigepealt nende lahendusi.

Alibaba Cloudil on kaks tüüpi toodet, mis võivad meile sobida: CDN ja DCDN. Esimene variant on klassikaline CDN teatud domeenile (alamdomeenile). Teine variant tähendab Dünaamiline marsruut CDN-i jaoks (ma nimetan seda dünaamiliseks CDN-iks), seda saab kasutada Full-site režiimis (wildcard domeenide jaoks), see salvestab staatilise sisu ja kiirendab dünaamilist sisu, mis tähendab, et ka lehe dünaamika laaditakse läbi teenusepakkuja kiirete võrguühenduste. See on meile oluline, sest meie sait on peamiselt dünaamiline, kasutame mitmeid alamdomeene ja on mugavam seadistada CDN üks kord 'tähe' jaoks — *.semrushchina.cn.

Oleme seda toodet juba näinud meie varasemates Hiina projekti etappides, kuid sel hetkel ei töötanud see veel ja arendajad lubasid, et toode on kiiresti kõikidele klientidele kergesti saadaval. Ja nüüd see on.

DCDN-is saab:

seada SSL-terminatsiooni oma sertifikaadiga,
aktiveerida dünaamilise sisu kiirenduse,
paindlikult seadistada staatiliste failide salvestus,
teha puhastust katusesse,
edastada veebisokette,
aktiveerida kompressioon ja isegi HTML beautifier.

Ühesõnaga, kõik nagu suurte ja tuntud CDN-teenusepakkujate puhul.

Pärast seda, kui Origin (koht, kuhu CDN servad suunduvad) on määratud, tuleb luua CNAME, mis viitab tähe kujule, all.semrushchina.cn.w.kunluncan.com (see CNAME saadi Alibaba Cloudi konsoolist), ja CDN hakkab tööle.

Testide tulemuste põhjal aitas see CDN meid tõeliselt palju. Statistika on toodud allpool.

Lahendus
Suurus
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
13 s
16s
25 s

Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

Need on tõeliselt head tulemused, eriti kui võrrelda neid algsete numbritega. Kuid me teadsime, et meie USA veebisaidi www.semrush.com brauseritest WhatsAppis saadud test töötab keskmiselt 8.3 sekundiga (väga ligikaudne väärtus). On veel võimalusi, kuhu areneda. Lisaks on olnud ka teisi CDN-teenuse pakkujaid, keda oli huvitav testida.

Sellega liikume sujuvalt edasi ühe veelgi suurema tegijaga Hiina turul — Tencent.

Tencent Cloud

Tencent arendab oma pilve alles — see on selgelt näha väikese tooteportfelliga. Selle kasutamise käigus soovisime testida mitte ainult nende CDN-i, vaid ka üleüldiselt võrgu infrastruktuuri:

kas neil on midagi sarnast CENile?
kuidas toimib IPSEC? Kas see on kiire, milline on tööaeg?
kas neil on Anycast?

Vaatame need küsimused eraldi üle.

CEN-i analoog

Tencentil on toode Cloud Connect Network (CCN), võimaldades ühendada VPC-sid erinevates regioonides, sealhulgas Hiina sees ja väljaspool. Toode on praegu sise-beta faasis, ja sellele liitumiseks tuleb saata pilet. Toetuse kaudu saime teada, et globaalsetel kontodel (midagi mitte Hiina kodanike ja mitte juriidiliste isikute kohta) ei ole lubatud osaleda beta testimise programmis ja üldiselt ei ole võimalik Hiina siseregioni ühendada regionaalsetega väljaspoolt. 1-0 Ali Cloudi kasuks

IPSEC

Tencent'i kõige lõuna poolm region Guangzhou. Me lõime tunnel ja ühendasime selle Hongkongi piirkonnaga GCP-s (siis oli see piirkond juba saadaval). Samuti tõstsime korraga teise tunnelisse Ali Cloudis Shenzhenist Hongkongi. Selgus, et Tencent'i võrgu kaudu on latentsus Hongkongi suunas üldiselt parem (10ms), kui Shenzhenist Hongkongi suunas Ali kaudu (120ms — mis?). Kuid see ei kiirendanud kuidagi seda veebilehte, mis oli suunatud tööle läbi Tencent'i ja selle tunneli, mis oli endiselt üllatav fakt ja tõestas veel kord järgmist: latentsus — Hiinas ei ole see näitaja, millele tõeliselt tähelepanu pöörata lahenduse väljatöötamise käigus, et läbida Hiina tulemüüri.

Anycast Interneti kiirus

Veel üks toode, mis võimaldab töötada anycast IP kaudu — AIA. Kuid see ei ole saadaval ka globaalses kontos, seega ei saa ma sellest rääkida, kuid teadmine, et selline toode eksisteerib, võib olla kasulik.

Kuid CDN-i test näitas üsna huvitavaid tulemusi. Tencenti CDN-i ei saa aktiveerida full-site režiimis, vaid ainult konkreetsete domeenide jaoks. Me registreerisime domeenid ja suunatud neile liiklust:

Selgus, et sellel CDN-il on selline funktsioon: Ristpiiri liikluse optimeerimine. See funktsioon peaks vähendama kulusid liikluse läbimise ajal Hiina tulemüüri kaudu. Näiteks Päritolu oli märgitud Google'i GLB (GLB anycast) IP-aadress. Nii soovisime lihtsustada projekti arhitektuuri.

Tulemused olid väga head — samal tasemel Ali Cloud CDN-iga, ja kohati isegi paremad. See on üllatav, sest testide õnnestumise korral saaks loobuda suurest osast infrastruktuurist, tunnelitest, CEN-ist, virtuaalmasinatest jne.

Ei jäänud kaua rõõmustamiseks, kuna ilmnes probleem: testid Catchpointis kukkusid läbi internetiteenuse pakkujaga China Mobile. Igasugustelt asukohtadelt saime aegumise kaudu Tencenti CDN-i. Suhtlemine tehnilise toe poole ei viinud kuhugi. Umbes ööpäeva üritasime seda probleemi lahendada, kuid ei saavutanud midagi.

Olin sel hetkel Hiinas, kuid ei suutnud selle teenusepakkuja avalikku Wi-Fi-d leida, et probleemiga isiklikult tutvuda. Muus osas nägi kõik kiire ja hea välja.
Kuid kuna operaator China Mobile kuulus kolme suurema operaatori hulka, pidime liikluse suunama Ali CDN-i.
Aga tervikuna oli see üsna huvitav lahendus, mis väärib pikemat testimist ja probleemi tõrkeotsingut.

Akamai

Viimane CDN-teenusepakkuja, keda me testisime, on Akamai. See on suur teenusepakkuja, kellel on Hiinas oma võrk. Loomulikult ei saanud me temast mööda vaadata.

Algusest peale leppisime Akamai-ga kokku prooviperioodis, et saaksime domeeni vahetada ja vaadata, kuidas see nende võrgus töötab. Kogu testimise tulemusi kirjeldan ma kui "Mida me meeldis" ja "Mida ei meeldinud", samuti toon välja testide tulemused.

Mida meeldis:

Akamai tiim aitas meid kõigis küsimustes ja toetas meid kõigis katse etappides. Nad üritasid pidevalt oma poolel midagi paremaks muuta. Andsid häid tehnilisi nõuandeid.
Akamai töötab umbes 10-15% aeglasemalt kui meie lahendus Ali Cloud CDN kaudu. Muljetavaldav on see, et Akamai Originis määrasime GLB IP-aadressi, mis tähendab, et liiklus ei läinud läbi meie lahenduse (osa infrastruktuurist on potentsiaalselt võimalik eemaldada). Siiski näitasid testitulemused, et see lahendus on halvem kui meie praegune variant (võrdlevad tulemused allpool).
Testiti nii GLB als Originit kui ka Originit Hiinas. Mõlemad valikud on umbes samasugused.
On Sure Route (automaatne marsruudi optimeerimine). Saate oma testobjekti Originisse paigutada, ja Akamai Edge-serverid proovivad seda hankida (tavaline GET). Nende päringute jaoks mõõdetakse kiirus ja muud mõõdikud, mille põhjal Akamai võrgustik optimeerib marsruute, et liiklus kulgeks meie saidile kiiremini ja oleks nähtav, et selle funktsiooni sisse lülitamine avaldas tõeliselt suurt mõju saidi töö kiirusel.
Konfiguratsiooni versioonimine veebiliideses on suurepärane. Võimalik on teha versioonide võrdlust, vaadata diff'i. Vaadata eelmisi versioone.
Uus versioon tuleks eelnevalt väljastada Akamai Staging võrgus — see on identne tootmisvõrguga, kuid see ei mõjuta reaalseid kasutajaid. Selle testi jaoks tuleb DNS-kandeid kohalikul masinal spoofiaerida.
Nende suure staatilise sisu võrgu kaudu on laadimiskiirus äärmiselt kiire, samuti näib see kehtivat ka kõigi teiste failide kohta. Fail külmast vahemälust võetakse mitu korda kiiremini kui sama fail Ali CDN külmast vahemälust. Kuumast vahemälust on kiirus enam-vähem sama.

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

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

Oleme tähele pannud, et ülaltoodud näite olukord sõltub erinevatest teguritest. Selle punkti kirjutamise hetkeks testisin uuesti. Tulemused mõlema platvormi jaoks osutusid enam-vähem samaks. See näitab, et internet Hiinas käitub isegi suurte operaatorite ja pilveteenuste pakkujate puhul aeg-ajalt erinevalt.

Eelnevale punktile lisaks, Akamai suur pluss: kui Ali näitab sarnaseid kõrge jõudluse ja äärmiselt madala (see kehtib nii Ali CDN, Ali CEN, kui ka Ali IPSEC) tõusudena, siis Akamai puhul, olen kuidas iganes nende võrku testinud, kõik töötab stabiilselt.
Akamai tõepoolest omab suurt katvust Hiinas ja töötab paljude teenusepakkujatega.

Mis ei meeldinud:

Veebiliides ja töömudel ei meeldi — sellised nullid. Aga põhimõtteliselt harjub ehk ära.
Testitulemused on halvemad kui meie platvormil.
Testide vigu on rohkem kui meie platvormil (uptime on madalam).
Hiinas pole oma DNS-servereid. Seega on palju vigu testides, kuna DNS lahendustähtaeg on ületatud.
Ei pakuta oma IP vahemikke -> puudub võimalus õigesti määrata set_real_ip_from meie serverites.

Metrikud (~3626 jooksu; kõik näitajad, välja arvatud uptime, millisekundites; statistika ühe ajaperioodi kohta):

CDN teenusepakkuja
Mediaan
75%
95%
Vastus
Veebilehe vastus
Suurus
DNS
Connect
Oota
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

Jaotamine protsentilisse (ms):

Protsentil
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

Kokkuvõtteks: variant Akamaiga on elujõuline, kuid ei anna samu stabiilsuse ja kiirusnäitajaid nagu meie enda lahendus koos Ali CDN-iga.

Väikesed märkmed

Mõned punktid ei ole jutustusse mahtunud, aga sooviksin neist ka kirjutada.

Peking + Tokyo ja Hongkong

Nagu ma juba varem mainisin, testisime IPSEC tunnelit Hongkongi (HK) suunal. Kuid katsetasime ka CEN-i HK-ga. See on veidi odavam, ja oli huvitav näha, kuidas see töötab linnade vahel, mille vahemaa on ~100km. Huvitav oli märkida, et latentsus nende linnade vahel on 100ms kõrgem kui meie algses versioonis (Taiwani suunal). Kiirus ja stabiilsus olid Taiwani puhul samuti paremad. Lõpuks jätsime HK-i varu IPSEC piirkonnaks.

Lisaks proovisime käivitada sellist seadet:

klientide lõpetamine Pekingi regionaalses keskuses,
IPSEC ja CEN Tokyosse,
Ali CDN-i määramine Pekingi originaalserverina.

See skeem ei olnud nii stabiilne, kuigi kiirus ei olnud meie lahendusele järeleandmisi. Tunneliga seoses märkasin perioodilisi katkestusi isegi CEN-i puhul, mis pidi olema stabiilne. Seetõttu naasime vana skeemi juurde ja lõpetasime selle etapi.

Allpool on esitatud latentsuse statistika erinevate regioonide vahel erinevate kanalite kohta. Võib-olla on see kellelegi huvitav.

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

Ülevaade internetist Hiinas

Lisaks internetiprobleemidele, mis on esitatud artikli alguses.

Internet Hiinas töötab seespool üsna kiiresti.
- Järeldus põhineb avalike Wi-Fi võrkude testimisel erinevates kohtades, kus neid võrgud kasutab suur hulk inimesi.
- Allalaadimis- ja üleslaadimiskiirus serveritesse Hiinas oli umbes 20 Mbit/s ja 5-10 Mbit/s vastavalt.
- Kiirus serveritesse Hiina väliselt on lihtsalt kosmiliselt madal, alla 1 Mbit/s.
Internet Hiinas ei ole väga stabiilne.
- Mõnikord avanevad saidid kiiresti, mõnikord aeglaselt (samal kellaajal eri päevadel), tingimusel et konfiguratsioon ei muutu. Oleme seda jälginud näitel semrushchina.cn. Seda võib kirjutada Ali CDN-le, mis töötab samuti vahelduvalt sõltuvalt kellaajast, tähtede asendist jne.
Mobiilne internet on peaaegu kõikjal 4G või 4G+. Töötab metroos, liftides — lühidalt, igal pool.
See, et Hiina kasutajad usuvad ainult .cn domeenidesse — on müüt. Oleme seda teada saanud otse kasutajatelt.
- Saab näha, kuidas http://baidu.cn redirectib www.baidu.com peale (samuti mandri-Hiinas).
Paljusid ressursse on tõepoolest blokeeritud. Primitiivne: google.com, Facebook, Twitter. Kuid paljud Google'i ressursid töötavad (muidugi, mitte kõikides Wi-Fi võrguühendustes ning VPN ei tööta ka (lülitite poolel kindlasti mitte).
Paljud "tehnilised" blokeeritud korporatsioonide domeenid töötavad samuti. See tähendab, et ei ole alati mõistlik kõik Google'i ja teised näiliselt blokeeritud ressursid mahakanda. Tuleb otsida mingit keelatud domeenide nimekirja.
Nendel on kolm peamist interneti operaatorit: China Unicom, China Telecom, China Mobile. On ka väiksemaid, kuid nende turuosa on ebaoluline.

Boonus: lõppscheem lahendusest.

Kokkuvõte

Aasta on möödunud projekti algusest. Alustasime sellest, et meie veebisait keeldus täielikult korralikult töötamast Hiinast, ja lihtsalt GET curl võttis aega 5.5 sekundit.

Seejärel, selliste näitajate juures esimese lahenduse (Cloudflare) puhul:

Lahendus
Suurus
Mediaan
75. protsentiil
95. protsentiil

Cloudflare
86.6
18s
30s
60s

Lõpuks jõudsime selliste tulemusteni (statistika viimase kuu kohta):

Lahendus
Suurus
Mediaan
75. protsentiil
95. protsentiil

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

Nagu näha, ei ole 100% tööaega seni veel saavutatud, kuid me leiame midagi, ja seejärel räägime teile tulemustest uues artiklis :)

Luges, kes lugesid lõpuni kõik kolm osa — respekteerimine. Loodan, et see oli teile sama huvitav, kui mulle, kui ma seda tegin.