ETag: এটি কী, ক্যাশিং প্রক্রিয়া এবং হেডার কনফিগারেশন

ETag কী?

ETag (Entity Tag) হল একটি HTTP প্রতিক্রিয়া হেডার যা একটি রিসোর্সের একটি নির্দিষ্ট সংস্করণের জন্য একটি অনন্য শনাক্তকারী ধারণ করে। সার্ভার ফাইল কন্টেন্ট, এর মেটাডেটা বা রিভিশন নম্বরের উপর ভিত্তি করে ETag গণনা করে এবং GET অনুরোধের জবাবে এটি ক্লায়েন্টের কাছে পাঠায়। ক্লায়েন্ট এই শনাক্তকারী সংরক্ষণ করে এবং একই রিসোর্সে পরবর্তী অনুরোধে এটি If-None-Match হেডারে পাঠায়। যদি রিসোর্স পরিবর্তিত না হয়, সার্ভার 304 Not Modified দিয়ে সাড়া দেয় এবং ক্লায়েন্ট তার ক্যাশে করা কপি ব্যবহার করে।

ETag ফরম্যাট RFC 7232-এ উদ্ধৃতি চিহ্নের মধ্যে একটি স্ট্রিং হিসাবে সংজ্ঞায়িত করা হয়েছে: "33a64df551425fcc55e4d42a148795d9f25f89d4"। মানটি ফাইল কন্টেন্টের একটি SHA-1 হ্যাশ, একটি বৃদ্ধিমূলক সংস্করণ নম্বর, স্ট্যাটিক ফাইলের জন্য inode-সংখ্যা-সময়ের সংমিশ্রণ বা সার্ভার দ্বারা উৎপন্ন একটি নির্বিচার টোকেন হতে পারে। একমাত্র প্রয়োজনীয়তা হল যে মানটি রিসোর্স পরিবর্তিত হলে পরিবর্তন হতে হবে এবং রিসোর্স একই থাকলে পরিবর্তন হবে না।

ETag শর্তসাপেক্ষ অনুরোধ প্রক্রিয়ার (conditional requests) অন্তর্গত — HTTP প্রোটোকলের মৌলিক অপ্টিমাইজেশানগুলির মধ্যে একটি। নিঃশর্ত অনুরোধের বিপরীতে যেখানে সার্ভার সর্বদা একটি সম্পূর্ণ প্রতিক্রিয়া ফেরত দেয়, একটি শর্তসাপেক্ষ অনুরোধ ক্লায়েন্টকে ডেটা পুনরায় লোড না করেই ক্যাশের প্রাসঙ্গিকতা পরীক্ষা করতে দেয়। HTTP Archive (2025) অনুসারে, সমস্ত HTTP প্রতিক্রিয়ার প্রায় 40% হল 304 Not Modified সঠিক ETag এবং Last-Modified কনফিগারেশনের কারণে।

ETag কোথায় ব্যবহার করা হয়

ETag REST API-তে ডেটা সংগ্রহ লোডিং অপ্টিমাইজ করতে ব্যবহৃত হয় — যদি অবজেক্ট তালিকা পরিবর্তিত না হয়, ক্লায়েন্ট সম্পূর্ণ JSON স্থানান্তর না করেই 304 পায়। স্ট্যাটিক ফাইল (CSS, JS, ছবি) এর জন্য, ETag CDN এবং ব্রাউজারগুলিকে ক্যাশের সতেজতা দক্ষতার সাথে পরীক্ষা করতে দেয়। মোবাইল অ্যাপ্লিকেশনে, ETag পটভূমি সিঙ্ক্রোনাইজেশন এর জন্য গুরুত্বপূর্ণ: অ্যাপটি পরীক্ষা করে যে সার্ভারের ডেটা পরিবর্তিত হয়েছে কিনা এবং শুধুমাত্র প্রয়োজন হলে আপডেট ডাউনলোড করে। এটি ট্র্যাফিক এবং ডিভাইসের ব্যাটারি বাঁচায়।

ETag কীভাবে কাজ করে?

