Kuidas me lõhkusime Suurt Hiina Tuli(Tule) (osa 3)

Tere!
Igas headruvad head lood lõppevad. Ja meie lugu sellest, kuidas me leiutasime Hiina tulemüüri kiire läbimise lahenduse, ei ole erand. Seetõttu kiirustan jagama teiega viimast, lõpetavat osa sellel teemal.

Eelmises osas rääkisime paljusid meie loodud teststandardeid ja milliseid tulemusi need andsid. Ja me peatume sellel, et oleks tore lisada CDN! meie skeemi elavdamiseks.

Räägin teile, kuidas me testisime Alibaba Cloud CDN-i, Tencent Cloud CDN-i ja Akamai-d ning millele lõpuks otsustasime. Ja loomulikult teeme kokkuvõtte.

Alibaba Cloud CDN

Me oleme hostitud Alibaba Cloudis, kasutame IPSEC-i ja CEN-i samalt. Seetõttu on mõistlik esmalt proovida nende lahendusi.

Alibaba Cloudil on kaks tüüpi toodet, mis võiksid meile sobida: CDN ja DCDN. Esimene variant on klassikaline CDN konkreetse domeeni (alamdomeeni) jaoks. Teine variant dešifreeritakse kui Dynamic Route for CDN (ma kutsun seda dünaamiliseks CDN-iks), seda saab aktiveerida Full-site režiimis (wildcard domeenide jaoks), see salvestab staatikat ja kiirendab dünaamilist sisu, see tähendab, et ka lehe dünaamika laaditakse tasemel kiirete võrgu pakkumise kaudu. See on meie jaoks oluline, kuna meie veebisait on peamiselt dünaamiline, seal on kasutusel palju alamdomeene ja on mugavam seadistada CDN kord ühe korra „tähe” jaoks — *.semrushchina.cn.

Oleme seda toodet varem meie Hiina projekti etappides näinud, kuid siis ei töötanud see veel ja arendajad lubasid, et toode on kohe kõikidele klientidele kergesti kergesti kätte saadav. Ja see on nüüd kergesti kergesti kätte saadav.

DCDN-is saab:

• seada SSL-terminatsiooni oma sertifikaadiga,
• aktiveerida dünaamilise sisu kiirenduse,
• paindlikult seadistada staatiliste failide vahemälu,
• teha vahemälu puhastamine,
• edastada veebipõhised sokid,
• aktiveerida kompressioon ja isegi HTML ilustaja.

Ühesõnaga, kõik nagu suurte ja tõsiste CDN-teenuse pakkujate juures.

Pärast seda, kui Origin (koht, kuhu CDN-i serva serverid lähevad) on määratud, jääb alles luua CNAME tähe jaoks, mis suunab all.semrushchina.cn.w.kunluncan.com (see CNAME saadi Alibaba Cloudi konsoolist), ja CDN hakkab töötama.

Testide tulemuste kohaselt aitas see CDN meid väga. Statistika on toodud allpool.

Lahendus
Aeg
Mediaan
75. percentiil
95. percentiil

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 to ensure the content fits the target audience. That's a great result, especially compared to the initial figures. However, we knew that the browser test of the American version of our website www.semrush.com averages about 8.3s from the US (a very close estimate). There's still room for improvement. Additionally, there were CDN providers we were interested in testing.

This smoothly leads us to another giant in the Chinese market — Tencent.

Tencent Cloud

Tencent is still developing its cloud — this is evident from the limited number of products. During our usage, we wanted to test not only their CDN but also their overall network infrastructure:

• do they have something similar to CEN?
• how does IPSEC work for them? Is it fast, what’s the uptime?
• do they have Anycast?

Let's break down these questions separately.

CEN Analog

Tencent has a product Cloud Connect Network (CCN), which allows connecting VPCs from different regions, both within China and externally. The product is currently in internal beta, and a ticket must be created to request access. From support, we learned that global accounts (not related to Chinese citizens or legal entities) cannot participate in the beta testing program and, in general, cannot connect a region inside China to a region outside. 1-0 in favor of Ali Cloud.

