ETag: τι είναι, μηχανισμός αποθήκευσης στην κρυπτή μνήμη και ρύθμιση της κεφαλίδας

Τι είναι το ETag;

ETag (Entity Tag) — είναι μια κεφαλίδα απάντησης HTTP που περιέχει ένα μοναδικό αναγνωριστικό μιας συγκεκριμένης έκδοσης πόρου. Ο διακομιστής υπολογίζει το ETag βάσει του περιεχομένου του αρχείου, των μεταδεδομένων του ή του αριθμού αναθεώρησης και το μεταβιβάζει στον πελάτη στην απάντηση σε μια αίτηση GET. Ο πελάτης αποθηκεύει αυτό το αναγνωριστικό και σε επόμενες αιτήσεις προς τον ίδιο πόρο το στέλνει στην κεφαλίδα If-None-Match. Αν ο πόρος δεν έχει αλλάξει, ο διακομιστής απαντά με 304 Not Modified, και ο πελάτης χρησιμοποιεί το αποθηκευμένο στην κρυπτή μνήμη αντίγραφό του.

Η μορφή του ETag ορίζεται στο RFC 7232 ως συμβολοσειρά σε εισαγωγικά: "33a64df551425fcc55e4d42a148795d9f25f89d4". Η τιμή μπορεί να είναι ένα hash SHA-1 του περιεχομένου του αρχείου, ένας αυξητικός αριθμός έκδοσης, ένας συνδυασμός inode-αριθμός-χρόνος για στατικά αρχεία ή ένα οποιοδήποτε token που δημιουργείται από τον διακομιστή. Η μοναδική απαίτηση είναι η τιμή να αλλάζει σε κάθε αλλαγή του πόρου και να μην αλλάζει αν ο πόρος παραμένει ο ίδιος.

Το ETag ανήκει στους μηχανισμούς υπό προϋποθέσεις αιτήσεων (conditional requests) — μία από τις βασικές βελτιστοποιήσεις του πρωτοκόλλου HTTP. Σε αντίθεση με τις ανόρυσιμες αιτήσεις, όπου ο διακομιστής επιστρέφει πάντα μια πλήρη απάντηση, μια υπό προϋποθέσεις αίτηση επιτρέπει στον πελάτη να ελέγχει την επικαιρότητα της κρυπτής μνήμης χωρίς να κατεβάσει ξανά τα δεδομένα. Σύμφωνα με τα δεδομένα HTTP Archive (2025), περίπου 40% όλων των απαντήσεων HTTP είναι 304 Not Modified χάρη στη σωστή ρύθμιση του ETag και του Last-Modified.

Πού εφαρμόζεται το ETag

Το ETag χρησιμοποιείται σε REST API για βελτιστοποίηση της φόρτωσης συλλογών δεδομένων — αν η λίστα αντικειμένων δεν έχει αλλάξει, ο πελάτης λαμβάνει 304 χωρίς να στέλνει ολόκληρο το JSON. Σε στατικά αρχεία (CSS, JS, εικόνες) το ETag επιτρέπει σε CDN και προγράμματα περιήγησης να ελέγχουν αποτελεσματικά την επικαιρότητα της κρυπτής μνήμης. Σε κινητές εφαρμογές, το ETag είναι κρίσιμο για συγχρονισμό παρασκηνίου: η εφαρμογή ελέγχει αν τα δεδομένα στον διακομιστή έχουν αλλάξει και κατεβάζει ενημερώσεις μόνο όταν χρειαστεί. Αυτό εξοικονομεί εύρος ζώνης και μπαταρία συσκευής.

Πώς λειτουργεί το ETag;

Ο πλήρης κύκλος λειτουργίας του ETag αποτελείται από τέσσερα βήματα. Ο διακομιστής δημιουργεί το ETag στην πρώτη αίτηση και το επιστρέφει στην κεφαλίδα απάντησης. Ο πελάτης αποθηκεύει το ETag μαζί με τον αποθηκευμένο στην κρυπτή μνήμη πόρο. Σε μια επαναληπτική αίτηση, ο πελάτης στέλνει την κεφαλίδα If-None-Match με την τιμή του αποθηκευμένου ETag. Ο διακομιστής συγκρίνει την ληφθείσα τιμή με το τρέχον ETag του πόρου: σε περίπτωση αντιστοιχίας, επιστρέφει 304 Not Modified με κενό σωματίδιο, σε περίπτωση ασυμφωνίας — 200 OK με νέο πόρο και νέο ETag.

