फाइल ट्रांसफर प्रोटोकॉल

फाइल ट्रांसफर प्रोटोकॉल (एफ़टीपी) एक मानक संचार प्रोटोकॉल है जिसका उपयोग कंप्यूटर नेटवर्क पर सर्वर से क्लाइंट तक कम्प्यूटर फाइल के हस्तांतरण के लिए किया जाता है। एफ़टीपी क्लाइंट-सर्वर मॉडल आर्किटेक्चर पर क्लाइंट और सर्वर के बीच अलग-अलग नियंत्रण और डेटा कनेक्शन का उपयोग करके बनाया गया है। एफ़टीपी उपयोगकर्ता खुद को एक स्पष्ट पाठ | स्पष्ट-पाठ साइन-इन प्रोटोकॉल के साथ प्रमाणित कर सकते हैं, सामान्य रूप से एक उपयोगकर्ता नाम और पासवर्ड के रूप में, लेकिन अगर सर्वर इसे अनुमति देने के लिए कॉन्फ़िगर किया गया है तो गुमनाम रूप से जुड़ सकता है। सुरक्षित प्रसारण के लिए जो उपयोगकर्ता नाम और पासवर्ड की सुरक्षा करता है, और सामग्री को एन्क्रिप्ट करता है, FTP अक्सर #Security with Transport Layer Security|SSL/TLS (FTPS) होता है या एसएसएच फाइल ट्रांसफर प्रोटोकॉल (SFTP) के साथ बदल दिया जाता है।

पहले एफ़टीपी क्लाइंट एप्लिकेशन कमांड लाइन इंटरफेस थे। ऑपरेटिंग सिस्टम में ग्राफिकल यूज़र इंटरफ़ेस होने से पहले कमांड-लाइन प्रोग्राम विकसित किए गए थे, और अभी भी अधिकांश खिड़कियाँ, यूनिक्स और लिनक्स ऑपरेटिंग सिस्टम के साथ भेजे जाते हैं। डेस्कटॉप कंप्यूटर, सर्वर, मोबाइल डिवाइस और हार्डवेयर के लिए कई समर्पित एफ़टीपी क्लाइंट (कंप्यूटिंग) और ऑटोमेशन उपयोगिताओं को विकसित किया गया है, और एफ़टीपी को HTML संपादकों और फ़ाइल प्रबंधकों जैसे उत्पादकता अनुप्रयोगों में शामिल किया गया है।

एक एफ़टीपी क्लाइंट आमतौर पर वेब ब्राउज़र में एकीकृत होता था, जहाँ फ़ाइल सर्वर को यूनिफॉर्म रिसोर्स पहचानकर्ता प्रीफ़िक्स के साथ ब्राउज़ किया जाता है. 2021 के दौरान, दो प्रमुख वेब ब्राउज़र विक्रेताओं ने इस क्षमता को हटा दिया। FTP प्रोटोकॉल के लिए सपोर्ट सबसे पहले Google Chrome 88 में जनवरी 2021 में डिसेबल किया गया था, इसके बाद अप्रैल 2021 में फ़ायरफ़ॉक्स 88.0। जुलाई 2021 में, Firefox 90 ने FTP को पूरी तरह से हटा दिया, और Google ने अक्टूबर 2021 में सूट का पालन किया, FTP को पूरी तरह से Google Chrome 95 में हटा दिया।

एफ़टीपी सर्वरों का इतिहास
फाइल ट्रांसफर प्रोटोकॉल के लिए मूल विनिर्देश अभय भूषन द्वारा लिखा गया था और के रूप में प्रकाशित किया गया था 16 अप्रैल 1971 को। 1980 तक, FTP नेटवर्क कंट्रोल प्रोटोकॉल (ARPANET) पर चलता था, जो इंटरनेट प्रोटोकॉल सूट के पूर्ववर्ती था। TCP/IP। प्रोटोकॉल को बाद में एक टीसीपी/आईपी संस्करण द्वारा बदल दिया गया था,  (जून 1980) और  (अक्टूबर 1985), वर्तमान विनिर्देश। कई प्रस्तावित मानकों में संशोधन, उदाहरण के लिए  (फरवरी 1994) फ़ायरवॉल-फ्रेंडली एफ़टीपी (निष्क्रिय मोड) को सक्षम करता है,  (जून 1997) सुरक्षा विस्तार का प्रस्ताव करता है,  (सितंबर 1998) IPv6 के लिए समर्थन जोड़ता है और एक नए प्रकार के निष्क्रिय मोड को परिभाषित करता है।

