CDN: জিরো টু মাস্টারি · বিগিনার · ১৮ মিনিট · 02 / 16

একটা রিকোয়েস্টের পুরো যাত্রা

ব্রাউজারে URL টাইপ করা থেকে বাইট ফেরত পাওয়া পর্যন্ত: DNS কীভাবে কাছের PoP বেছে দেয়, এজে TLS কেন শেষ হয়, ক্যাশ লুকআপের চারটা ফল, shield হয়ে origin পর্যন্ত যাওয়া, আর curl দিয়ে প্রতিটা ধাপ মাপা।

cdnrequest flowanycasttls terminationcache hitcache missorigin shieldcurl timing

গল্পে বুঝি

মিরপুরের এক মহল্লায় একটা ছোট পাঠাগার আছে, দেখাশোনা করেন মরিয়ম। শহরের সব পাঠাগার একটা নেটওয়ার্কের অংশ, আর নেটওয়ার্কের কেন্দ্রীয় গ্রন্থাগার শাহবাগে, যেখানে প্রতিটা বইয়ের মূল কপি থাকে। খোয়ারিজমি একদিন মহল্লার পাঠাগারে এসে বললেন, “বিরুনির ‘কিতাব আল-হিন্দ’ আছে?” মরিয়ম প্রথমে তাকে খুঁজলেন। নেই। তিনি সরাসরি শাহবাগে ফোন করলেন না; আগে ফোন দিলেন মিরপুর জোনের বড় শাখায়, যারা পুরো জোনের ছোট পাঠাগারগুলোর হয়ে কেন্দ্রের সাথে যোগাযোগ রাখে। জোনের শাখাতেও নেই, তাই ওরাই শাহবাগ থেকে একটা কপি আনাল, নিজেদের তাকেও একটা রেখে দিল, আর একটা পাঠিয়ে দিল মরিয়মের কাছে। খোয়ারিজমি দুই দিন পর বই পেলেন।

পরের সপ্তাহে কিন্দি এসে একই বই চাইলেন। এবার মরিয়মের তাকেই বই আছে, পাঁচ মিনিটে হাতে। তাকের প্রতিটা বইয়ের ভেতরে মরিয়ম একটা স্লিপ লাগিয়ে রাখেন: “এই সংস্করণ ৩০ দিন পর্যন্ত চলবে।” মাস পেরোলে বইটা তাকে থাকে ঠিকই, কিন্তু কেউ চাইলে মরিয়ম জোনে ফোন করে জিজ্ঞেস করেন, “নতুন সংস্করণ এসেছে?” না এলে স্লিপের তারিখ বাড়িয়ে দেন; এলে পুরনোটা সরিয়ে নতুনটা আনান। আর ভিড়ের দিনে, জোনের লাইন ব্যস্ত থাকলে, মরিয়ম পুরনো সংস্করণটাই দিয়ে দেন, সাথে বলেন, “নতুনটা আনতে বলেছি।”

আরেকটা জিনিস আছে। পাঠাগারে ঢোকার মুখে রেজিস্টারে নাম লিখে সই করতে হয়, পরিচয় যাচাই হয় ওখানেই। মরিয়ম সই দেখেন; শাহবাগের লোকেরা খোয়ারিজমিকে কখনো দেখেই না, তারা শুধু চেনে জোনের শাখাকে। আর একই মহল্লায় যদি বিশজন একসাথে একই নতুন বই চায়, মরিয়ম বিশবার ফোন করেন না: একবার চান, এলে সবাইকে দেন।

