Πώς ξεπεράσαμε το Μεγάλο Κινεζικό Τείχος προστασίας (Μέρος 3)

Γεια σας!
Όλες οι καλές ιστορίες τελειώνουν. Και η ιστορία μας για το πώς καταλήξαμε σε μια λύση για να περάσουμε γρήγορα το Κινεζικό Τείχος προστασίας δεν αποτελεί εξαίρεση. Επομένως, σπεύδω να μοιραστώ μαζί σας το τελευταίο, το τελικό μέρος σχετικά με το θέμα αυτό.

Στο προηγούμενο μέρος μιλήσαμε για πολλούς πάγκους δοκιμών που καταλήξαμε και τι αποτελέσματα έδωσαν. Και καταλήξαμε στο τι θα ήταν ωραίο να προσθέσουμε CDN! για το ιξώδες στο σχήμα μας.

Θα σας πω πώς δοκιμάσαμε το Alibaba Cloud CDN, το Tencent Cloud CDN και το Akamai και σε τι καταλήξαμε. Και φυσικά, ας συνοψίσουμε.

Alibaba Cloud CDN

Φιλοξενούμαστε στο Alibaba Cloud και χρησιμοποιούμε IPSEC και CEN από αυτά. Θα ήταν λογικό να δοκιμάσουμε πρώτα τις λύσεις τους.

Το Alibaba Cloud έχει δύο είδη προϊόντων που μπορεί να μας ταιριάζουν: CDN и DCDN. Η πρώτη επιλογή είναι ένα κλασικό CDN για έναν συγκεκριμένο τομέα (subdomain). Η δεύτερη επιλογή σημαίνει Δυναμική διαδρομή για CDN (το ονομάζω δυναμικό CDN), μπορεί να ενεργοποιηθεί σε λειτουργία πλήρους ιστότοπου (για τομείς μπαλαντέρ), αποθηκεύει επίσης στατικό περιεχόμενο και επιταχύνει το δυναμικό περιεχόμενο από μόνο του, δηλαδή, η δυναμική της σελίδας θα φορτωθεί επίσης μέσω του παρόχου γρήγορα δίκτυα. Αυτό είναι σημαντικό για εμάς, επειδή βασικά ο ιστότοπός μας είναι δυναμικός, χρησιμοποιεί πολλούς υποτομείς και είναι πιο βολικό να ρυθμίσετε ένα CDN μία φορά για τον "αστερίσκο" - *.semrushchina.cn.

Είχαμε ήδη δει αυτό το προϊόν στα προηγούμενα στάδια του κινεζικού μας έργου, αλλά τότε δεν λειτουργούσε ακόμη και οι προγραμματιστές υποσχέθηκαν ότι το προϊόν θα γινόταν σύντομα διαθέσιμο σε όλους τους πελάτες. Και το έκανε.

Στο DCDN μπορείτε:

• διαμορφώστε τον τερματισμό SSL με το πιστοποιητικό σας,
• ενεργοποίηση της επιτάχυνσης του δυναμικού περιεχομένου,
• ρυθμίστε ευέλικτα την προσωρινή αποθήκευση στατικών αρχείων,
• εκκαθάριση της προσωρινής μνήμης,
• μπροστινές υποδοχές ιστού,
• ενεργοποιήστε τη συμπίεση και ακόμη και το HTML Beautifier.

Γενικά, όλα είναι ίδια με τους ενήλικες και τους μεγάλους παρόχους CDN.

Αφού καθοριστεί το Origin (το μέρος όπου θα πάνε οι διακομιστές άκρης CDN), το μόνο που μένει είναι να δημιουργήσετε ένα CNAME για τον αστερίσκο, με αναφορά all.semrushchina.cn.w.kunluncan.com (αυτό το CNAME ελήφθη στην κονσόλα Alibaba Cloud) και το CDN θα λειτουργήσει.

Με βάση τα αποτελέσματα των δοκιμών, αυτό το CDN μας βοήθησε πολύ. Τα στατιστικά φαίνονται παρακάτω.

Λύση
Uptime
Διάμεσος
75 εκατοστημόριο
95 εκατοστημόριο

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

