ProHoster > Blog > Administracija > Kako smo probijali Veliki Kineski Vatrozid (č.1)

Kako smo probijali Veliki Kineski Vatrozid (č.1)

Pozdrav svima!

Na vezi je Nikita — sustavni inženjer iz tvrtke SEMrush. Danas ću vam pričati o tome kako smo se suočili s izazovom osiguravanja stabilnosti rada naše usluge semrush.com u Kini, te s kakvim smo se problemima susreli tijekom tog procesa (uzimajući u obzir lokaciju našeg podatkovnog centra na istočnoj obali SAD-a).

Ovo će biti velika priča podijeljena na nekoliko članaka. Ispričat ću vam kako je sve bilo kod nas: od potpuno nefunkcionalne usluge iz Kine, do performansi usluge na razini američke verzije za Amerikance. Obavještavam vas, bit će zanimljivo i korisno. Idemo.

Problemi kineskog interneta

Čak je i netko tko nije upoznat sa specifičnostima mrežnog upravljanja barem jednom čuo za Veliki kineski vatrozid. Uuuu, zvuči kul, zar ne? No, što je to, kako zapravo funkcionira — pitanje je prilično složeno. Na internetu možete pronaći mnogo članaka koji se bave tim, ali s tehničke strane, struktura ovog vatrozida nigdje nije opisana. Što, usput budi rečeno, nije iznenađujuće. Iskreno, nakon godine dana rada neću moći točno reći kako on funkcionira, no mogu podijeliti svoja zapažanja i praktične zaključke. I započet ćemo s glasinama o tom vatrozidu.

Postoji mnogo glasina o tom vatrozidu. Hajde da skupimo glavne i najzanimljivije od njih na jedan popis:

  • Google, Facebook, Twitter i drugi slični servisi su blokirani i ne rade u Kini.
  • Svaki promet koji ide IZ Kine i U Kinu, analiziraju se i ograničavaju pomoću strojnog učenja (u slučaju sumnjivog prometa), što značajno usporava taj promet koji prolazi granicu.
  • Kineske obavještajne službe mogu hakirati svaki šifrirani promet koji prolazi kroz njihov vatrozid.
  • VPN tuneli, IPSEC tuneli su nestabilni, često padaju i neprestano se blokiraju.
  • Što je jednostavnije šifriranje, to je jednostavnija pass fraza korištena za autentifikaciju/šifru prometa, brže prolazi kroz kineski vatrozid.

Evo što smo uspjeli saznati o tim glasinama:

  • Google, Facebook, Twitter i drugi slični servisi su zaista blokirani (vaš KO), no mnoge tehničke domene Googlea, primjerice, nisu blokirane i funkcionišu (isti gstatic.com). Iz toga slijedi zaključak: ne treba bezumno uklanjati sve Googleove i druge, naizgled blokirane, resurse.
  • Svaki promet koji prolazi granicu zaista povećava vrijeme kašnjenja. Pogledajte dvije rezultate. Jedna web stranica, jedna stranica, jednostavan GET curl’om. Prvo mjerenje iz Kine (predivan grad Shenzhen). Drugo mjerenje izvana iz Hong Konga (ima suverenitet, i između njega i svijeta nema vatrozida). Udaljenost između gradova u pravoj liniji je otprilike 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/s

Obratite pažnju na time_connect. I općenito, vidite rezultat: vatrozid dodaje 4 dodatne sekunde, što je katastrofalno sporo.

  • VPN i IPSEC tuneli često ispadaju. O tome ću pričati malo kasnije i detaljnije. VPN serveri koje koriste korisnici, s vremenom se blokiraju (obično unutar jednog dana nakon početka korištenja).
  • Postoji mišljenje, koje dolazi od ljudi koji žive u Kini, da što je enkripcija prometa jednostavnija, to brže prolazi kroz granicu, jer je lako shvatiti da u njemu nema ništa protuzakonito. I isto tako 'čisti' promet dobiva više propusnosti i brzine prolaza, dok 'prljavi' promet, u kojem ništa nije prepoznatljivo, dobiva suprotno sporiji prolaz. Kao primjer, spomenut ću curl do ifconfig.co putem HTTPS i HTTP protokola. 

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/s

