MSS नियम राउटरमा काम गर्छ, तर Squid सम्म पुग्दैन

एक प्रशासकले FORWARD मा TCPMSS क्ल्याम्पिङ थप्छ। सिधै राउट गरिएको ट्राफिक सुधार हुन्छ, तर स्थानीय Squid इन्स्ट्यान्स मार्फत डाउनलोड अझै अड्किन्छ। प्रोक्सीको वेबसाइट जडान क्लाइन्टको TCP जडान त्यो शृंखलाबाट जानु मात्र होइन।

सामान्य टर्मिनेटिङ फर्वार्ड प्रोक्सीमा क्लाइन्टतर्फको जडान स्थानीय रूपमा टुंगिन्छ। प्रोक्सीले मूल वा प्यारेन्टतर्फ दोस्रो TCP जडान बनाउँछ। Linux मा त्यो जडानका लागि बनाइएका प्याकेटहरू स्थानीय आउटपुट मार्ग अनुसरण गर्छन्।

त्यसैले FORWARD मात्रको नियम पूर्ण रूपमा कार्यशील हुँदै पनि समायोजन गर्नुपर्ने ह्यान्डशेक छुटाउन सक्छ। हुक छान्नु अघि वास्तविक जडान र SYN को दिशा नक्सामा उतार्नुहोस्। कन्टेनर वा छुट्टै नेमस्पेसले अर्को राउटेड खण्ड थप्न सक्छन्, त्यसैले सही स्थान प्रक्रिया कहाँ चल्छ भन्नेमा निर्भर हुन्छ।

PMTU सङ्ख्या सिधै MSS मा नराख्नुहोस्

मार्ग MTU भनेको IP प्याकेटको आकार हो। TCP MSS ले TCP पेलोड वर्णन गर्छ र सम्बन्धित हेडरहरू विचार गर्नुपर्छ। त्यस्तै, ping पेलोडको लम्बाइ पूरा IP प्याकेटको लम्बाइ होइन। परिचित 28 बाइट थप मूलभूत IPv4 ICMP echo व्यवस्थासँग जोडिएको छ, हरेक ठेगाना परिवार वा इन्क्याप्सुलेसनसँग होइन।

TCPMSS लक्ष्यले स्पष्ट मान र PMTU क्ल्याम्पिङ अभिलेख गर्छ। क्ल्याम्पिङ अझै मार्गको MTU जानकारीमा निर्भर छ; यो मार्ग पत्ता लगाउने कार्य स्वस्थ छ भन्ने प्रमाण होइन, र आवश्यक ICMP सन्देशहरूलाई अनुमति दिने विकल्प पनि होइन।

लक्षणलाई सिद्धान्तसँग पनि मिलाउनुहोस्। पूरा भएको ह्यान्डशेकपछि ठूला स्थानान्तरणमा अड्किनु प्याकेट आकार जाँच्ने आधार हुन सक्छ। बारम्बार जवाफ नआउने SYN वा तत्काल reset लाई फराकिलो व्याख्या चाहिन्छ; साना प्याकेट असफल हुँदैमा अत्यधिक ठूलो डेटा खण्ड प्रमाणित हुँदैन।

अभिलेखमा काम गर्ने सिधा जडान र असफल प्रोक्सी जडान छुट्टै राख्नुहोस्। एउटै मेसिनबाट पनि तिनीहरूले फरक स्रोत, मार्ग र इन्क्याप्सुलेसन प्रयोग गर्न सक्छन्।