বিষয়বস্তু বিতরণ নেটওয়ার্ক (CDN)

একটি সামগ্রী বিতরণ নেটওয়ার্ক ব্যবহার করে কর্মক্ষমতা উন্নত করুন।

কেটি হেমপেনিয়াস

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

ওভারভিউ

একটি সামগ্রী বিতরণ নেটওয়ার্ক সার্ভারগুলির একটি নেটওয়ার্ক নিয়ে গঠিত যা ব্যবহারকারীদের কাছে দ্রুত সামগ্রী সরবরাহ করার জন্য অপ্টিমাইজ করা হয়। যদিও CDN গুলি তর্কযোগ্যভাবে ক্যাশে কন্টেন্ট পরিবেশনের জন্য সবচেয়ে বেশি পরিচিত, CDN গুলি ক্যাশে অযোগ্য কন্টেন্টের ডেলিভারিও উন্নত করতে পারে। সাধারণভাবে বলতে গেলে, আপনার CDN দ্বারা আপনার সাইট যত বেশি বিতরণ করা হবে, তত ভাল।

উচ্চ-স্তরে, CDN-এর কার্যকারিতা সুবিধাগুলি মুষ্টিমেয় কিছু নীতি থেকে উদ্ভূত হয়: CDN সার্ভারগুলি অরিজিন সার্ভারের তুলনায় ব্যবহারকারীদের কাছাকাছি অবস্থান করে এবং তাই একটি ছোট রাউন্ড-ট্রিপ টাইম (RTT) লেটেন্সি থাকে; নেটওয়ার্কিং অপ্টিমাইজেশানগুলি CDN-গুলিকে অরিজিন সার্ভার থেকে বিষয়বস্তু "সরাসরি" লোড করার চেয়ে আরও দ্রুত সামগ্রী সরবরাহ করতে দেয়; সবশেষে, CDN ক্যাশে অরিজিন সার্ভারে ভ্রমণ করার অনুরোধের প্রয়োজনীয়তা দূর করে।

সম্পদ বিতরণ

যদিও এটি অ-স্বজ্ঞাত বলে মনে হতে পারে, রিসোর্স (এমনকি ক্যাশে অযোগ্য) সরবরাহ করার জন্য একটি CDN ব্যবহার করা সাধারণত ব্যবহারকারীকে আপনার সার্ভার থেকে "সরাসরি" রিসোর্স লোড করার চেয়ে দ্রুততর হবে৷

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

কিছু CDN ইন্টারনেট জুড়ে ছড়িয়ে থাকা একাধিক CDN সার্ভারের মাধ্যমে ট্রাফিককে মূলের দিকে রুট করার মাধ্যমে আরও উন্নতি করে। CDN সার্ভারের মধ্যে সংযোগগুলি বর্ডার গেটওয়ে প্রোটোকল (BGP) দ্বারা নির্ধারিত রুটের পরিবর্তে নির্ভরযোগ্য এবং অত্যন্ত অপ্টিমাইজ করা রুটের মাধ্যমে ঘটে। যদিও BGP হল ইন্টারনেটের ডি ফ্যাক্টো রাউটিং প্রোটোকল, এর রাউটিং সিদ্ধান্ত সবসময় কর্মক্ষমতা-ভিত্তিক হয় না। অতএব, BGP-নির্ধারিত রুটগুলি CDN সার্ভারগুলির মধ্যে সূক্ষ্মভাবে সুরক্ষিত রুটের তুলনায় কম পারফরম্যান্স হতে পারে।

ক্যাশিং

একটি CDN এর সার্ভারে ক্যাশিং রিসোর্স পরিবেশন করার জন্য উত্স পর্যন্ত সমস্ত পথ ভ্রমণ করার অনুরোধের প্রয়োজনীয়তা দূর করে। ফলস্বরূপ, সম্পদ আরো দ্রুত বিতরণ করা হয়; এটি অরিজিন সার্ভারে লোডও হ্রাস করে।

ক্যাশে সম্পদ যোগ করা হচ্ছে

CDN ক্যাশে পপুলেট করার সবচেয়ে বেশি ব্যবহৃত পদ্ধতি হল CDN "পুল" রিসোর্স যেমন প্রয়োজন হয় - এটি "অরিজিন পুল" নামে পরিচিত। প্রথমবার যখন ক্যাশে থেকে একটি নির্দিষ্ট সংস্থান অনুরোধ করা হয় তখন CDN এটিকে অরিজিন সার্ভার থেকে অনুরোধ করবে এবং প্রতিক্রিয়াটি ক্যাশে করবে। এই পদ্ধতিতে, ক্যাশের বিষয়বস্তু সময়ের সাথে সাথে তৈরি করা হয় কারণ অতিরিক্ত আনক্যাশড রিসোর্স অনুরোধ করা হয়।

ক্যাশে থেকে সম্পদ সরানো হচ্ছে

CDNs ক্যাশে থেকে অপ্রয়োজনীয় সম্পদগুলিকে পর্যায়ক্রমে সরাতে ক্যাশে উচ্ছেদ ব্যবহার করে। উপরন্তু, সাইটের মালিকরা স্পষ্টভাবে রিসোর্স মুছে ফেলার জন্য purging ব্যবহার করতে পারেন।

