.NET में HttpClient के नुकसान

"नुकसान" पर लेखों की एक श्रृंखला जारी रखने से मैं System.Net.HttpClient की उपेक्षा नहीं कर सकता, जो अक्सर अभ्यास में उपयोग किया जाता है, लेकिन इसमें कई गंभीर समस्याएं हैं जो तुरंत दिखाई नहीं दे सकती हैं।

प्रोग्रामिंग में एक काफी सामान्य समस्या यह है कि डेवलपर्स केवल एक विशेष घटक की कार्यक्षमता पर केंद्रित होते हैं, जबकि एक बहुत ही महत्वपूर्ण गैर-कार्यात्मक घटक की अनदेखी करते हैं, जो विफलताओं, सुरक्षा, आदि के मामले में प्रदर्शन, मापनीयता, वसूली में आसानी को प्रभावित कर सकता है। उदाहरण के लिए, एक ही HttpClient प्रतीत होता है कि प्राथमिक घटक है, लेकिन कई सवाल हैं: यह सर्वर के समानांतर कनेक्शन कितना बनाता है, वे कितने समय तक रहते हैं, यह कैसे व्यवहार करेगा यदि DNS नाम जो पहले अलग-अलग आईपी पते पर स्विच किया गया था ? आइए लेख में इन सवालों के जवाब देने की कोशिश करते हैं।

1. कनेक्शन लीक
2. समवर्ती सर्वर कनेक्शन को सीमित करें
3. लंबे समय तक रहने वाले कनेक्शन और डीएनएस कैशिंग

HttpClient के साथ पहली समस्या गैर-स्पष्ट कनेक्शन रिसाव है । काफी बार, मुझे उस कोड को पूरा करना पड़ा जहां यह प्रत्येक अनुरोध को निष्पादित करने के लिए बनाया गया है:

public async Task<string> GetSomeText(Guid textId) { using (var client = new HttpClient()) { return await client.GetStringAsync($"http://someservice.com/api/v1/some-text/{textId}"); } } 

दुर्भाग्य से, यह दृष्टिकोण संसाधनों की एक बड़ी बर्बादी और खुले कनेक्शन की सूची के अतिप्रवाह प्राप्त करने की उच्च संभावना की ओर जाता है। समस्या को स्पष्ट रूप से दिखाने के लिए, यह निम्नलिखित कोड निष्पादित करने के लिए पर्याप्त है:

 static void Main(string[] args) { for(int i = 0; i < 10; i++) { using (var client = new HttpClient()) { client.GetStringAsync("https://habr.com").Wait(); } } } 

और अंत में, netstat के माध्यम से खुले कनेक्शन की सूची देखें:

 PS C: \ Development \ व्यायाम> netstat -n |  सेलेक्ट-स्ट्रिंग-स्टाटन "178.248.237.68"

   टीसीपी 192.168.1.13:43684 178.248.237.68-00-0043 TIME_WAIT
   टीसीपी 192.168.1.13:43685 178.248.237.68-00-0043 TIME_WAIT
   टीसीपी 192.168.1.13:43686 178.248.237.68-00-0043 TIME_WAIT
   टीसीपी 192.168.1.13:43687 178.248.237.68-00-0043 TIME_WAIT
   टीसीपी 192.168.1.13:43689 178.248.237.68-00-0043 TIME_WAIT
   टीसीपी 192.168.1.13-00-003690 178.248.237.68-00-0043 TIME_WAITIT
   टीसीपी 192.168.1.13-00-003691 178.248.237.68-00-0043 TIME_WAITIT
   टीसीपी 192.168.1.13-00-003692 178.248.237.68-00-0043 TIME_WAITIT
   टीसीपी 192.168.1.13-00-003693 178.248.237.68-00-0043 TIME_WAITIT
   टीसीपी 192.168.1.13-00-003695 178.248.237.68-00-0043 TIME_WAITIT

यहां, आउटपुट को गति देने के लिए इन-स्विच का उपयोग किया जाता है, क्योंकि अन्यथा प्रत्येक आईपी के लिए नेटस्टैट डोमेन नाम की तलाश करेगा, और 178.248.237.68 लेखन के समय habr.com आईपी पते के लिए दिखेगा।

कुल मिलाकर, हम देखते हैं कि उपयोग किए जाने वाले निर्माण के बावजूद, और भले ही कार्यक्रम पूरी तरह से पूरा हो गया हो, सर्वर से कनेक्शन "लटका हुआ" रहा। और वे तब तक लटकाएंगे जब तक रजिस्ट्री कुंजी में इंगित नहीं किया जाता है HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpTimedWaitDelay।

