Hoe we de Grote Chinese Firewall doorbraken (deel 3)

Hey there!
Aan alle goede verhalen komt een einde. En ons verhaal over hoe we een oplossing bedachten om snel de Chinese Firewall te passeren, is daarop geen uitzondering. Daarom haast ik mij om de laatste met u te delen, het laatste deel over dit thema.

In het vorige deel hebben we gesproken over de vele testbanken die we bedacht hebben en welke resultaten deze opleverden. En we hebben besloten wat leuk zou zijn om toe te voegen CDN! voor viscositeit in ons schema.

Ik zal je vertellen hoe we Alibaba Cloud CDN, Tencent Cloud CDN en Akamai hebben getest en waar we uiteindelijk mee zijn beland. En natuurlijk, laten we samenvatten.

Alibaba Cloud-CDN

We worden gehost op Alibaba Cloud en gebruiken daar IPSEC en CEN van. Het zou logisch zijn om eerst hun oplossingen te proberen.

Alibaba Cloud heeft twee soorten producten die bij ons passen: CDN и DCDN. De eerste optie is een klassiek CDN voor een specifiek domein (subdomein). De tweede optie staat voor Dynamische route voor CDN (Ik noem het dynamisch CDN), het kan worden ingeschakeld in de modus Volledige site (voor wildcard-domeinen), het slaat ook statische inhoud op in de cache en versnelt de dynamische inhoud op zichzelf, dat wil zeggen dat de dynamiek van de pagina ook wordt geladen via de provider snelle netwerken. Dit is belangrijk voor ons, omdat onze site in principe dynamisch is, veel subdomeinen gebruikt en het handiger is om eenmalig een CDN in te stellen voor de “asterisk” - *.semrushchina.cn.

We hadden dit product al in de beginfase van ons Chinese project gezien, maar toen werkte het nog niet en de ontwikkelaars beloofden dat het product binnenkort voor alle klanten beschikbaar zou komen. En dat deed hij.

In DCDN kunt u:

• SSL-beëindiging configureren met uw certificaat,
• versnelling van dynamische inhoud mogelijk maken,
• configureer flexibel caching van statische bestanden,
• de cache leegmaken,
• voorwaartse webcontactdozen,
• schakel compressie en zelfs HTML Beautifier in.

Over het algemeen is alles hetzelfde als bij volwassenen en grote CDN-aanbieders.

Nadat de Origin (de plaats waar de CDN edge-servers naartoe zullen gaan) is opgegeven, hoeft u alleen nog maar een CNAME voor de asterisk te maken, verwijzend naar all.semrushchina.cn.w.kunluncan.com (deze CNAME is ontvangen in de Alibaba Cloud-console) en de CDN zal werken.

Op basis van de testresultaten heeft dit CDN ons enorm geholpen. De statistieken worden hieronder weergegeven.

beslissing
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 aan het begin. Maar we wisten dat de browsertest van de Amerikaanse versie van onze website www.semrush.com vanuit de VS gemiddeld 8.3 seconden duurt (een zeer geschatte waarde). Er is ruimte voor verbetering. Bovendien waren er ook CDN-providers die interessant waren om te testen.

Dus gaan we soepel verder naar een andere reus op de Chinese markt - Tencent.

Tencent-wolk

Tencent is net zijn cloud aan het ontwikkelen - dit is te zien aan een klein aantal producten. Terwijl we het gebruikten, wilden we niet alleen hun CDN testen, maar ook hun netwerkinfrastructuur als geheel:

• hebben ze iets dat lijkt op CEN?
• Hoe werkt IPSEC voor hen? Is het snel, wat is de uptime?
• Hebben ze Anycast?

Laten we deze vragen afzonderlijk bekijken.

Analoog CEN

Tencent heeft een product Cloud Connect-netwerk (CCN), waardoor u VPC's uit verschillende regio's kunt verbinden, inclusief regio's binnen en buiten China. Het product bevindt zich nu in de interne bètafase en u moet een ticket aanmaken waarin u wordt gevraagd er verbinding mee te maken. We hebben uit de steun geleerd dat mondiale accounts (we hebben het niet over Chinese burgers of rechtspersonen) niet kunnen deelnemen aan het bètatestprogramma en in het algemeen een regio binnen China kunnen verbinden met een regio daarbuiten. 1-0 in het voordeel van Ali Cloud

