उबदार HTTPS विरुद्ध उबदार VPN: तोच विनंती मार्ग तुलना करा

HTTPS प्रत्येक API विनंतीसाठी नवीन TCP कनेक्शन आणि नवीन TLS हँडशेक उघडते, म्हणून एक तास उघडे राहणारे टनेल स्वस्त वाटते असे तुम्ही वाचले असेल। त्याचा पहिला अर्धा भाग सहसा खोटा असतो। समर्थित क्लायंट अनेक देवघेवीसाठी प्रस्थापित कनेक्शन पुन्हा वापरतो, आणि प्रत्येक कॉलला नवीन क्लायंट बनवणारे मापन जीवनचक्र मोजते, संरक्षण नाही। या पानाचा उर्वरित भाग त्याऐवजी काय मोजावे याबद्दल आहे।

पुनर्वापर प्रत्यक्षात काय मागतो

टिकाऊपणा HTTP मॉडेलचा भाग आहे, युक्ती नाही: एक कनेक्शन अनेक विनंती-प्रतिसाद देवघेवी वाहते। दोन्हीपैकी कोणताही पक्ष ते बंद करतो तेव्हा, सर्व्हर निष्क्रिय किंवा जास्त भार असलेले कनेक्शन बाजूला करतो तेव्हा, किंवा हेडर किंवा प्रोटोकॉल नियम कनेक्शन पुन्हा वापरता येणार नाही असे सांगतो तेव्हा कनेक्शन संपते। HTTPS तो संवाद प्रत्येक देवघेवीसाठी नवीन हँडशेक न मागता TLSच्या आत ठेवते। म्हणून दुसरी विनंती पहिल्या विनंतीचा हँडशेक पुनरावृत्त करत नाही, जर दरम्यान कशाने कनेक्शन संपवले नसेल तर।

पुन्हा वापराला एक अटही आहे जी अनुप्रयोग सहज मोडतात। कनेक्शन पुन्हा वापरण्याचा विचार करणाऱ्या क्लायंटला प्रतिसादाचे संपूर्ण शरीर वाचावे लागते, आणि अर्ध्यावर सोडलेला प्रतिसाद हा कनेक्शन पूल कोणाच्याही लक्षात न येता गायब होण्याचा नेहमीचा मार्ग आहे।

लायब्ररीचा समर्थित क्लायंट आणि कनेक्शन पूलचे जीवनचक्र तपासा, पूल सुरू किंवा बंद आहे असे गृहीत धरू नका। मान्य झालेली HTTP आवृत्तीही नोंदवा, कारण HTTP/2 आणि HTTP/3 कनेक्शन पुनर्वापर HTTP/1.1पेक्षा वेगळ्या पद्धतीने हाताळतात। मान्य आवृत्तीला मापनाचा भाग माना, तळटीप नाही।

तुलना जीवनचक्र का मोजते

प्रत्येक क्रियेसाठी नवीन क्लायंट बनवणे आणि त्याची एक तासापासून जोडलेल्या टनेलशी तुलना करणे कनेक्शन प्रस्थापनेची तुलना स्थिर स्थितीशी करते। हे वैध मापन आहे, आणि हे HTTPS विरुद्ध VPN नाही। एकाच क्लायंट संरचनेचे दोन रन एकापेक्षा वर्तन अधिक चांगल्या प्रकारे वर्णन करतात, विशेषतः जेव्हा पहिला रन एखादा रिझॉल्व्हर किंवा कनेक्शन कॅश गरम करतो।

API क्रिया, सर्व्हर, खाते आणि डेटा स्थिर ठेवा, अन्यथा तुलना एकापेक्षा जास्त चल वाहते। टाइमर कुठे ठेवाल हे आधीच ठरवा, कारण प्रस्थापना, TLS चर्चा, अनुप्रयोग अंमलबजावणी आणि प्रतिसाद पोहोचवणे एकूणात वेगळे योगदान देतात। पहिल्या विनंतीचा एक टाइमर प्रस्थापनेचे वर्णन करतो आणि तुम्ही प्रत्यक्षात चालवता त्या स्थिर रहदारीबद्दल काहीही सांगत नाही। टाइमरच्या मर्यादा संख्यांच्या शेजारी लिहा।

