🥇Hoe we door de Grote Chinese Firewall breken (deel 3)

Hallo!
Alle goede verhalen komen tot een einde. En ons verhaal over hoe we een oplossing hebben bedacht voor de snelle doorgang door de Chinese firewall is daar geen uitzondering op. Daarom haast ik me om jullie het laatste deel te delen, het afsluitende deel over dit onderwerp.

In het vorige deel hebben we gesproken over de vele teststandaarden die door ons zijn bedacht en welke resultaten ze hebben opgeleverd. We stopten bij de overweging om CDN toe te voegen! voor de consistentie in onze opstelling.

Ik zal jullie vertellen hoe we Alibaba Cloud CDN, Tencent Cloud CDN en Akamai hebben getest en waar we uiteindelijk op zijn overgestapt. En natuurlijk zullen we een samenvatting geven.

Alibaba Cloud CDN

We hosten bij Alibaba Cloud, maken gebruik van IPSEC en CEN van hen. Het is logisch om eerst hun oplossingen te proberen.

Alibaba Cloud heeft twee soorten producten die voor ons geschikt kunnen zijn: CDN en DCDN. De eerste optie is een klassieke CDN voor een specifiek domein (subdomein). De tweede optie staat voor Dynamic Route for CDN (ik noem het dynamische CDN), kan worden ingeschakeld in Full-site modus (voor wildcard-domeinen), het cachet ook statische content en accelereert de dynamische content, wat betekent dat de dynamiek van de pagina ook zal worden geladen via de snelle netwerken van de provider. Dit is belangrijk voor ons, omdat onze site voornamelijk dynamisch is, met veel subdomeinen, en het is handiger om het CDN één keer in te stellen voor de “ster” — *.semrushchina.cn.

We hebben dit product al eerder gezien in de vroege fasen van ons Chinese project, maar toen werkte het nog niet, en de ontwikkelaars beloofden dat het product binnenkort voor alle klanten beschikbaar zou zijn. En het is nu beschikbaar.

Met DCDN kun je:

de SSL-terminatie met je eigen certificaat instellen,
de acceleratie van dynamische content inschakelen,
de caching van statische bestanden flexibel instellen,
cachepurge uitvoeren,
websockets doorsturen,
compressie inschakelen en zelfs HTML Beautifier gebruiken.

Kortom, alles zoals bij volwassen en grote CDN-providers.

Nadat de Origin (de plaats waar de CDN edge servers naartoe zullen gaan) is opgegeven, moet er een CNAME voor de ster worden aangemaakt die verwijst naar all.semrushchina.cn.w.kunluncan.com (deze CNAME is verkregen in de Alibaba Cloud-console), en de CDN zal werken.

Volgens de testresultaten heeft deze CDN ons enorm geholpen. De statistieken worden hieronder weergegeven.

Oplossing
Uptime
Mediaan
75 percentiel
95 percentiel

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

Dit zijn zeer goede resultaten, vooral als je ze vergelijkt met de cijfers die in het begin waren. Maar we wisten dat de browser test van de Amerikaanse versie van onze website www.semrush.com gemiddeld 8,3 seconden in de VS uitvoert (een zeer benaderende waarde). Er is nog ruimte voor verbetering. Bovendien waren er ook CDN-providers die we interessant vonden om te testen.

Zo gaan we soepel over naar een andere gigant op de Chinese markt — Tencent.

Tencent Cloud

Tencent ontwikkelt zijn cloud nog steeds — dat is te zien aan het kleine aantal producten. Tijdens het gebruik ervan wilden we niet alleen hun CDN testen, maar ook de netwerkinfrastructuur in het algemeen:

hebben ze iets vergelijkbaars met CEN?
hoe werkt IPSEC bij hen? Is het snel, wat is de uptime?
hebben ze Anycast?

Laten we deze vragen afzonderlijk bespreken.

Een soortgelijk product als CEN

Tencent heeft een product Cloud Connect Network (CCN), waarmee je VPC's uit verschillende regio's met elkaar kunt verbinden, inclusief regio's binnen en buiten China. Het product is momenteel in een interne bèta, en je moet een ticket aanmaken om je aan te sluiten. Van de support vernamen we dat global-accounts (het gaat niet om burgers van China en niet om juridische entiteiten) niet kunnen deelnemen aan het bèta-testprogramma en in het algemeen niet regio's binnen China kunnen verbinden met regio's daarbuiten. 1-0 voor Ali Cloud.

