मेरे सहकर्मी का मानना था कि यह भौतिक दूरी के कारण है जबकि मुझे नहीं लगता कि यह मायने रखता है। एक बार जब आप प्रारंभिक हैंडशेक कर चुके होते हैं और डेटा प्रवाह शुरू हो जाता है, तो यह मेरी समझ में नहीं आता है, इससे कोई फर्क नहीं पड़ता कि सर्वर कहाँ स्थित है और परिणाम लगभग समान होना चाहिए। क्या मुझसे कोई चूक हो रही है? यह वास्तव में कैसे काम करता है?
आप दोनों इतिहास के किसी बिंदु पर सही थे, लेकिन आपकी समझ ज्यादातर सही है ... आज :)। आपके मित्र द्वारा दिए गए पुराने उत्तर और आज हमारे पास मौजूद क्षमताओं के बीच कुछ कारक बदल गए हैं।
- टीसीपी विंडो स्केलिंग
- होस्ट बफर ट्यूनिंग
आपके द्वारा देखे गए परिणामों में अंतर इससे प्रभावित हो सकता है:
- पैकेट खो गया
- समानांतर टीसीपी स्थानान्तरण
टीसीपी विंडो स्केलिंग: बैंडविड्थ-देरी प्रभाव
जैसा कि आपके मित्र ने उल्लेख किया है, टीसीपी हेडर में खिड़की के आकार को प्राप्त करने के लिए टीसीपी के पुराने कार्यान्वयन को मूल 16-बिट प्राप्त विंडो द्वारा लागू सीमा से सामना करना पड़ा (रेफरी आरएफसी 793: धारा 3.1 ); RWIN नियंत्रित करता है कि एक एकल टीसीपी सॉकेट में कितने अनजाने डेटा की प्रतीक्षा की जा सकती है। 16-बिट आरडब्ल्यूआईएन उच्च बैंडविड्थ-देरी उत्पादों (और आज के उच्च बैंडविड्थ इंटरनेट कनेक्शनों में से कई 16-बिट मूल्य तक सीमित होंगे) के साथ सीमित इंटरनेट पथ।
उच्च आरटीटी मूल्यों के लिए, यह बहुत बड़ा आरडब्ल्यूआईएन होना सहायक है। उदाहरण के लिए, यदि मलेशिया से अमेरिका तक का आपका मार्ग RTT लगभग 200ms का है, तो मूल TCP RWIN आपको 2.6Mbps तक सीमित कर देगा।
थ्रूपुट अधिकतम = Rcv_Win / RTT
* थ्रूपुट अधिकतम = 65535 * 8 / 0.200 *
थ्रूपुट अधिकतम = 2.6Mbps
RFC 1323 ने इन सीमाओं को पार करने के लिए कुछ "TCP विकल्प" को परिभाषित किया; उन टीसीपी विकल्पों में से एक "विंडो स्केलिंग" है। यह एक स्केल फैक्टर पेश करता है, जो मूल RWIN मूल्य को गुणा करता है, ताकि पूर्ण प्राप्त विंडो मान प्राप्त हो सके; विंडो स्केलिंग विकल्पों का उपयोग करके अधिकतम RWIN की 1073725440 बाइट्स की अनुमति दें। समान गणनाओं को लागू करना:
थ्रूपुट अधिकतम = Rcv_Win / RTT
* थ्रूपुट अधिकतम = 1073725440 * 8 / 0.200 *
थ्रूपुट अधिकतम = 42.96 जीबीपीएस
ध्यान रखें कि स्थानांतरण की अवधि में धीरे-धीरे टीसीपी आरडब्ल्यूआईएन बढ़ाता है, जब तक कि पैकेट का नुकसान एक समस्या नहीं है। उच्च-विलंब कनेक्शन पर वास्तव में बड़ी हस्तांतरण दरों को देखने के लिए, आपको एक बड़ी फ़ाइल (इसलिए टीसीपी के पास विंडो बढ़ाने का समय है) और पैकेट हानि कनेक्शन के लिए समस्या नहीं हो सकती है।
पैकेट खो गया
प्रशांत महासागर में इंटरनेट सर्किट कई बार बहुत भीड़भाड़ हो जाते हैं। मेरा कुछ परिवार ताइवान में रहता है, और हम नियमित रूप से उन मुद्दों पर चलते हैं जब हम उनके साथ Google टॉक का उपयोग करते हैं। जब मैं यूएस से उनकी डीएसएल लाइन पिंग करता हूं, तो मुझे अक्सर 0.5% से अधिक पैकेट का नुकसान होता है; अगर आपको "धीमे" सर्वर से 0.5% हानि जैसा कुछ भी दिखाई दे रहा है, तो यह बहुत आसानी से एकल टीसीपी सॉकेट पर थ्रूपुट को सीमित कर देगा।
समानांतर टीसीपी धाराएँ
FYI करें, कुछ गति परीक्षण वेबसाइटें समानांतर टीसीपी धाराओं का उपयोग थ्रूपुट को बढ़ाने के लिए करती हैं ; यह आपके द्वारा देखे जाने वाले परिणामों को प्रभावित कर सकता है, क्योंकि समानांतर टीसीपी स्ट्रीम नाटकीय रूप से उस स्थिति में वृद्धि करती है जब आपको रास्ते में कुछ पैकेट-नुकसान होता है। मैंने चार समानांतर टीसीपी धाराओं को देखा है जो एक 5Mbps केबल मॉडेम को पूरी तरह से संतृप्त करता है जो 1% निरंतर पैकेट नुकसान से ग्रस्त है। आम तौर पर 1% नुकसान एकल टीसीपी स्ट्रीम के थ्रूपुट को कम करेगा।
बोनस सामग्री: होस्ट बफर ट्यूनिंग
कई पुराने ओएस कार्यान्वयनों में सीमित बफ़र्स के साथ सॉकेट थे; पुराने OS के साथ (Windows 2000 की तरह), इससे कोई फर्क नहीं पड़ा कि टीसीपी ने बड़ी मात्रा में डेटा को इन-फ्लाइट में जाने दिया ... उनके सॉकेट बफ़र्स को बड़े RWIN का लाभ उठाने के लिए तैयार नहीं किया गया था। टीसीपी ट्रांसफर पर उच्च प्रदर्शन को सक्षम करने के लिए बहुत सारे शोध किए गए थे । आधुनिक ऑपरेटिंग सिस्टम (इस उत्तर के लिए, हम विंडोज विस्टा और बाद में "आधुनिक" कह सकते हैं) उनके सॉकेट बफर कार्यान्वयन में बेहतर बफर आवंटन तंत्र शामिल हैं।