Γεια σε όλους!
Ο Nikita είναι σε επαφή - μηχανικός συστήματος από την εταιρεία SEMrush. Σήμερα θα σας πω πώς αντιμετωπίσαμε το καθήκον να διασφαλίσουμε τη σταθερότητα της υπηρεσίας μας semrush.com στην Κίνα και ποια προβλήματα αντιμετωπίσαμε κατά την υλοποίησή της (δεδομένης της τοποθεσίας του κέντρου δεδομένων μας στην ανατολική ακτή των Ηνωμένων Πολιτειών).
Αυτή θα είναι μια μεγάλη ιστορία, χωρισμένη σε πολλά άρθρα. Θα σας πω πώς συνέβησαν όλα για εμάς: από μια εντελώς μη λειτουργική υπηρεσία από την Κίνα, έως δείκτες απόδοσης της υπηρεσίας στο επίπεδο της αμερικανικής έκδοσης για τους Αμερικανούς. Υπόσχομαι ότι θα είναι ενδιαφέρον και χρήσιμο. Πάμε λοιπόν.
Προβλήματα του κινεζικού Διαδικτύου
Ακόμα και το πιο απομακρυσμένο άτομο από τις ιδιαιτερότητες της διαχείρισης δικτύου έχει ακούσει για αυτό Μεγάλο Τείχος προστασίας της Κίνας. Ουάου, ακούγεται ωραίο, σωστά; Αλλά τι είναι και πώς λειτουργεί πραγματικά είναι ένα αρκετά περίπλοκο ερώτημα. Μπορείτε να βρείτε πολλά άρθρα στο Διαδίκτυο αφιερωμένα σε αυτό, αλλά από τεχνική άποψη, η δομή αυτού του τείχους προστασίας δεν περιγράφεται πουθενά. Κάτι που, ωστόσο, δεν προκαλεί έκπληξη. Θα παραδεχτώ αμέσως ότι με βάση τα αποτελέσματα ενός έτους εργασίας, δεν θα μπορώ να πω ακριβώς πώς λειτουργεί, αλλά μπορώ να σας πω για τα σχόλιά μου και τα πρακτικά συμπεράσματά μου. Και θα ξεκινήσουμε με φήμες για αυτό το τείχος προστασίας.
Υπάρχουν πολλές φήμες για αυτό ακριβώς το τείχος προστασίας. Ας συγκεντρώσουμε τα κύρια και πιο ενδιαφέροντα από αυτά σε μια λίστα:
- Το Google, το Facebook, το Twitter και άλλες παρόμοιες υπηρεσίες είναι αποκλεισμένες και δεν λειτουργούν στην Κίνα.
- Οποιαδήποτε κίνηση πηγαίνει ΕΚΤΟΣ Κίνας και ΣΤΗΝ Κίνα αναλύεται και περιορίζεται χρησιμοποιώντας μηχανική εκμάθηση (στην περίπτωση ύποπτης κυκλοφορίας), η οποία επιβραδύνει σημαντικά τη διέλευση της (κυκλοφορίας) μέσω των συνόρων.
- Οι κινεζικές υπηρεσίες πληροφοριών θα χακάρουν κάθε κρυπτογραφημένη κίνηση που διέρχεται από το τείχος προστασίας τους.
- Οι σήραγγες VPN, οι σήραγγες IPSEC είναι ασταθείς, συντρίβονται και μπλοκάρονται συνεχώς.
- Όσο πιο απλή είναι η κρυπτογράφηση, όσο πιο απλή είναι η φράση πρόσβασης που χρησιμοποιείται για τον έλεγχο ταυτότητας/κρυπτογράφηση της κυκλοφορίας, τόσο πιο γρήγορα περνά από το κινεζικό τείχος προστασίας.
Δείτε τι μάθαμε για αυτές τις φήμες:
- Το Google, το Facebook, το Twitter και άλλες παρόμοιες υπηρεσίες είναι πράγματι αποκλεισμένες (το KO σας), αλλά πολλοί τεχνικοί τομείς της Google, για παράδειγμα, δεν είναι αποκλεισμένοι και λειτουργούν (το ίδιο gstatic.com). Το συμπέρασμα προκύπτει από αυτό: δεν πρέπει να κόψετε απερίσκεπτα όλους τους πόρους της Google και άλλους πόρους που φαίνεται να είναι αποκλεισμένοι.
- Οποιαδήποτε κίνηση διέρχεται από τα σύνορα πραγματικά προσθέτει σοβαρή καθυστέρηση στην ώρα της. Δείτε τα δύο αποτελέσματα. Ένας ιστότοπος, μία σελίδα, απλό GET μπούκλαΩμ. Η πρώτη μέτρηση ήταν από την ίδια την Κίνα (την όμορφη πόλη Shenzhen). Το δεύτερο μετρήθηκε από έξω από το Χονγκ Κονγκ (έχει κυριαρχία και δεν υπάρχει τείχος προστασίας μεταξύ αυτού και του κόσμου). Η απόσταση μεταξύ των πόλεων σε ευθεία γραμμή είναι περίπου 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sΔώστε προσοχή time_connect. Και γενικά, βλέπετε το αποτέλεσμα: το τείχος προστασίας προσθέτει 4 επιπλέον δευτερόλεπτα, τα οποία είναι τερατώδες.
- Οι σήραγγες VPN και IPSEC αποτυγχάνουν συχνά. Θα μιλήσω για αυτό λίγο αργότερα και πιο αναλυτικά. Οι διακομιστές VPN που χρησιμοποιούνται από τους χρήστες αποκλείονται με την πάροδο του χρόνου (συνήθως εντός μιας ημέρας μετά την έναρξη χρήσης).
- Υπάρχει μια άποψη που ελήφθη από ανθρώπους που ζουν στην Κίνα ότι όσο πιο απλή είναι η κρυπτογράφηση της κυκλοφορίας, τόσο πιο γρήγορα περνάει από τα σύνορα, γιατί είναι εύκολο να καταλάβει κανείς ότι δεν υπάρχει τίποτα παράνομο σε αυτό. Και με τον ίδιο τρόπο, η «καθαρή» κίνηση λαμβάνει περισσότερο εύρος ζώνης και ταχύτητα διέλευσης, ενώ η «βρώμικη» κίνηση, στην οποία τίποτα δεν μπορεί να γίνει κατανοητό, δέχεται, αντίθετα, μια πιο αργή διέλευση. Για παράδειγμα θα χρησιμοποιήσω το curl to ifconfig.co μέσω HTTPS και πρωτοκόλλου HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sΔιαφορά 5 δευτερολέπτων για συνολικό χρόνο λήψης 13 byte. Επιπλέον, όταν κάνετε μια τέτοια δοκιμή πολλές φορές, μπορείτε να παρατηρήσετε ότι το GET στο HTTP ολοκληρώνεται γενικά την ίδια ώρα κάθε φορά, ενώ στο HTTPS ο ιστότοπος αποκρίνεται μερικές φορές σε 3, 5, 10 ακόμη και 17 δευτερόλεπτα. Μερικές φορές συμβαίνουν σφάλματα SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Λοιπόν τι έχουμε:
- Τα προβλήματα που δημιουργούνται από το κινεζικό τείχος προστασίας περιγράφονται παραπάνω.
- Τα ping σε εξωτερικούς πόρους και μέσα σε σήραγγες εξαφανίζονται περιοδικά.
- Η καθυστέρηση μεταξύ δύο σημείων αλλάζει συνεχώς και συχνά είναι απλά απρόβλεπτη. Όταν συνδέετε διαφορετικές πόλεις/περιοχές, αναμένετε ότι, με βάση τη γεωγραφική θέση των περιοχών, η καθυστέρηση θα είναι μικρότερη, αλλά έχετε ακριβώς την αντίθετη κατάσταση.
- Το Διαδίκτυο και τα κανάλια επικοινωνίας είναι είτε γρήγορα είτε αργά. Υπάρχει μια μικρή εξάρτηση από την ώρα της ημέρας και την ημέρα της εβδομάδας, αλλά όχι πάντα.
- Τα αιτήματα DNS προς τον έξω κόσμο από την Κίνα μερικές φορές υπερβαίνουν το επιτρεπόμενο χρονικό όριο.
Η εικόνα που προκύπτει είναι απλά «εξαιρετική».
Το κέντρο δεδομένων, όπως είπα ήδη, βρίσκεται στις ανατολικές Ηνωμένες Πολιτείες και ολόκληρο το SEMrush αποτελείται από δεκάδες διασυνδεδεμένα προϊόντα, backends, frontends, βάσεις δεδομένων και όλα αυτά στο DC και στα cloud. Εμείς, ως ομάδα διαχειριστών συστημάτων, αναλάβαμε το καθήκον να ξεκινήσουμε γρήγορα να εργαζόμαστε στην Κίνα με λίγη προσπάθεια.
Έπρεπε να απαντήσουμε σε μια σημαντική ερώτηση: είναι δυνατόν να τα βγάλουμε πέρα με λίγα έξοδα και να λύσουμε όλα τα προβλήματα που σχετίζονται με το κινεζικό Διαδίκτυο και το τείχος προστασίας σε επίπεδο δικτύου/σύννεφου/διακομιστή;
Ξεκινήσαμε λαμβάνοντας .
Άδεια ICP
Για να μπορέσετε να φιλοξενήσετε την υπηρεσία σας εντός της Κίνας (ηπειρωτική Κίνα) και να πραγματοποιήσετε δοκιμές, πρέπει πρώτα να αποκτήσετε άδεια ICP για τον τομέα.
Εάν η επισκεψιμότητα χρηστών του ιστότοπού σας τερματιστεί εντός της ηπειρωτικής Κίνας και εάν ο τομέας σας δεν διαθέτει άδεια ICP, η επισκεψιμότητά σας θα αποκλειστεί από την πλευρά του ISP/φιλοξενίας. Είναι ενδιαφέρον ότι η άδεια ICP περιλαμβάνει έναν συγκεκριμένο πάροχο, είτε είναι Cloudflare είτε Alibaba Cloud. Επομένως, εάν λάβατε άδεια ICP για το Cloudflare και φιλοξενήσατε τον ιστότοπό σας μαζί τους, δεν θα μπορείτε να μετακινηθείτε «απρόσκοπτα» στο Alibaba Cloud. Θα χρειαστεί να προσθέσετε άλλη φιλοξενία σε αυτήν την άδεια.
Έχοντας λάβει άδεια ICP για τον τομέα, μπορέσαμε να βρούμε και να εφαρμόσουμε συγκεκριμένες τεχνικές ιδέες και λύσεις.
Δοκιμαστικές λύσεις
Προτού όμως δημιουργήσετε απευθείας επιλογές σταδιοποίησης, γυρίσετε τα κουμπιά, βελτιστοποιήσετε την απόδοση και την ταχύτητά του, πρέπει να επιλέξετε ένα εργαλείο για να τον δοκιμάσετε, προκειμένου να δείτε ποιες από τις ενέργειές μας βελτιώνουν ή, αντίθετα, επιδεινώνουν την απόδοση του ιστότοπου.
Το εργαλείο δοκιμών μας έπρεπε να πληροί δύο βασικές απαιτήσεις:
- θα πρέπει να μπορεί να εκτελεί δοκιμές από την Κίνα,
- πρέπει να έχει δοκιμές προγράμματος περιήγησης.
Βρήκαμε λοιπόν ! Έχουν εξαιρετική κάλυψη τοποθεσιών δοκιμών σε όλο τον κόσμο. Στην Κίνα, μέσω αυτού του εργαλείου μπορούν επίσης να πραγματοποιηθούν δοκιμές από 100500 επαρχίες. Το καθένα έχει πολλούς διαφορετικούς παρόχους + τη δυνατότητα να κάνει Σπονδυλική στήλη-δοκιμές (κάτι σαν εικονική μηχανή σε κέντρο δεδομένων) και Τελευταίο μίλι-δοκιμές (όσο το δυνατόν πιο κοντά στις συνθήκες χρήστη, γνωστός και ως σταθμός εργασίας). Ο τελευταίος τύπος δοκιμών είναι πιο ακριβός.
Έχοντας συνάψει μια ετήσια σύμβαση (λιγότερο από αυτό δεν είναι δυνατό), αρχίσαμε να μελετάμε το όργανο. Ειλικρινά, μας εξέπληξε ευχάριστα η λειτουργικότητά του. Μπορείτε να τρέξετε:
- Δοκιμές DNS,
- Δοκιμές Ιστού (δοκιμές προγράμματος περιήγησης, απλό GET/POST, εξομοίωση πελάτη για κινητά κ.λπ.),
- Έλεγχοι συναλλαγών (για παράδειγμα, σύνδεση),
- Δοκιμές API,
- Ping, traceroute, NTP κ.λπ.
Δεν μπορείς να τα αναφέρεις όλα. Και το πιο σημαντικό, κάθε δοκιμή μπορεί να προσαρμοστεί αρκετά καλά προσθέτοντας μια δέσμη κεφαλίδων και άλλων παραμέτρων. Η έξοδος είναι ένας τεράστιος όγκος πληροφοριών που περιγράφει πλήρως τη δοκιμή σας. Αν μιλάμε για τα πιο ενδιαφέροντα πράγματα για εμάς (δοκιμές προγράμματος περιήγησης), το αποτέλεσμα περιλαμβάνει:
- Σύνδεση, Αναμονή, Φόρτωση, SSL, χρόνος DNS,
- TTFB, TTLB, Το έγγραφο ολοκληρώθηκε, χρόνος απόδοσης, φόρτωση DOM,
- Απόκριση (κάτι κοντά στο Time To First Byte), Απόκριση Ιστοσελίδας (κάτι κοντά στο Time To Last Byte),
- Οποιοδήποτε εκατοστημόριο, Μέσος όρος, Διάμεσος χρόνος
- Κ.λπ.
Κατά συνέπεια, όλες αυτές οι μετρήσεις είναι εξαιρετικές για να βλέπετε αλλαγές και να κατανοείτε εάν τα πράγματα έχουν βελτιωθεί. Κυρίως κοιτάξαμε Απόκριση, Απόκριση Ιστοσελίδας, Διάμεσος, 75 και 95 εκατοστιαίες μονάδες.
Ένα σημαντικό ερώτημα που ήταν στον αέρα από την αρχή: Μπορείτε να εμπιστευτείτε το Catchpoint;? Αυτό το εργαλείο αντικατοπτρίζει την πραγματική ταχύτητα φόρτωσης ιστότοπου στην Κίνα από διαφορετικές πόλεις ή είναι απλώς κάποιο είδος δοκιμής σε κενό που δεν έχει καμία σχέση με την πραγματική εμπειρία χρήστη;
Αυτό είναι ένα μεγάλο πρόβλημα, επειδή βρίσκοντας στη Ρωσία είναι σχεδόν αδύνατο να μάθετε αξιόπιστα πώς λειτουργεί ένας ιστότοπος από την Κίνα. Κάνοντας ένα socks-proxy μέσω μιας εικονικής μηχανής, το τελικό αποτέλεσμα είναι ότι ο ιστότοπος φορτώνει μέσα σε λίγα λεπτά, κάτι που είναι απλά απαράδεκτο για δοκιμές, επομένως η μόνη επιλογή για χειροκίνητη δοκιμή είναι το curl και το απλό ΛΗΨΗ από την κονσόλα με χρονοδιακόπτη . Αυτό βοηθά επειδή αυτή η δοκιμή αντικατοπτρίζει καλά την ταχύτητα της λύσης δικτύου και αν υπάρχουν επίσης δοκιμές προγράμματος περιήγησης, τότε είναι πολύ καλό.
Αργότερα πήγαμε εμείς οι ίδιοι στην Κίνα και πειστήκαμε αυτό Μπορείτε να εμπιστευτείτε το Catchpoint αντανακλά με ακρίβεια τους πραγματικούς δείκτες απόδοσης.
Cloudflare China Network
Δεδομένου ότι χρησιμοποιούμε με επιτυχία το Cloudflare για τον κύριο τομέα semrush.com, αποφασίσαμε να δοκιμάσουμε αμέσως τη λειτουργία τους που ονομάζεται . Αυτή η επιλογή είναι ενεργοποιημένη μόνο για τοποθεσίες Enterprise κατόπιν ξεχωριστού αιτήματος και με επιπλέον χρέωση. Είναι επίσης διαθέσιμο μόνο σε ιστότοπους που διαθέτουν κατάλληλη άδεια ICP που αναφέρει το Cloudflare ως πάροχο. Μετά την ενεργοποίησή του, το "Κινεζικό CDN" από το Cloudflare γίνεται διαθέσιμο για τον ιστότοπο - η κίνηση από τις κινεζικές περιοχές προσγειώνεται στο πλησιέστερο PoP (Points of Presence) CF και, στη συνέχεια, μέσω των δικτύων του ή των δικτύων παρόχων/συνεργατών παραδίδεται στην προέλευση .
Το διάγραμμα αυτού του πάγκου δοκιμών παρουσιάζεται παρακάτω.
Αυτή είναι μια εξαιρετική επιλογή για εμάς. Αποδεικνύεται ότι ο δεύτερος τομέας θα είναι επίσης για CF, το οποίο δεν προσθέτει στον αριθμό των λύσεων που χρησιμοποιούνται στην εταιρεία και επίσης πρακτικά δεν περιπλέκει την υποδομή.
Πραγματοποιήσαμε δοκιμές προγράμματος περιήγησης και συνέβη αυτό:
Τα κόκκινα διαμάντια είναι αποτυχίες δοκιμών. Τα παρακάτω αρχεία είναι σφάλματα DNS (επίλυση χρονικού ορίου λήξης). Οι αποτυχίες στην κορυφή είναι τάιμ άουτ.
Χρόνος λειτουργίας: 86.6
Διάμεσος: 18 δευτ
75 εκατοστημόριο: 29.3s
95 εκατοστημόριο: 60s
Διάμεσος, αφού αφαιρέθηκε η φόρτωση recaptcha (Η υπηρεσία Google αποκλεισμένη στην Κίνα) μειώθηκε από 28 σε 18 δευτερόλεπτα. Αλλά αυτά είναι ακόμα τρομερά αποτελέσματα, λαμβάνοντας υπόψη ότι η ίδια δοκιμή για το semrush.com (από τις ΗΠΑ) έδωσε λιγότερο από 10 δευτερόλεπτα για το 95% των χρηστών (από τις ΗΠΑ) στην ίδια σελίδα (στατική + δυναμική).
Μπορείτε να μπείτε σε κάθε δοκιμή και να κοιτάξετε Υδατόπτωση και άλλες πιο λεπτομερείς παραμέτρους. Αρχίσαμε να διερευνούμε τους λόγους των σφαλμάτων και αν για τα χρονικά όρια όλα είναι λίγο πολύ ξεκάθαρα: το Διαδίκτυο στην Κίνα «μπαίνει και βγαίνει», εξαιτίας αυτού η ταχύτητα σύνδεσης και φόρτωσης πόρων από το εξωτερικό είναι ασταθής και άνιση, τότε τα σφάλματα DNS μας εξέπληξαν πολύ. Το βρήκαμε Κρότος Το Cloudflare βρίσκεται στην πραγματικότητα στην Κίνα, η διεύθυνση του ιστότοπου επιλύεται σε μία anycast IP, αλλά οι διακομιστές DNS είναι αμερικανικοί, γι' αυτό τα αιτήματα DNS αναγκάζονται να περάσουν από τα σύνορα, επομένως μερικές φορές αποτυγχάνουν.
Έχοντας διευκρινίσει αυτή την ερώτηση με την ΚΙ, αποδείχθηκε ότι Δεν έχουν δικούς τους διακομιστές DNS στην Κίνα, και πότε θα είναι είναι ακόμα άγνωστο.
Ως εκ τούτου, αποφασίσαμε να δοκιμάσουμε μόνο το Cloudflare DNS και αλλάξαμε τον μηχανισμό λειτουργίας Cloudflare για τον ιστότοπό μας σε "Μόνο DNS" Αυτή είναι μια λειτουργία κατά την οποία το Cloudflare δεν εκτελεί την κυκλοφορία μεσολάβησης μέσω του εαυτού του, πράγμα που σημαίνει ότι δεν παρέχει προστασία DDoS, CDN και άλλες δυνατότητες και λειτουργεί στη λειτουργία ενός κανονικού διακομιστή DNS.
Αυτή η βάση φαίνεται σχηματικά στο παρακάτω σχήμα. Το σχήμα λαμβάνει υπόψη την αναδυόμενη γνώση ότι οι διακομιστές DNS του Cloudflare βρίσκονται πίσω από ένα τείχος προστασίας.
Στο Catchpoint πραγματοποιήσαμε απλές δοκιμές GET (όχι δοκιμές προγράμματος περιήγησης), οι οποίες έδειξαν πολλές αποτυχίες. Προκλήθηκαν από τα ίδια σφάλματα DNS.
Ξεκινήσαμε τον εντοπισμό σφαλμάτων αυτών των σφαλμάτων χρησιμοποιώντας σκάβω και διαπίστωσε ότι με το πρώτο αίτημα η διεύθυνση καθορίζεται σωστά, και μετά από επαναλαμβανόμενη αίτηση λαμβάνουμε κάθε φορά ΣΕΡΒΦΑΪΛ и δεν βρέθηκε. Γιατί συμβαίνει αυτό ξαφνικά;
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Δεν υπάρχουν τέτοια σφάλματα κατά την απευθείας αναζήτηση διακομιστών Cloudflare NS:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192Αυτό σημαίνει ότι το πρόβλημα βρίσκεται στην πλευρά του "τοπικού" διακομιστή DNS ή του διακομιστή του παρόχου.
Περαιτέρω έρευνα αποκάλυψε ότι ΣΕΡΒΦΑΪΛ έχουμε αποφασιστικότητα ΑΑΑΑ- αρχεία.
Αποδείχθηκε ότι όταν ζητήθηκε από το Cloudflare ΑΑΑΑ-εγγραφή που δεν υπάρχει στον τομέα, απάντησε το Cloudflare А-μια καταχώρηση που αποτελεί σφάλμα και μη συμμόρφωση με το RFC. Γιατί ο τοπικός επιλύτης (χχχχ) Δεν μου άρεσε, και απάντησε ΣΕΡΒΦΑΪΛ. Αυτή η συμπεριφορά είναι σαφώς ορατή στο παρακάτω αρχείο καταγραφής:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE rcvd: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Υποβάλαμε μια αναφορά σφάλματος στο Cloudflare και το διόρθωσαν μετά από κάποιο χρονικό διάστημα. Αποδείχθηκε ενδιαφέρον: αυτή τη στιγμή δεν υπάρχει ακόμα υποστήριξη IPv6 στην Κίνα, επομένως το Cloudflare δεν μπορούσε να εκδώσει τη διεύθυνση IPv6 του εκεί ως απάντηση σε ένα αίτημα ΑΑΑΑ- αρχεία. Τελικά όλα λύθηκαν με τέτοιο τρόπο που η Cloudflare άρχισε να απαντά για την Κίνα ΧΩΡΙΣ ΔΕΔΟΜΕΝΑ σε τέτοια αιτήματα.
Έτσι, τα σφάλματα DNS στις δοκιμές Catchpoint μειώθηκαν απότομα, αλλά όχι εντελώς. Τα τάιμ άουτ είναι ακόμα εδώ:
Και αρχίσαμε να ψάχνουμε άλλη λύση.
Στο επόμενο μέρος θα σας πω πώς δοκιμάσαμε το κινέζικο σύννεφο Alibaba Cloud, πώς, με τη βοήθεια μιας μικρής «μαγείας» του Nginx, μπορέσαμε να δημιουργήσουμε γρήγορα λύσεις PoC (Proof of Concept), πώς δημιουργήσαμε λύσεις Multi-Cloud, μία από τις οποίες τελικά βοήθησε σημαντικά στην επιτάχυνση του έργου της υπηρεσίας από την Κίνα.
Μείνετε συντονισμένοι!
Επόμενα μέρη
Πηγή: www.habr.com
