🥇Jak jsme prolomili Velký čínský firewall (č. 3)

Ahoj!
Každý dobrý příběh má svůj konec. A náš příběh o tom, jak jsme vyvinuli řešení pro rychlé překonání čínského firewallu, není výjimkou. Proto se s vámi chci podělit o jeho poslední část, závěrečná část na toto téma.

V předchozí části jsme hovořili o mnoha testovacích stupních, které jsme vytvořili, a jaké výsledky nám přinesly. A skončili jsme tím, že by nebylo špatné přidat CDN! pro lepší funkčnost v našem schématu.

Povím vám, jak jsme testovali Alibaba Cloud CDN, Tencent Cloud CDN a Akamai, a na čem jsme se nakonec rozhodli. No a samozřejmě shrneme.

Alibaba Cloud CDN

Hostujeme na Alibaba Cloud, používáme IPSEC a CEN od nich. Je logické, že bychom měli nejprve vyzkoušet jejich řešení.

Alibaba Cloud má dva typy produktů, které by nám mohly vyhovovat: CDN a DCDN. První varianta představuje klasický CDN pro konkrétní doménu (subdoménu). Druhá varianta se rozkládá jako Dynamic Route for CDN (nazývám to dynamický CDN), který lze použít v režimu Full-site (pro wildcard domény), také ukládá statické soubory do cache a urychluje dynamický obsah, což znamená, že dynamika stránky také bude načítána prostřednictvím rychlých sítí poskytovatele. To je pro nás důležité, protože máme převážně dynamický web, na kterém se používá mnoho subdomén, a lépe se nastavuje CDN jednou pro “hvězdičku” — *.semrushchina.cn.

Tento produkt jsme už viděli v dřívějších fázích našeho čínského projektu, ale tehdy ještě nefungoval, a vývojáři slíbili, že produkt brzy bude k dispozici pro všechny klienty. A stalo se.

V DCDN lze:

nastavit terminaci SSL se svým certifikátem,
zapnout akceleraci dynamického obsahu,
flexibilně nastavit cachování statických souborů,
provádět vymazání cache,
umožnit webové sockety,
zapnout kompresi a dokonce HTML Beautifier.

Obecně platí, že vše jak u velkých a dospělých CDN poskytovatelů.

Po určení-Origin (to místo, kam budou směřovat edge servery CDN) je potřeba vytvořit CNAME pro hvězdičku, která referencuje na all.semrushchina.cn.w.kunluncan.com (tento CNAME byl získán v konzoli Alibaba Cloud), a CDN začne fungovat.

Podle výsledků testů nám tento CDN hodně pomohl. Statistika je uvedena níže.

Řešení
Uptime
Medián
75. percentile
95. percentile

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

To jsou velmi dobré výsledky, zvlášť když je porovnáme s tím, jaké čísla byla na začátku. Ale věděli jsme, že prohlížečový test americké verze našeho webu www.semrush.com se průměrně spouští z USA za 8,3s (velmi přibližná hodnota). Je kam růst. O to víc, zůstali nám ještě CDN poskytovatelé, které bylo zajímavé otestovat.

Tak plynule přecházíme k dalšímu gigantu na čínském trhu — Tencent.

Tencent Cloud

Tencent své cloudové služby teprve rozvíjí — to je patrné z malého množství produktů. Při jeho použití jsme chtěli otestovat nejen jejich CDN, ale i celkově síťovou infrastrukturu:

mají něco podobného jako CEN?
jak u nich funguje IPSEC? Je to rychlé, jaká je dostupnost?
mají u nich Anycast?

Tyto otázky rozebereme jednotlivě.

Analog CEN

Tencent má produkt Cloud Connect Network (CCN), který umožňuje propojit VPC z různých regionů, včetně regionů uvnitř Číny a mimo ni. Produkt je nyní ve vnitřní beta fázi a je třeba vytvořit ticket s žádostí o připojení. Od podpory jsme se dozvěděli, že global-účty (nemluvíme o občanech Číny a právnických osobách) se nemohou účastnit beta testování a vůbec propojit region v Číně s regionem venku. 1-0 v prospěch Ali Cloud.

IPSEC

Nejjižnější region Tencentu je — Guangzhou. Vytvořili jsme tunel a spojili ho s regionem Hongkong v GCP (ten region byl již dostupný). Zároveň jsme také zvedli druhý tunel v Ali Cloud z Shenzhenu do Hongkongu. Ukázalo se, že přes síť Tencent je latence do Hongkongu obecně lepší (10ms) než ze Shenzhenu do Hongkongu v Ali (120ms — co?). Ale to nijak nezrychlilo práci webu, který byl nasměrován na práci přes Tencent a tento tunel, což samo o sobě bylo překvapující a znovu dokazovalo následující: latence — pro Čínu to není ukazatel, na který skutečně stojí za to se zaměřit při vývoji řešení pro překonání čínské firewallu.

Anycast Internet Acceleration

Další produkt, který umožňuje pracovat přes anycast IP — AIA. Ale není také dostupný pro globální účty, takže o něm nebudu vyprávět, ale může být užitečné vědět, že takový produkt existuje.

