🥇Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

Hi!
Visiem labajiem stāstiem pienāk beigas. Un mūsu stāsts par to, kā mēs radījām risinājumu, lai ātri pārvarētu Ķīnas ugunsmūri, nav izņēmums. Tāpēc es steidzos dalīties ar jums pēdējā, beigu daļa par šo tēmu.

Iepriekšējā daļā mēs runājām par daudziem testu stendiem, kurus mēs izdomājām un kādus rezultātus tie deva. Un mēs izlēmām, ko būtu jauki pievienot CDN! viskozitātei mūsu shēmā.

Es jums pastāstīšu, kā mēs pārbaudījām Alibaba Cloud CDN, Tencent Cloud CDN un Akamai, un ar ko mēs nonācām. Un, protams, apkoposim.

Alibaba Cloud CDN

Mēs esam mitināti pakalpojumā Alibaba Cloud un no tiem izmantojam IPSEC un CEN. Būtu loģiski vispirms izmēģināt viņu risinājumus.

Alibaba Cloud ir divu veidu produkti, kas mums var būt piemēroti: CDN и DCDN. Pirmā iespēja ir klasisks CDN noteiktam domēnam (apakšdomēnam). Otrā iespēja nozīmē Dinamiskais maršruts CDN (es to saucu par dinamisku CDN), to var iespējot pilnas vietnes režīmā (aizstājējzīmju domēniem), tas arī saglabā statisko saturu kešatmiņā un paātrina dinamisko saturu, tas ir, lapas dinamika tiks ielādēta arī caur pakalpojumu sniedzēja ātri tīkli. Tas mums ir svarīgi, jo pamatā mūsu vietne ir dinamiska, tajā tiek izmantoti daudzi apakšdomēni, un ērtāk ir vienreiz iestatīt CDN “zvaigznītei” - *.semrushchina.cn.

Mēs jau bijām redzējuši šo produktu mūsu Ķīnas projekta agrākajos posmos, taču tad tas vēl nedarbojās, un izstrādātāji solīja, ka produkts drīzumā kļūs pieejams visiem klientiem. Un viņš to darīja.

DCDN varat:

konfigurējiet SSL pārtraukšanu ar savu sertifikātu,
ļauj paātrināt dinamisku saturu,
elastīgi konfigurēt statisko failu kešatmiņu,
iztīrīt kešatmiņu,
pārsūtīt tīmekļa ligzdas,
iespējot saspiešanu un pat HTML Beautifier.

Kopumā viss ir tāpat kā ar pieaugušajiem un lieliem CDN pakalpojumu sniedzējiem.

Kad ir norādīts Origin (vieta, kur nonāks CDN malas serveri), atliek tikai izveidot zvaigznītei CNAME, atsaucoties all.semrushchina.cn.w.kunluncan.com (šis CNAME tika saņemts Alibaba Cloud konsolē), un CDN darbosies.

Pamatojoties uz testa rezultātiem, šis CDN mums ļoti palīdzēja. Statistika ir parādīta zemāk.

Šķīdums
Uptime
Median
75 procentile
95 procentile

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

Tie ir ļoti labi rezultāti, it īpaši, ja salīdzina tos ar tiem skaitļiem, kas bija sākumā. Taču mēs zinājām, ka mūsu vietnes www.semrush.com amerikāņu versijas pārlūkprogrammas tests no ASV tiek izpildīts vidēji 8.3 s (ļoti aptuvena vērtība). Ir ko uzlabot. Turklāt bija arī CDN pakalpojumu sniedzēji, kurus bija interesanti pārbaudīt.

Tāpēc mēs vienmērīgi pārietam uz citu gigantu Ķīnas tirgū - Tencent.

Tencent mākonis

Tencent tikai izstrādā savu mākoni – to var redzēt no neliela produktu skaita. Izmantojot to, mēs vēlējāmies pārbaudīt ne tikai viņu CDN, bet arī visu tīkla infrastruktūru:

vai viņiem ir kaut kas līdzīgs CEN?
Kā viņiem darbojas IPSEC? Vai tas ir ātri, kāds ir darbības laiks?
vai viņiem ir Anycast?

Apskatīsim šos jautājumus atsevišķi.

Analogais CEN

Tencent ir produkts Cloud Connect tīkls (CCN), ļaujot savienot VPC no dažādiem reģioniem, tostarp reģioniem Ķīnā un ārpus tās. Produktam tagad ir iekšējā beta versija, un jums ir jāizveido biļete, kurā tiek lūgts izveidot savienojumu ar to. No atbalsta mēs uzzinājām, ka globālie konti (mēs nerunājam par Ķīnas pilsoņiem vai juridiskām personām) nevar piedalīties beta testēšanas programmā un kopumā savienot Ķīnas reģionu ar reģionu ārpusē. 1:0 Ali Cloud labā