संचार और डेटा स्थानांतरण
एफ़टीपी सक्रिय या निष्क्रिय मोड में चल सकता है, जो निर्धारित करता है कि डेटा कनेक्शन कैसे स्थापित किया जाता है। (मोड का यह अर्थ एफ़टीपी प्रोटोकॉल में मोड कमांड से अलग है।) IPv6 का समर्थन करने के लिए सितंबर 1998 में दोनों मोड अपडेट किए गए थे। उस समय पैसिव मोड में और बदलाव किए गए, इसे विस्तारित पैसिव मोड में अपडेट किया गया। सर्वर FTP सर्वर रिटर्न कोड की सूची के साथ नियंत्रण कनेक्शन पर प्रतिक्रिया करता है | ASCII में तीन अंकों की स्थिति कोड एक वैकल्पिक पाठ संदेश के साथ। उदाहरण के लिए, 200 (या 200 OK ) का अर्थ है कि अंतिम आदेश सफल रहा। संख्याएं प्रतिक्रिया के लिए कोड का प्रतिनिधित्व करती हैं और वैकल्पिक पाठ मानव-पठनीय स्पष्टीकरण या अनुरोध का प्रतिनिधित्व करता है (उदाहरण के लिए <फाइल को संग्रहीत करने के लिए खाते की आवश्यकता है>)। नियंत्रण कनेक्शन पर भेजे गए बाधा संदेश का उपयोग करके डेटा कनेक्शन पर फ़ाइल डेटा के चल रहे स्थानांतरण को निरस्त किया जा सकता है।
 * सक्रिय मोड में, क्लाइंट पोर्ट एम पर सर्वर से आने वाले डेटा कनेक्शन के लिए सुनना शुरू कर देता है। यह FTP कमांड पोर्ट एम को सर्वर को सूचित करने के लिए भेजता है कि वह किस पोर्ट पर सुन रहा है। सर्वर तब अपने पोर्ट 20, FTP सर्वर डेटा पोर्ट से क्लाइंट के लिए एक डेटा चैनल शुरू करता है।
 * उन परिस्थितियों में जहां क्लाइंट फ़ायरवॉल (कंप्यूटिंग) के पीछे है और आने वाले टीसीपी कनेक्शन को स्वीकार करने में असमर्थ है, निष्क्रिय मोड का उपयोग किया जा सकता है। इस मोड में, क्लाइंट सर्वर को PASV कमांड भेजने के लिए कंट्रोल कनेक्शन का उपयोग करता है और फिर सर्वर से एक सर्वर आईपी एड्रेस और सर्वर पोर्ट नंबर प्राप्त करता है, जिसके बाद क्लाइंट एक मनमाना क्लाइंट पोर्ट से सर्वर आईपी एड्रेस और सर्वर पोर्ट नंबर प्राप्त करने के लिए डेटा कनेक्शन खोलने के लिए उपयोग करता है।

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

एनएटी और फ़ायरवॉल ट्रैवर्सल
क्लाइंट द्वारा PORT कमांड भेजे जाने के बाद FTP सामान्य रूप से सर्वर को क्लाइंट से वापस कनेक्ट करके डेटा ट्रांसफर करता है। यह नेवोर्क पता अनुवादन और फायरवॉल दोनों के लिए समस्याग्रस्त है, जो इंटरनेट से आंतरिक होस्ट की ओर कनेक्शन की अनुमति नहीं देते हैं। NATs के लिए, एक अतिरिक्त जटिलता यह है कि PORT कमांड में IP पतों और पोर्ट नंबर का प्रतिनिधित्व सार्वजनिक IP पते और NAT के पोर्ट के बजाय आंतरिक होस्ट के IP पते और पोर्ट को संदर्भित करता है।

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

