SSTP भित्रको TCP: पुनःप्रसारण दुई पटक किन हुन्छ

मुखको कुरो प्रोटोकलभन्दा अगाडि आउँछ। वरपर सोध्नुहोस् र SSTP ढिलो हो, कुनै कुराले बाध्य नगरेसम्म तपाईंले बच्ने विकल्प। त्यो प्रतिष्ठाले एकै प्रकारको मार्गमा एउटै असफलता मोडको वर्णन गर्छ।

संयन्त्र वास्तविक छ। यो सशर्त पनि छ, जसको उल्लेख प्रतिष्ठाले कहिल्यै गर्दैन।

एउटै मार्गमा दुई भरपर्दो स्ट्रिम

SSTP आफ्नो सुरुङलाई HTTPS सत्रभित्र बेर्छ। HTTPS TCP माथि चल्छ, र त्यो बाह्य स्ट्रिमले क्रमबद्ध डेलिभरीको ग्यारेन्टी गर्छ। त्यसैले एउटा हराएको खण्डले आफ्नो पछाडि लाइनमा उभिएको सबैलाई रोक्छ। अन्य आन्तरिक कुराकानीमा पर्ने पछिल्ला बाइटहरू जसरी पनि पर्खन्छन्।

आन्तरिक TCP प्रवाहहरूले आफ्नै क्रम र भिड नियन्त्रण राख्छन्। तिनीहरूले बाह्य पुनःप्राप्ति देख्न सक्दैनन्, त्यसैले तिनीहरूले देख्ने एक मात्र कुरा स्तब्धता हो। मार्ग भिडभाडमा छ भनी तिनीहरूलाई भन्ने सङ्केत नै त्यही स्तब्धता हो।

अब दुवै तह एकैसाथ पछाडि हट्छन्। यही नै सम्पूर्ण अन्तरक्रिया हो, र यसलाई सुरु गर्न एउटा हराएको खण्ड नै पर्याप्त छ।

प्रभाव कहाँ देखिन्छ र कहाँ देखिँदैन

सफा मार्गमा बाह्य स्ट्रिमले विरलै केही पुनःप्राप्त गर्छ। अन्तरक्रिया कहिल्यै सक्रिय हुँदैन, र SSTP ले अन्तरक्रियात्मक ट्राफिकलाई पूर्ण रूपमा राम्रोसँग बोक्छ। व्यापक दाबी ठ्याक्कै यही बिन्दुमा असफल हुन्छ।

हानि वा पुनःक्रमण अन्तर्निहित मार्गसम्म पुग्दा प्रभाव देखिन्छ। भिडभाड भएको Wi-Fi लिङ्क वा परिवर्तनशील विलम्बताको मोबाइल जडानले परिस्थिति बनाउँछ। त्यसपछि अवरुद्ध बाह्य लाइन सुरुङभित्र देखिने ढिलाइमा परिणत हुन्छ।

यो कामको भारसँगै बढ्छ। धेरै समानान्तर प्रवाहले लाइन भर्छन् र लाइनको टाउकोमा अवरोध अझ बिगार्छन्। उही मार्गमा एउटा अन्तरक्रियात्मक सत्र स्वीकार्य लाग्न सक्छ।

लक्षण सामान्यतया के होइन

हरेक ढिलो सत्र यो समस्या होइन। पहिलो प्याकेटदेखि स्थिर कम दरले क्षमता, आकार दिने वा सर्भर सीमातर्फ सङ्केत गर्छ। स्थानीय भिडभाडसँग मिल्ने विरामहरू पहुँच लिङ्कमा लाइनतर्फ सङ्केत गर्छन्।

उपाय फरक छन्, त्यसैले निदान पहिले आउँछ। बफर ट्युनिङले आकार दिइएको लिङ्कका लागि केही गर्दैन। प्रोटोकल बदल्नाले क्षमता सकिएको सर्भरका लागि केही गर्दैन। बारम्बार रिसेटले पूर्ण रूपमा अर्कै ठाउँतर्फ सङ्केत गर्छ।

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

समस्या हुँदै गर्दा नै मापन गर्नुहोस्। स्वस्थ मिनेटमा लिइएको क्याप्चरले खराब मिनेटमा चल्ने लूपबारे केही पनि प्रमाणित गर्दैन।

भरपर्दो तुलना

यदि साँच्चै अर्को यातायात उपलब्ध छ भने, नियन्त्रित अवस्थामा तुलना गर्नुहोस्। उही होस्ट, उही सञ्जाल, उही गन्तव्य र उही काम। दुवै रन उही दस मिनेटभित्र हुनुपर्छ, तब मार्गका परिस्थिति मिल्छन्।

पोर्ट बदल्नाले प्रोटोकल बदल्दैन। SSTP क्लाइन्टमा असम्बन्धित प्रोफाइल आयात गर्नाले वैकल्पिक यातायात बन्दैन। सर्भरले दोस्रो विकल्प दिँदा मात्र तुलनाको अर्थ हुन्छ।

TLS प्रमाणीकरण सधैं सक्रिय राख्नुहोस्। कार्यसम्पादनको काम प्रमाणित नगरिएको प्रमाणपत्र स्वीकार गर्ने कारण होइन। यदि स्तब्धता मुख्यतः अपलिङ्क भरिएको बेला देखिन्छ भने, तहहरूलाई दोष दिनुअघि लाइनहरू हेर्नुहोस्।