ফরওয়ার্ড প্রক্সি 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-এর কাছে এমন সীমানা-নিশ্চয়তা চাওয়া যা এটি দেয় না।