Η χαμηλή καθυστέρηση DNS είναι το κλειδί για τη γρήγορη περιήγηση στο Διαδίκτυο. Για να το ελαχιστοποιήσετε, είναι σημαντικό να επιλέξετε προσεκτικά διακομιστές DNS και . Αλλά το πρώτο βήμα είναι να απαλλαγούμε από άχρηστα ερωτήματα.
Αυτός είναι ο λόγος για τον οποίο το DNS σχεδιάστηκε αρχικά ως πρωτόκολλο υψηλής προσωρινής αποθήκευσης. Οι διαχειριστές ζωνών ορίζουν μια ώρα ζωής (TTL) για μεμονωμένες καταχωρίσεις και οι επιλύτες χρησιμοποιούν αυτές τις πληροφορίες όταν αποθηκεύουν καταχωρήσεις στη μνήμη για να αποφύγουν την περιττή κίνηση.
Είναι αποτελεσματική η προσωρινή αποθήκευση; Πριν από μερικά χρόνια, η μικρή μου έρευνα έδειξε ότι δεν ήταν τέλειο. Ας ρίξουμε μια ματιά στην τρέχουσα κατάσταση των πραγμάτων.
Για να συλλέξω πληροφορίες έχω επιδιορθώσει για να αποθηκεύσετε την τιμή TTL για την απόκριση. Ορίζεται ως το ελάχιστο TTL των εγγραφών του για κάθε εισερχόμενο αίτημα. Αυτό παρέχει μια καλή επισκόπηση της κατανομής TTL της πραγματικής επισκεψιμότητας και λαμβάνει επίσης υπόψη τη δημοτικότητα των μεμονωμένων αιτημάτων. Η επιδιορθωμένη έκδοση του διακομιστή λειτούργησε για αρκετές ώρες.
Το σύνολο δεδομένων που προκύπτει αποτελείται από 1 εγγραφές (όνομα, qtype, TTL, timestamp). Ακολουθεί η συνολική κατανομή TTL (ο άξονας X είναι TTL σε δευτερόλεπτα):
Εκτός από ένα μικρό χτύπημα στο 86 (κυρίως για αρχεία SOA), είναι αρκετά σαφές ότι τα TTL βρίσκονται στο χαμηλό εύρος. Ας ρίξουμε μια πιο προσεκτική ματιά:
Εντάξει, τα TTL μεγαλύτερα από 1 ώρα δεν είναι στατιστικά σημαντικά. Τότε ας εστιάσουμε στο εύρος 0−3600:
Τα περισσότερα TTL είναι από 0 έως 15 λεπτά:
Η συντριπτική πλειοψηφία είναι από 0 έως 5 λεπτά:
Δεν είναι πολύ καλό.
Η αθροιστική κατανομή κάνει το πρόβλημα ακόμη πιο προφανές:
Οι μισές αποκρίσεις DNS έχουν TTL 1 λεπτό ή λιγότερο και τα τρία τέταρτα έχουν TTL 5 λεπτά ή λιγότερο.
Αλλά περιμένετε, στην πραγματικότητα είναι χειρότερο. Μετά από όλα, αυτό είναι TTL από έγκυρους διακομιστές. Ωστόσο, οι συσκευές επίλυσης πελατών (π.χ. δρομολογητές, τοπικές κρυφές μνήμες) λαμβάνουν ένα TTL από αναλυτές ανάντη και μειώνεται κάθε δευτερόλεπτο.
Έτσι, ο πελάτης μπορεί πραγματικά να χρησιμοποιήσει κάθε καταχώριση για, κατά μέσο όρο, το ήμισυ του αρχικού TTL πριν στείλει ένα νέο αίτημα.
Ίσως αυτά τα πολύ χαμηλά TTL ισχύουν μόνο για ασυνήθιστα αιτήματα και όχι για δημοφιλείς ιστότοπους και API; Ας ρίξουμε μια ματιά:
Ο άξονας X είναι TTL, ο άξονας Y είναι δημοτικότητα ερωτημάτων.
Δυστυχώς, τα πιο δημοφιλή ερωτήματα είναι επίσης τα χειρότερα για την προσωρινή αποθήκευση.
Ας κάνουμε μεγέθυνση:
Ετυμηγορία: είναι πολύ κακό. Ήταν ήδη άσχημα πριν, αλλά έγινε ακόμη χειρότερα. Η προσωρινή αποθήκευση DNS έχει γίνει σχεδόν άχρηστη. Καθώς λιγότεροι άνθρωποι χρησιμοποιούν τον αναλυτή DNS του ISP τους (για καλούς λόγους), η αύξηση της καθυστέρησης γίνεται πιο αισθητή.
Η προσωρινή αποθήκευση DNS έχει γίνει χρήσιμη μόνο για περιεχόμενο που δεν επισκέπτεται κανείς.
Σημειώστε επίσης ότι το λογισμικό μπορεί ερμηνεύουν χαμηλά TTL.
Γιατί έτσι;
Γιατί οι εγγραφές DNS έχουν οριστεί σε τόσο χαμηλό TTL;
- Οι συσκευές εξισορρόπησης φορτίου παλαιού τύπου έμειναν με προεπιλεγμένες ρυθμίσεις.
- Υπάρχουν μύθοι ότι η εξισορρόπηση φορτίου DNS εξαρτάται από το TTL (αυτό δεν είναι αλήθεια - από την εποχή του Netscape Navigator, οι πελάτες έχουν επιλέξει μια τυχαία διεύθυνση IP από ένα σύνολο RR και δοκίμασαν με διαφάνεια μια άλλη εάν δεν μπορούν να συνδεθούν)
- Οι διαχειριστές θέλουν να εφαρμόσουν τις αλλαγές αμέσως, επομένως είναι πιο εύκολο να προγραμματίσουν.
- Ο διαχειριστής ενός διακομιστή DNS ή ενός προγράμματος εξισορρόπησης φορτίου θεωρεί ότι το καθήκον του είναι η αποτελεσματική ανάπτυξη της διαμόρφωσης που ζητούν οι χρήστες και όχι η επιτάχυνση τοποθεσιών και υπηρεσιών.
- Τα χαμηλά TTL σας προσφέρουν ηρεμία.
- Οι άνθρωποι αρχικά ορίζουν χαμηλά TTL για δοκιμή και μετά ξεχνούν να τα αλλάξουν.
Δεν συμπεριέλαβα το "failover" στη λίστα γιατί γίνεται όλο και λιγότερο σχετικό. Εάν χρειάζεται να ανακατευθύνετε τους χρήστες σε άλλο δίκτυο μόνο και μόνο για να εμφανίσετε μια σελίδα σφάλματος όταν όλα τα άλλα είναι κατεστραμμένα, μια καθυστέρηση άνω του 1 λεπτού είναι πιθανώς αποδεκτή.
Επιπλέον, ένα TTL ενός λεπτού σημαίνει ότι εάν αποκλειστούν οι έγκυροι διακομιστές DNS για περισσότερο από 1 λεπτό, κανένας άλλος δεν θα μπορεί να έχει πρόσβαση σε εξαρτημένες υπηρεσίες. Και ο πλεονασμός δεν θα βοηθήσει εάν η αιτία είναι ένα σφάλμα διαμόρφωσης ή ένα hack. Από την άλλη πλευρά, με λογικά TTL, πολλοί πελάτες θα συνεχίσουν να χρησιμοποιούν την προηγούμενη διαμόρφωση και δεν θα παρατηρήσουν ποτέ τίποτα.
Οι υπηρεσίες CDN και οι εξισορροπητές φορτίου ευθύνονται σε μεγάλο βαθμό για τα χαμηλά TTL, ειδικά όταν συνδυάζουν 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:
$ τρυπάνι raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 ΣΕ CNAME github.map.fastly.net. github.map.fastly.net. 1 ΣΕ Α 151.101.16.133
Το πρόγραμμα επίλυσης Level3 πιθανότατα εκτελείται σε BIND. Εάν συνεχίσετε να στέλνετε αυτό το αίτημα, θα επιστρέφεται πάντα ένα TTL 1. Ουσιαστικά, raw.githubusercontent.com δεν αποθηκεύεται ποτέ στην κρυφή μνήμη.
Ακολουθεί ένα άλλο παράδειγμα μιας τέτοιας κατάστασης με έναν πολύ δημοφιλή τομέα:
$ 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. Ay. Το ένα έχει ένα αξιοπρεπές TTL, αλλά είναι εντελώς άχρηστο. Άλλα CNAME έχουν αρχικό TTL 60 δευτερολέπτων, αλλά για τομείς akamai.net το μέγιστο TTL είναι 20 δευτερόλεπτα και κανένα από αυτά δεν είναι σε φάση.
Τι γίνεται με τους τομείς που κάνουν συνεχώς δημοσκοπήσεις στις συσκευές 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 δευτερόλεπτο τις περισσότερες φορές όταν χρησιμοποιείτε το πρόγραμμα επίλυσης Level3.
Dropbox;
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 ΣΤΟ CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 ΣΕ Ένα τρυπάνι 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 ΣΕ Α 162.125.64.3
Στην ηχογράφηση safebrowsing.googleapis.com Η τιμή TTL είναι 60 δευτερόλεπτα, όπως οι τομείς του Facebook. Και, πάλι, από την πλευρά του πελάτη, αυτές οι τιμές μειώνονται στο μισό.
Τι θα λέγατε να ορίσετε ένα ελάχιστο TTL;
Χρησιμοποιώντας το όνομα, τον τύπο αιτήματος, το TTL και την αρχικά αποθηκευμένη χρονική σήμανση, έγραψα ένα σενάριο για την προσομοίωση 1,5 εκατομμυρίων αιτημάτων που περνούν από έναν επιλύτη προσωρινής αποθήκευσης για να εκτιμήσω τον όγκο των περιττών αιτημάτων που αποστέλλονται λόγω μιας καταχώρισης προσωρινής μνήμης που έχει λήξει.
Το 47,4% των αιτημάτων υποβλήθηκαν μετά τη λήξη ενός υπάρχοντος αρχείου. Αυτό είναι αδικαιολόγητα υψηλό.
Ποιος θα είναι ο αντίκτυπος στην προσωρινή αποθήκευση εάν οριστεί το ελάχιστο TTL;
Ο άξονας X είναι οι ελάχιστες τιμές 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 λεπτά. Η ρύθμιση του ελάχιστου TTL σε 40 λεπτά αντί για 5 λεπτά δεν θα εμποδίσει τους χρήστες να έχουν πρόσβαση στην υπηρεσία.
Ωστόσο, αυτό θα μειώσει σημαντικά την καθυστέρηση και θα βελτιώσει το απόρρητο και την αξιοπιστία αποφεύγοντας περιττά αιτήματα.
Φυσικά, οι RFC λένε ότι το TTL πρέπει να τηρείται αυστηρά. Αλλά η πραγματικότητα είναι ότι το σύστημα DNS έχει γίνει πολύ αναποτελεσματικό.
Εάν εργάζεστε με έγκυρους διακομιστές DNS, ελέγξτε τα TTL σας. Χρειάζεστε πραγματικά τόσο γελοία χαμηλές τιμές;
Φυσικά, υπάρχουν καλοί λόγοι για να ορίσετε μικρά TTL για εγγραφές DNS. Όχι όμως για το 75% της επισκεψιμότητας DNS που παραμένει ουσιαστικά αμετάβλητο.
Και αν για κάποιο λόγο χρειάζεται πραγματικά να χρησιμοποιήσετε χαμηλά TTL για DNS, ταυτόχρονα βεβαιωθείτε ότι ο ιστότοπός σας δεν έχει ενεργοποιημένη την προσωρινή αποθήκευση. Για τους ίδιους λόγους.
Εάν εκτελείτε μια τοπική προσωρινή μνήμη DNS, όπως π.χ που σας επιτρέπει να ορίσετε ελάχιστα TTL, χρησιμοποιήστε αυτήν τη λειτουργία. Είναι εντάξει. Δεν θα γίνει τίποτα κακό. Ρυθμίστε το ελάχιστο TTL σε περίπου 40 λεπτά (2400 δευτερόλεπτα) και 1 ώρα. Αρκετά λογικό εύρος.
Πηγή: www.habr.com