IPSEC

De meest zuidelijke regio bij Tencent is — Guangzhou. We hebben een tunnel opgezet en deze verbonden met de Hongkong-regio in GCP (toen was deze regio al beschikbaar). Tegelijkertijd hebben we ook een tweede tunnel in Ali Cloud opgezet van Shenzhen naar Hongkong. Het bleek dat de latentie via het Tencent-netwerk over het algemeen beter was (10 ms) dan van Shenzhen naar Hongkong via Ali (120 ms — wat?). Maar dit versnelde de werking van de website niet, gericht op het werken via Tencent en deze tunnel, wat op zich een verbazingwekkend feit was en nogmaals bewees: latentie — voor China is dit geen indicator waar je echt rekening mee moet houden tijdens de ontwikkeling van een oplossing voor het passerende Chinese firewall.

Anycast Internet Acceleration

Een ander product dat werkt via anycast IP — AIA. Maar het is ook niet beschikbaar voor globale accounts, dus ik kan er niet veel over zeggen, maar weten dat dit product bestaat, kan nuttig zijn.

De CDN-test toonde echter vrij interessante resultaten. De CDN van Tencent kan niet op full-site worden ingeschakeld, alleen op specifieke domeinen. We hebben domeinen aangemaakt en verkeer erop geleid:

Het bleek dat deze CDN zo'n functie heeft: Optimalisatie van grensoverschrijdend verkeer. Deze functie zou de kosten voor het verkeer dat door de Chinese firewall gaat, moeten verlagen. Als Origin IP-adres van de Google GLB (GLB anycast) werd opgegeven. Op deze manier wilden we de architectuur van het project vereenvoudigen.

De resultaten waren zeer goed — op het niveau van Ali Cloud CDN, en soms zelfs beter. Dit is verrassend, want bij succesvolle tests kunnen we een aanzienlijk deel van de infrastructuur, tunnels, CEN, virtuele servers, enz. achterwege laten.

We waren niet lang blij, aangezien er een probleem opdook: de tests in Catchpoint faalden voor de internetprovider China Mobile. Vanaf elke locatie kregen we een time-out via de CDN van Tencent. Correspondentie met de technische ondersteuning leidde tot niets. We hebben ongeveer een dag geprobeerd dit probleem op te lossen, maar het lukte ons niet.

Op dat moment was ik in China, maar ik kon geen openbaar Wi-Fi-netwerk van deze provider vinden om het probleem persoonlijk te verifiëren. Verder leek alles snel en goed te werken.
Echter, omdat China Mobile een van de drie grootste operators is, waren we gedwongen om het verkeer terug te sturen naar Ali CDN.
Maar al met al was dit een vrij interessante oplossing die verdere testing en troubleshooten van dit probleem verdient.

Akamai

De laatste CDN-provider die we hebben getest is Akamai. Dit is een enorme provider die zijn netwerk in China heeft. Natuurlijk konden we niet om hen heen.

Vanaf het begin spraken we met Akamai af voor een testperiode, zodat we het domein konden omzetten en konden zien hoe het presteert op hun netwerk. De resultaten van de testen zal ik beschrijven in de vorm van 'Wat goed was' en 'Wat niet goed was', evenals de testresultaten.

Wat goed was:

De mensen van Akamai hielpen ons enorm bij alle vragen en begeleidden ons tijdens alle testfasen. Ze probeerden voortdurend iets te verbeteren aan hun kant. Ze gaven goede technische adviezen.
Akamai werkt ongeveer 10-15% langzamer dan onze oplossing via Ali Cloud CDN. Het is indrukwekkend dat we in Origin voor Akamai het IP-adres van GLB hebben opgegeven, wat betekent dat het verkeer niet via onze oplossing ging (we kunnen mogelijk een deel van de infrastructuur achterwege laten). Maar ondanks dat toonden de testresultaten aan dat deze oplossing slechter presteerde dan onze huidige optie (vergelijkende resultaten hieronder).
Zowel Origin GLB als Origin in China werden getest. Beide opties zijn ongeveer gelijk.
Er is Sure Route (automatische routeroptimalisatie). U kunt een testobject op Origin plaatsen, en de Akamai Edge-servers zullen proberen het op te halen (gewone GET). Voor deze aanvragen worden de snelheid en andere statistieken gemeten, op basis waarvan het Akamai-netwerk routes optimaliseert zodat het verkeer sneller naar onze site gaat en zichtbaar is dat het inschakelen van deze functie inderdaad een significante impact heeft gehad op de snelheid van de site.
Configuratieversiebeheer in de webinterface is geweldig. U kunt versies vergelijken en de diff bekijken. U kunt eerdere versies bekijken.
U kunt een nieuwe versie eerst alleen op het Staging-netwerk van Akamai uitrollen — een netwerk dat identiek is aan de productieomgeving, maar deze weg beïnvloedt geen echte gebruikers. Voor deze test moet u de DNS-records op de lokale machine spoofen.
Zeer snelle laadtijden via hun netwerk voor grote statische bestanden, en blijkbaar voor andere bestanden ook. Een bestand uit de 'koude' cache wordt veel sneller opgehaald dan hetzelfde bestand uit de 'koude' cache van Ali CDN. Uit de 'warme' cache is de snelheid al min of meer hetzelfde.

Ali CDN-test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Totaal    % Ontvangen % Xferd  Gemiddelde Snelheid   Tijd    Tijd     Tijd  Huidig
                                 Dload  Upload   Totaal   Besteed    Overig  Snelheid
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_totaal:  11.208119
----------
grootte_download:  5895467 Bytes
snelheid_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
  % Totaal    % Ontvangen % Xferd  Gemiddelde Snelheid   Tijd    Tijd     Tijd  Huidig
                                 Dload  Upload   Totaal   Besteed    Overig  Snelheid
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_totaal:  3.154850
----------
grootte_download:  5895467 Bytes
snelheid_download:  1868699.000B/s

We hebben opgemerkt dat de situatie uit het bovenstaande voorbeeld van verschillende factoren afhankelijk is. Op het moment van schrijven van deze sectie heb ik de test nogmaals uitgevoerd. De resultaten voor beide platformen bleken ongeveer hetzelfde te zijn. Dit geeft aan dat het internet in China zelfs voor grote operators en cloudproviders af en toe verschillend gedrag vertoont.

Aan het vorige punt voeg ik een groot pluspunt toe voor Akamai: als je bij Ali dergelijke uitbarstingen van hoge prestaties en zeer lage zichtbaarheid ziet (dit geldt voor zowel Ali CDN, Ali CEN, als Ali IPSEC), dan werkt bij Akamai elke keer, ongeacht hoeveel ik hun netwerk test, alles stabiel.
Akamai heeft inderdaad een grote dekking in China en werkt via veel providers.

Wat we niet leuk vonden:

Ik vind de webinterface en de werkwijze niet leuk — het is allemaal erg basaal. Maar in principe raakt men eraan gewend (waarschijnlijk).
De testresultaten zijn slechter dan onze eigen site.
Er zijn meer fouten tijdens de tests dan op onze eigen site (uptime is lager).
Ze hebben geen eigen DNS-servers in China. Dit leidt tot veel fouten in de tests door DNS resolve timeouts.
Ze geven geen informatie over hun IP-reeksen -> geen mogelijkheid om correct in te stellen. set_real_ip_from op onze servers.

Statistieken (~3626 runs; alle statistieken, behalve uptime, in ms; gegevens voor één tijdsinterval):

CDN Provider
Mediaan
75%
95%
Response
Webpagina Respons
Uptime
DNS
Verbinden
Wait
Load
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

Verdeling per Percentiel (in ms):

Percentiel
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

De conclusie is als volgt: de optie met Akamai is levensvatbaar, maar biedt niet dezelfde stabiliteits- en snelheidsmetingen als onze eigen oplossing gecombineerd met Ali CDN.

Kleine notities

Sommige punten zijn niet in het verhaal opgenomen, maar ik wil ook hierover schrijven.

Peking + Tokio en Hongkong