মিলিয়ে নিই: খোয়ারিজমির কাছের পাঠাগারে যাওয়া হলো DNS আর anycast দিয়ে কাছের এজ PoP-এ পৌঁছানো। রেজিস্টারে সই আর পরিচয় যাচাই হলো এজে TLS টার্মিনেশন। মরিয়মের তাক হলো এজ ক্যাশ; তাকে না পাওয়া MISS, পাওয়া HIT। জোনের বড় শাখা হলো origin shield বা tiered cache, আর শাহবাগ হলো origin। বইয়ের স্লিপ হলো TTL; মেয়াদ শেষে “নতুন সংস্করণ এসেছে?” জিজ্ঞেস করা হলো revalidation, আর মেয়াদ পেরোনো বই দিয়ে দেওয়া হলো STALE সার্ভ করা। বিশজনের জন্য একবার চাওয়া হলো request collapsing। বাস্তবে আপনার সাইটের প্রতিটা রিকোয়েস্ট ঠিক এই পথেই চলে, আর এই চ্যাপ্টার প্রতিটা ধাপ খুলে দেখায়।

পুরো ছবি এক নজরে

A request through a CDN, first miss then hit

এবার প্রতিটা ধাপ আলাদা করে।

ধাপ ১: DNS কাছের PoP বেছে দেয়

ইউজার কোন PoP-এ যাবে, সেই সিদ্ধান্ত হয় প্রথম প্যাকেট পাঠানোর আগেই, DNS-এ। CDN দুইভাবে এটা করে, আর অনেক CDN দুটো মিলিয়ে ব্যবহার করে।

CNAME দিয়ে CDN-এর হাতে তুলে দেওয়া

সবচেয়ে প্রচলিত সেটআপে আপনার রেকর্ড CDN-এর একটা হোস্টনেমের দিকে CNAME করা থাকে:

$ dig +noall +answer www.baytalhikma.org
www.baytalhikma.org.        300   IN  CNAME  baytalhikma.cdn-provider.example.
baytalhikma.cdn-provider.example. 20 IN A    203.0.113.40
baytalhikma.cdn-provider.example. 20 IN A    203.0.113.41

(আউটপুট উদাহরণ হিসেবে দেওয়া।) প্রথম লাইনটা আপনার zone থেকে আসে। দ্বিতীয় অংশটা CDN-এর নিজস্ব DNS সার্ভার থেকে, আর লক্ষ করুন TTL মাত্র ২০ সেকেন্ড। CDN-এর DNS প্রতিটা প্রশ্ন দেখে ঠিক করে কোন PoP-এর IP দেবে: যে resolver প্রশ্ন করছে তার লোকেশন, PoP-গুলোর লোড, কোনটা সুস্থ। TTL ছোট রাখে যাতে পরিস্থিতি বদলালে দ্রুত অন্য PoP-এ পাঠাতে পারে। এই কৌশলের বিস্তারিত (GeoDNS, EDNS Client Subnet, resolver-এর লোকেশন বনাম ইউজারের লোকেশন) আছে DNS ট্র্যাকের চ্যাপ্টার ১০-এ।

Anycast: একই IP, অনেক জায়গায়

আরেকটা পদ্ধতিতে CDN একটা IP অ্যাড্রেস পৃথিবীর সব PoP থেকে একসাথে ঘোষণা করে (BGP দিয়ে)। ঢাকার ইউজার আর লন্ডনের ইউজার একই IP-তে প্যাকেট পাঠায়, কিন্তু ইন্টারনেটের রাউটিং প্রতিটা প্যাকেটকে “সবচেয়ে কাছের” ঘোষণাকারীর কাছে নিয়ে যায়। এখানে “কাছের” মানে নেটওয়ার্ক পথের হিসাবে কাছের, ম্যাপে সবসময় কাছের নয়।

$ dig +short baytalhikma.org
198.51.100.7
# Same answer from Dhaka, Cairo and Cordoba.
# Which building answers depends on BGP routing, not on DNS.

Anycast-এর সুবিধা: DNS resolver-এর লোকেশন নিয়ে কোনো অনুমান লাগে না, আর একটা PoP ডাউন হলে রাউটিং নিজেই পরের কাছেরটায় সরে যায়। দুর্বলতা: রাউটিং কখনো কখনো অদ্ভুত পথ বাছে, যেমন ঢাকার কোনো ISP-এর ট্রাফিক কাছের PoP ছেড়ে দূরের একটায় চলে যাওয়া, কারণ ওই ISP-এর আপস্ট্রিম চুক্তি সেরকম। চ্যাপ্টার ১৪-তে এটা কীভাবে ধরবেন দেখাব।