Αυτά είναι πολύ καλά αποτελέσματα, ειδικά αν τα συγκρίνετε με αυτά που ήταν τα νούμερα στην αρχή. Όμως γνωρίζαμε ότι η δοκιμή του προγράμματος περιήγησης της αμερικανικής έκδοσης του ιστότοπού μας www.semrush.com εκτελείται από τις ΗΠΑ σε 8.3 δευτερόλεπτα κατά μέσο όρο (πολύ κατά προσέγγιση τιμή). Υπάρχει περιθώριο βελτίωσης. Επιπλέον, υπήρχαν επίσης πάροχοι CDN που ήταν ενδιαφέρον να δοκιμαστούν.

Έτσι προχωράμε ομαλά σε έναν άλλο γίγαντα στην κινεζική αγορά - Tencent.

Tencent Cloud

Η Tencent μόλις αναπτύσσει το cloud της - αυτό φαίνεται από έναν μικρό αριθμό προϊόντων. Κατά τη χρήση του, θέλαμε να δοκιμάσουμε όχι μόνο το CDN τους, αλλά και την υποδομή δικτύου τους στο σύνολό τους:

• εχουν κατι παρομοιο με το CEN?
• Πώς λειτουργεί το IPSEC για αυτούς; Είναι γρήγορο, ποιος είναι ο χρόνος λειτουργίας;
• έχουν Anycast;

Ας δούμε αυτές τις ερωτήσεις ξεχωριστά.

Αναλογικό CEN

Η Tencent έχει ένα προϊόν Cloud Connect Network (CCN), επιτρέποντάς σας να συνδέετε VPC από διαφορετικές περιοχές, συμπεριλαμβανομένων περιοχών εντός και εκτός Κίνας. Το προϊόν βρίσκεται τώρα σε εσωτερική έκδοση beta και πρέπει να δημιουργήσετε ένα εισιτήριο που θα σας ζητά να συνδεθείτε σε αυτό. Από την υποστήριξη μάθαμε ότι οι παγκόσμιοι λογαριασμοί (δεν μιλάμε για Κινέζους πολίτες ή νομικά πρόσωπα) δεν μπορούν να συμμετέχουν στο πρόγραμμα δοκιμών beta και, γενικά, να συνδέσουν μια περιοχή εντός της Κίνας με μια περιοχή εκτός. 1-0 υπέρ του Άλι Κλάουντ

IPsec

Η νοτιότερη περιοχή του Tencent είναι Γκουανγκζού. Συναρμολογήσαμε μια σήραγγα και τη συνδέσαμε με την περιοχή του Χονγκ Κονγκ στο GCP (τότε αυτή η περιοχή είχε ήδη γίνει διαθέσιμη). Το δεύτερο τούνελ στο Ali Cloud από το Shenzhen στο Χονγκ Κονγκ ανυψώθηκε επίσης την ίδια στιγμή. Αποδείχθηκε ότι μέσω του δικτύου Tencent η καθυστέρηση στο Χονγκ Κονγκ είναι γενικά καλύτερη (10ms) από ότι από το Shenzhen στο Χονγκ Κονγκ στο Ali (120ms - τι;). Αλλά αυτό δεν επιτάχυνε σε καμία περίπτωση το έργο του ιστότοπου που στοχεύει στην εργασία μέσω του Tencent και αυτού του τούνελ, το οποίο από μόνο του ήταν ένα εκπληκτικό γεγονός και για άλλη μια φορά απέδειξε το εξής: λανθάνουσα κατάσταση - για την Κίνα αυτό δεν είναι ένας δείκτης που πραγματικά αξίζει δίνοντας προσοχή κατά την ανάπτυξη μιας λύσης για το πέρασμα του κινεζικού τείχους προστασίας.

Επιτάχυνση Διαδικτύου Anycast

Ένα άλλο προϊόν που σας επιτρέπει να εργάζεστε μέσω anycast IP είναι ΔΑΑ. Αλλά δεν είναι επίσης διαθέσιμο σε παγκόσμιους λογαριασμούς, επομένως δεν θα σας πω γι 'αυτό, αλλά το να γνωρίζετε ότι υπάρχει ένα τέτοιο προϊόν μπορεί να είναι χρήσιμο.