एक सवाल तुरंत उठ सकता है - ऐसे मामलों में .NET कोर कैसे व्यवहार करता है? विंडोज पर क्या है, लिनक्स पर क्या है - बिल्कुल वैसा ही, क्योंकि इस तरह का कनेक्शन रिटेंशन सिस्टम लेवल पर होता है, न कि एप्लिकेशन लेवल पर। TIME_WAIT स्थिति सॉकेट की एक विशेष स्थिति है, क्योंकि यह अनुप्रयोग द्वारा बंद है, और यह उन पैकेटों को संसाधित करने के लिए आवश्यक है जो अभी भी नेटवर्क पर जा सकते हैं। लिनक्स के लिए, इस स्थिति की अवधि / proc / sys / net / ipv4 / tcp_fin_timeout में सेकंड में निर्दिष्ट की जाती है, और यदि आवश्यक हो, तो इसे बदला जा सकता है।

HttpClient का दूसरा मुद्दा सर्वर के समवर्ती कनेक्शन की गैर-स्पष्ट सीमा है । मान लीजिए कि आप परिचित .NET फ्रेमवर्क 4.7 का उपयोग करते हैं, जिसकी मदद से आप अत्यधिक भरी हुई सेवा विकसित करते हैं, जहाँ HTTP के माध्यम से अन्य सेवाओं के लिए कॉल आते हैं। कनेक्शन रिसाव के साथ संभावित समस्या का समाधान किया गया है, इसलिए सभी अनुरोधों के लिए एक ही HttpClient उदाहरण का उपयोग किया जाता है। क्या गलत हो सकता है?

निम्नलिखित कोड को चलाकर समस्या को आसानी से देखा जा सकता है:

 static void Main(string[] args) { var client = new HttpClient(); var tasks = new List<Task>(); for (var i = 0; i < 10; i++) { tasks.Add(SendRequest(client, "http://slowwly.robertomurray.co.uk/delay/5000/url/https://habr.com")); } Task.WaitAll(tasks.ToArray()); } private static async Task SendRequest(HttpClient client, string url) { var response = await client.GetAsync(url); Console.WriteLine($"Received response {response.StatusCode} from {url}"); } 

लिंक में निर्दिष्ट संसाधन आपको निर्दिष्ट समय के लिए सर्वर की प्रतिक्रिया में देरी करने की अनुमति देता है, इस मामले में - 5 सेकंड।

जैसा कि उपरोक्त कोड को निष्पादित करने के बाद नोटिस करना आसान है - हर 5 सेकंड में केवल 2 प्रतिक्रियाएं आती हैं, हालांकि 10 एक साथ अनुरोध किए गए थे। यह इस तथ्य के कारण है कि HTTP के साथ एक नियमित .NET फ्रेमवर्क में अन्य चीजों के साथ बातचीत, एक विशेष वर्ग System.Net.ServicePointManager के माध्यम से जाती है जो HTTP कनेक्शन के विभिन्न पहलुओं को नियंत्रित करती है। इस वर्ग में एक DefaultConnectionLimit गुण है जो इंगित करता है कि प्रत्येक डोमेन के लिए कितने समवर्ती कनेक्शन बनाए जा सकते हैं। और इसलिए ऐतिहासिक रूप से, किसी संपत्ति का डिफ़ॉल्ट मूल्य 2 है।

यदि आप बहुत शुरुआत में उपरोक्त कोड उदाहरण में जोड़ते हैं

 ServicePointManager.DefaultConnectionLimit = 5; 

तब उदाहरण के निष्पादन में तेजी आएगी, क्योंकि अनुरोधों को 5 के बैच में निष्पादित किया जाएगा।

और .NET कोर में यह कैसे काम करता है, इस पर आगे बढ़ने से पहले, सेवाप्रबंधक के बारे में थोड़ा और कहा जाना चाहिए। ऊपर चर्चा की गई संपत्ति उन कनेक्शनों की डिफ़ॉल्ट संख्या को इंगित करती है जो किसी भी डोमेन के बाद के कनेक्शन के लिए उपयोग की जाएगी। लेकिन इसके साथ-साथ, व्यक्तिगत रूप से प्रत्येक डोमेन नाम के लिए मापदंडों को नियंत्रित करना संभव है और यह ServicePoint वर्ग के माध्यम से किया जाता है:

 var delayServicePoint = ServicePointManager.FindServicePoint(new Uri("http://slowwly.robertomurray.co.uk")); delayServicePoint.ConnectionLimit = 3; var habrServicePoint = ServicePointManager.FindServicePoint(new Uri("https://habr.com")); habrServicePoint.ConnectionLimit = 5; 

