Android में नेटवर्किंग: ट्रैफ़िक, सुरक्षा और बैटरी

आज, Google Play में 800 हजार से अधिक एप्लिकेशन हैं। उनमें से कई क्लाइंट-सर्वर संचार के आधार पर कार्यान्वित किए जाते हैं। ऐसे अनुप्रयोगों को विकसित करते समय, आपको तीन मुख्य बिंदुओं पर विचार करने की आवश्यकता होती है, जिस पर इस लेख में चर्चा की जाएगी।

आवेदन के नेटवर्क भाग को लागू करते समय याद रखने योग्य बातें

पहला ट्रैफिक है। हमेशा मुफ्त वाई-फाई कनेक्शन पर काम करना संभव नहीं है, और मोबाइल इंटरनेट अभी भी महंगा है, और आपको यह याद रखने की आवश्यकता है क्योंकि ट्रैफ़िक उपयोगकर्ता का पैसा है।

दूसरी बैटरी की सीमा है। कुछ रोजमर्रा की गतिविधियों, बैठकों, सैर, व्यापार के लिए उपयोगकर्ता के लिए मोबाइल डिवाइस आवश्यक हैं, और जब बैटरी सबसे अधिक निष्क्रिय समय पर चलती है, तो उपयोगकर्ता अशिष्ट है।
तीसरी सुरक्षा है। चूंकि सभी समान हम मोबाइल क्लाइंट के बारे में बात कर रहे हैं, और डेटा क्लाइंट से सर्वर और सर्वर से पूरे नेटवर्क पर चल रहा है, उन्हें संरक्षित किया जाना चाहिए।

नेटवर्किंग दृष्टिकोण

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



दूसरा दृष्टिकोण लगातार मतदान है: क्लाइंट सर्वर को एक अनुरोध भेजता है और इसे बताता है: "मुझे ताजा डेटा दें"; सर्वर क्लाइंट के अनुरोध का जवाब देता है और वह सब कुछ देता है जो उसने इस बिंदु पर जमा किया है।



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

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



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



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

HttpUrlConnection और HttpClient

एंड्रॉइड डेवलपर के शस्त्रागार में इन प्रोटोकॉल के साथ काम करने के लिए दो कक्षाएं हैं। पहला है java.net.ttpURLConnection, दूसरा है org.apache.http.client.HttpClient। ये दोनों लाइब्रेरी एंड्रॉइड एसडीके में शामिल हैं। इसके बाद, इन पुस्तकालयों में से प्रत्येक के साथ काम करने पर यातायात, बैटरी और सुरक्षा को प्रभावित करने वाले मुख्य बिंदुओं पर विस्तार से चर्चा की जाएगी।

HttpURLConnection के साथ, सब कुछ सरल है। एक वर्ग और सभी। इसका कारण यह है कि पैरेंट क्लास URLConnection न केवल HTTP प्रोटोकॉल पर काम करने के लिए डिज़ाइन किया गया था, बल्कि फाइल, मेल्टो, एफटीपी, आदि पर भी काम किया गया था।



HttpClient को अधिक ऑब्जेक्ट ओरिएंटेड बनाया गया है। इसमें अमूर्तता का स्पष्ट अलगाव है। सरलतम मामले में, हम पांच अलग-अलग इंटरफेस के साथ काम करेंगे: HttpRequest, HttpResponse, HttpEntity और HttpContext। इसलिए, अपाचेव क्लाइंट HttpUrlConnection की तुलना में बहुत अधिक भारी है।



आमतौर पर, प्रति एप्लिकेशन HttpClient वर्ग का केवल एक उदाहरण है। यह उसके भारीपन के कारण है। प्रत्येक अनुरोध के लिए एक अलग उदाहरण का उपयोग करना व्यर्थ होगा। उदाहरण के लिए, हम अनुप्रयोग वर्ग के उत्तराधिकारी में HTTP क्लाइंट का एक उदाहरण संग्रहीत कर सकते हैं।



HttpUrlConnection के मामले में, प्रत्येक अनुरोध के लिए एक नया क्लाइंट उदाहरण बनाया जाना चाहिए।



यातायात किससे बना है?

जबकि हमारा एप्लिकेशन चल रहा है, चित्र कुछ इस तरह होगा।



अनुरोधों की संख्या और आवृत्ति UI - एप्लिकेशन इंटरफ़ेस की कार्यक्षमता और संतृप्ति पर निर्भर करेगी। ऐसा प्रत्येक अनुरोध सर्वर से एक टीसीपी कनेक्शन स्थापित करता है। इस स्थिति में, जो ट्रैफ़िक खर्च किया जाएगा, वह कनेक्शन सेटिंग्स के योग और प्रेषित डेटा के योग के बराबर होगा। इस मामले में, लंबे समय तक रहने वाले कनेक्शन (जीवित रहने) का उपयोग करके यातायात की खपत को कम किया जा सकता है।



