उपयोगकर्ता क्रियाओं की अनुपस्थिति में दूरस्थ कनेक्शन डिस्कनेक्ट पर काबू पाएं

जीयूआई और टर्मिनल अनुप्रयोगों के साथ काम करते समय, अक्सर ऐसा होता है कि एक उपयोगकर्ता, रिमोट एक्सेस मोड (आमतौर पर इंटरनेट के माध्यम से) में काम करता है, 15 मिनट के लिए कंप्यूटर छोड़ने के बाद, लौटने पर पता चलता है कि प्रोग्राम क्रैश हो गया है। यह निम्नलिखित वाक्यांशों वाले एक त्रुटि के साथ किसी भी कार्रवाई का जवाब देता है: "सर्वर के साथ खोया हुआ कनेक्शन", "[WINSOCK] मेजबान द्वारा वर्चुअल सर्किट रीसेट", आदि। "लंबे समय से चलने वाली" विधियों (सर्वर से अनुरोध) को निष्पादित करते समय यह भी देखा जाता है, जिसमें प्रगति बार या किसी भी अन्तरक्रियाशीलता का आउटपुट प्रदान नहीं किया जाता है।

यह समस्या न केवल जीयूआई और टर्मिनल समाधान के लिए इंटरसिस्टम कैशे और एनसेंबल डीबीएमएस पर आधारित है, बल्कि सामान्य रूप से टीसीपी / आईपी के माध्यम से किसी भी क्लाइंट-सर्वर इंटरैक्शन के लिए विशिष्ट है। आमतौर पर यह एक विशेष प्रकार के खाली संदेशों का समय-समय पर आदान-प्रदान करके आवेदन स्तर पर हल किया जाता है, केवल यह संकेत देने के लिए कि आवेदन "जीवित" है।

नीचे प्रोग्रामिंग के बिना इस समस्या को हल करने का तरीका बताया गया है।

समस्या का स्रोत

समस्या का स्रोत टीसीपी / आईपी प्रोटोकॉल की प्रकृति में है। आमतौर पर, टीसीपी / आईपी सत्र का स्रोत और इसके रिसीवर विभिन्न नेटवर्क पर होते हैं, और सत्र के मार्ग में कई राउटर होते हैं। उनमें से कम से कम एक आम तौर पर NAT पता अनुवाद करता है। राउटर के संसाधन हमेशा सीमित होते हैं, इसलिए उनमें से कुछ मृत सत्रों से NAT तालिकाओं को साफ करते हैं। एक सत्र को "मृत" माना जाता है यदि पैकेट को कुछ निर्दिष्ट समय अंतराल के लिए प्रेषित नहीं किया गया था (चलो इसे सफाई अंतराल कहते हैं)। इस प्रकार, एक "मूक" सत्र को एक "मृत" के लिए गलत किया जा सकता है और NAT तालिका से हटा दिया जा सकता है। इसी समय, न तो स्रोत और न ही रिसीवर को इस बारे में सूचित किया जाता है ("एक शाही मामला नहीं"), और उन दोनों को विश्वास है कि सत्र अभी भी "जीवित" है (जो कि घटना के समय क्लाइंट या सर्वर पर निष्पादित करके नेटस्टैट कमांड के साथ सत्यापित करना आसान है) त्रुटियों, लेकिन ठीक पर क्लिक करने से पहले)। जब उपयोगकर्ता जो त्रुटि संदेश प्राप्त करता है वह ठीक क्लिक करता है, तो ग्राहक सत्र विराम के बारे में सीखेगा; सर्वर की प्रक्रिया समाप्त हो जाएगी जब "मृत" सत्र ओएस को पहचानता है।

यह प्रयोगात्मक रूप से स्थापित किया गया है कि कई राउटरों के लिए सफाई अंतराल (कम से कम फ्लैशेड लिनक्स 2.4 / आईपीटीवी के साथ) लगभग 10 मिनट है। हम अपने टीसीपी सत्र को स्वचालित रूप से एक सक्रिय स्थिति में बनाए रखने की कोशिश करेंगे, तब भी जब कोई डेटा पैकेट प्रेषित नहीं होता है।

