কর্মক্ষমতা সুবিধা

ভূমিকা: DNS বিলম্বের কারণ এবং প্রশমন

যেহেতু ওয়েব পৃষ্ঠাগুলি আরও জটিল হয়ে উঠেছে, অসংখ্য ডোমেন থেকে সংস্থানগুলিকে উল্লেখ করে, DNS লুকআপগুলি ব্রাউজিং অভিজ্ঞতায় একটি গুরুত্বপূর্ণ বাধা হয়ে দাঁড়াতে পারে৷ যখনই কোনও ক্লায়েন্টকে নেটওয়ার্কে একটি DNS সমাধানকারীকে জিজ্ঞাসা করতে হয়, তখন প্রবর্তিত লেটেন্সি তাৎপর্যপূর্ণ হতে পারে, রিসোলভারকে যে নৈকট্য এবং নাম সার্ভারের সংখ্যার উপর নির্ভর করে প্রশ্ন করতে হয় (2টির বেশি বিরল, তবে এটি ঘটতে পারে)। উদাহরণ হিসেবে, নিচের স্ক্রিন শটটি পেজ স্পিড ওয়েব পারফরম্যান্স পরিমাপ টুল দ্বারা রিপোর্ট করা সময় দেখায়। প্রতিটি বার পৃষ্ঠা থেকে উল্লেখ করা একটি সম্পদ প্রতিনিধিত্ব করে; কালো অংশগুলি DNS লুকআপ নির্দেশ করে। এই পৃষ্ঠায়, প্রথম 11 সেকেন্ডে 13টি লুকআপ তৈরি করা হয় যেখানে পৃষ্ঠাটি লোড করা হয়। যদিও বেশ কয়েকটি লুকআপ সমান্তরালভাবে করা হয়েছে, স্ক্রিন শট দেখায় যে 5টি সিরিয়াল লুকআপ সময় প্রয়োজন, মোট 11 সেকেন্ডের পৃষ্ঠা লোড সময়ের কয়েক সেকেন্ডের জন্য অ্যাকাউন্টিং।

DNS লেটেন্সির দুটি উপাদান রয়েছে:

  • ক্লায়েন্ট (ব্যবহারকারী) এবং DNS সমাধানকারী সার্ভারের মধ্যে বিলম্ব। বেশিরভাগ ক্ষেত্রে এটি মূলত নেটওয়ার্ক সিস্টেমে স্বাভাবিক রাউন্ড-ট্রিপ টাইম (RTT) সীমাবদ্ধতার কারণে হয়: ক্লায়েন্ট এবং সার্ভার মেশিনের মধ্যে ভৌগলিক দূরত্ব; নেটওয়ার্ক কনজেশন; প্যাকেট ক্ষতি এবং দীর্ঘ পুনঃপ্রচার বিলম্ব (গড়ে এক সেকেন্ড); ওভারলোড সার্ভার, ডিনায়াল-অফ-সার্ভিস আক্রমণ এবং তাই।
  • সমাধানকারী সার্ভার এবং অন্যান্য নাম সার্ভারের মধ্যে বিলম্ব। বিলম্বের এই উত্সটি প্রাথমিকভাবে নিম্নলিখিত কারণগুলির দ্বারা সৃষ্ট হয়:
    • ক্যাশে মিস। যদি একটি রিসোলভারের ক্যাশে থেকে একটি প্রতিক্রিয়া পরিবেশন করা না যায়, তবে অন্য নাম সার্ভারগুলিকে পুনরাবৃত্তিমূলকভাবে জিজ্ঞাসা করা প্রয়োজন, যোগ করা নেটওয়ার্ক লেটেন্সি যথেষ্ট, বিশেষ করে যদি প্রামাণিক সার্ভারগুলি ভৌগলিকভাবে দূরবর্তী হয়।
    • আন্ডারপ্রভিশনিং যদি ডিএনএস সমাধানকারী ওভারলোড হয়, তবে তাদের অবশ্যই ডিএনএস রেজোলিউশনের অনুরোধ এবং প্রতিক্রিয়াগুলি সারিবদ্ধ করতে হবে এবং প্যাকেটগুলি ফেলে দেওয়া এবং পুনরায় প্রেরণ করা শুরু করতে পারে৷
    • দূষিত ট্রাফিক. এমনকি যদি একটি DNS পরিষেবা অতিরিক্ত ব্যবস্থা করা হয়, DoS ট্র্যাফিক সার্ভারগুলিতে অযৌক্তিক লোড রাখতে পারে। একইভাবে, কামিনস্কি-স্টাইলের আক্রমণে প্লাডিং রিসোলভারকে এমন প্রশ্নের সাথে জড়িত থাকতে পারে যা ক্যাশে বাইপাস করার গ্যারান্টিযুক্ত এবং রেজোলিউশনের জন্য বহির্গামী অনুরোধের প্রয়োজন।