• ক্যাশে উচ্ছেদ

  ক্যাশে একটি সীমিত স্টোরেজ ক্ষমতা আছে. যখন একটি ক্যাশে তার ধারণক্ষমতার কাছাকাছি হয়, তখন এটি এমন সংস্থানগুলিকে সরিয়ে দিয়ে নতুন সংস্থানগুলির জন্য জায়গা করে দেয় যেগুলি সম্প্রতি অ্যাক্সেস করা হয়নি বা যেগুলি অনেক জায়গা নেয়। এই প্রক্রিয়াটি ক্যাশে উচ্ছেদ হিসাবে পরিচিত। একটি রিসোর্স একটি ক্যাশে থেকে উচ্ছেদ হওয়ার মানে এই নয় যে এটি একটি CDN নেটওয়ার্কের সমস্ত ক্যাশে থেকে উচ্ছেদ করা হয়েছে৷

• শুদ্ধ করা

  শুদ্ধকরণ ("ক্যাশে অবৈধকরণ" নামেও পরিচিত) হল একটি CDN-এর ক্যাশে থেকে একটি সম্পদ অপসারণের একটি প্রক্রিয়া যার মেয়াদ শেষ হওয়ার জন্য অপেক্ষা না করে বা উচ্ছেদ করা হয়। এটি সাধারণত একটি API এর মাধ্যমে কার্যকর করা হয়। যেসব পরিস্থিতিতে বিষয়বস্তু প্রত্যাহার করতে হবে (উদাহরণস্বরূপ, টাইপো সংশোধন করা, মূল্যের ত্রুটি, বা ভুল সংবাদ নিবন্ধ) সেক্ষেত্রে শুদ্ধ করা গুরুত্বপূর্ণ। তার উপরে, এটি একটি সাইটের ক্যাশিং কৌশলে একটি গুরুত্বপূর্ণ ভূমিকা পালন করতে পারে।

  যদি একটি CDN কাছাকাছি তাত্ক্ষণিক purging সমর্থন করে, purging কে গতিশীল বিষয়বস্তুর ক্যাশে পরিচালনার জন্য একটি প্রক্রিয়া হিসাবে ব্যবহার করা যেতে পারে: একটি দীর্ঘ TTL ব্যবহার করে ক্যাশে ডায়নামিক সামগ্রী, তারপর যখনই এটি আপডেট করা হয় তখনই সংস্থানটি পরিস্কার করুন৷ এইভাবে, কখন রিসোর্স পরিবর্তন হবে তা আগে থেকে না জানা সত্ত্বেও একটি গতিশীল সম্পদের ক্যাশিং সময়কাল সর্বাধিক করা সম্ভব। এই কৌশলটিকে কখনও কখনও "হোল্ড-টিল-টোল্ড ক্যাশিং" হিসাবে উল্লেখ করা হয়।

  যখন শুদ্ধকরণ স্কেলে ব্যবহার করা হয় তখন এটি সাধারণত "ক্যাশে ট্যাগ" বা "সারোগেট ক্যাশে কী" নামে পরিচিত একটি ধারণার সাথে ব্যবহার করা হয়। এই পদ্ধতিটি সাইটের মালিকদের একটি ক্যাশ করা সম্পদের সাথে এক বা একাধিক অতিরিক্ত শনাক্তকারীকে (কখনও কখনও "ট্যাগ" হিসাবে উল্লেখ করা হয়) সংযুক্ত করতে দেয়। এই ট্যাগগুলি তখন অত্যন্ত দানাদার শুদ্ধকরণের জন্য ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, আপনি আপনার সাইটের ফুটার ধারণ করে এমন সমস্ত সংস্থানগুলিতে (উদাহরণস্বরূপ, /about , /blog ) একটি "পাদলেখ" ট্যাগ যোগ করতে পারেন৷ যখন ফুটার আপডেট করা হয়, তখন আপনার CDN কে নির্দেশ দিন "ফুটার" ট্যাগের সাথে যুক্ত সমস্ত সংস্থান শুদ্ধ করতে।

ক্যাশেযোগ্য সম্পদ

যদি এবং কিভাবে একটি সম্পদ ক্যাশে করা উচিত তা সরকারী বা ব্যক্তিগত কিনা তা নির্ভর করে; স্থির বা গতিশীল।

বেসরকারী এবং সরকারী সম্পদ

• ব্যক্তিগত সম্পদ

  ব্যক্তিগত সংস্থানগুলিতে একটি একক ব্যবহারকারীর উদ্দেশ্যে ডেটা থাকে এবং তাই CDN দ্বারা ক্যাশে করা উচিত নয়৷ ব্যক্তিগত সম্পদ Cache-Control: private শিরোনাম।

• পাবলিক রিসোর্স

  পাবলিক রিসোর্স ব্যবহারকারী-নির্দিষ্ট তথ্য ধারণ করে না এবং তাই একটি CDN দ্বারা ক্যাশেযোগ্য। একটি সম্পদ একটি CDN দ্বারা ক্যাশেযোগ্য বলে বিবেচিত হতে পারে যদি এটিতে একটি Cache-Control: no-store বা Cache-Control: private শিরোনাম না থাকে। একটি পাবলিক রিসোর্স কতটা সময় ধরে ক্যাশে করা যায় তার উপর নির্ভর করে কত ঘন ঘন সম্পদ পরিবর্তন হয়।

গতিশীল এবং স্ট্যাটিক বিষয়বস্তু

• গতিশীল বিষয়বস্তু

  ডায়নামিক কন্টেন্ট হল কন্টেন্ট যা ঘন ঘন পরিবর্তিত হয়। একটি API প্রতিক্রিয়া এবং একটি দোকান হোমপেজ এই বিষয়বস্তু ধরনের উদাহরণ. যাইহোক, এই বিষয়বস্তুটি ঘন ঘন পরিবর্তিত হওয়ার কারণে এটিকে ক্যাশে করা থেকে বিরত রাখে না। ভারী ট্র্যাফিকের সময়কালে, খুব অল্প সময়ের জন্য এই প্রতিক্রিয়াগুলি ক্যাশ করা (উদাহরণস্বরূপ, 5 সেকেন্ড) অরিজিন সার্ভারের লোডকে উল্লেখযোগ্যভাবে হ্রাস করতে পারে, যেখানে ডেটা সতেজতার উপর ন্যূনতম প্রভাব পড়ে।