प्रस्तावित समाधान

ओएस स्तर पर, टूटे टीसीपी कनेक्शन का पता निम्न कर्नेल मापदंडों द्वारा नियंत्रित किया जाता है जो tcp_keepalive तंत्र के संचालन को नियंत्रित करते हैं [1] :
• tcp_keepalive_time - डेटा के साथ अंतिम पैकेट भेजने के क्षण से समय अंतराल; इस अवधि के बाद, कनेक्शन को सत्यापन की आवश्यकता के रूप में चिह्नित किया गया है; चेक की शुरुआत के बाद, पैरामीटर का उपयोग नहीं किया जाता है;
• tcp_keepalive_intvl - परीक्षण पैकेट के बीच अंतराल (भेजने के बाद जो tcp_keepalive_time समाप्त हो जाता है);
• tcp_keepalive_probes - अनजाने परीक्षण पैकेट की संख्या; इस काउंटर का उपयोग करने के बाद, कनेक्शन टूटा हुआ माना जाता है।

मुझे कहना होगा कि tcp_keepalive तंत्र का एक दोहरा उद्देश्य है: इसका उपयोग यौगिक की गतिविधि को कृत्रिम रूप से बनाए रखने और टूटे हुए (तथाकथित "आधे-खुले") यौगिकों का पता लगाने के लिए किया जा सकता है। यह लेख मुख्य रूप से पहले आवेदन पर चर्चा करता है, दूसरा आवेदन, शायद, इस विषय पर अगले लेख में चर्चा की जाएगी।

टीसीपी कनेक्शन के लिए tcp_keepalive तंत्र को सक्षम करने के लिए, दो शर्तें आवश्यक हैं:
• ओएस स्तर का समर्थन; सौभाग्य से, यह विंडोज और लिनक्स दोनों पर उपलब्ध है;
• कनेक्शन के एक छोर पर सॉकेट SO_KEEPALIVE पैरामीटर के साथ खुला होना चाहिए। जैसा कि यह निकला, कैच सेवाएँ इस पैरामीटर के साथ सॉकेट खोलती हैं, और ओपनएसएसएच सेवा भी ऐसा करना आसान है।

पहला पैरामीटर ( tcp_keepalive_time ) हमारे लिए सबसे अधिक रुचि वाला है, क्योंकि यह इस पर निर्भर करता है कि कितनी बार निष्क्रिय कनेक्शन की जाँच की जाएगी (यातायात की कमी के दृष्टिकोण से)। विंडोज और लिनक्स दोनों में इसका डिफ़ॉल्ट मान दो घंटे (7200 सेकेंड) है। निष्क्रियता का विशिष्ट समय, जिसके बाद एक विराम होता है, लगभग 10 मिनट होता है। इसलिए, पैरामीटर मान को 5 मिनट पर सेट करने का प्रस्ताव है, जो नेटवर्क को अत्यधिक ट्रैफ़िक के साथ लोड किए बिना टीसीपी सत्रों की गतिविधि को बनाए रखने की अनुमति देगा (5 मिनट 5 सेकंड नहीं है)।

Windows सर्वर पर tcp_keepalive विकल्प सेट करना

आपके पास सर्वर का प्रशासक अधिकार होना चाहिए। रजिस्ट्री कुंजी में
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters
300000 (दशमलव) के मान के साथ KeepAliveTime नामक एक DWORD पैरामीटर बनाएं। पैरामीटर मिलीसेकंड में सेट है, इसलिए प्रस्तावित मूल्य 5 मिनट है। फिर कैच को रोकें और सर्वर को रिबूट करें।

दो अन्य tcp_keepalive मापदंडों के लिए, विंडोज में उनकी चूक निम्नानुसार हैं:

KeepAliveInterval
कुंजी: Tcpip \ Parameters
मान प्रकार: REG_DWORD - मिलीसेकंड में समय
वैध सीमा: 0–0xFFFFFFFE
डिफ़ॉल्ट: 1000 (1 सेकंड)

