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 पडताळणी सतत सुरू ठेवा। कार्यक्षमतेचे काम पडताळणी न केलेले प्रमाणपत्र स्वीकारण्याचे कारण नाही। जर स्तब्धता मुख्यतः अपलिंक भरलेली असताना दिसतात, तर स्तरांना दोष देण्यापूर्वी रांगा पहा।