2009-07-28 25 views
44

मेरे पास आईआईएस पर बैठा एक वेब एप्लिकेशन है, और [रिमोट] सर्विस-मशीन के साथ बात कर रहा है। मुझे यकीन नहीं है कि मुख्य प्रोटोकॉल के रूप में टीसीपी या एचटीपी चुनना है या नहीं।टीसीपी बनाम। एचटीपी बेंचमार्क

अधिक जानकारी के:

  1. मैं एक से अधिक सेवा \ endpoint
  2. उनमें से कुछ हो जाएगा एक तरह से
  3. अन्य हो जाएगा दो तरीके होंगे
  4. वेब पृष्ठों सेवाओं के सामने काम करेंगे
  5. हम उच्च पैमाने वेब साइट के बारे में बात कर रहे हैं

मुझे अंतर बहुत अच्छी तरह से पता है, लेकिन मैं एक अच्छा बेंचमार्क ढूंढ रहा हूं, जो दिखाता है कि टीसीपी कितनी तेजी से है?

+0

यह निर्भर करता है कि आप क्या करना चाहते हैं। क्या आपके पास वेब-ऐप की सेवा की सेवा के बारे में अधिक जानकारी है? अनुरोध एक शॉट (यानी, प्रश्न, प्रतिक्रिया) हैं या कई प्रश्नों और प्रतिक्रियाओं के साथ बातचीत होती है? –

उत्तर

68

HTTP टीसीपी परत के ऊपर की ओर एक परत है जो डेटा ट्रांसमिशन को मानकीकृत करता है। तो स्वाभाविक रूप से टीसीपी सॉकेट का उपयोग HTTP का उपयोग करने से कम भारी होगा। यदि प्रदर्शन एकमात्र चीज है जिसके बारे में आप परवाह करते हैं तो सादा टीसीपी आपके लिए सबसे अच्छा समाधान है।

आप उपयोग की आसानी और सादगी के कारण HTTP पर विचार करना चाहेंगे जो अंततः विकास के समय को कम कर देता है। यदि आप ऐसा कुछ कर रहे हैं जो सीधे ब्राउज़र द्वारा उपयोग किया जा सकता है (AJAX कॉल के माध्यम से) तो आपको HTTP का उपयोग करना चाहिए। गैर-आधुनिक ब्राउज़र के लिए सीधे HTTP के बिना टीसीपी कनेक्शन का उपभोग करने के लिए आपको फ्लैश या सिल्वरलाइट का उपयोग करना होगा और यह आमतौर पर समृद्ध सामग्री जैसे वीडियो और/या ऑडियो के लिए होता है। हालांकि, अब कई आधुनिक ब्राउज़र (2013 तक) जावास्क्रिप्ट के माध्यम से सीधे नेटवर्क, ऑडियो और वीडियो संसाधनों तक पहुंचने के लिए एपीआई का समर्थन करते हैं। विचार करने की एकमात्र चीज आपके उपयोगकर्ताओं के बीच आधुनिक वेब ब्राउज़र की उपयोग दर है; ब्राउज़र संगतता के बारे में नवीनतम जानकारी के लिए caniuse.com देखें।

बेंचमार्क के लिए, this एकमात्र चीज है जो मैंने पाया। पेज 5 देखें, इसमें प्रदर्शन ग्राफ है। ध्यान दें कि यह वास्तव में सेब से सेब की तुलना नहीं करता है क्योंकि यह HTTP/XML डेटा विकल्प के साथ टीसीपी/बाइनरी डेटा विकल्प की तुलना करता है। जो सवाल पूछता है: आपकी सेवाओं का किस प्रकार का डेटा आउटपुट होता है? बाइनरी (वीडियो, ऑडियो, फाइलें) या पाठ (जेएसओएन, एक्सएमएल, एचटीएमएल)?

सामान्य प्रदर्शन उन्मुख प्रणाली में सैन्य या वित्तीय क्षेत्रों की तरह शायद सादे टीसीपी कनेक्शन का उपयोग करेंगे। जहां सामान्य वेब केंद्रित कंपनियां HTTP का उपयोग करने का विकल्प चुनती हैं और आईआईएस या अपाचे का उपयोग अपनी सेवाओं को होस्ट करने के लिए करती हैं।

+0

आप 'WebSocket' कच्चे TCP कनेक्शन और कैनवास/WebGL क्या करना है की तुलना से लाभ उठा सकती एक ब्राउज़र में जावास्क्रिप्ट का उपयोग कर समृद्ध सामग्री के लिए। –

+9

सच; 4 साल के अपने मूल पोस्ट के बाद यह अब संभव है ऑडियो, वीडियो, और नेटवर्क एपीआई जे एस और एचटीएमएल 5 सुविधाओं (WebSocket, WebGL, कैनवास, ऑडियो, खींचें और छोड़ें, WebWorkers पर, WebRTC, जियोलोकेशन, वेब संग्रहण, TypedArrays, आदि का उपयोग कर का उपयोग करने की) – Darwyn

+0