Zoals ik hierboven al zei, hebben we een IPSEC-tunnel naar Hongkong (HK) getest. Maar we hebben ook CEN naar HK getest. Het is iets goedkoper en het was interessant om te zien hoe het zou presteren tussen steden op een afstand van ~100 km. Interessant was dat de latency tussen deze steden 100 ms hoger was dan in onze oorspronkelijke opzet (tot Taiwan). Snelheid en stabiliteit waren ook beter voor Taiwan. Uiteindelijk hebben we HK als een back-up IPSEC-regio behouden.

Daarnaast hebben we geprobeerd om een dergelijke installatie op te zetten:

terminatie van klanten in Peking,
IPSEC en CEN naar Tokio,
in Ali CDN werd als origin server in Peking opgegeven.

Dit schema was niet zo stabiel, hoewel de snelheid in het algemeen niet onderdeed voor onze oplossing. Wat betreft de tunnel, ik heb sporadische uitval gezien, zelfs voor CEN, dat stabiel zou moeten zijn. Daarom zijn we teruggegaan naar de oude opzet en hebben we deze staging afgebroken.

Hieronder staan de statistieken voor latency tussen verschillende regio's via verschillende kanalen. Misschien is het voor iemand interessant.

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

Algemene informatie over internet in China

Als aanvulling op de internetproblemen die in het begin van het artikel zijn beschreven.

Internet in China werkt behoorlijk snel binnen het land.
- De conclusie is gebaseerd op tests van publieke Wi-Fi-netwerken op verschillende locaties, waar deze netwerken door veel mensen worden gebruikt.
- De download- en uploadsnelheid naar servers binnen China was ongeveer 20 Mbps en 5-10 Mbps respectievelijk.
- De snelheid naar servers buiten China is gewoon minimaal, minder dan 1 Mbps.
Internet in China is niet erg stabiel.
- Soms kunnen websites snel laden, soms langzaam (op hetzelfde tijdstip op verschillende dagen), mits de configuratie niet verandert. Dit hebben we waargenomen op semrushchina.cn. Dit kan worden toegeschreven aan Ali CDN, dat ook afhankelijk van het tijdstip van de dag, de stand van de sterren, enzovoorts, inconsistente prestaties vertoont.
Mobiele internetverbindingen zijn bijna overal 4G of 4G+. Het werkt in de metro, in liften — kortom, overal.
Het is een mythe dat Chinese gebruikers alleen vertrouwen op .cn-domeinen. We hebben dit rechtstreeks van gebruikers vernomen.
- Je kunt zien hoe http://baidu.cn redirect naar www.baidu.com (ook in het vasteland van China).
Veel bronnen zijn daadwerkelijk geblokkeerd. Simpel gezegd: google.com, Facebook, Twitter. Maar veel Google-resources werken (natuurlijk, niet op alle Wi-Fi-netwerken en VPN wordt hierbij niet gebruikt (ook niet aan de routerzijde, dat is zeker).
Veel 'technische' domeinen van geblokkeerde bedrijven werken ook. Dit betekent dat je niet altijd onvoorzichtig alle schijnbaar geblokkeerde Google- en andere bronnen moet verwijderen. Het is nodig om een lijst van verboden domeinen te zoeken.
Ze hebben slechts drie belangrijke internetproviders: China Unicom, China Telecom, China Mobile. Er zijn nog kleinere, maar hun marktaandeel is onbetekenend.

Bonus: uiteindelijke oplossingsschema

Conclusie

Er is een jaar verstreken sinds de start van het project. We begonnen met het feit dat onze website over het algemeen niet goed functioneerde vanuit China, en een eenvoudige GET-curl nam 5,5 seconden in beslag.

Daarna, met deze cijfers bij de eerste oplossing (Cloudflare):

Oplossing
Uptime
Mediaan
75 percentiel
95 percentiel

Cloudflare
86.6
18s
30s
60s

Uiteindelijk hebben we deze resultaten bereikt (statistieken van de afgelopen maand):

Oplossing
Uptime
Mediaan
75 percentiel
95 percentiel

Ali CDN + CEN/IPsec + GLB
99.86
8,8s
9,5s
13,7s

Zoals te zien is, lukt het voorlopig nog niet om 100% uptime te bereiken, maar we zullen iets verzinnen en vervolgens de resultaten in een nieuw artikel met jullie delen :)

Aan degene die alle drie delen tot het einde heeft gelezen: respect. Ik hoop dat jullie het net zo interessant vonden als ik, toen ik het deed.