IPSEC

The southernmost region for Tencent is — Guangzhou. We set up a tunnel and connected it with the Hong Kong region in GCP (at that time this region had already become available). We also simultaneously raised a second tunnel in Ali Cloud from Shenzhen to Hong Kong. It turned out that the latency through Tencent’s network to Hong Kong is generally better (10ms) than from Shenzhen to Hong Kong in Ali (120ms — what?). However, this did not speed up the website's operation routed through Tencent and this tunnel, which in itself was an astonishing fact and once again proved the following: latency — for China, this is not a metric that really deserves attention during the development of a solution for passing through the Chinese firewall.

Anycast Internet Acceleration

Another product that allows functioning through anycast IP — AIA. However, it is also unavailable to global accounts, so I won't elaborate on it, but knowing that such a product exists may be useful.

However, the CDN test showed quite interesting results. Tencent’s CDN cannot be enabled for the full site, only for specific domains. We set up domains and directed traffic to them:

It turned out that this CDN has such a function: Piiriülese Liikluse Optimeerimine. See funktsioon peaks vähendama kulusid, kui liiklus läbib Hiina tulemüüri. Näiteks Origin oli märkida Google'i GLB (GLB anycast) IP-aadress. Seeläbi soovisime lihtsustada projekti arhitektuuri.

Tulemused olid väga head — Ali Cloud CDNi tasemel ja kohati isegi paremad. See on üllatav, kuna testide eduka tulemuse korral võiks osad infrastruktuuri, tunnelite, CEN-i, virtuaalmasinate jne osadest loobuda.

Meie rõõm ei kestnud kaua, kuna ilmnes probleem: testid Catchpoints kukkusid läbi interneti teenuse pakkuja China Mobile jaoks. Kõigest asukohast saime aega välja CDN Tencentiga. Kirjavahetus tehnilise toega ei viinud kuhugi. Umbes ööpäeva üritasime seda probleemi lahendada, kuid ei saanud midagi korda.

Olin sel hetkel Hiinas, kuid ei suutnud leida avalikku Wi-Fi-d selle teenusepakkuja võrgus, et veenduda probleemis isiklikult. Muud näisid kõik kiired ja head.
Kuid kuna China Mobile on üks kolmest suurimast operaatorist, olime sunnitud liikluse tagasi suunama Ali CDN-i.
Kuid kokkuvõttes oli see üsna huvitav lahendus, mis väärib pikemat testimist ja selle probleemi tõrkeotsingut.

Akamai

Viimane CDN-teenuse pakkuja, keda testisime, on Akamai. See on suur teenusepakkuja, kellel on oma võrk Hiinas. Loomulikult ei saanud me temast üle vaadata.

Alates algusest leppisime Akamaiga kokku testiperioodis, et saaksime domeeni vahetada ja näha, kuidas see nende võrgus töötab. Kõik testimise tulemused kirjeldan ma osas “Mida meeldis” ja “Mida ei meeldinud”, samuti annan testide tulemused.

Mida meeldis:

• Akamai töötajad aitasid meid väga kõigis küsimustes ja toetasid meid kõikidel testimise etappidel. Nad püüdsid pidevalt paremini teha oma poole pealt. 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 jaoks määrasime originaali IP-aadressi GLB, st liiklus ei läinud meie lahenduse läbi (potentsiaalselt oleks võimalik loobuda osast infrastruktuurist). Kuid siiski näitas testide tulemused, et see lahendus on halvem kui meie praegune variant (võrdlevad tulemused allpool).
• Testiti nii GLB originaali kui ka originaali Hiinas. Mõlemad variandid olid enam-vähem samad.
• Jah Sure Route (automaatne marsruutimise optimeerimine). Saate paigutada katseobjekti Originisse ning Akamai Edge serverid proovivad selle kätte saada (tavaline GET). Nende päringute jaoks mõõdetakse kiirus ja muud mõõdikud, mille põhjal Akamai võrgustik optimeerib marsruute, et liiklus meie saidile kulgeks kiiremini ja oleks selgelt näha, et selle funktsiooni kasutuselevõtt on tõeliselt mõjutanud saidi laadimise kiirust.
• Konfiguratsiooni versioonimine veebiliideses on suurepärane. Saate teha versioonide vahel võrreldes, vaadata erinevusi. Vaadata eelnevaid versioone.
• Saate uusi versioone alustada esmalt ainult Akamai Staging võrgus — see on samasugune võrk nagu tootmisvõrk, kuid see tee ei mõjuta reaalset kasutajat. Selle testi jaoks on vajalik DNS-kirjete petmine kohalikul masinal.
• Eriti kiire laadimiskiirus nende võrgu kaudu suure staatika ja tõenäoliselt ka teiste failide jaoks. Fail külmast vahemälust saadakse 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 märganud, et eelneva näite olukord sõltub erinevatest teguritest. Selle punkti kirjutamise hetkel tegin testi veel kord. Mõlema platvormi tulemused osutusid enam-vähem sarnaseks. See näitab meile, et Hiinas käitub internet isegi suurte operaatorite ja pilveteenuse pakkujate seas aeg-ajalt erinevalt.

Lisadesin eelmainitud punktile suure plussina Akamai kohta: kui Ali puhul on nähtavad sellised kõrge jõudluse ja väga madala latentsusega tükid (see kehtib nii Ali CDN, Ali CEN kui ka Ali IPSEC kohta), siis Akamai puhul, iga kord, kui ma nende võrku testin, töötab kõik stabiilselt.
Akamai'l on tõepoolest suur katvus Hiinas ja nad töötavad paljude teenusepakkujatega.

Mida me ei meeldi:

• Ma ei meeldi veebiliides ega töökorraldus — need on nullid. Kuid põhimõtteliselt harjub ära (ilmselt).
• Testide tulemused on halvemad kui meie omal platvormil.
• Vigu testide käigus on rohkem kui meie platvormil (ülevaatus on madalam).
• Hiinas ei ole oma DNS-servereid. Seetõttu on testides palju vigu, kuna DNS-i lahendamise aeg on ületas.
• Ei paku oma IP-aadresse -> ei ole võimalik kirja panna korrektseid set_real_ip_from meie serverites.

Metrika (~3626 testi; kõik metoodikad, välja arvatud ülevus, on ms; statistika ühes ajavahemikus):

CDN teenusepakkuja
Mediaan
75%
95%
Vastus
Veebilehe vastus
Aeg
DNS
Ühenda
Oota
Laadi
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 percentiili järgi (ms):

Percentiil
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: Akamai variant on elujõuline, kuid ei anna sama stabiilsuse ja kiiruse näitajaid, nagu meie enda lahendus koos Ali CDN-iga.

Väikesed märkmed

Mõned punktid ei mahtunud jutustusse, kuid soovisin neist ka kirjutada.

Pekingi + Tokyo ja Hongkong

Nagu ma juba eespool mainisin, testisime IPSEC tunnelit Hongkongi (HK) suunal. Kuid testisime ka CENi HK suunal. See on veidi odavam ja oli huvitav näha, kuidas see töötab linnade vahel, mille kaugus on ~100 km. Huvitav oli, et latentsus nende linnade vahel on 100 ms kõrgem kui meie algvariandi puhul (Taiwani suunal). Kiirus ja stabiilsus oli samuti parem Taiwani puhul. Lõpuks jätsime HK backup IPSEC piirkonnaks.

Lisaks proovisime üles seada sellise paigalduse:

• klientide lõpetamine Pekingis,
• IPSEC ja CEN Tokyo suunal,
• Ali CDN-is anti Pekingi server originaalserveriks.