डेटा प्रकार
नेटवर्क पर डेटा स्थानांतरित करते समय, चार डेटा प्रकारों को परिभाषित किया जाता है: * ASCII (टाइप ए): टेक्स्ट के लिए उपयोग किया जाता है। यदि आवश्यक हो, तो भेजने वाले मेजबान के चरित्र प्रतिनिधित्व से विस्तारित ASCII | में डेटा परिवर्तित किया जाता है ट्रांसमिशन से पहले 8-बिट ASCII, और (फिर से, यदि आवश्यक हो) प्राप्त करने वाले मेजबान के चरित्र प्रतिनिधित्व के लिए, नई पंक्ति सहित। परिणामस्वरूप, यह मोड उन फ़ाइलों के लिए अनुपयुक्त है जिनमें ASCII के अलावा अन्य डेटा शामिल है।
 * इमेज (टाइप I, जिसे आमतौर पर बाइनरी डेटा मोड कहा जाता है): भेजने वाली मशीन प्रत्येक फ़ाइल को बाइट द्वारा बाइट भेजती है, और प्राप्तकर्ता इसे प्राप्त करते ही bytstream को स्टोर कर लेता है। (एफ़टीपी के सभी कार्यान्वयनों के लिए छवि मोड समर्थन की सिफारिश की गई है)।
 * EBCDIC (टाइप ई): ईबीसीडीआईसी कैरेक्टर सेट का उपयोग कर मेजबानों के बीच सादे पाठ के लिए प्रयुक्त।
 * स्थानीय (टाइप एल एन): मशीनों के बीच फ़ाइल स्थानांतरण का समर्थन करने के लिए डिज़ाइन किया गया है जो 8-बिट बाइट्स का उपयोग नहीं करते हैं, उदा। 36-बिट कंप्यूटिंग | 36-बिट सिस्टम जैसे DEC PDP-10s। उदाहरण के लिए, TYPE L 9 का उपयोग 9-बिट बाइट में डेटा स्थानांतरित करने के लिए किया जाएगा, या TYPE L 36 का उपयोग 36-बिट शब्दों को स्थानांतरित करने के लिए किया जाएगा। अधिकांश समकालीन FTP क्लाइंट/सर्वर केवल L 8 का समर्थन करते हैं, जो I के समतुल्य है।
 * UTF-8 (TYPE U) का उपयोग करने वाली यूनिकोड टेक्स्ट फ़ाइलें: एक समय सीमा समाप्त इंटरनेट ड्राफ्ट में परिभाषित जो कभी भी RFC नहीं बना, हालाँकि इसे कई FTP क्लाइंट/सर्वर द्वारा लागू किया गया है।

ध्यान दें कि इन डेटा प्रकारों को आमतौर पर मोड कहा जाता है, हालांकि अस्पष्ट रूप से उस शब्द का उपयोग सक्रिय-बनाम-निष्क्रिय संचार मोड (ऊपर देखें), और FTP प्रोटोकॉल मोड कमांड द्वारा निर्धारित मोड (नीचे देखें) के संदर्भ में भी किया जाता है।

पाठ फ़ाइलों (टाइप ए और टाइप ई) के लिए, फ़ाइल को प्रिंट करने के तरीके को नियंत्रित करने के लिए तीन अलग-अलग प्रारूप नियंत्रण विकल्प प्रदान किए जाते हैं: ये प्रारूप मुख्य रूप से लाइन प्रिंटर के लिए प्रासंगिक थे; अधिकांश समकालीन एफ़टीपी ग्राहक/सर्वर केवल एन के डिफ़ॉल्ट प्रारूप नियंत्रण का समर्थन करते हैं।
 * गैर-प्रिंट (टाइप ए एन और टाइप ई एन) - फ़ाइल में प्रिंटर के लिए कोई कैरेज नियंत्रण वर्ण नहीं है
 * टेलनेट (TYPE A T और TYPE E T) - फ़ाइल में टेलनेट (या दूसरे शब्दों में, ASCII C0) कैरेज कंट्रोल कैरेक्टर (CR, LF, आदि) शामिल हैं।
 * एएसए कैरिज नियंत्रण वर्ण (टाइप ए ए और टाइप ईए) - फाइल में एएसए कैरिज कंट्रोल कैरेक्टर हैं

फ़ाइल संरचना
फ़ाइल संगठन को STRU कमांड का उपयोग करके निर्दिष्ट किया गया है। निम्नलिखित फ़ाइल संरचनाएँ RFC959 के खंड 3.1.1 में परिभाषित हैं:
 * एफ या फ़ाइल संरचना (धारा-उन्मुख)। फ़ाइलों को बाइट्स, वर्णों या शब्दों के मनमाने अनुक्रम के रूप में देखा जाता है। यूनिक्स सिस्टम और अन्य सिस्टम जैसे सीपी/एम, एमएस-डॉस और माइक्रोसॉफ्ट विंडोज पर यह सामान्य फ़ाइल संरचना है। (धारा 3.1.1.1)
 * आर या रिकॉर्ड संरचना (रिकॉर्ड-उन्मुख)। फाइलों को रिकॉर्ड में विभाजित के रूप में देखा जाता है, जो निश्चित या परिवर्तनीय लंबाई हो सकती है। यह फाइल संगठन मेनफ्रेम और मिडरेंज सिस्टम पर आम है, जैसे एमवीएस, वीएम/सीएमएस, ओएस/400 और वीएमएस, जो रिकॉर्ड-उन्मुख फ़ाइल सिस्टम सिस्टम का समर्थन करते हैं।
 * पी या पृष्ठ संरचना (पृष्ठ-उन्मुख)। फ़ाइलें पृष्ठों में विभाजित होती हैं, जिनमें या तो डेटा या मेटाडेटा हो सकता है; प्रत्येक पृष्ठ में विभिन्न विशेषताएँ देने वाला एक हेडर भी हो सकता है। यह फ़ाइल संरचना विशेष रूप से टेनेक्स (ऑपरेटिंग सिस्टम) सिस्टम के लिए डिज़ाइन की गई थी, और आमतौर पर अन्य प्लेटफॉर्म पर समर्थित नहीं है। RFC1123 खंड 4.1.2.3 अनुशंसा करता है कि इस संरचना को लागू नहीं किया जाना चाहिए।

