फॉरवर्ड प्रॉक्सी TCP विभागांच्या सीमा जपत नाही
फॉरवर्ड प्रॉक्सीच्या दोन्ही बाजूंचा रहदारी तपासताना TCP विभाजन, सॉकेट वाचन आणि HTTP चौकट वेगळे ठेवा.
समजा, Squid मधून गेल्यानंतर HTTP प्रतिसाद कैद केलेल्या अनेक TCP विभागांमध्ये दिसतो. ते सामान्य TCP वर्तन असू शकते, प्रतिसाद चुकीने विभागला गेल्याचा पुरावा नाही.
फॉरवर्ड प्रॉक्सीला साधारणपणे दोन जोडण्या असतात:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin
प्रत्येक जोडणीची स्वतःची TCP स्थिती, क्रमांक आणि पॅकेटीकरण असते. प्रॉक्सी एका जोडणीतून माहिती वाचून दुसऱ्यात लिहू शकतो, मूळ विभागाचे आकार न जपता. बफरिंग, पाठवण्याची वेळ, गर्दी आणि मार्गाच्या आकारमर्यादा वेगळे गट तयार करू शकतात.
वेगळे ठेवण्यासारख्या तीन सीमा
| सीमा | ती कशामुळे ठरते |
|---|---|
| TCP विभाग | वाहतूक आणि नेटवर्क मार्ग |
| सॉकेट वाचनाचा निकाल | उपलब्ध प्रवाह बाइट आणि कॉलरचा बफर |
| HTTP संदेश किंवा चौकट | HTTP प्रोटोकॉलचे चौकट नियम |
एका वाचनात हेडरचा काही भाग, पूर्ण हेडर सोबत बॉडी बाइट, किंवा एकापेक्षा जास्त अनुप्रयोग-स्तर सीमा ओलांडणारा डेटा असू शकतो. TCP “HTTP प्रतिसादाचा शेवट” यशस्वी वाचनाच्या शेवटाशी जोडत नाही.
म्हणून HTTP/1.1 पार्सर हेडर जमा करतो आणि लागू बॉडी-चौकट नियम वापरतो, त्यात लांबी, हस्तांतरण कोडिंग किंवा परवानगी असलेले जोडणी बंद करणे यांचा समावेश होतो. HTTP/2 चौकट ही प्रोटोकॉल रचना आहे जी स्वतः TCP विभाग ओलांडू शकते; ती नेटवर्क पॅकेटचे दुसरे नाव नाही.
यशस्वी CONNECT बोगदा बोगद्यातील बाइट प्रवाह जपतो, तरीही दोन TCP पाय वापरतो. प्रॉक्सीने बोगद्यातील बाइट बदलले नसले तरी त्याच्या विभाग सीमा वेगळ्या असू शकतात.
भ्रष्टाचाराची चौकशी करताना पुन्हा जोडलेल्या अनुप्रयोग डेटाची तुलना करा. पॅकेट संख्या तुलना करणे किंवा दोन्ही बाजूंना समान पॅकेट लांबी अपेक्षित धरणे म्हणजे TCP कडे तो देत नसलेली सीमा-हमी मागणे होय.