Kumusta sa lahat!
Si Nikita ay nakikipag-ugnayan - isang system engineer mula sa kumpanya SEMrush. Ngayon sasabihin ko sa iyo ang tungkol sa kung paano namin hinarap ang gawain ng pagtiyak ng katatagan ng aming serbisyo ng semrush.com sa China, at kung anong mga problema ang naranasan namin sa pagpapatupad nito (ibinigay ang lokasyon ng aming data center sa silangang baybayin ng Estados Unidos).
Ito ay magiging isang malaking kuwento, na nahahati sa ilang mga artikulo. Sasabihin ko sa iyo kung paano nangyari ang lahat para sa amin: mula sa isang ganap na hindi gumaganang serbisyo mula sa China, hanggang sa mga tagapagpahiwatig ng pagganap ng serbisyo sa antas ng Amerikanong bersyon nito para sa mga Amerikano. Ipinapangako ko na ito ay magiging kawili-wili at kapaki-pakinabang. So, tara na.
Mga problema ng Chinese Internet
Kahit na ang pinakamalayo na tao mula sa mga detalye ng pangangasiwa ng network ay narinig Great Firewall ng China. Wow, mukhang cool, tama? Ngunit kung ano ito at kung paano ito gumagana ay isang medyo kumplikadong tanong. Maaari kang makahanap ng maraming mga artikulo sa Internet na nakatuon dito, ngunit mula sa isang teknikal na punto ng view, ang istraktura ng firewall na ito ay hindi inilarawan kahit saan. Na, gayunpaman, ay hindi nakakagulat. Aaminin ko kaagad na batay sa mga resulta ng isang taon ng trabaho, hindi ko masasabi nang eksakto kung paano ito gumagana, ngunit masasabi ko sa iyo ang tungkol sa aking mga komento at praktikal na konklusyon. At magsisimula tayo sa mga alingawngaw tungkol sa firewall na ito.
Maraming alingawngaw tungkol sa mismong firewall na ito. Kolektahin natin ang pangunahin at pinakakawili-wili sa mga ito sa isang listahan:
- Ang Google, Facebook, Twitter at iba pang katulad na serbisyo ay naka-block at hindi gumagana sa China.
- Ang anumang trapikong LABAS ng Tsina at PAPASOK sa China ay na-parse at nililimitahan gamit ang machine learning (sa kaso ng kahina-hinalang trapiko), na lubos na nagpapabagal dito (trapiko) na dumadaan sa hangganan.
- Iha-hack ng mga ahensya ng intelihente ng China ang anumang naka-encrypt na trapiko na dumadaan sa kanilang firewall.
- Ang mga VPN tunnel, IPSEC tunnels ay hindi matatag, bumagsak at patuloy na hinaharangan.
- Kung mas simple ang pag-encrypt, mas simple ang pass phrase na ginamit upang patotohanan/i-encrypt ang trapiko, mas mabilis itong dumaan sa Chinese firewall.
Narito ang nalaman namin tungkol sa mga tsismis na ito:
- Ang Google, Facebook, Twitter at iba pang katulad na mga serbisyo ay talagang naka-block (iyong KO), ngunit maraming mga teknikal na domain ng Google, halimbawa, ay hindi pinagbawalan at gumagana (ang parehong gstatic.com). Ang konklusyon ay sumusunod mula dito: hindi mo dapat walang ingat na putulin ang lahat ng Google at iba pang mga mapagkukunan na mukhang na-block.
- Ang anumang trapiko na dumadaan sa hangganan ay talagang nagdaragdag ng malubhang pagkaantala sa oras nito. Tingnan ang dalawang resulta. Isang site, isang page, simpleng GET kulutan'om. Ang unang sukat ay mula mismo sa Tsina (ang magandang lungsod ng Shenzhen). Ang pangalawa ay sinukat mula sa labas mula sa Hong Kong (ito ay may soberanya, at walang firewall sa pagitan nito at ng mundo). Ang distansya sa pagitan ng mga lungsod sa isang tuwid na linya ay humigit-kumulang 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/sTandaan ang pagkakakonekta ng oras. At sa pangkalahatan, nakikita mo ang resulta: ang firewall ay nagdaragdag ng 4 na dagdag na segundo, na napakahaba.
- Ang mga tunnel ng VPN at IPSEC ay madalas na nabigo. Pag-uusapan ko ito sa ibang pagkakataon at nang mas detalyado. Ang mga VPN server na ginagamit ng mga user ay naharang sa paglipas ng panahon (karaniwan ay sa loob ng isang araw pagkatapos ng simula ng paggamit).
- May isang opinyon na natanggap mula sa mga taong naninirahan sa China na ang mas simple ang pag-encrypt ng trapiko, mas mabilis itong dumaan sa hangganan, dahil madaling maunawaan na walang ilegal tungkol dito. At sa parehong paraan, ang "malinis" na trapiko ay tumatanggap ng mas maraming bandwidth at bilis ng pagpasa, habang ang "marumi" na trapiko, kung saan walang mauunawaan, ay tumatanggap, sa kabaligtaran, ng mas mabagal na daanan. Halimbawa, gagamit ako ng curl to ifconfig.co sa pamamagitan ng HTTPS at HTTP protocol.
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/sIsang pagkakaiba ng 5 segundo para sa kabuuang oras ng pag-download na 13 bytes. Bukod dito, kapag gumagawa ng ganoong pagsubok nang ilang beses, maaari mong mapansin na ang GET sa HTTP ay nakumpleto sa pangkalahatan sa parehong oras sa bawat oras, habang sa HTTPS ang site kung minsan ay tumutugon sa 3, 5, 10 at kahit na 17 segundo. Minsan nangyayari ang mga error sa SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Kaya kung ano ang mayroon kami:
- Ang mga problemang nilikha ng Chinese firewall ay inilarawan sa itaas.
- Pana-panahong nawawala ang mga ping sa mga panlabas na mapagkukunan at sa loob ng mga tunnel.
- Ang latency sa pagitan ng dalawang punto ay patuloy na nagbabago, at kadalasan ito ay hindi mahuhulaan. Kapag kumokonekta sa iba't ibang lungsod/rehiyon, inaasahan mo na, batay sa heograpikal na lokasyon ng mga rehiyon, magiging mas kaunti ang pagkaantala, ngunit eksaktong kabaligtaran na sitwasyon ang makukuha mo.
- Ang Internet at mga channel ng komunikasyon ay mabilis o mabagal. Mayroong bahagyang pag-asa sa oras ng araw at araw ng linggo, ngunit hindi palaging.
- Ang mga kahilingan sa DNS sa labas ng mundo mula sa China ay minsan ay lumalampas sa pinapayagang timeout.
Ang larawang lumalabas ay simpleng "mahusay."
Ang data center, gaya ng nasabi ko na, ay nasa silangang Estados Unidos, at ang buong SEMrush ay binubuo ng dose-dosenang magkakaugnay na produkto, backend, frontend, database, at lahat ng ito sa DC at clouds. Kami, bilang isang pangkat ng mga tagapangasiwa ng system, ay binigyan ng gawaing mabilis na magsimulang magtrabaho sa China nang walang kaunting pagsisikap.
Kailangan naming sagutin ang isang mahalagang tanong: posible bang makayanan sa maliit na gastos at malutas ang lahat ng problemang nauugnay sa Chinese Internet at firewall sa antas ng network/cloud/server?
Nagsimula kami sa pagtanggap .
Lisensya sa ICP
Upang ma-host ang iyong serbisyo sa loob ng China (Mainland China) at makapagsagawa ng mga pagsubok, kailangan mo munang kumuha ng lisensya ng ICP para sa domain.
Kung ang trapiko ng gumagamit ng iyong site ay winakasan sa loob ng Mainland China, at kung ang iyong domain ay walang lisensya ng ICP, ang iyong trapiko ay maba-block sa bahagi ng ISP/hosting. Kapansin-pansin, ang isang partikular na provider ay umaangkop sa lisensya ng ICP, maging ito Cloudflare o Alibaba Cloud. Samakatuwid, kung nakatanggap ka ng lisensya ng ICP para sa Cloudflare at na-host ang iyong website sa kanila, hindi ka makakalipat sa Alibaba Cloud. Kakailanganin mong magdagdag ng isa pang pagho-host sa lisensyang ito.
Dahil nakatanggap kami ng lisensya ng ICP para sa domain, nakagawa kami ng mga partikular na ideya at solusyong teknikal.
Mga solusyon sa pagsubok
Ngunit bago ka direktang lumikha ng mga pagpipilian sa pagtatanghal, i-on ang mga knobs, i-optimize ang pagganap ng site at ang bilis nito, kailangan mong pumili ng tool para sa pagsubok nito upang makita kung alin sa aming mga aksyon ang bumubuti o, sa kabaligtaran, lumala ang pagganap ng site.
Kailangang matugunan ng aming tool sa pagsubok ang dalawang pangunahing kinakailangan:
- dapat itong magpatakbo ng mga pagsubok mula sa China,
- dapat mayroon itong mga pagsubok sa browser.
Kaya nahanap namin ! Mayroon silang mahusay na saklaw ng mga lokasyon ng pagsubok sa buong mundo. Sa China, ang mga pagsubok ay maaari ding patakbuhin mula sa 100500 probinsya sa pamamagitan ng tool na ito. Ang bawat isa ay may iba't ibang provider + ang kakayahang gawin Gulugod-mga pagsubok (tulad ng isang virtual machine sa isang data center) at Huling milya-mga pagsubok (mas malapit hangga't maaari sa mga kondisyon ng gumagamit, aka workstation). Ang huling uri ng mga pagsubok ay mas mahal.
Ang pagkakaroon ng pagtatapos ng isang taunang kontrata (hindi mas mababa ang posible), sinimulan naming pag-aralan ang instrumento. Sa totoo lang, nagulat kami sa functionality nito. Maaari kang tumakbo:
- Mga pagsubok sa DNS,
- Mga pagsubok sa web (mga pagsubok sa browser, simpleng GET/POST, emulation ng mobile client, atbp.),
- Mga pagsusuri sa transaksyon (halimbawa, pag-login),
- Mga pagsubok sa API,
- Ping, traceroute, NTP, atbp.
Hindi mo mailista ang lahat. At ang pinakamahalaga, ang bawat pagsubok ay maaaring ma-customize nang maayos sa pamamagitan ng pagdaragdag ng isang grupo ng mga header at iba pang mga parameter. Ang output ay isang malaking halaga ng impormasyon na ganap na naglalarawan sa iyong pagsubok. Kung pinag-uusapan natin ang mga pinakakawili-wiling bagay para sa amin (mga pagsubok sa browser), kasama sa resulta ang:
- Kumonekta, Maghintay, Mag-load, SSL, oras ng DNS,
- TTFB, TTLB, Kumpleto ang dokumento, Oras ng pag-render, pag-load ng DOM,
- Tugon (isang bagay na malapit sa Time To First Byte), Tugon sa Webpage (isang bagay na malapit sa Time To Last Byte),
- Anumang percentile, Average, Median time
- Atbp.
Alinsunod dito, ang lahat ng mga sukatan na ito ay mahusay para makita ang mga pagbabago at maunawaan kung ang mga bagay ay naging mas mahusay. Pangunahin naming pinagtitinginan Tugon, Tugon sa Webpage, Median, 75 at 95 Percentiles.
Isang mahalagang tanong na nasa himpapawid mula pa sa simula: Mapagkakatiwalaan mo ba ang Catchpoint?? Sinasalamin ba ng tool na ito ang tunay na bilis ng paglo-load ng site sa China mula sa iba't ibang lungsod, o isa lang itong uri ng pagsubok sa vacuum na walang kinalaman sa tunay na karanasan ng user?
Ito ay isang malaking problema, dahil ang pagiging nasa Russia ay halos imposibleng mapagkakatiwalaang malaman kung paano gumagana ang isang site mula sa China. Sa pamamagitan ng paggawa ng socks-proxy sa pamamagitan ng virtual machine, ang resulta ay naglo-load ang site sa loob ng ilang minuto, na sadyang hindi katanggap-tanggap para sa mga pagsubok, kaya ang tanging opsyon para sa manu-manong pagsubok ay curl at simpleng GET mula sa console na may timer . Nakakatulong ito dahil mahusay na ipinapakita ng pagsubok na ito ang bilis ng solusyon sa network, at kung mayroon ding mga pagsubok sa browser, napakahusay nito.
Nang maglaon kami mismo ang pumunta sa China at kumbinsido iyon Maaari mong pagkatiwalaan ang Catchpoint;
Cloudflare China Network
Dahil matagumpay naming ginagamit ang Cloudflare para sa pangunahing domain na semrush.com, nagpasya kaming agad na subukan ang kanilang feature na tinatawag . Ang opsyong ito ay pinagana lamang para sa mga Enterprise site sa hiwalay na kahilingan at para sa karagdagang bayad. Available lang din ito sa mga site na may naaangkop na lisensya ng ICP na naglilista ng Cloudflare bilang provider. Pagkatapos itong paganahin, ang “Chinese CDN” mula sa Cloudflare ay magiging available para sa site - ang trapiko mula sa mga rehiyon ng China ay dumarating sa pinakamalapit na PoP (Points of Presence) CF, at pagkatapos ay sa pamamagitan ng mga network nito o sa mga network ng mga provider/partner na ito ay inihahatid sa pinanggalingan. .
Ang diagram ng test bench na ito ay ipinakita sa ibaba.
Ito ay isang mahusay na pagpipilian para sa amin. Ito ay lumiliko na ang pangalawang domain ay para din sa CF, na hindi nagdaragdag sa bilang ng mga solusyon na ginamit sa kumpanya, at halos hindi kumplikado sa imprastraktura.
Nagpatakbo kami ng mga pagsubok sa browser at ito ang nangyari:
Ang mga pulang diamante ay nabigo sa pagsubok. Ang mga file sa ibaba ay mga DNS error (resolve timeout). Ang mga pagkabigo sa itaas ay mga timeout.
Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s
Median, pagkatapos maalis ang pag-load reCAPTCHA (Na-block ang serbisyo ng Google sa China) mula 28 hanggang 18 segundo. Ngunit ang mga ito ay kakila-kilabot pa rin na mga resulta, kung isasaalang-alang na ang parehong pagsubok para sa semrush.com (mula sa US) ay nagbigay ng wala pang 10 segundo para sa 95% ng mga user (mula sa US) sa parehong pahina (static + dynamic).
Maaari kang pumunta sa bawat pagsubok at tumingin Talon at iba pang mas detalyadong mga parameter. Sinimulan naming siyasatin ang mga dahilan ng mga pagkakamali, at kung para sa mga pag-timeout ang lahat ay higit pa o hindi gaanong malinaw: ang Internet sa China ay "gumagalaw at lumabas", dahil dito ang bilis ng koneksyon at pag-load ng mga mapagkukunan mula sa ibang bansa ay hindi matatag at hindi pantay, pagkatapos ay ang mga DNS error ay lubhang nagulat sa amin. Natagpuan namin iyon PoP Ang Cloudflare ay aktwal na matatagpuan sa China, ang address ng site ay nagre-resolve sa isang anycast IP, ngunit ang mga DNS server ay Amerikano, kung kaya't ang mga kahilingan ng DNS ay napipilitang tumawid sa hangganan, kaya kung minsan ay nabigo sila.
Ang pagkakaroon ng paglilinaw sa tanong na ito sa CF, ito ay naging Wala silang sariling mga DNS server sa China, at kung kailan ito mangyayari ay hindi pa rin alam.
Samakatuwid, nagpasya kaming subukan lamang ang Cloudflare DNS at binago ang mekanismo ng pagpapatakbo ng Cloudflare para sa aming site sa "DNS lang" Ito ay isang mode kapag ang Cloudflare ay hindi nag-proxy ng trapiko sa pamamagitan ng sarili nito, na nangangahulugang hindi ito nagbibigay ng proteksyon ng DDoS, CDN at iba pang mga tampok, at gumagana sa mode ng isang regular na DNS server.
Ang stand na ito ay ipinapakita sa schematically sa sumusunod na figure. Isinasaalang-alang ng figure ang umuusbong na kaalaman na ang mga DNS server ng Cloudflare ay nasa likod ng isang firewall.
Sa Catchpoint nagpatakbo kami ng mga simpleng pagsubok sa GET (hindi mga pagsubok sa browser), na nagpakita ng maraming pagkabigo. Ang mga ito ay sanhi ng parehong mga error sa DNS.
Sinimulan naming i-debug ang mga error na ito gamit maghukay at nalaman na sa unang kahilingan ang address ay natukoy nang tama, at sa paulit-ulit na kahilingan natatanggap namin sa bawat oras SERVFAIL и hindi mahanap. Bakit biglaan ang nangyayari?
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)Walang ganoong mga error kapag direktang nagtatanong sa mga server ng Cloudflare NS:
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.192Nangangahulugan ito na ang problema ay nasa gilid ng "lokal" na DNS server o server ng provider.
Ang karagdagang pagsisiyasat ay nagsiwalat na SERVFAIL tayo ay nasa paglutas AAAA-mga talaan.
Ito pala kapag nagre-request kay Cloudflare AAAA-record na wala sa domain, tumugon ang Cloudflare А-isang entry na isang error at hindi pagsunod sa RFC. Bakit ang lokal na solver (xxxx) Hindi ko nagustuhan, at sumagot siya SERVFAIL. Ang pag-uugali na ito ay malinaw na nakikita sa log sa ibaba:
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
Nagsumite kami ng ulat ng bug sa Cloudflare, at inayos nila ito pagkaraan ng ilang oras. Ito ay naging kawili-wili: sa ngayon ay wala pa ring suporta sa IPv6 sa China, kaya hindi maibigay ng Cloudflare ang IPv6 address nito doon bilang tugon sa isang kahilingan AAAA-mga talaan. Sa huli, ang lahat ay nalutas sa paraang nagsimulang sumagot ang Cloudflare para sa China NODATA sa mga ganitong kahilingan.
Kaya, ang mga error sa DNS sa mga pagsubok sa Catchpoint ay bumaba nang husto, ngunit hindi ganap. Narito pa rin ang mga timeout:
At nagsimula kaming maghanap ng isa pang solusyon.
Sa susunod na bahagi ay sasabihin ko sa iyo kung paano namin sinubukan ang Chinese cloud Alibaba Cloud, paano, sa tulong ng kaunting "magic" ng Nginx, mabilis kaming nakagawa ng mga solusyon sa PoC (Proof of Concept), kung paano kami gumawa ng mga Multi-Cloud na solusyon, na isa sa mga ito ay lubos na nakatulong sa pagpapabilis ng gawain ng serbisyo mula sa China.
Manatiling nakatutok!
Mga susunod na bahagi
Pinagmulan: www.habr.com
