Η χαμηλή καθυστέρηση DNS είναι το κλειδί για γρήγορη περιήγηση. Για να το ελαχιστοποιήσετε, είναι σημαντικό να επιλέξετε προσεκτικά τους διακομιστές DNS και . Αλλά το πρώτο πράγμα που πρέπει να κάνετε είναι να απαλλαγείτε από άχρηστα ερωτήματα.
Αυτός είναι ο λόγος για τον οποίο το DNS σχεδιάστηκε αρχικά ως ένα πρωτόκολλο με υψηλή δυνατότητα προσωρινής αποθήκευσης. Οι διαχειριστές ζωνών ορίζουν ένα χρονικό διάστημα ζωής (TTL) για μεμονωμένες εγγραφές και οι αναλυτές χρησιμοποιούν αυτές τις πληροφορίες κατά την αποθήκευση εγγραφών στη μνήμη για να αποφύγουν την περιττή κίνηση.
Είναι αποτελεσματική η προσωρινή αποθήκευση; Πριν από μερικά χρόνια, η μικρή μου έρευνα έδειξε ότι δεν ήταν τέλειο. Ας ρίξουμε μια ματιά στην τρέχουσα κατάσταση πραγμάτων.
Για να συλλέξω πληροφορίες που διόρθωσα για να αποθηκεύσετε την τιμή TTL για την απόκριση. Ορίζεται ως το ελάχιστο TTL των εγγραφών του, για κάθε εισερχόμενο αίτημα. Αυτό παρέχει μια καλή επισκόπηση της κατανομής TTL της πραγματικής επισκεψιμότητας και λαμβάνει επίσης υπόψη τη δημοτικότητα μεμονωμένων ερωτημάτων. Η ενημερωμένη έκδοση του διακομιστή λειτούργησε για αρκετές ώρες.
Το σύνολο δεδομένων που προκύπτει αποτελείται από 1 εγγραφές (όνομα, τύπος q, TTL, χρονική σήμανση). Εδώ είναι η συνολική κατανομή TTL (ο άξονας x είναι TTL σε δευτερόλεπτα):
Εκτός από μια μικρή αύξηση στα 86 (κυρίως για αρχεία SOA), είναι αρκετά προφανές ότι τα TTL βρίσκονται στο χαμηλό εύρος. Ας ρίξουμε μια πιο προσεκτική ματιά:
Εντάξει, τα TTL άνω της 1 ώρας δεν είναι στατιστικά σημαντικά. Ας επικεντρωθούμε λοιπόν στο εύρος 0-3600:
Τα περισσότερα TTL είναι μεταξύ 0 και 15 λεπτών:
Η συντριπτική πλειοψηφία είναι από 0 έως 5 λεπτά:
Αυτό δεν είναι πολύ καλό.
Η αθροιστική κατανομή καθιστά το πρόβλημα ακόμη πιο προφανές:
Οι μισές από τις απαντήσεις DNS έχουν TTL 1 λεπτού ή λιγότερο και τα τρία τέταρτα έχουν TTL 5 λεπτών ή λιγότερο.
Αλλά περιμένετε, είναι στην πραγματικότητα χειρότερα. Άλλωστε, αυτό είναι TTL από έγκυρους διακομιστές. Ωστόσο, οι αναλυτές-πελάτες (π.χ. δρομολογητές, τοπικές προσωρινές μνήμες) λαμβάνουν TTL από τους αναλυτές upstream και αυτό μειώνεται κάθε δευτερόλεπτο.
Έτσι, ο πελάτης μπορεί στην πραγματικότητα να χρησιμοποιήσει κάθε εγγραφή για, κατά μέσο όρο, το μισό του αρχικού TTL πριν στείλει ένα νέο αίτημα.
Ίσως αυτά τα πολύ χαμηλά TTL επηρεάζουν μόνο ασυνήθιστα αιτήματα και όχι δημοφιλείς ιστότοπους και API; Ας ρίξουμε μια ματιά:
Ο άξονας X είναι το TTL, ο άξονας Y είναι η δημοτικότητα ερωτημάτων.
Δυστυχώς, τα πιο δημοφιλή ερωτήματα είναι επίσης τα χειρότερα αποθηκευμένα στην προσωρινή μνήμη.
Ας κάνουμε ζουμ σε:
Ετυμηγορία: Είναι πραγματικά άσχημο. Ήταν ήδη άσχημα πριν, αλλά έγινε ακόμη χειρότερα. Η προσωρινή αποθήκευση DNS έχει γίνει σχεδόν άχρηστη. Καθώς λιγότεροι άνθρωποι χρησιμοποιούν τον αναλυτή DNS του παρόχου υπηρεσιών Διαδικτύου (ISP) τους (για καλούς λόγους), η αύξηση της καθυστέρησης γίνεται πιο αισθητή.
Η προσωρινή αποθήκευση DNS έχει γίνει χρήσιμη μόνο για περιεχόμενο που δεν επισκέπτεται κανείς.
Λάβετε επίσης υπόψη ότι το λογισμικό ενδέχεται να ερμηνεύουν τα χαμηλά TTL.
Γιατί έτσι;
Γιατί οι εγγραφές DNS έχουν οριστεί σε τόσο μικρό TTL;
- Οι παλαιότεροι εξισορροπητές φορτίου παραμένουν με τις προεπιλεγμένες ρυθμίσεις.
- Υπάρχουν μύθοι ότι η εξισορρόπηση φορτίου DNS εξαρτάται από το TTL (αυτό δεν ισχύει - από το Netscape Navigator, οι υπολογιστές-πελάτες επιλέγουν μια τυχαία διεύθυνση IP από το σύνολο RR και δοκιμάζουν προφανώς μια άλλη αν δεν μπορούν να συνδεθούν)
- Οι διαχειριστές θέλουν να εφαρμόζουν τις αλλαγές αμέσως, επομένως είναι πιο εύκολο να προγραμματίσουν.
- Ο διαχειριστής ενός διακομιστή DNS ή ενός εξισορροπητή φορτίου θεωρεί την εργασία του ως αποτελεσματική ανάπτυξη της ρύθμισης παραμέτρων που ζητούν οι χρήστες και όχι ως επιτάχυνση της λειτουργίας ιστότοπων και υπηρεσιών.
- Το χαμηλό TTL προσφέρει ηρεμία.
- Οι άνθρωποι αρχικά ορίζουν χαμηλά TTL για δοκιμές και μετά ξεχνούν να τα αλλάξουν.
Δεν συμπεριέλαβα την "ανατροπή" στη λίστα επειδή αρχίζει να γίνεται λιγότερο σχετική. Εάν χρειάζεται να ανακατευθύνετε τους χρήστες σε άλλο δίκτυο μόνο και μόνο για να εμφανιστεί μια σελίδα σφάλματος όταν απολύτως όλα τα άλλα είναι προβληματικά, μια καθυστέρηση μεγαλύτερη του 1 λεπτού είναι πιθανώς αποδεκτή.
Επιπλέον, το TTL ενός λεπτού σημαίνει ότι εάν οι έγκυροι διακομιστές DNS αποκλειστούν για περισσότερο από 1 λεπτό, κανείς άλλος δεν θα μπορεί να έχει πρόσβαση σε εξαρτημένες υπηρεσίες. Και ο πλεονασμός δεν θα βοηθήσει αν η αιτία είναι σφάλμα διαμόρφωσης ή κάποιο hack. Από την άλλη πλευρά, με λογικά TTL, πολλοί πελάτες θα συνεχίσουν να χρησιμοποιούν την προηγούμενη διαμόρφωση και δεν θα παρατηρήσουν ποτέ τίποτα.
Τα χαμηλά TTL οφείλονται σε μεγάλο βαθμό στις υπηρεσίες CDN και στους εξισορροπητές φορτίου, ειδικά όταν συνδυάζουν CNAME με χαμηλά TTL και εγγραφές με εξίσου χαμηλά (αλλά ανεξάρτητα) TTL:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Κάθε φορά που λήγει το CNAME ή οποιαδήποτε από τις εγγραφές A, πρέπει να αποστέλλεται ένα νέο αίτημα. Και τα δύο έχουν TTL 30 δευτερολέπτων, αλλά δεν είναι το ίδιο. Ο πραγματικός μέσος χρόνος TTL θα είναι 15 δευτερόλεπτα.
Αλλά περιμένετε! Είναι ακόμη χειρότερο. Μερικοί αναλυτές συμπεριφέρονται πολύ άσχημα σε αυτήν την περίπτωση με δύο συνδεδεμένα χαμηλά TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 ΣΤΟ CNAME github.map.fastly.net. github.map.fastly.net. 1 ΣΤΟ A 151.101.16.133
Ο αναλυτής επιπέδου 3 πιθανώς εκτελείται σε BIND. Αν συνεχίσετε να στέλνετε αυτό το αίτημα, θα επιστρέφει πάντα TTL 1. Ουσιαστικά, raw.githubusercontent.com δεν αποθηκεύτηκε ποτέ στην προσωρινή μνήμη.
Ακολουθεί ένα άλλο παράδειγμα αυτής της κατάστασης με ένα πολύ δημοφιλές domain:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Τουλάχιστον τρεις εγγραφές CNAME. Ναι. Το ένα έχει αξιοπρεπές TTL, αλλά είναι εντελώς άχρηστο. Σε άλλα CNAME το αρχικό TTL είναι 60 δευτερόλεπτα, αλλά για domains akamai.net Το μέγιστο TTL είναι 20 δευτερόλεπτα και κανένα από αυτά δεν είναι σε φάση.
Τι γίνεται με τα domains που συνεχώς κάνουν δημοσκοπήσεις σε συσκευές Apple;
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Το ίδιο πρόβλημα με τον Firefox και το TTL που κολλάνε στο 1 δευτερόλεπτο τις περισσότερες φορές όταν χρησιμοποιείται ο αναλυτής επιπέδου 3.
Dropbox;
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 ΣΤΟ CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 ΣΕ A 162.125.67.3 $ τρυπάνι client.dropbox.com @4.2.2.2 client.dropbox.com. 1 ΣΤΟ CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 ΣΤΟ A 162.125.64.3
Στην ηχογράφηση safebrowsing.googleapis.com Η τιμή TTL είναι 60 δευτερόλεπτα, όπως και για τα domains του Facebook. Και πάλι, από την άποψη του πελάτη, αυτές οι τιμές μειώνονται στο μισό.
Τι θα λέγατε να ορίσετε ένα ελάχιστο TTL;
Χρησιμοποιώντας το όνομα, τον τύπο αιτήματος, το TTL και την αρχικά αποθηκευμένη χρονική σήμανση, έγραψα ένα σενάριο για την προσομοίωση 1,5 εκατομμυρίου αιτημάτων που διέρχονται από έναν αναλυτή προσωρινής αποθήκευσης, ώστε να εκτιμηθεί ο αριθμός των επιπλέον αιτημάτων που αποστέλλονται λόγω μιας ληγμένης καταχώρησης προσωρινής αποθήκευσης.
Το 47,4% των αιτημάτων υποβλήθηκαν μετά τη λήξη του υφιστάμενου αρχείου. Αυτό είναι αδικαιολόγητα υψηλό.
Ποιες θα είναι οι επιπτώσεις στην προσωρινή αποθήκευση εάν οριστεί ένα ελάχιστο TTL;
Ο άξονας Χ είναι οι ελάχιστες τιμές TTL. Οι εγγραφές με αρχικά TTL πάνω από αυτήν την τιμή δεν επηρεάζονται.
Ο άξονας Y είναι το ποσοστό των αιτημάτων από έναν υπολογιστή-πελάτη που έχει ήδη μια καταχώρηση αποθηκευμένη στην προσωρινή μνήμη, αλλά έχει λήξει και υποβάλλει ένα νέο αίτημα.
Το μερίδιο των «επιπλέον» αιτημάτων μειώνεται από 47% σε 36% απλώς ορίζοντας τον ελάχιστο χρόνο λήξης (TTL) στα 5 λεπτά. Ορίζοντας ελάχιστο χρόνο TTL 15 λεπτών, ο αριθμός αυτών των αιτημάτων μειώνεται στο 29%. Ένας ελάχιστος χρόνος TTL 1 ώρας τα μειώνει στο 17%. Σημαντική διαφορά!
Τι θα λέγατε να μην αλλάξουμε τίποτα στην πλευρά του διακομιστή, αλλά να ορίσουμε τα ελάχιστα TTL στις προσωρινές μνήμες DNS του πελάτη (δρομολογητές, τοπικοί αναλυτές);
Ο αριθμός των απαιτούμενων αιτημάτων μειώνεται από 47% σε 34% όταν ορίζεται ελάχιστος χρόνος TTL 5 λεπτών, σε 25% με ελάχιστο χρόνο 15 λεπτών και σε 13% με ελάχιστο χρόνο 1 ώρας. Ίσως η βέλτιστη τιμή είναι 40 λεπτά.
Ο αντίκτυπος αυτής της ελάχιστης αλλαγής είναι τεράστιος.
Ποιες είναι οι συνέπειες;
Φυσικά, η υπηρεσία μπορεί να μετεγκατασταθεί σε έναν νέο πάροχο cloud, έναν νέο διακομιστή, ένα νέο δίκτυο, απαιτώντας από τους πελάτες να χρησιμοποιούν τις πιο πρόσφατες εγγραφές DNS. Και ένα αρκετά μικρό TTL βοηθάει ώστε μια τέτοια μετάβαση να γίνει ομαλά και ανεπαίσθητα. Αλλά με τη μετάβαση σε μια νέα υποδομή, κανείς δεν περιμένει από τους πελάτες να μεταβούν σε νέες εγγραφές DNS εντός 1 λεπτού, 5 λεπτών ή 15 λεπτών. Ο ορισμός της ελάχιστης διάρκειας ζωής σε 40 λεπτά αντί για 5 λεπτά δεν θα εμποδίσει τους χρήστες να έχουν πρόσβαση στην υπηρεσία.
Ωστόσο, αυτό θα μειώσει σημαντικά την καθυστέρηση και θα βελτιώσει το απόρρητο και την αξιοπιστία αποφεύγοντας τα περιττά αιτήματα.
Φυσικά, τα RFC αναφέρουν ότι το TTL πρέπει να τηρείται αυστηρά. Αλλά η πραγματικότητα είναι ότι το σύστημα DNS έχει γίνει πολύ αναποτελεσματικό.
Εάν εργάζεστε με αξιόπιστους διακομιστές DNS, ελέγξτε τα TTL σας. Χρειάζεστε πραγματικά τόσο γελοία χαμηλές τιμές;
Φυσικά, υπάρχουν βάσιμοι λόγοι για τον ορισμό μικρών TTL για εγγραφές DNS. Αλλά όχι για το 75% της κίνησης DNS που παραμένει ουσιαστικά αμετάβλητο.
Και αν για κάποιο λόγο χρειάζεται πραγματικά να χρησιμοποιήσετε χαμηλά TTL για DNS, βεβαιωθείτε επίσης ότι η προσωρινή αποθήκευση δεν είναι ενεργοποιημένη στον ιστότοπό σας. Για τους ίδιους λόγους.
Εάν έχετε εκτελεσμένη μια τοπική προσωρινή μνήμη DNS, όπως π.χ. , το οποίο σας επιτρέπει να ορίσετε το ελάχιστο TTL, χρησιμοποιήστε αυτήν τη συνάρτηση. Αυτό είναι εντάξει. Τίποτα κακό δεν θα συμβεί. Ρυθμίστε το ελάχιστο TTL σε περίπου 40 λεπτά (2400 δευτερόλεπτα) και 1 ώρα. Αρκετά λογικό εύρος.
Πηγή: www.habr.com