// Αίτηση πελάτη με If-None-Match
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Απάντηση διακομιστή — ο πόρος δεν άλλαξε
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Σε μια κινητή εφαρμογή, αυτός ο κύκλος μπορεί να υλοποιηθεί μέσω ενός πελάτη HTTP με υποστήριξη κρυπτής μνήμης. Το OkHttp, για παράδειγμα, διαχειρίζεται αυτόματα το ETag μέσω CacheInterceptor: αποθηκεύει το ETag της απάντησης και σε μια επαναληπτική αίτηση προσθέτει If-None-Match. Κατά τη λήψη 304, το OkHttp επιστρέφει τα αποθηκευμένα στην κρυπτή μνήμη δεδομένα. Το OkHttp υποστηρίζει το ETag χωρίς επιπλέον ρύθμιση — αρκεί η ενεργοποίηση της κρυπτής μνήμης μέσω OkHttpClient.Builder.cache().

Δημιουργία ETag στον διακομιστή

Ο διακομιστής μπορεί να υπολογίζει το ETag με διαφορετικούς τρόπους: μέσω hash MD5 ή SHA του περιεχομένου, μέσω του αριθμού αναθεώρησης από τη βάση δεδομένων (π.χ. updated_at από MySQL), μέσω του συνδυασμού inode + mtime + size για στατικά αρχεία (το Nginx δημιουργεί ETag ακριβώς με αυτόν τον τρόπο). Για δυναμικά API, το πιο αξιόπιστο είναι το hash περιεχομένου: αν η απάντηση JSON άλλαξε έστω ένα πεδίο, το ETag θα αλλάξει. Ωστόσο, ο υπολογισμός του hash σε κάθε αίτηση επιβαρύνει την CPU — για συστήματα υψηλής φόρτωσης είναι καλύτερο να χρησιμοποιείται αυξητικός αριθμός έκδοσης.

Ισχυρά και ασθενή ETag

Το RFC 7232 ορίζει δύο τύπους ETag: ισχυρά (strong) και ασθενή (weak). Ένα ισχυρό ETag σημαίνει ότι δύο αναπαραστάσεις του πόρου είναι ταυτόσημες byte-προς-byte — κανένα bit δεν διαφέρει. Ένα ασθενές ETag (πρόθεμα W/) εγγυάται μόνο σημασιολογική ισοδυναμία: το περιεχόμενο μπορεί να διαφέρει σε επίπεδο σειριοποίησης (διαστήματα, σειρά πεδίων JSON), αλλά τα δεδομένα θεωρούνται ίδια για τον πελάτη. Τα ασθενή ETag σημειώνονται με πρόθεμα W/, π.χ. W/"1a2b3c".

Η επιλογή του τύπου ETag εξαρτάται από τις απαιτήσεις ακρίβειας σύγκρισης. Για στατικά αρχεία (CSS, JS, εικόνες) προτιμούνται τα ισχυρά ETag — αν το αρχείο έχει αλλάξει, ο πελάτης πρέπει να λάβει τη νέα έκδοση. Για δυναμικά API, όπου το ίδιο JSON μπορεί να σειριοποιηθεί με διαφορετική σειρά πεδίων ή μορφοποίηση, τα ασθενή ETag παρέχουν περισσότερη ευελιξία: ο διακομιστής δημιουργεί το ETag βάσει επιχειρηματικών δεδομένων, όχι της συμβολοσειράς.

Περιορισμός των ασθενών ETag: δεν μπορούν να χρησιμοποιηθούν με αιτήσεις εύρους (Range requests). Αν ο πελάτης ζητά ένα μέρος του αρχείου, ο διακομιστής πρέπει να επιστρέψει ένα ισχυρό ETag για να εγγυηθεί ότι το τμήμα αντιστοιχεί στον πλήρη πόρο. Τα ασθενή ETag δεν παρέχουν τέτοια εγγύηση. Σε άλλα σενάρια, τα ασθενή ETag είναι ασφαλή και συνιστώνται για API.

ETag vs Last-Modified

Το ETag και το Last-Modified είναι δύο κεφαλίδες HTTP για υπό προϋποθέσεις αιτήσεις που χρησιμοποιούνται συχνά μαζί. Το Last-Modified υποδεικνύει την ημερομηνία της τελευταίας τροποποίησης του πόρου και λειτουργεί με την κεφαλίδα If-Modified-Since. Το ETag παρέχει ένα μοναδικό αναγνωριστικό έκδοσης και λειτουργεί με If-None-Match. Κάθε ένα έχει τα πλεονεκτήματα και τους περιορισμούς του, και ο συνδυασμός παρέχει μέγιστη αποδοτικότητα αποθήκευσης στην κρυπτή μνήμη.