जीवित रखने का मूल विचार HTTP अनुरोधों को भेजने और प्राप्त करने के लिए समान टीसीपी कनेक्शन का उपयोग करना है। मुख्य लाभ ट्रैफ़िक और क्वेरी निष्पादन समय कम हो जाते हैं। मैंने एक साधारण परीक्षण किया, जिसमें इस तथ्य को समाहित किया गया कि 10 अनुरोधों को एक ही मेजबान को क्रमिक रूप से निष्पादित किया गया था। डेटा नीचे दी गई तालिका में प्रस्तुत किया गया है। जिंदा बंद रखने के साथ, आप देख सकते हैं कि औसत क्वेरी निष्पादन का समय लगभग दो सेकंड था। जीवित रखने के मामले में, यह समय घटकर 1.7 सेकंड हो गया, जो कि 16% अधिक तेज है। यह मुख्य रूप से इस तथ्य के कारण है कि सर्वर से अक्सर कनेक्शन स्थापित करने की आवश्यकता समाप्त हो जाती है। सुरक्षित HTTPS कनेक्शन का उपयोग करते समय, अंतर अधिक ध्यान देने योग्य होगा, क्योंकि SSL हैंडशेक टीसीपी हैंडशेक की तुलना में बहुत कठिन है।



जीवित कनेक्शन रखने के लिए एक महत्वपूर्ण पैरामीटर जीवित अवधि है। इसका अर्थ है एक समय अंतराल। यदि इस अंतराल के भीतर कई HTTP अनुरोध आते हैं, तो पहले से स्थापित टीसीपी कनेक्शन का पुन: उपयोग किया जाएगा।



यह आंकड़ा से देखा जा सकता है कि चौथे और तीसरे अनुरोध के बीच का समय जीवित अवधि को पार कर गया है, इसलिए सर्वर के लिए एक नया टीसीपी कनेक्शन बनाया गया है।
आइए देखें कि आप उपरोक्त पैरामीटर को कैसे कॉन्फ़िगर कर सकते हैं। HttpClient के मामले में, सब कुछ ठीक है, हमारे पास हमारे निपटान में ConnectionKeepAliveStrategy इंटरफ़ेस है। GetKeepAliveDuration विधि को ओवरराइड करके, हम जीवित अवधि पैरामीटर के वांछित मान को वापस कर सकते हैं।

httpClient.setKeepAliveStrategy( new ConnectionKeepAliveStrategy() { @Override public long getKeepAliveDuration( HttpResponse response, HttpContext context) { return KEEP_ALIVE_DURATION_MILLISECONDS; } }); 

HttpUrlConnection के साथ काम करते समय, आपको एंड्रॉइड 2.2 प्लेटफॉर्म में बग को याद रखना होगा और प्लेटफॉर्म <= 2.2 पर जिंदा रखना होगा।

 if (Build.VERSION.SDK_INT < Build.VERSION_CODES.FROYO) { System.setProperty("http.keepAlive", "false"); } 

HttpUrlConnection के साथ काम करते समय दूसरा अप्रिय (शायद केवल मेरे लिए) क्षण यह है कि जीवित अवधि पैरामीटर को कॉन्फ़िगर करने योग्य नहीं है (मुझे कोई कानूनी तरीका नहीं मिला, अगर कोई मुझसे कहता है कि मैं आभारी रहूंगा)। डिफ़ॉल्ट रूप से, यह लगभग 5 सेकंड है।
इसके अलावा, जब एक जीवित कनेक्शन के साथ काम करते हैं, तो आपको स्थापित कनेक्शन (कनेक्शन) से डेटा को पूरी तरह से पढ़ने की कोशिश करनी चाहिए। यदि आप डेटा नहीं पढ़ते हैं, तो आप कनेक्शन प्राप्त कर सकते हैं कि मैं पूल में लटका रहूंगा और "विचार" करूंगा कि कोई और उन्हें पढ़ने जा रहा है। यदि एक InputStream सफलतापूर्वक प्राप्त होता है, तो प्रतिक्रिया निकाय को उसकी संपूर्णता में पढ़ें। एक पूर्ण रीड डेटा से कनेक्शन को साफ़ कर देगा , और इस कनेक्शन का पुन: उपयोग होने की अधिक संभावना होगी।

(कुकी) kukoy के साथ कार्य करना

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