धन्यवाद इस अच्छा स्पष्टीकरण के लिए Darwyn। मेरी कई गलत धारणाओं को साफ़ करता है। क्या आप जावास्क्रिप्ट के माध्यम से सीधे "एपीआई नेटवर्क, ऑडियो और वीडियो संसाधनों तक पहुंचने के लिए थोड़ा सा विस्तार कर सकते हैं।" – akshay

6

आप इसे हमेशा बेंचमार्क कर सकते हैं।

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

प्लस, HTTP चश्मा सभी प्रकार की विशेषताओं को परिभाषित करता है (और क्लाइंट/सर्वर लागू करता है, जिसे आप "मुफ्त में" उपयोग करने के लिए उपयोग करते हैं, यानी कोई अतिरिक्त कार्यान्वयन कार्य नहीं करता है) जो किसी भी तृतीय-पक्ष इंटरऑपरेबिलिटी को इतना आसान बनाता है। "यहां मेरा यूआरएल है, जो आप भेजते हैं उसके नियम यहां दिए गए हैं, यहां मैं जो भी लौटाता हूं, उसके नियम यहां हैं ..."

+2

चेतावनी - यदि यह एक वार्तालाप है, तो HTTP कुशल नहीं हो सकता है - हर बार एक टीसीपी कनेक्शन खोलने के माध्यम से HTTP में एकाधिक अनुरोध महंगा होता है और मैंने संसाधनों को भूख से देखा है क्योंकि अंतर्निहित टीसीपी कनेक्शन साफ़ रूप से बंद नहीं हैं। हां, HTTP/1.1 अधिक अनुरोधों के लिए कनेक्शन को खोलने का समर्थन करता है, लेकिन यह स्पष्ट नहीं है कि यह अन्य सेवा इसका समर्थन करती है या नहीं। –

+2

यह सच है, हालांकि यदि अन्य सर्वर इसका समर्थन करता है, तो वह उन "मुक्त" अनुकूलन में से एक है। चूंकि कनेक्शन साफ ​​रूप से बंद नहीं किए जा रहे हैं, यह लाइब्रेरी में एक बग है, और यह एक गंभीर समस्या होगी, लेकिन फिर से "रोल-अप-खुद" केस को हर संभावित स्थिति से सावधान रहना होगा जिसके परिणामस्वरूप एक ही संसाधन हो सकता है भुखमरी। –

+0

मुझे यकीन नहीं है कि कार्यान्वयन में आपका क्या मतलब है ?! ... तो यह पहले से ही लागू किया और परीक्षण किया जाता है यह सिर्फ WCF और net.tcp उपयोग करने के लिए करता है, तो यह तेजी से हो जाएगा (और यदि आवश्यक हो जावा प्रॉक्सी बनाने) या शायद हम जावा के लिए कार्यान्वयन है लानत सरल है, बस की जरूरत है फैसला करो, है ना? – rabashani

29

प्रश्न के लिए आपको वास्तव में एक उत्तर की आवश्यकता है "क्या टीसीपी या HTTP के लिए तेज़ होगा आवेदन "। जवाब यह है कि यह आपके आवेदन की प्रकृति पर निर्भर करता है, और जिस तरह से आप अपने आवेदन में टीसीपी और/या HTTP का उपयोग करते हैं। एक सामान्य HTTP बनाम टीसीपी बेंचमार्क आपके प्रश्न का उत्तर नहीं देगा, क्योंकि संभावना है कि बेंचमार्क आपके एप्लिकेशन व्यवहार से मेल नहीं खाएगा।

सिद्धांत रूप में, टीसीपी का उपयोग करके एक बेहतर रूप से डिज़ाइन/कार्यान्वित समाधान HTTP से उपयोग करने वाले एक से अधिक तेज़ होगा। लेकिन यह आपके आवेदन के ब्योरे के आधार पर लागू करने के लिए भी काफी काम हो सकता है।

अन्य समस्याएं हैं जो आपकी पसंद को प्रभावित कर सकती हैं। उदाहरण के लिए, यदि आप कुछ यादृच्छिक बंदरगाह पर टीसीपी का उपयोग करते हैं, तो आप HTTP का उपयोग करते हुए फ़ायरवॉल समस्याओं में भागने की संभावना कम हैं। दूसरा यह है कि HTTP आईआईएस सर्वर और बैकएंड सिस्टम के बीच लोड बैलेंसर को कार्यान्वित करना आसान बना देगा।

अंत में, दिन के अंत में यह संभवतः अधिक महत्वपूर्ण है कि आपका सिस्टम विश्वसनीय, रखरखाव योग्य और (शायद) स्केलेबल है जितना तेज़ है। एक समझदार रणनीति पहले सरल संस्करण को लागू करना है, लेकिन इसे अपने सिर में तेजी से बनाने के लिए योजना है ... यदि सरल समाधान बहुत धीमा है।

+2

के रूप में जोखिम भरा आप एसएसएल और प्राधिकरण implementions जो महत्वपूर्ण जोखिम और प्रयास कम कर देता है स्व-निर्मित समाधान –

संबंधित मुद्दे