फ़ॉरवर्ड प्रॉक्सी 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 से ऐसी सीमा-गारंटी माँगना है जो वह नहीं देता।