1. प्लेटफार्मों पर = = 4.0.3 (एपीआई स्तर 15) डोमेन की शुरुआत में एक बिंदु होना चाहिए
2. CookieSyncManager के सिंक () विधि को कॉल करने के बाद, कुकी केवल आपके एप्लिकेशन के अंदर WebView में सेट की गई है, लेकिन ब्राउज़र में नहीं । यह सीमा एंड्रॉइड सिस्टम द्वारा सुरक्षा कारणों से लगाई गई है।

सुरक्षित कनेक्शन (HTTPS)

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



प्लेटफार्मों पर <Android 4.0, HTTPS पर नेटवर्क अनुरोध करने की कोशिश करते समय, एक SSLHandshakeException क्रैश हो जाएगा। कीचेन एपीआई का उपयोग करके एक विश्वसनीय प्रमाणपत्र स्थापित करने की क्षमता एंड्रॉइड 4.0 पर दिखाई दी । लेकिन 4.0 से नीचे के प्लेटफार्मों के बारे में क्या? इन प्लेटफार्मों पर, हमारे पास दो विकल्प हैं:

1. एक स्थानीय प्रमाणपत्र स्टोर बनाएं
2. किसी भी प्रमाण पत्र पर भरोसा करें। इस मामले में, ट्रैफ़िक भी एन्क्रिप्ट किया जाएगा, लेकिन मध्य हमले में एक आदमी का खतरा बना रहेगा

यदि विकल्प स्थानीय प्रमाण पत्र की दुकान के निर्माण पर गिर गया, तो इसके बनने के बाद, आप इसे इस प्रकार से जोड़ सकते हैं:

- HttpUrlConnection के मामले में:
...

 TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm); KeyStore keyStore = KeyStore.getInstance("BKS"); InputStream in = context.getResources().openRawResource(mykeystore); keyStore.load(in, "mysecret".toCharArray()); in.close(); tmf.init(keyStore); SSLContext sslc = SSLContext.getInstance("TLS"); sslc.init(null, tmf.getTrustManagers(),new SecureRandom()); 

...
- HttpClient के मामले में:

 private SSLSocketFactory createSslSocketFactory() { SSLSocketFactory sf = null; try { KeyStore keyStore = KeyStore.getInstance("BKS"); InputStream in = context.getResources().openRawResource(mykeystore); keyStore.load(in, "mysecret".toCharArray()); in.close(); sf = new SSLSocketFactory(keyStore); sf.setHostnameVerifier(STRICT_HOSTNAME_VERIFIER); } catch (Exception e) { e.printStackTrace(); } return sf; }. 

KeyStore.getInstance ("BKS") का उपयोग करके हमें एक KeyStore ऑब्जेक्ट मिलता है जो Bounce Castle KeyStore प्रारूप (क्रिप्टो एल्गोरिदम के साथ काम करने के लिए जावा पैकेज) का समर्थन करता है। mykeystore - उस संसाधन की आईडी जिसमें प्रमाणपत्र स्थित हैं।
mysecret - KeyStore से पासवर्ड। अधिक जानकारी के लिए, ऊपर दिए गए स्थानीय प्रमाणपत्र स्टोर का लिंक देखें।

यदि विकल्प "किसी भी प्रमाण पत्र के साथ विश्वास" पर गिर गया, तो यह निम्नानुसार दो इंटरफेस को लागू करने के लिए पर्याप्त है:

 private class DummyHostnameVerifier implements HostnameVerifier{ @Override public boolean verify(String hostname, SSLSession session) { return true; } } private class DummyTrustManager implements X509TrustManager{ @Override public void checkClientTrusted(...) throws CertificateException { //empty } @Override public void checkServerTrusted(...) throws CertificateException { //empty } ... } 

फिर आपको ये कार्यान्वयन या तो HttpClient या HttpUrlConnection के लिए लागू करना चाहिए।

बैटरी के बारे में क्या?

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

लेख पढ़ने के बाद, आपको शायद आश्चर्य होगा कि किस उपकरण का उपयोग करना है - HttpClient या HttpUrlConnection? Android डेवलपर्स नए अनुप्रयोगों में HttpUrlConnection का उपयोग करने की सलाह देते हैं इसका उपयोग करना आसान है, इसे आगे विकसित किया जाएगा और मंच के अनुकूल बनाया जाएगा। HttpClient को एंड्रॉइड 2.3 के नीचे प्लेटफार्मों पर उपयोग किया जाना चाहिए, मुख्य रूप से जीवित कनेक्शन के साथ एक गंभीर बग के कारण।

बेशक, हम अपने मोबाइल एप्लिकेशन विकसित करते समय इन तीन बिंदुओं को ध्यान में रखते हैं। और क्या, सबसे पहले, आप के बारे में सोचते हैं?