Test CDN však ukázal docela zajímavé výsledky. CDN od Tencentu nelze aktivovat na full-site, pouze na konkrétních doménách. Založili jsme domény a pustili na ně provoz:

Ukázalo se, že tento CDN má tuto funkci: Optimalizace mezinárodního provozu. Tato funkce by měla snižovat náklady na průchod provozu čínskou firewallovou sítí. Jako původní byla uvedena IP adresa Googlového GLB (GLB anycast). Tímto způsobem jsme chtěli zjednodušit architekturu projektu.

Výsledky byly velmi dobré — na úrovni Ali Cloud CDN, a místy dokonce i lepší. Je to překvapující, protože v případě úspěšných testů bychom se mohli vzdát významné části infrastruktury, tunelů, CEN, virtuálních serverů apod.

Radovali jsme se však jen krátce, neboť se objevila problém: testy v Catchpoint selhávaly pro poskytovatele internetových služeb China Mobile. Z jakýchkoli lokalit jsme dostávali timeout přes CDN Tencent. Komunikace s technickou podporou nebyla k ničemu. Asi den jsme se snažili tento problém vyřešit, ale nic se nepodařilo.

V té době jsem byl v Číně, ale nedokázal jsem najít veřejnou Wi-Fi síť tohoto poskytovatele, abych se na problém podíval osobně. Jinak vše vypadalo rychle a dobře.
Avšak vzhledem k tomu, že operátor China Mobile patří mezi tři největší operátory, byli jsme nuceni vrátit provoz na Ali CDN.
Celkově však bylo toto řešení poměrně zajímavé a zaslouží si delší testování a řešení této problému.

Akamai

Posledním CDN poskytovatelem, kterého jsme testovali, je Akamai. Je to obrovský poskytovatel, který má svou síť v Číně. Samozřejmě, že jsme jej nemohli opominout.

Od samého začátku jsme se s Akamai dohodli na zkušební době, abychom mohli přepnout doménu a sledovat, jak bude fungovat v jejich síti. Výsledky všech testů popíšu ve formě "Co se nám líbilo" a "Co se nám nelíbilo", a také uvedu výsledky testů.

Co se nám líbilo:

Chlapci z Akamai byli velmi nápomocní ve všech otázkách a podporovali nás na všech etapách testování. Neustále se snažili něco zlepšit na své straně. Dávali dobré technické rady.
Akamai funguje přibližně o 10-15 % pomaleji než naše řešení přes Ali Cloud CDN. Úžasné je, že v případě Akamai jsme uváděli IP adresu GLB, což znamená, že provoz nešel přes naše řešení (potenciálně se lze vzdát části infrastruktury). Nicméně výsledky testů ukázaly, že tato varianta řešení je horší než naše aktuální varianta (srovnávací výsledky viz níže).
Testoval se jak Origin GLB, tak původ v Číně. Obě varianty jsou přibližně stejné.
Existuje Sure Route (automatizované optimalizace směrování). Můžete si umístit testovací objekt na Origin, a Edge servery Akamai se ho pokusí vyzvednout (běžný GET). Pro tyto žádosti se měří rychlost a další metriky, na jejichž základě síť Akamai optimalizuje trasy, aby provoz směřoval rychleji na naše stránky a bylo jasné, že aktivace této funkce skutečně významně ovlivnila rychlost práce webu.
Verzování konfigurace v webovém rozhraní je skvělé. Můžete provést porovnání verzí, podívat se na rozdíly. Podívat se na předchozí verze.
Novou verzi lze nejprve nasadit pouze na Staging síť Akamai — je to stejná síť jako produkční, ale tento postup nemá vliv na skutečné uživatele. Pro tento test je nutné provést spoofing DNS záznamů na místním počítači.
Velmi rychlá rychlost načítání přes jejich síť velké statiky, a pravděpodobně jakýchkoli jiných souborů. Soubor z "chladného" cache se vybírá mnohem rychleji než stejný soubor z "chladného" cache Ali CDN. Ze "horkého" cache je rychlost už víceméně stejná.

Ali CDN test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Celkem    % Přijato % Přenosu  Průměrná Rychlost   Čas    Čas     Čas  Aktuální
                                 Stahování  Nahrávání   Celkem   Stráveno    Zbývá  Rychlost
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/s

Akamai test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Celkem    % Přijato % Přenosu  Průměrná Rychlost   Čas    Čas     Čas  Aktuální
                                 Stahování  Nahrávání   Celkem   Stráveno    Zbývá  Rychlost
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/s

Všimli jsme si, že situace z výše uvedeného příkladu závisí na různých faktorech. V době psaní tohoto bodu jsem provedl test znovu. Výsledky pro obě platformy byly přibližně stejné. To nám říká, že internet v Číně, i pro velké operátory a cloudové poskytovatele, se občas chová různě.

