शक्ति प्रशिक्षण: उच्च भार के तहत HTTPS को रोल करें

सितंबर में, Mail.Ru मेल ने सभी उपयोगकर्ताओं के लिए HTTPS एन्क्रिप्शन सक्षम किया।

एक सुरक्षित कनेक्शन के फायदे बड़ी इंटरनेट परियोजनाओं के सभी डेवलपर्स के लिए स्पष्ट हैं। अधिकांश आधुनिक वेब सर्वर (nginx, Apache, आदि) और ब्राउज़र HTTPS का समर्थन करते हैं। इसी समय, कई साइटें नहीं हैं, जिन पर सुरक्षित प्रोटोकॉल हमेशा सक्षम और डिफ़ॉल्ट रूप से होता है। ऐसा क्यों है? हमने एचटीटीपीएस समर्थन के साथ किन चुनौतियों का सामना किया? कट के नीचे पढ़ें।

अत्यधिक लोड सिस्टम पर एसएसएल की विशेषताएं

वास्तव में, HTTPS SSL नेटवर्क लेयर पर एक सामान्य HTTP प्रोटोकॉल है, जो एन्क्रिप्शन द्वारा एक असुरक्षित नेटवर्क चैनल को सुरक्षित बनाने की अनुमति देता है।

SSL का समर्थन करने के लिए क्या करने की आवश्यकता है?

ऐसा लगता है कि यह एक प्रमाण पत्र का आदेश देने के लिए पर्याप्त है, इसे सर्वरों में विघटित करना, nginx में विकल्प को सक्षम करना और सुरक्षित यातायात की दुनिया में आपका स्वागत है। लेकिन वास्तव में, सब कुछ इतना सरल नहीं है। या बल्कि, ऐसा नहीं है: सब कुछ सरल होगा यदि किसी कारण से हमें "हैलो दुनिया" पाठ के साथ एक स्थिर पृष्ठ को सुरक्षित करने की आवश्यकता हो। लेकिन बहुत सी विविध सामग्री, जैसे Mail.Ru Mail, के साथ अत्यधिक भरी हुई प्रणाली के लिए, सबसे दिलचस्प हिस्सा तब शुरू होता है जब प्रमाण पत्र पहले ही खरीद लिए जाते हैं और रख दिए जाते हैं।

Mail.Ru मेल और "हैलो वर्ल्ड" वाले काल्पनिक पेज में क्या अंतर है? वास्तव में, HTTPS समर्थन के संदर्भ में दो मुख्य अंतर हैं। सबसे पहले, मेल में कई पृष्ठ होते हैं - दर्जनों: पत्रों की एक सूची, अक्षर स्वयं, सेटिंग्स, पता पुस्तिका, आदि, और प्रत्येक पृष्ठ में सैकड़ों तत्व (चित्र, जेएस-उपनाम, सीएसएस-एस, आदि) हैं। । दूसरे, मेल एक बहुत बड़े लोड के तहत चलता है, प्रति सेकंड हजारों HTTP अनुरोधों को संसाधित करता है (सहित, निश्चित रूप से, स्थिर अनुरोध)। इन दो पहलुओं के कारण, HTTPS समर्थन का कार्यान्वयन एक ऐसा मुश्किल था।

ये पहलू समर्थन को कैसे प्रभावित करते हैं? पहला पहलू निम्नानुसार प्रभावित करता है: जब पृष्ठ एकल होता है, तो सर्वर में एक प्रमाण पत्र होता है, ब्राउज़र इसे समझता है, सब कुछ काम करता है। समस्या तब शुरू होती है जब कई पृष्ठ होते हैं और, इसके अलावा, जब इन पृष्ठों में बाहरी तत्व होते हैं जो इस पृष्ठ के संदर्भ में चलते हैं। ब्राउज़र का मानना ​​है कि कनेक्शन केवल तभी सुरक्षित है जब पृष्ठ पर अंतिम सभी तत्व सुरक्षित प्रोटोकॉल का उपयोग करके प्रस्तुत किए गए थे: यह सभी छवियों, जेएस, सीएसएस, आदि पर लागू होता है। यदि असुरक्षित प्रोटोकॉल पर कम से कम एक तत्व दिया गया था, तो ब्राउज़र पूरे पृष्ठ को असुरक्षित मानेगा और उपयोगकर्ता को इसके बारे में सूचित करेगा।

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

इससे कैसे निपटें?

बैनर प्रणाली

मेल एक विषम निर्माण है। हमारा अपना बैनर सिस्टम है। यह केवल एक मेल प्रणाली नहीं है, बल्कि Mail.Ru पोर्टल की सामान्य बैनर प्रणाली है, जिसने किसी भी HTTPS के बारे में कुछ भी नहीं सुना है। यह देखते हुए कि हमें HTTPS के माध्यम से सभी पृष्ठों से सभी डेटा भेजने थे, बैनर प्रणाली को काफी हद तक संशोधित करना था।

