लिनक्स में न्यूनतम टीसीपी एमएसएस

Question

लिनक्स में टीसीपी एमएसएस कम से कम 88 (शामिल / नेट / tcp.h होना चाहिए):

/* Minimal accepted MSS. It is (60+60+8) - (20+20). */
#define TCP_MIN_MSS             88U

मेरा सवाल है: वे "60 + 60 + 8" के साथ कहां आए और क्यों? मुझे लगता है कि 20 + 20 आईपी हेडर + टीसीपी हेडर से आता है।

संपादित करें: हेडर पर करीब से देखने के बाद, सूत्र मेरे लिए इस तरह दिखता है:

(MAX_IP_HDR + MAX_TCP_HDR + MIN_IP_FRAG) - (MIN_IP_HDR + MIN_TCP_HDR)

सवाल अभी भी खड़ा है: क्यों ? लिनक्स कर्नेल इस सूत्र का उपयोग क्यों करता है, जिससे टीसीपी सेगमेंट के एक मजबूर प्रवाह को रोकना पड़ता है, कहते हैं, 20 बाइट्स? यहाँ iperf सोचो।

EDIT2: यहां मेरा उपयोग मामला है। सॉकेट / कनेक्शन पर कम एमएसएस मजबूर करके, स्टैक द्वारा भेजे गए सभी पैकेटों का आकार छोटा होगा। मैं पैकेट / सेकंड टेस्टिंग के लिए iperf के साथ काम करते समय कम MSS सेट करना चाहता हूं। मैं MSS के लिए इस निचली सीमा की वजह से वायर पर 128 बाइट्स (142 बाइट्स के ईथरनेट फ्रेम) से छोटे पैकेट नहीं पा सकता हूँ! मैं RFC 2544 के अनुसार 64 बाइट्स के एक ईथरनेट फ्रेम आकार के करीब जाना चाहता हूं। सैद्धांतिक रूप से यह संभव होना चाहिए: 18 + 20 + 20 <64।

Comments

यह 20 बाइट्स के टीसीपी सेगमेंट को कैसे प्रतिबंधित करता है?

— डेविड श्वार्ट्ज

MSS अधिकतम सेगमेंट साइज़ के लिए है, यह विशेष रूप से सेगमेंट साइज़ के लिए ऊपरी सीमा (कम नहीं) है। TCP_MIN_MSS इस सीमा के लिए निम्न सीमा को निर्दिष्ट करता है। तो, यह 88 बाइट्स के साथ किसी भी तरह सेगमेंट में निषेध नहीं करता है, यह सिर्फ बताता है कि किसी भी कनेक्शन के लिए एमएसएस> = 88 बाइट्स होना चाहिए।

— जिलेन 6

बेशक! पर्याप्त स्पष्ट नहीं होने के लिए क्षमा करें। कृपया नवीनतम संपादन देखें।

— मिर्ज़ा ग़ेरज़ान

आपने बाउंटी की समाप्ति क्यों की? डेविड का जवाब कम से कम मेरी संतुष्टि तक चीजें साफ करता है। उनके उत्तर और मेरे बीच का अंतर यह है कि हम अलग-अलग मिनीमा के बारे में बात कर रहे हैं। जो इसके लायक है, उसके लिए एक तीसरा न्यूनतम है, जो कि 41, या 20 + 20 + 1 टीसीपी डेटा का बाइट है। तो न्यूनतम पैकेट का आकार उस कारण पर आकस्मिक है जो आप पूछ रहे हैं। मुझे उम्मीद है कि 68 उन मामलों में सही उत्तर है जहां कर्नेल उपयोग करता है TCP_MIN_MSS।

— वॉरेन यंग

मैं अभी भी उत्तर से संतुष्ट नहीं हूँ। मैं अभी भी उस कारण को देखने में विफल हूं जिसके लिए कर्नेल मुझे एक ऐप पर एक छोटे से एमएसबी को लगाने की अनुमति नहीं देता है। मैं 41 बाइट्स के आईपी-लोडेड (टीसीपी-लोडेड) की एक निरंतर धारा को पसंद करूंगा, लेकिन मैं नहीं कर सकता TCP_MIN_MSS। यह 1 क्यों नहीं हो सकता है? क्या RFC टूट जाएगा? क्या सिद्धांत / व्यावहारिक समस्या का कारण होगा? क्या आप सुनिश्चित हैं कि यह "युक्ति के बाहर" है? "अलग मिनिमा"? यहां केवल एक न्यूनतम ब्याज है: कर्नेल द्वारा अनुमत सबसे छोटा एमएसएस।

— मिरिक़ा गिर्ज़ान

Answer 1

अधिकतम आकार के टीसीपी और आईपी हेडर का समर्थन करने के लिए एक कार्यान्वयन आवश्यक है, जो प्रत्येक 60 बाइट्स हैं।

कार्यान्वयन को 576-बाइट डेटाग्राम का समर्थन करना चाहिए, जो अधिकतम हेडर के साथ भी डेटाग्राम में 8 बाइट्स से अधिक डेटा का मतलब है। डेटा के 8 से अधिक बाइट्स के साथ डेटाग्राम भेजने के लिए, आईपी विखंडन को कम से कम एक पैकेट में डेटा के कम से कम 8 बाइट्स डालने होंगे जो डेटाग्राम के टुकड़ों का प्रतिनिधित्व करते हैं। इस प्रकार एक पैकेट में कार्यान्वयन को कम से कम 8 बाइट डेटा का समर्थन करना चाहिए।