• স্ট্যাটিক বিষয়বস্তু

  স্ট্যাটিক কন্টেন্ট কদাচিৎ পরিবর্তিত হয়, যদি কখনো হয়। চিত্র, ভিডিও এবং সংস্করণযুক্ত লাইব্রেরিগুলি সাধারণত এই বিষয়বস্তুর প্রকারের উদাহরণ। যেহেতু স্ট্যাটিক বিষয়বস্তু পরিবর্তিত হয় না, তাই এটি একটি লং টাইম টু লিভ (TTL)-এর সাথে ক্যাশে করা উচিত - উদাহরণস্বরূপ, 6 মাস বা 1 বছর৷

একটি CDN নির্বাচন করা হচ্ছে

একটি CDN নির্বাচন করার সময় কর্মক্ষমতা সাধারণত একটি শীর্ষ বিবেচ্য বিষয়। যাইহোক, একটি CDN যে অন্যান্য বৈশিষ্ট্যগুলি অফার করে (উদাহরণস্বরূপ, নিরাপত্তা এবং বিশ্লেষণ বৈশিষ্ট্য), সেইসাথে একটি CDN-এর মূল্য, সমর্থন এবং অনবোর্ডিং সবই একটি CDN নির্বাচন করার সময় বিবেচনা করা গুরুত্বপূর্ণ।

কর্মক্ষমতা

একটি উচ্চ-স্তরে, একটি CDN-এর কর্মক্ষমতা কৌশলটি লেটেন্সি কমানো এবং ক্যাশে হিট অনুপাত সর্বাধিক করার মধ্যে ট্রেডঅফের পরিপ্রেক্ষিতে চিন্তা করা যেতে পারে। অনেক পয়েন্ট অব উপস্থিতি (PoPs) সহ CDN কম লেটেন্সি প্রদান করতে পারে কিন্তু ট্রাফিক আরও ক্যাশে বিভক্ত হওয়ার ফলে কম ক্যাশ হিট অনুপাত অনুভব করতে পারে। বিপরীতভাবে, কম PoPs সহ CDNগুলি ভৌগলিকভাবে ব্যবহারকারীদের থেকে আরও দূরে অবস্থিত হতে পারে, তবে উচ্চ ক্যাশে হিট অনুপাত অর্জন করতে পারে।

এই ট্রেডঅফের ফলস্বরূপ, কিছু CDN ক্যাশে করার জন্য একটি টায়ার্ড পদ্ধতি ব্যবহার করে: ব্যবহারকারীদের কাছাকাছি অবস্থিত PoPs ("এজ ক্যাশে" নামেও পরিচিত) সেন্ট্রাল PoPs এর সাথে সম্পূরক হয় যার উচ্চ ক্যাশে হিট অনুপাত রয়েছে। যখন একটি প্রান্ত ক্যাশে একটি সংস্থান খুঁজে পায় না, তখন এটি সংস্থানের জন্য একটি কেন্দ্রীয় PoP-এর দিকে তাকাবে। এই পদ্ধতিটি একটি উচ্চতর সম্ভাবনার জন্য সামান্য বেশি লেটেন্সি ট্রেড করে যে রিসোর্সটি একটি CDN ক্যাশে থেকে পরিবেশন করা যেতে পারে - যদিও অগত্যা একটি প্রান্ত ক্যাশে নয়।

লেটেন্সি মিনিমাইজ করা এবং ক্যাশে হিট রেশিও বাড়ানোর মধ্যে ট্রেডঅফ হল একটি স্পেকট্রাম। কোনো বিশেষ পদ্ধতি সর্বজনীনভাবে ভালো নয়; যাইহোক, আপনার সাইটের প্রকৃতি এবং এর ব্যবহারকারী বেসের উপর নির্ভর করে, আপনি দেখতে পারেন যে এই পদ্ধতিগুলির মধ্যে একটি অন্যটির তুলনায় উল্লেখযোগ্যভাবে ভাল কর্মক্ষমতা প্রদান করে।

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

সবচেয়ে বড় কন্টেন্টফুল পেইন্টের (LCP) উপর প্রভাব

এই নিবন্ধে পূর্বে বর্ণিত হিসাবে, একটি CDN-এর প্রাথমিক উদ্দেশ্য হল ভৌগলিকভাবে ব্যবহারকারীদের কাছাকাছি থাকা সার্ভারগুলিতে সংস্থানগুলি বিতরণ করে বিলম্ব কমানো। এই কারণে, একটি CDN এর প্রাথমিক সুবিধা হল এটি লোডিং কর্মক্ষমতা উন্নত করে। বিশেষ করে, আপনার ওয়েবসাইটের সার্ভার-সাইড আর্কিটেকচারে একটি CDN প্রবর্তন করার সময় একটি সম্পদের টাইম টু ফার্স্ট বাইট (TTFB) উল্লেখযোগ্যভাবে উন্নত করা যেতে পারে।

যদিও TTFB একটি ব্যবহারকারী-কেন্দ্রিক কর্মক্ষমতা মেট্রিক নয়, এটি Largest Contentful Paint (LCP) এর সমস্যা নির্ণয়ের জন্য একটি গুরুত্বপূর্ণ মেট্রিক, যা একটি ব্যবহারকারী-কেন্দ্রিক মেট্রিক।

