অ্যাপ্লিকেশনে ETag — এটি কী, উদ্দেশ্য এবং নীতি
ETag হল একটি HTTP রেসপন্স হেডার যা একটি রিসোর্স সংস্করণের অনন্য শনাক্তকারী ধারণ করে। সার্ভার ETag তৈরি করে কন্টেন্ট হ্যাশ বা সংস্করণ নম্বর হিসাবে এবং ডেটার সাথে ক্লায়েন্টকে ফেরত দেয়। পরবর্তী অনুরোধে, ক্লায়েন্ট এই শনাক্তকারীটি If-None-Match হেডারে পাঠায়, যা সার্ভারকে পরীক্ষা করার সুযোগ দেয় যে রিসোর্স পরিবর্তিত হয়েছে কিনা। MDN Web Docs, 2025 অনুসারে, ETag হল HTTP-তে শর্তসাপেক্ষ GET অনুরোধ প্রক্রিয়ার ভিত্তি। ETag-এর সাথে শর্তসাপেক্ষ অনুরোধ মোবাইল অ্যাপ্লিকেশন সিঙ্ক্রোনাইজেশনের সময় স্থানান্তরিত ডেটার পরিমাণ 90% পর্যন্ত কমিয়ে দেয়।
মূল পয়েন্ট
- ETag হল একটি HTTP হেডার যা রিসোর্স সংস্করণের একটি অনন্য শনাক্তকারী ধারণ করে, সাধারণত এর কন্টেন্টের হ্যাশ।
- If-None-Match — ক্লায়েন্ট সংরক্ষিত ETag পাঠায়, সার্ভার 304 Not Modified ফেরত দেয় যদি রিসোর্স পরিবর্তিত না হয়।
- ট্রাফিক সাশ্রয় — ETag-এর সাথে শর্তসাপেক্ষ অনুরোধ মোবাইল অ্যাপ্লিকেশন সিঙ্ক্রোনাইজেশনের সময় ডেটার পরিমাণ কমায় কারণ রেসপন্স বডি প্রেরিত হয় না।
- শক্তিশালী এবং দুর্বল ETag — শক্তিশালীগুলি বাইট-বাই-বাইট কন্টেন্ট পৃথক করে, দুর্বলগুলি রিসোর্সের শব্দার্থক সমতুল্যতা অনুমোদন করে।
- ব্যবহার — ETag REST API-তে ডেটা সিঙ্ক্রোনাইজেশন, ক্যাশিং এবং সম্পাদনা দ্বন্দ্ব প্রতিরোধে ব্যবহৃত হয়।
HTTP এবং মোবাইল অ্যাপ্লিকেশনে ETag কী?
ETag (Entity Tag) হল শর্তসাপেক্ষ হেডার পরিবারের একটি HTTP হেডার যা ক্যাশে করা রিসোর্স বৈধতা প্রদান করে। সার্ভার ETag গণনা করে হ্যাশ (MD5, SHA-256) বা রিসোর্স সংস্করণ নম্বর হিসাবে এবং GET অনুরোধের জবাবে ফেরত দেয়। ক্লায়েন্ট ETag ডেটার সাথে সংরক্ষণ করে এবং পরবর্তী অনুরোধে এটি If-None-Match হেডারে পাঠায়। যদি রিসোর্স কন্টেন্ট পরিবর্তিত না হয়, সার্ভার রেসপন্স বডি ছাড়া 304 Not Modified স্ট্যাটাসে সাড়া দেয়।
মোবাইল অ্যাপ্লিকেশনের জন্য, ETag অত্যন্ত গুরুত্বপূর্ণ কারণ এটি ডাউনলোড করা ডেটার পরিমাণ হ্রাস করে। প্রতিটি লঞ্চ বা সিঙ্ক্রোনাইজেশনে, অ্যাপটি If-None-Match অনুরোধের মাধ্যমে রিসোর্সের হালনাগাদ অবস্থা পরীক্ষা করে — সম্পূর্ণ ডেটা লোড করার পরিবর্তে, এটি 304 পায় এবং স্থানীয় কপি ব্যবহার করে। Google Chrome Team (2024) অনুসারে, মোবাইল API-তে ETag ব্যবহার তালিকার জন্য গড় রেসপন্স সাইজ 87% এবং পৃথক অবজেক্টের জন্য 94% কমিয়ে দেয়।
ETag সার্ভার-সাইডে উৎপন্ন হয় এবং নির্ধারক (অভিন্ন কন্টেন্টের জন্য অভিন্ন, শেয়ার্ড ক্যাশের জন্য উপযোগী) অথবা প্রতিটি রেসপন্সের জন্য অনন্য (কঠোর বৈধতার জন্য) হতে পারে। মোবাইল সিঙ্ক্রোনাইজেশনের জন্য ডিজাইন করা REST API-তে, সবচেয়ে সাধারণ সংমিশ্রণ হল কন্টেন্ট হ্যাশ এবং ডেটাবেসে রেকর্ড সংস্করণ নম্বর।
ETag-এর প্রকার: শক্তিশালী এবং দুর্বল শনাক্তকারী
শক্তিশালী ETag (strong ETag) হল শনাক্তকারী যা কন্টেন্টের যেকোনো পরিবর্তনে পরিবর্তিত হয়, যার মধ্যে সামান্য পরিবর্তন (স্পেস, ফরম্যাটিং) অন্তর্ভুক্ত। ফরম্যাট: “abc123def” (ডাবল কোটে, উপসর্গ ছাড়া)। শক্তিশালী ETag নিশ্চিত করে যে রিসোর্স বাইট-বাই-বাইট পরিবর্তিত হয়নি। এগুলি রেঞ্জ অনুরোধ (Range requests) এবং আংশিক ডাউনলোডের অখণ্ডতা যাচাইয়ের জন্য বাধ্যতামূলক।
দুর্বল ETag (weak ETag) হল W/ উপসর্গযুক্ত শনাক্তকারী, উদাহরণস্বরূপ W/“abc123def”। এগুলি অনুমতি দেয় যে রিসোর্স শব্দার্থকভাবে সমতুল্য এমনকি বাইট উপস্থাপনা ভিন্ন হলেও। দুর্বল ETag সেই সার্ভারগুলির জন্য উপযোগী যা ভিন্ন স্পেস বা ফরম্যাটিং কিন্তু একই অর্থ সহ গতিশীলভাবে রেসপন্স তৈরি করে। তবে, দুর্বল ETag রেঞ্জ অনুরোধ সমর্থন করে না।
ETag প্রকারের তুলনা:
| বৈশিষ্ট্য | শক্তিশালী ETag | দুর্বল ETag |
|---|---|---|
| ফরম্যাট | “hash” | W/“hash” |
| সংবেদনশীলতা | বাইট-বাই-বাইট | শব্দার্থক |
| রেঞ্জ অনুরোধ | সমর্থিত | সমর্থিত নয় |
| CDN ক্যাশিং | আদর্শ | সীমিত |
| সিঙ্ক্রোনাইজেশন | উচ্চ নির্ভুলতা | দ্বন্দ্ব অনুমোদন |
ETag বনাম Last-Modified: কী বেছে নেবেন
Last-Modified হল একটি HTTP হেডার যা রিসোর্সের শেষ পরিবর্তনের তারিখ এবং সময় নির্দেশ করে। ক্লায়েন্ট এটি If-Modified-Since হেডারে ফেরত পাঠায়। Last-Modified বাস্তবায়ন করা সহজ (সার্ভারের শুধুমাত্র একটি তারিখ প্রয়োজন), কিন্তু এর মৌলিক সীমাবদ্ধতা রয়েছে: এক সেকেন্ডের রেজোলিউশন (একই সেকেন্ডে দুটি পরিবর্তন পৃথকীকরণযোগ্য নয়) এবং একই টাইমস্ট্যাম্প থাকলে কন্টেন্ট পরিবর্তিত হয়েছে কিনা তা নির্ধারণে অক্ষমতা (যেমন, ব্যাকআপ পুনরুদ্ধারের পরে)।
ETag এই সমস্যাগুলি সমাধান করে: কন্টেন্ট হ্যাশ সময় নির্বিশেষে যেকোনো পরিবর্তনে পরিবর্তিত হয়। তাই, আধুনিক REST API উভয় হেডারের সংমিশ্রণ ব্যবহার করে: সঠিক বৈধতার জন্য ETag এবং আনুমানিক CDN ফিল্টারিংয়ের জন্য Last-Modified। Apache HTTP Server এবং Nginx ডিফল্টভাবে স্ট্যাটিক ফাইলের জন্য উভয় হেডার তৈরি করে।
সিঙ্ক্রোনাইজেশন সহ মোবাইল অ্যাপ্লিকেশনের জন্য, ETag বেশি গুরুত্বপূর্ণ কারণ এটি সম্পাদনা দ্বন্দ্ব সনাক্ত করতে সক্ষম করে। যদি ক্লায়েন্ট If-Match: “etag” সহ PUT অনুরোধ পাঠায়, সার্ভার অনুরোধ প্রত্যাখ্যান করে যদি রিসোর্স অন্য ক্লায়েন্ট দ্বারা পরিবর্তিত হয় (আশাবাদী লকিং)। সেকেন্ড-স্তরের নির্ভুলতার কারণে Last-Modified এই ধরনের নির্ভরযোগ্যতা নিশ্চিত করতে পারে না।
Kotlin-এ ETag-এর সাথে কাজের উদাহরণ
একটি ক্লায়েন্ট-সাইড বাস্তবায়ন দেখি Retrofit এবং OkHttp-এর সাথে Kotlin ব্যবহার করে মোবাইল অ্যাপ্লিকেশনে ETag-এর। প্রতিটি GET অনুরোধে, ক্লায়েন্ট রেসপন্স থেকে ETag সংরক্ষণ করে এবং পরবর্তী অনুরোধে এটি If-None-Match হেডারে পাঠায়। যদি সার্ভার 304 ফেরত দেয়, ডেটা পুনরায় ডাউনলোড করা হয় না।
ETag ক্যাশিং সহ OkHttp ক্লায়েন্ট সেটআপ করা:
kotlin
class EtagClient {
private val etagCache =
mutableMapOf<String, String>()
private val client = OkHttpClient.Builder().build()
suspend fun fetchWithEtag(
url: String
): Result<String> {
val request = Request.Builder()
.url(url)
.header("If-None-Match",
etagCache[url] ?: "")
.build()
val response = client.newCall(request).await()
return when (response.code) {
304 -> Result.success(
"not_modified")
200 -> {
response.header("ETag")?.let {
etagCache[url] = it
}
Result.success(response.body?.string()
?: "")
}
else -> Result.failure(
Exception("HTTP ${response.code}"))
}
}
}ক্লায়েন্ট সফল 200 রেসপন্সের পরে ETag সংরক্ষণ করে এবং পরবর্তী অনুরোধে এটি If-None-Match হেডারে পাঠায়। 304 রেসপন্সে, ক্লায়েন্ট জানে যে স্থানীয় সংস্করণ হালনাগাদ আছে এবং পুনরায় ডাউনলোড করতে ট্রাফিক অপচয় করে না। এই প্যাটার্নটি ঘন ঘন অনুরোধকৃত রিসোর্সের জন্য মোবাইল অ্যাপ্লিকেশনের নেটওয়ার্ক খরচ 80–90% কমিয়ে দেয়।
মোবাইল অ্যাপ্লিকেশন সিঙ্ক্রোনাইজেশনে ETag-এর ভূমিকা
ETag একটি মূল প্রক্রিয়া REST API-এর সাথে মোবাইল অ্যাপ্লিকেশন সিঙ্ক্রোনাইজেশন অপ্টিমাইজ করার জন্য। স্ট্যান্ডার্ড সিঙ্ক স্কিমে, ক্লায়েন্ট প্রথমে ETag বৈধতা সহ রিসোর্সের তালিকা অনুরোধ করে — যদি কোনো রিসোর্স পরিবর্তিত না হয়, সার্ভার 304 ফেরত দেয় এবং ক্লায়েন্ট সিঙ্ক্রোনাইজেশন সম্পূর্ণ করে। যদি পরিবর্তন থাকে, সার্ভার শুধুমাত্র পরিবর্তিত রিসোর্স ফেরত দেয়। এই পদ্ধতিকে ডেল্টা সিঙ্ক্রোনাইজেশন বলা হয় এবং এটি সীমিত ট্রাফিকযুক্ত মোবাইল ডিভাইসের জন্য অত্যন্ত গুরুত্বপূর্ণ।
আশাবাদী লকিং পরিস্থিতিতে, ETag Lost Update দ্বন্দ্ব প্রতিরোধে ব্যবহৃত হয়। যখন ক্লায়েন্ট একটি রিসোর্স আপডেট করতে PUT অনুরোধ পাঠায়, এটি If-Match: “etag” হেডার অন্তর্ভুক্ত করে। যদি ETag মেলে না (অন্য ক্লায়েন্ট ইতিমধ্যে রিসোর্স পরিবর্তন করেছে), সার্ভার 412 Precondition Failed-এর সাথে সাড়া দেয়, এবং ক্লায়েন্টকে বর্তমান সংস্করণ পুনরায় আনতে হবে এবং পরিবর্তন পুনরায় চেষ্টা করতে হবে। এই পদ্ধতি ডেটাবেস-স্তরের লক ছাড়াই ডেটা সামঞ্জস্য নিশ্চিত করে।
অফলাইন মোড সহ বিতরণকৃত সিস্টেমের জন্য, ETag দ্বন্দ্ব সমাধানের সাথে সংমিশ্রণে ব্যবহৃত হয়। ক্লায়েন্ট সমস্ত রিসোর্সের জন্য বর্তমান ETag পেয়ে সিঙ্ক্রোনাইজ করে। পরিবর্তন পাঠানোর সময়, সার্ভার If-Match পরীক্ষা করে — যদি ETag মেলে না, একটি দ্বন্দ্ব নথিভুক্ত করা হয় যা নির্বাচিত কৌশল (LWW, Merge) অনুসারে সমাধান করা হয়। Postman API Report (2025) অনুসারে, মোবাইল অ্যাপ্লিকেশনের জন্য 67% প্রোডাকশন REST API সংস্করণ বৈধতার প্রাথমিক প্রক্রিয়া হিসাবে ETag ব্যবহার করে।
সচরাচর জিজ্ঞাসিত প্রশ্ন
ETag HTTP হেডার কী?
ETag হল একটি HTTP রেসপন্স হেডার যা রিসোর্স সংস্করণের অনন্য শনাক্তকারী ধারণ করে। ক্লায়েন্ট এটি শর্তসাপেক্ষ অনুরোধের জন্য ব্যবহার করে: যদি রিসোর্স পরিবর্তিত না হয়, সার্ভার রেসপন্স বডি ছাড়া 304 Not Modified ফেরত দেয়, ট্রাফিক সাশ্রয় করে।
ETag এবং Last-Modified-এর মধ্যে পার্থক্য কী?
ETag সঠিক তুলনার জন্য কন্টেন্ট হ্যাশ ব্যবহার করে। Last-Modified সেকেন্ড নির্ভুলতার সাথে পরিবর্তনের তারিখের উপর ভিত্তি করে। প্রকৃত পরিবর্তন সনাক্ত করতে ETag বেশি নির্ভরযোগ্য এবং If-Match-এর মাধ্যমে আশাবাদী লকিং সমর্থন করে।
শক্তিশালী এবং দুর্বল ETag কী?
শক্তিশালী ETag (উপসর্গ ছাড়া) রিসোর্স বাইট-বাই-বাইট পৃথক করে। দুর্বল ETag (W/ উপসর্গ সহ) শব্দার্থক সমতুল্যতা অনুমোদন করে। শক্তিশালীগুলি রেঞ্জ অনুরোধের জন্য প্রয়োজন, দুর্বলগুলি গতিশীলভাবে উৎপন্ন কন্টেন্টের জন্য।
ETag কীভাবে মোবাইল সিঙ্ক্রোনাইজেশনে সাহায্য করে?
ETag ট্রাফিক 80–90% কমায়: ক্লায়েন্ট If-None-Match-এর মাধ্যমে সমস্ত রিসোর্সের হালনাগাদ অবস্থা পরীক্ষা করে, শুধুমাত্র পরিবর্তিতগুলি ডাউনলোড করে। ETag ছাড়া, ক্লায়েন্ট প্রতিটি সিঙ্ক্রোনাইজেশনে সম্পূর্ণ ডেটা ডাউনলোড করবে, ট্রাফিক এবং ব্যাটারি অপচয় করবে।
সার্ভারে ETag কীভাবে বাস্তবায়ন করবেন?
সার্ভার ETag গণনা করে রেসপন্স কন্টেন্টের হ্যাশ (MD5, SHA-256) হিসাবে বা ডেটাবেস থেকে রেকর্ড সংস্করণ নম্বর ব্যবহার করে। Spring Boot-এ, @Cacheable অ্যানোটেশন etag = true সহ যথেষ্ট। Express.js-এ, etag মিডলওয়্যার ডিফল্টভাবে সক্রিয়।
সারসংক্ষেপ
- ETag কন্টেন্ট হ্যাশ বা সংস্করণ নম্বরের উপর ভিত্তি করে রিসোর্স সংস্করণ বৈধতার জন্য একটি HTTP হেডার।
- শর্তসাপেক্ষ অনুরোধ — ক্লায়েন্ট সংরক্ষিত ETag সহ If-None-Match পাঠায়, সার্ভার অপরিবর্তিত থাকলে 304-এ সাড়া দেয়।
- ETag প্রকার — শক্তিশালী (বাইট-বাই-বাইট, রেঞ্জ অনুরোধের জন্য) এবং দুর্বল (শব্দার্থক সমতুল্যতা, W/ উপসর্গ)।
- সুবিধা — ETag Last-Modified-এর চেয়ে বেশি নির্ভুল কারণ হ্যাশ সময় নির্বিশেষে যেকোনো কন্টেন্ট পরিবর্তনে পরিবর্তিত হয়।
- আশাবাদী লকিং — If-Match-এর মাধ্যমে, ETag সমবর্তী রিসোর্স সম্পাদনার সময় Lost Update দ্বন্দ্ব প্রতিরোধ করে।
- ডেল্টা সিঙ্ক্রোনাইজেশন — ETag সিঙ্ক স্কিম চালিত করে যেখানে শুধুমাত্র পরিবর্তিত রিসোর্স প্রেরিত হয়।
- সুপারিশ — মোবাইল অ্যাপ্লিকেশনের জন্য REST API-তে সর্বদা ETag যোগ করুন। CDN এবং প্রক্সি সার্ভার সামঞ্জস্যের জন্য Last-Modified-এর সাথে সংযুক্ত করুন।
আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব
IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।
আরও পড়ুন