इसे एक साथ रखकर, एक कार्यान्वयन को 60 + 60 + 8 बाइट पैकेट का समर्थन करना चाहिए।

जब हम ऐसे पैकेट भेजते हैं जो एक टीसीपी स्ट्रीम का हिस्सा होते हैं, तो उनके पास एक 20-बाइट आईपी हेडर (प्लस विकल्प) और 20-बाइट टीसीपी हेडर (प्लस विकल्प) होता है। यह डेटा और विकल्पों के लिए शेष (60 + 60 + 8) - (20 + 20) बाइट्स छोड़ देता है। इसलिए यह वह अधिकतम है जो हम कार्यान्वयन के टीसीपी एमएसएस को सुरक्षित रूप से मान सकते हैं।

Comments

एमएसएस हैडर हालांकि (यह सिर्फ पेलोड है), और शामिल नहीं है 60शो में दो बार

— माइकल Mrozek

एक कार्यान्वयन अधिकतम-आकार के हेडर के साथ एक पैकेट का समर्थन करने में सक्षम होना चाहिए, लेकिन हम अधिकतम-आकार के हेडर नहीं भेज रहे हैं। अधिकतम और जो हम वास्तव में भेजते हैं उसके बीच का अंतर इसलिए डेटा के लिए उपलब्ध है और इसे एमएसएस में जोड़ा जाना चाहिए।

— डेविड श्वार्ट्ज

ठीक है, तो आपने 8 बाइट्स बताए हैं। मुझे नहीं पता कि आपके "टीसीपी / आईपी" हेडर का क्या मतलब है। मुझे एक आईपी हेडर और एक टीसीपी का पता है। और, जैसा कि माइकल ने 60 बार दो बार दिखाया। और आरएफसी केवल "प्रभावी एमएसएस" पर चर्चा करता है और न्यूनतम नहीं।

— Mircea Gherzan

60 बार दो बार दिखाई देता है, एक बार आईपी हेडर के लिए और एक बार टीसीपी हेडर के लिए।

— डेविड श्वार्ट्ज

68 सिर्फ विखंडन के बारे में है। "60 + 60 + 8" खंडित हो सकता है, इसलिए विखंडन की परवाह क्यों है? यहां तक ​​कि "68 + 20" खंडित हो सकता है। और "दूसरे पक्ष" को "60 + 60 + 8" क्यों "स्वीकार" करना चाहिए? "स्वीकार करें" के रूप में "विखंडन के बिना"? नीचे पंक्ति: मुझे "20 + 20" + 10 बाइट्स डेटा भेजने की अनुमति क्यों नहीं है?

— Mircea Gherzan

Answer 2

मुझे नहीं पता कि वह नंबर कहां से आया है, लेकिन मैं आपको बता सकता हूं कि यह कल्पना के बाहर है। IP नेटवर्क के लिए समर्थित न्यूनतम MTU 576 बाइट्स है, जो 512 डेटा बाइट्स है जो IP + TCP हेडर और TCP विकल्पों के लिए 64 बाइट्स तक है। उस मूल्य को विशिष्ट मामले में शालीनता से कम ओवरहेड देने के लिए चुना गया था।

कर्नेल कोड के बिट्स को पढ़ने से पता चलता है कि आप जो मूल्य दिखा रहे हैं वह मनमाना नहीं है। कच्चे कच्चे 64 का उपयोग करने के लिए एक पुराना अभ्यास था TCP_MIN_MSS। इसलिए, मुझे लगता है कि कुछ अजीब आईपी-ओवर-फू नेटवर्क है जो कर्नेल डेवलपर्स में आए थे जिससे उन्हें यह तय हुआ कि वे मूल्य बढ़ा सकते हैं कि आप कैसे देखते हैं।

हालांकि, यह गैर-मानक नेटवर्क प्रकार क्या है, मैं नहीं कह सकता।

Comments

576 डेटाग्राम के लिए MTU है । इस मामले में, यह पैकेट सीमाएं हैं जो मायने रखती हैं, न कि डेटाग्राम सीमाएं क्योंकि टीसीपी पैकेट डीएफ बिट सेट करते हैं।

— डेविड श्वार्ट्ज

IP डेटाग्राम के लिए न्यूनतम MTU परिभाषित किया गया है, और TCP पैकेट भी IP डेटाग्राम हैं।

— जिलेटेन

सही है, लेकिन यह टीसीपी सीमा पैकेट के लिए है, डेटाग्राम नहीं, क्योंकि टीसीपी डेटाग्राम कभी नहीं (सामान्य रूप से) टुकड़े होते हैं। एकमात्र अर्थ जिसमें 576-बाइट डेटाग्राम नियम मायने रखता है, इसका मतलब है कि कार्यान्वयन एक पैकेट में डेटा के कम से कम 8 बाइट्स (इसलिए सूत्र में 8) का समर्थन करने में सक्षम होना चाहिए। अन्यथा, 576-बाइट डेटाग्राम को खंडित करना असंभव होगा।

— डेविड श्वार्ट्ज