আপনি কোন PoP-এ পৌঁছেছেন?

বেশিরভাগ CDN রেসপন্স হেডারে বা একটা ডায়াগনস্টিক URL-এ PoP-এর নাম জানায়, প্রায়ই কাছের এয়ারপোর্টের তিন অক্ষরের কোড দিয়ে (DAC = ঢাকা, SIN = সিঙ্গাপুর, FRA = ফ্রাঙ্কফুর্ট)। হেডারের নাম প্রোভাইডার অনুযায়ী আলাদা:

$ curl -sI https://www.baytalhikma.org/ | grep -iE 'x-served-by|cf-ray|x-amz-cf-pop|via|server'
server: cdn-provider
via: 1.1 edge-sin3
x-served-by: cache-sin-12345-SIN

(উদাহরণ।) ঢাকা থেকে রিকোয়েস্ট করে যদি সিঙ্গাপুরের PoP দেখেন, সেটা ভুল নাও হতে পারে: হয়তো আপনার প্রোভাইডারের ঢাকায় PoP নেই, বা আপনার ISP-এর পথ ওদিকেই যায়।

ধাপ ২: কানেকশন আর এজে TLS

ব্রাউজার এখন এজের IP-তে TCP কানেকশন খোলে, তারপর TLS হ্যান্ডশেক করে। দুটোই হয় ইউজার আর এজের মধ্যে, ছোট RTT-তে। এর মানে:

এজের কাছে আপনার ডোমেইনের TLS সার্টিফিকেট থাকতে হয় (CDN সাধারণত নিজেই ইস্যু করে দেয়, বা আপনি আপলোড করেন; চ্যাপ্টার ৮)।
এজ রিকোয়েস্টটা ডিক্রিপ্ট করে পড়ে: URL, হেডার, কুকি সব দেখে। না পড়লে ক্যাশ করবে কীভাবে? তাই CDN আপনার ট্রাফিকের একটা বিশ্বস্ত মধ্যস্থতাকারী।
এজ থেকে origin পর্যন্ত আলাদা একটা কানেকশন থাকে, যেটা নিজেও HTTPS হওয়া উচিত। “ইউজার থেকে এজ HTTPS, এজ থেকে origin HTTP” সেটআপ ব্রাউজারে সবুজ তালা দেখায়, কিন্তু পথের অর্ধেক খোলা। চ্যাপ্টার ৮-এ এর ফাঁদ (রিডাইরেক্ট লুপ সহ) দেখাব।

এজ থেকে origin-এর কানেকশনগুলো CDN সাধারণত খোলা রেখে বারবার ব্যবহার করে (connection reuse)। তাই miss হলেও origin পর্যন্ত বাকি পথে নতুন TCP আর TLS হ্যান্ডশেকের খরচ প্রায়ই লাগে না। এজন্যই ক্যাশ না হওয়া রিকোয়েস্টও CDN দিয়ে গেলে প্রায়ই একটু দ্রুত হয়।

ধাপ ৩: ক্যাশ লুকআপ

রিকোয়েস্ট পড়ার পর এজ প্রথমে একটা ক্যাশ কী বানায়: সাধারণত হোস্ট + পাথ + query string, সাথে কনফিগার করা হলে কিছু হেডার (চ্যাপ্টার ৪ পুরোটাই এ নিয়ে)। তারপর ওই কী দিয়ে নিজের স্টোরেজে খোঁজে। ফল চার রকম হতে পারে:

ফল	মানে	এরপর কী হয়
HIT	কপি আছে, এখনো টাটকা (TTL শেষ হয়নি)	সরাসরি ইউজারকে দেয়; origin কিছুই জানে না
MISS	কপি নেই	পরের লেয়ার বা origin থেকে আনে
EXPIRED	কপি আছে কিন্তু TTL শেষ	origin-কে জিজ্ঞেস করে বদলেছে কিনা (revalidation)
STALE	কপির TTL শেষ, কিন্তু নিয়ম অনুযায়ী পুরনোটাই দেওয়া হলো (origin ধীর/ডাউন, বা ব্যাকগ্রাউন্ডে আপডেট চলছে)	ইউজার পুরনো কপি পায়, এজ পেছনে নতুনটা আনে

অনেক CDN এর বাইরেও স্টেটাস দেখায়: BYPASS (নিয়ম অনুযায়ী ক্যাশ দেখাই হয়নি, যেমন লগইন কুকি থাকলে), DYNAMIC বা PASS (রেসপন্স ক্যাশেবল নয়), REVALIDATED (EXPIRED কপি origin যাচাই করে বলেছে বদলায়নি)। ঠিক কোন শব্দ, তা প্রোভাইডার অনুযায়ী আলাদা; চ্যাপ্টার ৫-এ বিস্তারিত।

Revalidation: পুরোটা না এনে “বদলেছে?” জিজ্ঞেস করা

EXPIRED কপির জন্য এজ পুরো ফাইল আবার না চেয়ে একটা conditional request পাঠায়, আগের রেসপন্সের ETag বা Last-Modified দিয়ে:

GET /img/astrolabe.webp HTTP/1.1
Host: baytalhikma.org
If-None-Match: "a1b2c3"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3"
Cache-Control: max-age=86400

304-এ কোনো বডি নেই, শুধু হেডার। ২ MB ছবির বদলে কয়েকশো বাইট। এজ নিজের কপির মেয়াদ বাড়িয়ে আবার সার্ভ করতে থাকে। চ্যাপ্টার ৩-এ এটা আরও খুলে বলব।

ধাপ ৪: Miss হলে কোথায় যায়: tiered cache আর shield

সবচেয়ে সরল CDN-এ প্রতিটা এজ miss হলে সরাসরি origin-এ যায়। সমস্যা: CDN-এর যদি দুইশো PoP থাকে, তাহলে একটা নতুন ফাইলের জন্য origin দুইশোবার রিকোয়েস্ট পেতে পারে, প্রতিটা PoP থেকে একবার করে। বিশ্বজুড়ে কম জনপ্রিয় ফাইলের জন্য প্রতিটা PoP-এ hit ratio-ও কম থাকে।

সমাধান হলো মাঝে একটা লেয়ার: origin shield বা tiered cache। এজ miss হলে আগে যায় একটা নির্দিষ্ট মাঝের PoP-এ (সাধারণত origin-এর কাছের)। সেখানে থাকলে ওখান থেকেই নেয়; না থাকলে শুধু shield-ই origin-এ যায়।

Edge-only vs tiered caching

ফল: origin একটা ফাইলের জন্য মোটামুটি একবারই রিকোয়েস্ট পায়, আর shield-এর বড় ক্যাশে কম জনপ্রিয় ফাইলও টিকে থাকে। খরচ: miss হলে একটা বাড়তি হপ। চ্যাপ্টার ৭-এ shield কোথায় বসাবেন আর কখন এটা ক্ষতি করে, তা দেখাব।

Request collapsing

হঠাৎ একটা ছবি ভাইরাল হলো, একই PoP-এ এক সেকেন্ডে পাঁচশো রিকোয়েস্ট, আর ক্যাশে তখনো নেই। ভালো CDN পাঁচশোটা রিকোয়েস্ট origin-এ পাঠায় না: প্রথমটা পাঠায়, বাকিগুলোকে অপেক্ষায় রাখে, রেসপন্স এলে সবাইকে একসাথে দেয়। এটাই request collapsing (কখনো “request coalescing”)। গল্পে মরিয়মের “একবার চাই, সবাইকে দিই”। এটা না থাকলে প্রতিটা ডিপ্লয় বা purge-এর পর origin-এ একটা ছোট ঢেউ আসে, যাকে cache stampede বলে।

