Hur vi bröt igenom Kinas stora brandvägg (del 3)

Hälsningar!
Alla bra historier tar slut. Och vår berättelse om hur vi kom fram till en lösning för att snabbt passera den kinesiska brandväggen är inget undantag. Därför skyndar jag mig att dela den sista med dig, den sista delen om detta ämne.

I förra delen pratade vi om många testbänkar som vi kom fram till och vilka resultat de gav. Och vi bestämde oss för vad som skulle vara trevligt att lägga till CDN! för viskositet i vårt system.

Jag ska berätta hur vi testade Alibaba Cloud CDN, Tencent Cloud CDN och Akamai, och vad vi slutade med. Och naturligtvis, låt oss sammanfatta.

Alibaba Cloud CDN

Vi finns på Alibaba Cloud och använder IPSEC och CEN från dem. Det vore logiskt att prova deras lösningar först.

Alibaba Cloud har två typer av produkter som kan passa oss: CDN и DCDN. Det första alternativet är ett klassiskt CDN för en specifik domän (underdomän). Det andra alternativet står för Dynamisk rutt för CDN (Jag kallar det dynamiskt CDN), det kan aktiveras i Full-site-läge (för jokerteckendomäner), det cachar även statiskt innehåll och accelererar dynamiskt innehåll på sig själv, det vill säga att sidans dynamik också laddas via leverantörens snabba nätverk. Detta är viktigt för oss, eftersom vår sida i grunden är dynamisk, den använder många underdomäner och det är bekvämare att sätta upp ett CDN en gång för "asterisken" - *.semrushchina.cn.

Vi hade redan sett den här produkten i de tidigare stadierna av vårt kinesiska projekt, men då fungerade den inte ännu, och utvecklarna lovade att produkten snart skulle bli tillgänglig för alla kunder. Och det gjorde han.

I DCDN kan du:

• konfigurera SSL-uppsägning med ditt certifikat,
• möjliggör acceleration av dynamiskt innehåll,
• flexibelt konfigurera cachning av statiska filer,
• rensa cachen,
• framåt webbuttag,
• aktivera komprimering och till och med HTML Beautifier.

I allmänhet är allt detsamma som med vuxna och stora CDN-leverantörer.

Efter att ursprunget (platsen dit CDN-kantservrarna kommer att gå) har specificerats, återstår bara att skapa ett CNAME för asterisken, med hänvisning till all.semrushchina.cn.w.kunluncan.com (denna CNAME togs emot i Alibaba Cloud-konsolen) och CDN kommer att fungera.

Baserat på testresultaten hjälpte denna CDN oss mycket. Statistiken visas nedan.

beslutet
Uptime
median
75 Percentil
95 Percentil

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

Det är mycket bra resultat, speciellt om man jämför dem med vad siffrorna var i början. Men vi visste att webbläsartestet för den amerikanska versionen av vår webbplats www.semrush.com körs från USA på i genomsnitt 8.3s (ett mycket ungefärligt värde). Det finns utrymme för förbättringar. Dessutom fanns det även CDN-leverantörer som var intressanta att testa.

Så vi går smidigt vidare till en annan jätte på den kinesiska marknaden - Tencent.

Tencent moln

Tencent håller just på att utveckla sitt moln – detta kan ses från ett litet antal produkter. När vi använde det ville vi testa inte bara deras CDN, utan också deras nätverksinfrastruktur som helhet:

• har de något som liknar CEN?
• Hur fungerar IPSEC för dem? Är det snabbt, vad är drifttiden?
• har de Anycast?

Låt oss titta på dessa frågor separat.

Analog CEN

Tencent har en produkt Cloud Connect-nätverk (CCN), så att du kan ansluta VPC:er från olika regioner, inklusive regioner inom och utanför Kina. Produkten är nu i intern beta, och du måste skapa en biljett som ber att få ansluta till den. Vi lärde oss från supporten att globala konton (vi pratar inte om kinesiska medborgare eller juridiska personer) inte kan delta i betatestprogrammet och i allmänhet koppla samman en region i Kina med en region utanför. 1-0 till Ali Clouds fördel

IPSEC

Tencents sydligaste region är Guangzhou. Vi monterade en tunnel och kopplade den till Hong Kong-regionen i GCP (då hade denna region redan blivit tillgänglig). Den andra tunneln i Ali Cloud från Shenzhen till Hong Kong höjdes också samtidigt. Det visade sig att via Tencent-nätverket är latensen till Hong Kong generellt sett bättre (10ms) än från Shenzhen till Hong Kong till Ali (120ms - vad?). Men detta påskyndade inte på något sätt arbetet med webbplatsen som syftade till att arbeta genom Tencent och denna tunnel, vilket i sig var ett fantastiskt faktum och återigen bevisade följande: latens - för Kina är detta inte en indikator som verkligen är värd uppmärksamma när man utvecklar en lösning för att passera den kinesiska brandväggen.

Anycast Internet Acceleration

En annan produkt som låter dig arbeta via anycast IP är AIA. Men det är inte heller tillgängligt för globala konton, så jag kommer inte att berätta om det, men att veta att en sådan produkt finns kan vara användbart.