সিডিএনগুলি এলসিপির উন্নতিতে বিশেষভাবে কার্যকর কারণ তারা নথি সরবরাহের (কানেকশন সেটআপে TTFB হ্রাস করে এবং নথি ক্যাশে) এবং এলসিপি উপাদান রেন্ডার করার জন্য প্রয়োজনীয় যে কোনও স্ট্যাটিক সংস্থান সরবরাহের উন্নতি করতে পারে।

অতিরিক্ত বৈশিষ্ট্য

CDN সাধারণত তাদের মূল CDN অফার ছাড়াও বিভিন্ন ধরনের বৈশিষ্ট্য অফার করে। সাধারণত অফার করা বৈশিষ্ট্যগুলির মধ্যে রয়েছে: লোড ব্যালেন্সিং, ইমেজ অপ্টিমাইজেশান, ভিডিও স্ট্রিমিং, এজ কম্পিউটিং এবং নিরাপত্তা পণ্য।

কিভাবে একটি CDN সেটআপ এবং কনফিগার করবেন

আদর্শভাবে আপনার সম্পূর্ণ সাইট পরিবেশন করার জন্য একটি CDN ব্যবহার করা উচিত। একটি উচ্চ-স্তরে, এটির জন্য সেটআপ প্রক্রিয়াটি একটি CDN প্রদানকারীর সাথে সাইন আপ করা, তারপর CDN প্রদানকারীর দিকে নির্দেশ করার জন্য আপনার CNAME DNS রেকর্ড আপডেট করা। উদাহরণস্বরূপ, www.example.com এর CNAME রেকর্ড উদাহরণ example.my-cdn.com এর দিকে নির্দেশ করতে পারে। এই DNS পরিবর্তনের ফলে, আপনার সাইটের ট্রাফিক CDN এর মাধ্যমে রুট করা হবে।

যদি সমস্ত সংস্থান পরিবেশন করার জন্য একটি CDN ব্যবহার করা একটি বিকল্প না হয়, আপনি কেবলমাত্র একটি উপসেট সংস্থান পরিবেশন করার জন্য একটি CDN কনফিগার করতে পারেন - উদাহরণস্বরূপ, শুধুমাত্র স্ট্যাটিক সংস্থান৷ আপনি একটি পৃথক CNAME রেকর্ড তৈরি করে এটি করতে পারেন যা শুধুমাত্র সেই সংস্থানগুলির জন্য ব্যবহার করা হবে যা CDN দ্বারা পরিবেশন করা উচিত। উদাহরণস্বরূপ, আপনি একটি static.example.com CNAME রেকর্ড তৈরি করতে পারেন যা example.my-cdn.com এর দিকে নির্দেশ করে। আপনার তৈরি করা static.example.com সাবডোমেনের দিকে নির্দেশ করার জন্য আপনাকে CDN দ্বারা পরিবেশিত সংস্থানগুলির URLগুলি পুনরায় লিখতে হবে৷

যদিও আপনার CDN এই সময়ে সেট আপ করা হবে, আপনার কনফিগারেশনে অদক্ষতা থাকতে পারে। এই নিবন্ধের পরবর্তী দুটি বিভাগ ব্যাখ্যা করবে কিভাবে ক্যাশে হিট অনুপাত বৃদ্ধি করে এবং কর্মক্ষমতা বৈশিষ্ট্যগুলি সক্ষম করে আপনার CDN থেকে সর্বাধিক সুবিধা পেতে হয়।

ক্যাশে হিট অনুপাত উন্নত করা

একটি কার্যকর CDN সেটআপ ক্যাশে থেকে যতটা সম্ভব রিসোর্স পরিবেশন করবে। এটি সাধারণত ক্যাশে হিট রেশিও (CHR) দ্বারা পরিমাপ করা হয়। ক্যাশে হিট অনুপাত একটি নির্দিষ্ট সময়ের ব্যবধানে মোট অনুরোধের সংখ্যা দ্বারা ভাগ করা ক্যাশে হিটের সংখ্যা হিসাবে সংজ্ঞায়িত করা হয়।

একটি নতুন করে শুরু করা ক্যাশে 0 এর CHR থাকবে কিন্তু ক্যাশে সম্পদের সাথে জনবহুল হওয়ায় এটি বৃদ্ধি পায়। বেশিরভাগ সাইটের জন্য 90% এর CHR একটি ভাল লক্ষ্য। আপনার CDN প্রদানকারী আপনাকে আপনার CHR সম্পর্কিত বিশ্লেষণ এবং প্রতিবেদন সরবরাহ করবে।

CHR অপ্টিমাইজ করার সময়, প্রথম জিনিসটি যাচাই করতে হবে যে সমস্ত ক্যাশেযোগ্য সংস্থানগুলি সঠিক সময়ের জন্য ক্যাশে এবং ক্যাশে করা হচ্ছে। এটি একটি সাধারণ মূল্যায়ন যা সমস্ত সাইটের দ্বারা করা উচিত৷

CHR অপ্টিমাইজেশানের পরবর্তী স্তর, বিস্তৃতভাবে বলতে গেলে, যৌক্তিকভাবে সমতুল্য সার্ভার প্রতিক্রিয়াগুলি আলাদাভাবে ক্যাশে করা হচ্ছে না তা নিশ্চিত করতে আপনার CDN সেটিংসকে সূক্ষ্ম সুর করা। এটি একটি সাধারণ অদক্ষতা যা ক্যাশিং-এ প্রশ্ন প্যারাম, কুকি এবং অনুরোধ শিরোনামের মতো কারণগুলির প্রভাবের কারণে ঘটে।