ধাপ ৫: Origin উত্তর দেয়, এজ জমা রাখে

origin রেসপন্স পাঠায়, সাথে হেডার। এজ ওই হেডার পড়ে ঠিক করে:

এটা কি জমা রাখা যাবে? Cache-Control: private বা no-store থাকলে না। অনেক CDN-এ Set-Cookie থাকলেও ডিফল্টে না (চ্যাপ্টার ৩)।
কতক্ষণ? s-maxage, max-age, CDN-এর নিজের নিয়ম, অথবা কিছু না থাকলে প্রোভাইডারের একটা ডিফল্ট।
কোন কী-তে? রিকোয়েস্টের ক্যাশ কী, আর Vary হেডার থাকলে সেই অনুযায়ী আলাদা কপি (চ্যাপ্টার ৪)।

তারপর রেসপন্স ইউজারের দিকে স্ট্রিম করে, একই সাথে নিজের স্টোরেজে লেখে। বড় ফাইলের ক্ষেত্রে এজ পুরোটা পাওয়ার আগেই ইউজারকে পাঠানো শুরু করে।

ধাপ ৬: পরের ইউজার, HIT

এবার একই শহরের আরেকজন একই ফাইল চায়। DNS, TCP, TLS একইভাবে হয়, কিন্তু ক্যাশ লুকআপে HIT। এজ সরাসরি উত্তর দেয়, সাথে একটা Age হেডার, যা বলে কপিটা কত সেকেন্ড আগে origin থেকে এসেছে:

$ curl -sI https://www.baytalhikma.org/img/astrolabe.webp
HTTP/2 200
content-type: image/webp
content-length: 184213
cache-control: public, max-age=86400
etag: "a1b2c3"
age: 42
x-cache: HIT

(উদাহরণ।) age: 42 মানে এই কপি ৪২ সেকেন্ড ধরে ক্যাশে আছে। max-age=86400 থেকে age বাদ দিলে বাকি টাটকা সময়: ৮৬,৩৫৮ সেকেন্ড।

curl দিয়ে প্রতিটা ধাপ মাপা

এখন তত্ত্বটা সংখ্যায় দেখি। curl-এর -w অপশন কানেকশনের প্রতিটা মাইলফলকের সময় দেয়, রিকোয়েস্ট শুরু থেকে জমা হিসেবে (প্রতিটা আগেরটার চেয়ে বড়):

ভেরিয়েবল	কখন পর্যন্ত
`time_namelookup`	DNS শেষ
`time_connect`	TCP হ্যান্ডশেক শেষ
`time_appconnect`	TLS হ্যান্ডশেক শেষ
`time_starttransfer`	প্রথম বাইট এল (TTFB)
`time_total`	পুরো রেসপন্স এল

একটা ফরম্যাট ফাইল বানিয়ে রাখুন, বারবার কাজে লাগবে:

cat > ~/curl-timing.txt <<'EOF'
   dns:  %{time_namelookup}s
   tcp:  %{time_connect}s
   tls:  %{time_appconnect}s
  ttfb:  %{time_starttransfer}s
 total:  %{time_total}s
  code:  %{http_code}
EOF

curl -so /dev/null -w @"$HOME/curl-timing.txt" https://www.baytalhikma.org/img/astrolabe.webp

MISS বনাম HIT, পাশাপাশি

ক্যাশ খালি এমন একটা URL দুইবার পরপর চালান (একটা নতুন query string যোগ করলে প্রায়ই নতুন ক্যাশ কী হয়, তাই প্রথমবার নিশ্চিত MISS):

# First request: MISS (illustrative numbers, Dhaka → edge in Dhaka, origin in Frankfurt)
   dns:  0.012s
   tcp:  0.018s
   tls:  0.041s
  ttfb:  0.389s
 total:  0.412s

