কোন Squid বাইট কাউন্টার ট্রাফিক কোটা ব্যবহার করা উচিত?
Squid লগ ফিল্ড যোগ করার আগে নির্ধারণ করুন প্রক্সি কোটা উত্তর, অনুরোধ, আপস্ট্রিম বডি নাকি অ্যাক্সেস-লিংক ট্রাফিক মাপে।
“প্রতিটি ব্যবহারকারীকে দশ গিগাবাইট দিন” শুনতে নির্দিষ্ট লাগে, যতক্ষণ না দুটি প্রতিবেদন মিলছে না। একটি ক্লায়েন্টকে পাঠানো উত্তর যোগ করেছে; অন্যটি আপস্ট্রিম থেকে আনা বাইট গণনা করেছে। দুটিই হয়তো নিজের বেছে নেওয়া ফিল্ড সঠিকভাবেই জানাচ্ছে।
Squid-এর লগ ফরম্যাটে আলাদা কাউন্টার আছে:
| ফিল্ড | নথিভুক্ত পরিমাপ |
|---|---|
%<st | অ্যাডাপ্টেশনের পরে ক্লায়েন্টকে পাঠানো মোট উত্তর ট্রাফিক |
%>st | ক্লায়েন্ট থেকে পাওয়া মোট অনুরোধের আকার, চাঙ্কড-এনকোডিং বাইট বাদ দিয়ে |
%<bs | পরবর্তী হপ থেকে পাওয়া HTTP-সমতুল্য বার্তা-বডি বাইট, নথিভুক্ত বর্জনসহ |
নেটিভ Squid লগের বাইট কলাম ক্লায়েন্ট-উত্তর কাউন্টার ব্যবহার করে। এটি সংরক্ষিত ফাইলের দৈর্ঘ্যের সমান হওয়ার প্রতিশ্রুতি নয়, আর আইএসপি যে প্রতিটি ইথারনেট বা IP বাইট চার্জ করে তার পরিমাপও নয়।
ক্যাশ হিট পার্থক্য দেখায়: Squid নতুন আপস্ট্রিম ফেচ না করেই উত্তর পাঠাতে পারে। আপলোড-প্রধান কাজ আরেকটি দিক দেখায়: কেবল উত্তর গণনা করলে অনুরোধের দিকটি বাজেটের বাইরে থাকে।
CONNECT-এর ক্ষেত্রে প্রক্সি টানেলের ভেতরের প্রতিটি এনক্রিপ্টেড ফাইল বা পৃষ্ঠা না বুঝেই রিলে করা ট্রাফিক হিসাব করতে পারে। তবে টানেলের মোট বাইটকে ডাউনলোড করা অ্যাপ্লিকেশন অবজেক্টের নির্ভুল তালিকায় বদলাতে পারে না।
কাউন্টারের পাশেই কোটা চুক্তি লিখুন: দিক, পর্যবেক্ষণ বিন্দু, হিসাবকাল এবং পরিচয়। তারপর লগ ফরম্যাটের সংস্করণ প্রতিবেদনের সঙ্গে রাখুন। বাইটের অর্থ নিয়ে মতভেদ অনুমানভিত্তিক সংশোধন গুণক দিয়ে প্রতিটি মান গুণ করে “ঠিক” করা উচিত নয়। প্রয়োগের জন্য সম্পন্ন লেনদেনের মোট সক্রিয় ব্যবহারের চেয়ে পিছিয়ে থাকতে পারে।