Hi!
Kaikki hyvät tarinat päättyvät. Ja tarinamme siitä, kuinka keksimme ratkaisun kiinalaisen palomuurin ohittamiseksi nopeasti, ei ole poikkeus. Siksi kiirehdin jakamaan kanssasi viimeisen, viimeinen osa tästä aiheesta.
Edellisessä osassa puhuimme monista keksimistämme testipenkeistä ja siitä, mitä tuloksia ne antoivat. Ja päätimme, mitä olisi mukavaa lisätä CDN! viskositeetin vuoksi järjestelmäämme.
Kerron sinulle, kuinka testasimme Alibaba Cloud CDN:ää, Tencent Cloud CDN:ää ja Akamaita ja mihin päädyimme. Ja tietysti tehdään yhteenveto.
Alibaba Cloud CDN
Meitä isännöi Alibaba Cloud ja käytämme niiden IPSEC- ja CEN-standardeja. Olisi loogista kokeilla heidän ratkaisujaan ensin.
Alibaba Cloudilla on kahdenlaisia tuotteita, jotka voivat sopia meille: CDN и DCDN. Ensimmäinen vaihtoehto on klassinen CDN tietylle verkkotunnukselle (aliverkkotunnukselle). Toinen vaihtoehto tarkoittaa Dynaaminen reitti CDN:lle (Kutsun sitä dynaamiseksi CDN:ksi), se voidaan ottaa käyttöön Full-site-tilassa (jokerimerkkiverkkotunnuksille), se tallentaa myös staattisen sisällön välimuistiin ja kiihdyttää dynaamista sisältöä itsestään, eli sivun dynamiikka latautuu myös palveluntarjoajan kautta. nopeat verkot. Tämä on meille tärkeää, koska sivustomme on pohjimmiltaan dynaaminen, se käyttää monia aliverkkotunnuksia ja on kätevämpää määrittää CDN kerran "tähdelle" - *.semrushchina.cn.
Olimme nähneet tämän tuotteen jo kiinalaisen projektimme aikaisemmissa vaiheissa, mutta silloin se ei vielä toiminut, ja kehittäjät lupasivat, että tuote tulee pian kaikkien asiakkaiden saataville. Ja hän teki.
DCDN:ssä voit:
- määritä SSL-päättäminen varmenteellasi,
- mahdollistaa dynaamisen sisällön nopeuttaminen,
- määrittää joustavasti staattisten tiedostojen välimuistin,
- tyhjennä välimuisti,
- eteenpäin verkkoliitännät,
- mahdollistaa pakkaus ja jopa HTML Beautifier.
Yleensä kaikki on sama kuin aikuisilla ja suurilla CDN-palveluntarjoajilla.
Kun Origin (paikka, johon CDN reunapalvelimet menevät) on määritetty, ei ole muuta kuin luotava tähdelle CNAME viittaamalla all.semrushchina.cn.w.kunluncan.com (tämä CNAME vastaanotettiin Alibaba Cloud -konsoliin) ja CDN toimii.
Testitulosten perusteella tämä CDN auttoi meitä paljon. Tilastot näkyvät alla.
päätös
Päällä
Mediaani
75 prosenttipiste
95 prosenttipiste
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
Nämä ovat erittäin hyviä tuloksia, varsinkin jos vertaa niitä siihen, mitä numeroita alussa oli. Tiesimme kuitenkin, että verkkosivustomme www.semrush.com amerikkalaisen version selaintesti suoritetaan Yhdysvalloista keskimäärin 8.3 sekunnissa (erittäin likimääräinen arvo). Parantamisen varaa on. Lisäksi oli myös CDN-palveluntarjoajia, joita oli mielenkiintoista testata.
Joten siirrymme sujuvasti toiseen jättiläiseen Kiinan markkinoille - Tencent.
Tencent-pilvi
Tencent on vasta kehittämässä pilviään - tämä näkyy pienestä määrästä tuotteita. Sitä käytettäessä halusimme testata paitsi heidän CDN:ään, myös heidän verkkoinfrastruktuuriaan kokonaisuudessaan:
- onko niissä jotain samanlaista kuin CEN?
- Miten IPSEC toimii heille? Onko se nopea, mikä on käyttöaika?
- onko heillä Anycast?
Katsotaanpa näitä kysymyksiä erikseen.
Analoginen CEN
Tencentillä on tuote Cloud Connect -verkko (), jonka avulla voit yhdistää VPC:itä eri alueilta, mukaan lukien alueet Kiinassa ja sen ulkopuolella. Tuote on nyt sisäisessä betavaiheessa, ja sinun on luotava lippu, jossa pyydetään yhdistämään siihen. Opimme tuesta, että globaalit tilit (emme puhu Kiinan kansalaisista tai juridisista henkilöistä) eivät voi osallistua betatestausohjelmaan ja yleensä yhdistävät Kiinan sisällä olevan alueen ulkopuoliseen alueeseen. 1-0 Ali Cloudin hyväksi
IPSEC
Tencentin eteläisin alue on Guangzhou. Kokosimme tunnelin ja liitimme sen Hongkongin alueelle GCP:ssä (silloin tämä alue oli jo tullut saataville). Samaan aikaan nostettiin myös toinen tunneli Ali Cloudissa Shenzhenistä Hongkongiin. Kävi ilmi, että Tencent-verkon kautta viive Hongkongiin on yleensä parempi (10ms) kuin Shenzhenistä Hongkongiin Aliin (120ms - mitä?). Mutta tämä ei millään tavalla nopeuttanut Tencentin ja tämän tunnelin läpikäymiseen tähtäävän sivuston työtä, mikä sinänsä oli hämmästyttävä tosiasia ja osoitti jälleen seuraavan: latenssi - Kiinalle tämä ei ole todella arvoinen indikaattori kiinnittää huomiota kehitettäessä ratkaisua Kiinan palomuurin läpäisemiseen.
Anycast Internet Acceleration
Toinen tuote, jonka avulla voit työskennellä Anycast IP:n kautta, on . Mutta se ei ole myöskään saatavilla globaaleille tileille, joten en kerro siitä, mutta tällaisen tuotteen olemassaolosta voi olla hyötyä.
Mutta CDN-testi osoitti melko mielenkiintoisia tuloksia. Tencentin CDN:ää ei voi ottaa käyttöön koko sivustolla, vain tietyillä verkkotunnuksilla. Loimme verkkotunnuksia ja lähetimme niihin liikennettä:
Kävi ilmi, että tällä CDN:llä on seuraava toiminto: Rajat ylittävän liikenteen optimointi. Tämän ominaisuuden pitäisi vähentää kustannuksia, kun liikenne kulkee Kiinan palomuurin läpi. Kuten Alkuperä Google GLB:n (GLB anycast) IP-osoite määritettiin. Siksi halusimme yksinkertaistaa projektin arkkitehtuuria.
Tulokset olivat erittäin hyviä - Ali Cloud CDN:n tasolla ja paikoin jopa parempia. Tämä on yllättävää, koska jos testit onnistuvat, voit hylätä merkittävän osan infrastruktuurista, tunneleista, CEN: stä, virtuaalikoneista jne.
Emme iloineet kauan, kun ongelma paljastui: Catchpointin testit epäonnistuivat Internet-palveluntarjoajan China Mobilen osalta. Saimme aikakatkaisun mistä tahansa paikasta Tencentin CDN:n kautta. Kirjeenvaihto teknisen tuen kanssa ei johtanut mihinkään. Yritimme ratkaista tätä ongelmaa noin päivän ajan, mutta mikään ei auttanut.
Olin Kiinassa sillä hetkellä, mutta en löytänyt julkista Wi-Fi-yhteyttä tämän palveluntarjoajan verkosta varmistaakseni ongelman henkilökohtaisesti. Muuten kaikki näytti nopealta ja hyvältä.
Koska China Mobile on yksi kolmesta suurimmasta operaattorista, jouduimme kuitenkin palauttamaan liikennettä Ali CDN:lle.
Mutta kaiken kaikkiaan tämä oli melko mielenkiintoinen ratkaisu, joka ansaitsee pidemmän testauksen ja tämän ongelman vianetsinnän.
Akamai
Viimeisin testaamamme CDN-palveluntarjoaja oli Akamai. Tämä on valtava palveluntarjoaja, jonka verkko on Kiinassa. Emme tietenkään voineet ohittaa sitä.
Sovimme Akamain kanssa heti alusta lähtien kokeilujaksosta, jotta voimme vaihtaa verkkotunnusta ja katsoa kuinka se toimii heidän verkossaan. Kuvailen kaikkien testien tuloksia muodossa "Mistä pidin" ja "Mistä en pitänyt", ja annan myös testitulokset.
Mistä pidimme:
- Akamain kaverit olivat erittäin avuliaita kaikissa kysymyksissä ja seurasivat meitä kaikissa testin vaiheissa. Yritimme jatkuvasti parantaa jotain puolellamme. He antoivat hyviä teknisiä neuvoja.
- Akamai on noin 10-15 % hitaampi kuin ratkaisumme Ali Cloud CDN:n kautta. Vaikuttavaa on, että Origin for Akamai -sovelluksessa määritimme GLB:n IP-osoitteen, mikä tarkoittaa, että liikenne ei mennyt ratkaisumme läpi (voimme mahdollisesti hylätä osan infrastruktuurista). Mutta silti testitulokset osoittivat, että tämä ratkaisu on huonompi kuin nykyinen versiomme (vertailutulokset alla).
- Testattu sekä Origin GLB että Origin Kiinassa. Molemmat vaihtoehdot ovat suunnilleen samat.
- On Varma reitti (automaattinen reitityksen optimointi). Voit isännöidä testiobjektia Originissa, ja Akamai Edge -palvelimet yrittävät poimia sen (tavallinen GET). Näitä pyyntöjä varten mitataan nopeutta ja muita mittareita, joiden perusteella Akamai-verkko optimoi reitit niin, että liikenne sujuu sivustollamme nopeammin ja oli selvää, että tämän ominaisuuden käyttöönotolla oli todella vahva vaikutus sivuston nopeuteen.
- Asetusten versiointi verkkokäyttöliittymässä on siistiä. Voit tehdä Vertaa versioita, katso diff. Katso aiemmat versiot.
- Voit ottaa uuden version käyttöön ensin vain Akamai Staging -verkossa - samassa verkossa kuin tuotanto, vain tämä tapa ei vaikuta todellisiin käyttäjiin. Tätä testiä varten sinun on huijattava paikallisen koneen DNS-tietueet.
- Erittäin nopea latausnopeus verkon kautta suurille staattisille tiedostoille ja ilmeisesti kaikille muille tiedostoille. "Kylmän" välimuistin tiedosto haetaan monta kertaa nopeammin kuin sama tiedosto Ali CDN:n "kylmasta" välimuistista. "Kuumasta" välimuistista nopeus on jo sama, plus tai miinus.
Ali CDN -testi:
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 testi:
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/sHuomasimme, että yllä olevan esimerkin tilanne riippuu useista tekijöistä. Tätä kohtaa kirjoittaessani tein testin uudelleen. Tulokset molemmilla alustoilla olivat suunnilleen samat. Tämä kertoo meille, että Kiinan Internet, jopa suurten operaattoreiden ja pilvipalvelujen tarjoajien, käyttäytyy toisinaan eri tavalla.
Edelliseen kohtaan lisään suuren plussan Akamai: jos Ali näyttää samanlaisia välähdyksiä korkeasta suorituskyvystä ja erittäin alhaisesta suorituskyvystä (tämä koskee Ali CDN:ää, Ali CENiä ja Ali IPSEC:iä), niin Akamai joka kerta, riippumatta kuinka testaan heidän verkkoaan, kaikki toimii vakaasti.
Akamailla on paljon kattavuutta Kiinassa ja se toimii monien palveluntarjoajien kautta.
Mistä ei pitänyt:
- En pidä verkkoliittymästä ja sen toiminnasta - se on niin huono. Mutta periaatteessa siihen tottuu (luultavasti).
- Testitulokset ovat huonommat kuin sivustollamme.
- Testien aikana on enemmän virheitä kuin sivustollamme (käyttöaika alla).
- Meillä ei ole omia DNS-palvelimia Kiinassa. Tästä syystä testeissä on monia virheitä DNS-selvityksen aikakatkaisun vuoksi.
- He eivät anna IP-alueitaan -> oikeita ei ole mahdollista rekisteröidä set_real_ip_from palvelimillamme.
Mittarit (~3626 XNUMX ajoa; kaikki mittarit paitsi Käyttöaika, ms; tilastot yhdeltä ajanjaksolta):
CDN-palveluntarjoaja
Mediaani
75%
95%
Vastaus
Verkkosivun vastaus
Päällä
DNS
kytkeä
Odota
Ladata
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
Jakauma prosenttipisteissä (ms):
Prosentuaalinen
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
Johtopäätös on tämä: Akamai-vaihtoehto on käyttökelpoinen, mutta se ei tarjoa samaa vakautta ja nopeutta kuin oma ratkaisumme yhdistettynä Ali CDN:ään.
Pienet muistiinpanot
Jotkut hetket eivät sisältyneet tarinaan, mutta niistäkin haluaisin kirjoittaa.
Peking + Tokio ja Hongkong
Kuten edellä sanoin, testasimme IPSEC-tunnelia Hongkongiin (HK). Mutta testasimme myös CEN: n HK: lle. Se maksaa vähän vähemmän, ja mietin, miten se toimisi kaupunkien välillä, joiden etäisyys on ~100 km. Mielenkiintoiseksi osoittautui, että näiden kaupunkien välinen latenssi on 100 ms korkeampi kuin alkuperäisessä versiossamme (Taiwaniin). Nopeus, vakaus oli myös parempi Taiwanille. Tämän seurauksena jätimme HK:n IPSEC-varaalueeksi.
Lisäksi yritimme asentaa seuraavan asennuksen:
- asiakkaiden lopettaminen Pekingissä,
- IPSEC ja CEN Tokioon,
- Ali CDN:ssä Pekingin palvelin ilmoitettiin alkuperäksi.
Tämä kaava ei ollut niin vakaa, vaikka se ei nopeudeltaan ollutkaan ratkaisumme huonompi. Tunnelin osalta olen nähnyt ajoittaisia pudotuksia jopa CEN:lle, jonka olisi pitänyt olla vakaa. Siksi palasimme vanhaan suunnitelmaan ja purimme tämän lavastusen.
Alla on tilastot latenssista eri alueiden välillä eri kanaville. Ehkä joku on kiinnostunut siitä.
IPSec
Ali cn-beijing <—> GCP aasia-koillis1 — 193 ms
Ali cn-shenzhen <—> GCP aasia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms
CEN
Ali cn-beijing <—> Ali ap-koillis-1 - 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong - 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms
Yleistä tietoa Internetistä Kiinassa
Lisäyksenä Internetin ongelmiin, jotka kuvattiin heti alussa, artikkelin ensimmäisessä osassa.
- Internet Kiinassa on melko nopea sisällä.
- Johtopäätös tehtiin testaamalla julkisia Wi-Fi-verkkoja eri paikoissa, joissa näitä verkkoja käyttää suuri joukko ihmisiä.
- Lataus- ja lähetysnopeudet palvelimille Kiinan sisällä olivat noin 20 Mbit/s ja 5-10 Mbit/s.
- Nopeus Kiinan ulkopuolisille palvelimille on yksinkertaisesti niukka, alle 1 Mbit/s.
- Internet Kiinassa ei ole kovin vakaa.
- Joskus sivustot voivat avautua nopeasti, joskus hitaasti (samaan aikaan päivästä eri päivinä), jos kokoonpano ei muutu. Huomasimme tämän esimerkillä semrushchina.cn. Tämä voi johtua Ali CDN:stä, joka myös toimii näin ja näin riippuen vuorokaudenajasta, tähtien sijainnista jne.
- Mobiili Internet on lähes kaikkialla 4G tai 4G+. Ota kiinni metrosta, hisseistä - lyhyesti sanottuna kaikkialla.
- On myytti, että kiinalaiset käyttäjät luottavat vain .cn-vyöhykkeen verkkotunnuksiin. Opimme tämän suoraan käyttäjiltä.
- Voit nähdä kuinka uudelleenohjaa osoitteeseen www.baidu.com (myös Manner-Kiinassa).
- Monet resurssit ovat todellakin tukossa. Alkukantainen: google.com, Facebook, Twitter. Mutta monet Googlen resurssit toimivat (ei tietenkään kaikissa Wi-Fi-verkoissa ja VPN:ää ei käytetä (se on varmaa myös reitittimen puolella).
- Myös monet estettyjen yritysten "tekniset" toimialueet toimivat. Tämä tarkoittaa, että sinun ei aina pidä piittaamattomasti karsia pois kaikkia Googlen ja muiden näennäisesti estettyjen resurssien käytöstä. Sinun on etsittävä luettelo kiellettyistä verkkotunnuksista.
- Heillä on vain kolme pääasiallista Internet-operaattoria: China Unicom, China Telecom ja China Mobile. Pienempiäkin on, mutta niiden markkinaosuus on mitätön
Bonus: lopullinen ratkaisukaavio
Koko
Projektin alkamisesta on kulunut vuosi. Aloitimme siitä, että sivustomme kieltäytyi yleensä toimimasta normaalisti Kiinasta, ja yksinkertaisesti GET curl kesti 5.5 sekuntia.
Sitten näillä indikaattoreilla ensimmäisessä ratkaisussa (Cloudflare):
päätös
Päällä
Mediaani
75 prosenttipiste
95 prosenttipiste
CloudFlare
86.6
18s
30s
60s
Pääsimme lopulta seuraaviin tuloksiin (viime kuukauden tilastot):
päätös
Päällä
Mediaani
75 prosenttipiste
95 prosenttipiste
Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s
Kuten näette, emme ole vielä pystyneet saavuttamaan 100% käytettävyyttä, mutta keksimme jotain, ja sitten kerromme tuloksista uudessa artikkelissa :)
Kunnioitus niille, jotka lukevat kaikki kolme osaa loppuun. Toivon, että pidit tämän kaiken yhtä mielenkiintoisena kuin minä tein sen tehdessäni.
PS Edelliset osat
Lähde: will.com