Ke předchozímu bodu přidávám velké plus pro Akamai: zatímco u Ali jsou viditelné skoky vysokého výkonu a velmi nízké latence (to platí jak pro Ali CDN, tak pro Ali CEN a Ali IPSEC), u Akamai pokaždé, když testuji jejich síť, všechno funguje stabilně.
Akamai skutečně má velké pokrytí v Číně a spolupracuje s mnoha poskytovateli.

Co se mi nelíbilo:

Nelíbí se mi webové rozhraní a pracovní schéma - jsou naprosto základní. Ale v zásadě si na to člověk zvykne (asi).
Výsledky testů jsou horší než na naší platformě.
Chybovost při testech je vyšší než na naší platformě (uptime je nižší).
Nemají vlastní DNS servery v Číně. Odtud pochází mnoho chyb v testech kvůli timeoutům při resolvování DNS.
Neposkytují své IP rozsahy -> není možnost zapisovat správně set_real_ip_from na našich serverech.

Metodika (~3626 běhů; všechny metriky kromě Uptime v ms; statistika za jedno časové období):

CDN poskytovatel
Medián
75%
95%
Odpověď
Odpověď webové stránky
Uptime
. Vytvořte A-záznam blog a určete pro něj nějakou fiktivní IP (to je oficiální
Připojení
Čekání
Načtení
SSL

Ali CDN
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

Rozdělení podle Percentilu (v ms):

Percentil
Akamai
Ali CDN

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

Závěr je takový: varianta s Akamai je životaschopná, ale nedává stejné ukazatele stability a rychlosti jako naše vlastní řešení v kombinaci s Ali CDN.

Malé poznámky

Některé body nebyly zařazeny do vyprávění, ale chtěl bych o nich napsat také.

Peking + Tokio a Hongkong

Jak jsem již zmínil výše, testovali jsme IPSEC tunel do Hongkongu (HK). Ale také jsme testovali CEN do HK. Stojí o něco méně a bylo zajímavé, jak bude fungovat mezi městy vzdálenými ~100 km. Zajímavé bylo, že latence mezi těmito městy byla o 100 ms vyšší než v naší původní variantě (do Tchaj-wanu). Rychlost a stabilita byly také lepší pro Tchaj-wan. Nakonec jsme ponechali HK jako záložní region IPSEC.

Kromě toho jsme zkusili nastavit takovou instalaci:

terminace klientů v Pekingu,
IPSEC a CEN do Tokia,
v Ali CDN byl uveden jako origin server v Pekingu.

Toto schéma nebylo tak stabilní, i když rychlostí v zásadě nijak nevyčnívalo proti našemu řešení. Co se tunelu týče, viděl jsem občasné výpadky, i když by měl být CEN stabilní. Proto jsme se vrátili k původnímu schématu a zrušili tuto stage.

Níže uvádím statistiky o latenci mezi různými regiony podle různých kanálů. Možná to bude někoho zajímat.

IPsec
Ali cn-beijing GCP asia-northeast1 — 193ms
Ali cn-shenzhen GCP asia-east2 — 91ms
Ali cn-shenzhen GCP us-east4 — 200ms

CEN
Ali cn-beijing Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms

Obecné informace o internetu v Číně

Jako doplněk k problémům s internetem popsaným na začátku, v první části článku.

Internet v Číně funguje poměrně rychle uvnitř.
- Závěr je založen na testování veřejných Wi-Fi sítí na různých místech, kde jsou tyto sítě používány velkým počtem lidí.
- Rychlost stahování a nahrávání na servery uvnitř Číny byla přibližně 20 Mbit/s a 5-10 Mbit/s respektive.
- Rychlost k serverům mimo Čínu je prostě zanedbatelná, méně než 1 Mbit/s.
Internet v Číně není příliš stabilní.
- Někdy se webové stránky mohou otvírat rychle, někdy pomalu (ve stejnou dobu dne v různé dny), za předpokladu, že se konfigurace nemění. To jsme pozorovali na příkladu semrushchina.cn. Může to být přičítáno Ali CDN, který také funguje tak nebo onak v závislosti na čase dne, poloze hvězd atd.
Mobilní internet prakticky všude 4G nebo 4G+. Funguje v metru, výtazích — zkrátka všude.
To, že čínští uživatelé věří pouze doménám v zóně .cn, je mýtus. Zjistili jsme to přímo od uživatelů.
- Můžete vidět, jak http://baidu.cn přesměrovává na www.baidu.com (také v pevninské Číně).
Mnoho zdrojů je skutečně blokováno. Zjednodušeně: google.com, Facebook, Twitter. Ale mnoho googleových zdrojů funguje (samozřejmě, ne na všech Wi-Fi a VPN není použita (na straně routeru také, to je jisté).
Mnoho 'technických' domén blokovaných korporací také funguje. To znamená, že není vždy nutné nezodpovědně odstraňovat všechny google a další zdánlivě blokované zdroje. Je třeba hledat nějaký seznam zakázaných domén.
Mají pouze tři hlavní internetové operátory: China Unicom, China Telecom, China Mobile. Existují i menší, ale jejich podíl na trhu je nepatrný.