एसएसएल कनेक्शन की उच्च मात्रा को प्रभावी ढंग से लागत

Question

मैंने हाल ही में एक नोड.जेएस आधारित वेब सॉकेट सर्वर स्थापित किया है जिसे एक छोटे ईसी 2 इंस्टेंस (m1.small) पर प्रति सेकंड लगभग 2,000 नए कनेक्शन अनुरोधों को संभालने के लिए परीक्षण किया गया है। M1.small उदाहरण की लागत को ध्यान में रखते हुए, और वेबसॉकेट सक्षम प्रॉक्सी सर्वर जैसे HAProxy के पीछे कई उदाहरण डालने की क्षमता, हम परिणामों से बहुत खुश हैं।

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

इसलिए मैंने पाउंड, स्टनल और स्टड जैसे कई समाधानों को देखा, जिनमें से सभी 443 को आने वाले कनेक्शनों को समाप्त करने की इजाजत देते थे, और फिर पोर्ट 80 पर हैप्रोक्सी पर पहुंचे, जो बदले में वेब पर कनेक्शन पास करता है सर्वर। दुर्भाग्यवश, हालांकि, मैंने पाया कि एक सी 1.मेडियम (हाई सीपीयू) उदाहरण पर एसएसएल टर्मिनेशन प्रॉक्सी सर्वर पर यातायात भेजना बहुत सी जल्दी से सभी सीपीयू संसाधनों का उपभोग करता है, और केवल 50 या उससे अधिक अनुरोधों की दर से। मैंने ऊपर सूचीबद्ध सभी तीन समाधानों का उपयोग करने की कोशिश की, और उनमें से सभी ने वही प्रदर्शन किया जैसा कि मैं हुड के तहत मानता हूं, वे सभी ओपनएसएसएल पर भरोसा करते हैं। मैंने 64 बिट बहुत बड़े उच्च CPU इंस्टेंस (c1.xlarge) का उपयोग करने का प्रयास किया और पाया कि प्रदर्शन केवल लागत के साथ रैखिक रूप से पैमाने पर है। तो ईसी 2 मूल्य निर्धारण के आधार पर, मुझे प्रति सेकेंड 200 एसएसएल अनुरोधों के लिए लगभग $ 600p/मीटर का भुगतान करना होगा, प्रति सेकेंड 2,000 गैर एसएसएल अनुरोधों के लिए $ 60p/m के विपरीत। जब हम प्रति सेकेंड 1,000 या 10,000 अनुरोध स्वीकार करने की योजना बनाते हैं तो पूर्व मूल्य आर्थिक रूप से अभावनीय हो जाता है।

मैंने Node.js 'https सर्वर का उपयोग करके एसएसएल को समाप्त करने का भी प्रयास किया, और प्रदर्शन पाउंड, सुरंग और स्टड के समान था, इसलिए उस दृष्टिकोण के लिए कोई स्पष्ट लाभ नहीं था।

तो मुझे उम्मीद है कि कोई मदद कर सकता है यह सलाह दे रहा है कि मैं इस हास्यास्पद लागत के आसपास कैसे प्राप्त कर सकता हूं जिसे हमें एसएसएल कनेक्शन प्रदान करने के लिए अवशोषित करना है। मैंने सुना है कि एसएसएल हार्डवेयर त्वरक बहुत बेहतर प्रदर्शन प्रदान करते हैं क्योंकि हार्डवेयर एसएसएल एन्क्रिप्शन और डिक्रिप्शन के लिए डिज़ाइन किया गया है, लेकिन जैसा कि हम वर्तमान में हमारे सभी सर्वरों के लिए अमेज़ॅन ईसी 2 का उपयोग कर रहे हैं, एसएसएल हार्डवेयर एक्सेलेरेटर का उपयोग करना एक विकल्प नहीं है जब तक हमारे पास एक अलग डेटा न हो भौतिक सर्वर के साथ केंद्र। मैं सिर्फ यह देखने के लिए संघर्ष कर रहा हूं कि अमेज़ॅन, Google, फेसबुक की पसंद एसएसएल पर अपने सभी ट्रैफिक प्रदान कर सकती है जब इसकी लागत बहुत अधिक होती है। वहां एक बेहतर समाधान होना चाहिए।