# Second request: HIT
   dns:  0.001s
   tcp:  0.007s
   tls:  0.029s
  ttfb:  0.036s
 total:  0.052s

পড়ার নিয়ম হলো পাশাপাশি দুইটা সংখ্যার পার্থক্য দেখা:

tcp − dns ≈ এজ পর্যন্ত একটা RTT। দুইবারেই ছোট (কয়েক ms), মানে এজ সত্যিই কাছে। এটা বড় হলে (১০০ ms-এর বেশি) আপনি দূরের PoP-এ যাচ্ছেন।
tls − tcp ≈ TLS হ্যান্ডশেক। এটাও এজের সাথে, তাই ছোট।
ttfb − tls ≈ রিকোয়েস্ট পাঠানো থেকে প্রথম বাইট। এখানেই HIT আর MISS-এর আসল পার্থক্য: MISS-এ ৩৫০ ms (এজ → origin → এজ), HIT-এ ৭ ms (এজ নিজের ডিস্ক বা মেমরি থেকে)।
প্রথমবার dns বড়, দ্বিতীয়বার প্রায় শূন্য: OS বা resolver ক্যাশ।

ttfb − tls বড় কিন্তু রেসপন্স হেডারে HIT? তাহলে এজ ধীর (বিরল), অথবা আসলে আপনার শেলের curl কোনো proxy দিয়ে যাচ্ছে। আর যদি MISS-ও ছোট হয়, তাহলে সম্ভবত shield-এ HIT হয়েছে: এজে নেই, কিন্তু মাঝের লেয়ারে আছে। কিছু CDN হেডারে দুই লেয়ারের ফলই দেখায় (যেমন x-cache: MISS, HIT)।

একটা নির্দিষ্ট IP বা PoP-কে জোর করে জিজ্ঞেস করা

DNS এড়িয়ে সরাসরি একটা নির্দিষ্ট এজ IP বা origin-এ রিকোয়েস্ট পাঠাতে --resolve ব্যবহার করুন। SNI আর Host হেডার ঠিক থাকে, শুধু কোন IP-তে যাবে সেটা বদলায়:

# Ask the origin directly, bypassing the CDN (origin IP from your hosting panel)
curl -sI --resolve www.baytalhikma.org:443:192.0.2.10 https://www.baytalhikma.org/

# Ask one specific edge IP
curl -sI --resolve www.baytalhikma.org:443:203.0.113.41 https://www.baytalhikma.org/

এজ আর origin-এর রেসপন্স পাশাপাশি রাখলে “সমস্যা CDN-এ, নাকি origin-এ?” প্রশ্নের অর্ধেক উত্তর এক মিনিটে পাওয়া যায়। চ্যাপ্টার ১৪-এর পুরো পদ্ধতি এই কৌশলের ওপর দাঁড়ানো।

একটা পেজ মানে অনেকগুলো যাত্রা

একটা HTML পেজ খুললে ব্রাউজার ডজনখানেক বা শতাধিক রিকোয়েস্ট পাঠায়: CSS, JS, ফন্ট, ছবি, API। প্রতিটার যাত্রা আলাদা, ফলও আলাদা: HTML হয়তো BYPASS (লগইন কুকি আছে), JS আর CSS HIT, একটা নতুন ছবি MISS, API DYNAMIC। ব্রাউজারের DevTools-এর Network ট্যাবে প্রতিটা রিকোয়েস্টের রেসপন্স হেডার খুলে CDN স্ট্যাটাস দেখুন; Timing ট্যাবে উপরের curl ধাপগুলোই ছবিতে দেখা যায়।