প্রাথমিক নিরীক্ষা

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

ন্যূনতম, এই শিরোনামগুলির মধ্যে একটিকে সাধারণত একটি CDN দ্বারা ক্যাশে করার জন্য একটি সংস্থান সেট করতে হবে:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

উপরন্তু, যদিও এটি একটি CDN দ্বারা একটি সংস্থান ক্যাশ করা হয়েছে কিনা বা কীভাবে তা প্রভাবিত করে না, এটি Cache-Control: immutable নির্দেশিকা সেট করাও ভাল অনুশীলন। Cache-Control: immutable নির্দেশ করে যে একটি সংস্থান "তার সতেজতা জীবনকালে আপডেট করা হবে না"। ফলস্বরূপ, ব্রাউজার ক্যাশে থেকে এটি পরিবেশন করার সময় ব্রাউজার সংস্থানটিকে পুনরায় যাচাই করবে না, যার ফলে একটি অপ্রয়োজনীয় সার্ভার অনুরোধ মুছে যাবে। দুর্ভাগ্যবশত, এই নির্দেশটি শুধুমাত্র Firefox এবং Safari দ্বারা সমর্থিত - এটি Chromium-ভিত্তিক ব্রাউজার দ্বারা সমর্থিত নয়৷ এই সমস্যাটি Cache-Control: immutable । এই সমস্যাটি তারকাচিহ্নিত করা এই বৈশিষ্ট্যটির জন্য সমর্থনকে উত্সাহিত করতে সহায়তা করতে পারে৷

HTTP ক্যাশিংয়ের আরও বিশদ ব্যাখ্যার জন্য, HTTP ক্যাশে সহ অপ্রয়োজনীয় নেটওয়ার্ক অনুরোধগুলি প্রতিরোধ করুন দেখুন।

ফাইন টিউনিং

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

প্রশ্ন প্যারাম

ডিফল্টরূপে, CDN একটি রিসোর্স ক্যাশ করার সময় কোয়েরি প্যারামগুলি বিবেচনা করে। যাইহোক, ক্যোয়ারী প্যারাম হ্যান্ডলিং এর ছোট সমন্বয় CHR এর উপর উল্লেখযোগ্য প্রভাব ফেলতে পারে। উদাহরণ স্বরূপ:

• অপ্রয়োজনীয় ক্যোয়ারী প্যারামস

  ডিফল্টরূপে, একটি CDN example.com/blog এবং example.com/blog?referral_id=2zjk আলাদাভাবে ক্যাশে করবে যদিও তারা সম্ভবত একই অন্তর্নিহিত সম্পদ। referral\_id ক্যোয়ারী প্যারাম উপেক্ষা করার জন্য একটি CDN এর কনফিগারেশন সামঞ্জস্য করে এটি ঠিক করা হয়েছে।

• জিজ্ঞাসা পরম আদেশ

  একটি CDN example.com/blog?id=123&query=dogs example.com/blog?query=dogs&id=123 থেকে আলাদাভাবে ক্যাশে করবে। বেশিরভাগ সাইটের জন্য, ক্যোয়ারী প্যারাম অর্ডার কোন ব্যাপার না, তাই কোয়েরি প্যারামগুলি সাজানোর জন্য CDN কনফিগার করা (যার ফলে সার্ভারের প্রতিক্রিয়া ক্যাশে ব্যবহৃত URL স্বাভাবিক করা) CHR বৃদ্ধি করবে।

পরিবর্তন

ভ্যারি রেসপন্স হেডার ক্যাশে জানায় যে একটি নির্দিষ্ট URL-এর সাথে সম্পর্কিত সার্ভারের প্রতিক্রিয়া অনুরোধে সেট করা হেডারের উপর নির্ভর করে পরিবর্তিত হতে পারে (উদাহরণস্বরূপ, Accept-Language বা Accept-Encoding অনুরোধ শিরোনাম)। ফলস্বরূপ, এটি একটি CDN কে এই প্রতিক্রিয়াগুলিকে আলাদাভাবে ক্যাশে করার নির্দেশ দেয়৷ ভ্যারি হেডারটি CDN দ্বারা ব্যাপকভাবে সমর্থিত নয় এবং এর ফলে ক্যাশে থেকে অন্যথায় ক্যাশেযোগ্য রিসোর্স পরিবেশিত না হতে পারে।

যদিও ভ্যারি হেডার একটি দরকারী টুল হতে পারে, অনুপযুক্ত ব্যবহার CHR-কে আঘাত করে। উপরন্তু, আপনি যদি Vary ব্যবহার করেন, অনুরোধ শিরোনামকে স্বাভাবিক করা CHR উন্নত করতে সাহায্য করবে। উদাহরণস্বরূপ, স্বাভাবিককরণ ছাড়াই অনুরোধ শিরোনাম Accept-Language: en-US এবং Accept-Language: en-US,en;q=0.9 এর ফলে দুটি পৃথক ক্যাশে এন্ট্রি হবে, যদিও তাদের বিষয়বস্তু একই রকম হবে।

কুকিজ

Cookie হেডারের মাধ্যমে অনুরোধে কুকি সেট করা হয়; সেগুলি Set-Cookie হেডারের মাধ্যমে প্রতিক্রিয়াগুলিতে সেট করা হয়। Set-Cookie হেডারের অপ্রয়োজনীয় ব্যবহার এড়ানো উচিত কারণ ক্যাশে সাধারণত এই শিরোনাম ধারণকারী সার্ভার প্রতিক্রিয়া ক্যাশে করবে না।

