Hi!
Wszystkie dobre historie szybko się kończą. Nasza historia o tym, jak wymyśliliśmy rozwiązanie umożliwiające szybkie ominięcie chińskiej zapory ogniowej, nie jest wyjątkiem. Dlatego spieszę podzielić się z Wami ostatnim, ostatnia część na ten temat.
W poprzedniej części rozmawialiśmy o wielu stanowiskach testowych, które wymyśliliśmy i jakie dały wyniki. I ustaliliśmy, co warto dodać CDN! dla lepkości do naszego schematu.
Opowiem Wam, jak testowaliśmy Alibaba Cloud CDN, Tencent Cloud CDN i Akamai i z czym skończyliśmy. I oczywiście podsumujmy.
CDN w chmurze Alibaba
Jesteśmy hostowani w Alibaba Cloud i korzystamy z nich IPSEC i CEN. Logiczne byłoby wypróbowanie najpierw ich rozwiązań.
Alibaba Cloud ma dwa rodzaje produktów, które mogą nam odpowiadać: CDN и DCDN. Pierwsza opcja to klasyczny CDN dla konkretnej domeny (subdomeny). Druga opcja oznacza Dynamiczna trasa dla CDN (nazywam to dynamicznym CDN), można go włączyć w trybie Full-site (dla domen wieloznacznych), buforuje także zawartość statyczną i sama przyspiesza zawartość dynamiczną, czyli dynamika strony będzie również ładowana przez dostawcę szybkie sieci. Jest to dla nas ważne, ponieważ w zasadzie nasza strona jest dynamiczna, korzysta z wielu subdomen, a wygodniej jest założyć CDN raz dla „gwiazdki” - *.semrushchina.cn.
Widzieliśmy ten produkt już we wcześniejszych etapach naszego chińskiego projektu, ale wtedy jeszcze nie działał, a twórcy obiecali, że produkt wkrótce będzie dostępny dla wszystkich klientów. I zrobił.
W DCDN możesz:
- skonfiguruj zakończenie SSL za pomocą swojego certyfikatu,
- umożliwić akcelerację treści dynamicznych,
- elastycznie konfiguruj buforowanie plików statycznych,
- wyczyść pamięć podręczną,
- gniazda sieciowe forward,
- włączyć kompresję, a nawet upiększanie HTML.
Ogólnie rzecz biorąc, wszystko jest takie samo jak u dorosłych i dużych dostawców CDN.
Po określeniu pochodzenia (miejsca, do którego trafią serwery brzegowe CDN), wystarczy utworzyć CNAME dla gwiazdki, odwołując się do all.semrushchina.cn.w.kunluncan.com (ten CNAME został odebrany w konsoli Alibaba Cloud), a CDN będzie działać.
Sądząc po wynikach testów, ten CDN bardzo nam pomógł. Statystyki pokazano poniżej.
decyzja
Uptime
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, zwłaszcza jeśli porównać je z tym, co było na początku. Wiedzieliśmy jednak, że test przeglądarki amerykańskiej wersji naszej witryny www.semrush.com z USA trwa średnio 8.3 s (wartość bardzo przybliżona). Jest miejsce na poprawę. Co więcej, byli też dostawcy CDN, których przetestowanie było interesujące.
Płynnie zatem przechodzimy do kolejnego giganta na chińskim rynku – Tencent.
Tencent Chmura
Tencent dopiero rozwija swoją chmurę – widać to po niewielkiej liczbie produktów. Korzystając z niego, chcieliśmy przetestować nie tylko ich CDN, ale także całą infrastrukturę sieciową:
- czy mają coś podobnego do CEN?
- Jak działa dla nich IPSEC? Czy jest szybki i jaki jest czas sprawności?
- czy mają Anycast?
Przyjrzyjmy się tym pytaniom osobno.
Analogowy CEN
Tencent ma produkt Sieć Cloud Connect (), umożliwiając łączenie VPC z różnych regionów, w tym regionów w Chinach i poza nimi. Produkt jest obecnie w fazie wewnętrznej wersji beta i należy utworzyć zgłoszenie z prośbą o połączenie się z nim. Ze wsparcia dowiedzieliśmy się, że konta globalne (nie mówimy o chińskich obywatelach ani osobach prawnych) nie mogą uczestniczyć w programie testów beta i ogólnie łączyć region w Chinach z regionem na zewnątrz. 1:0 na korzyść Ali Cloud
IPSEC
Najbardziej wysunięty na południe region Tencent to Kanton. Zmontowaliśmy tunel i połączyliśmy go z regionem Hongkong w GCP (wówczas ten region był już dostępny). W tym samym czasie powstał także drugi tunel w Ali Cloud z Shenzhen do Hongkongu. Okazało się, że poprzez sieć Tencent opóźnienie do Hongkongu jest generalnie lepsze (10ms) niż z Shenzhen do Hongkongu do Ali (120ms – co?). Ale to w żaden sposób nie przyspieszyło pracy serwisu mającego na celu pracę przez Tencent i ten tunel, co samo w sobie było niesamowitym faktem i po raz kolejny udowodniło, co następuje: opóźnienie - dla Chin nie jest to wskaźnik naprawdę warty zwracając uwagę przy opracowywaniu rozwiązania umożliwiającego przejście przez chińską zaporę ogniową.
Przyspieszenie Internetu Anycast
Kolejnym produktem umożliwiającym pracę za pośrednictwem protokołu Anycast IP jest . Ale nie jest ona dostępna również dla kont globalnych, więc nie będę Wam o tym opowiadać, ale wiedza o istnieniu takiego produktu może się przydać.
Ale test CDN pokazał kilka całkiem interesujących wyników. Sieci CDN firmy Tencent nie można włączyć w całej witrynie, tylko w określonych domenach. Stworzyliśmy domeny i skierowaliśmy do nich ruch:
Okazało się, że ten CDN ma następującą funkcję: Optymalizacja ruchu transgranicznego. Ta funkcja powinna obniżyć koszty, gdy ruch przechodzi przez chińską zaporę ogniową. Jak Origin Podano adres IP Google GLB (GLB anycast). Tym samym chcieliśmy uprościć architekturę projektu.
Wyniki były bardzo dobre – na poziomie Ali Cloud CDN, a miejscami nawet lepsze. Jest to zaskakujące, ponieważ jeśli testy wypadną pomyślnie, można porzucić znaczną część infrastruktury, tunele, CEN, maszyny wirtualne itp.
Nie cieszyliśmy się długo, gdy ujawniono problem: testy w Catchpoint nie powiodły się u dostawcy Internetu China Mobile. Z dowolnej lokalizacji otrzymaliśmy przekroczenie limitu czasu za pośrednictwem sieci CDN Tencent. Korespondencja z supportem technicznym nic nie dała. Próbowaliśmy rozwiązać ten problem przez około jeden dzień, ale nic nie działało.
Byłem w tym momencie w Chinach, ale nie mogłem znaleźć publicznego Wi-Fi w sieci tego dostawcy, aby osobiście zweryfikować problem. Poza tym wszystko wyglądało szybko i dobrze.
Jednak w związku z tym, że China Mobile jest jednym z trzech największych operatorów, byliśmy zmuszeni przywrócić ruch do Ali CDN.
Ale ogólnie było to dość interesujące rozwiązanie, które zasługuje na dłuższe testowanie i rozwiązywanie tego problemu.
Akamai
Ostatnim testowanym przez nas dostawcą CDN był Akamai. To ogromny dostawca, który ma swoją sieć w Chinach. Oczywiście nie mogliśmy tego przeboleć.
Od samego początku umówiliśmy się z Akamai na okres próbny, abyśmy mogli zmienić domenę i zobaczyć, jak będzie działać w ich sieci. Wynik wszystkich testów opiszę w formie „Co mi się podobało” i „Co mi się nie podobało”, a także podam wyniki testów.
Co nam się podobało:
- Chłopaki z Akamai byli bardzo pomocni we wszystkich pytaniach i towarzyszyli nam na wszystkich etapach testów. Cały czas staraliśmy się ulepszyć coś po naszej stronie. Dali dobre rady techniczne.
- Akamai działa około 10-15% wolniej niż nasze rozwiązanie poprzez Ali Cloud CDN. Imponujące jest to, że w Origin dla Akamai podaliśmy adres IP GLB, co oznacza, że ruch nie przechodził przez nasze rozwiązanie (potencjalnie moglibyśmy porzucić część infrastruktury). Jednak wyniki testów pokazały, że to rozwiązanie jest gorsze od naszej obecnej wersji (wyniki porównawcze poniżej).
- Przetestowano zarówno Origin GLB, jak i Origin w Chinach. Obie opcje są w przybliżeniu takie same.
- Jest Jasne Trasa (automatyczna optymalizacja tras). Możesz udostępnić obiekt testowy w Origin, a serwery Akamai Edge spróbują go odebrać (zwykły GET). Dla tych żądań mierzona jest prędkość i inne wskaźniki, na podstawie których sieć Akamai optymalizuje trasy, aby ruch na naszej stronie płynął szybciej i było jasne, że włączenie tej funkcji naprawdę miało duży wpływ na szybkość działania witryny.
- Wersjonowanie konfiguracji w interfejsie internetowym jest fajne. Możesz wykonać porównanie wersji, spójrz na różnicę. Zobacz poprzednie wersje.
- Możesz najpierw wdrożyć nową wersję tylko w sieci Akamai Staging - tej samej sieci, co produkcja, tylko w ten sposób nie będzie to miało wpływu na prawdziwych użytkowników. Na potrzeby tego testu musisz sfałszować rekordy DNS na komputerze lokalnym.
- Bardzo duża prędkość pobierania przez ich sieć dużych plików statycznych i najwyraźniej wszelkich innych plików. Plik z „zimnej” pamięci podręcznej jest pobierany wielokrotnie szybciej niż ten sam plik z „zimnej” pamięci podręcznej Ali CDN. Z „gorącej” pamięci podręcznej prędkość jest już taka sama, plus lub minus.
Test Ali CDN:
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/sTest Akamai:
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/sZauważyliśmy, że sytuacja w powyższym przykładzie zależy od różnych czynników. W chwili pisania tego punktu ponownie przeprowadziłem test. Wyniki dla obu platform były w przybliżeniu takie same. To mówi nam, że Internet w Chinach, nawet w przypadku dużych operatorów i dostawców usług w chmurze, zachowuje się od czasu do czasu inaczej.
Do poprzedniego punktu dodam duży plus dla Akamai: jeśli Ali wykazuje podobne przebłyski wysokiej wydajności i bardzo niskiej wydajności (dotyczy Ali CDN, Ali CEN i Ali IPSEC), to Akamai za każdym razem, bez względu na to jak testuję ich sieć, wszystko działa stabilnie.
Akamai ma duży zasięg w Chinach i współpracuje z wieloma dostawcami.
Co nie podobało się:
- Nie podoba mi się interfejs sieciowy i sposób jego działania – jest taki kiepski. Ale w zasadzie można się do tego przyzwyczaić (prawdopodobnie).
- Wyniki testów są gorsze niż na naszej stronie.
- Podczas testów pojawia się więcej błędów niż na naszej stronie (czas działania poniżej).
- Nie mamy własnych serwerów DNS w Chinach. Dlatego w testach występuje wiele błędów z powodu przekroczenia limitu czasu rozpoznawania DNS.
- Nie podają swoich zakresów IP -> nie ma możliwości zarejestrowania prawidłowych set_real_ip_from na naszych serwerach.
Metryki (~3626 uruchomień; wszystkie metryki z wyjątkiem czasu działania w ms; statystyki za jeden okres):
Dostawca CDN
Mediana
75%
95%
Odpowiedź
Odpowiedź strony internetowej
Uptime
DNS
Skontaktuj się
Czekać
Załadować
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
Rozkład procentowy (w ms):
Percentyl
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
Wniosek jest taki: opcja Akamai jest opłacalna, ale nie zapewnia takiej samej stabilności i szybkości, jak nasze własne rozwiązanie w połączeniu z Ali CDN.
Małe notatki
Niektóre momenty nie zostały ujęte w historii, ale o nich też chciałabym napisać.
Pekin + Tokio i Hongkong
Jak powiedziałem powyżej, testowaliśmy tunel IPSEC do Hongkongu (HK). Ale przetestowaliśmy także CEN do HK. Kosztuje trochę mniej, a zastanawiałem się jak będzie działać pomiędzy miastami oddalonymi o ~100 km. Ciekawostką okazało się, że opóźnienie pomiędzy tymi miastami jest o 100ms większe niż w naszej oryginalnej wersji (do Tajwanu). Szybkość i stabilność były również lepsze dla Tajwanu. W rezultacie opuściliśmy HK jako zapasowy region IPSEC.
Dodatkowo próbowaliśmy zainstalować następującą instalację:
- likwidacja klientów w Pekinie,
- IPSEC i CEN do Tokio,
- w Ali CDN jako źródło wskazano serwer w Pekinie.
Schemat ten nie był aż tak stabilny, choć pod względem szybkości generalnie nie ustępował naszemu rozwiązaniu. Jeśli chodzi o tunel, widziałem sporadyczne spadki nawet w przypadku CEN, który powinien być stabilny. Dlatego powróciliśmy do starego schematu i zdemontowaliśmy tę inscenizację.
Poniżej znajdują się statystyki dotyczące opóźnień między różnymi regionami dla różnych kanałów. Może kogoś to zainteresuje.
IPsec
Ali cn-Pekin <—> GCP asia-northeast1 — 193 ms
Ali cn-shenzhen <—> GCP asia-east2 — 91 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms
CEN
Ali cn-pekin <—> Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms
Ogólne informacje o Internecie w Chinach
Jako dodatek do problemów z Internetem opisanych na samym początku, w pierwszej części artykułu.
- Internet w Chinach jest dość szybki.
- Wnioski wyciągnięto na podstawie testów publicznych sieci Wi-Fi w różnych lokalizacjach, w których korzysta z nich duża liczba osób.
- Prędkości pobierania i wysyłania na serwery w Chinach wynosiły odpowiednio około 20 Mbit/s i 5–10 Mbit/s.
- Prędkość do serwerów poza Chinami jest po prostu skromna, mniejsza niż 1 Mbit/s.
- Internet w Chinach nie jest zbyt stabilny.
- Czasem witryny otwierają się szybko, czasem wolno (o tej samej porze dnia w różne dni), pod warunkiem, że konfiguracja się nie zmieni. Zaobserwowaliśmy to na przykładzie semrushchina.cn. Można to przypisać Ali CDN, który również działa w ten i inny sposób w zależności od pory dnia, położenia gwiazd itp.
- Internet mobilny to niemal wszędzie 4G lub 4G+. Złap go w metrze, windach – krótko mówiąc, wszędzie.
- Mitem jest, że chińscy użytkownicy ufają wyłącznie domenom ze strefy .cn. Dowiedzieliśmy się tego bezpośrednio od użytkowników.
- Możesz zobaczyć jak przekierowanie na stronę www.baidu.com (również w Chinach kontynentalnych).
- Wiele zasobów jest rzeczywiście zablokowanych. Prymitywne: google.com, Facebook, Twitter. Ale wiele zasobów Google działa (oczywiście nie we wszystkich Wi-Fi i VPN nie jest używany (na pewno także po stronie routera).
- Działa również wiele domen „technicznych” zablokowanych korporacji. Oznacza to, że nie należy zawsze lekkomyślnie odcinać wszystkich zasobów Google i innych pozornie zablokowanych zasobów. Musisz poszukać jakiejś listy zabronionych domen.
- Mają tylko trzech głównych operatorów Internetu: China Unicom, China Telecom, China Mobile. Są jeszcze mniejsze, ale ich udział w rynku jest niewielki
Bonus: diagram rozwiązania końcowego
Łączny
Od rozpoczęcia projektu minął rok. Zaczęliśmy od tego, że nasza strona generalnie nie chciała normalnie działać z Chin, a samo GET curl trwało 5.5 sekundy.
Następnie z tymi wskaźnikami w pierwszym rozwiązaniu (Cloudflare):
decyzja
Uptime
Mediana
75 percentyl
95 percentyl
Cloudflare
86.6
18s
30s
60s
Ostatecznie osiągnęliśmy następujące wyniki (statystyki za ostatni miesiąc):
decyzja
Uptime
Mediana
75 percentyl
95 percentyl
Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s
Jak widać nie udało nam się jeszcze osiągnąć 100% uptime'u, ale coś wymyślimy i o efektach poinformujemy w nowym artykule :)
Szacunek dla tych, którzy przeczytali wszystkie trzy części do końca. Mam nadzieję, że uznaliście to wszystko za równie interesujące jak ja, kiedy to robiłem.
PS Poprzednie części
Źródło: www.habr.com