इस कोड को निष्पादित करने के बाद, उसी HttpClient उदाहरण के माध्यम से Habr के साथ किसी भी इंटरैक्शन में 5 एक साथ कनेक्शन का उपयोग किया जाएगा, और "धीमी" साइट के साथ 3 कनेक्शन।

यहां एक और दिलचस्प बारीकियों है - स्थानीय पते (लोकलहोस्ट) के लिए कनेक्शन की संख्या की सीमा int.MaxValue डिफ़ॉल्ट रूप से है। पहले DefaultConnectionLimit को सेट किए बिना इस कोड को निष्पादित करने के परिणामों को देखें:

 var habrServicePoint = ServicePointManager.FindServicePoint(new Uri("https://habr.com")); Console.WriteLine(habrServicePoint.ConnectionLimit); var localServicePoint = ServicePointManager.FindServicePoint(new Uri("http://localhost")); Console.WriteLine(localServicePoint.ConnectionLimit); 

अब .NET .NET पर चलते हैं। हालाँकि ServicePointManager अभी भी System.Net नामस्थान में मौजूद है, लेकिन यह .NET कोर में HttpClient के व्यवहार को प्रभावित नहीं करता है। इसके बजाय, HTTP कनेक्शन मापदंडों को HttpClientHandler (या SocketsHttpHandler, जिसे हम बाद में बात करेंगे) का उपयोग करके नियंत्रित किया जा सकता है:

 static void Main(string[] args) { var handler = new HttpClientHandler(); handler.MaxConnectionsPerServer = 2; var client = new HttpClient(handler); var tasks = new List<Task>(); for (int i = 0; i < 10; i++) { tasks.Add(SendRequest(client, "http://slowwly.robertomurray.co.uk/delay/5000/url/https://habr.com")); } Task.WaitAll(tasks.ToArray()); Console.ReadLine(); } private static async Task SendRequest(HttpClient client, string url) { var response = await client.GetAsync(url); Console.WriteLine($"Received response {response.StatusCode} from {url}"); } 

उपरोक्त उदाहरण बिल्कुल उसी तरह व्यवहार करेगा जैसे नियमित .NET फ्रेमवर्क के लिए प्रारंभिक उदाहरण - एक समय में केवल 2 कनेक्शन स्थापित करने के लिए। लेकिन यदि आप MaxConnectionsPerServer प्रॉपर्टी सेट के साथ लाइन को हटाते हैं, तो एक साथ कनेक्शन की संख्या बहुत अधिक होगी, क्योंकि .NET कोर में डिफ़ॉल्ट रूप से इस प्रॉपर्टी का मूल्य int.MaxValue है।

और अब चलो डिफ़ॉल्ट सेटिंग्स के साथ तीसरी गैर-स्पष्ट समस्या को देखते हैं, जो पिछले दो - लंबे समय तक रहने वाले कनेक्शन और डीएनएस कैशिंग से कम महत्वपूर्ण नहीं हो सकती है। दूरस्थ सर्वर के साथ कनेक्शन स्थापित करते समय, डोमेन नाम को पहले संबंधित आईपी पते पर हल किया जाता है, फिर बाद में कनेक्शन को गति देने के लिए प्राप्त पते को कुछ समय के लिए कैश में डाल दिया जाता है। इसके अलावा, संसाधनों को बचाने के लिए, ज्यादातर अक्सर प्रत्येक अनुरोध के बाद कनेक्शन बंद नहीं होता है, लेकिन लंबे समय तक खुला रहता है।

कल्पना करें कि जिस सिस्टम को हम विकसित कर रहे हैं, उसे पुनः आरंभ किए बिना सामान्य रूप से काम करना चाहिए यदि सर्वर जिसके साथ इंटरैक्ट करता है वह एक अलग आईपी पते में बदल गया है। उदाहरण के लिए, यदि आप वर्तमान में विफल होने के कारण किसी अन्य डेटा केंद्र पर जाते हैं। यहां तक ​​कि अगर पहले डेटा सेंटर (जो जल्दी भी हो सकता है) में विफलता के कारण एक स्थायी कनेक्शन टूट गया है, डीएनएस कैश हमारे सिस्टम को इस तरह के बदलाव का तुरंत जवाब देने की अनुमति नहीं देगा। डीएनएस राउंड-रॉबिन के माध्यम से लोड बैलेंसिंग के पते पर कॉल के लिए भी यही सच है।

एक "सामान्य" .NET फ्रेमवर्क के मामले में, इस व्यवहार को ServicePointManager और ServicePoint (नीचे सूचीबद्ध सभी पैरामीटर मिलीसेकंड में मान लेते हैं) के माध्यम से नियंत्रित किया जा सकता है:

• ServicePointManager.DnsRefreshTimeout - इंगित करता है कि प्रत्येक डोमेन नाम के लिए प्राप्त आईपी पते को कितनी देर तक कैश किया जाएगा, डिफ़ॉल्ट मान 2 मिनट (120000) है।
• ServicePoint.ConnectionLeaseTimeout - यह बताता है कि कनेक्शन को कितने समय तक खुला रखा जा सकता है। डिफ़ॉल्ट रूप से, कनेक्शन के लिए कोई समय सीमा नहीं है; कोई भी कनेक्शन मनमाने ढंग से लंबे समय तक रखा जा सकता है, क्योंकि यह पैरामीटर -1 है। अनुरोध पूरा होने के तुरंत बाद इसे 0 पर सेट करने से प्रत्येक कनेक्शन बंद हो जाएगा।
• ServicePoint.MaxIdleTime - कनेक्शन की निष्क्रियता के समय के बाद कनेक्शन बंद हो जाएगा। निष्क्रियता का अर्थ है कनेक्शन के माध्यम से कोई डेटा स्थानांतरण नहीं। डिफ़ॉल्ट रूप से, इस पैरामीटर का मान 100 सेकंड (100000) है।

अब, इन मापदंडों की समझ में सुधार करने के लिए, हम उन सभी को एक परिदृश्य में संयोजित करेंगे। मान लीजिए कि किसी ने DnsRefreshTimeout और MaxIdleTime को नहीं बदला और वे क्रमशः 120 और 100 सेकंड के हैं। इसके साथ, ConnectionLeaseTimeout को 60 सेकंड के लिए सेट किया गया था। एप्लिकेशन केवल एक कनेक्शन स्थापित करता है, जिसके माध्यम से यह हर 10 सेकंड में अनुरोध भेजता है।

इन सेटिंग्स के साथ, कनेक्शन हर 60 सेकंड (ConnectionLeaseTimeout) को बंद कर दिया जाएगा, भले ही यह समय-समय पर डेटा स्थानांतरित करता है। समापन और पुन: निर्माण इस तरह से होगा जैसे अनुरोधों के सही निष्पादन में हस्तक्षेप न करना - यदि समय हो गया है, और फिलहाल अनुरोध अभी भी निष्पादित किया जा रहा है, तो अनुरोध पूरा होने के बाद कनेक्शन बंद हो जाएगा। जब भी कोई कनेक्शन दोबारा बनाया जाता है, तो संबंधित IP पते को पहले कैश से लिया जाएगा, और केवल तभी जब उसका रिज़ॉल्यूशन समाप्त हो गया हो (120 सेकंड), सिस्टम DNS सर्वर को एक अनुरोध भेजेगा।

MaxIdleTime पैरामीटर इस परिदृश्य में कोई भूमिका नहीं निभाएगा, क्योंकि कनेक्शन 10 सेकंड से अधिक समय के लिए निष्क्रिय नहीं है।

इन मापदंडों का इष्टतम अनुपात विशिष्ट स्थिति और गैर-कार्यात्मक आवश्यकताओं पर निर्भर करता है:

• यदि आप उस डोमेन नाम के पीछे आईपी पते को पारदर्शी रूप से स्विच करने का इरादा नहीं रखते हैं जो आपके एप्लिकेशन तक पहुंचता है, और उसी समय आपको नेटवर्क कनेक्शन की लागत को कम करने की आवश्यकता होती है, तो डिफ़ॉल्ट सेटिंग्स एक अच्छे विकल्प की तरह दिखती हैं।
• यदि विफलताओं के मामले में आईपी पते के बीच स्विच करने की आवश्यकता होती है, तो आप DnsRefreshTimeout को 0 पर सेट कर सकते हैं, और गैर-नकारात्मक मान के लिए ConnectionLeaseTimeout आपको सूट कर सकता है। कौन सा विशेष रूप से इस बात पर निर्भर करता है कि आपको कितनी जल्दी दूसरे आईपी पर स्विच करने की आवश्यकता है। जाहिर है, आप एक विफलता के लिए सबसे तेज़ संभव प्रतिक्रिया चाहते हैं, लेकिन यहां आपको इष्टतम मूल्य खोजने की आवश्यकता है, जो एक तरफ, एक स्वीकार्य स्विचिंग समय प्रदान करता है, दूसरी तरफ, कनेक्शन को बार-बार बनाने के माध्यम से सिस्टम के थ्रूपुट और प्रतिक्रिया समय को नीचा नहीं करता है।
  