KeepAliveProbes
ऐसा पैरामीटर (अपुष्ट परीक्षण पैकेट की संख्या निर्धारित करना) रजिस्ट्री में मौजूद नहीं है। [२] के अनुसार, विंडोज २००० / XP / २००३ में, TcpMaxDataRetransmission पैरामीटर (डिफ़ॉल्ट ५) का मान इस गुणवत्ता में उपयोग किया जाता है, और बाद के संस्करणों में [३] - १० का निश्चित मान। इसलिए, यदि केवल पहले पैरामीटर का मान बदल गया है (के साथ) 7200 से 300), दूसरे के लिए डिफ़ॉल्ट रखते हुए, विंडोज 2008 सर्वर 1 * 10 + 300 = 310 सेकंड के बाद टीसीपी कनेक्शन के वियोग के बारे में सीखेगा।

लिनक्स सर्वर पर tcp_keepalive विकल्प सेट करना

आप सर्वर को पुनरारंभ किए बिना चलते-फिरते पैरामीटर मान बदल सकते हैं। रूट के रूप में लॉग इन करें और चलाएं:

echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time 

संभव सर्वर रिबूट के संबंध में परिवर्तन को टिकाऊ बनाने के लिए, कर्नेल पैरामीटर फ़ाइल /etc/sysctl.conf को संपादित करने का सबसे आसान तरीका है, इसमें एक पंक्ति जोड़ना (दो बेहतर हैं):

 # help to prevent disconnects net.ipv4.tcp_keepalive_time = 300 

कृपया ध्यान दें कि विंडोज के विपरीत, पैरामीटर मान सेकंड में सेट है।
अन्य दो tcp_keepalive मापदंडों के लिए, लिनक्स में उनकी चूक निम्नानुसार हैं:

 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 

यदि आप केवल पहले पैरामीटर (7200 से 300 तक) के मूल्य को बदलते हैं, तो अन्य दो के लिए डिफॉल्ट को संरक्षित करते हुए, लिनक्स सर्वर केवल 75 * 9 + 300 = 975 सेकंड के बाद वियोग के बारे में सीखेंगे।

Caché DBMS कॉन्फ़िगरेशन में TCPKeepAlive पैरामीटर सेट करना

संस्करण 2008.2 के साथ शुरू, विंडोज और लिनक्स प्लेटफार्मों के लिए कैच में सॉकेट स्तर पर tcp_keepalive_time सेट करने का अवसर है, जो सुविधाजनक है क्योंकि यह आपको ऑपरेटिंग सिस्टम सेटिंग्स को बदलने से बचने की अनुमति देता है। हालांकि, "अपने शुद्ध रूप में" यह सुविधा मुख्य रूप से केवल स्वतंत्र सॉकेट सर्वर डेवलपर्स के लिए ब्याज की है। सौभाग्य से, इसे [SQL] अनुभाग में TCPKeepAlive = n कॉन्फ़िगरेशन पैरामीटर के साथ पूरक किया गया था, जो सिस्टम प्रबंधन पोर्टल पृष्ठ: कॉन्फ़िगरेशन> सामान्य SQL सेटिंग्स से संपादन योग्य है। डिफ़ॉल्ट मान 300 सेकंड है (डॉक्टर ने जो आदेश दिया है)। पैरामीटर का प्रभाव न केवल एसक्यूएल तक फैलता है, बल्कि, जैसा कि आप अनुमान लगा सकते हैं, किसी भी कनेक्शन को% Service_Bings द्वारा सेवा की गई कैच से। इनमें CacheActiveX.Factory के माध्यम से विशेष रूप से ऑब्जेक्ट एक्सेस शामिल है, इसलिए यदि आपका एप्लिकेशन इस प्रोटोकॉल को परिवहन के रूप में उपयोग कर सकता है, तो इस अवसर को न चूकें।

OpenSSH सर्वर कॉन्फ़िगरेशन में KeepAlive सेटिंग्स सेट करना