HTTP/2 আর HTTP/3-এ একই হোস্টের সব রিকোয়েস্ট একটা কানেকশনে যায়, তাই DNS, TCP, TLS-এর খরচ পেজে একবারই লাগে। সব অ্যাসেট একই CDN হোস্টনেমে রাখার এটা একটা বড় কারণ।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ	নিশ্চিত করবেন কীভাবে	সমাধান
রেসপন্সে কোনো CDN হেডার নেই	`dig +noall +answer www.baytalhikma.org` চালিয়ে দেখুন CNAME বা IP CDN-এর কিনা	DNS এখনো origin-এ। CDN-এর CNAME সেট করুন, বা প্রক্সি মোড চালু করুন; পুরনো রেকর্ডের TTL শেষ হওয়া পর্যন্ত অপেক্ষা করুন (DNS চ্যাপ্টার ৪)
`tcp − dns` ১০০ ms-এর বেশি, যদিও কাছে PoP আছে	PoP-এর নাম দেখুন হেডারে; `traceroute` বা `mtr` দিয়ে পথ দেখুন	ভুল PoP-এ রাউটিং। অন্য ISP বা মোবাইল ডেটা থেকে তুলনা করুন; ধারাবাহিক হলে প্রোভাইডারকে PoP নাম আর traceroute সহ জানান
প্রতিটা রিকোয়েস্ট MISS, বারবার চালালেও	দুইবার `curl -sI` চালিয়ে `age` আর ক্যাশ স্ট্যাটাস দেখুন	রেসপন্স ক্যাশেবল নয় (`Set-Cookie`, `private`, `no-store`), অথবা ক্যাশ কী প্রতিবার বদলাচ্ছে। চ্যাপ্টার ৩ ও ৪
MISS-এ TTFB বিশাল (কয়েক সেকেন্ড)	`--resolve` দিয়ে সরাসরি origin-এ একই রিকোয়েস্টের TTFB মাপুন	origin নিজেই ধীর হলে সেটা ঠিক করুন; origin দ্রুত হলে এজ-origin পথ বা shield সেটিং দেখুন (চ্যাপ্টার ৭)
ডিপ্লয়ের পর origin-এ হঠাৎ রিকোয়েস্টের ঢেউ	origin-এর অ্যাক্সেস লগে একই URL অনেকবার একই সেকেন্ডে আসছে কিনা দেখুন	request collapsing বা shield চালু করুন; সব ক্যাশ একসাথে purge না করে ভার্সনড ফাইলনেম ব্যবহার করুন (চ্যাপ্টার ৬)
HTTPS কাজ করে কিন্তু origin লগে প্লেইন HTTP আসে	origin-এর লগে স্কিম বা পোর্ট দেখুন	এজ থেকে origin-ও HTTPS করুন, সার্টিফিকেট যাচাই সহ (চ্যাপ্টার ৮)

মূল শিক্ষা

কোন PoP, সেটা DNS-এ ঠিক হয়। CNAME দিয়ে CDN-এর DNS ইউজারভিত্তিক IP দেয়, অথবা anycast-এ একই IP সব PoP থেকে ঘোষিত হয় আর রাউটিং কাছেরটায় নেয়।
TLS এজে শেষ হয়। হ্যান্ডশেক ছোট RTT-তে হয়, আর এজ রিকোয়েস্ট পড়তে পারে বলেই ক্যাশ করতে পারে।
ক্যাশ লুকআপের চার ফল: HIT, MISS, EXPIRED (revalidate করে), STALE (পুরনোটাই দেয়)।
Revalidation পুরো ফাইল না এনে 304 Not Modified-এ মেয়াদ বাড়ায়।
Shield origin-কে শত PoP-এর miss থেকে বাঁচায়; request collapsing একই মুহূর্তের হাজার miss-কে একটায় নামায়।
Age হেডার বলে কপিটা ক্যাশে কতক্ষণ আছে।
curl -w দিয়ে পার্থক্য পড়ুন: tcp − dns এজের দূরত্ব, ttfb − tls HIT বনাম MISS। --resolve দিয়ে এজ আর origin আলাদা করে জিজ্ঞেস করুন।