See skeem polnud nii stabiilne, kuigi kiiruselt ei jäänud meie lahendusest maha. Mis puudutab tunnelit, siis nägin perioodilisi katkeid isegi CEN-i puhul, mis pidi olema stabiilne. Seetõttu naasime vana skeemi juurde ja lagundasime selle st stage.

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

IPsec
Ali cn-beijing GCP asia-northeast1 — 193 ms
Ali cn-shenzhen GCP asia-east2 — 91 ms
Ali cn-shenzhen GCP us-east4 — 200ms

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

Ülevaade internetist Hiinas

Lisaks artikli alguses kirjeldatud internetiprobleemidele.

• Internet Hiinas töötab siseriiklikult üsna kiiresti.
  • Järeldus on tehtud avalike Wi-Fi võrkude testimise põhjal erinevates asukohtades, kus neid võrgus kasutab palju inimesi.
  • Siseriiklike serverite allalaadimis- ja üleslaadimiskiirus oli umbes 20 Mbit/s ja 5-10 Mbit/s vastavalt.
  • Kiirus väliskanalites on lihtsalt minimaalne, vähem kui 1 Mbit/s.
• Internet Hiinas ei ole eriti stabiilne.
  • Mõnikord avanevad veebilehed kiiresti, mõnikord aeglaselt (sama aja jooksul eri päevadel), tingimusel et seadistused ei muutu. Oleme seda täheldanud näiteks semrushchina.cn näitel. Seda võib seostada Ali CDN-iga, mis töötab samuti perioodiliselt kiiruselt, sõltuvalt päevast, tähtede asendist jne.
• Mobiilne internet on praktiliselt igal pool 4G või 4G+. Signaal on olemas metroos, liftides — lühidalt, pea igal pool.
• Kuna Hiina kasutajad usuvad ainult .cn domeenidesse — on müüt. Oleme seda otse kasutajatelt välja uurinud.
  • Saab näha, kuidas http://baidu.cn redirectib www.baidu.com (tõepoolest ka mandri-Hiinas).
• Paljud ressursid on tõepoolest blokeeritud. Lihtsalt: google.com, Facebook, Twitter. Kuid paljud Google'i ressursid töötavad (muidugi mitte kõikides Wi-Fi võrkudes ning VPN ei ole sel juhul kasutamisel (ka ruuteri poolel, see on kindel).
• Paljud blokeeritud ettevõtete "tehnilised" domeenid töötavad samuti. See tähendab, et kõiki Google'i ja muid näiliselt blokeeritud ressursse ei pruugi valimatult eemaldada. Tuleb otsida mõni keelatud domeenide nimekiri.
• Neil on vaid kolm peamist internetiteenuse pakkujat: China Unicom, China Telecom, China Mobile. On ka mõned väiksemad, kuid nende osakaal turul on ebaoluline.

Boonus: lõplik lahenduste skeem

Kokkuvõte

Aasta on möödunud projekti käivitamisest. Alustasime sellest, et meie veebisait keeldus Hiinas normaalselt töötamast, GET curliga kestsid laadimised 5,5 sekundit.

Siis, neid näitajaid esimesel lahendusel (Cloudflare):

Lahendus
Aeg
Mediaan
75. percentiil
95. percentiil

Cloudflare
86.6
18s
30s
60s

Jõudsime selliste tulemusteni (eelmise kuu statistika):

Lahendus
Aeg
Mediaan
75. percentiil
95. percentiil

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

Kuidas näha, 100% tööaega pole veel saavutatud, kuid me midagi välja mõtleme ja siis räägime teile tulemustest uues artiklis :)

Kes, kes luges kõik kolm osa lõpuni — respekte. Loodan, et see oli teile sama huvitav kui mulle, kui ma seda tegin.

P.S. Eelnevad osad

Osa 1
Osa 2

Allikas: habr.com