कोई सलाह या विचारों की बहुत सराहना की जाएगी।

धन्यवाद मैट

Answer 1

Node.js 'https सर्वर के प्रदर्शन को बहुत पाउंड, stunnel और संवर्धन के लिए समान है, और वहाँ है कि दृष्टिकोण के लिए कोई स्पष्ट लाभ है।

Answer 2

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

Answer 3

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

सभी टीएलएस सिफर सूट बराबर पैदा नहीं होते हैं, कुछ में दूसरों की तुलना में अधिक CPU लागत होती है, चाहे वह मुख्य विनिमय या सिफर से हो। उपयोग किए गए सॉफ़्टवेयर के आधार पर, सर्वर स्वीकार करने वाले सिफर की एक स्ट्रिंग निर्दिष्ट करने का एक तरीका होना चाहिए (और सर्वर को उस पर जोर देने का एक तरीका भी)। OpenSSL के लिए इन इस तरह से काम करते हैं: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS

आप गति के लिए जा रहे हैं, कम से कम सुनिश्चित करें कि आप सिफर कि Diffie-Hellmann (गैर अण्डाकार-वक्र तरह) की-एक्सचेंजों को रोजगार उपयोग नहीं कर रहे हैं। डीएच कुंजी एक्सचेंज का उपयोग करके सिफर सुइट्स को अक्षम करने के लिए, सुनिश्चित करें कि स्ट्रिंग में कुछ बिंदु पर !DH शामिल है। आप परीक्षण कर सकते हैं कि किस स्ट्रिंग परिणाम जिसमें सिफर उपलब्ध हैं, उदाहरण के लिए, openssl ciphers -v 'HIGH:!aNULL:!DH:!ECDH'।

यह स्ट्रिंग सामान्य डिफी-हेलमैन के साथ-साथ एल्लिप्टिक वक्र डिफी-हेलमैन कुंजी एक्सचेंजों को अक्षम करता है। यह आपके ओपनएसएसएल संस्करण के आधार पर केवल आरएसए कुंजी एक्सचेंज छोड़ देता है।

सिफर के संबंध में, आपको शायद अपने इच्छित ईसी 2 हार्डवेयर पर परीक्षण करना चाहिए। हार्डवेयर त्वरण के बिना, आपको शायद एईएस 128 पर एईएस 126 पर आरसी 4 को किसी अन्य चीज़ पर at least according to this benchmark पर पसंद करना चाहिए।

मैं this wonderful post पढ़ने का भी सुझाव देता हूं, विशेष रूप से प्रबुद्ध पहला चित्र जो टीएलएस हैंडशेक प्रदर्शन पर डीएच के प्रभाव को दिखाता है।

अंत में, सुनिश्चित करें कि आप टीएलएस सत्र कैशिंग का उपयोग कर रहे हैं। यह कुछ सीपीयू भी बचाता है।

Answer 4

मुझे एहसास हुआ कि अमेज़ॅन के लोचदार लोड बैलेंसर एसएसएल टर्मिनेशन के लिए बहुत धीमी है ... मैंने www.blitz.io (कोई संबंध नहीं, केवल एक ग्राहक) पर 1 से 250 समवर्ती कनेक्शन के साथ एक साधारण परीक्षण किया। यह बहुत असफल रहा ... लेकिन अगर मैं ईएलबी के सामने के अंत में टीसीपी 443 और बैकएंड 443 पर बैकएंड पर कोई सर्टिफिकेट नहीं करता हूं, तो उस उदाहरण पर आईआईएस और एसएसएल प्रमाण चलाते समय यह एक छोटे से इंस्टेंस के सीपीयू को मिटा देता है। मुझे सिर्फ हैंडशेक की ज़रूरत है, यह एक साधारण वेब सेवा है जो सभी जगहों पर ग्राहकों की सेवा करती है। हर बार नया कनेक्शन सेटअप और टियरडाउन।

मैं उच्च ट्रैफिक एसएसएल वेब सेवा कैसे डिजाइन कर सकता हूं, अधिमानतः एसएसएल के साथ सख्त सुरक्षा अनुपालन के लिए बैकएंड के लिए सभी तरह से?