अधिकांश समकालीन FTP क्लाइंट और सर्वर केवल STRU F का समर्थन करते हैं। STRU R अभी भी मेनफ्रेम और मिनीकंप्यूटर फ़ाइल स्थानांतरण अनुप्रयोगों में उपयोग में है।

डेटा ट्रांसफर मोड
डेटा ट्रांसफर तीन में से किसी भी मोड में किया जा सकता है: * स्ट्रीम मोड (MODE S): डेटा को एक सतत स्ट्रीम के रूप में भेजा जाता है, जिससे FTP को कोई भी प्रोसेसिंग करने से राहत मिलती है। बल्कि, सभी प्रोसेसिंग को ट्रांसमिशन कंट्रोल प्रोटोकॉल पर छोड़ दिया गया है। जब तक डेटा को रिकॉर्ड (कंप्यूटर साइंस) में विभाजित नहीं किया जाता है, तब तक किसी एंड-ऑफ-फाइल इंडिकेटर की आवश्यकता नहीं होती है।
 * ब्लॉक मोड (मोड बी): मुख्य रूप से रिकॉर्ड-ओरिएंटेड फाइलों (एसटीआरयू आर) को स्थानांतरित करने के लिए डिज़ाइन किया गया है, हालांकि इसका उपयोग स्ट्रीम-ओरिएंटेड (एसटीआरयू एफ) टेक्स्ट फाइलों को स्थानांतरित करने के लिए भी किया जा सकता है। एफ़टीपी डेटा के प्रत्येक रिकॉर्ड (या लाइन) को कई ब्लॉक (ब्लॉक हेडर, बाइट काउंट और डेटा फ़ील्ड) में डालता है और फिर इसे टीसीपी पर भेजता है। * कंप्रेस्ड मोड (MODE C): रन-लेंथ एन्कोडिंग का उपयोग करके डेटा कंप्रेशन के साथ मोड B को बढ़ाता है।

अधिकांश समकालीन एफ़टीपी ग्राहक और सर्वर मोड बी या मोड सी लागू नहीं करते हैं; मेनफ्रेम और मिनीकंप्यूटर ऑपरेटिंग सिस्टम के लिए FTP क्लाइंट और सर्वर इसके अपवाद हैं।

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

अतिरिक्त आदेश
एफ़टीपी के अधिक हालिया कार्यान्वयन संशोधित तथ्य का समर्थन करते हैं: संशोधन समय (एमएफएमटी) कमांड, जो क्लाइंट को फ़ाइल अपलोड करते समय उस विशेषता के संरक्षण को सक्षम करने के लिए उस फ़ाइल विशेषता को दूरस्थ रूप से समायोजित करने की अनुमति देता है। दूरस्थ फ़ाइल टाइमस्टैम्प को पुनः प्राप्त करने के लिए, MDTM कमांड है। कुछ सर्वर (और क्लाइंट) दो तर्कों के साथ MDTM कमांड के गैर-मानक सिंटैक्स का समर्थन करते हैं, जो MFMT की तरह ही काम करता है

लॉगिन
एफ़टीपी लॉगिन पहुँच प्रदान करने के लिए सामान्य उपयोगकर्ता नाम और पासवर्ड योजना का उपयोग करता है। उपयोगकर्ता नाम USER कमांड का उपयोग करके सर्वर को भेजा जाता है, और PASS कमांड का उपयोग करके पासवर्ड भेजा जाता है। यह अनुक्रम तार पर अनएन्क्रिप्टेड है, इसलिए नेटवर्क स्नीफिंग हमले के लिए असुरक्षित हो सकता है। यदि क्लाइंट द्वारा प्रदान की गई जानकारी सर्वर द्वारा स्वीकार कर ली जाती है, तो सर्वर क्लाइंट को ग्रीटिंग भेजेगा और सत्र शुरू हो जाएगा। यदि सर्वर इसका समर्थन करता है, तो उपयोगकर्ता लॉगिन प्रमाणिकता प्रदान किए बिना लॉग इन कर सकते हैं, लेकिन वही सर्वर ऐसे सत्रों के लिए केवल सीमित पहुंच को अधिकृत कर सकता है।