কর্মক্ষমতা বৈশিষ্ট্য

এই বিভাগে পারফরম্যান্স বৈশিষ্ট্যগুলি নিয়ে আলোচনা করা হয়েছে যা সাধারণত CDN দ্বারা তাদের মূল পণ্য অফার করার অংশ হিসাবে অফার করা হয়। অনেক সাইট এই বৈশিষ্ট্যগুলি সক্ষম করতে ভুলে যায়, যার ফলে সহজ পারফরম্যান্স জিতে হারিয়ে যায়।

সঙ্কোচন

সমস্ত টেক্সট-ভিত্তিক প্রতিক্রিয়া gzip বা Brotli দিয়ে সংকুচিত করা উচিত। আপনার যদি পছন্দ থাকে তবে জিজিপের উপরে ব্রটলি বেছে নিন। ব্রটলি একটি নতুন কম্প্রেশন অ্যালগরিদম, এবং জিজিপের তুলনায় এটি উচ্চ কম্প্রেশন অনুপাত অর্জন করতে পারে।

ব্রটলি কম্প্রেশনের জন্য দুই ধরনের CDN সাপোর্ট আছে: "Brotli from origin" এবং "স্বয়ংক্রিয় Brotli কম্প্রেশন"।

আদি থেকে ব্রটলি

উৎপত্তি থেকে Brotli যখন একটি CDN উৎস দ্বারা Brotli-সংকুচিত ছিল সম্পদ পরিবেশন করে। যদিও এটি এমন একটি বৈশিষ্ট্যের মতো মনে হতে পারে যা সমস্ত CDN-কে বাক্সের বাইরে সমর্থন করতে সক্ষম হওয়া উচিত, তবে এটির জন্য প্রয়োজন যে একটি CDN এর সাথে সংশ্লিষ্ট সংস্থানের একাধিক সংস্করণ (অন্য কথায়, জিজিপ-সংকুচিত এবং ব্রটলি-সংকুচিত সংস্করণ) ক্যাশে করতে সক্ষম হবে। একটি প্রদত্ত URL।

স্বয়ংক্রিয় ব্রটলি কম্প্রেশন

স্বয়ংক্রিয় ব্রটলি কম্প্রেশন হল যখন রিসোর্সগুলিকে CDN দ্বারা সংকুচিত করা হয়। CDN ক্যাশেযোগ্য এবং নন-ক্যাশেযোগ্য উভয় সংস্থান সংকুচিত করতে পারে।

প্রথমবার যখন কোনও সংস্থান অনুরোধ করা হয় তখন এটি "যথেষ্ট ভাল" কম্প্রেশন ব্যবহার করে পরিবেশন করা হয় - উদাহরণস্বরূপ, Brotli-5। এই ধরনের কম্প্রেশন ক্যাশেযোগ্য এবং নন-ক্যাশেযোগ্য সম্পদ উভয় ক্ষেত্রেই প্রযোজ্য।

এদিকে, যদি কোনো রিসোর্স ক্যাশেযোগ্য হয়, CDN অফলাইন প্রসেসিং ব্যবহার করে রিসোর্সটিকে আরও শক্তিশালী কিন্তু অনেক ধীর কম্প্রেশন লেভেলে কম্প্রেস করবে - উদাহরণস্বরূপ, Brotli-11। একবার এই সংকোচনটি সম্পূর্ণ হলে, আরও সংকুচিত সংস্করণটি ক্যাশে করা হবে এবং পরবর্তী অনুরোধগুলির জন্য ব্যবহার করা হবে।

কম্প্রেশন সেরা অভ্যাস

যে সাইটগুলি পারফরম্যান্সকে সর্বোচ্চ করতে চায় তাদের মূল সার্ভার এবং CDN উভয়েই ব্রটলি কম্প্রেশন প্রয়োগ করা উচিত। উৎপত্তিস্থলে ব্রোটলি কম্প্রেশন সম্পদের স্থানান্তর আকারকে কমিয়ে দেয় যা ক্যাশে থেকে পরিবেশন করা যায় না। অনুরোধ পরিবেশন বিলম্ব রোধ করতে, মূল একটি মোটামুটি রক্ষণশীল কম্প্রেশন স্তর ব্যবহার করে গতিশীল সম্পদ সংকুচিত করা উচিত - উদাহরণস্বরূপ, Brotli-4; ব্রটলি-11 ব্যবহার করে স্ট্যাটিক সংস্থানগুলি সংকুচিত করা যেতে পারে। যদি একটি উৎপত্তি ব্রটলিকে সমর্থন না করে, তাহলে gzip-6 ব্যবহার করা যেতে পারে গতিশীল সম্পদ সংকুচিত করতে; gzip-9 স্ট্যাটিক রিসোর্স সংকুচিত করতে ব্যবহার করা যেতে পারে।

TLS 1.3

TLS 1.3 হল ট্রান্সপোর্ট লেয়ার সিকিউরিটি (TLS) এর নতুন সংস্করণ, HTTPS দ্বারা ব্যবহৃত ক্রিপ্টোগ্রাফিক প্রোটোকল। TLS 1.3 TLS 1.2 এর তুলনায় আরও ভাল গোপনীয়তা এবং কর্মক্ষমতা প্রদান করে।

TLS 1.3 TLS হ্যান্ডশেককে দুটি রাউন্ডট্রিপ থেকে একটিতে ছোট করে। HTTP/1 বা HTTP/2 ব্যবহার করে সংযোগের জন্য, TLS হ্যান্ডশেককে একটি রাউন্ডট্রিপে সংক্ষিপ্ত করা কার্যকরভাবে সংযোগ সেটআপের সময় 33% কমিয়ে দেয়।

