ପ୍ୟାକେଟ ଟ୍ରେସ TCP ZeroWindow ଦେଖାଏ। କର୍ନେଲ ସେଟିଂ ବଦଳାଇବା ପୂର୍ବରୁ ଶୂନ୍ୟ ଘୋଷଣା କରୁଥିବା ଶେଷ ବିନ୍ଦୁ ଚିହ୍ନଟ କରନ୍ତୁ।

ସେ ଶେଷ ବିନ୍ଦୁ ସେହି TCP ସଂଯୋଗରେ ନିଜର ଗ୍ରହଣ କ୍ଷମତା ବର୍ଣ୍ଣନା କରୁଛି। ଏହା ସମଗ୍ର ପ୍ରକ୍ସିର କେତେ ବ୍ୟାଣ୍ଡୱିଡଥ ଅଛି ଘୋଷଣା କରୁନାହିଁ। ଶୂନ୍ୟ-ୱିଣ୍ଡୋ ପ୍ରୋବ ପଠାଉଥିବା ବ୍ୟକ୍ତିକୁ ଘୋଷିତ କ୍ଷମତା ବଦଳିଛି କି ନାହିଁ ଜାଣିବାକୁ ଦିଏ; ପ୍ରୋବ ଏକାକୀ ପ୍ୟାକେଟ କ୍ଷତି କିମ୍ବା ଖରାପ ପ୍ରକ୍ସି ପ୍ରମାଣ କରେ ନାହିଁ।

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

ଏହି ସବୁ ଅଲଗା TCP ବାର୍ତ୍ତାଳାପ। ଧରନ୍ତୁ ବ୍ରାଉଜର ଏକ ବଡ଼ ପ୍ରତିକ୍ରିୟା ପଢ଼ିବା ବନ୍ଦ କରେ ଏବଂ A ରେ ଶୂନ୍ୟ ଘୋଷଣା କରେ। ପ୍ରକ୍ସିର ନିଜ ବଫର ଭରିବା ସହିତ ଏହା ଶେଷରେ B ଖାଲି କରିବା ବନ୍ଦ କରିପାରେ। B ରେ ପରେ ଦେଖାଯାଉଥିବା ଶୂନ୍ୟ ୱିଣ୍ଡୋ ମୂଳ ସମସ୍ୟା ନୁହେଁ, ମନ୍ଥର କ୍ଲାୟେଣ୍ଟର ପରିଣାମ ହୋଇପାରେ।

ଅପଲୋଡ ସମୟରେ ବିପରୀତ ସ୍ଥିତି ସମ୍ଭବ। ଯଦି ଗନ୍ତବ୍ୟ ଆପ୍ଲିକେସନ ଡାଟା ବ୍ୟବହାର କରିବା ବନ୍ଦ କରେ, B ରେ ଏହାର ୱିଣ୍ଡୋ ବନ୍ଦ ହୋଇପାରେ। ତାପରେ ଚାପ ପ୍ରକ୍ସିର ବଫର ଦେଇ କ୍ଲାୟେଣ୍ଟ ଆଡ଼କୁ ଫେରିପାରେ।

ପର୍ଯ୍ୟବେକ୍ଷଣଗୁଡ଼ିକୁ କ୍ରମରେ ରଖନ୍ତୁ

  1. ସଂଯୋଗର ଦୁଇ ଶେଷ ବିନ୍ଦୁ ଏବଂ ପ୍ରଭାବିତ ଡାଟା ସ୍ଥାନାନ୍ତରର ଦିଶା ଲିପିବଦ୍ଧ କରନ୍ତୁ।
  2. କେଉଁ ଶେଷ ବିନ୍ଦୁ ପ୍ରଥମେ ସଙ୍କୁଚିତ କିମ୍ବା ଶୂନ୍ୟ ଗ୍ରହଣ ୱିଣ୍ଡୋ ଘୋଷଣା କଲା ଚିହ୍ନଟ କରନ୍ତୁ।
  3. ଏହାର ଆପ୍ଲିକେସନ ପଢ଼ୁଥିଲା କି, ଅନ୍ୟ କାର୍ଯ୍ୟରେ ଅଟକି ଥିଲା କି, କିମ୍ବା ସମ୍ବଳ ଦ୍ୱାରା ସୀମିତ ଥିଲା କି ଯାଞ୍ଚ କରନ୍ତୁ।
  4. ମୂଳ କାରଣ ନିର୍ଦ୍ଧାରଣ କରିବା ପୂର୍ବରୁ ପ୍ରକ୍ସିର ଅନ୍ୟ ସଂଯୋଗରେ ସମୟ ସହ ତୁଳନା କରନ୍ତୁ।

Wireshark ର ୱିଣ୍ଡୋ ବିଶ୍ଳେଷଣ ଲେବଲ କ୍ୟାପଚରର ଉପଯୋଗୀ ବ୍ୟାଖ୍ୟା, ପ୍ରତ୍ୟେକ ଗ୍ରହଣ ବଫର ବଢ଼ାଇବା ନିର୍ଦ୍ଦେଶ ନୁହେଁ। ୱିଣ୍ଡୋ ସ୍କେଲିଂକୁ ମଧ୍ୟ ସଂଯୋଗର ଆଲୋଚନା ଦୃଷ୍ଟିରୁ ବ୍ୟାଖ୍ୟା କରିବା ଆବଶ୍ୟକ।

ପ୍ରକ୍ସି ତାଲିକାରୁ ଅନ୍ୟ ଏକ ଶେଷ ବିନ୍ଦୁ ଚେଷ୍ଟା କରି ସ୍ଥାନାନ୍ତର ସୁଧାରିବା ଦେଖିବା ପଥ ବଦଳିଛି ବୋଲି ଉପଯୋଗୀ ପ୍ରମାଣ। କିନ୍ତୁ ଏହା ନିଜେ ପ୍ରମାଣ କରେ ନାହିଁ ଯେ କୌଣସି ଅପରେଟିଂ ସିଷ୍ଟମର TCP କାର୍ଯ୍ୟକାରୀ ତ୍ରୁଟିପୂର୍ଣ୍ଣ ଥିଲା। ବ୍ୟାଖ୍ୟାକୁ ଗ୍ରହଣ ପ୍ରକ୍ରିୟା ଏବଂ ଯେଉଁ ସଂଯୋଗରେ ଅପେକ୍ଷା ଆରମ୍ଭ ହୋଇଥିଲା ସେଥିସହ ଯୋଡ଼ି ରଖନ୍ତୁ।

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