एफ़टीपी में, निष्क्रिय और विस्तारित निष्क्रिय मोड के बीच अंतर क्या हैं?


17

क्या कोई केवल निष्क्रिय मोड एफ़टीपी (पीएएसवी) और विस्तारित निष्क्रिय मोड एफ़टीपी (ईपीएसवी) के बीच अंतर बता सकता है?


2
@DavidPostill क्षमा करें, मुझे वास्तव में केवल PASV बनाम EPSV में दिलचस्पी थी।
CGCampbell

जवाबों:


20

एकमात्र अंतर यह है कि PORT/PASVआईपीवी 4 तक सीमित हैं , जबकि EPRT/EPSVकिसी भी नेटवर्क प्रोटोकॉल के साथ काम करते हैं (हालांकि केवल आईपीवी 6 का उपयोग अभ्यास में किया जाता है)।

एफ़टीपी नियंत्रण प्रोटोकॉल विनिमय पते और पोर्ट सूचना में मानक PORT(सक्रिय) और PASV(निष्क्रिय) आदेश छह 1-बाइट दशमलव के रूप में होता है , जिसमें से दूसरे छोर पर एक चार-बाइट आईपी पते और दो-बाइट टीसीपी पोर्ट नंबर को फिर से बनाना पड़ता है।

PORT <address[4]>,<port[2]>

PORT 132,235,1,2,24,131

लेकिन फिर अन्य प्रोटोकॉल दिखाई देने लगे। IPv4 को "IPng" के साथ प्रतिस्थापित किया जाने वाला था, जिसमें काफी प्रतिस्पर्धी प्रतिस्थापन प्रस्ताव थे (OSI CLNP, TUBA, SIP, SIPP, CATNIP - इतिहास के विभिन्न समयों में), कुछ छोटे, लंबे, लंबे, यहाँ तक कि परिवर्तनीय मेजबान पता आकारों के साथ, 16 बाइट के पते के साथ IPv6 तक अंत में परिभाषित किया गया।

बस अधिक बाइट भेजने से काम नहीं होगा - सर्वर और क्लाइंट को पता लंबाई पर शुद्ध प्रोटोकॉल आधारित शुद्ध रूप से पता चलने की उम्मीद नहीं की जा सकती है। (उदाहरण के लिए, यदि आपके पास 16 बाइट एड्रेस + 4 बाइट पोर्ट के साथ एक प्रोटोकॉल है, तो दूसरा 12 बाइट एड्रेस + बाइट पोर्ट के साथ है?)

इसके अलावा - भले ही यह 20 साल पहले कम महत्वपूर्ण था - इन दिनों इंटरनेट पर लाखों एनएटी डिवाइस हैं , जो एफ़टीपी नियंत्रण कनेक्शनों का निरीक्षण और प्रबंधन करते हैं ताकि "बाहर" मेजबान केवल वैश्विक आईपीवी 4 पते देखें, भले ही "अंदर" होस्ट ने एक RFC1918 स्थानीय को भेजा। नेट के बिना भी, स्टेटफुल फायरवॉल अक्सर नियंत्रण नियमों को मैन्युअल नियमों के बिना डेटा कनेक्शन की अनुमति देने के लिए देखते हैं।

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

उपरोक्त विभिन्न समस्याओं से बचने के लिए, FTP में मल्टी-प्रोटोकॉल सपोर्ट के लिए नए कमांड पेश करने पड़े।

1993 में, RFC 1639 (मूल रूप से RFC 1545 ) ने "लॉन्ग एड्रेस" LPRTऔरLPSV कमांड्स की शुरुआत की , जो एक वैरिएबल की लंबाई के समान PORTऔर PASVलेकिन थे ; उन्होंने प्रोटोकॉल प्रकार पहचानकर्ता को भी शामिल किया। (हालांकि इसका सिंटैक्स नहीं बदला - IPv6 पता: पोर्ट केवल छह के बजाय 21 नंबर के रूप में भेजा जाएगा।)

LPRT <protocol>,<addr-length>,<address...>,<port-length>,<port...>

LPRT 4,4,132,235,1,2,2,24,131

LPRT 6,16,16,128,0,0,0,0,0,0,0,8,8,0,32,12,65,122,2,20,162

हालाँकि, यह अभी भी कुछ समस्याओं को ठीक नहीं करता था, जैसे कि एक सर्वर को नियंत्रण कनेक्शन की तुलना में एक अलग प्रोटोकॉल का उपयोग करने के लिए कहना। RFC भी जल्दी से पुराना हो गया; जब आईपीवी 6 केवल एक साल बाद बाहर आया, तो इसका उपयोग एलपीआरटी के साथ नहीं किया जा सकता था क्योंकि इसके लिए कोई एलपीआरटी प्रोटोकॉल पहचानकर्ता नहीं सौंपा गया था (केवल विभिन्न प्रारंभिक प्रस्तावों के लिए)।

