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 को व्यापक व्याख्या चाहिए; छोटे पैकेट विफल होने से अत्यधिक बड़ा डेटा खंड सिद्ध नहीं होता।

रिकॉर्ड में काम करने वाला सीधा कनेक्शन और विफल प्रॉक्सी कनेक्शन अलग रखें। एक ही मशीन से भी वे अलग स्रोत, मार्ग और एनकैप्सुलेशन इस्तेमाल कर सकते हैं।