ଫରୱାର୍ଡ ପ୍ରକ୍ସି TCP ସେଗମେଣ୍ଟର ସୀମା ସଂରକ୍ଷଣ କରେ ନାହିଁ

ଧରନ୍ତୁ Squid ଦେଇ ଯିବା ପରେ ଏକ HTTP ପ୍ରତିକ୍ରିୟା ଅନେକ ଧରାଯାଇଥିବା TCP ସେଗମେଣ୍ଟରେ ଦେଖାଯାଏ। ଏହା ସାଧାରଣ TCP ଆଚରଣ ହୋଇପାରେ, ପ୍ରତିକ୍ରିୟା ଭୁଲ ଭାବରେ ବିଭାଜିତ ହୋଇଛି ବୋଲି ପ୍ରମାଣ ନୁହେଁ।

ଫରୱାର୍ଡ ପ୍ରକ୍ସିର ସାଧାରଣତଃ ଦୁଇଟି ସଂଯୋଗ ଥାଏ:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

ପ୍ରତ୍ୟେକ ସଂଯୋଗର ନିଜସ୍ୱ TCP ସ୍ଥିତି, କ୍ରମ ସଂଖ୍ୟା ଏବଂ ପ୍ୟାକେଟାଇଜେସନ୍ ଥାଏ। ପ୍ରକ୍ସି ଏକ ସଂଯୋଗରୁ ତଥ୍ୟ ପଢ଼ି ଅନ୍ୟଟିରେ ଲେଖିପାରେ, ମୂଳ ସେଗମେଣ୍ଟ ଆକାର ସଂରକ୍ଷଣ ନକରି। ବଫରିଂ, ପଠାଇବା ସମୟ, ଭିଡ଼ ଏବଂ ପଥର ଆକାର ସୀମା ଅନ୍ୟ ଏକ ଗୋଷ୍ଠୀ ସୃଷ୍ଟି କରିପାରେ।

ଅଲଗା ରଖିବା ଯୋଗ୍ୟ ତିନୋଟି ସୀମା

ଏକ ପଠନରେ ହେଡରର ଏକ ଅଂଶ, ସମ୍ପୂର୍ଣ୍ଣ ହେଡର ସହିତ ବଡି ବାଇଟ୍, କିମ୍ବା ଏକରୁ ଅଧିକ ଆପ୍ଲିକେସନ୍-ସ୍ତର ସୀମା ଅତିକ୍ରମ କରୁଥିବା ତଥ୍ୟ ରହିପାରେ। TCP “HTTP ପ୍ରତିକ୍ରିୟାର ଶେଷ”କୁ ସଫଳ ପଠନର ଶେଷ ସହିତ ଯୋଡ଼େ ନାହିଁ।

ତେଣୁ HTTP/1.1 ପାର୍ସର ହେଡର ସଂଗ୍ରହ କରି ପ୍ରଯୁଜ୍ୟ ବଡି-ଫ୍ରେମିଂ ନିୟମ ପ୍ରୟୋଗ କରେ, ଯେଉଁଥିରେ ଲମ୍ବ, ସ୍ଥାନାନ୍ତର କୋଡିଂ କିମ୍ବା ଅନୁମତିପ୍ରାପ୍ତ ସଂଯୋଗ ବନ୍ଦ ଅନ୍ତର୍ଭୁକ୍ତ। HTTP/2 ଫ୍ରେମ୍ ଏକ ପ୍ରୋଟୋକଲ ଗଠନ ଯାହା ନିଜେ TCP ସେଗମେଣ୍ଟ ଅତିକ୍ରମ କରିପାରେ; ଏହା ନେଟୱାର୍କ ପ୍ୟାକେଟର ଅନ୍ୟ ନାମ ନୁହେଁ।

ସଫଳ CONNECT ଟନେଲ ଟନେଲ ଭିତରର ବାଇଟ୍ ପ୍ରବାହ ସଂରକ୍ଷଣ କରେ, ତଥାପି ଦୁଇଟି TCP ପାଦ ବ୍ୟବହାର କରେ। ପ୍ରକ୍ସି ଟନେଲ ଭିତରର ବାଇଟ୍ ପରିବର୍ତ୍ତନ ନକରିଥିଲେ ମଧ୍ୟ ଏହାର ସେଗମେଣ୍ଟ ସୀମା ଭିନ୍ନ ହୋଇପାରେ।

ଦୁଷ୍ଟତା ଅନୁସନ୍ଧାନ କରିବା ସମୟରେ ପୁନଃ ସଂଯୋଜିତ ଆପ୍ଲିକେସନ୍ ତଥ୍ୟ ତୁଳନା କରନ୍ତୁ। ପ୍ୟାକେଟ୍ ସଂଖ୍ୟା ତୁଳନା କରିବା କିମ୍ବା ଉଭୟ ପାର୍ଶ୍ୱରେ ସମାନ ପ୍ୟାକେଟ୍ ଲମ୍ବ ଆଶା କରିବା TCP ନିକଟରୁ ଏପରି ସୀମା-ନିଶ୍ଚିତତା ମାଗିବା ଯାହା ଏହା ଦିଏ ନାହିଁ।