इस तथ्य के अलावा कि हमने HTTPS के माध्यम से सभी बैनर्स, स्क्रिप्ट और स्टैटिक्स को रेंडर करने के लिए वेब सर्वर सिखाया, हमें पार्टनर पिक्सल से निपटना था। एक पिक्सेल एक 1x1 चित्र है जो एक साथी प्रदान करता है और एक बैनर प्रदर्शित होने पर वह जुड़वाँ होता है। यह ध्यान दिया जाना चाहिए कि हमारे सभी साथी HTTPS पर काम नहीं करते हैं, और, जैसा कि मैंने पहले ही नोट किया है, पृष्ठ पर असुरक्षित तत्व नहीं होने चाहिए, भले ही वे आकार में 1x1 पिक्सेल हों। बेशक, सभी पिक्सल को एक प्रॉक्सी के माध्यम से पारित करना संभव था, लेकिन सबसे पहले हम एक सरल तरीके से गए। हम भागीदारों के साथ सहमत हुए, उन्हें समझाया कि यह सब कितना अद्भुत और आवश्यक है, और अब वे हमारे लिए HTTPS पिक्सेल वितरित कर रहे हैं। बेशक, यह आसान काम नहीं था, लेकिन यह काम कर गया। सच है, अब नए भागीदारों को सिखाना आवश्यक है कि तस्वीर का लिंक सुरक्षित होना चाहिए।

बैनर के साथ एक और समस्या है: उन्हें न केवल तकनीकी विशेषज्ञों द्वारा दर्ज किया जा सकता है, बल्कि कंप्यूटर साक्षरता के विभिन्न स्तरों वाले अन्य कर्मचारी। तदनुसार, एक संभावना है कि बैनर, गैर-एसएसएल छवियों, जेएस, असुरक्षित काउंटर के साथ पृष्ठ पर अच्छी तरह से दिखाई दे सकते हैं।

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

सर्वव्यापी HTTPS

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

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

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

इसके अलावा, हमें My World परियोजना के SSL भाग में स्थानांतरित करना पड़ा, जिसमें से मेल के रूप में अवतार प्राप्त होता है, साथ ही सर्वर जिन पर लॉगिंग सिस्टम तैनात है। इसके अलावा, वेब एजेंट और सर्वर, जिसमें से संलग्नक और उनके पूर्वावलोकन लोड किए गए हैं, एसएसएल पर स्विच किए जाते हैं।

इस तथ्य के अलावा कि यह नोट करना दिलचस्प है, हमने मोबाइल उपकरणों पर स्मार्ट एसएसएल समर्थन बनाया है। सभी मोबाइल डिवाइस एसएसएल के साथ सही तरीके से काम नहीं करते हैं, और हमने एक प्रणाली विकसित की है जो सर्वर-साइड कोड से डिवाइस का प्रकार निर्धारित करता है और परिणाम के आधार पर कार्य करता है।

फिलहाल, iPhone और iPad पर समर्थन शामिल है, अन्य मोबाइल उपकरणों में कुछ समस्याएं हैं जिन पर हम काम कर रहे हैं। यह घंटा दूर नहीं है जब सभी आधुनिक मोबाइल डिवाइस Mail.Ru मेल HTTPS के माध्यम से डिफ़ॉल्ट रूप से काम करेंगे।

अनुकूलन

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

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

फिर हमने एक लंबे समय के लिए एक आईपी पते के लिए प्रमुख डेटा का पुन: उपयोग करके हैंडशेक के समय को कम करने के लिए एक एसएसएल कैश बनाया।

और अंत में, मैं एक छोटी सी हैक के बारे में बात करूंगा जिसने उत्पादकता में भी काफी वृद्धि की है। हमने / dev / random / / dev / urandom से एक लिंक बनाया। यह तेजी से काम करता है क्योंकि / dev / random अवरुद्ध है, / dev / urandom अवरुद्ध नहीं है। इसलिए, I / O प्रतीक्षा कम हो गई है। और चूंकि हमारे वेब सर्वर पर डिस्क पर्याप्त रूप से भरी हुई है (लॉगिंग, आने वाले स्टैटिक्स, सेविंग अटैचमेंट्स इत्यादि के कारण), अतिरिक्त I / O प्रतीक्षा का पूरे सर्वर के संचालन पर महत्वपूर्ण प्रभाव पड़ता है।

निष्कर्ष

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

यदि आपके पास अभी भी उच्च भार के तहत HTTPS के कार्यान्वयन के बारे में प्रश्न हैं, तो उन्हें टिप्पणियों में पूछें, मैं खुशी के साथ उत्तर दूंगा।

डेनिस एनिकिन,
Mail.ru मेल के तकनीकी निदेशक