Razlika od 5 sekundi u ukupnom vremenu učitavanja 13 bajtova. Čineći ovaj test nekoliko puta, može se primijetiti da GET na HTTP obično traje otprilike isto vrijeme svaki puta, dok na HTTPS stranica ponekad odgovara za 3, 5, 10, pa čak i 17 sekundi. Ponekad se javljaju SSL greške:

Nepoznata SSL protokol greška u vezi s ifconfig.co:443.

Dakle, šta imamo:

  • Problemi uzrokovani kineskim vatrozidom, opisani iznad.
  • Pingovi do vanjskih resursa i unutar tunela ponekad nestaju.
  • Latencija između dvije tačke stalno se mijenja, a često je jednostavno nepredvidiva. Povezujući različite gradove/regije, očekuješ da će, obzirom na geografski položaj regiona, kašnjenje biti manje, a zapravo dobiješ potpuno suprotnu situaciju.
  • Internet i komunikacijski kanali rade ponekad brzo, ponekad sporo. Tu postoji mala zavisnost od doba dana i dana u tjednu, ali ne uvijek.
  • DNS upiti prema vanjskom svijetu iz Kine nekad prelaze dopušteno vreme.

Slika se čini „izvrsnom”.

Data centar, kao što sam već rekao, nalazi se na istoku SAD-a, a cijeli SEMrush se sastoji od desetaka međusobno povezanih proizvoda, backend-a, frontend-a, baza podataka, i sve to u DC-u i oblačnim sistemima. Pred nama, kao timu sistemskih administratora, postavljen je zadatak da brzo počnemo raditi u Kini s minimalnim naporima.

Morali smo odgovoriti na važno pitanje: možemo li proći s malim naporima i riješiti sve probleme povezane s kineskim internetom i vatrozidom na razini mreže/oblaka/servera?

Započeli smo s dobivanjem ICP- dozvole.

ICP dozvola

Da bismo imali mogućnost postavljanja svoje usluge unutar Kine (mainland China) i provođenja testova, prvo je potrebno dobiti ICP dozvolu za domenu.

Ako je korisnički promet vaše web stranice preusmjeren unutar Kine, a vaš domen nema ICP licencu, vaš promet će biti blokiran od strane davatelja usluga/hosting provajdera. Zanimljivo je da u ICP licencu ulazi određeni davatelj, bilo da je to Cloudflare ili Alibaba Cloud. Stoga, ako ste dobili ICP licencu za Cloudflare i hostali svoju web stranicu kod njih, kasnije se nećete moći "besprijekorno" preseliti na Alibaba Cloud. Bit ćete primorani dodati još jednog hosting pružatelja u tu licencu.

Nakon što smo dobili ICP licencu za domen, mogli smo smišljati i provoditi konkretne tehničke ideje i rješenja.

Testiranje rješenja

No, prije nego što započnemo s izradom varijanti za staging, podešavanjem, optimizacijom rada i brzine web stranice, potrebno je odabrati alat za testiranje kako bismo vidjeli koje naše akcije poboljšavaju ili, naprotiv, pogoršavaju rad web stranice.

Naš alat za testiranje morao je ispunjavati dva glavna zahtjeva:

  • mora imati mogućnost pokretanja testova iz Kine,
  • mora imati testove preglednika.

Tako smo pronašli Catchpoint! Imaju izvrsno pokriće točkama testiranja širom svijeta. U Kini putem ovog alata također možete pokretati testove iz 100500 provincija. U svakoj nekoliko različitih davatelja + mogućnost izvođenja Backbone-testova (nešto poput virtualke u data centru) i Lastmile-testova (maksimalno približeni korisničkim uvjetima, aka radna stanica). Posljednja vrsta testova je skuplja.