IPSEC

Tencentas dienvidu reģions ir Guandžou. Mēs samontējām tuneli un savienojām to ar Honkongas reģionu GCP (tad šis reģions jau bija pieejams). Tajā pašā laikā tika pacelts arī otrs tunelis Ali Cloud no Šeņdžeņas uz Honkongu. Izrādījās, ka caur Tencent tīklu latentums uz Honkongu parasti ir labāks (10 ms) nekā no Šenženas uz Honkongu līdz Ali (120 ms - kas?). Bet tas nekādā veidā nepaātrināja vietnes darbu, kuras mērķis bija strādāt caur Tencent un šo tuneli, kas pats par sevi bija pārsteidzošs fakts un vēlreiz pierādīja sekojošo: latentums - Ķīnai tas nav rādītājs, kas patiešām ir vērts. pievēršot uzmanību, izstrādājot risinājumu Ķīnas ugunsmūra šķērsošanai.

Anycast interneta paātrinājums

Vēl viens produkts, kas ļauj strādāt, izmantojot Anycast IP, ir AAI. Bet tas nav pieejams arī globālajiem kontiem, tāpēc es jums par to nestāstīšu, taču var būt noderīgi zināt, ka šāds produkts pastāv.

Bet CDN tests parādīja diezgan interesantus rezultātus. Tencent CDN nevar iespējot visā vietnē, tikai noteiktos domēnos. Mēs izveidojām domēnus un nosūtījām uz tiem trafiku:

Izrādījās, ka šim CDN ir šāda funkcija: Pārrobežu satiksmes optimizācija. Šai funkcijai ir jāsamazina izmaksas, kad satiksme šķērso Ķīnas ugunsmūri. Kā izcelšanās Tika norādīta Google GLB (GLB anycast) IP adrese. Tādējādi mēs vēlējāmies vienkāršot projekta arhitektūru.

Rezultāti bija ļoti labi – Ali Cloud CDN līmenī un vietām pat labāki. Tas ir pārsteidzoši, jo, ja testi būs veiksmīgi, var pamest ievērojamu daļu infrastruktūras, tuneļus, CEN, virtuālās mašīnas utt.

Mēs ilgi nepriecājāmies, jo atklājās problēma: interneta pakalpojumu sniedzēja China Mobile testi Catchpoint neizdevās. No jebkuras vietas mēs saņēmām taimautu, izmantojot Tencent's CDN. Sarakste ar tehnisko atbalstu ne pie kā nenoveda. Mēs mēģinājām atrisināt šo problēmu apmēram dienu, bet nekas nedarbojās.

Es tajā brīdī atrados Ķīnā, taču nevarēju atrast publisko Wi-Fi šī pakalpojumu sniedzēja tīklā, lai personīgi pārbaudītu problēmu. Citādi viss izskatījās ātri un labi.
Tomēr, tā kā China Mobile ir viens no trim lielākajiem operatoriem, mēs bijām spiesti atgriezt trafiku uz Ali CDN.
Bet kopumā tas bija diezgan interesants risinājums, kas ir pelnījis ilgāku šīs problēmas pārbaudi un problēmu novēršanu.

Akamai

Pēdējais mūsu pārbaudītais CDN nodrošinātājs bija Akamai. Šis ir milzīgs pakalpojumu sniedzējs, kura tīkls atrodas Ķīnā. Protams, mēs nevarējām tikt tam garām.

Jau pašā sākumā vienojāmies ar Akamai par izmēģinājuma periodu, lai varētu pārslēgt domēnu un redzēt, kā tas darbosies viņu tīklā. Visu testu rezultātus es aprakstīšu formā “Kas man patika” un “Kas man nepatika”, kā arī norādīšu testa rezultātus.

Kas man patika:

Puiši no Akamai bija ļoti izpalīdzīgi visos jautājumos un pavadīja mūs visos testēšanas posmos. Mēs nemitīgi centāmies kaut ko uzlabot savā pusē. Viņi sniedza labus tehniskos padomus.
Akamai ir aptuveni par 10–15% lēnāks nekā mūsu risinājums, izmantojot Ali Cloud CDN. Iespaidīgi ir tas, ka programmā Origin for Akamai mēs norādījām GLB IP adresi, kas nozīmē, ka trafiks nenotika caur mūsu risinājumu (iespējams, mēs varētu pamest daļu infrastruktūras). Bet tomēr testa rezultāti parādīja, ka šis risinājums ir sliktāks par mūsu pašreizējo versiju (salīdzinošie rezultāti zemāk).
Pārbaudīts gan Origin GLB, gan Origin Ķīnā. Abas iespējas ir aptuveni vienādas.
Ir Drošs maršruts (automātiskā maršrutēšanas optimizācija). Varat mitināt testa objektu vietnē Origin, un Akamai Edge serveri mēģinās to uztvert (parastais GET). Šiem pieprasījumiem tiek mērīts ātrums un citi rādītāji, pamatojoties uz kuriem Akamai tīkls optimizē maršrutus, lai mūsu vietnes satiksme būtu ātrāka, un bija skaidrs, ka šīs funkcijas iespējošana patiešām spēcīgi ietekmēja vietnes ātrumu.
Konfigurācijas versijas izveide tīmekļa saskarnē ir lieliska. Varat veikt Salīdzināt versijas, apskatīt atšķir. Skatīt iepriekšējās versijas.
Jaunu versiju vispirms varat izlaist tikai Akamai Staging tīklā — tajā pašā tīklā, kas tiek ražots, tikai tas neietekmēs reālos lietotājus. Lai veiktu šo testu, jums ir jāmānīja DNS ieraksti vietējā datorā.
Ļoti ātrs lejupielādes ātrums, izmantojot tīklu, lieliem statiskiem failiem un, acīmredzot, visiem citiem failiem. Fails no “aukstās” kešatmiņas tiek izgūts daudzas reizes ātrāk nekā tas pats fails no Ali CDN “aukstās” kešatmiņas. No “karstās” kešatmiņas ātrums jau ir tāds pats, plus vai mīnus.

Ali CDN tests:

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 tests:

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

Mēs pamanījām, ka situācija iepriekš minētajā piemērā ir atkarīga no dažādiem faktoriem. Rakstot šo punktu, es vēlreiz izpildīju testu. Rezultāti abām platformām bija aptuveni vienādi. Tas liecina, ka internets Ķīnā, pat lielajiem operatoriem un mākoņpakalpojumu sniedzējiem, laiku pa laikam darbojas atšķirīgi.

Iepriekšējam punktam pievienošu lielu plusu Akamai: ja Ali rāda līdzīgus augstas veiktspējas un ļoti zemas veiktspējas mirkļus (tas attiecas uz Ali CDN, Ali CEN un Ali IPSEC), tad Akamai katru reizi, neatkarīgi no kā es pārbaudu viņu tīklu, viss darbojas stabili.
Akamai ir plašs pārklājums Ķīnā, un tas darbojas caur daudziem pakalpojumu sniedzējiem.

Kas man nepatika:

Man nepatīk tīmekļa saskarne un veids, kā tas darbojas — tas ir tik slikts. Bet būtībā pie tā pierod (iespējams).
Testa rezultāti ir sliktāki nekā mūsu vietnē.
Pārbaužu laikā ir vairāk kļūdu nekā mūsu vietnē (darbspējas laiks zemāk).
Mums Ķīnā nav savu DNS serveru. Tāpēc pārbaudēs ir daudz kļūdu DNS atrisināšanas noildzes dēļ.
Viņi nenorāda savus IP diapazonus -> nav iespējams reģistrēt pareizos set_real_ip_from mūsu serveros.

Metrika (aptuveni 3626 palaišanas reizes; visa metrika, izņemot darbspējas laiku, ms; statistika par vienu laika periodu):

CDN nodrošinātājs
Median
75%
95%
Atbilde
Tīmekļa lapas atbilde
Uptime
DNS
Meklēt speciālistu
Pagaidiet
Slodze
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

Sadalījums pēc procentiles (ms):

Procentils
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

Secinājums ir šāds: Akamai iespēja ir dzīvotspējīga, taču nenodrošina tādu pašu stabilitāti un ātrumu kā mūsu pašu risinājums kopā ar Ali CDN.

Mazas piezīmes

Daži momenti nebija iekļauti stāstā, bet es arī par tiem gribētu uzrakstīt.

Pekina + Tokija un Honkonga