इसे ठीक करने के लिए, 1998 में RFC 2428 को जोड़ा गया EPRTऔर EPSV, उर्फ ​​"विस्तारित पोर्ट" और "विस्तारित निष्क्रिय" , जिसमें एक प्रोटोकॉल पर बातचीत करने का एक तरीका भी था जो दोनों का समर्थन करता है। IPv6 के लिए "विस्तारित" कमांड मानव-पठनीय रूप में पते भी भेजते हैं, इसका मतलब है कि अलग दशमलव संख्याओं की एक श्रृंखला के बजाय हेक्स और कोलोन नोटेशन का उपयोग करना।

EPRT x<protocol>x<address>x<port>x

EPRT |1|132.235.1.2|6275|

EPRT |2|1080::8:800:200C:417A|5282|

निष्कर्ष में, IPv6 समर्थन एकमात्र अंतर है।


वाह, सभी साइटें जो मैंने पढ़ी हैं और यह इस एक पर क्लिक नहीं की है। उसके लिये आपका धन्यवाद। मैं इसे (शायद) एक या दो घंटे में स्वीकार कर लूंगा, देखना चाहता हूं कि क्या कोई और इसे अलग करता है। साथ ही, मैंने एक्टिव होने के लिए जो कारण पूछा, वह यह था कि गूगल के साथ अच्छी तरह से काम करने वाले टैगिंग के कारण, यह प्रश्न / उत्तर खोजों में मिलेगा। यदि कोई भी उत्तर में नहीं जोड़ता है (इसे Google उत्तर के लिए पूरी तरह से पूर्ण बना दिया जाता है) तो मैं आपके उत्तर की सामग्री को प्रतिबिंबित करने के लिए अपने मूल प्रश्न और शरीर को संपादित करूंगा, अनिवार्य रूप से आपके प्रश्न को आपके उत्तर में फिट करूंगा।
CGCampbell

3
एक और अंतर यह है कि EPSVप्रतिक्रिया में आईपी पता ( PASVप्रतिक्रिया क्या करती है) शामिल नहीं है। यह आम समस्या से बचने के लिए है जब एक नेट के पीछे स्थित एफ़टीपी सर्वर बाहरी आईपी पते को नहीं जानता है और एफ़टीपी क्लाइंट को यह आंतरिक पता भेजकर भ्रमित करता है।
मार्टिन प्रिक्रील

@MartinPrikryl जो कहता है उसे जोड़ने के लिए, एक और कारण एफ़टीपी-ओवर-टीएलएस का उपयोग करते समय, फ़ायरवॉल / NAT इसे फिर से लिखने के लिए PASV कमांड में आईपी पते को बाधित नहीं कर सकता है (कम से कम नियंत्रण कनेक्शन को मिटाने के बिना।) जबकि। यूनिक्स दुनिया के लोग आमतौर पर एफ़टीपी-ओवर-टीएलएस के बजाय एसएफटीपी का उपयोग करते हैं, एफ़टीपी-ओवर-टीएलएस का उपयोग आमतौर पर आईबीएम मेनफ़्रेम के साथ किया जाता है, क्योंकि एफ़टीपी के पास रिकॉर्ड-ओरिएंटेड फ़ाइलों (STRU R, MODE B) का समर्थन है, जबकि SFTP केवल स्ट्रीम-ओरिएंटेड का समर्थन करता है फ़ाइलें
साइमन Kissane

1

सक्रिय और निष्क्रिय के बीच अंतर पहले से ही उत्तर दिया गया है। एक्सटेंडेड पैसिव (EPSV) IPv4 और IPv6 के साथ सिर्फ पैसिव है, क्योंकि PASV के प्रति प्रतिक्रिया का सिंटैक्स IPv4 के लिए विशिष्ट था और इस प्रकार IPv6 के लिए एक नए कमांड की आवश्यकता थी। सक्रिय मोड में EPTR बनाम PORT के साथ भी। ईपीआरटी और ईपीएसवी के साथ थोड़ा अलग व्यवहार है, जिसमें वे केवल पोर्ट को शामिल कर सकते हैं, न कि आईपी और पोर्ट जैसे पोर्ट और पीएएसवी करते हैं। इस प्रकार डेटा ट्रांसफर केवल उन प्रणालियों के बीच किया जा सकता है जिनके पास नियंत्रण कनेक्शन है। पोर्ट और पीएएसवी के साथ अन्य प्रणालियों के बीच डेटा कनेक्शन बनाना संभव है (हालांकि यह आज खराब डिजाइन और सुरक्षा जोखिम माना जाता है)।


2
इस तरह का जवाब मुझे नहीं चाहिए था। यह मुझे उतना ही बताता है जितना कि मुझे कहीं और मिल सकता है, जो यह है कि IPV6 के लिए EPSV बनाया गया था, लेकिन यह नहीं समझा रहा था कि क्यों। (यानी मैं आपके कारण को एक अच्छी पर्याप्त व्याख्या के रूप में स्वीकार नहीं करता) मैं आपको इस उम्मीद में बता रहा हूं कि आप शायद अपना उत्तर और भी बेहतर बना लेंगे।
CGCampbell

यह स्पष्ट करने के लिए संपादित प्रतिक्रिया, कि IPv6 का समर्थन नहीं करने के लिए PASV कमांड की प्रतिक्रिया और इस प्रकार एक नई कमांड की आवश्यकता थी।
स्टीफेन उल्रिच
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.