फर्वार्ड प्रोक्सीले TCP खण्डका सीमाहरू जोगाउँदैन

मानौं Squid हुँदै गएपछि क्याप्चर गरिएका धेरै TCP खण्डहरूमा एउटा HTTP प्रतिक्रिया देखिन्छ। त्यो सामान्य TCP व्यवहार हुन सक्छ, प्रतिक्रिया गलत रूपमा विभाजन भयो भन्ने प्रमाण होइन।

फर्वार्ड प्रोक्सीसँग सामान्यतया दुई जडानहरू हुन्छन्:

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

प्रत्येक जडानको आफ्नै TCP अवस्था, क्रम संख्या र प्याकेटीकरण हुन्छ। प्रोक्सीले एउटा जडानबाट डेटा पढेर अर्कोमा लेख्न सक्छ, मूल खण्डका आकार नराखी। बफरिङ, पठाउने समय, भीड र मार्गको आकार-सीमाले अर्को समूह बनाउन सक्छ।

अलग राख्नुपर्ने तीन सीमाहरू

एउटा पढाइमा हेडरको एउटा भाग, पूरा हेडरसँगै बडी बाइट, वा एकभन्दा बढी अनुप्रयोग-तह सीमा नाघ्ने डेटा हुन सक्छ। TCP ले “HTTP प्रतिक्रियाको अन्त्य” सफल पढाइको अन्त्यसँग जोड्दैन।

त्यसैले HTTP/1.1 पार्सरले हेडरहरू जम्मा गरी लागू हुने बडी-फ्रेमिङ नियमहरू प्रयोग गर्छ, जसमा लम्बाइ, स्थानान्तरण कोडिङ वा अनुमत जडान बन्द हुनु पर्छ। HTTP/2 फ्रेम एउटा प्रोटोकल संरचना हो जुन आफैं TCP खण्डहरू नाघ्न सक्छ; यो सञ्जाल प्याकेटको अर्को नाम होइन।

सफल CONNECT सुरुङले सुरुङभित्रको बाइट प्रवाह जोगाउँछ, तैपनि दुई TCP खुट्टा प्रयोग गर्छ। प्रोक्सीले सुरुङभित्रका बाइट बदलेको नभए पनि यसका खण्ड सीमाहरू फरक हुन सक्छन्।

भ्रष्टाचारको अनुसन्धान गर्दा पुनः जोडिएको अनुप्रयोग डेटा तुलना गर्नुहोस्। प्याकेट संख्या तुलना गर्नु वा दुवैतर्फ समान प्याकेट लम्बाइ अपेक्षा गर्नु भनेको TCP सँग यसले नदिने सीमा-ग्यारेन्टी माग्नु हो।