IPSEC

De meest zuidelijke regio van Tencent is Kanton. We hebben een tunnel gemonteerd en deze in GCP verbonden met de regio Hong Kong (toen was deze regio al beschikbaar). Tegelijkertijd werd ook de tweede tunnel in Ali Cloud van Shenzhen naar Hong Kong verhoogd. Het bleek dat via het Tencent-netwerk de latentie naar Hong Kong over het algemeen beter is (10 ms) dan van Shenzhen naar Hong Kong naar Ali (120 ms - wat?). Maar dit versnelde op geen enkele manier het werk van de site gericht op het werken via Tencent en deze tunnel, wat op zichzelf een verbazingwekkend feit was en opnieuw het volgende bewees: latentie - voor China is dit geen indicator die echt de moeite waard is Hierop letten bij het ontwikkelen van een oplossing om de Chinese firewall te passeren.

Anycast-internetversnelling

Een ander product waarmee je via anycast IP kunt werken is AIA. Maar het is ook niet beschikbaar voor wereldwijde accounts, dus ik zal je er niet over vertellen, maar het kan nuttig zijn om te weten dat een dergelijk product bestaat.

Maar de CDN-test liet een aantal behoorlijk interessante resultaten zien. Het CDN van Tencent kan niet worden ingeschakeld op een volledige site, alleen op specifieke domeinen. We hebben domeinen gemaakt en verkeer naar deze domeinen gestuurd:

Het bleek dat dit CDN de volgende functie heeft: Optimalisatie van grensoverschrijdend verkeer. Deze functie zou de kosten moeten verlagen wanneer verkeer door de Chinese firewall gaat. Als Oorsprong Het IP-adres van Google GLB (GLB anycast) is opgegeven. Daarom wilden we de projectarchitectuur vereenvoudigen.

De resultaten waren zeer goed - op het niveau van Ali Cloud CDN, en op sommige plaatsen zelfs beter. Dit is verrassend, want als de tests succesvol zijn, kun je een aanzienlijk deel van de infrastructuur, tunnels, CEN, virtuele machines, enz. verlaten.

We waren er niet lang blij mee, want er kwam een ​​probleem aan het licht: tests in Catchpoint mislukten voor internetprovider China Mobile. Vanaf elke locatie ontvingen we een time-out via het CDN van Tencent. Correspondentie met technische ondersteuning leidde tot niets. We hebben ongeveer een dag geprobeerd dit probleem op te lossen, maar niets werkte.

Ik was op dat moment in China, maar kon geen openbare wifi vinden op het netwerk van deze provider om het probleem persoonlijk te verifiëren. Verder zag alles er snel en goed uit.
Omdat China Mobile een van de drie grootste operators is, waren we echter genoodzaakt verkeer terug te sturen naar Ali CDN.
Maar over het algemeen was dit een nogal interessante oplossing die langer testen en oplossen van dit probleem verdient.

Akamai

De laatste CDN-provider die we hebben getest was Akamai. Dit is een enorme aanbieder met een netwerk in China. Natuurlijk konden we er niet omheen.

Vanaf het allereerste begin hebben we met Akamai een proefperiode afgesproken, zodat we van domein konden wisselen en kijken hoe het op hun netwerk zou werken. Ik zal het resultaat van alle tests beschrijven in de vorm van ‘Wat ik leuk vond’ en ‘Wat ik niet leuk vond’, en ik zal ook de testresultaten geven.

Wat we leuk vonden:

• De jongens van Akamai waren zeer behulpzaam bij alle vragen en vergezelden ons in alle testfasen. We probeerden voortdurend iets aan onze kant te verbeteren. Ze gaven goed technisch advies.
• Akamai is ongeveer 10-15% langzamer dan onze oplossing via Ali Cloud CDN. Wat indrukwekkend is, is dat we in Origin for Akamai het IP-adres van de GLB hebben gespecificeerd, wat betekent dat het verkeer niet door onze oplossing is gegaan (mogelijk zouden we een deel van de infrastructuur kunnen verlaten). Maar toch toonden de testresultaten aan dat deze oplossing slechter is dan onze huidige versie (vergelijkende resultaten hieronder).
• Zowel Origin GLB als Origin in China getest. Beide opties zijn ongeveer hetzelfde.
• Er is Zeker route (automatische routeringsoptimalisatie). Je kunt een testobject hosten op Origin, en de Akamai Edge-servers zullen proberen het op te halen (reguliere GET). Voor deze verzoeken worden snelheid en andere statistieken gemeten, op basis waarvan het Akamai-netwerk de routes optimaliseert zodat het verkeer naar onze site sneller gaat en het was duidelijk dat het inschakelen van deze functie echt een sterke impact had op de snelheid van de site.
• Het versiebeheer van de configuratie in de webinterface is cool. Je kunt Vergelijken voor versies, kijk naar diff. Bekijk eerdere versies.
• U kunt een nieuwe versie eerst alleen uitrollen op het Akamai Staging-netwerk - hetzelfde netwerk als de productie, maar op deze manier heeft dit geen invloed op echte gebruikers. Voor deze test moet u DNS-records op uw lokale computer spoofen.
• Zeer hoge downloadsnelheid via hun netwerk voor grote statische bestanden, en blijkbaar ook voor alle andere bestanden. Een bestand uit de “koude” cache wordt vele malen sneller opgehaald dan hetzelfde bestand uit de “koude” cache van Ali CDN. Vanuit de "hot" cache is de snelheid al hetzelfde, plus of min.

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

We hebben gemerkt dat de situatie in bovenstaand voorbeeld afhankelijk is van verschillende factoren. Toen ik dit punt schreef, heb ik de test opnieuw uitgevoerd. De resultaten voor beide platforms waren ongeveer hetzelfde. Dit leert ons dat het internet in China, zelfs voor grote operators en cloudproviders, zich van tijd tot tijd anders gedraagt.

Aan het vorige punt zal ik een groot pluspunt voor Akamai toevoegen: als Ali vergelijkbare flitsen van hoge prestaties en zeer lage prestaties vertoont (dit geldt voor Ali CDN, Ali CEN en Ali IPSEC), dan zal Akamai elke keer, ongeacht hoe ik hun netwerk test, alles werkt stabiel.
Akamai heeft in China wel veel dekking en werkt via veel aanbieders.

Wat niet leuk vond:

• Ik hou niet van de webinterface en de manier waarop deze werkt - het is zo slecht. Maar eigenlijk raak je er (waarschijnlijk) aan gewend.
• Testresultaten zijn slechter dan onze site.
• Er zijn meer fouten tijdens tests dan op onze site (uptime hieronder).
• We hebben geen eigen DNS-servers in China. Daarom zijn er veel fouten in tests als gevolg van een DNS-resolutietime-out.
• Ze geven hun IP-bereiken niet op -> er is geen manier om de juiste te registreren set_real_ip_from op onze servers.

Statistieken (~3626 runs; alle statistieken behalve Uptime, in ms; statistieken voor één periode):

CDN-provider
Mediaan
75%
95%
antwoord
Reactie van webpagina
Uptime
DNS
Verbinden
Wacht
Laden
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

Verdeling per percentiel (in ms):

percentiel
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

De conclusie is deze: de Akamai-optie is haalbaar, maar biedt niet dezelfde stabiliteit en snelheid als onze eigen oplossing in combinatie met Ali CDN.

Kleine opmerkingen

Sommige momenten zijn niet in het verhaal opgenomen, maar ik zou er ook graag over willen schrijven.

Peking + Tokio en Hong Kong

Zoals ik hierboven al zei, hebben we een IPSEC-tunnel naar Hong Kong (HK) getest. Maar we hebben ook CEN tot HK getest. Het kost iets minder, en ik vroeg me af hoe het zou werken tussen steden met een afstand van ~100 km. Het bleek interessant dat de latentie tussen deze steden 100 ms hoger is dan in onze originele versie (naar Taiwan). Snelheid en stabiliteit waren ook beter voor Taiwan. Als gevolg hiervan verlieten we HK als back-up IPSEC-regio.