Αλλά η δοκιμή CDN έδειξε αρκετά ενδιαφέροντα αποτελέσματα. Το CDN της Tencent δεν μπορεί να ενεργοποιηθεί σε έναν πλήρη ιστότοπο, μόνο σε συγκεκριμένους τομείς. Δημιουργήσαμε τομείς και στείλαμε επισκεψιμότητα σε αυτούς:

Αποδείχθηκε ότι αυτό το CDN έχει την ακόλουθη λειτουργία: Βελτιστοποίηση διασυνοριακής κυκλοφορίας. Αυτή η δυνατότητα θα πρέπει να μειώσει το κόστος όταν η κίνηση διέρχεται από το κινεζικό τείχος προστασίας. Οπως και Προέλευση Καθορίστηκε η διεύθυνση IP του Google GLB (GLB anycast). Έτσι, θέλαμε να απλοποιήσουμε την αρχιτεκτονική του έργου.

Τα αποτελέσματα ήταν πολύ καλά - σε επίπεδο Ali Cloud CDN, και σε ορισμένα σημεία ακόμα καλύτερα. Αυτό είναι εκπληκτικό, γιατί εάν οι δοκιμές είναι επιτυχείς, μπορείτε να εγκαταλείψετε ένα σημαντικό μέρος της υποδομής, τις σήραγγες, το CEN, τις εικονικές μηχανές κ.λπ.

Δεν χαρήκαμε για πολύ, καθώς αποκαλύφθηκε ένα πρόβλημα: οι δοκιμές στο Catchpoint απέτυχαν για τον πάροχο Διαδικτύου China Mobile. Από οποιαδήποτε τοποθεσία λάβαμε timeout μέσω του CDN της Tencent. Η αλληλογραφία με την τεχνική υποστήριξη δεν οδήγησε σε τίποτα. Προσπαθήσαμε να λύσουμε αυτό το πρόβλημα για περίπου μια μέρα, αλλά τίποτα δεν λειτούργησε.

Ήμουν στην Κίνα εκείνη τη στιγμή, αλλά δεν μπορούσα να βρω δημόσιο Wi-Fi στο δίκτυο αυτού του παρόχου για να επαληθεύσω προσωπικά το πρόβλημα. Κατά τα άλλα όλα φαίνονταν γρήγορα και καλά.
Ωστόσο, λόγω του γεγονότος ότι η China Mobile είναι ένας από τους τρεις μεγαλύτερους παρόχους, αναγκαστήκαμε να επιστρέψουμε την κίνηση στο Ali CDN.
Αλλά συνολικά, αυτή ήταν μια αρκετά ενδιαφέρουσα λύση που αξίζει μεγαλύτερης διάρκειας δοκιμή και αντιμετώπιση προβλημάτων αυτού του προβλήματος.

Akamai

Ο τελευταίος πάροχος CDN που δοκιμάσαμε ήταν Akamai. Αυτός είναι ένας τεράστιος πάροχος που έχει το δίκτυό του στην Κίνα. Φυσικά, δεν μπορέσαμε να το προσπεράσουμε.

Από την αρχή, συμφωνήσαμε με την Akamai για μια δοκιμαστική περίοδο, ώστε να μπορέσουμε να αλλάξουμε το domain και να δούμε πώς θα λειτουργούσε στο δίκτυό τους. Θα περιγράψω το αποτέλεσμα όλων των δοκιμών με τη μορφή "Τι μου άρεσε" και "Τι δεν μου άρεσε" και θα δώσω επίσης τα αποτελέσματα της δοκιμής.

Τι μας άρεσε:

• Τα παιδιά από το Akamai ήταν πολύ εξυπηρετικά σε όλες τις ερωτήσεις και μας συνόδευσαν σε όλα τα στάδια των δοκιμών. Προσπαθούσαμε συνεχώς να βελτιώσουμε κάτι από την πλευρά μας. Έδωσαν καλές τεχνικές συμβουλές.
• Το Akamai είναι περίπου 10-15% πιο αργό από τη λύση μας μέσω του Ali Cloud CDN. Αυτό που είναι εντυπωσιακό είναι ότι στο Origin for Akamai προσδιορίσαμε τη διεύθυνση IP του GLB, που σημαίνει ότι η κίνηση δεν περνούσε από τη λύση μας (ενδεχομένως θα μπορούσαμε να εγκαταλείψουμε μέρος της υποδομής). Ωστόσο, τα αποτελέσματα των δοκιμών έδειξαν ότι αυτή η λύση είναι χειρότερη από την τρέχουσα έκδοσή μας (συγκριτικά αποτελέσματα παρακάτω).
• Δοκιμάστηκε τόσο το Origin GLB όσο και το Origin στην Κίνα. Και οι δύο επιλογές είναι περίπου ίδιες.
• Υπάρχει Σίγουρη διαδρομή (αυτόματη βελτιστοποίηση δρομολόγησης). Μπορείτε να φιλοξενήσετε ένα δοκιμαστικό αντικείμενο στο Origin και οι διακομιστές Akamai Edge θα προσπαθήσουν να το παραλάβουν (κανονικό GET). Για αυτά τα αιτήματα, μετρώνται η ταχύτητα και άλλες μετρήσεις, βάσει των οποίων το δίκτυο Akamai βελτιστοποιεί τις διαδρομές, ώστε η επισκεψιμότητα να πηγαίνει πιο γρήγορα για τον ιστότοπό μας και ήταν σαφές ότι η ενεργοποίηση αυτής της δυνατότητας είχε πραγματικά ισχυρό αντίκτυπο στην ταχύτητα του ιστότοπου.
• Η έκδοση της διαμόρφωσης στη διεπαφή ιστού είναι πολύ καλή. Μπορείτε να κάνετε Σύγκριση για εκδόσεις, δείτε τη διαφορά. Δείτε προηγούμενες εκδόσεις.
• Μπορείτε να διαθέσετε μια νέα έκδοση πρώτα μόνο στο δίκτυο Akamai Staging - το ίδιο δίκτυο με την παραγωγή, μόνο που αυτός ο τρόπος δεν θα επηρεάσει τους πραγματικούς χρήστες. Για αυτήν τη δοκιμή, πρέπει να πλαστογραφήσετε τις εγγραφές DNS στον τοπικό σας υπολογιστή.
• Πολύ γρήγορη ταχύτητα λήψης μέσω του δικτύου τους για μεγάλα στατικά αρχεία και, προφανώς, οποιαδήποτε άλλα αρχεία. Ένα αρχείο από την "κρύα" κρυφή μνήμη ανακτάται πολλές φορές πιο γρήγορα από το ίδιο αρχείο από την "κρύα" κρυφή μνήμη του Ali CDN. Από την "καυτή" κρυφή μνήμη, η ταχύτητα είναι ήδη η ίδια, συν ή πλην.

Τεστ 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/s

Δοκιμή 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/s

Παρατηρήσαμε ότι η κατάσταση στο παραπάνω παράδειγμα εξαρτάται από διάφορους παράγοντες. Τη στιγμή που γράφω αυτό το σημείο, έτρεξα ξανά το τεστ. Τα αποτελέσματα και για τις δύο πλατφόρμες ήταν περίπου τα ίδια. Αυτό μας λέει ότι το Διαδίκτυο στην Κίνα, ακόμη και για μεγάλους φορείς εκμετάλλευσης και παρόχους cloud, συμπεριφέρεται διαφορετικά κατά καιρούς.

Στο προηγούμενο σημείο, θα προσθέσω ένα μεγάλο πλεονέκτημα για το Akamai: εάν ο Ali εμφανίζει παρόμοια φλας υψηλής απόδοσης και πολύ χαμηλής απόδοσης (αυτό ισχύει για Ali CDN, Ali CEN και Ali IPSEC), τότε το Akamai, κάθε φορά, δεν έχει σημασία πώς δοκιμάζω το δίκτυό τους, όλα λειτουργούν σταθερά.
Η Akamai έχει μεγάλη κάλυψη στην Κίνα και λειτουργεί μέσω πολλών παρόχων.

Αυτό που δεν μου άρεσε:

• Δεν μου αρέσει η διεπαφή ιστού και ο τρόπος που λειτουργεί - είναι τόσο κακή. Αλλά βασικά το συνηθίζεις (μάλλον).
• Τα αποτελέσματα των δοκιμών είναι χειρότερα από τον ιστότοπό μας.
• Υπάρχουν περισσότερα σφάλματα κατά τη διάρκεια των δοκιμών από ό,τι στον ιστότοπό μας (χρόνος λειτουργίας παρακάτω).
• Δεν έχουμε δικούς μας διακομιστές DNS στην Κίνα. Ως εκ τούτου, υπάρχουν πολλά σφάλματα στις δοκιμές λόγω του χρονικού ορίου επίλυσης DNS.
• Δεν παρέχουν τις περιοχές IP τους -> δεν υπάρχει τρόπος να καταχωρήσετε τις σωστές set_real_ip_from στους διακομιστές μας.

Μετρήσεις (~3626 εκτελέσεις, όλες οι μετρήσεις εκτός από το Uptime, σε ms, στατιστικά για μία χρονική περίοδο):

Πάροχος CDN
Διάμεσος
75%
95%
Απάντηση
Απάντηση Ιστοσελίδας
Uptime
DNS
Connect
Περιμένετε
Φορτίο
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

Κατανομή ανά εκατοστημόριο (σε ms):

Εκατοστημόριο
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

Το συμπέρασμα είναι το εξής: η επιλογή Akamai είναι βιώσιμη, αλλά δεν παρέχει την ίδια σταθερότητα και ταχύτητα με τη δική μας λύση σε συνδυασμό με το Ali CDN.

Μικρές νότες

Κάποιες στιγμές δεν συμπεριλήφθηκαν στην ιστορία, αλλά θα ήθελα να γράψω και γι' αυτές.

Πεκίνο + Τόκιο και Χονγκ Κονγκ

Όπως είπα παραπάνω, δοκιμάσαμε μια σήραγγα IPSEC στο Χονγκ Κονγκ (HK). Αλλά δοκιμάσαμε επίσης το CEN στο HK. Κοστίζει λίγο λιγότερο, και αναρωτιόμουν πώς θα λειτουργούσε μεταξύ πόλεων με απόσταση ~100 km. Αποδείχθηκε ενδιαφέρον ότι η καθυστέρηση μεταξύ αυτών των πόλεων είναι 100ms υψηλότερη από ό,τι στην αρχική μας έκδοση (προς Ταϊβάν). Η ταχύτητα, η σταθερότητα ήταν επίσης καλύτερες για την Ταϊβάν. Ως αποτέλεσμα, φύγαμε από το HK ως εφεδρική περιοχή IPSEC.

Επιπλέον, προσπαθήσαμε να εγκαταστήσουμε την ακόλουθη εγκατάσταση:

• τερματισμός πελατών στο Πεκίνο,
• IPSEC και CEN στο Τόκιο,
• στο Ali CDN ο διακομιστής στο Πεκίνο αναφέρθηκε ως προέλευση.

Αυτό το σχήμα δεν ήταν τόσο σταθερό, αν και από άποψη ταχύτητας γενικά δεν ήταν κατώτερο από τη λύση μας. Σχετικά με το τούνελ, έχω δει κατά διαστήματα πτώσεις ακόμη και για την CEN, η οποία θα έπρεπε να ήταν σταθερή. Επομένως, επιστρέψαμε στο παλιό σχήμα και διαλύσαμε αυτή τη σταδιοποίηση.

Ακολουθούν στατιστικά στοιχεία σχετικά με τον λανθάνοντα χρόνο μεταξύ διαφορετικών περιοχών για διαφορετικά κανάλια. Ίσως κάποιος ενδιαφέρεται για αυτό.

IPsec
Ali cn-Beijing <—> GCP ασία-βορειοανατολικά1 — 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 — 216 ​​ms

Γενικές πληροφορίες για το Διαδίκτυο στην Κίνα

Ως προσθήκη στα προβλήματα με το Διαδίκτυο που περιγράφηκαν στην αρχή, στο πρώτο μέρος του άρθρου.

