Hei kaikille!
Nikita on yhteydessä - järjestelmäinsinööri yrityksestä SEMrush. Tänään kerron sinulle, kuinka kohtasimme tehtävän varmistaa semrush.com-palvelumme vakaus Kiinassa ja mitä ongelmia kohtasimme sen käyttöönoton aikana (ottaen huomioon datakeskuksemme sijainnin Yhdysvaltojen itärannikolla).
Tästä tulee iso tarina, joka on jaettu useisiin artikkeleihin. Kerron sinulle, kuinka se kaikki tapahtui meille: täysin toimimattomasta palvelusta Kiinasta palvelun suorituskykyindikaattoreihin sen amerikkalaisen version tasolla amerikkalaisille. Lupaan, että se on mielenkiintoinen ja hyödyllinen. Joten mennään.
Kiinan Internetin ongelmat
Jopa verkonhallinnan erityispiirteistä kauimpana oleva ihminen on kuullut siitä Kiinan suuri palomuuri. Vau, kuulostaa siistiltä, eikö? Mutta mikä se on ja miten se todella toimii, on melko monimutkainen kysymys. Internetistä löytyy monia tähän liittyviä artikkeleita, mutta teknisestä näkökulmasta tämän palomuurin rakennetta ei ole kuvattu missään. Mikä ei kuitenkaan ole yllättävää. Myönnän heti, että vuoden työn tulosten perusteella en osaa sanoa tarkalleen, miten se toimii, mutta voin kertoa kommenteistani ja käytännön johtopäätöksistäni. Ja aloitamme huhuilla tästä palomuurista.
Tästä palomuurista liikkuu monia huhuja. Kootaan tärkeimmät ja mielenkiintoisimmat niistä yhteen luetteloon:
- Google, Facebook, Twitter ja muut vastaavat palvelut on estetty, eivätkä ne toimi Kiinassa.
- Kaikki Kiinan ULKOPUOLELLA ja Kiinaan menevä liikenne jäsennetään ja rajoitetaan koneoppimisen avulla (epäilyttävän liikenteen tapauksessa), mikä hidastaa huomattavasti rajan läpi kulkevaa liikennettä.
- Kiinan tiedustelupalvelut hakkeroivat kaiken palomuurinsa läpi kulkevan salatun liikenteen.
- VPN-tunnelit, IPSEC-tunnelit ovat epävakaita, kaatuvat ja ovat jatkuvasti tukossa.
- Mitä yksinkertaisempi salaus on, sitä yksinkertaisempaa salalausetta käytetään liikenteen todentamiseen/salaukseen, sitä nopeammin se kulkee Kiinan palomuurin läpi.
Tässä on, mitä saimme selville näistä huhuista:
- Google, Facebook, Twitter ja muut vastaavat palvelut ovat todellakin estetty (sinun KO), mutta esimerkiksi monet tekniset Google-verkkotunnukset eivät ole kiellettyjä ja toimivat (sama gstatic.com). Tästä seuraa johtopäätös: sinun ei pitäisi piittaamattomasti leikata pois kaikkia Googlea ja muita resursseja, jotka näyttävät olevan estetty.
- Kaikki rajan ylittävä liikenne viivästää huomattavasti aikaa. Katso kaksi tulosta. Yksi sivusto, yksi sivu, yksinkertainen HANKI kiemura'om. Ensimmäinen mittaus tehtiin itse Kiinasta (kaunis Shenzhenin kaupunki). Toinen mitattiin ulkopuolelta Hongkongista (sillä on suvereniteetti, eikä sen ja maailman välillä ole palomuuria). Kaupunkien välinen etäisyys suorassa linjassa on noin 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sKiinnitä huomiota aika_yhteys. Ja yleensä, näet tuloksen: palomuuri lisää 4 ylimääräistä sekuntia, mikä on hirvittävän pitkä.
- VPN- ja IPSEC-tunnelit epäonnistuvat usein. Puhun tästä hieman myöhemmin ja tarkemmin. Käyttäjien käyttämät VPN-palvelimet estetään ajan myötä (yleensä vuorokauden sisällä käytön alkamisesta).
- Kiinassa asuvilta on saatu mielipide, että mitä yksinkertaisempi liikenteen salaus on, sitä nopeammin se kulkee rajan läpi, koska on helppo ymmärtää, ettei siinä ole mitään laitonta. Ja samalla tavalla "puhdas" liikenne saa enemmän kaistanleveyttä ja kulkunopeutta, kun taas "likainen" liikenne, jossa ei voi ymmärtää mitään, saa päinvastoin hitaamman kulun. Käytän esimerkiksi curl-toimintoa ifconfig.co HTTPS:n ja HTTP-protokollan kautta.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/s5 sekunnin ero 13 tavun kokonaislatausajassa. Lisäksi kun teet tällaista testiä useita kertoja, voit huomata, että HTTP:n GET valmistuu yleensä joka kerta samassa ajassa, kun taas HTTPS:ssä sivusto vastaa joskus 3, 5, 10 ja jopa 17 sekunnissa. Joskus tapahtuu SSL-virheitä:
Unknown SSL protocol error in connection to ifconfig.co:443.
Eli mitä meillä on:
- Kiinan palomuurin aiheuttamat ongelmat on kuvattu yllä.
- Pingit ulkoisiin resursseihin ja sisäisiin tunneleihin katoavat ajoittain.
- Kahden pisteen välinen latenssi muuttuu jatkuvasti, ja usein se on yksinkertaisesti arvaamaton. Kun yhdistät eri kaupunkeja/alueita, odotat, että alueiden maantieteellisen sijainnin perusteella viive on pienempi, mutta tilanne on täysin päinvastainen.
- Internet ja viestintäkanavat ovat joko nopeita tai hitaita. Kellonajasta ja viikonpäivästä on lievä riippuvuus, mutta ei aina.
- DNS-pyynnöt ulkomaailmalle Kiinasta ylittävät joskus sallitun aikakatkaisun.
Esiin tuleva kuva on yksinkertaisesti "erinomainen".
Palvelinkeskus, kuten jo sanoin, sijaitsee Yhdysvaltojen itäosassa, ja koko SEMrush koostuu kymmenistä toisiinsa yhdistetyistä tuotteista, taustajärjestelmistä, käyttöliittymistä, tietokannoista ja kaikesta tästä DC:ssä ja pilvissä. Meille järjestelmänvalvojien tiiminä annettiin tehtävänä aloittaa nopeasti työskentely Kiinassa pienellä vaivalla.
Meidän piti vastata tärkeään kysymykseen: onko mahdollista tulla toimeen vähällä kustannuksella ja ratkaista kaikki kiinalaiseen Internetiin ja palomuuriin liittyvät ongelmat verkko/pilvi/palvelintasolla?
Aloitimme vastaanottamalla .
ICP-lisenssi
Jotta voit isännöidä palveluasi Kiinassa (Manner-Kiina) ja suorittaa testejä, sinun on ensin hankittava ICP-lisenssi verkkotunnukselle.
Jos sivustosi käyttäjäliikenne lopetetaan Manner-Kiinassa ja jos verkkotunnuksellasi ei ole ICP-lisenssiä, liikenne estetään Internet-palveluntarjoajan/isäntäpuolen puolella. Mielenkiintoista on, että ICP-lisenssi sisältää tietyn palveluntarjoajan, olipa se sitten Cloudflare tai Alibaba Cloud. Siksi, jos sait ICP-lisenssin Cloudflarelle ja isännöit verkkosivustoasi heidän kanssaan, et voi siirtyä "saumattomasti" Alibaba Cloudiin. Sinun on lisättävä tähän lisenssiin toinen hosting.
Saatuamme ICP-lisenssin toimialueelle pystyimme keksimään ja toteuttamaan erityisiä teknisiä ideoita ja ratkaisuja.
Testausratkaisut
Mutta ennen kuin luot suoraan lavastusvaihtoehtoja, käännät nuppeja, optimoit sivuston suorituskyvyn ja sen nopeuden, sinun on valittava työkalu sen testaamiseen, jotta näet, mitkä toiminnoistamme parantavat tai päinvastoin huonontavat sivuston suorituskykyä.
Testaustyökalumme oli täytettävä kaksi päävaatimusta:
- sen pitäisi pystyä suorittamaan testejä Kiinasta,
- sillä täytyy olla selaintestit.
Joten löysimme ! Heillä on erinomainen kattavuus testauspaikoista ympäri maailmaa. Kiinassa testejä voidaan suorittaa myös 100500 XNUMX maakunnassa tämän työkalun avulla. Jokaisella on useita eri palveluntarjoajia + kyky tehdä Selkäranka-testit (jotain kuten virtuaalikone datakeskuksessa) ja Lastmile-testit (mahdollisimman lähellä käyttöolosuhteita, eli työasema). Jälkimmäisen tyyppiset testit ovat kalliimpia.
Tehtyämme vuosittaisen sopimuksen (vähemmän ei ole mahdollista) aloimme tutkia instrumenttia. Suoraan sanottuna olimme iloisesti yllättyneitä sen toimivuudesta. Voit juosta:
- DNS-testit,
- Verkkotestit (selaintestit, yksinkertainen GET/POST, mobiiliasiakasemulointi jne.),
- Tapahtumatarkastukset (esimerkiksi kirjautuminen),
- API-testit,
- Ping, traceroute, NTP jne.
Kaikkea ei voi luetella. Ja mikä tärkeintä, jokainen testi voidaan mukauttaa melko hyvin lisäämällä joukko otsikoita ja muita parametreja. Tulos on valtava määrä tietoa, joka kuvaa täysin testiäsi. Jos puhumme meille mielenkiintoisimmista asioista (selaintestit), tulos sisältää:
- Yhdistä, odota, lataa, SSL, DNS-aika,
- TTFB, TTLB, asiakirja valmis, renderöintiaika, DOM-lataus,
- Response (jotain lähellä Time To Last Bytea), Webpage Response (jotain lähellä Time To Last Bytea),
- Mikä tahansa prosenttipiste, keskiarvo, mediaaniaika
- Jne.
Näin ollen kaikki nämä mittarit ovat erinomaisia muutosten näkemiseen ja sen ymmärtämiseen, ovatko asiat parantuneet. Katsoimme pääasiassa Vaste, verkkosivun vastaus, mediaani, 75 ja 95 prosenttipisteet.
Tärkeä kysymys, joka oli ilmassa alusta asti: Voitko luottaa Catchpointiin?? Kuvaako tämä työkalu todellista sivustojen latausnopeutta Kiinassa eri kaupungeista, vai onko se vain jonkinlainen tyhjiötesti, jolla ei ole mitään tekemistä todellisen käyttökokemuksen kanssa?
Tämä on suuri ongelma, koska Venäjällä ollessa on lähes mahdotonta saada luotettavasti selville, kuinka kiinalainen sivusto toimii. Tekemällä socks-proxyn virtuaalikoneen kautta lopputuloksena on, että sivusto latautuu parissa minuutissa, mikä on yksinkertaisesti mahdotonta hyväksyä testeissä, joten ainoa vaihtoehto manuaaliseen testaukseen on curl ja yksinkertainen GET konsolista ajastimella. . Tämä auttaa, koska tämä testi heijastaa hyvin verkkoratkaisun nopeutta, ja jos on myös selaintestejä, niin se on erittäin hyvä.
Myöhemmin menimme itse Kiinaan ja olimme vakuuttuneita siitä Voit luottaa Catchpointiin, se heijastaa melko tarkasti todellisia suorituskykyindikaattoreita.
Cloudflare China Network
Koska käytämme onnistuneesti Cloudflarea semrush.com-pääverkkotunnuksessa, päätimme heti kokeilla heidän ominaisuuttaan . Tämä vaihtoehto on käytössä vain Enterprise-sivustoissa erillisestä pyynnöstä ja lisämaksusta. Se on myös saatavilla vain sivustoille, joilla on asianmukainen ICP-lisenssi, joka ilmoittaa Cloudflaren palveluntarjoajana. Sen käyttöönoton jälkeen Cloudflaren "kiinalainen CDN" tulee saataville sivustolle - liikenne Kiinan alueelta laskeutuu lähimpään PoP (Points of Presence) CF:ään, jonka verkkojen tai palveluntarjoajien/kumppaneiden verkkojen kautta se toimitetaan alkuperälle. .
Tämän testipenkin kaavio on esitetty alla.
Tämä on meille loistava vaihtoehto. Osoittautuu, että myös toinen verkkoalue tulee olemaan CF:lle, mikä ei lisää yrityksessä käytettävien ratkaisujen määrää, eikä myöskään käytännössä monimutkaista infrastruktuuria.
Teimme selaintestejä ja tapahtui näin:
Punaiset timantit ovat testivirheitä. Alla olevat tiedostot ovat DNS-virheitä (resolve timeout). Huipulla olevat epäonnistumiset ovat aikakatkaisuja.
Käyttöaika: 86.6
Mediaani: 18s
75 prosenttipiste: 29.3 s
95 prosenttipiste: 60 s
Mediaani, latauksen jälkeen poistettiin reCaptcha (Google-palvelu estetty Kiinassa) laski 28 sekunnista 18 sekuntiin. Mutta nämä ovat silti kauheita tuloksia, kun otetaan huomioon, että sama testi semrush.comille (Yhdysvalloista) antoi alle 10 sekuntia 95%:lle käyttäjistä (Yhdysvalloista) samalla sivulla (staattinen + dynaaminen).
Voit mennä jokaiseen testiin ja katsoa Vesiputous ja muut tarkemmat parametrit. Aloimme selvittää virheiden syitä, ja jos aikakatkaisujen osalta kaikki on enemmän tai vähemmän selvää: Internet Kiinassa "liikkuu sisään ja ulos", tämän vuoksi yhteyden nopeus ja resurssien lataus ulkomailta on epävakaa ja epätasainen, sitten DNS-virheet yllättivät meidät suuresti. Löysimme sen Pop Cloudflare sijaitsevat itse asiassa Kiinassa, sivuston osoite ratkaisee yhden anycast-IP-osoitteen, mutta DNS-palvelimet ovat amerikkalaisia, minkä vuoksi DNS-pyynnöt pakotetaan kulkemaan rajan yli, joten joskus ne epäonnistuvat.
Selvitettyään tätä kysymystä CF:n kanssa, kävi ilmi Heillä ei ole omia DNS-palvelimia Kiinassa, ja milloin se tapahtuu, ei ole vielä tiedossa.
Siksi päätimme testata vain Cloudflare DNS:ää ja muutimme sivustomme Cloudflaren toimintamekanismiksi "Vain DNS" Tämä on tila, jossa Cloudflare ei välitä välityspalvelinliikennettä itsensä kautta, mikä tarkoittaa, että se ei tarjoa DDoS-suojausta, CDN:ää ja muita ominaisuuksia ja toimii tavallisen DNS-palvelimen tilassa.
Tämä teline on esitetty kaavamaisesti seuraavassa kuvassa. Kuvassa on otettu huomioon uusi tieto siitä, että Cloudflaren DNS-palvelimet ovat palomuurin takana.
Catchpointissa suoritimme yksinkertaisia GET-testejä (ei selaintestejä), jotka osoittivat paljon epäonnistumisia. Ne johtuivat samoista DNS-virheistä.
Aloimme korjata näitä virheitä käyttämällä kaivaa ja huomasimme, että ensimmäisestä pyynnöstä osoite määritetään oikein, ja toistuvasta pyynnöstä saamme joka kerta SERVFAIL и ei löydetty. Miksi tämä tapahtuu yhtäkkiä?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Tällaisia virheitä ei esiinny, kun kyselyä Cloudflare NS -palvelimille tehdään suoraan:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192Tämä tarkoittaa, että ongelma on "paikallisen" DNS-palvelimen tai palveluntarjoajan palvelimen puolella.
Lisätutkimukset paljastivat sen SERVFAIL päädymme ratkaisuun AAAA- levyt.
Kävi ilmi, että pyydettäessä Cloudflarelta AAAA-tietue, jota ei ole toimialueella, Cloudflare vastasi А-merkintä, joka on virhe ja RFC:n vastainen. Miksi paikallinen ratkaisija (xxxx) En pitänyt siitä, ja hän vastasi SERVFAIL. Tämä käyttäytyminen näkyy selvästi alla olevassa lokissa:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE rcvd: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Lähetimme virheraportin Cloudflarelle, ja he korjasivat sen jonkin ajan kuluttua. Se osoittautui mielenkiintoiseksi: tällä hetkellä Kiinassa ei vieläkään ole IPv6-tukea, joten Cloudflare ei voinut antaa IPv6-osoitettaan siellä vastauksena pyyntöön AAAA- levyt. Lopulta kaikki ratkesi niin, että Cloudflare alkoi vastata Kiinan puolesta NODATA tällaisiin pyyntöihin.
Siten DNS-virheet Catchpoint-testeissä vähenivät jyrkästi, mutta eivät kokonaan. Aikakatkaisut ovat vielä täällä:
Ja aloimme etsimään toista ratkaisua.
Seuraavassa osassa kerron kuinka testasimme kiinalaista pilveä Alibaba Cloud, kuinka Nginxin pienen "taikuuden" avulla pystyimme nopeasti luomaan PoC (Proof of Concept) -ratkaisuja, kuinka loimme Multi-Cloud -ratkaisuja, joista yksi auttoi lopulta suuresti nopeuttamaan palvelun työtä Kiinasta.
Pysy kanavalla!
Seuraavat osat
Lähde: will.com