Potpisavši godišnji ugovor (manje se ne može), započeli smo s proučavanjem alata. Moram priznati da smo bili ugodno iznenađeni njegovim funkcionalnostima. Možete pokretati:

  • DNS testove,
  • Web testove (pretraživačke, jednostavni GET/POST, emulacija mobilnog klijenta itd.),
  • Transakcijske provjere (npr. prijava),
  • API testove,
  • Ping, traceroute, NTP itd.

Sve to nije moguće pobrojati. I što je najvažnije, svaki test se može dobro prilagoditi, dodajući paket zaglavlja i drugih parametara. Na izlazu se dobiva ogromna količina informacija koja potpuno opisuje vaš test. Kada govorimo o najzanimljivijem za nas (testovi preglednika), rezultati uključuju:

  • Connect, Wait, Load, SSL, DNS vrijeme,
  • TTFB, TTLB, Dokument završeno, Vrijeme renderiranja, DOM učitavanje,
  • Odgovor (nešto slično vremenu do prvog bajta), Odgovor web stranice (nešto slično vremenu do posljednjeg bajta),
  • Bilo koji percentil, Prosjek, Medijan vremena
  • I slično.

Stoga, sve te metrike pomažu u praćenju promjena i razumijevanju je li situacija poboljšana. Mi smo se uglavnom fokusirali na Response, Webpage Response, Median, 75 i 95 Percentiles.

Važno pitanje koje se postavljalo od samog početka: može li se vjerovati Catchpointu?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
To je veliki problem jer je gotovo nemoguće pouzdano utvrditi kako web stranica iz Kine radi dok ste u Rusiji. Kada radite socks-proxy kroz virtualnu mašinu, na izlazu dobijete učitavanje stranice koje traje nekoliko minuta, što je jednostavno neprihvatljivo za testove, stoga jedina opcija za ručno testiranje ostaje curl i jednostavni GET iz konzole uz mjerenje vremena. To pomaže, jer ovaj test dobro odražava brzinu mrežnog rješenja, a ako imate i testove u pregledniku, to je još bolje.

Kasnije smo sami otišli u Kinu i uvjerili se da Catchpointu se može vjerovati, pouzdano odražava stvarne brzinske pokazatelje.

Cloudflare China Network

Pošto za glavni domen semrush.com uspješno koristimo Cloudflare, odlučili smo odmah isprobati njihovu opciju pod nazivom China Network. Ova opcija se aktivira samo za Enterprise sajtove na poseban zahtjev i uz dodatnu naknadu. Također, dostupna je samo za sajtove koji imaju odgovarajuću ICP licencu, u kojoj je Cloudflare naveden kao pružatelj usluga. Nakon njenog uključivanja, za sajt postaje dostupan “kineski CDN” od Cloudflare — promet iz kineskih regija slijeće u najbliže PoP (Points of Presence) CF, a zatim se već preko njihovih mreža ili mreža partnera isporučuje do origina.

Shema ovog testnog okruženja prikazana je u nastavku.

Za nas je to izvrsna opcija. Očigledno, drugi domen će također biti iza CF, što ne povećava broj rješenja koja se koriste u kompaniji, a također gotovo ne komplicira infrastrukturu.

Pokrenuli smo testove u pregledniku i evo što smo dobili:

Crveni rombovi — to su neuspjesi testova. Neuspjesi dolje — DNS greške (resolve timeout). Neuspjesi gore — vremenska ograničenja.

Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s

Medijan, nakon što je uklonjena učitavanje reCaptcha (usluga Googlea, blokirana u Kini), smanjila se s 28 na 18 sekundi. Ipak, to su strašni pokazatelji, ako se uzme u obzir da je isti test za semrush.com (iz SAD-a) davao manje od 10 sekundi za 95% korisnika (iz SAD-a) na istoj stranici (statika + dinamika).

U svakom testu možete ući i pogledati Waterfall i drugi detaljniji parametri. Počeli smo istraživati uzroke grešaka, a dok su za timeoutove sve više-manje jasne: internet u Kini “odjednom radi, odjednom ne radi”, zbog čega je brzina povezivanja i učitavanja resursa iz inostranstva nestabilna i neujednačena, DNS greške su nas jako iznenadile. Otkrili smo da PoP usluge Cloudflare zaista se nalaze u Kini, adresa web stranice razdvaja se na jedan anycast IP, ali se koriste američki DNS serveri, zbog čega DNS upiti moraju prolaziti kroz granicu, pa zato ponekad ne uspevaju.