अनाम एफ़टीपी
एक होस्ट जो एफ़टीपी सेवा प्रदान करता है, गुमनामी एफ़टीपी एक्सेस प्रदान कर सकता है। उपयोगकर्ता नाम के लिए संकेत दिए जाने पर उपयोगकर्ता आमतौर पर 'अनाम' (कुछ एफ़टीपी सर्वरों में लोअर-केस और केस-संवेदी) खाते के साथ सेवा में लॉग इन करते हैं। हालांकि उपयोगकर्ताओं को आमतौर पर पासवर्ड के बजाय अपना ईमेल पता भेजने के लिए कहा जाता है, आपूर्ति किए गए डेटा पर वास्तव में कोई सत्यापन नहीं किया जाता है। कई एफ़टीपी होस्ट जिनका उद्देश्य सॉफ़्टवेयर अपडेट प्रदान करना है, अनाम लॉगिन की अनुमति देंगे।

HTTP
से अंतर हाइपरटेक्स्ट ट्रांसफ़र प्रोटोकॉल अनिवार्य रूप से एफ़टीपी में उन बगों को ठीक करता है जो वेब पेजों में सामान्य रूप से कई छोटे अस्थायी स्थानांतरणों के लिए उपयोग करने में असुविधाजनक बनाते हैं।

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

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

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

वेब ब्राउज़र
अधिकांश सामान्य वेब ब्राउज़र FTP सर्वर पर होस्ट की गई फ़ाइलों को पुनः प्राप्त कर सकते हैं, हालाँकि वे FTPS जैसे प्रोटोकॉल एक्सटेंशन का समर्थन नहीं कर सकते हैं। जब एक HTTP—URL के बजाय एक FTP—की आपूर्ति की जाती है, तो दूरस्थ सर्वर पर पहुंच योग्य सामग्री को अन्य वेब सामग्री के लिए उपयोग किए जाने वाले तरीके के समान प्रस्तुत किया जाता है। FireFTP एक ब्राउज़र एक्सटेंशन है जिसे एक पूर्ण विशेषताओं वाले FTP क्लाइंट के रूप में डिज़ाइन किया गया है, इसे अतीत में फ़ायर्फ़ॉक्स के भीतर चलाया जा सकता था, लेकिन अब यह वाटरफॉक्स के साथ काम करने की सलाह देता है।

Google क्रोम ने क्रोम 88 में पूरी तरह से एफ़टीपी समर्थन हटा दिया। 2019 तक, मोज़िला प्रस्तावों पर चर्चा कर रहा था, जिसमें केवल पुराने एफ़टीपी कार्यान्वयन के लिए समर्थन को हटाना शामिल था जो अब उनके कोड को सरल बनाने के लिए उपयोग में नहीं हैं। अप्रैल, 2021 में, मोज़िला ने फ़ायरफ़ॉक्स 88.0 जारी किया, जिसने डिफ़ॉल्ट रूप से एफ़टीपी समर्थन को अक्षम कर दिया। जुलाई 2021 में, Firefox 90 ने FTP समर्थन पूरी तरह से बंद कर दिया।

सिंटेक्स
FTP URL सिंटैक्स में वर्णित है, रूप लेना:  (ब्रैकेट वाले हिस्से वैकल्पिक हैं)।

उदाहरण के लिए, URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt सर्वर public.ftp-server पर निर्देशिका mydirectory से फ़ाइल myfile.txt का प्रतिनिधित्व करता है। example.com एक एफ़टीपी संसाधन के रूप में। URL ftp://user001:secretpassword@pStreet.ftp-servers.example.com/mydirectory/myfile.txt उपयोगकर्ता नाम और पासवर्ड का एक विनिर्देश जोड़ता है जिसका उपयोग इस संसाधन तक पहुंचने के लिए किया जाना चाहिए।

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

कुछ भिन्नताएं मौजूद हैं कि विभिन्न ब्राउज़र उन मामलों में पथ समाधान का इलाज कैसे करते हैं जहां उपयोगकर्ता के लिए गैर-रूट होम निर्देशिका है।