আমরা বিশ্বাস করি যে ক্যাশে মিস ফ্যাক্টর হল ডিএনএস লেটেন্সির সবচেয়ে প্রভাবশালী কারণ এবং নীচে আরও আলোচনা করুন৷

ক্যাশে মিস

এমনকি যদি একজন সমাধানকারীর প্রচুর স্থানীয় সম্পদ থাকে, তবে দূরবর্তী নাম সার্ভারের সাথে কথা বলার সাথে সম্পর্কিত মৌলিক বিলম্বগুলি এড়ানো কঠিন। অন্য কথায়, ধরে নিচ্ছি যে সমাধানকারী যথেষ্ট ভালভাবে প্রবিধান করা হয়েছে যাতে ক্যাশে হিটগুলি সার্ভার-সাইডে শূন্য সময় নেয়, ক্যাশে মিসগুলি লেটেন্সির ক্ষেত্রে খুব ব্যয়বহুল থাকে। একটি মিস পরিচালনা করতে, একজন সমাধানকারীকে কমপক্ষে একটির সাথে কথা বলতে হয়, তবে প্রায়শই দুটি বা তার বেশি বাহ্যিক নাম সার্ভারের সাথে কথা বলতে হয়। Googlebot ওয়েব ক্রলার পরিচালনা করে, আমরা সাড়া দেয় এমন নাম সার্ভারগুলির জন্য গড় রেজোলিউশন সময় 130 ms লক্ষ্য করেছি৷ যাইহোক, ইউডিপি প্যাকেট লস এবং সার্ভারগুলি পৌঁছনোর অযোগ্য হওয়ার কারণে, পূর্ণ 4-6% অনুরোধের সময় শেষ হয়। যদি আমরা প্যাকেট লস, ডেড নেম সার্ভার, ডিএনএস কনফিগারেশন ত্রুটি ইত্যাদির মতো ব্যর্থতাগুলি বিবেচনা করি, প্রকৃত গড় এন্ড-টু-এন্ড রেজোলিউশন সময় 300-400 ms। যাইহোক, উচ্চ বৈচিত্র্য এবং একটি দীর্ঘ লেজ আছে।

যদিও ক্যাশে মিস রেট ডিএনএস সার্ভারের মধ্যে পরিবর্তিত হতে পারে, নিম্নলিখিত কারণে ক্যাশে মিস করা মৌলিকভাবে এড়ানো কঠিন:

  • ইন্টারনেটের আকার এবং বৃদ্ধি। বেশ সহজভাবে, ইন্টারনেটের বৃদ্ধির সাথে সাথে, নতুন ব্যবহারকারী এবং নতুন সাইট উভয়ের মাধ্যমেই, বেশিরভাগ বিষয়বস্তু প্রান্তিক আগ্রহের। যদিও কয়েকটি সাইট (এবং এর ফলে ডিএনএস নাম) খুব জনপ্রিয়, বেশিরভাগই শুধুমাত্র কয়েকজন ব্যবহারকারীর জন্য আগ্রহী এবং খুব কমই অ্যাক্সেস করা হয়; তাই বেশিরভাগ অনুরোধের ফলে ক্যাশে মিস হয়।
  • কম সময়-টু-লাইভ (TTL) মান। নিম্ন DNS TTL মানগুলির দিকে প্রবণতার অর্থ হল রেজোলিউশনগুলির আরও ঘন ঘন সন্ধানের প্রয়োজন৷
  • ক্যাশে বিচ্ছিন্নতা। DNS সার্ভারগুলি সাধারণত লোড ব্যালেন্সারের পিছনে মোতায়েন করা হয় যা এলোমেলোভাবে বিভিন্ন মেশিনে প্রশ্ন বরাদ্দ করে। এর ফলে প্রতিটি পৃথক সার্ভার একটি শেয়ার্ড পুল থেকে ক্যাশে করা রেজোলিউশনগুলি পুনরায় ব্যবহার করতে সক্ষম হওয়ার পরিবর্তে একটি পৃথক ক্যাশে বজায় রাখে।

