NTP (Network Time Protocol) একটি নেটওয়ার্ক টাইম সিঙ্ক্রোনাইজেশন প্রোটোকল যা লোকাল নেটওয়ার্কে মিলিসেকেন্ড এবং গ্লোবাল নেটওয়ার্কে দশ মিলিসেকেন্ড পর্যন্ত নির্ভুলতা প্রদান করে। 1985 সালে ডেভিড মিলস দ্বারা বিকশিত, প্রোটোকলটি সমস্ত আধুনিক অপারেটিং সিস্টেম, মোবাইল ডিভাইস এবং নেটওয়ার্ক সরঞ্জামে UTC রেফারেন্স সময়ের সাথে অভ্যন্তরীণ ঘড়ি সিঙ্ক্রোনাইজ করতে ব্যবহৃত হয়। NTP পুল প্রজেক্ট (2026) অনুসারে, প্রতিদিন 4 বিলিয়নেরও বেশি ডিভাইস সিঙ্ক্রোনাইজেশনের জন্য NTP অনুরোধ করে।
মূল বিষয়
NTP (Network Time Protocol) একটি নেটওয়ার্ক প্রোটোকল যা প্যাকেট-সুইচড নেটওয়ার্কের মাধ্যমে কম্পিউটারের অভ্যন্তরীণ ঘড়িকে রেফারেন্স সময় উৎসের সাথে সঠিকভাবে সিঙ্ক্রোনাইজ করার জন্য ডিজাইন করা হয়েছে। RFC 5905 (NTPv4)-এ বর্ণিত, প্রোটোকলটি সার্ভারের একটি হায়ারার্কিক্যাল সিস্টেম ব্যবহার করে, যেখানে প্রতিটি স্তরকে স্ট্রেটাম বলা হয়। একটি NTP ক্লায়েন্ট সার্ভারে অনুরোধ পাঠায়, প্যাকেটের রাউন্ড-ট্রিপ সময় (RTT) মাপে এবং রেফারেন্স সময়ের সাপেক্ষে নিজের ঘড়ির অফসেট গণনা করে। সংশোধন অ্যালগরিদম শুধুমাত্র একক অফসেটই নয়, বরং ঘড়ি জেনারেটরের ড্রিফটও বিবেচনা করে, যা পুনরাবৃত্ত অনুরোধ ছাড়াই দীর্ঘ সময় ধরে নির্ভুলতা বজায় রাখতে দেয়।
প্রোটোকলটি ডেভিড মিলস 1985 সালে ARPANET নেটওয়ার্কের জন্য তৈরি করেছিলেন। প্রথম স্পেসিফিকেশন (RFC 958) 100 ms পর্যন্ত নির্ভুলতার সাথে একটি সহজ সিঙ্ক্রোনাইজেশন অ্যালগরিদম বর্ণনা করেছিল। NTPv3 (RFC 1305, 1992) একটি ফিল্টারিং অ্যালগরিদম এবং উন্নত বিলম্ব প্রক্রিয়াকরণ যোগ করেছিল। NTPv4 (RFC 5905, 2010) — বর্তমান সংস্করণ — IPv6 সমর্থন, স্বয়ংক্রিয় সার্ভার কনফিগারেশন এবং Network Time Security (NTS)-এর মাধ্যমে আক্রমণ থেকে সুরক্ষা অন্তর্ভুক্ত করে। 40 বছরে, প্রোটোকলটি একটি গবেষণা প্রকল্প থেকে একটি অবকাঠামো মানতে পরিণত হয়েছে, যা ছাড়া আর্থিক লেনদেন, টেলিকমিউনিকেশন এবং মোবাইল নেটওয়ার্ক অসম্ভব হবে।
NTP-এর কাজের নীতি নেটওয়ার্কে প্যাকেট ভ্রমণ সময় মাপার উপর ভিত্তি করে। ক্লায়েন্ট টাইমস্ট্যাম্প T1 (স্থানীয় প্রেরণের সময়) সহ একটি অনুরোধ পাঠায়। সার্ভার সময় T2 (সার্ভার সময়)-এ অনুরোধ গ্রহণ করে, টাইমস্ট্যাম্প T3 সহ একটি প্রতিক্রিয়া তৈরি করে এবং পাঠায়। ক্লায়েন্ট সময় T4-এ প্রতিক্রিয়া গ্রহণ করে। চারটি টাইমস্ট্যাম্প ব্যবহার করে, ক্লায়েন্ট অফসেট = ((T2 - T1) + (T3 - T4)) / 2 এবং বিলম্ব = (T4 - T1) - (T3 - T2) গণনা করে। যদি বিলম্ব 1 সেকেন্ডের বেশি হয়, ফলাফল অবিশ্বস্ত বলে বিবেচিত হয় — এটি ওভারলোডেড বা অস্থির চ্যানেল থেকে রক্ষা করে।
শুধু সঠিক সময় সেট করা যথেষ্ট নয় — একটি ডিভাইসের কোয়ার্টজ অসিলেটর তাপমাত্রা, বার্ধক্য এবং ভোল্টেজের কারণে ক্রমাগত ড্রিফট করে (সময় এগিয়ে বা পিছিয়ে যায়)। NTP PLL (Phase-Locked Loop) অ্যালগরিদম ব্যবহার করে এই সমস্যার সমাধান করে: এটি জোর করে সময় সেট করে না, বরং ঘড়ির গতি সামঞ্জস্য করে। যদি ডিভাইসটি প্রতি ঘন্টায় 0.1 সেকেন্ড দ্রুত হয়, NTP সিস্টেম ঘড়িকে ধীর করে দেয় যতক্ষণ না ড্রিফট ক্ষতিপূরণ করা হয়। এই পদ্ধতি স্থিতিশীল নেটওয়ার্কে প্রতি 30 সেকেন্ডের পরিবর্তে প্রতি কয়েক ঘন্টায় সিঙ্ক্রোনাইজেশন অনুমতি দেয়।
// Simplified NTP algorithm schema
struct NTPPacket {
uint8_t flags; // LI, VN, Mode
uint8_t stratum; // server stratum level
uint32_t refTimestamp; // reference timestamp
uint32_t originTimestamp; // T1
uint32_t recvTimestamp; // T2
uint32_t xmitTimestamp; // T3
};
// Calculate offset and delay
double offset = ((t2 - t1) + (t3 - t4)) / 2.0;
double delay = (t4 - t1) - (t3 - t2);
সম্পূর্ণ NTP সিস্টেম একটি হায়ারার্কিতে সংগঠিত, যেখানে প্রতিটি স্তরকে স্ট্রেটাম বলা হয়। স্ট্রেটাম 0 হল রেফারেন্স ঘড়ি: পারমাণবিক ঘড়ি, GPS রিসিভার বা WWVB রেডিও সিগন্যাল। এই ডিভাইসগুলি সরাসরি নেটওয়ার্কের সাথে সংযুক্ত নয়। স্ট্রেটাম 1 — সার্ভার যা সরাসরি রেফারেন্স ঘড়ির সাথে সংযুক্ত। স্ট্রেটাম 2 স্ট্রেটাম 1 থেকে সময় গ্রহণ করে, স্ট্রেটাম 3 স্ট্রেটাম 2 থেকে, এবং এভাবে স্ট্রেটাম 15 পর্যন্ত। স্ট্রেটাম সংখ্যা যত বেশি, নির্ভুলতা তত কম হতে পারে — প্রতিটি স্তর সামান্য বিলম্ব এবং ত্রুটি যোগ করে। স্ট্রেটাম 16 মানে সময় উপলব্ধ নয় (সিঙ্ক্রোনাইজড নয়)।
| স্ট্রেটাম | বিবরণ | নির্ভুলতা |
|---|---|---|
| Stratum 0 | পারমাণবিক ঘড়ি, GPS, রেডিও সিগন্যাল | ন্যানোসেকেন্ড |
| Stratum 1 | রেফারেন্সের সাথে সংযুক্ত সার্ভার | মাইক্রোসেকেন্ড |
| Stratum 2 | পাবলিক NTP সার্ভার | 1–10 ms |
| Stratum 3 | প্রতিষ্ঠানের স্থানীয় সার্ভার | 10–50 ms |
| Stratum 4+ | ক্লায়েন্ট ডিভাইস | 100 ms পর্যন্ত |
মোবাইল ডিভাইসের জন্য, স্ট্রেটাম 2 সার্ভার সর্বোত্তম — এগুলি পর্যাপ্ত数量和য়ে আছে এবং নির্ভুলতা এবং প্রাপ্যতার মধ্যে ভাল ভারসাম্য প্রদান করে। উদাহরণস্বরূপ, pool.ntp.org সারা বিশ্বের হাজার হাজার সার্ভারের একটি পুল যা স্বয়ংক্রিয়ভাবে লোড বিতরণ করে। Android অ্যাপ্লিকেশনের জন্য, সরাসরি স্ট্রেটাম 1 ব্যবহার করার পরামর্শ দেওয়া হয় না: প্রথমত, এটি প্রাথমিক সার্ভারে অতিরিক্ত লোড তৈরি করে, এবং দ্বিতীয়ত, একটি মোবাইল ডিভাইসের কেবল 10–50 ms নির্ভুলতা প্রয়োজন, যা স্ট্রেটাম 2 প্রদান করে। কর্পোরেট নেটওয়ার্কে, একটি স্থানীয় স্ট্রেটাম 3-4 সার্ভার সেটআপ করা হয় যা বাহ্যিক স্ট্রেটাম 2-এর সাথে সিঙ্ক্রোনাইজ হয়।
SNTP (Simple Network Time Protocol, RFC 4330) সীমিত সম্পদযুক্ত ডিভাইসের জন্য NTP-এর একটি সরলীকৃত বাস্তবায়ন: মাইক্রোকন্ট্রোলার, IoT সেন্সর এবং মোবাইল অ্যাপ্লিকেশন যার উচ্চ নির্ভুলতার প্রয়োজন নেই। সম্পূর্ণ NTP-এর বিপরীতে, SNTP একাধিক সার্ভারের ফিল্টারিং করে না, ঘড়ি ড্রিফট বিশ্লেষণ করে না এবং জটিল PLL অ্যালগরিদম ব্যবহার করে না। একটি SNTP ক্লায়েন্ট অনুরোধ পাঠায়, প্রতিক্রিয়া গ্রহণ করে এবং একবার সময় সেট করে। নেটওয়ার্কের উপর নির্ভর করে SNTP নির্ভুলতা 10–100 ms — এটি আর্থিক লেনদেন ব্যতীত, অধিকাংশ মোবাইল পরিস্থিতির জন্য যথেষ্ট।
SNTP Android অ্যাপ্লিকেশনের জন্য উপযুক্ত যেগুলিকে ক্রমাগত সিঙ্ক্রোনাইজেশন বজায় না রেখে সার্ভার থেকে বর্তমান সময় পেতে হবে। উদাহরণস্বরূপ, একটি অ্যাপ লগইনে সার্ভারের সময় দেখায় বা দিনে একবার সিঙ্ক্রোনাইজ হয়। সম্পূর্ণ NTP সার্ভার সিস্টেম, টেলিকমিউনিকেশন সরঞ্জাম, আর্থিক প্ল্যাটফর্ম এবং বিতরণকৃত ডাটাবেসের জন্য প্রয়োজন যেখানে ধারাবাহিক নির্ভুলতা এবং ড্রিফট মনিটরিং গুরুত্বপূর্ণ। মোবাইল ডেভেলপমেন্টের জন্য, SNTP যথেষ্ট — অন্তর্নির্মিত Android সময় পরিষেবা Google সার্ভারের সাথে পর্যায়ক্রমিক সিঙ্ক্রোনাইজেশনের জন্য এটি ব্যবহার করে।
Android অ্যাপ্লিকেশনে, NTP-এর মাধ্যমে সঠিক সময় পাওয়া প্রয়োজন যখন সিস্টেম সময় ব্যবহারকারী দ্বারা পরিবর্তন করা যেতে পারে বা নেটওয়ার্কের অভাবের কারণে প্রকৃত সময় থেকে আলাদা হয়। Android-এ কোনো অন্তর্নির্মিত পাবলিক NTP ক্লায়েন্ট নেই — ডেভেলপাররা Apache Commons Net SntpClient লাইব্রেরি বা তৃতীয়-পক্ষের সমাধান ব্যবহার করে। 2022 সালে, Google Android API-তে (Google Play Services-এর মাধ্যমে) একটি অভ্যন্তরীণ SntpClient ক্লাস যোগ করেছিল, কিন্তু এটির কনফিগারেশন প্রয়োজন এবং সাধারণ ব্যবহারের জন্য নথিভুক্ত নয়। একটি বিকল্প পদ্ধতি হল REST API-এর মাধ্যমে সময় অনুরোধ করা যা প্রতিক্রিয়া বডিতে সার্ভার টাইমস্ট্যাম্প ফেরত দেয়।
Android-এ একটি মৌলিক SNTP বাস্তবায়নের মধ্যে একটি NTP সার্ভারে (যেমন pool.ntp.org) UDP প্যাকেট পাঠানো, প্রতিক্রিয়া পার্স করা এবং ট্রান্সমিট টাইমস্ট্যাম্প (T3) বের করা অন্তর্ভুক্ত। কোডটিকে নেটওয়ার্ক টাইমআউট এবং পার্সিং ত্রুটিগুলি পরিচালনা করতে হবে — বাস্তব অ্যাপ্লিকেশনে, এই অপারেশনটি ব্যাকগ্রাউন্ড থ্রেডে সঞ্চালিত হয় এবং ফলাফলটি পরবর্তী সিঙ্ক্রোনাইজেশন পর্যন্ত ক্যাশে করা হয়। Apache Commons Net লাইব্রেরি একটি প্রস্তুত NTPUDPClient ক্লাস সরবরাহ করে যা build.gradle-এ নির্ভরতা যোগ করে ন্যূনতম পরিবর্তনের সাথে Android-এ ব্যবহার করা যেতে পারে।
// Get NTP time via Apache Commons Net
fun getNtpTime(server: String = "pool.ntp.org"): Date? {
return try {
val client = NTPUDPClient()
client.setDefaultTimeout(5000)
val info = client.getTime(InetAddress.getByName(server))
client.close()
Date(info.getMessage().getTransmitTimeStamp().getTime())
} catch (e: Exception) {
null
}
}
NTP-এর নির্ভুলতা বিভিন্ন কারণের উপর নির্ভর করে: নেটওয়ার্ক বিলম্ব (RTT), চ্যানেল স্থিতিশীলতা, সার্ভার লোড এবং স্থানীয় ঘড়ি জেনারেটরের গুণমান। 1 ms-এর কম বিলম্বযুক্ত স্থানীয় নেটওয়ার্কে, NTP 0.1–1 ms নির্ভুলতা অর্জন করে। 10–50 ms বিলম্বযুক্ত ইন্টারনেটে, নির্ভুলতা 10–50 ms-এ নেমে আসে। একক নির্ভুলতার চেয়ে বেশি গুরুত্বপূর্ণ হল স্থিতিশীলতা: যদি বিলম্ব পরিবর্তিত হয় (jitter), NTP-কে নির্ভরযোগ্য অফসেট গণনা করতে আরও সময় প্রয়োজন। মোবাইল ডিভাইসের জন্য, অস্থিরতার প্রধান কারণ হল Wi-Fi এবং মোবাইল নেটওয়ার্কের মধ্যে স্যুইচিং, যেখানে বিলম্ব মাত্রার ক্রম অনুসারে পরিবর্তিত হতে পারে।
সঠিক সময়ের প্রতি সংবেদনশীল Android অ্যাপ্লিকেশনের জন্য, সুপারিশ করা হয়: একাধিক NTP সার্ভার ব্যবহার করুন এবং সর্বনিম্ন বিলম্বযুক্তটি নির্বাচন করুন; নেটওয়ার্ক স্যুইচের সময় সিঙ্ক্রোনাইজেশন এড়িয়ে চলুন; শেষ প্রাপ্ত সময় ক্যাশে করুন এবং System.currentTimeMillis-এর মাধ্যমে এটি সামঞ্জস্য করুন। গেম এবং রিয়েল-টাইম অ্যাপ্লিকেশনের জন্য (NTP নেটওয়ার্ক লেটেন্সির কারণে এখানে উপযুক্ত নয়) — প্রতিটি অনুরোধে প্রেরিত সার্ভার সময় ব্যবহার করুন। আর্থিক অ্যাপ্লিকেশনে, সর্বদা সার্ভারের সাথে পার্থক্য পরীক্ষা করুন — যদি পার্থক্য 5 সেকেন্ডের বেশি হয়, অপারেশনটিকে সম্ভাব্য অনিরাপদ হিসাবে ব্লক করুন।
সচরাচর জিজ্ঞাসিত প্রশ্ন
NTP (Network Time Protocol) ইন্টারনেটের মাধ্যমে ঘড়ি সিঙ্ক্রোনাইজেশন প্রোটোকল। UTC রেফারেন্সের সাথে ডিভাইসের সময় সারিবদ্ধ করার জন্য এটি প্রয়োজন। NTP ছাড়া, কোয়ার্টজ অসিলেটর ড্রিফটের কারণে কম্পিউটারের ঘড়ি প্রতিদিন সেকেন্ডের পর সেকেন্ড পিছিয়ে যায়, যা আর্থিক লেনদেন, লগিং এবং নিরাপত্তার জন্য গুরুত্বপূর্ণ।
NTP সিস্টেম স্তর — স্ট্রেটা ব্যবহার করে: স্ট্রেটাম 0 (পারমাণবিক ঘড়ি এবং GPS), স্ট্রেটাম 1 (রেফারেন্সের সাথে সংযুক্ত সার্ভার), স্ট্রেটাম 2 (পাবলিক NTP সার্ভার), স্ট্রেটাম 3–4 (স্থানীয় সার্ভার), স্ট্রেটাম 5–15 (ক্লায়েন্ট)। স্ট্রেটাম যত বেশি, সম্ভাব্য ত্রুটি তত বেশি। স্ট্রেটাম 16 মানে সময় সিঙ্ক্রোনাইজড নয়।
SNTP সীমিত সম্পদযুক্ত ডিভাইসের জন্য NTP-এর একটি সরলীকৃত সংস্করণ। এটি সার্ভার ফিল্টার করে না, ঘড়ি ড্রিফট বিশ্লেষণ করে না বা PLL ব্যবহার করে না। SNTP মোবাইল অ্যাপ্লিকেশনের জন্য উপযুক্ত যেখানে 10–100 ms নির্ভুলতা যথেষ্ট। সার্ভার, টেলিকমিউনিকেশন সরঞ্জাম এবং ফিনটেক সিস্টেমের জন্য সম্পূর্ণ NTP প্রয়োজন।
Apache Commons Net লাইব্রেরি NTPUDPClient ক্লাসের সাথে ব্যবহার করুন। pool.ntp.org-এ অনুরোধ পাঠান, প্রতিক্রিয়া পান এবং ট্রান্সমিট টাইমস্ট্যাম্প বের করুন। বিকল্পভাবে, আপনার সার্ভারের REST API ব্যবহার করুন, যা Date হেডার বা প্রতিক্রিয়া বডিতে Unix Timestamp ফর্ম্যাটে সার্ভার সময় ফেরত দেয়।
NTP সিঙ্ক্রোনাইজেশন ছাড়া, ডিভাইসের সিস্টেম সময় মিনিট বা ঘন্টা পর্যন্ত পার্থক্য হতে পারে। এটি পুশ নোটিফিকেশন, SSL সার্টিফিকেট যাচাইকরণ, লগ, টাস্ক শিডিউলার এবং ক্রিপ্টোগ্রাফিক প্রোটোকল ব্যাহত করে। আর্থিক অ্যাপ্লিকেশনে, 5 সেকেন্ডের বেশি পার্থক্য নিরাপত্তা হুমকি হিসাবে বিবেচিত হয়।
সারাংশ
আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব
IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।
আরও পড়ুন