डाउनलोड प्रबंधक
अधिकांश सामान्य डाउनलोड प्रबंधक एफ़टीपी सर्वरों पर होस्ट की गई फ़ाइलों को प्राप्त कर सकते हैं, जबकि उनमें से कुछ एफ़टीपी सर्वरों पर होस्ट की गई फ़ाइलों को पुनः प्राप्त करने के लिए इंटरफ़ेस भी प्रदान करते हैं। DownloadStudio न केवल FTP सर्वर से फाइल अधःभारण प्रबंधक की अनुमति देता है बल्कि FTP सर्वर पर फाइलों की सूची भी देखता है।

अन्य
लिब्रे ऑफिस एफ़टीपी सर्वर से फ़ाइल खोलने का समर्थन करता है, लेकिन 7.4 रिलीज़ से, इस सुविधा को बहिष्कृत कर दिया गया है, और डेवलपर्स इसे भविष्य के संस्करण में हटाने का इरादा रखते हैं।

सुरक्षा
एफ़टीपी को एक सुरक्षित प्रोटोकॉल के रूप में डिज़ाइन नहीं किया गया था, और इसमें कई सुरक्षा कमजोरियाँ हैं। मई 1999 में, के लेखक निम्नलिखित समस्याओं के लिए एक भेद्यता सूचीबद्ध:
 * पशु बल का आक्रमण
 * एफ़टीपी उछाल हमला
 * पैकेट कैप्चर
 * पोर्ट चोरी (अगले खुले पोर्ट का अनुमान लगाना और वैध कनेक्शन को हड़पना)
 * स्पूफिंग हमला
 * उपयोगकर्ता नाम गणना
 * सर्विस अटैक से इनकार

एफ़टीपी अपने ट्रैफ़िक को एन्क्रिप्ट नहीं करता है; सभी प्रसारण स्पष्ट पाठ में हैं, और उपयोगकर्ता नाम, पासवर्ड, आदेश और डेटा नेटवर्क पर पैकेट कैप्चर (पैकेट विश्लेषक) करने में सक्षम किसी के द्वारा पढ़ा जा सकता है। यह समस्या कई इंटरनेट प्रोटोकॉल विनिर्देशों (जैसे एसएमटीपी, टेलनेट, पोस्ट ऑफिस प्रोटोकॉल और इंटरनेट संदेश एक्सेस प्रोटोकॉल) के लिए आम है, जिन्हें परिवहन परत सुरक्षा या एसएसएल जैसे एन्क्रिप्शन तंत्र के निर्माण से पहले डिजाइन किया गया था।

इस समस्या के सामान्य समाधानों में शामिल हैं:
 * 1) असुरक्षित प्रोटोकॉल के सुरक्षित संस्करणों का उपयोग करना, उदाहरण के लिए, FTP के बजाय FTPS और Telnet के बजाय TelnetS।
 * 2) एक अलग, अधिक सुरक्षित प्रोटोकॉल का उपयोग करना जो कार्य को संभाल सकता है, उदा। SSH फाइल ट्रांसफर प्रोटोकॉल या सुरक्षित कॉपी प्रोटोकॉल।
 * 3) सुरक्षित खोल (एसएसएच) या वर्चुअल प्राइवेट नेटवर्क (वीपीएन) जैसी सुरक्षित सुरंग का उपयोग करना।

एसएसएच पर एफ़टीपी
एसएसएच पर एफ़टीपी एक सामान्य एफ़टीपी सत्र को एक सुरक्षित शेल कनेक्शन पर सुरंग बनाने का अभ्यास है। क्योंकि एफ़टीपी कई ट्रांसमिशन कंट्रोल प्रोटोकॉल कनेक्शन (एक टीसीपी / आईपी प्रोटोकॉल के लिए असामान्य है जो अभी भी उपयोग में है) का उपयोग करता है, एसएसएच पर सुरंग बनाना विशेष रूप से कठिन है। कई एसएसएच ग्राहकों के साथ, नियंत्रण चैनल के लिए एक सुरंग स्थापित करने का प्रयास (पोर्ट 21 पर प्रारंभिक क्लाइंट-टू-सर्वर कनेक्शन) केवल उस चैनल की रक्षा करेगा; जब डेटा स्थानांतरित किया जाता है, तो एफ़टीपी सॉफ्टवेयर या तो नए टीसीपी कनेक्शन (डेटा चैनल) सेट करता है और इस प्रकार कोई गोपनीयता या अखंडता सुरक्षा नहीं होती है।

अन्यथा, SSH क्लाइंट सॉफ़्टवेयर के लिए FTP प्रोटोकॉल का विशिष्ट ज्ञान होना, FTP नियंत्रण चैनल संदेशों की निगरानी और पुनर्लेखन करना और FTP डेटा चैनलों के लिए नए पैकेट अग्रेषण को स्वायत्त रूप से खोलना आवश्यक है। इस मोड का समर्थन करने वाले सॉफ़्टवेयर पैकेज में शामिल हैं:
 * टेक्टिया कनेक्टसिक्योर (विन/लिनक्स/यूनिक्स) SSH संचार सुरक्षा सॉफ़्टवेयर सुइट का