প্রশমন

Google পাবলিক ডিএনএস-এ, আমরা ডিএনএস লুকআপের সময় দ্রুত করার জন্য বিভিন্ন পদ্ধতি প্রয়োগ করেছি। এই পদ্ধতির কিছু মোটামুটি মানসম্মত; অন্যরা পরীক্ষামূলক:

পর্যাপ্তভাবে ক্লাস্টার পরিবেশন করা

ক্যাশিং ডিএনএস সমাধানকারীদের প্রামাণিক নাম সার্ভারের চেয়ে বেশি ব্যয়বহুল ক্রিয়াকলাপ সম্পাদন করতে হয়, যেহেতু অনেক প্রতিক্রিয়া মেমরি থেকে পরিবেশন করা যায় না; পরিবর্তে, তাদের অন্যান্য নাম সার্ভারের সাথে যোগাযোগের প্রয়োজন হয় এবং এইভাবে প্রচুর নেটওয়ার্ক ইনপুট/আউটপুট দাবি করে। অধিকন্তু, ওপেন রেজোলিউররা ক্যাশে বিষাক্ত করার প্রচেষ্টার জন্য অত্যন্ত ঝুঁকিপূর্ণ, যা ক্যাশে মিস রেট বাড়ায় (এই ধরনের আক্রমণগুলি বিশেষভাবে জাল নামের জন্য অনুরোধ পাঠায় যা ক্যাশে থেকে সমাধান করা যায় না), এবং DoS আক্রমণে, যা ট্রাফিক লোড বাড়ায়। যদি সমাধানকারীদের পর্যাপ্তভাবে প্রবিধান না করা হয় এবং লোডের সাথে তাল মিলিয়ে চলতে না পারে, তাহলে এটি কর্মক্ষমতার উপর খুব নেতিবাচক প্রভাব ফেলতে পারে। প্যাকেটগুলি বাদ দেওয়া হয় এবং পুনরায় প্রেরণ করা প্রয়োজন, নাম সার্ভারের অনুরোধগুলি সারিবদ্ধ হতে হবে এবং আরও অনেক কিছু। এই সব কারণ বিলম্ব যোগ.

তাই, উচ্চ-ভলিউম ইনপুট/আউটপুটের জন্য ডিএনএস সমাধানকারীদের জন্য ব্যবস্থা করা গুরুত্বপূর্ণ। এর মধ্যে সম্ভাব্য DDoS আক্রমণগুলি পরিচালনা করা অন্তর্ভুক্ত, যার একমাত্র কার্যকর সমাধান হল অনেকগুলি মেশিনের সাথে অতিরিক্ত ব্যবস্থা করা। একই সময়ে, যাইহোক, যখন আপনি মেশিন যোগ করেন তখন ক্যাশে হিট রেট না কমানো গুরুত্বপূর্ণ; এর জন্য একটি কার্যকর লোড-ব্যালেন্সিং নীতি বাস্তবায়নের প্রয়োজন, যা আমরা নীচে আলোচনা করছি।

শেয়ার্ড ক্যাশিংয়ের জন্য লোড-ব্যালেন্সিং

মেশিন যোগ করে স্কেলিং রেজলভার পরিকাঠামো আসলে ব্যাকফায়ার করতে পারে এবং লোড ব্যালেন্সিং সঠিকভাবে না করা হলে ক্যাশ হিট রেট কমাতে পারে । একটি সাধারণ স্থাপনায়, একাধিক মেশিন একটি লোড ব্যালেন্সারের পিছনে বসে থাকে যা রাউন্ড রবিনের মতো একটি সাধারণ অ্যালগরিদম ব্যবহার করে প্রতিটি মেশিনে সমানভাবে ট্রাফিক বিতরণ করে। এর ফলাফল হল যে প্রতিটি মেশিন তার নিজস্ব স্বতন্ত্র ক্যাশে বজায় রাখে, যাতে ক্যাশে করা বিষয়বস্তু মেশিন জুড়ে বিচ্ছিন্ন হয়। ট্রাফিকের প্রকৃতির উপর নির্ভর করে যদি প্রতিটি ইনকামিং কোয়েরি একটি এলোমেলো মেশিনে বিতরণ করা হয়, তাহলে কার্যকর ক্যাশে মিস রেট আনুপাতিকভাবে বাড়ানো যেতে পারে। উদাহরণ স্বরূপ, দীর্ঘ TTL সহ নামগুলির জন্য যা বারবার জিজ্ঞাসা করা হয়, ক্যাশে মিস রেট ক্লাস্টারে মেশিনের সংখ্যা দ্বারা বাড়ানো যেতে পারে। (খুব সংক্ষিপ্ত TTL সহ নামের জন্য, যেগুলি খুব কমই জিজ্ঞাসা করা হয়, বা যার ফলে ক্যাশেযোগ্য প্রতিক্রিয়া দেখা যায় (0 TTL এবং ত্রুটি), মেশিন যোগ করার মাধ্যমে ক্যাশে মিস রেট সত্যিই প্রভাবিত হয় না।)