Daarnaast hebben we geprobeerd de volgende installatie te installeren:

• beëindiging van klanten in Beijing,
• IPSEC en CEN naar Tokio,
• in Ali CDN werd de server in Beijing als oorsprong aangegeven.

Dit schema was niet zo stabiel, hoewel het qua snelheid over het algemeen niet onderdeed voor onze oplossing. Wat de tunnel betreft, heb ik zelfs voor CEN af en toe dalingen gezien, die stabiel hadden moeten zijn. Daarom keerden we terug naar het oude schema en ontmantelden we deze enscenering.

Hieronder vindt u statistieken over de latentie tussen verschillende regio's voor verschillende kanalen. Misschien heeft iemand er interesse in.

IPsec
Ali cn-beijing <—> GCP Azië-noordoost1 — 193 ms
Ali cn-shenzhen <—> GCP Azië-Oost2 — 91 ms
Ali cn-shenzhen <—> GCP us-oost4 — 200 ms

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

Algemene informatie over internet in China

Als aanvulling op de problemen met internet die helemaal aan het begin, in het eerste deel van het artikel, zijn beschreven.

• Internet in China is binnen behoorlijk snel.
  • De conclusie is getrokken op basis van het testen van openbare Wi-Fi-netwerken op verschillende locaties waar deze netwerken door een groot aantal mensen worden gebruikt.
  • De download- en uploadsnelheden naar servers in China waren respectievelijk ongeveer 20 Mbit/s en 5-10 Mbit/s.
  • De snelheid naar servers buiten China is ronduit mager, minder dan 1 Mbit/s.
• Het internet in China is niet erg stabiel.
  • Soms kunnen sites snel openen, soms langzaam (op hetzelfde tijdstip van de dag op verschillende dagen), op voorwaarde dat de configuratie niet verandert. We hebben dit waargenomen met het voorbeeld van semrushchina.cn. Dit kan worden toegeschreven aan Ali CDN, dat ook zo werkt en dat afhankelijk van het tijdstip van de dag, de stand van de sterren, etc.
• Mobiel internet is vrijwel overal 4G of 4G+. Vang het in de metro, liften - kortom, overal.
• Het is een mythe dat Chinese gebruikers alleen domeinen in de .cn-zone vertrouwen. Dit hebben we rechtstreeks van gebruikers geleerd.
  • Je kunt zien hoe http://baidu.cn doorverwijzen naar www.baidu.com (ook op het vasteland van China).
• Veel bronnen zijn inderdaad geblokkeerd. Primitief: google.com, Facebook, Twitter. Maar veel Google-bronnen werken (uiteraard niet op alle Wi-Fi en VPN wordt niet gebruikt (ook aan de routerkant, dat is zeker).
• Veel ‘technische’ domeinen van geblokkeerde bedrijven werken ook. Dit betekent dat je niet altijd roekeloos alle Google en andere schijnbaar geblokkeerde bronnen moet verwijderen. U moet zoeken naar een lijst met verboden domeinen.
• Ze hebben slechts drie grote internetoperatoren: China Unicom, China Telecom en China Mobile. Er zijn zelfs kleinere, maar hun marktaandeel is onbeduidend

Bonus: eindoplossingsdiagram

Totaal

Er is een jaar verstreken sinds de start van het project. We begonnen met het feit dat onze site over het algemeen weigerde normaal te werken vanuit China, en dat het eenvoudigweg GET-curl 5.5 seconden duurde.

Vervolgens met deze indicatoren in de eerste oplossing (Cloudflare):

beslissing
Uptime
Mediaan
75 percentiel
95 percentiel

Cloudflare
86.6
18s
30s
60s

Uiteindelijk bereikten we de volgende resultaten (statistieken van de afgelopen maand):

beslissing
Uptime
Mediaan
75 percentiel
95 percentiel

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

Zoals je ziet is het nog niet gelukt om 100% uptime te behalen, maar daar komen we wel op uit, en dan vertellen we je in een nieuw artikel over de resultaten :)

Respect voor degenen die alle drie de delen tot het einde hebben gelezen. Ik hoop dat je dit allemaal net zo interessant vond als ik toen ik het deed.

PS Vorige delen

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

Bron: www.habr.com