Hello kila mtu!
Nikita anawasiliana - mhandisi wa mfumo kutoka kwa kampuni SEMrush. Leo nitakuambia kuhusu jinsi tulivyokabiliana na kazi ya kuhakikisha uthabiti wa huduma yetu ya semrush.com nchini China, na matatizo gani tuliyopata wakati wa utekelezaji wake (kutokana na eneo la kituo chetu cha data kwenye pwani ya mashariki ya Marekani).
Hii itakuwa hadithi kubwa, imegawanywa katika makala kadhaa. Nitakuambia jinsi yote yalivyotokea kwetu: kutoka kwa huduma isiyo ya kazi kabisa kutoka China, hadi viashiria vya utendaji wa huduma katika kiwango cha toleo lake la Marekani kwa Wamarekani. Ninaahidi itakuwa ya kuvutia na yenye manufaa. Kwa hiyo, twende.
Matatizo ya mtandao wa Kichina
Hata mtu wa mbali zaidi kutoka kwa maelezo ya usimamizi wa mtandao amesikia kuhusu Firewall kubwa ya Uchina. Lo, inasikika, sawa? Lakini ni nini na jinsi inavyofanya kazi ni swali gumu sana. Unaweza kupata vifungu vingi kwenye mtandao vinavyotolewa kwa hili, lakini kutoka kwa mtazamo wa kiufundi, muundo wa firewall hii haujaelezewa popote. Ambayo, hata hivyo, haishangazi. Nitakubali mara moja kwamba kulingana na matokeo ya mwaka wa kazi, sitaweza kusema hasa jinsi inavyofanya kazi, lakini naweza kukuambia kuhusu maoni yangu na hitimisho la vitendo. Na tutaanza na uvumi kuhusu firewall hii.
Kuna uvumi mwingi juu ya firewall hii. Wacha tukusanye kuu na ya kuvutia zaidi yao kwenye orodha moja:
- Google, Facebook, Twitter na huduma zingine zinazofanana zimezuiwa na hazifanyi kazi nchini Uchina.
- Trafiki yoyote inayoenda NJE ya Uchina na NDANI YA Uchina huchanganuliwa na kupunguzwa kwa kutumia mafunzo ya mashine (katika hali ya trafiki inayoshukiwa), ambayo hupunguza kasi yake (trafiki) kupita mpaka.
- Mashirika ya kijasusi ya China yatavamia trafiki yoyote iliyosimbwa kwa njia fiche inayopita kwenye ngome zao.
- Vichungi vya VPN, vichuguu vya IPSEC si dhabiti, vinaanguka na huzuiwa kila wakati.
- Kadiri usimbaji fiche unavyokuwa rahisi, ndivyo maneno ya siri yanavyotumiwa kuthibitisha/kusimba trafiki kwa njia fiche, ndivyo inavyopita kwenye ngome ya Kichina.
Haya ndiyo tuliyoyapata kuhusu tetesi hizi:
- Google, Facebook, Twitter na huduma zingine zinazofanana kwa hakika zimezuiwa (KO yako), lakini vikoa vingi vya kiufundi vya Google, kwa mfano, havijapigwa marufuku na vinafanya kazi (gstatic.com sawa). Hitimisho linafuata kutoka kwa hili: hupaswi kukata bila kujali rasilimali zote za Google na nyingine ambazo zinaonekana kuzuiwa.
- Trafiki yoyote inayopita mpaka inaongeza ucheleweshaji mkubwa kwa wakati wake. Angalia matokeo mawili. Tovuti moja, ukurasa mmoja, PATA rahisi curl'om. Kipimo cha kwanza kilitoka China yenyewe (mji mzuri wa Shenzhen). Ya pili ilipimwa kutoka nje kutoka Hong Kong (ina uhuru, na hakuna firewall kati yake na dunia). Umbali kati ya miji katika mstari wa moja kwa moja ni takriban 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/sMakini na muda_connect. Na kwa ujumla, unaona matokeo: firewall inaongeza sekunde 4 za ziada, ambazo ni ndefu sana.
- Vichungi vya VPN na IPSEC hushindwa mara nyingi. Nitazungumza juu ya hii baadaye kidogo na kwa undani zaidi. Seva za VPN ambazo hutumiwa na watumiaji huzuiwa kwa muda (kawaida ndani ya siku baada ya kuanza kwa matumizi).
- Kuna maoni yaliyopokelewa kutoka kwa watu wanaoishi nchini China kwamba rahisi zaidi encryption ya trafiki, kasi inapita kwenye mpaka, kwa sababu ni rahisi kuelewa kwamba hakuna kitu kinyume cha sheria kuhusu hilo. Na kwa njia hiyo hiyo, trafiki "safi" hupokea bandwidth zaidi na kasi ya kifungu, wakati trafiki "chafu", ambayo hakuna kitu kinachoweza kueleweka, inapokea, kinyume chake, kifungu cha polepole. Kwa mfano nitatumia curl kwa ifconfig.co kupitia itifaki ya HTTPS na HTTP.
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/sTofauti ya sekunde 5 kwa jumla ya muda wa upakuaji wa baiti 13. Zaidi ya hayo, unapofanya jaribio kama hilo mara kadhaa, unaweza kugundua kuwa GET kwenye HTTP inakamilika kwa ujumla kwa wakati mmoja kila wakati, wakati kwenye HTTPS tovuti wakati mwingine hujibu kwa sekunde 3, 5, 10 na hata 17. Wakati mwingine makosa ya SSL hufanyika:
Unknown SSL protocol error in connection to ifconfig.co:443.
Kwa hivyo tunayo:
- Matatizo yaliyoundwa na firewall ya Kichina yanaelezwa hapo juu.
- Pings kwa rasilimali za nje na vichuguu vya ndani hupotea mara kwa mara.
- Ucheleweshaji kati ya alama mbili hubadilika kila wakati, na mara nyingi haitabiriki. Wakati wa kuunganisha miji/maeneo mbalimbali, unatarajia kwamba, kulingana na eneo la kijiografia la mikoa, ucheleweshaji utakuwa mdogo, lakini unapata hali tofauti kabisa.
- Mtandao na njia za mawasiliano ni za haraka au polepole. Kuna utegemezi kidogo juu ya wakati wa siku na siku ya wiki, lakini si mara zote.
- Maombi ya DNS kwa ulimwengu wa nje kutoka Uchina wakati mwingine huzidi muda ulioruhusiwa.
Picha inayojitokeza ni "bora."
Kituo cha data, kama nilivyokwisha sema, kiko mashariki mwa Merika, na SEMrush nzima ina bidhaa kadhaa zilizounganishwa, sehemu za nyuma, sehemu za mbele, hifadhidata, na haya yote katika DC na mawingu. Sisi, kama timu ya wasimamizi wa mfumo, tulipewa jukumu la kuanza kufanya kazi haraka nchini China kwa bidii kidogo.
Tulipaswa kujibu swali muhimu: inawezekana kupata kwa gharama kidogo na kutatua matatizo yote yanayohusiana na mtandao wa Kichina na firewall kwenye kiwango cha mtandao / wingu / seva?
Tulianza kwa kupokea .
Leseni ya ICP
Ili uweze kupangisha huduma yako ndani ya Uchina (Uchina Bara) na kufanya majaribio, lazima kwanza upate leseni ya ICP ya kikoa.
Ikiwa trafiki ya watumiaji wa tovuti yako itakomeshwa ndani ya Uchina Bara, na ikiwa kikoa chako hakina leseni ya ICP, trafiki yako itazuiwa kwenye upande wa ISP/mwenyeji. Inafurahisha, leseni ya ICP inajumuisha mtoa huduma maalum, iwe Cloudflare au Alibaba Cloud. Kwa hivyo, ikiwa ulipokea leseni ya ICP ya Cloudflare na kukaribisha tovuti yako nayo, hutaweza "kuhama" bila mshono hadi Alibaba Cloud. Utahitaji kuongeza upangishaji mwingine kwenye leseni hii.
Baada ya kupokea leseni ya ICP ya kikoa, tuliweza kuja na kutekeleza mawazo na masuluhisho mahususi ya kiufundi.
Ufumbuzi wa majaribio
Lakini kabla ya kuunda chaguzi za uwekaji moja kwa moja, geuza visu, uboresha utendaji wa tovuti na kasi yake, unahitaji kuchagua zana ya kuijaribu ili kuona ni ipi kati ya hatua zetu zinazoboresha au, kinyume chake, kuzidisha utendaji wa tovuti.
Chombo chetu cha majaribio kilipaswa kukidhi mahitaji mawili kuu:
- inapaswa kuwa na uwezo wa kuendesha majaribio kutoka China,
- lazima iwe na majaribio ya kivinjari.
Kwa hivyo tulipata ! Wana chanjo bora ya maeneo ya majaribio ulimwenguni kote. Nchini Uchina, majaribio yanaweza pia kuendeshwa kutoka mikoa 100500 kupitia zana hii. Kila moja ina watoa huduma kadhaa tofauti + uwezo wa kufanya Uti wa mgongo-majaribio (kitu kama mashine ya kawaida kwenye kituo cha data) na Lastmile- vipimo (karibu iwezekanavyo na hali ya mtumiaji, aka kituo cha kazi). Aina ya mwisho ya vipimo ni ghali zaidi.
Baada ya kumaliza mkataba wa kila mwaka (chini ya hiyo haiwezekani), tulianza kusoma chombo. Kwa kweli, tulishangazwa sana na utendaji wake. Unaweza kukimbia:
- vipimo vya DNS,
- Majaribio ya wavuti (majaribio ya vivinjari, GET/POST rahisi, uigaji wa mteja wa simu, n.k.),
- Ukaguzi wa shughuli (kwa mfano, kuingia),
- vipimo vya API,
- Ping, traceroute, NTP, nk.
Huwezi kuorodhesha kila kitu. Na muhimu zaidi, kila jaribio linaweza kubinafsishwa vizuri kwa kuongeza rundo la vichwa na vigezo vingine. Matokeo ni kiasi kikubwa cha maelezo ambayo yanaelezea kikamilifu jaribio lako. Ikiwa tunazungumza juu ya vitu vya kupendeza zaidi kwetu (vipimo vya kivinjari), matokeo ni pamoja na:
- Unganisha, Subiri, Pakia, SSL, wakati wa DNS,
- TTFB, TTLB, Hati imekamilika, Muda wa Utoaji, upakiaji wa DOM,
- Majibu (jambo lililo karibu na Time To First Byte), Majibu ya Ukurasa wa Wavuti (jambo lililo karibu na Time To Last Byte),
- Asilimia yoyote, Wastani, Wakati wa Kati
- Na kadhalika.
Ipasavyo, vipimo hivi vyote ni vyema kwa kuona mabadiliko na kuelewa ikiwa mambo yamekuwa bora. Tuliangalia hasa Majibu, Majibu ya Ukurasa wa Wavuti, Wastani, Asilimia 75 na 95.
Swali muhimu ambalo lilikuwa hewani tangu mwanzo: Je, unaweza kuamini Catchpoint?? Je, zana hii inaakisi kasi halisi ya upakiaji wa tovuti nchini Uchina kutoka miji tofauti, au ni aina fulani ya jaribio katika utupu ambalo halihusiani na matumizi halisi ya mtumiaji?
Hili ni shida kubwa, kwa sababu kuwa nchini Urusi karibu haiwezekani kujua jinsi tovuti kutoka Uchina inavyofanya kazi. Kwa kufanya wakala wa soksi kupitia mashine ya kawaida, matokeo ya mwisho ni kwamba tovuti hupakia ndani ya dakika chache, ambayo haikubaliki kwa majaribio, kwa hivyo chaguo pekee la upimaji wa mwongozo ni curl na PATA rahisi kutoka kwa koni iliyo na kipima muda. . Hii husaidia kwa sababu mtihani huu unaonyesha vizuri kasi ya ufumbuzi wa mtandao, na ikiwa pia kuna vipimo vya kivinjari, basi ni nzuri sana.
Baadaye sisi wenyewe tulikwenda China na tukasadikishwa hivyo Unaweza kuamini Catchpoint; inaonyesha kwa usahihi viashiria halisi vya utendakazi.
Mtandao wa Cloudflare China
Kwa kuwa tulifanikiwa kutumia Cloudflare kwa kikoa kikuu cha semrush.com, tuliamua kujaribu mara moja kipengele chao kinachoitwa . Chaguo hili limewezeshwa kwa tovuti za Biashara tu kwa ombi tofauti na kwa ada ya ziada. Pia inapatikana kwa tovuti ambazo zina leseni inayofaa ya ICP ambayo inaorodhesha Cloudflare kama mtoa huduma. Baada ya kuiwezesha, "CDN ya Kichina" kutoka Cloudflare inapatikana kwa tovuti - trafiki kutoka mikoa ya Uchina inatua kwenye PoP (Points of Presence) CF iliyo karibu zaidi, na kisha kupitia mitandao yake au mitandao ya watoa huduma/washirika inawasilishwa asili. .
Mchoro wa benchi hii ya mtihani umewasilishwa hapa chini.
Hili ni chaguo kubwa kwetu. Inabadilika kuwa kikoa cha pili pia kitakuwa cha CF, ambacho hakiongezi kwa idadi ya suluhisho zinazotumiwa katika kampuni, na pia kivitendo haifanyi ugumu wa miundombinu.
Tuliendesha majaribio ya kivinjari na hii ndio ilifanyika:
Almasi nyekundu ni kushindwa kwa mtihani. Faili zilizo hapa chini ni hitilafu za DNS (suluhisha muda kuisha). Kushindwa huko juu ni kuisha kwa muda.
Muda wa ziada: 86.6
Wastani: 18s
Asilimia 75: 29.3s
Asilimia 95: 60s
Wastani, baada ya upakiaji iliondolewa recaptcha (Huduma ya Google imezuiwa nchini Uchina) ilipungua kutoka sekunde 28 hadi 18. Lakini haya bado ni matokeo ya kutisha, kwa kuzingatia kwamba jaribio sawa la semrush.com (kutoka Marekani) lilitoa chini ya sekunde 10 kwa 95% ya watumiaji (kutoka Marekani) kwenye ukurasa huo huo (tuli + dynamic).
Unaweza kwenda katika kila mtihani na kuangalia Maporomoko ya maji na vigezo vingine vya kina zaidi. Tulianza kuchunguza sababu za makosa, na ikiwa kwa muda kila kitu kiko wazi zaidi au kidogo: Mtandao nchini China "huingia na kutoka", kwa sababu ya hii kasi ya uunganisho na upakiaji wa rasilimali kutoka nje ya nchi ni imara na isiyo sawa, basi makosa ya DNS yalitushangaza sana. Tumegundua hilo Po Cloudflare ziko nchini Uchina, anwani ya tovuti hutatuliwa kwa IP yoyote ya utangazaji, lakini seva za DNS ni za Amerika, ndiyo sababu maombi ya DNS yanalazimika kuvuka mpaka, kwa hivyo wakati mwingine hushindwa.
Baada ya kufafanua swali hili na CF, ikawa hivyo Hawana seva zao za DNS nchini Uchina, na lini itakuwa bado haijulikani.
Kwa hivyo, tuliamua kujaribu Cloudflare DNS pekee na tukabadilisha utaratibu wa uendeshaji wa Cloudflare kwa tovuti yetu kuwa “DNS pekee" Hii ni hali wakati Cloudflare haifanyi trafiki ya seva mbadala yenyewe, ambayo inamaanisha haitoi ulinzi wa DDoS, CDN na vipengele vingine, na hufanya kazi katika hali ya seva ya kawaida ya DNS.
Msimamo huu umeonyeshwa schematically katika takwimu ifuatayo. Takwimu inazingatia maarifa yanayoibuka kuwa seva za DNS za Cloudflare ziko nyuma ya ngome.
Katika Catchpoint tuliendesha majaribio rahisi ya GET (si majaribio ya kivinjari), ambayo yalionyesha mapungufu mengi. Yalisababishwa na makosa sawa ya DNS.
Tulianza kutatua hitilafu hizi kwa kutumia kuchimba na kugundua kuwa kwa ombi la kwanza anwani imedhamiriwa kwa usahihi, na kwa ombi la kurudiwa tunapokea kila wakati HUDUMA и haipatikani. Kwa nini hii inatokea ghafla?
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)Hakuna makosa kama haya wakati wa kuuliza seva za Cloudflare NS moja kwa moja:
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.192Hii ina maana kwamba tatizo liko upande wa seva ya "ndani" ya DNS au seva ya mtoa huduma.
Uchunguzi zaidi ulibaini hilo HUDUMA tunapata suluhu aAAA-rekodi.
Ilibadilika kuwa wakati wa kuomba kutoka kwa Cloudflare AAAA-rekodi ambayo haipo kwenye kikoa, Cloudflare ilijibu А-ingizo ambalo ni kosa na kutofuata RFC. Kwa nini msuluhishi wa eneo hilo (xxx) Sikuipenda, naye akajibu HUDUMA. Tabia hii inaonekana wazi katika logi hapa chini:
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
Tuliwasilisha ripoti ya hitilafu kwa Cloudflare, na waliirekebisha baada ya muda fulani. Ilibadilika kuwa ya kufurahisha: kwa sasa bado hakuna msaada wa IPv6 nchini Uchina, kwa hivyo Cloudflare haikuweza kutoa anwani yake ya IPv6 huko kujibu ombi. AAAA-rekodi. Mwishowe, kila kitu kilitatuliwa kwa njia ambayo Cloudflare ilianza kujibu Uchina HAKUNA DATA kwa maombi kama hayo.
Kwa hivyo, makosa ya DNS katika vipimo vya Catchpoint yalipungua kwa kasi, lakini sio kabisa. Muda bado uko hapa:
Na tukaanza kutafuta suluhisho lingine.
Katika sehemu inayofuata nitakuambia jinsi tulivyojaribu wingu la Kichina Alibaba Cloud, jinsi gani, kwa msaada wa "uchawi" mdogo wa Nginx, tuliweza kuunda haraka ufumbuzi wa PoC (Ushahidi wa Dhana), jinsi tulivyounda ufumbuzi wa Multi-Cloud, moja ambayo hatimaye ilisaidia sana kuharakisha kazi ya huduma. kutoka China.
Endelea!
Sehemu zinazofuata
Chanzo: mapenzi.com