एफटीपीएस
स्पष्ट एफटीपीएस एफ़टीपी मानक का एक विस्तार है जो ग्राहकों को एफ़टीपी सत्रों को एन्क्रिप्ट करने का अनुरोध करने की अनुमति देता है। यह AUTH TLS कमांड भेजकर किया जाता है। सर्वर के पास उन कनेक्शनों को अनुमति देने या अस्वीकार करने का विकल्प होता है जो टीएलएस का अनुरोध नहीं करते हैं। यह प्रोटोकॉल एक्सटेंशन में परिभाषित किया गया है. निहित एफटीपीएस एफ़टीपी के लिए एक पुराना मानक है जिसके लिए एसएसएल या टीएलएस कनेक्शन के उपयोग की आवश्यकता होती है। यह सादा एफ़टीपी की तुलना में विभिन्न बंदरगाहों का उपयोग करने के लिए निर्दिष्ट किया गया था।

SSH फाइल ट्रांसफर प्रोटोकॉल
SSH फ़ाइल स्थानांतरण प्रोटोकॉल (कालानुक्रमिक रूप से दो प्रोटोकॉल संक्षिप्त SFTP में से दूसरा) फ़ाइलों को स्थानांतरित करता है और उपयोगकर्ताओं के लिए एक समान कमांड सेट करता है, लेकिन फ़ाइलों को स्थानांतरित करने के लिए सिक्योर शेल प्रोटोकॉल (SSH) का उपयोग करता है। एफ़टीपी के विपरीत, यह कमांड और डेटा दोनों को एन्क्रिप्ट करता है, पासवर्ड और संवेदनशील जानकारी को नेटवर्क पर खुले तौर पर प्रसारित होने से रोकता है। यह FTP सॉफ़्टवेयर के साथ इंटरऑपरेट नहीं कर सकता है, हालाँकि कुछ FTP क्लाइंट सॉफ़्टवेयर SSH फ़ाइल स्थानांतरण प्रोटोकॉल के लिए भी समर्थन प्रदान करते हैं।

तुच्छ फ़ाइल स्थानांतरण प्रोटोकॉल
ट्रिवियल फाइल ट्रांसफर प्रोटोकॉल (TFTP) एक सरल, लॉक-स्टेप FTP है जो क्लाइंट को एक फ़ाइल प्राप्त करने या एक फ़ाइल को दूरस्थ होस्ट पर रखने की अनुमति देता है। इसका एक प्राथमिक उपयोग नेटवर्क बूटिंग के शुरुआती चरणों में है, क्योंकि TFTP को लागू करना बहुत आसान है। TFTP में सुरक्षा का अभाव है और अधिक मजबूत फ़ाइल स्थानांतरण प्रोटोकॉल जैसे फ़ाइल स्थानांतरण प्रोटोकॉल द्वारा प्रदान की जाने वाली अधिकांश उन्नत सुविधाएँ। TFTP को पहली बार 1981 में मानकीकृत किया गया था और प्रोटोकॉल के लिए वर्तमान विनिर्देश में पाया जा सकता है.

सरल फ़ाइल स्थानांतरण प्रोटोकॉल
सिंपल फाइल ट्रांसफर प्रोटोकॉल (पहला प्रोटोकॉल संक्षिप्त एसएफटीपी), जैसा कि परिभाषित किया गया है, TFTP और FTP के बीच जटिलता मध्यवर्ती स्तर के साथ एक (असुरक्षित) फ़ाइल स्थानांतरण प्रोटोकॉल के रूप में प्रस्तावित किया गया था। इसे इंटरनेट पर कभी भी व्यापक रूप से स्वीकार नहीं किया गया था, और अब इसे इंटरनेट इंजीनियरिंग टास्क फोर्स द्वारा ऐतिहासिक दर्जा दिया गया है। यह पोर्ट 115 के माध्यम से चलता है, और अक्सर SFTP का आद्याक्षर प्राप्त करता है। इसमें 11 कमांड का कमांड सेट है और तीन प्रकार के डेटा ट्रांसमिशन का समर्थन करता है: एएससीआईआई, बाइनरी फ़ाइल और निरंतर। एक शब्द आकार वाले सिस्टम के लिए जो कि 8 बिट्स का गुणक है, बाइनरी और निरंतर का कार्यान्वयन समान है। प्रोटोकॉल उपयोगकर्ता आईडी और पासवर्ड, पदानुक्रमित फ़ोल्डर और फ़ाइल प्रबंधन (नाम बदलने, हटाने, अपलोड करने, डाउनलोड करने, अधिलेखित करने के साथ डाउनलोड करने और संलग्न के साथ डाउनलोड करने सहित) के साथ लॉगिन का भी समर्थन करता है।