Men CDN-testet visade några ganska intressanta resultat. Tencents CDN kan inte aktiveras på en fullständig webbplats, bara på specifika domäner. Vi skapade domäner och skickade trafik till dem:

Det visade sig att denna CDN har följande funktion: Optimering av gränsöverskridande trafik. Denna funktion bör minska kostnaderna när trafik passerar genom den kinesiska brandväggen. Som Ursprung IP-adressen för Google GLB (GLB anycast) angavs. Därför ville vi förenkla projektarkitekturen.

Resultaten var mycket bra - på nivå med Ali Cloud CDN, och på vissa ställen ännu bättre. Detta är förvånande, för om testerna är framgångsrika kan du överge en betydande del av infrastrukturen, tunnlar, CEN, virtuella maskiner, etc.

Vi gladde oss inte länge, eftersom ett problem avslöjades: tester i Catchpoint misslyckades för internetleverantören China Mobile. Från vilken plats som helst fick vi en timeout via Tencents CDN. Korrespondens med teknisk support ledde inte till någonting. Vi försökte lösa detta problem i ungefär en dag, men ingenting fungerade.

Jag var i Kina vid det tillfället, men kunde inte hitta offentligt Wi-Fi på nätverket för denna leverantör för att personligen verifiera problemet. Annars såg allt snabbt och bra ut.
Men på grund av det faktum att China Mobile är en av de tre största operatörerna, var vi tvungna att återföra trafik till Ali CDN.
Men totalt sett var detta en ganska intressant lösning som förtjänar längre testning och felsökning av detta problem.

Akamai

Den sista CDN-leverantören vi testade var Akamai. Detta är en enorm leverantör som har sitt nätverk i Kina. Naturligtvis kunde vi inte komma förbi det.

Redan från början kom vi överens med Akamai om en provperiod så att vi kunde byta domän och se hur det skulle fungera på deras nätverk. Jag kommer att beskriva resultatet av alla tester i form av "Vad jag gillade" och "Vad jag inte gillade", och jag kommer också att ge testresultaten.

Vad vi gillade:

• Killarna från Akamai var mycket hjälpsamma i alla frågor och följde med oss ​​i alla skeden av testningen. Vi försökte hela tiden förbättra något på vår sida. De gav bra tekniska råd.
• Akamai är cirka 10-15 % långsammare än vår lösning via Ali Cloud CDN. Vad som är imponerande är att vi i Origin för Akamai angav GLB:s IP-adress, vilket betyder att trafiken inte gick igenom vår lösning (potentiellt skulle vi kunna överge en del av infrastrukturen). Men ändå visade testresultaten att denna lösning är sämre än vår nuvarande version (jämförande resultat nedan).
• Testade både Origin GLB och Origin i Kina. Båda alternativen är ungefär desamma.
• Det finns Visst rutt (automatisk routingoptimering). Du kan vara värd för ett testobjekt på Origin, och Akamai Edge-servrarna kommer att försöka hämta det (vanligt GET). För dessa förfrågningar mäts hastighet och andra mätvärden, baserat på vilka Akamai-nätverket optimerar rutterna så att trafiken går snabbare för vår webbplats och det var tydligt att aktiveringen av denna funktion verkligen hade en stark inverkan på webbplatsens hastighet.
• Det är coolt att versionera konfigurationen i webbgränssnittet. Du kan göra Jämför för versioner, titta på diff. Se tidigare versioner.
• Du kan rulla ut en ny version först endast på Akamai Staging-nätverket - samma nätverk som produktion, bara detta sätt kommer inte att påverka verkliga användare. För detta test måste du förfalska DNS-poster på din lokala dator.
• Mycket snabb nedladdningshastighet genom deras nätverk för stora statiska filer och, tydligen, alla andra filer. En fil från den "kalla" cachen hämtas många gånger snabbare än samma fil från den "kalla" cachen hos Ali CDN. Från den "heta" cachen är hastigheten redan densamma, plus eller minus.

Ali CDN-test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
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
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
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

Vi märkte att situationen i exemplet ovan beror på olika faktorer. När jag skrev den här punkten körde jag testet igen. Resultaten för båda plattformarna var ungefär desamma. Detta säger oss att Internet i Kina, även för stora operatörer och molnleverantörer, beter sig olika från tid till annan.

Till föregående punkt ska jag lägga till ett stort plus för Akamai: om Ali visar liknande blixtar av hög prestanda och mycket låg prestanda (detta gäller Ali CDN, Ali CEN och Ali IPSEC), då Akamai, varje gång, oavsett hur jag testar deras nätverk, allt fungerar stabilt.
Akamai har en hel del täckning i Kina och arbetar via många leverantörer.

Vad gillade inte:

• Jag gillar inte webbgränssnittet och hur det fungerar - det är så dåligt. Men i princip vänjer man sig (förmodligen).
• Testresultaten är sämre än vår sida.
• Det finns fler fel under tester än på vår sida (upptid nedan).
• Vi har inga egna DNS-servrar i Kina. Därför finns det många fel i tester på grund av timeout för DNS-lösning.
• De tillhandahåller inte sina IP-intervall -> det finns inget sätt att registrera de korrekta set_real_ip_from på våra servrar.

Mätvärden (~3626 körningar; alla mätvärden utom Drifttid, i ms; statistik för en tidsperiod):

CDN-leverantör
median
75%
95%
Svar
Webbsidesvar
Uptime
DNS
Kontakta
Vänta
Ladda
SSL

AliCDN
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

Fördelning efter procent (i ms):

percentil
Akamai
AliCDN

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

Slutsatsen är denna: Akamai-alternativet är gångbart, men ger inte samma stabilitet och hastighet som vår egen lösning tillsammans med Ali CDN.

Små anteckningar

Vissa ögonblick fanns inte med i berättelsen, men jag skulle vilja skriva om dem också.

Peking + Tokyo och Hong Kong

Som jag sa ovan testade vi en IPSEC-tunnel till Hong Kong (HK). Men vi testade även CEN till HK. Det kostar lite mindre, och jag undrade hur det skulle fungera mellan städer med ett avstånd på ~100 km. Det visade sig vara intressant att latensen mellan dessa städer är 100ms högre än i vår originalversion (till Taiwan). Snabbhet, stabilitet var också bättre för Taiwan. Som ett resultat lämnade vi HK som en backup-IPSEC-region.

Dessutom försökte vi installera följande installation:

• uppsägning av kunder i Peking,
• IPSEC och CEN till Tokyo,
• i Ali CDN angavs servern i Peking som ursprung.

Detta schema var inte så stabilt, även om det i fråga om hastighet i allmänhet inte var sämre än vår lösning. Angående tunneln så har jag sett intermittenta fall även för CEN som borde ha varit stabilt. Därför återgick vi till det gamla schemat och demonterade denna iscensättning.

Nedan finns statistik över latens mellan olika regioner för olika kanaler. Kanske någon är intresserad av det.

IPsec
Ali cn-beijing <—> GCP asien-nordost1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

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

Allmän information om Internet i Kina

Som ett tillägg till problemen med Internet som beskrivs i början, i den första delen av artikeln.

• Internet i Kina är ganska snabbt inuti.
  • Slutsatsen drogs utifrån att testa offentliga Wi-Fi-nätverk på olika platser där dessa nätverk används av ett stort antal människor.
  • Nedladdnings- och uppladdningshastigheterna till servrar i Kina var cirka 20 Mbit/s respektive 5-10 Mbit/s.
  • Hastigheten till servrar utanför Kina är helt enkelt mager, mindre än 1 Mbit/s.
• Internet i Kina är inte särskilt stabilt.
  • Ibland kan webbplatser öppnas snabbt, ibland långsamt (vid samma tid på dagen olika dagar), förutsatt att konfigurationen inte ändras. Vi observerade detta med exemplet semrushchina.cn. Detta kan tillskrivas Ali CDN, som också fungerar så här och att beroende på tid på dygnet, stjärnornas position osv.
• Mobilt internet finns nästan överallt 4G eller 4G+. Fånga det i tunnelbanan, hissar - kort sagt, överallt.
• Det är en myt att kinesiska användare bara litar på domäner i .cn-zonen. Vi lärde oss detta direkt från användarna.
  • Du kan se hur http://baidu.cn omdirigera till www.baidu.com (även på det kinesiska fastlandet).
• Många resurser är verkligen blockerade. Primitiv: google.com, Facebook, Twitter. Men många Google-resurser fungerar (naturligtvis inte på alla Wi-Fi och VPN används inte (på routersidan också, det är säkert).
• Många "tekniska" domäner för blockerade företag fungerar också. Det betyder att du inte alltid bör vårdslöst skära bort alla Google och andra till synes blockerade resurser. Du måste leta efter en lista över förbjudna domäner.
• De har bara tre huvudsakliga internetoperatörer: China Unicom, China Telecom, China Mobile. Det finns ännu mindre, men deras marknadsandel är obetydlig

Bonus: slutlig lösningsdiagram

Totalt

Ett år har gått sedan projektet startade. Vi började med det faktum att vår sida i allmänhet vägrade att fungera normalt från Kina, och helt enkelt GET curl tog 5.5 sekunder.

Sedan, med dessa indikatorer i den första lösningen (Cloudflare):

beslutet
Uptime
median
75 Percentil
95 Percentil

CloudFlare
86.6
18s
30s
60s

Vi nådde så småningom följande resultat (statistik för den senaste månaden):

beslutet
Uptime
median
75 Percentil
95 Percentil

Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

Som du kan se har vi ännu inte kunnat uppnå 100% drifttid, men vi kommer på något, och sedan berättar vi om resultatet i en ny artikel :)

Respekt till dem som läser alla tre delar till slutet. Jag hoppas att du tyckte att allt detta var lika intressant som jag gjorde när jag gjorde det.

PS Tidigare delar

Часть 1
Часть 2

Källa: will.com