🥇Jak przeszliśmy przez Wielki Chiński Firewall (cz.3)

Cześć!
Każda dobra historia ma swój koniec. Nasza opowieść o tym, jak opracowaliśmy rozwiązanie szybkiego przejścia przez Chiński Firewall, nie jest wyjątkiem. Dlatego spieszę, aby podzielić się z Wami ostatnią, końcową częścią na ten temat.

W poprzedniej części opowiedzieliśmy o wielu stanowiskach testowych, które wymyśliliśmy, oraz o wynikach, jakie przyniosły. Zatrzymaliśmy się na tym, że warto byłoby dodać CDN! dla spójności do naszego schematu.

Opowiem Wam, jak testowaliśmy Alibaba Cloud CDN, Tencent Cloud CDN i Akamai, a także na czym ostatecznie się zatrzymaliśmy. No i oczywiście podsumujemy.

Alibaba Cloud CDN

Hostujemy się w Alibaba Cloud, korzystając z IPSEC i CEN od nich. Dobrze byłoby najpierw przetestować ich rozwiązania.

Alibaba Cloud oferuje dwa rodzaje produktów, które mogą nam odpowiadać: CDN i DCDN. Pierwsza opcja to klasyczny CDN dla konkretnej domeny (subdomeny). Druga opcja to Dynamic Route for CDN (nazywam to dynamicznym CDN), który można aktywować w trybie Full-site (dla domen wildcard), również buforuje statykę i przyspiesza ładowanie dynamicznej zawartości, to znaczy, że dynamiczna strona również będzie ładowana przez szybkie sieci dostawcy. Jest to dla nas istotne, ponieważ nasza strona jest głównie dynamiczna, używa wielu subdomen, a wygodniej jest skonfigurować CDN raz dla „gwiazdki” — *.semrushchina.cn.

Widzieliśmy ten produkt na wcześniejszych etapach naszego chińskiego projektu, ale wtedy jeszcze nie działał, a deweloperzy obiecali, że wkrótce produkt stanie się dostępny dla wszystkich klientów. I stał się.

W DCDN można:

ustawić terminację SSL z własnym certyfikatem,
włączyć akcelerację dynamicznej zawartości,
elastycznie skonfigurować buforowanie statycznych plików,
przeprowadzać purge buforu,
przekazywać web-sockety,
włączyć kompresję i nawet HTML Beautifier.

W skrócie, wszystko jak u doświadczonych i dużych dostawców CDN.

Po wskazaniu Origin (miejsca, gdzie trafią serwery edge CDN), pozostaje tylko stworzyć CNAME dla gwiazdki, odwołując się do all.semrushchina.cn.w.kunluncan.com (ten CNAME uzyskaliśmy w konsoli Alibaba Cloud), a CDN zacznie działać.

Z wyników testów, ten CDN bardzo nam pomógł. Statystyki przedstawione poniżej.

Rozwiązanie
Czas pracy
Mediana
75 Percentyl
95 Percentyl

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 bardzo dobre wyniki, tym bardziej, jeśli porównamy je z danymi początkowymi. Wiedzieliśmy jednak, że test przeglądarkowy amerykańskiej wersji naszej strony www.semrush.com średnio trwa 8,3 s (to bardzo przybliżona wartość). Jest nad czym pracować. Tym bardziej, że były jeszcze dostawcy CDN, których interesowało, aby przetestować.

Tak płynnie przechodzimy do kolejnego giganta na chińskim rynku — Tencent.

Tencent Cloud

Tencent dopiero rozwija swoje chmury — widać to po niewielkiej liczbie produktów. W trakcie ich używania chcieliśmy przetestować nie tylko ich CDN, ale także ogólną infrastrukturę sieciową:

czy mają coś podobnego do CEN?
jak działa IPSEC? Czy jest szybki, jaki jest uptime?
czy mają Anycast?

Rozważmy te pytania osobno.

Odpowiednik CEN

Tencent ma produkt Cloud Connect Network (CCN), który pozwala na łączenie VPC z różnych regionów, w tym regionów wewnątrz Chin i na zewnątrz. Produkt jest obecnie w wewnętrznej becie i trzeba tworzyć zgłoszenie z prośbą o dołączenie do niego. Od wsparcia dowiedzieliśmy się, że globalne konta (nie ma mowy o obywatelach Chin ani osobach prawnych) nie mogą brać udziału w programie beta testowania i ogólnie połączyć region wewnątrz Chin z regionem na zewnątrz. 1-0 dla Ali Cloud