সম্পূর্ণ ETag জীবনচক্র চারটি ধাপ নিয়ে গঠিত। সার্ভার প্রথম অনুরোধে একটি ETag তৈরি করে এবং এটি প্রতিক্রিয়া হেডারে ফেরত দেয়। ক্লায়েন্ট ETag ক্যাশে করা রিসোর্সের সাথে সংরক্ষণ করে। পুনরাবৃত্ত অনুরোধে, ক্লায়েন্ট If-None-Match হেডার সংরক্ষিত ETag মান সহ পাঠায়। সার্ভার প্রাপ্ত মান বর্তমান রিসোর্স ETag-এর সাথে তুলনা করে: মিলে গেলে, এটি খালি বডি সহ 304 Not Modified ফেরত দেয়; মিল না হলে, এটি নতুন রিসোর্স এবং নতুন ETag সহ 200 OK ফেরত দেয়।

// 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, উদাহরণস্বরূপ, CacheInterceptor-এর মাধ্যমে স্বয়ংক্রিয়ভাবে ETag পরিচালনা করে: এটি প্রতিক্রিয়া ETag সংরক্ষণ করে এবং পুনরাবৃত্ত অনুরোধে If-None-Match যোগ করে। 304 পাওয়ার পর, OkHttp ক্যাশে করা ডেটা ফেরত দেয়। OkHttp অতিরিক্ত কনফিগারেশন ছাড়াই ETag সমর্থন করে — শুধু OkHttpClient.Builder.cache()-এর মাধ্যমে ক্যাশ সক্ষম করুন।

সার্ভারে ETag জেনারেশন

সার্ভার বিভিন্ন উপায়ে ETags গণনা করতে পারে: কন্টেন্টের MD5 বা SHA হ্যাশের মাধ্যমে, ডেটাবেস থেকে রিভিশন নম্বরের মাধ্যমে (যেমন MySQL থেকে updated_at), স্ট্যাটিক ফাইলের জন্য inode + mtime + আকারের সংমিশ্রণের মাধ্যমে (Nginx এইভাবেই ETags তৈরি করে)। ডায়নামিক API-র জন্য, কন্টেন্ট হ্যাশ সবচেয়ে নির্ভরযোগ্য: যদি JSON প্রতিক্রিয়ার একটি ফিল্ডও পরিবর্তিত হয়, ETag পরিবর্তিত হবে। তবে, প্রতিটি অনুরোধে হ্যাশ গণনা করা CPU-তে চাপ ফেলে — উচ্চ-লোড সিস্টেমের জন্য, একটি বৃদ্ধিমূলক সংস্করণ নম্বর ব্যবহার করা ভাল।

শক্তিশালী এবং দুর্বল ETag

RFC 7232 দুটি ধরণের ETags সংজ্ঞায়িত করে: শক্তিশালী (strong) এবং দুর্বল (weak)। একটি শক্তিশালী ETag মানে হল যে রিসোর্সের দুটি উপস্থাপনা বাইট-প্রতি-বাইট অভিন্ন — একটি বিটও আলাদা নয়। একটি দুর্বল ETag (উপসর্গ W/) শুধুমাত্র শব্দার্থগত সমতুল্যতা নিশ্চিত করে: কন্টেন্ট সিরিয়ালাইজেশন স্তরে (স্পেস, JSON ফিল্ড অর্ডার) ভিন্ন হতে পারে, কিন্তু ডেটা ক্লায়েন্টের জন্য একই হিসাবে বিবেচিত হয়। দুর্বল ETags W/ উপসর্গ দিয়ে চিহ্নিত করা হয়, উদাহরণস্বরূপ W/"1a2b3c"।

ETag প্রকারের পছন্দ তুলনা নির্ভুলতার প্রয়োজনীয়তার উপর নির্ভর করে। স্ট্যাটিক ফাইল (CSS, JS, ছবি) এর জন্য, শক্তিশালী ETags পছন্দনীয় — যদি ফাইল পরিবর্তিত হয়, ক্লায়েন্টকে নতুন সংস্করণ পেতে হবে। ডায়নামিক API-র জন্য, যেখানে একই JSON ভিন্ন ফিল্ড অর্ডার বা ফরম্যাটিং সহ সিরিয়ালাইজ করা যেতে পারে, দুর্বল ETags আরও নমনীয়তা প্রদান করে: সার্ভার স্ট্রিং উপস্থাপনার পরিবর্তে বিজনেস ডেটার উপর ভিত্তি করে ETag তৈরি করে।