ক্যাশেযোগ্য নামের জন্য হিট রেট বাড়ানোর জন্য, সার্ভার লোড-ব্যালেন্স করা গুরুত্বপূর্ণ যাতে ক্যাশে খণ্ডিত না হয়। গুগল পাবলিক ডিএনএস-এ, আমাদের ক্যাশিংয়ের দুটি স্তর রয়েছে। মেশিনের একটি পুলে, ব্যবহারকারীর খুব কাছাকাছি, একটি ছোট প্রতি মেশিন ক্যাশে সর্বাধিক জনপ্রিয় নাম রয়েছে। এই ক্যাশে থেকে কোনো প্রশ্ন সন্তুষ্ট না হলে, এটি মেশিনের অন্য পুলে পাঠানো হয় যা ক্যাশে নাম দিয়ে বিভাজন করে। এই দ্বিতীয় স্তরের ক্যাশের জন্য, একই নামের জন্য সমস্ত ক্যোয়ারী একই মেশিনে পাঠানো হয়, যেখানে নামটি হয় ক্যাশে করা হয় বা হয় না।

বিস্তৃত ভৌগলিক কভারেজের জন্য পরিবেশন ক্লাস্টার বিতরণ করা

বন্ধ সমাধানকারীদের জন্য, এটি সত্যিই একটি সমস্যা নয়। উন্মুক্ত সমাধানকারীদের জন্য, আপনার সার্ভারগুলি আপনার ব্যবহারকারীদের কাছে যত কাছাকাছি থাকবে, ক্লায়েন্টের শেষে তারা তত কম লেটেন্সি দেখতে পাবে। উপরন্তু, পর্যাপ্ত ভৌগলিক কভারেজ থাকা পরোক্ষভাবে শেষ থেকে শেষ লেটেন্সি উন্নত করতে পারে, কারণ নাম সার্ভারগুলি সাধারণত DNS সমাধানকারীর অবস্থানের জন্য অপ্টিমাইজ করা ফলাফল প্রদান করে। অর্থাৎ, যদি কোনো বিষয়বস্তু প্রদানকারী বিশ্বজুড়ে মিরর করা সাইটগুলি হোস্ট করে, তাহলে সেই প্রদানকারীর নাম সার্ভারগুলি ডিএনএস সমাধানকারীর নিকটতম আইপি ঠিকানাটি ফিরিয়ে দেবে।

Google পাবলিক DNS বিশ্বব্যাপী ডেটা সেন্টারে হোস্ট করা হয় এবং ব্যবহারকারীদের ভৌগলিকভাবে নিকটতম ডেটা সেন্টারে পাঠাতে যেকোনওকাস্ট রাউটিং ব্যবহার করে।

উপরন্তু, Google পাবলিক DNS EDNS ক্লায়েন্ট সাবনেট (ECS) সমর্থন করে, একটি DNS প্রোটোকল এক্সটেনশন সমাধানকারীদের জন্য ক্লায়েন্টের অবস্থান নাম সার্ভারে ফরওয়ার্ড করার জন্য, যা প্রকৃত ক্লায়েন্ট আইপি ঠিকানার জন্য অপ্টিমাইজ করা অবস্থান-সংবেদনশীল প্রতিক্রিয়া প্রদান করতে পারে, সমাধানকারীর IP ঠিকানার পরিবর্তে। বিস্তারিত জানার জন্য এই FAQ পড়ুন. Google পাবলিক DNS স্বয়ংক্রিয়ভাবে নাম সার্ভার সনাক্ত করে যা EDNS ক্লায়েন্ট সাবনেট সমর্থন করে।