यदि आप SSH [4] (शेल मोड में या अपने GUI एप्लिकेशन के लिए परिवहन के रूप में काम करने के लिए) का उपयोग करते हैं, तो ... सबसे अधिक संभावना है, किया गया कर्नेल ट्यूनिंग पर्याप्त होगा, क्योंकि ओपनएसएसएच सेवा (कम से कम 5.x संस्करण में) -Dfault पैरामीटर SO_KEEPALIVE के साथ एक सॉकेट खोलता है।

बस मामले में, आपको कॉन्फ़िगरेशन फ़ाइल / etc / ssh / sshd_config की जांच करनी चाहिए। इसमें लाइन लगाएं

 #TCPKeepAlive yes 

यदि आप पाते हैं, तो आपको कुछ भी करने की आवश्यकता नहीं है, क्योंकि डिफ़ॉल्ट पैरामीटर मान टिप्पणी रूप में प्रदान किए गए हैं।

SSH v.2 प्रोटोकॉल के पास सत्र गतिविधि की निगरानी के वैकल्पिक साधन हैं, उदाहरण के लिए, OpenSSH सेवा सेटिंग्स ClientAliveInterval और ClientAliveCountMax को कॉन्फ़िगर करके।
TCPKeepAlive के विपरीत, इन मापदंडों का उपयोग करना, KeepAlive अनुरोधों को एक सुरक्षित SSH चैनल के माध्यम से भेजा जाता है और प्रतिस्थापित नहीं किया जा सकता है। किसी को यह स्वीकार करना होगा कि वैकल्पिक साधन पारंपरिक TCPKeepAlive तंत्र की तुलना में सुरक्षित हैं, जिसके लिए KeepAlive पैकेट का विश्लेषण करने और DoS के हमलों के आयोजन का खतरा है [5] ।

 ClientAliveInterval 0 

टाइमआउट को सेकंड में सेट करता है, उसके बाद, यदि क्लाइंट से कोई जानकारी नहीं मिलती है, तो sshd उसे एक सुरक्षित चैनल के माध्यम से प्रतिक्रिया अनुरोध भेजता है। डिफ़ॉल्ट मान 0 है, जिसका अर्थ है कि ऐसा अनुरोध क्लाइंट को नहीं भेजा जाएगा।

 ClientAliveCountMax 3 

क्लाइंट को उन अनुरोधों की संख्या निर्धारित करता है जो उन्हें प्रतिक्रिया प्राप्त किए बिना sshd द्वारा भेजे जा सकते हैं। यदि सीमा समाप्त हो जाती है, तो sshd क्लाइंट के साथ डिस्कनेक्ट करता है और सत्र समाप्त करता है। डिफ़ॉल्ट मान है 3. यदि आप ClientAliveInterval पैरामीटर को 60 पर सेट करते हैं, तो ClientAliveCountMax को अपरिवर्तित छोड़ दें, तो गैर-प्रतिसाद देने वाले ssh क्लाइंट लगभग 180 सेकंड के बाद डिस्कनेक्ट हो जाएंगे। इस स्थिति में, TCP KeepAlive तंत्र को सेटिंग द्वारा अक्षम करें

 TCPKeepAlive no 

क्या यह हमेशा काम करता है?

नेटवर्क समस्याओं की श्रेणियां हैं जिनमें वर्णित दृष्टिकोण अप्रभावी हो सकता है।