HTTP/2 এবং HTTP/3

HTTP/2 এবং HTTP/3 উভয়ই HTTP/1 এর উপর কর্মক্ষমতা সুবিধা প্রদান করে। দুটির মধ্যে, HTTP/3 বৃহত্তর সম্ভাব্য কর্মক্ষমতা সুবিধা প্রদান করে। HTTP/3 এখনও সম্পূর্ণরূপে প্রমিত নয়, তবে এটি ঘটলে এটি ব্যাপকভাবে সমর্থিত হবে।

HTTP/2

যদি আপনার CDN ইতিমধ্যেই ডিফল্টরূপে HTTP/2 সক্ষম না করে থাকে, তাহলে আপনার এটি চালু করার কথা বিবেচনা করা উচিত। HTTP/2 HTTP/1 এর উপর একাধিক কর্মক্ষমতা সুবিধা প্রদান করে এবং সমস্ত প্রধান ব্রাউজার দ্বারা সমর্থিত । HTTP/2 এর পারফরম্যান্স বৈশিষ্ট্যগুলির মধ্যে রয়েছে: মাল্টিপ্লেক্সিং , স্ট্রিম অগ্রাধিকার , এবং হেডার কম্প্রেশন ।

• মাল্টিপ্লেক্সিং

  মাল্টিপ্লেক্সিং তর্কাতীতভাবে HTTP/2 এর সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্য। মাল্টিপ্লেক্সিং একই সময়ে একাধিক অনুরোধ-প্রতিক্রিয়া জোড়া পরিবেশন করতে একটি একক TCP সংযোগ সক্ষম করে। এটি অপ্রয়োজনীয় সংযোগ সেটআপের ওভারহেড দূর করে; প্রদত্ত যে একটি নির্দিষ্ট সময়ে একটি ব্রাউজার খুলতে পারে এমন সংযোগের সংখ্যা সীমিত, এটির এই অর্থও রয়েছে যে ব্রাউজার এখন সমান্তরালভাবে একটি পৃষ্ঠার সংস্থানগুলির আরও বেশি অনুরোধ করতে সক্ষম। মাল্টিপ্লেক্সিং তাত্ত্বিকভাবে HTTP/1 অপ্টিমাইজেশনের প্রয়োজনীয়তাকে সরিয়ে দেয় যেমন কনক্যাটেনেশন এবং স্প্রাইট শীট - তবে, বাস্তবে, এই কৌশলগুলি প্রাসঙ্গিক থাকবে কারণ বড় ফাইলগুলি আরও ভালভাবে সংকুচিত হয়।

• স্ট্রীম অগ্রাধিকার

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

স্ট্রীম অগ্রাধিকার একটি নির্ভরতা গাছের মাধ্যমে ব্রাউজার দ্বারা প্রকাশ করা হয় এবং এটি শুধুমাত্র পছন্দের একটি বিবৃতি : অন্য কথায়, সার্ভার ব্রাউজার দ্বারা সরবরাহ করা অগ্রাধিকারগুলি পূরণ করতে (বা এমনকি বিবেচনা করতে) বাধ্য নয়৷ স্ট্রিম অগ্রাধিকার আরো কার্যকর হয় যখন একটি সাইট একটি CDN এর মাধ্যমে পরিবেশিত হয়।

HTTP/2 সংস্থান অগ্রাধিকারের CDN বাস্তবায়ন ব্যাপকভাবে পরিবর্তিত হয়। আপনার CDN সম্পূর্ণরূপে এবং সঠিকভাবে HTTP/2 সংস্থান অগ্রাধিকার সমর্থন করে কিনা তা সনাক্ত করতে, দেখুন HTTP/2 এখনও দ্রুত? .

যদিও আপনার CDN ইন্সট্যান্সকে HTTP/2 তে স্যুইচ করা মূলত একটি সুইচ ফ্লিপ করার বিষয়, এটি উৎপাদনে সক্রিয় করার আগে এই পরিবর্তনটি পুঙ্খানুপুঙ্খভাবে পরীক্ষা করা গুরুত্বপূর্ণ। HTTP/1 এবং HTTP/2 অনুরোধ এবং প্রতিক্রিয়া শিরোনামের জন্য একই কনভেনশন ব্যবহার করে - কিন্তু এই কনভেনশনগুলি মেনে চলা না হলে HTTP/2 অনেক কম ক্ষমাশীল। ফলস্বরূপ, নন-স্পেক প্র্যাকটিস যেমন হেডারে নন-ASCII বা বড় হাতের অক্ষরগুলি অন্তর্ভুক্ত করা হলে HTTP/2 সক্ষম হয়ে গেলে ত্রুটির কারণ হতে পারে। এটি ঘটলে, সংস্থান ডাউনলোড করার জন্য একটি ব্রাউজারের প্রচেষ্টা ব্যর্থ হবে৷ ডাউনলোডের ব্যর্থ প্রচেষ্টা DevTools-এর "নেটওয়ার্ক" ট্যাবে দৃশ্যমান হবে৷ উপরন্তু, ত্রুটি বার্তা "ERR_HTTP2_PROTOCOL_ERROR" কনসোলে প্রদর্শিত হবে।

HTTP/3

HTTP/3 হল HTTP/2 এর উত্তরসূরী। 2020 সালের সেপ্টেম্বর পর্যন্ত, সমস্ত প্রধান ব্রাউজারে HTTP/3 এর জন্য পরীক্ষামূলক সমর্থন রয়েছে এবং কিছু CDN এটি সমর্থন করে। পারফরম্যান্স হল HTTP/2 এর তুলনায় HTTP/3 এর প্রাথমিক সুবিধা। বিশেষত, HTTP/3 সংযোগ স্তরে হেড-অফ-লাইন ব্লকিং দূর করে এবং সংযোগ সেটআপের সময় হ্রাস করে।