• यदि आपको आईपी पते को बदलने के लिए सबसे तेज़ संभव प्रतिक्रिया की आवश्यकता है, उदाहरण के लिए, जैसे कि DNS राउंड-रॉबिन के माध्यम से संतुलन के मामले में, आप DnsRefreshTimeout और ConnectionLeaseTimeout को 0 पर सेट करने का प्रयास कर सकते हैं, लेकिन यह बहुत बेकार होगा, प्रत्येक अनुरोध के लिए, DNS सर्वर को पहले मतदान किया जाएगा, जिसके बाद लक्ष्य नोड का कनेक्शन फिर से स्थापित किया जाएगा।
  
• ऐसी स्थितियां हो सकती हैं जहां बिना शून्य-शून्य DnsRefreshTimeout के साथ ConnectionLeaseTimeout को 0 पर सेट करना उपयोगी हो सकता है, लेकिन मैं अभी एक उपयुक्त स्क्रिप्ट के साथ नहीं आ सकता। तार्किक रूप से, इसका मतलब यह होगा कि प्रत्येक अनुरोध के लिए, कनेक्शन नए सिरे से बनाए जाएंगे, लेकिन जब भी संभव हो कैश से आईपी पते लिए जाएंगे।

निम्नलिखित कोड का एक उदाहरण है जिसका उपयोग ऊपर वर्णित मापदंडों के व्यवहार को देखने के लिए किया जा सकता है:

 var client = new HttpClient(); ServicePointManager.DnsRefreshTimeout = 120000; var habrServicePoint = ServicePointManager.FindServicePoint(new Uri("https://habr.com")); habrServicePoint.MaxIdleTime = 100000; habrServicePoint.ConnectionLeaseTimeout = 60000; while (true) { client.GetAsync("https://habr.com").Wait(); Thread.Sleep(10000); } 

जबकि परीक्षण कार्यक्रम चल रहा है, आप कनेक्शन स्थापित करने के लिए मॉनिटर करने के लिए एक लूप में पावरशेल के माध्यम से नेटस्टैट चला सकते हैं।

तुरंत यह कहा जाना चाहिए कि .NET कोर में वर्णित मापदंडों को कैसे प्रबंधित किया जाए। ConnectionLimit के मामले में, ServicePointManager की सेटिंग काम नहीं करेगी। कोर में एक विशेष प्रकार का HTTP हैंडलर है, जो ऊपर वर्णित तीन मापदंडों में से दो को लागू करता है - सॉकेट्सहैपहैंडलर:

 var handler = new SocketsHttpHandler(); handler.PooledConnectionLifetime = TimeSpan.FromSeconds(60); // ConnectionLeaseTimeout handler.PooledConnectionIdleTimeout = TimeSpan.FromSeconds(100); // MaxIdleTime var client = new HttpClient(handler); 

कोई पैरामीटर नहीं है जो .NET कोर में DNS रिकॉर्ड के कैशिंग समय को नियंत्रित करता है। परीक्षण मामलों से पता चलता है कि कैशिंग काम नहीं करता है - एक नया डीएनएस कनेक्शन बनाते समय, रिज़ॉल्यूशन फिर से किया जाता है, इसलिए शर्तों के तहत सामान्य ऑपरेशन के लिए जब अनुरोधित डोमेन नाम अलग-अलग आईपी पते के बीच स्विच कर सकता है, तो बस इच्छित मूल्य पर PooledConnectionLifetime सेट करें।

सभी के अलावा, यह कहा जाना चाहिए कि इन सभी समस्याओं को माइक्रोसॉफ्ट के डेवलपर्स द्वारा ध्यान नहीं दिया जा सकता था, और इसलिए, .NET कोर 2.1 के साथ शुरू, HTTP क्लाइंट का एक कारखाना दिखाई दिया जो उनमें से कुछ को हल करने की अनुमति देता है - https://docs.microsoft.com/en- us / dotnet / standard / microservices-आर्किटेक्चर / कार्यान्वयन-लचीला-एप्लिकेशन / उपयोग-httpclientfactory-to-implement-resilient-http-request । इसके अलावा, कनेक्शन के जीवनकाल के प्रबंधन के अलावा, नया घटक टाइप किए गए क्लाइंट बनाने के लिए अवसर प्रदान करता है, साथ ही साथ कुछ अन्य उपयोगी चीजें भी। इस लेख और इससे लिंक में HttpClientFactory के उपयोग पर पर्याप्त जानकारी और उदाहरण हैं, इसलिए, मैं इस लेख में इसके साथ जुड़े विवरणों पर विचार नहीं करूंगा।