उनमें से एक तब होता है, जब नेटवर्क सेवाओं की खराब गुणवत्ता के कारण, संचार कम समय के लिए शारीरिक रूप से गायब हो सकता है। यदि सत्र निष्क्रिय है, और क्लाइंट या सर्वर द्वारा एक दूसरे को कुछ भेजने की कोशिश करने से पहले कनेक्शन अस्थायी रूप से खो जाता है और पुनर्स्थापित हो जाता है, तो उनमें से कोई भी कुछ भी "नोटिस" नहीं करता है, और टीसीपी सत्र बच जाता है। समय-समय पर जाँच के मामले में, TCPKeepAlive एक ग्राहक से संपर्क के अस्थायी नुकसान के समय सर्वर से संपर्क करने की संभावना को बढ़ाता है, जिससे टीसीपी कनेक्शन के जबरन डिस्कनेक्ट हो सकते हैं। इस स्थिति में, आप KeepAliveInterval सर्वर को 60-75 सेकंड (यह याद रखते हुए कि विंडोज़ की चूक 1 सेकंड तक) बढ़ाने के लिए 10 की अधिकतम संख्या के साथ प्रयास कर सकते हैं, इस उम्मीद में कि 10 मिनट में कोई भी अस्थायी नेटवर्क समस्या स्वयं हल हो जाएगी। सच है, अगर रिट्रांसमिशन बहुत लंबे समय तक रहता है, तो यह पता चला है कि
KeepAliveTime + (KeepAliveInterval * रिट्रीट की संख्या)> 10 मिनट
तब टीसीपी सत्र, किए गए सभी प्रयासों के बावजूद, "मृत" के लिए गलत हो सकता है और NAT तालिका से साफ किया जा सकता है।

समस्याओं की एक और श्रेणी राउटर और / या संचार चैनलों के अपर्याप्त बैंडविड्थ के साथ जुड़ी हुई है, जब KeepAlive सहित किसी भी पैकेट को भीड़ के दौरान खो दिया जा सकता है। राउटर्स के मामले में, फर्मवेयर को बदलकर कभी-कभी ऐसी समस्याएं हल हो जाती हैं (उदाहरण के लिए, इसने मुझे Acorp ADSL XXXX को हराने में मदद की), या, सबसे खराब स्थिति में, इसे एक अधिक कुशल मॉडल के साथ बदल दिया। "बहुत संकीर्ण" संचार चैनलों के मामले में, उनके पास विस्तार करने के लिए कुछ भी नहीं बचा है।

निष्कर्ष

प्रस्तावित दृष्टिकोण टीसीपी / आईपी सत्रों की गतिविधि को कृत्रिम रूप से बनाए रखने की अनुमति देता है, जो वर्तमान में किसी भी डेटा को विशेष रूप से सिस्टम स्तर पर प्रसारित नहीं करता है, बिना आवेदन कोड में कोई बदलाव किए। आज इसका परीक्षण किया गया है और सफलतापूर्वक CIX में UNIX (Red Hat Enterprise Linux 5 के लिए x86-64) 2010.1.4 (Build 803), Caché for Windows (x86-64) 2010.1.4 (Build 803), साथ ही साथ और अधिक के लिए सफलतापूर्वक उपयोग किया गया है बाद के संस्करण।

यह मान्यता दी जानी चाहिए कि यह प्रभावी ढंग से काम करता है यदि नेटवर्क कनेक्शन शारीरिक रूप से स्थिर है, और निष्क्रिय सत्रों को तोड़ने के अलावा, आपको नेटवर्क की कोई अन्य समस्या नहीं है।

एक आक्रामक वातावरण (रिमोट एक्सेस, वितरित सिस्टम, आदि) में एक एप्लिकेशन को तैनात करते समय, KeepAlive को TCP स्तर पर नहीं, बल्कि उच्च स्तर के सुरक्षित प्रोटोकॉल के स्तर पर लागू करने के बारे में सोचें; SSH एक अच्छा उम्मीदवार है।

साहित्य

[१] फैबियो बुसाटो। टीसीपी की रखवाली HOWTO
[२] विंडोज सर्वर २००३ में सेवा हमलों से इनकार करने के खिलाफ टीसीपी / आईपी स्टैक को सख्त कैसे करें
[३] माइक्रोसॉफ्ट विंडोज विस्टा और विंडोज सर्वर २०० IP के लिए टीसीपी / आईपी रजिस्ट्री मान
[४] सिस्टम मैनुअल (मैन्स) देखने के लिए एक इंटरैक्टिव सिस्टम
[५] ओपनएसएसएच: sshd को स्थापित और कॉन्फ़िगर करना