• হেড-অফ-লাইন ব্লকিং দূর করা

  HTTP/2 মাল্টিপ্লেক্সিং চালু করেছে, এমন একটি বৈশিষ্ট্য যা একক সংযোগকে একসাথে একাধিক স্ট্রিম ডেটা প্রেরণ করতে ব্যবহার করার অনুমতি দেয়। যাইহোক, HTTP/2 এর সাথে, একটি একক ড্রপ প্যাকেট একটি সংযোগের সমস্ত স্ট্রীমকে ব্লক করে (একটি ঘটনা যা হেড-অফ-লাইন ব্লকিং নামে পরিচিত)। HTTP/3 এর সাথে, একটি ড্রপ করা প্যাকেট শুধুমাত্র একটি একক স্ট্রীমকে ব্লক করে। এই উন্নতিটি মূলত TCP এর পরিবর্তে HTTP/3 UDP (HTTP/3 QUIC এর মাধ্যমে UDP ব্যবহার করে) ব্যবহার করার ফলাফল। এটি HTTP/3 কে বিশেষভাবে উপযোগী করে তোলে জনাকীর্ণ বা ক্ষতিকারক নেটওয়ার্কে ডেটা স্থানান্তরের জন্য।

• কানেকশন সেটআপের সময় কমে গেছে

  HTTP/3 টিএলএস 1.3 ব্যবহার করে এবং তাই এর কার্যকারিতা সুবিধাগুলি ভাগ করে: একটি নতুন সংযোগ স্থাপনের জন্য শুধুমাত্র একটি একক রাউন্ড-ট্রিপ প্রয়োজন এবং একটি বিদ্যমান সংযোগ পুনরায় চালু করার জন্য কোনো রাউন্ডট্রিপের প্রয়োজন নেই৷

HTTP/3 দুর্বল নেটওয়ার্ক সংযোগে ব্যবহারকারীদের উপর সবচেয়ে বেশি প্রভাব ফেলবে: শুধুমাত্র HTTP/3 এর পূর্বসূরীদের তুলনায় প্যাকেট ক্ষয়কে ভালোভাবে পরিচালনা করে না, বরং 0-RTT বা 1-RTT সংযোগ সেটআপের ফলে পরম সময় সাশ্রয় হবে বলেও উচ্চ লেটেন্সি সহ নেটওয়ার্কগুলিতে আরও বেশি।

ইমেজ অপ্টিমাইজেশান

CDN ইমেজ অপ্টিমাইজেশান পরিষেবাগুলি সাধারণত ইমেজ অপটিমাইজেশনের উপর ফোকাস করে যা ইমেজ ট্রান্সফার সাইজ কমাতে স্বয়ংক্রিয়ভাবে প্রয়োগ করা যেতে পারে। উদাহরণস্বরূপ: EXIF ​​ডেটা ছিনতাই করা, ক্ষতিহীন কম্প্রেশন প্রয়োগ করা এবং ছবিগুলিকে নতুন ফাইল ফর্ম্যাটে রূপান্তর করা (উদাহরণস্বরূপ, WebP)। মিডিয়ান ওয়েব পৃষ্ঠায় চিত্রগুলি স্থানান্তর বাইটের ~50% তৈরি করে, তাই ছবিগুলি অপ্টিমাইজ করা পৃষ্ঠার আকার উল্লেখযোগ্যভাবে হ্রাস করতে পারে৷

মিনিফিকেশন

Minification JavaScript, CSS, এবং HTML থেকে অপ্রয়োজনীয় অক্ষরগুলি সরিয়ে দেয়। CDN এর পরিবর্তে অরিজিন সার্ভারে মিনিফেশন করা ভালো। সাইটের মালিকদের সংক্ষিপ্তকরণের কোড সম্পর্কে আরও প্রসঙ্গ রয়েছে এবং তাই তারা প্রায়শই CDN-এর দ্বারা নিয়োজিতদের চেয়ে বেশি আক্রমনাত্মক ক্ষুদ্রকরণ কৌশল ব্যবহার করতে পারে। যাইহোক, যদি উৎপত্তিস্থলে কোড ছোট করা একটি বিকল্প না হয়, তাহলে CDN দ্বারা সংক্ষিপ্তকরণ একটি ভাল বিকল্প।

উপসংহার

• একটি CDN ব্যবহার করুন: CDNগুলি দ্রুত সম্পদ সরবরাহ করে, অরিজিন সার্ভারে লোড কমায় এবং ট্রাফিক স্পাইক মোকাবেলায় সহায়ক।
• যতটা সম্ভব আক্রমনাত্মকভাবে ক্যাশে বিষয়বস্তু: স্ট্যাটিক এবং ডাইনামিক কন্টেন্ট উভয়ই ক্যাশে করা যেতে পারে এবং হওয়া উচিত - যদিও বিভিন্ন সময়কালের জন্য। আপনি সর্বোত্তমভাবে বিষয়বস্তু ক্যাশে করছেন তা নিশ্চিত করতে পর্যায়ক্রমে আপনার সাইট অডিট করুন।
• CDN পারফরম্যান্স বৈশিষ্ট্যগুলি সক্ষম করে: Brotli, TLS 1.3, HTTP/2, এবং HTTP/3 এর মতো বৈশিষ্ট্যগুলি কার্যক্ষমতাকে আরও উন্নত করে৷