Το Last-Modified είναι απλούστερο στην υλοποίηση — ο διακομιστής λαμβάνει αυτόματα την ημερομηνία από το σύστημα αρχείων ή ενημερώνει το πεδίο updated_at στη βάση δεδομένων. Η ημερομηνία όμως έχει ακρίβεια έως ένα δευτερόλεπτο, κάτι που δεν είναι αρκετό για πόρους που αλλάζουν πολλές φορές ανά δευτερόλεπτο. Επιπλέον, το Last-Modified δεν διακρίνει διαφορετικές καταστάσεις: αν το αρχείο αντικατασταθεί με την ίδια έκδοση, η ημερομηνία αλλάζει, αλλά το περιεχόμενο όχι — ο πελάτης φορτώνει ξανά τα ίδια δεδομένα.

Το ETag είναι ακριβέστερο: αλλάζει μόνο σε πραγματική αλλαγή του περιεχομένου. Αν ο διακομιστής επανέφερε την προηγούμενη έκδοση από αντίγραφο ασφαλείας, το ETag θα αλλάξει. Αν το αρχείο αντικατασταθεί με τα ίδια δεδομένα — το ETag παραμένει το ίδιο, και ο πελάτης δεν θα φορτώσει ξανά. Η κοινή χρήση συνιστάται από την προδιαγραφή HTTP: ο διακομιστής επιστρέφει και τις δύο κεφαλίδες, ο πελάτης στέλνει If-None-Match και If-Modified-Since ταυτόχρονα. Αν τουλάχιστον μία κεφαλίδα εμφανίζει αλλαγή — ο διακομιστής επιστρέφει νέο πόρο.

Προτεραιότητα κεφαλίδων

Σύμφωνα με την προδιαγραφή, το ETag έχει προτεραιότητα έναντι του Last-Modified. Αν ο διακομιστής έλαβε If-None-Match, πρέπει να ελέγχει μόνο το ETag, αγνοώντας το If-Modified-Since. Αυτό αποτρέπει race condition: αν ο πόρος άλλαξε μεταξύ της αποστολής του Last-Modified από τον πελάτη και του ελέγχου στον διακομιστή, το ETag θα είναι ο πιο πρόσφατος δείκτης. Στην πράξη, οι διακομιστές συνήθως ελέγχουν και τις δύο κεφαλίδες, αλλά σε περίπτωση ασυμφωνίας αποτελεσμάτων κερδίζει το ETag.

Υλοποίηση ETag στον διακομιστή

Η ρύθμιση του ETag εξαρτάται από τον τύπο του διακομιστή. Το Nginx δημιουργεί ETag για στατικά αρχεία αυτόματα βάσει inode, mtime και μεγέθους. Το Apache χρησιμοποιεί τον μηχανισμό FileETag. Για δυναμικές εφαρμογές σε Node.js, PHP, Python, Ruby, το ETag πρέπει να δημιουργείται με προγραμματισμό — μέσω hash της απάντησης, αριθμού έκδοσης δεδομένων ή συνδυασμού παραμέτρων αίτησης.

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // Δημιουργία ETag βάσει δεδομένων
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

        // Έλεγχος If-None-Match
        if r.Header.Get("If-None-Match") == etag {
            w.WriteHeader(http.StatusNotModified)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Η middleware Go προϋποκλέπτει την αίτηση, δημιουργεί ETag για το URL που ζητήθηκε (π.χ. υπολογίζει hash δεδομένων από την κρυπτή μνήμη ή τη βάση δεδομένων) και ορίζει την κεφαλίδα απάντησης. Αν ο πελάτης έστειλε If-None-Match και ταιριάζει με το τρέχον ETag, ο διακομιστής επιστρέφει αμέσως 304 Not Modified, χωρίς να καλείται ο κύριος handler. Σε παραγωγικό περιβάλλον, αξίζει να προστεθεί αποθήκευση στην κρυπτή μνήμη των υπολογισμένων ETag ανά URL και παραμέτρους για τη μείωση του φόρτου του διακομιστή.

Προβλήματα και παγίδες

Σε μια πολυδιακομιστική διάμορφωση (round-robin ή anycast) το ETag πρέπει να είναι το ίδιο σε όλους τους κόμβους για τον ίδιο πόρο. Αν το ETag δημιουργείται βάσει του inode του αρχείου και η ιστοσελίδα λειτουργεί σε πολλά διακομιστές, οι τιμές θα διαφέρουν. Η λύση — χρήση hash περιεχομένου ή κεντρικής αποθήκευσης εκδόσεων (Redis, etcd). Το δεύτερο πρόβλημα — συμπίεση gzip: το Nginx αλλάζει το ETag όταν η συμπίεση είναι ενεργή, κάτι που μπορεί να προκαλέσει υπερβολικά 304. Απαιτείται η ρύθμιση gzip_vary on για συγχρονισμό του ETag με συμπιεσμένο περιεχόμενο.