Kā jau teicu iepriekš, mēs pārbaudījām IPSEC tuneli uz Honkongu (HK). Bet mēs arī pārbaudījām CEN uz HK. Tas maksā nedaudz mazāk, un es domāju, kā tas darbosies starp pilsētām ar attālumu ~ 100 km. Interesanti izrādījās, ka latentums starp šīm pilsētām ir par 100 ms lielāks nekā mūsu sākotnējā versijā (uz Taivānu). Ātrums, stabilitāte arī Taivānai bija labāka. Rezultātā mēs atstājām HK kā rezerves IPSEC reģionu.

Turklāt mēs mēģinājām instalēt šādu instalāciju:

klientu izbeigšana Pekinā,
IPSEC un CEN uz Tokiju,
Ali CDN kā izcelsme tika norādīts serveris Pekinā.

Šī shēma nebija tik stabila, lai gan ātruma ziņā tā kopumā nebija zemāka par mūsu risinājumu. Attiecībā uz tuneli esmu redzējis periodiskus kritumus pat CEN, kam vajadzēja būt stabilam. Tāpēc atgriezāmies pie vecās shēmas un šo iestudējumu demontējām.

Tālāk ir sniegta statistika par latentumu starp dažādiem reģioniem dažādiem kanāliem. Varbūt kādam tas interesēs.

IPsec
Ali cn-peijing <—> GCP asia-northeast1 — 193ms
Ali cn-Shenzhen <—> GCP asia-east2 — 91 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

CEN
Ali cn-peijing <—> Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6 ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms

Vispārīga informācija par internetu Ķīnā

Kā papildinājums pašā sākumā aprakstītajām problēmām ar internetu raksta pirmajā daļā.

Internets Ķīnā ir diezgan ātrs iekšā.
- Secinājums izdarīts, pamatojoties uz publisko Wi-Fi tīklu testēšanu dažādās vietās, kur šos tīklus izmanto liels skaits cilvēku.
- Lejupielādes un augšupielādes ātrums serveros Ķīnā bija attiecīgi aptuveni 20 Mbit/s un 5-10 Mbit/s.
- Ātrums uz serveriem ārpus Ķīnas ir vienkārši niecīgs, mazāks par 1 Mbit/s.
Internets Ķīnā nav ļoti stabils.
- Dažreiz vietnes var atvērt ātri, dažreiz lēni (vienā un tajā pašā laikā dažādās dienās), ja konfigurācija nemainās. Mēs to novērojām, izmantojot semrushchina.cn piemēru. To var attiecināt uz Ali CDN, kas arī darbojas šādi un citādi atkarībā no diennakts laika, zvaigžņu stāvokļa utt.
Mobilais internets ir gandrīz visur 4G vai 4G+. Noķer to metro, liftos – īsi sakot, visur.
Tas ir mīts, ka ķīniešu lietotāji uzticas tikai domēniem .cn zonā. Mēs to uzzinājām tieši no lietotājiem.
- Jūs varat redzēt, kā http://baidu.cn novirzīt uz www.baidu.com (arī kontinentālajā Ķīnā).
Daudzi resursi patiešām ir bloķēti. Primitīvs: google.com, Facebook, Twitter. Bet daudzi Google resursi darbojas (protams, ne visos Wi-Fi un VPN netiek izmantots (arī maršrutētāja pusē, tas noteikti).
Darbojas arī daudzi bloķēto korporāciju “tehniskie” domēni. Tas nozīmē, ka nevajadzētu vienmēr neapdomīgi izgriezt visus Google un citus šķietami bloķētos resursus. Jums ir jāmeklē kāds aizliegto domēnu saraksts.
Viņiem ir tikai trīs galvenie interneta operatori: China Unicom, China Telecom, China Mobile. Ir vēl mazāki, taču to tirgus daļa ir niecīga

Bonuss: gala risinājuma diagramma

Kopsavilkums

Ir pagājis gads kopš projekta sākuma. Mēs sākām ar faktu, ka mūsu vietne parasti atteicās normāli strādāt no Ķīnas, un vienkārši GET curl aizņēma 5.5 sekundes.

Pēc tam ar šiem indikatoriem pirmajā risinājumā (Cloudflare):

Šķīdums
Uptime
Median
75 procentile
95 procentile

Cloudflare
86.6
18s
30s
60s

Galu galā mēs sasniedzām šādus rezultātus (statistika par pēdējo mēnesi):

Šķīdums
Uptime
Median
75 procentile
95 procentile

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

Kā redzat, 100% darbības laiku vēl neesam spējuši sasniegt, bet kaut ko izdomāsim, un tad par rezultātiem pastāstīsim jaunā rakstā :)

Respekts tiem, kas izlasīja visas trīs daļas līdz galam. Es ceru, ka jums tas viss likās tikpat interesanti kā man, kad es to darīju.