थंड प्रस्थापना उबदार विनंत्यांपासून वेगळी करा

पहिली विनंती पुढील विनंत्यांपासून वेगळी मोजा। नंतर जोडा जे सेवा प्रत्यक्षात पाहते: निष्क्रिय कालावधी, उसळी, एकाचवेळीपणा, प्रतिसादाचा आकार आणि पुनर्जोडणी।

दोन्ही मार्गांवर प्रमाणपत्र पडताळणी आणि HTTPS सुरू ठेवा, कारण ती काढून टाकल्यास वेगवान नाही तर वेगळी सुरक्षा रचना मोजली जाते। टनेल मार्ग किंवा गेटवेचे स्थान बदलत असेल, तर प्रत्येक वेळ बदल एन्क्रिप्शनवर ढकलण्याऐवजी तो फरक वेगळा नोंदवा, कारण मार्ग, हानी आणि रांग लहान विनंतीवर वर्चस्व गाजवू शकतात। निष्कर्ष काढण्यापूर्वी प्रत्येक मार्ग त्याच मार्गावर दोनदा चालवा। मान्य प्रोटोकॉल आणि टाइमरच्या मर्यादा दोन्ही रनसह नोंदवा।

बंद होणाऱ्या कनेक्शनसाठी योजना करा

टिकाऊ म्हणजे कायमचे नाही। सर्व्हर, प्रॉक्सी किंवा नेटवर्क बदल निष्क्रिय कालावधीत कनेक्शन बंद करू शकतो, आणि क्लायंटला आपल्या लायब्ररीच्या समर्थित वर्तनातून सावरणे लागते। त्या सावरण्यात स्थिती यंत्र आहे: विनंती सर्व्हरवर पूर्ण झाली असेल, किंवा सर्व्हरने ती वाचण्यापूर्वीच अयशस्वी झाली असेल, आणि बंद सॉकेट कॉल करणाऱ्याला काय घडले ते सांगत नाही। त्या स्थितीत बिगर-आयडेंपोटेंट क्रिया केवळ पुन्हा चालवता येत नाही, कारण पुनरावृत्ती अज्ञात निकालाचे दुहेरी लेखन करते। येथे उबदार टनेल आणि उबदार कनेक्शन सारखेच वागतात, कारण काम सुरू असतानाच्या क्षणी दोन्ही अयशस्वी होऊ शकतात।

सॉकेट पुन्हा उघडणाऱ्या लूपऐवजी सेवेची नोंदवलेली पुनर्प्रयत्न किंवा आयडेंपोटेंसी पद्धत वापरा। सावरणे स्पष्टपणे तपासा: निष्क्रिय कनेक्शन बंद करा आणि क्लायंट पुढे काय करतो ते पहा। सॉकेट पुन्हा उघडणे स्थिती बदलणाऱ्या कॉलची पुनरावृत्ती सुरक्षित करत नाही।

आधी मर्यादा निवडा, मग जुळवा

काहीही अनुकूलित करण्यापूर्वी प्रवेश आणि विश्वासाच्या गरजांवरून नेटवर्क मर्यादा निवडा। VPN आपल्या समकक्षांमधील भाग संरक्षित करतो, तर अनुप्रयोगाचे टोक आणि टनेलबाहेरील कोणताही स्पष्ट मजकूर भाग अजूनही महत्त्वाचा आहे। नंतर त्या मर्यादेआत कनेक्शनचे जीवनचक्र जुळवा। स्वस्त टनेलचा निष्कर्ष केवळ प्रत्येक विनंती हँडशेक पुनरावृत्त करते या विश्वासातून येतो, आणि येथे तोच विश्वास तपासला जात आहे।

RFC 9112मधील टिकाऊपणाचा विभाग पुनर्वापर प्रत्यक्षात काय वचन देते याचा संदर्भ आहे, कनेक्शन संपवणाऱ्या अटींसह। त्यांकडे दुर्लक्ष करणाऱ्या मापनावर विश्वास ठेवण्यापूर्वी तो एकदा वाचा।