• Το Διαδίκτυο στην Κίνα είναι αρκετά γρήγορο στο εσωτερικό.
  • Το συμπέρασμα βγήκε με βάση τη δοκιμή δημόσιων δικτύων Wi-Fi σε διάφορες τοποθεσίες όπου αυτά τα δίκτυα χρησιμοποιούνται από μεγάλο αριθμό ατόμων.
  • Οι ταχύτητες λήψης και μεταφόρτωσης σε διακομιστές εντός της Κίνας ήταν περίπου 20 Mbit/s και 5-10 Mbit/s, αντίστοιχα.
  • Η ταχύτητα σε διακομιστές εκτός Κίνας είναι απλά πενιχρή, μικρότερη από 1 Mbit/s.
• Το Διαδίκτυο στην Κίνα δεν είναι πολύ σταθερό.
  • Μερικές φορές οι ιστότοποι μπορούν να ανοίξουν γρήγορα, μερικές φορές αργά (την ίδια ώρα της ημέρας σε διαφορετικές ημέρες), με την προϋπόθεση ότι η διαμόρφωση δεν αλλάζει. Αυτό το παρατηρήσαμε με το παράδειγμα του semrushchina.cn. Αυτό μπορεί να αποδοθεί στο Ali CDN, το οποίο λειτουργεί επίσης με αυτόν τον τρόπο και ότι ανάλογα με την ώρα της ημέρας, τη θέση των αστεριών κ.λπ.
• Το Mobile Internet είναι σχεδόν παντού 4G ή 4G+. Προλάβετε το στο μετρό, τα ασανσέρ - με λίγα λόγια, παντού.
• Είναι μύθος ότι οι Κινέζοι χρήστες εμπιστεύονται μόνο τομείς στη ζώνη .cn. Αυτό το μάθαμε απευθείας από τους χρήστες.
  • Μπορείτε να δείτε πώς http://baidu.cn ανακατεύθυνση στο www.baidu.com (και στην ηπειρωτική Κίνα).
• Πολλοί πόροι είναι πράγματι αποκλεισμένοι. Primitive: google.com, Facebook, Twitter. Αλλά πολλοί πόροι της Google λειτουργούν (φυσικά, όχι σε όλα τα Wi-Fi και το VPN δεν χρησιμοποιείται (και από την πλευρά του δρομολογητή, αυτό είναι σίγουρο).
• Πολλοί «τεχνικοί» τομείς αποκλεισμένων εταιρειών λειτουργούν επίσης. Αυτό σημαίνει ότι δεν πρέπει πάντα να κόβετε απερίσκεπτα όλους τους πόρους της Google και άλλους φαινομενικά αποκλεισμένους πόρους. Πρέπει να αναζητήσετε κάποια λίστα με απαγορευμένους τομείς.
• Έχουν μόνο τρεις κύριους φορείς εκμετάλλευσης Διαδικτύου: China Unicom, China Telecom, China Mobile. Υπάρχουν και μικρότερα, αλλά το μερίδιο αγοράς τους είναι ασήμαντο

Μπόνους: διάγραμμα τελικής λύσης

Σύνολο

Ένας χρόνος έχει περάσει από την έναρξη του έργου. Ξεκινήσαμε με το γεγονός ότι ο ιστότοπός μας αρνήθηκε γενικά να λειτουργήσει κανονικά από την Κίνα και απλά το GET curl χρειάστηκε 5.5 δευτερόλεπτα.

Στη συνέχεια, με αυτούς τους δείκτες στην πρώτη λύση (Cloudflare):

Λύση
Uptime
Διάμεσος
75 εκατοστημόριο
95 εκατοστημόριο

Cloudflare
86.6
18s
30s
60s

Τελικά καταλήξαμε στα ακόλουθα αποτελέσματα (στατιστικά για τον τελευταίο μήνα):

Λύση
Uptime
Διάμεσος
75 εκατοστημόριο
95 εκατοστημόριο

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

Όπως μπορείτε να δείτε, δεν έχουμε καταφέρει ακόμα να επιτύχουμε 100% χρόνο λειτουργίας, αλλά θα καταλήξουμε σε κάτι και στη συνέχεια θα σας πούμε για τα αποτελέσματα σε ένα νέο άρθρο :)

Σεβασμός σε όσους διάβασαν και τα τρία μέρη μέχρι το τέλος. Ελπίζω να τα βρήκατε όλα αυτά τόσο ενδιαφέροντα όσο εγώ όταν το έκανα.

ΥΓ Προηγούμενα μέρη

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

Πηγή: www.habr.com