एफ़टीपी निष्क्रिय मोड एक एकल प्रसिद्ध बंदरगाह के विपरीत अल्पकालिक बंदरगाहों की एक श्रृंखला का उपयोग क्यों करता है? [बन्द है]

Question

एफ़टीपी निष्क्रिय मोड में, मैंने पढ़ा कि सर्वर क्लाइंट को एक यादृच्छिक पोर्ट नंबर भेजता है जहां वह डेटा चैनल स्थापित कर सकता है।
फिर क्लाइंट अपने रैंडम पोर्ट नंबर से सर्वर द्वारा भेजे गए इस पोर्ट नंबर पर एक डेटा चैनल स्थापित करता है।

मेरा सवाल यह है कि सर्वर क्लाइंट को रैंडम पोर्ट नंबर क्यों भेजता है? क्लाइंट सीधे सर्वर साइड पर नंबर 20 को पोर्ट करने के लिए डेटा चैनल की स्थापना क्यों नहीं कर सकता है?

Comments

मुझे लगा कि यह ऑफ टॉपिक था।

दुर्भाग्य से, OSI लेयर -4 से ऊपर के प्रोटोकॉल के बारे में प्रश्न यहाँ ऑफ-टॉपिक हैं।

— रॉन Maupin

Answer 1

कि कैसे FTP प्रोटोकॉल को निष्क्रिय मोड में काम करने के लिए डिज़ाइन किया गया था। यह शायद एक अच्छा विचार नहीं था, क्योंकि मुझे नहीं लगता कि यह मॉडल कभी भी किसी अन्य प्रोटोकॉल में फिर से दोहराया गया था (और यह एफ़टीपी सक्रिय मोड के बारे में और भी अधिक सच है)।

---

डेटा कनेक्शन पोर्ट पर, कोई प्रोटोकॉल नहीं है। वह सब जो सर्वर जानता है - केवल एक चीज जो उस संबंध में किसी भी जानकारी को वहन करती है - वह पोर्ट नंबर है जिसे आप कनेक्ट करते हैं।

यदि आप हर बार उसी पोर्ट से कनेक्ट होते हैं, तो सर्वर यह नहीं बता पाएगा कि आप किस फ़ाइल के लिए कनेक्ट कर रहे हैं। पोर्ट नंबर नियंत्रण कनेक्शन और डेटा कनेक्शन पर स्थानांतरण अनुरोध के बीच एक लिंक के रूप में कार्य करता है - पोर्ट नंबर PASVकमांड की प्रतिक्रिया में निहित है ।

यदि दो क्लाइंट एक ही समय में एक ट्रांसफर का अनुरोध करते हैं, जब सर्वर एक पोर्ट पर कनेक्शन स्वीकार करता है, तो सर्वर यह नहीं बता पाएगा कि किस फाइल को ट्रांसफर करना है। बेशक, सर्वर निर्णय के लिए एक क्लाइंट आईपी का उपयोग कर सकता है (वास्तव में कई एफ़टीपी सर्वर यह पुष्टि करते हैं कि क्लाइंट आईपी नियंत्रण कनेक्शन पर उपयोग किए गए आईपी से मेल खाता है, सुरक्षा के लिए)।

लेकिन यह काम नहीं करेगा:

• एक ही मशीन से कई कनेक्शन (अधिकांश एफ़टीपी ग्राहक समानांतर स्थानांतरण / कतारों का समर्थन करते हैं और आप वास्तव में एक मशीन पर कई अलग-अलग एफ़टीपी ग्राहक चला सकते हैं);
• समान (कॉरपोरेट) नेटवर्क के भीतर अलग-अलग मशीनों से कनेक्शन, क्योंकि उनके पास एक ही बाहरी आईपी है।

---

आंशिक रूप से मेरे जवाब से कॉपी किया गया कि एफ़टीपी निष्क्रिय मोड को केवल एक पोर्ट के विपरीत पोर्ट रेंज की आवश्यकता क्यों है? सर्वर दोष पर।

Comments

सर्वर की तरफ इस्तेमाल किया गया पोर्ट नंबर भी 20 सही हो सकता है? प्रत्येक उत्तर में, सर्वर की ओर पोर्ट संख्या 20 से अधिक है

— ज़ेफियर

मेरा उत्तर बताता है कि क्यों पोर्ट नंबर को प्रत्येक कनेक्शन / हस्तांतरण के लिए अद्वितीय होना चाहिए। तो यह 20 तक तय नहीं किया जा सकता है।

— मार्टिन प्रिक्रील

हाँ यह तय नहीं किया जा सकता है, लेकिन उनमें से एक 20 सही हो सकता है?

— जेफिर

हां, लेकिन सभी अन्य बंदरगाहों को 1024 से ऊपर होना चाहिए। और व्यावहारिक दृष्टिकोण से एक सन्निहित पोर्ट रेंज बेहतर है। अधिकांश फायरवॉल / NATs रेंज-आधारित नियमों का समर्थन करते हैं। आप अलग-अलग पोर्ट 20 के लिए एक विशेष नियम नहीं जोड़ना चाहते हैं - इसके अलावा अधिकांश एफ़टीपी सर्वर बंदरगाहों की सन्निहित सीमा का समर्थन करते हैं।

— मार्टिन प्रिक्रील

@ Zac67 नहीं, क्लाइंट निष्क्रिय मोड में फ़ाइल को पुनः प्राप्त करने के लिए एक नया कनेक्शन (नियंत्रण कनेक्शन से अलग) खोलेगा, इसलिए सर्वर क्लाइंट कनेक्शन के बीच अंतर करने के लिए स्रोत (क्लाइंट) पोर्ट नंबर का उपयोग नहीं कर सकता है। इसके अलावा, NAT अक्सर क्लाइंट सोर्स पोर्ट (और / या IP एड्रेस) को मैनेज करता है, जो अभ्यास में अनुपयोगी हो जाता है।

— jjmontes

Answer 2

आमतौर पर, सर्वर एक यादृच्छिक पोर्ट नहीं भेजता है, लेकिन एक परिभाषित (स्थापना द्वारा) रेंज / पूल से एक मुफ्त - क्लाइंट के लिए यह यादृच्छिक दिखता है। इस पोर्ट को फ़ायरवॉल पर अग्रेषित करने की आवश्यकता होती है, जिसमें एक सीमा को परिभाषित करने की आवश्यकता होती है।

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

Comments

तो यह 20 के रूप में अच्छी तरह से सही हो सकता है? हर वेबसाइट में डेटा के लिए सर्वर पोर्ट संख्या 20 से अधिक है।

— Zephyr

20 सक्रिय FTP के लिए सर्वर से आउटगोइंग पोर्ट है (जो किसी भी अधिक उपयोग में नहीं है)।

— Zac67

ऐसा नहीं था कि प्राचीन सर्वरों को परेशानी थी, यह है कि प्रोटोकॉल डिजाइनर अभी भी आदिम अनुरोध-प्रतिक्रिया से अधिक जटिल चीजों को करने का सबसे अच्छा तरीका जानने की कोशिश कर रहे थे।

— मार्क