आपको लगता है कि टीसीपी का उपयोग स्थानांतरण धीमा क्यों करता है? टीसीपी आमतौर पर सभी उपलब्ध बैंडविड्थ का उपयोग करने में सक्षम है। इसके बजाय यूडीपी का उपयोग तेजी से होने की संभावना नहीं है। वास्तव में, यदि आपने एक विश्वसनीय यूडीपी आधारित फ़ाइल स्थानांतरण करने की कोशिश की है, तो संभवतः आप टीसीपी के लिए एक निम्न विकल्प को कार्यान्वित कर सकते हैं - क्योंकि आपको विश्वसनीयता को स्वयं लागू करना होगा।
एफ़टीपी के बारे में समस्याग्रस्त है कि यह आपके द्वारा स्थानांतरित की जाने वाली प्रत्येक फ़ाइल के लिए एकाधिक सिंक्रोनस अनुरोध-प्रतिक्रिया आदेश करता है, और प्रत्येक फ़ाइल के लिए एक नया डेटा कनेक्शन खोलता है। इसका परिणाम बेहद अक्षम स्थानान्तरण में होता है जब बहुत सी छोटी फाइलें स्थानांतरित की जा रही हैं, क्योंकि अधिकांश समय प्रतीक्षा अनुरोध/प्रतिक्रियाओं में खर्च होता है और वास्तव में डेटा स्थानांतरित करने के बजाय डेटा कनेक्शन स्थापित करता है।
इस समस्या को हल करने का एक आसान तरीका फ़ाइलों/फ़ोल्डर्स को संग्रह में पैक करना है। जबकि आप निश्चित रूप से संग्रह कर सकते हैं, इसे एफ़टीपी या इसी तरह का उपयोग करके भेजें, और दूसरी तरफ इसे अनपैक करें, पैकिंग और अनपॅकिंग करने का समय अस्वीकार्य हो सकता है। पैकिंग और ऑनलाइन अनपॅक करके आप इस देरी से बच सकते हैं। मुझे ऐसे किसी भी सॉफ़्टवेयर से अवगत नहीं है जो इस तरह के ऑनलाइन पैकिंग/अनपॅकिंग को एकीकृत करता है। हालांकि, आप बस nc और tar कार्यक्रमों एक पाइप लाइन (लिनक्स, विंडोज पर Cygwin का उपयोग करें) में उपयोग कर सकते हैं:
रिसीवर पर फर्स्ट रन:
nc -l -p 7000 | tar x -C <destination_folder>
यह रिसीवर कर देगा एक कनेक्शन के लिए प्रतीक्षा पोर्ट संख्या 7000 पर फिर इस पर चलने:
cd /some/folder
tar c ./* | nc -q0 <ip_address_of_receiver>:7000
यह इस रिसीवर से कनेक्ट, हस्तांतरण शुरू करने कर देगा। प्रेषक टैर संग्रह बना देगा, इसे रिसीवर को भेज देगा, जो इसे निकाला जाएगा - सभी एक ही समय में। यदि आपको आवश्यकता है, तो आप प्रेषक और रिसीवर की भूमिकाओं को रिवर्स कर सकते हैं (रिसीवर प्रेषक से कनेक्ट करके)।
इस ऑनलाइन-टैर दृष्टिकोण में एफ़टीपी के दो प्रदर्शन मुद्दों में से कोई नहीं है; यह कोई अनुरोध-प्रतिक्रिया आदेश नहीं करता है, और केवल एक ही टीसीपी कनेक्शन का उपयोग करता है।
हालांकि, ध्यान दें कि यह सुरक्षित नहीं है; हमारे प्रेषक से पहले रिसीवर से कोई भी कनेक्ट हो सकता है, उसे अपना टैर आर्काइव भेजें। यदि यह एक मुद्दा है, तो उपयुक्त फ़ायरवॉल नियमों के संयोजन में एक वीपीएन का उपयोग किया जा सकता है।
संपादित: आप टीसीपी प्रदर्शन है, जो एक महत्वपूर्ण समस्या है, FileCatalyst पेज पर विश्वास किया जाए, तो के साथ एक समस्या के रूप में पैकेट क्षति का उल्लेख किया।यह सच है कि टीसीपी उच्च पैकेट नुकसान लिंक के साथ गैर-अनुकूल प्रदर्शन कर सकता है। ऐसा इसलिए है क्योंकि टीसीपी आम तौर पर पैकेट नुकसान के लिए आक्रामक प्रतिक्रिया करता है, क्योंकि यह मानता है कि नुकसान भीड़ के कारण है; Additive_increase/multiplicative_decrease देखें। मुझे किसी भी मुक्त/मुक्त स्रोत फ़ाइल स्थानांतरण कार्यक्रमों से अवगत नहीं है जो कस्टम प्रोटोकॉल के साथ इसे दूर करने का प्रयास करेंगे। हालांकि आप TCP congestion avoidance algorithms अलग-अलग प्रयास कर सकते हैं। विशेष रूप से, Vegas का प्रयास करें, जो ट्रांसमिशन दर को कम करने के लिए सिग्नल के रूप में पैकेट हानि का उपयोग करता है।
क्या आपने मेरे द्वारा शामिल किए गए लिंक देखे? यदि आपके पास स्थानांतरित करने के लिए 500 जीबी फ़ाइल है, तो एफ़टीपी का नियंत्रण कनेक्शन पूरी तरह से नगण्य है, और आप जो भी खत्म करते हैं वह कच्चे टीसीपी प्रदर्शन है। जो कि बड़ी फ़ाइलों के तेज़ी से संभव हस्तांतरण के लिए जरूरी नहीं है - विशेष रूप से किसी भी पैकेट हानि के साथ लिंक पर नहीं। मेरे द्वारा शामिल लिंक में उत्पाद स्पष्ट रूप से विश्वसनीयता को लागू करते हैं। – stolsvik
@stolsvik आपने उच्च नुकसान लिंक का उल्लेख नहीं किया है, जो AFAIK इंटरनेट में दुर्लभ हैं। मैंने इसके बारे में कुछ जोड़ा है। –
वास्तव में टीसीपी प्रोटोकॉल वास्तव में थोक एक तरफ स्थानांतरण के लिए डिज़ाइन नहीं किया गया है। निश्चित रूप से इसे करने के लिए किया जा सकता है, लेकिन टीसीपी को इस तरह से रिटर्न पैकेट की आवश्यकता होती है जो संक्षिप्त स्टालों का कारण बनती है और यह वास्तव में इष्टतम गति के लिए बफर आकार और विंडो आकार चुनने के लिए संतुलित संतुलन हो सकती है। साथ ही, कार्यान्वयन हमेशा ऐसा नहीं कर सकता जो उन्हें वास्तव में विभिन्न वैकल्पिक सेटिंग्स के साथ माना जाता है। –