Background App Refresh कैसे Public WiFi के प्रदर्शन को खराब करता है

हाउ बैकग्राउंड ऐप रिफ्रेश किल्स पब्लिक WiFi परफॉर्मेंस - ए Purple टेक्निकल ब्रीफिंग। आपका स्वागत है। यदि आप एक गेस्ट WiFi नेटवर्क के लिए जिम्मेदार हैं - चाहे वह कोई होटल हो, कोई रिटेल एस्टेट हो, कोई स्टेडियम हो, या फिर कोई कॉन्फ्रेंस सेंटर हो - तो यह ब्रीफिंग आपके एयर टाइम बजट के बारे में सोचने के तरीके को बदलने जा रही है। मैं आपको पब्लिक वायरलेस डिप्लॉयमेंट्स में क्षमता को खत्म करने वाले सबसे कम आंके जाने वाले कारणों में से एक के बारे में विस्तार से बताने जा रहा हूँ: बैकग्राउंड ऐप रिफ्रेश। हम कवर करेंगे कि प्रोटोकॉल स्तर पर यह क्या है, हाई-डेंसिटी वाले वातावरण में यह विशेष रूप से विनाशकारी क्यों है, और - सबसे महत्वपूर्ण बात - आज आप नेटवर्क लेयर पर इसके बारे में क्या कर सकते हैं। आइए समस्या के पैमाने से शुरुआत करते हैं। आपके मेहमान आपके नेटवर्क पर जो भी स्मार्टफोन लाते हैं, उसमें लगभग 30 से 80 इंस्टॉल किए गए एप्लिकेशन चल रहे होते हैं। उनमें से एक बड़ा हिस्सा बैकग्राउंड रिफ्रेश साइकिल चलाने के लिए कॉन्फ़िगर किया गया है - जैसे एनालिटिक्स सर्वर को पोल करना, क्लाउड डेटा सिंक करना, पुश नोटिफिकेशन टोकन लाना, OS अपडेट की जांच करना और एड नेटवर्क को पिंग करना। iOS पर, Apple का बैकग्राउंड ऐप रिफ्रेश फीचर iOS 7 में पेश किया गया था और तब से यह लगातार मौजूद है। Android के पास JobScheduler और WorkManager API के माध्यम से इसका अपना समकक्ष है। मुख्य बात यह है: ये प्रक्रियाएं इस बात की परवाह किए बिना चलती हैं कि उपयोगकर्ता सक्रिय रूप से अपने डिवाइस का उपयोग कर रहा है या नहीं। वे चुपचाप, अदृश्य रूप से और लगातार चलती रहती हैं। अब, एक या दो डिवाइस वाले घरेलू ब्रॉडबैंड कनेक्शन पर, यह अनिवार्य रूप से अदृश्य है। लेकिन इसे 1,200 प्रतिनिधियों वाले कॉन्फ्रेंस सेंटर, या 400 समवर्ती गेस्ट कनेक्शन वाले रिटेल फ्लैगशिप स्टोर तक बढ़ाएं, और गणित बहुत जल्दी असहज करने वाला हो जाता है। एंटरप्राइज वायरलेस डिप्लॉयमेंट्स में रिसर्च लगातार दर्शाती है कि बैकग्राउंड ट्रैफिक - एनालिटिक्स बीकन, OS अपडेट चेक, एड नेटवर्क पिंग, पुश नोटिफिकेशन पोलिंग, क्लाउड सिंक और सोशल मीडिया रिफ्रेश साइकिल - एक व्यस्त गेस्ट नेटवर्क पर कुल एक्सेस पॉइंट क्षमता के 30 से 45 प्रतिशत के बीच हो सकता है। यह वह क्षमता है जिससे आपके वैध उपयोगकर्ता - वे जो किसी प्रेजेंटेशन को स्ट्रीम करने, लेनदेन पूरा करने या केवल ब्राउज़ करने का प्रयास कर रहे हैं - वंचित रह जाते हैं। आइए मैं आपको रेडियो लेयर पर वास्तव में क्या हो रहा है, इसकी तकनीकी तस्वीर देता हूँ। एक 802.1X नेटवर्क में, एक्सेस पॉइंट से जुड़ने वाला प्रत्येक डिवाइस CSMA/CA - कैरियर सेंस मल्टीपल एक्सेस विद कोलिजन अवॉइडेंस का उपयोग करके एयर टाइम के लिए प्रतिस्पर्धा करता है। प्रत्येक बैकग्राउंड रिफ्रेश अनुरोध, चाहे पेलोड कितना भी छोटा क्यों न हो, एक पूर्ण एसोसिएशन अनुक्रम की आवश्यकता होती है: प्रोब अनुरोध, प्रमाणीकरण, एसोसिएशन, यदि आवश्यक हो तो DHCP, और फिर स्वयं डेटा एक्सचेंज। एक हाई-डेंसिटी डिप्लॉयमेंट में, यह कंटेंशन ओवरहेड महत्वपूर्ण होता है। एक सिंगल ऐप से एक सिंगल एनालिटिक्स बीकन केवल 200 बाइट्स डेटा ट्रांसफर कर सकता है, लेकिन वायरलेस मीडियम पर उस लेनदेन का ओवरहेड एयर टाइम में उससे 10 से 20 गुना अधिक खपत कर सकता है।WiFi 6 — IEEE 802.11ax — के साथ हमारे पास OFDMA और BSS Colouring हैं जो इसे अधिक कुशलता से प्रबंधित करने में मदद करते हैं। लेकिन इन सुधारों के बावजूद, मूलभूत समस्या बनी हुई है: जब तक आप नेटवर्क लेयर पर हस्तक्षेप नहीं करते, तब तक आप बैकग्राउंड ट्रैफ़िक द्वारा खपत किए गए एयर टाइम को वापस नहीं पा सकते हैं। रेडियो को यह नहीं पता होता या इससे कोई फर्क नहीं पड़ता कि कोई पैकेट वीडियो देखने वाला उपयोगकर्ता है या वर्जीनिया में टेलीमेट्री सर्वर को चुपचाप कॉल करने वाला कोई ऐप। यही वह जगह है जहाँ आपके आर्किटेक्चर में डीप पैकेट इंस्पेक्शन और ट्रैफ़िक वर्गीकरण महत्वपूर्ण उपकरण बन जाते हैं। एक ठीक से कॉन्फ़िगर किया गया ट्रैफ़िक वर्गीकरण इंजन, जो आपके वायरलेस कंट्रोलर और आपके अपस्ट्रीम गेटवे के बीच इनलाइन बैठता है, बैकग्राउंड रिफ्रेश ट्रैफ़िक को उसके गंतव्य, उसके पेलोड सिग्नेचर और उसके व्यावहारिक पैटर्न द्वारा पहचान सकता है। ज्ञात एनालिटिक्स एंडपॉइंट्स — Google Analytics, Firebase, Crashlytics, Flurry, Amplitude, Mixpanel, और दर्जनों अन्य — के पास अच्छी तरह से प्रलेखित IP रेंज और डोमेन पैटर्न हैं। DoubleClick, AppNexus, और इसी तरह के प्लेटफार्मों के विज्ञापन नेटवर्क एंडपॉइंट्स भी समान रूप से अच्छी तरह से सूचीबद्ध हैं। DNS या IP लेयर पर लागू की गई नियमित रूप से अपडेट की जाने वाली ब्लॉक सूची, इन अनुरोधों को कोई सार्थक बैंडविड्थ खपत करने से पहले ही रोक सकती है। यह दृष्टिकोण वेंडर-न्यूट्रल है। चाहे आप Cisco Catalyst Centre, Aruba Central, Juniper Mist, या Ruckus SmartZone डिप्लॉयमेंट चला रहे हों, सिद्धांत वही है: वर्गीकृत करें, फिर कार्रवाई करें। आपके पास पहचाने गए बैकग्राउंड ट्रैफ़िक के साथ क्या करना है, इसके लिए तीन विकल्प हैं। आप इसे पूरी तरह से ब्लॉक कर सकते हैं - जो कि सबसे आक्रामक दृष्टिकोण है, और क्षमता सुधार के लिए सबसे प्रभावी है। आप इसे रेट-लिमिट कर सकते हैं - ट्रैफ़िक को जाने देना लेकिन इसे एक निश्चित बैंडविड्थ सीमा तक सीमित करना, आमतौर पर बैकग्राउंड श्रेणियों के लिए प्रति डिवाइस 64 किलोबिट प्रति सेकंड। या आप QoS DSCP मार्किंग का उपयोग करके इसे डी-प्रायोरिटी दे सकते हैं, जिससे यह सबसे कम ट्रैफ़िक क्लास में चला जाता है ताकि यह केवल तभी एयर टाइम का उपयोग करे जब कोई अन्य ट्रैफ़िक प्रतिस्पर्धा न कर रहा हो। अधिकांश वेन्यू ऑपरेटरों के लिए, ज्ञात एनालिटिक्स और विज्ञापन नेटवर्क एंडपॉइंट्स को ब्लॉक करने का संयोजन, पीक आवर्स के दौरान OS अपडेट ट्रैफ़िक की रेट-लिमिटिंग के साथ मिलकर, क्षमता सुधार और उपयोगकर्ता अनुभव का सबसे अच्छा संतुलन प्रदान करता है। अब मैं आपको दो वास्तविक दुनिया के डिप्लॉयमेंट परिदृश्यों के माध्यम से ले चलता हूँ जहाँ इसने मापने योग्य अंतर पैदा किया।पहला UK मिडलैंड्स में 340 कमरों वाला एक फोर-स्टार होटल है। इस प्रॉपर्टी ने एक आधुनिक WiFi 6 इंफ्रास्ट्रक्चर में निवेश किया था - जिसमें गेस्ट फ्लोर, कॉन्फ्रेंस सुइट और सार्वजनिक क्षेत्रों में 48 एक्सेस पॉइंट शामिल थे। हार्डवेयर निवेश के बावजूद, WiFi के लिए गेस्ट संतुष्टि स्कोर लगातार लक्ष्य से नीचे था। नेटवर्क टीम ने Purple प्लेटफॉर्म का उपयोग करके ट्रैफ़िक विश्लेषण किया और पाया कि दोपहर 3 से शाम 6 बजे के बीच पीक चेक-इन अवधि के दौरान बैकग्राउंड ऐप रिफ्रेश ट्रैफ़िक गेस्ट SSID पर उपलब्ध एयर टाइम का 38 प्रतिशत उपभोग कर रहा था। एक लक्षित ब्लॉक सूची तैनात की गई जिसमें 847 ज्ञात एनालिटिक्स और एड नेटवर्क डोमेन शामिल थे। दो हफ्तों के भीतर, पीक अवधि के दौरान प्रति कनेक्टेड डिवाइस औसत थ्रूपुट में 34 प्रतिशत की वृद्धि हुई, और प्रॉपर्टी के आंतरिक NPS ट्रैकिंग पर गेस्ट WiFi संतुष्टि स्कोर में 22 अंकों का सुधार हुआ। दूसरा परिदृश्य इंग्लैंड और वेल्स में 60 स्टोरों वाला एक क्षेत्रीय रिटेल चेन है। प्रत्येक स्टोर एक गेस्ट WiFi SSID चलाता है जिसका उपयोग ग्राहकों और इन-स्टोर डिजिटल साइनेज दोनों द्वारा किया जाता है। IT टीम को डिजिटल साइनेज लेटेंसी के बारे में शिकायतें मिल रही थीं - व्यस्त ट्रेडिंग अवधि के दौरान स्क्रीन बफर हो रही थीं। ट्रैफ़िक विश्लेषण से पता चला कि गेस्ट SSID से कनेक्ट होने वाले ग्राहकों के डिवाइस काफी मात्रा में बैकग्राउंड ट्रैफ़िक उत्पन्न कर रहे थे, जिसमें iOS अपडेट चेक शामिल थे जो स्टोर नेटवर्क के माध्यम से मल्टी-गीगाबाइट पेलोड खींच रहे थे। एनालिटिक्स एंडपॉइंट्स के लिए DNS-लेवल ब्लॉकिंग और पहचाने गए OS अपडेट ट्रैफ़िक के लिए 1 मेगाबिट प्रति सेकंड की सख्त दर सीमा के संयोजन ने साइनेज लेटेंसी की समस्या को पूरी तरह से हल कर दिया। सेंट्रलाइज्ड पॉलिसी मैनेजमेंट का उपयोग करके पूरे एस्टेट में इस समाधान को तैनात करने में चार घंटे से भी कम समय लगा। आइए अब मैं उन कार्यान्वयन चरणों को कवर करता हूँ जिनका पालन आपको अपने स्वयं के परिवेश में इसे तैनात करने के लिए करना होगा। चरण एक बेसलाइन माप है। किसी भी कॉन्फ़िगरेशन को छूने से पहले, आपको अपने वर्तमान ट्रैफ़िक प्रोफ़ाइल को समझना होगा। एक ट्रैफ़िक विश्लेषण टूल तैनात करें - Purple का WiFi एनालिटिक्स प्लेटफॉर्म इसे मूल रूप से प्रदान करता है - और कार्यदिवस और सप्ताहांत के पैटर्न को कैप्चर करने के लिए इसे न्यूनतम पांच व्यावसायिक दिनों के लिए चलाएं। आप ज्ञात बैकग्राउंड-रिफ्रेश गंतव्यों पर जाने वाले ट्रैफ़िक के अनुपात, बैकग्राउंड गतिविधि की पीक अवधि और प्रति-डिवाइस उपभोग दरों की तलाश कर रहे हैं। चरण दो आपकी ब्लॉक सूची बनाना है। अपनी नींव के रूप में OISD डोमेन ब्लॉक सूची से शुरुआत करें - यह अच्छी तरह से बनाए रखी गई है, समुदाय-सत्यापित है, और प्रमुख एनालिटिक्स और एड नेटवर्क एंडपॉइंट्स को कवर करती है। ट्रैफ़िक विश्लेषण से अपने स्वयं के अवलोकनों के साथ इसे पूरक करें। महत्वपूर्ण रूप से, अंधाधुंध ब्लॉक न करें। कुछ बैकग्राउंड ट्रैफ़िक - विशेष रूप से पोर्ट 5223 पर Apple Push Notification Service, और Google Firebase Cloud Messaging - डिवाइस की कार्यक्षमता के लिए आवश्यक है। इन्हें ब्लॉक करने से उपयोगकर्ता शिकायतें उत्पन्न होंगी। पूरे एस्टेट में रोल आउट करने से पहले एक स्टेजिंग परिवेश में या एकल एक्सेस पॉइंट समूह पर अपनी ब्लॉक सूची का परीक्षण करें। तीसरा चरण है पॉलिसी परिनियोजन (policy deployment)। अपने वर्गीकरण नियमों को WLAN कंट्रोलर स्तर पर लागू करें, न कि व्यक्तिगत एक्सेस पॉइंट्स पर। यह निरंतरता सुनिश्चित करता है और निरंतर प्रबंधन को सरल बनाता है। यदि आपका कंट्रोलर एप्लिकेशन-अवेयर QoS का समर्थन करता है, तो सब कुछ हार्ड-ब्लॉक करने के बजाय बैकग्राउंड श्रेणियों को कम प्राथमिकता देने के लिए DSCP मार्किंग का उपयोग करें - यह आपको अधिक लचीलापन देता है और अनपेक्षित परिणामों के जोखिम को कम करता है। चौथा चरण है निरंतर निगरानी। बैकग्राउंड रीफ्रेश एंडपॉइंट्स बदलते रहते हैं। नए एनालिटिक्स SDKs सामने आते हैं। ऐप डेवलपर्स होम नेटवर्क से संपर्क करने के नए तरीके खोजते हैं। आपकी ब्लॉक लिस्ट की समीक्षा और अपडेट कम से कम हर तिमाही में होना चाहिए। जहां संभव हो, इसे थ्रेट इंटेलिजेंस फीड का उपयोग करके स्वचालित करें जिसमें विज्ञापन और एनालिटिक्स नेटवर्क अपडेट शामिल हों। अनुपालन (compliance) के दृष्टिकोण से, यह ध्यान रखना महत्वपूर्ण है कि नेटवर्क लेयर पर ट्रैफ़िक वर्गीकरण और ब्लॉकिंग RIPA या समकक्ष कानूनों के तहत इंटरसेप्शन का हिस्सा नहीं है, बशर्ते कि आप एन्क्रिप्टेड पेलोड की सामग्री की जांच नहीं कर रहे हों। आप गंतव्य मेटाडेटा - IP पते और डोमेन नाम - पर कार्रवाई कर रहे हैं, न कि संचार की सामग्री पर। यह नेटवर्क प्रबंधन के लिए GDPR Article 6 के वैध हितों के आधारों के अनुरूप है, लेकिन आपको अपनी पॉलिसी का दस्तावेजीकरण करना चाहिए और सुनिश्चित करना चाहिए कि इसका उल्लेख आपके नेटवर्क स्वीकार्य उपयोग नीति (acceptable use policy) और गोपनीयता नोटिस में किया गया है। अब, बचने के लिए कुछ सामान्य गलतियाँ। पहली गलती है ओवर-ब्लॉकिंग। जो टीमें पर्याप्त परीक्षण के बिना आक्रामक ब्लॉक लिस्ट तैनात करती हैं, वे अक्सर पाती हैं कि उन्होंने अनजाने में उस ऐप कार्यक्षमता को बाधित कर दिया है जिस पर उपयोगकर्ता निर्भर हैं। हमेशा महत्वपूर्ण सेवाओं के लिए एक अनुमति सूची (allowlist) बनाए रखें, और एक रोलबैक योजना तैयार रखें। दूसरी गलती है 5 GHz और 6 GHz बैंड विभाजन की अनदेखी करना। बैकग्राउंड रीफ्रेश ट्रैफ़िक 2.4 GHz पर केंद्रित होता है क्योंकि पुराने डिवाइस और IoT एंडपॉइंट डिफ़ॉल्ट रूप से उस बैंड का उपयोग करते हैं। यदि आप केवल 5 GHz ट्रैफ़िक का विश्लेषण कर रहे हैं, तो आप समस्या के बड़े हिस्से को अनदेखा कर रहे हैं। सुनिश्चित करें कि आपका विश्लेषण सभी बैंड्स को कवर करता है। तीसरी गलती इसे एक बार का समाधान मानना है। बैकग्राउंड रीफ्रेश ट्रैफ़िक पैटर्न लगातार विकसित होते रहते हैं। छह महीने पहले जो ब्लॉक लिस्ट व्यापक थी, वह वर्तमान एनालिटिक्स एंडपॉइंट्स के 30 प्रतिशत को छोड़ सकती है। अपने नेटवर्क प्रबंधन कैलेंडर में एक समीक्षा प्रक्रिया शामिल करें। अंत में, मैं नेटवर्क आर्किटेक्ट्स से अक्सर सुने जाने वाले कुछ त्वरित प्रश्नों के साथ समाप्त करना चाहूँगा। "क्या एनालिटिक्स ट्रैफ़िक को ब्लॉक करने से मेरे उपयोगकर्ताओं के लिए ऐप प्रदर्शन प्रभावित होगा?" अधिकांश मामलों में, नहीं। एनालिटिक्स बीकन फायर-एंड-फॉरगेट होते हैं। ऐप काम जारी रखने से पहले प्रतिक्रिया की प्रतीक्षा नहीं करता है। उपयोगकर्ता को इसका पता नहीं चलेगा। "क्या यह एन्क्रिप्टेड DNS के साथ काम करता है?" मानक DNS-over-HTTPS ट्रैफ़िक पारंपरिक DNS-आधारित ब्लॉकिंग को बायपास कर सकता है। आपको या तो गेटवे पर DoH को इंटरसेप्ट करना होगा या DNS ब्लॉकिंग के अलावा ज्ञात एनालिटिक्स श्रेणियों के लिए IP-स्तरीय ब्लॉकिंग का उपयोग करना होगा। एंटरप्राइज़-ग्रेड कंट्रोलर्स में दोनों दृष्टिकोण समर्थित हैं।"कॉरपोरेट SSID पर BYOD उपकरणों का क्या होगा?" यही सिद्धांत वहां भी लागू होते हैं, लेकिन आपके पास 802.1X ऑथेंटिकेशन और प्रति-उपयोगकर्ता पॉलिसी लागू करने सहित अतिरिक्त विकल्प होते हैं। कॉरपोरेट SSID के लिए, आप इस बात को लेकर अधिक सख्त हो सकते हैं कि कौन से बैकग्राउंड ट्रैफिक की अनुमति दी जाए। "मैं बोर्ड के सामने इस निवेश को कैसे सही साबित करूँ?" ROI का मामला सीधा है। 30 से 40 प्रतिशत बर्बाद हो रहे एयर टाइम को वापस पाना आपके मौजूदा इंफ्रास्ट्रक्चर में बिना एक भी अतिरिक्त एक्सेस पॉइंट खरीदे 30 से 40 प्रतिशत अधिक क्षमता जोड़ने के बराबर है। एक ऐसे वेन्यू के लिए जो क्षमता की शिकायतों को दूर करने के लिए हार्डवेयर अपग्रेड करने पर विचार कर रहा था, नेटवर्क-लेवल ट्रैफिक मैनेजमेंट उस पूंजीगत व्यय (CAPEX) को दो से तीन साल के लिए टाल सकता है। इस ब्रीफिंग के मुख्य कार्यों को संक्षेप में बताने के लिए। पहला, ट्रैफिक बेसलाइन एनालिसिस चलाएं - आप उसे मैनेज नहीं कर सकते जिसे आप माप नहीं सकते। दूसरा, जाने-माने एनालिटिक्स और विज्ञापन नेटवर्क एंडपॉइंट्स को टारगेट करने वाली एक मेनटेन की गई ब्लॉक लिस्ट तैनात करें। तीसरा, पीक ट्रेडिंग या इवेंट के घंटों के दौरान OS अपडेट ट्रैफिक के लिए रेट-लिमिटिंग का उपयोग करें। चौथा, लगातार मॉनिटर करें और हर तिमाही में अपनी पॉलिसियों को अपडेट करें। और पांचवां, अनुपालन के उद्देश्यों के लिए अपने दृष्टिकोण का दस्तावेजीकरण करें। यदि आप देखना चाहते हैं कि Purple का प्लेटफॉर्म इस डेटा को कैसे प्रदर्शित करता है और मल्टी-साइट एस्टेट्स में पॉलिसी डिप्लॉयमेंट को सक्षम बनाता है, तो लिंक शो नोट्स में दिया गया है। आपके समय के लिए धन्यवाद।