IPSEC

Najbardziej południowym regionem Tencent jest Guanhzhou. Zbudowaliśmy tunel i połączyliśmy go z regionem Hongkong w GCP (wtedy ten region był już dostępny). Równocześnie uruchomiliśmy drugi tunel w Ali Cloud z Shenzhen do Hongkongu. Okazało się, że przez sieć Tencent latency do Hongkongu jest lepsze (10 ms) w porównaniu do połączenia Shenzhen z Hongkongiem w Ali (120 ms — co?). Jednak to nie przyspieszało pracy strony, która miała działać poprzez Tencent i ten tunel, co samo w sobie było zaskakującym faktem i raz jeszcze dowodziło, że latency — dla Chin to nie jest wskaźnik, na który warto zwracać uwagę podczas opracowywania rozwiązania dotyczącego przejścia przez chiński firewall.

Anycast Internet Acceleration

Kolejny produkt, który pozwala pracować przez anycast IP — AIA. Ale również nie jest dostępny dla globalnych kont, więc o nim nic nie powiem, ale wiedza o istnieniu takiego produktu może być przydatna.

Test CDN pokazał dość interesujące wyniki. CDN Tencent nie można włączyć na pełnej stronie, tylko na konkretnych domenach. Przenieśliśmy domeny i skierowaliśmy na nie ruch:

Okazało się, że ten CDN ma taką funkcję: Optymalizacja Ruchu Międzynarodowego. Ta funkcja ma na celu obniżenie kosztów przy przekazywaniu ruchu przez chiński firewall. Jako Pochodzenie wskazano adres IP Google GLB (GLB anycast). Dzięki temu chcieliśmy uprościć architekturę projektu.

Wyniki były bardzo dobre — na poziomie Ali Cloud CDN, a miejscami nawet lepsze. To niesamowite, ponieważ w przypadku pomyślnych testów można by zrezygnować z istotnej części infrastruktury, tuneli, CEN, wirtualek itd.

Radość nie trwała długo, ponieważ pojawił się problem: testy w Catchpoint nie powiodły się dla dostawcy internetowego China Mobile. Z różnych lokalizacji otrzymywaliśmy timeout przez CDN Tencent. Korespondencja z pomocą techniczną nie przyniosła efektów. Przez około dobę próbowaliśmy rozwiązać ten problem, ale nic z tego nie wyszło.

W tym momencie byłem w Chinach, ale nie mogłem znaleźć publicznego Wi-Fi w sieci tego dostawcy, aby osobiście upewnić się o problemie. W pozostałych aspektach wszystko wyglądało na szybkie i dobre.
Jednakże, ponieważ operator China Mobile należy do trójki największych operatorów, byliśmy zmuszeni przywrócić ruch na Ali CDN.
Ogólnie jednak było to dość interesujące rozwiązanie, które zasługuje na dłuższe testowanie i rozwiązywanie tego problemu.

Akamai

Ostatnim dostawcą CDN, którego testowaliśmy, jest Akamai. To ogromny dostawca, który ma swoją sieć w Chinach. Oczywiście, nie mogliśmy go pominąć.

Na samym początku umówiliśmy się z Akamai na okres próbny, abyśmy mogli przekierować domenę i zobaczyć, jak będzie działać w ich sieci. Wynik wszystkich testów opiszę w postaci „Co się spodobało” i „Co się nie spodobało”, a także przedstawię wyniki testów.

Co się spodobało:

Zespół z Akamai bardzo pomagał w wszystkich kwestiach i towarzyszył nam na każdym etapie testów. Ciągle starali się poprawić coś po swojej stronie. Dali dobre porady techniczne.
Akamai działa około 10-15% wolniej niż nasze rozwiązanie poprzez Ali Cloud CDN. Zadziwiające jest to, że w Origin dla Akamai wskazaliśmy adres IP GLB, co oznacza, że ruch nie szedł przez nasze rozwiązanie (potencjalnie można by zrezygnować z części infrastruktury). Niemniej jednak wyniki testów pokazały, że ta opcja rozwiązania jest gorsza od naszej obecnej (wyniki porównawcze poniżej).
Testowano zarówno Origin GLB, jak i Origin w Chinach. Obie opcje są podobne.
Tak Pewna Trasa (automatyczna optymalizacja tras). Można umieścić obiekt testowy na Origin, a serwery brzegowe Akamai spróbują go pobrać (zwykły GET). Dla tych zapytań mierzona jest prędkość oraz inne metryki, na podstawie których sieć Akamai optymalizuje trasy, aby ruch był szybszy dla naszej strony i było widać, że włączenie tej funkcji naprawdę wpływa na szybkość działania strony.
Wersjonowanie konfiguracji w interfejsie internetowym to super sprawa. Można porównać wersje i zobaczyć różnice. Zobaczyć poprzednie wersje.
Nową wersję można wprowadzić najpierw tylko na sieć Staging Akamai — jest to ta sama sieć co produkcyjna, ale ten proces nie wpływa na prawdziwych użytkowników. Do tego testu trzeba zrobić spoofing rekordów DNS na lokalnej maszynie.
Bardzo szybka prędkość ładowania przez ich sieć dużej ilości statycznych danych, a także, widocznie, jakichkolwiek innych plików. Plik z "zimnego" cache'a jest pobierany wielokrotnie szybciej niż ten sam plik z "zimnego" cache'a Ali CDN. Z "gorącego" cache'a prędkość jest już mniej więcej taka sama.

Test Ali CDN:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Całkowity    % Odebrano % Xferd  Średnia prędkość   Czas    Czas     Czas  Bieżący
                                 Dload  Wysyłane   Całkowity   Spędzony    Pozostało  Prędkość
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 Bajtów
speed_download:  525999.000B/s

Test Akamai:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Całkowity    % Odebrano % Xferd  Średnia prędkość   Czas    Czas     Czas  Bieżący
                                 Dload  Wysyłane   Całkowity   Spędzony    Pozostało  Prędkość
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 Bajtów
speed_download:  1868699.000B/s

Zauważyliśmy, że sytuacja z przykładu powyżej zależy od różnych czynników. W momencie pisania tego akapitu przeprowadziłem test jeszcze raz. Wyniki dla obu platform okazały się mniej więcej takie same. To mówi nam, że internet w Chinach nawet dla dużych operatorów i dostawców chmurowych działa czasami różnie.

Do wcześniejszego punktu dodam dużą zaletę Akamai: jeśli u Ali widać takie wyładowania wysokiej wydajności i bardzo niskiej, to w przypadku Akamai za każdym razem, niezależnie od tego, jak testowałem ich sieć, wszystko działa stabilnie.
Akamai rzeczywiście ma dużą obecność w Chinach i współpracuje z wieloma dostawcami.

Co mi się nie podoba:

Nie podoba mi się interfejs webowy i sposób działania - są do niczego. Ale w zasadzie można się przyzwyczaić (prawdopodobnie).
Wyniki testów gorsze niż na naszej stronie.
Więcej błędów podczas testów niż na naszej stronie (uptime niższy).
Brak własnych serwerów DNS w Chinach. Stąd wiele błędów w testach z powodu przekroczenia czasu rozwiązywania DNS.
Nie podają swoich zakresów IP -> brak możliwości poprawnego wpisania set_real_ip_from na naszych serwerach.

Metryki (~3626 uruchomień; wszystkie metryki, z wyjątkiem Uptime, w ms; statystyka za jeden interwał czasowy):

Dostawca CDN
Mediana
75%
95%
Odpowiedź
Odpowiedź strony internetowej
Czas pracy
DNS
Connect
Oczekiwanie
Ładowanie
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

Rozkład według percentyla (w ms):

Percentyl
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

Wynik jest taki: opcja z Akamai jest wykonalna, ale nie zapewnia tych samych wskaźników stabilności i prędkości jak nasze własne rozwiązanie z Ali CDN.

Małe uwagi

Niektóre punkty nie zostały uwzględnione w opowieści, ale chciałbym o nich też napisać.

Pekin + Tokio i Hongkong