দুর্বল ETags-এর একটি সীমাবদ্ধতা: এগুলি রেঞ্জ অনুরোধ (Range requests) এর সাথে ব্যবহার করা যাবে না। যদি ক্লায়েন্ট একটি ফাইলের অংশ অনুরোধ করে, সার্ভারকে নিশ্চিত করতে একটি শক্তিশালী ETag ফেরত দিতে হবে যে খণ্ডটি সম্পূর্ণ রিসোর্সের সাথে সামঞ্জস্যপূর্ণ। দুর্বল ETags এই ধরনের নিশ্চয়তা প্রদান করে না। অন্যান্য পরিস্থিতিতে, দুর্বল ETags নিরাপদ এবং API-র জন্য সুপারিশ করা হয়।

ETag বনাম 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 উপেক্ষা করে। এটি রেস কন্ডিশন প্রতিরোধ করে: যদি ক্লায়েন্ট Last-Modified পাঠানো এবং সার্ভারে পরীক্ষার মধ্যে রিসোর্স পরিবর্তিত হয়, ETag আরও নতুন সূচক হবে। অনুশীলনে, সার্ভারগুলি সাধারণত উভয় হেডার পরীক্ষা করে, কিন্তু যখন ফলাফল অমিল হয়, ETag জয়ী হয়।

সার্ভারে ETag বাস্তবায়ন

ETag কনফিগারেশন সার্ভারের ধরণের উপর নির্ভর করে। Nginx inode, mtime এবং আকারের উপর ভিত্তি করে স্ট্যাটিক ফাইলের জন্য স্বয়ংক্রিয়ভাবে ETags তৈরি করে। Apache FileETag প্রক্রিয়া ব্যবহার করে। Node.js, PHP, Python, Ruby-তে ডায়নামিক অ্যাপ্লিকেশনের জন্য, ETags প্রোগ্রামেটিকভাবে তৈরি করা প্রয়োজন — প্রতিক্রিয়া হ্যাশ, ডেটা সংস্করণ নম্বর বা অনুরোধ প্যারামিটারের সংমিশ্রণের মাধ্যমে।

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)
    })
}

Go-তে Middleware অনুরোধটি আটকায়, অনুরোধিত URL-এর জন্য একটি ETag তৈরি করে (উদাহরণস্বরূপ, ক্যাশ বা DB থেকে ডেটা হ্যাশ গণনা করে) এবং প্রতিক্রিয়া হেডার সেট করে। যদি ক্লায়েন্ট If-None-Match পাঠায় এবং এটি বর্তমান ETag-এর সাথে মেলে, সার্ভার প্রধান হ্যান্ডলারকে কল না করেই অবিলম্বে 304 Not Modified ফেরত দেয়। উৎপাদনে, সার্ভার লোড কমাতে URL এবং প্যারামিটার দ্বারা গণনা করা ETags-এর ক্যাশিং যোগ করা উচিত।

সমস্যা এবং ফাঁদ

মাল্টি-সার্ভার কনফিগারেশনে (round-robin বা anycast), ETag একই রিসোর্সের জন্য সমস্ত নোডে একই হতে হবে। যদি ETag ফাইল inode-এর উপর ভিত্তি করে তৈরি হয় এবং সাইটটি একাধিক সার্ভারে স্থাপন করা হয়, মানগুলি ভিন্ন হবে। সমাধান হল কন্টেন্ট হ্যাশ বা কেন্দ্রীভূত সংস্করণ স্টোরেজ (Redis, etcd) ব্যবহার করা। দ্বিতীয় সমস্যা হল gzip কম্প্রেশন: যখন কম্প্রেশন সক্ষম থাকে তখন Nginx ETag পরিবর্তন করে, যা অপ্রয়োজনীয় 304 প্রতিক্রিয়া সৃষ্টি করতে পারে। কম্প্রেসড কন্টেন্টের সাথে ETag সিঙ্ক্রোনাইজ করতে gzip_vary on কনফিগার করা প্রয়োজন।