«ପ୍ରତ୍ୟେକ ଉପଭୋକ୍ତାଙ୍କୁ ଦଶ ଗିଗାବାଇଟ୍ ଦିଅନ୍ତୁ» ଦୁଇଟି ରିପୋର୍ଟ ଅସମ୍ମତ ନହେବା ପର୍ଯ୍ୟନ୍ତ ସଠିକ୍ ଶୁଣାଯାଏ। ଗୋଟିଏ ଗ୍ରାହକଙ୍କୁ ପଠାଯାଇଥିବା ଉତ୍ତର ଯୋଡ଼ିଥିଲା; ଅନ୍ୟଟି ଉପରସ୍ତରରୁ ଅଣାଯାଇଥିବା ବାଇଟ୍ ଗଣିଥିଲା। ଉଭୟ ନିଜ ଚୟନିତ ଫିଲ୍ଡ ସଠିକ୍ ଭାବରେ ରିପୋର୍ଟ କରୁଥାଇପାରନ୍ତି।

Squid ଲଗ୍ ଫର୍ମାଟରେ ଅଲଗା କାଉଣ୍ଟର ଅଛି:

ଫିଲ୍ଡଦଲିଲଭୁକ୍ତ ମାପ
%<stଆଡାପ୍ଟେସନ ପରେ ଗ୍ରାହକକୁ ପଠାଯାଇଥିବା ସମୁଦାୟ ଉତ୍ତର ଟ୍ରାଫିକ
%>stଗ୍ରାହକଠାରୁ ଗ୍ରହଣ କରାଯାଇଥିବା ସମୁଦାୟ ଅନୁରୋଧ ଆକାର, chunked ଏନକୋଡିଂ ବାଇଟ୍ ବାଦ୍ ଦେଇ
%<bsପରବର୍ତ୍ତୀ hop ରୁ ଗ୍ରହଣ କରାଯାଇଥିବା HTTP-ସମାନ ସନ୍ଦେଶ ବଡି ବାଇଟ୍, ଦଲିଲଭୁକ୍ତ ବ୍ୟତିକ୍ରମ ସହିତ

Squid ର ମୂଳ ଲଗ୍‌ର bytes ସ୍ତମ୍ଭ ଗ୍ରାହକ ଉତ୍ତର କାଉଣ୍ଟର ବ୍ୟବହାର କରେ। ଏହା ଏକ ପ୍ରତିଶ୍ରୁତି ନୁହେଁ ଯେ ମୂଲ୍ୟ ସଞ୍ଚିତ ଫାଇଲର ଲମ୍ବ ସହିତ ସମାନ, କିମ୍ବା ISP ଦ୍ୱାରା ଚାର୍ଜ କରାଯାଉଥିବା ପ୍ରତ୍ୟେକ Ethernet କିମ୍ବା IP ବାଇଟ୍‌ର ମାପ ନୁହେଁ।

କ୍ୟାସ୍ ହିଟ୍ ପାର୍ଥକ୍ୟ ଦେଖାଏ: Squid ଉପରସ୍ତରରୁ ନୂଆ ନ ଆଣି ଉତ୍ତର ପଠାଇ ପାରେ। ଅଧିକ ଅପଲୋଡ୍ ଥିବା କାମ ଅନ୍ୟ ଏକ ଦେଖାଏ: କେବଳ ଉତ୍ତର ଗଣିଲେ ଅନୁରୋଧର ଦିଗ ବଜେଟ୍ ବାହାରେ ରହେ।

CONNECT ପାଇଁ, ପ୍ରକ୍ସି ଟନେଲ ଭିତରେ ଥିବା ପ୍ରତ୍ୟେକ ଏନକ୍ରିପ୍ଟେଡ୍ ଫାଇଲ୍ କିମ୍ବା ପୃଷ୍ଠା ନ ବୁଝି ସ୍ଥାନାନ୍ତରିତ ଟ୍ରାଫିକ୍ ହିସାବ କରିପାରେ। କିନ୍ତୁ ଟନେଲର ବାଇଟ୍ ମୋଟକୁ ଡାଉନଲୋଡ୍ ହୋଇଥିବା ଆପ୍ଲିକେସନ୍ ବସ୍ତୁଗୁଡ଼ିକର ସଠିକ୍ ତାଲିକାରେ ପରିଣତ କରିପାରିବ ନାହିଁ।

କୋଟା ଚୁକ୍ତିନାମାକୁ କାଉଣ୍ଟର ପାଖରେ ଲେଖନ୍ତୁ: ଦିଗ, ପର୍ଯ୍ୟବେକ୍ଷଣ ବିନ୍ଦୁ, ହିସାବ ଅବଧି ଏବଂ ପରିଚୟ। ତା’ପରେ ଲଗ୍ ଫର୍ମାଟର ସଂସ୍କରଣକୁ ରିପୋର୍ଟ ସହିତ ରଖନ୍ତୁ। ଏକ ବାଇଟ୍‌ର ଅର୍ଥ ନେଇ ଅସହମତିକୁ ପ୍ରତ୍ୟେକ ମୂଲ୍ୟକୁ ଏକ ଅନୁମାନିତ ସଂଶୋଧନ ଗୁଣକ ସହିତ ଗୁଣନ କରି «ଠିକ୍» କରିବା ଉଚିତ୍ ନୁହେଁ। ପ୍ରୟୋଗ ପାଇଁ ସମ୍ପୂର୍ଣ୍ଣ ହୋଇଥିବା କାରବାରର ମୋଟ ରିଅଲ୍-ଟାଇମ୍ ବ୍ୟବହାରଠାରୁ ପଛରେ ରହିପାରେ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