Jak już wspomniałem wcześniej, testowaliśmy tunel IPSEC do Hongkongu (HK). Ale testowaliśmy również CEN do HK. Jest nieco tańszy i ciekawiło nas, jak będzie działał między miastami oddalonymi o ~100 km. Interesujące było to, że latencja między tymi miastami była o 100 ms wyższa niż w naszym pierwotnym wariancie (do Tajwanu). Szybkość i stabilność również były lepsze dla Tajwanu. W rezultacie zostawiliśmy HK jako zapasowy region IPSEC.

Ponadto próbowaliśmy uruchomić taką instalację:

terminowanie klientów w Pekinie,
IPSEC i CEN do Tokio,
w Ali CDN wskazany jako serwer origin w Pekinie.

Ten schemat nie był tak stabilny, choć pod względem szybkości w ogóle nie ustępował naszemu rozwiązaniu. Jeśli chodzi o tunel, zauważyłem okresowe spadki nawet dla CEN, który miał być stabilny. Dlatego wróciliśmy do starego schematu i zdemontowaliśmy ten staging.

Poniżej przedstawiono statystyki dotyczące latencji między różnymi regionami w różnych kanałach. Może kogoś to zainteresuje.

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

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

Ogólne informacje o internecie w Chinach

Jako uzupełnienie problemów z internetem opisanych na początku, w pierwszej części artykułu.

Internet w Chinach działa dość szybko wewnątrz kraju.
- Wnioski oparto na testowaniu publicznych sieci Wi-Fi w różnych lokalizacjach, gdzie te sieci są wykorzystywane przez dużą liczbę osób.
- Prędkość pobierania i wysyłania do serwerów wewnątrz Chin wynosiła około 20 Mbit/s i 5-10 Mbit/s odpowiednio.
- Prędkość do serwerów spoza Chin jest po prostu znikoma, mniej niż 1 Mbit/s.
Internet w Chinach nie jest zbyt stabilny.
- Czasami strony mogą ładować się szybko, czasami wolno (o tej samej porze w różnych dniach), pod warunkiem, że konfiguracja się nie zmienia. Obserwowaliśmy to na przykładzie semrushchina.cn. Można to przypisać Ali CDN, który również działa różnie w zależności od pory dnia, układu gwiazd itd.
Internet mobilny praktycznie wszędzie to 4G lub 4G+. Działa w metrze, windach — krótko mówiąc, wszędzie.
To, że chińscy użytkownicy wierzą tylko w domeny w strefie .cn, to mit. Potwierdzaliśmy to bezpośrednio u użytkowników.
- Można zobaczyć, jak http://baidu.cn przekierowuje na www.baidu.com (w mainland China również).
Wiele zasobów jest rzeczywiście zablokowanych. Prosto mówiąc: google.com, Facebook, Twitter. Ale wiele usług Google działa (oczywiście, nie na wszystkich Wi-Fi i VPN nie jest używany (na stronie routera również, to pewne).
Wiele „technicznych” domen zablokowanych korporacji również działa. To znaczy, że nie zawsze należy bezmyślnie usuwać wszystkie zasoby Google i inne, które wydają się zablokowane. Należy poszukać jakiegoś katalogu zablokowanych domen.
Mają tylko trzech głównych operatorów internetowych: China Unicom, China Telecom, China Mobile. Są też mniejsze, ale ich udział w rynku jest nieistotny.

Bonus: końcowy schemat rozwiązania

Podsumowanie

Minął rok od rozpoczęcia projektu. Zaczęliśmy od tego, że nasza strona w ogóle odmawiała normalnego działania z Chin, a sam GET curl zajmował 5,5 sekund.

Potem, przy takich wynikach przy pierwszym rozwiązaniu (Cloudflare):

Rozwiązanie
Czas pracy
Mediana
75 Percentyl
95 Percentyl

Cloudflare
86.6
18s
30s
60s

W końcu osiągnęliśmy takie wyniki (statystyki z ostatniego miesiąca):

Rozwiązanie
Czas pracy
Mediana
75 Percentyl
95 Percentyl

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

Jak widać, nie udało się na razie osiągnąć 100% uptime, ale znajdziemy jakieś rozwiązanie, a potem opowiemy Wam o wynikach w nowym artykule :)

Szacunek dla tych, którzy dotarli do końca wszystkich trzech części. Mam nadzieję, że to wszystko było dla was równie interesujące, jak dla mnie, gdy to robiłem.