एफ़टीपी उत्तर कोड
नीचे एफ़टीपी सर्वर रिटर्न कोड की सूची का सारांश दिया गया है जो एफ़टीपी सर्वर (कंप्यूटिंग) द्वारा वापस किया जा सकता है। इन कोडों को मानकीकृत किया गया है आईईटीएफ द्वारा। उत्तर कोड तीन अंकों का मान है। पहले अंक का उपयोग तीन संभावित परिणामों में से एक को इंगित करने के लिए किया जाता है — सफलता, विफलता, या किसी त्रुटि या अपूर्ण उत्तर को इंगित करने के लिए:
 * 2yz – सफलता का उत्तर
 * 4yz या 5yz - विफल उत्तर
 * 1yz या 3yz - त्रुटि या अधूरा उत्तर

दूसरा अंक त्रुटि के प्रकार को परिभाषित करता है:
 * x0z - सिंटेक्स। ये उत्तर सिंटैक्स त्रुटियों को संदर्भित करते हैं।
 * x1z - सूचना। सूचना के अनुरोधों के उत्तर।
 * x2z - कनेक्शन। नियंत्रण और डेटा कनेक्शन के संदर्भ में उत्तर।
 * x3z - प्रमाणीकरण और लेखा। लॉगिन प्रक्रिया और लेखा प्रक्रियाओं के लिए उत्तर।
 * x4z - परिभाषित नहीं।
 * x5z - फाइल सिस्टम। ये सर्वर फाइल सिस्टम से रिले स्टेटस कोड का जवाब देते हैं।

उत्तर कोड के तीसरे अंक का उपयोग दूसरे अंक द्वारा परिभाषित प्रत्येक श्रेणी के लिए अतिरिक्त विवरण प्रदान करने के लिए किया जाता है।

यह भी देखें
• Comparison of FTP client software

• Comparison of FTP server software packages

• Comparison of file transfer protocols

• Curl-loader – FTP/S loading/testing open-source software

• File eXchange Protocol (FXP)

• File Service Protocol (FSP)

• FTAM

• FTPFS

• List of FTP commands

• List of FTP server return codes

• Managed File Transfer

• OBEX

• Shared file access

• TCP Wrapper

अग्रिम पठन

 * – CWD Command of FTP. July 1975.
 * – (Standard) File Transfer Protocol (FTP). J. Postel, J. Reynolds. October 1985.
 * – (Informational) Firewall-Friendly FTP. February 1994.
 * – (Informational) How to Use Anonymous FTP. May 1994.
 * – FTP Operation Over Big Address Records (FOOBAR). June 1994.
 * – Uniform Resource Locators (URL). December 1994.
 * – (Proposed Standard) FTP Security Extensions. October 1997.
 * – (Proposed Standard) Feature negotiation mechanism for the File Transfer Protocol. August 1998.
 * – (Proposed Standard) Extensions for IPv6, NAT, and Extended passive mode. September 1998.
 * – (Informational) FTP Security Considerations. May 1999.
 * – (Proposed Standard) Internationalization of the File Transfer Protocol. July 1999.
 * – (Proposed Standard) Extensions to FTP. P. Hethmon. March 2007.
 * – (Proposed Standard) FTP Command and Extension Registry. March 2010.
 * – (Proposed Standard) File Transfer Protocol HOST Command for Virtual Hosts. March 2014.
 * IANA FTP Commands and Extensions registry – The official registry of FTP Commands and Extensions

इस पेज में लापता आंतरिक लिंक की सूची

 * एचटीएमएल संपादक
 * एफ़टीपी सर्वर रिटर्न कोड की सूची
 * सिम्पलेक्स संचार
 * टीसीपी और यूडीपी पोर्ट नंबरों की सूची
 * रिकॉर्ड (कंप्यूटर विज्ञान)
 * हवा निकालना
 * सूँघने का हमला
 * अखंडता संरक्षण
 * एसएसएच संचार सुरक्षा
 * शब्द का आकार

बाहरी संबंध

 * [//servertest.online/ftp FTP Server Online Tester] Authentication, encryption, mode and connectivity.
 * Anonymous FTP Servers by Country Code TLD (2012):
 * Anonymous FTP Servers by Country Code TLD (2012):