Razjasnivši ovo pitanje s CF, saznali smo da nemaju svoje DNS servere u Kini, a kada će ih biti — za sada nije poznato.

Zbog toga smo odlučili testirati samo DNS Cloudflare i promenili mehanizam rada Cloudflare za našu web stranicu na režim “Samo DNS”. To je režim kada Cloudflare ne proksira saobraćaj kroz sebe, što znači da ne pruža DDoS zaštitu, CDN i druge funkcije, i radi u režimu običnog DNS servera.

Ova postavka je shematski predstavljena na sledećem crtežu. Na crtežu su uzeta u obzir nova saznanja o tome da su DNS serveri Cloudflare iza firewall-a.

U Catchpointu smo pokrenuli jednostavne GET testove (ne brauzerske), koji su pokazali mnogo grešaka. Uzrok im je bila ista ona DNS greška.

Počeli smo debagirati te greške uz pomoć dig i otkrili da se prilikom prvog upita adresa ispravno određuje, dok prilikom ponovnog upita svaki put dobijamo SERVFAIL i not found. Odakle to odjednom?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ima adresu 220.170.186.192
Host semrushchina.cn nije pronađen: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ima adresu 220.170.186.192
Host semrushchina.cn nije pronađen: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ima adresu 220.170.186.192
Host semrushchina.cn nije pronađen: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ima adresu 220.170.186.192
Host semrushchina.cn nije pronađen: 2(SERVFAIL)

Prilikom upita NS servera Cloudflare direktno takvih grešaka nema:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Korišćenje servera domene:
Ime: ray.ns.cloudflare.com.
Adresa: 173.245.59.138#53
Alias:

semrushchina.cn ima adresu 220.170.186.192
semrushchina.cn ima adresu 220.170.186.192
Korišćenje servera domene:
Ime: ray.ns.cloudflare.com.
Adresa: 173.245.59.138#53
Alias:

semrushchina.cn ima adresu 220.170.186.192
semrushchina.cn ima adresu 220.170.186.192

Znači, problem je na strani “lokalnog” DNS servera ili servera provajdera.
Dalje istraživanje pokazalo je da SERVFAIL dobijamo na razrešavanju AAAA-zapisa.

Ispostavilo se da prilikom upita kod Cloudflare AAAAA-zapisi koja ne postoji u domeni, Cloudflare je odgovarao A-zapisanjem, što predstavlja grešku i nesklad s RFC-om. Zbog toga lokalnom rezolveru (x.x.x.x) to se nije svidjelo, pa je odgovarao SERVFAIL. U donjem logu ovo ponašanje je jasno vidljivo:

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

Poslali smo bug-izvještaj Cloudflareu, i oni su to ispravili nakon nekog vremena. Ispalo je zanimljivo: trenutno u Kini još uvijek nema podrške za IPv6, pa Cloudflare nije mogao pružiti svoj IPv6 adresu u odgovoru na zahtjev AAAAA-zapise. Na kraju je sve riješeno tako da je Cloudflare za Kinu počeo odgovarati NODATA na takve zahtjeve.

Tako su DNS greške u Catchpoint testovima drastično smanjene, ali ne do kraja. Tajmeri također nisu nestali:

I počeli smo tražiti drugo rješenje.

U sljedećem dijelu ću govoriti o tome kako smo testirali kineski Cloud Alibaba Cloud, kako smo uz pomoć male "magije" Nginx-a mogli brzo stvoriti PoC (Proof of Concept) rješenja, kako smo stvorili Multi-Cloud rješenja, od kojih je jedno na kraju značajno pomoglo ubrzanju usluge iz Kine.

Ostanite s nama!

Sljedeći dijelovi

Dio 2

Izvor: habr.com

Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere 🔥 Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere | ProHoster