सबसे छोटा संभव http और https डेटा अनुरोध

Question

कहता है कि मैं http प्रोटोकॉल का उपयोग कर सर्वर से एक बाइट प्राप्त करना चाहता हूं और मैं सब कुछ कम करना चाहता हूं, कोई शीर्षलेख केवल http://myserver.com/b नहीं है जहां बी एक वर्ण फ़ाइल है जिसमें एक वर्ण है , या बेहतर अभी भी बी सिर्फ एक चरित्र है (सुनिश्चित नहीं है कि यह संभव है)। क्या अपाचे के साथ ऐसा करने का कोई तरीका है और पूर्ण http के लिए आवश्यक डेटा की सबसे छोटी मात्रा और पूर्ण https लेनदेन क्या है? वैकल्पिक रूप से, यदि लेनदेन अधिक डेटा कुशल है तो लेन-देन केवल एक प्रमुख अनुरोध के साथ किया जा सकता है।

Answer 1

आप वास्तव में क्या हासिल करने की कोशिश कर रहे हैं, क्या यह जीवित रहने का एक प्रकार है?

आप "GET /" कर सकते हैं, जिसका अर्थ है HTTP/1.0 का उपयोग किया जा रहा है, लेकिन यह आपको आभासी होस्टिंग आदि जैसी चीजों से बाहर निकाल देता है। आप एक cgi-script में "/" मैप कर सकते हैं, इसकी आवश्यकता नहीं है आप जो हासिल करने की कोशिश कर रहे हैं उसके आधार पर एक असली फ़ाइल बनने के लिए। आप अपाचे को केवल शीर्षकों के न्यूनतम सेट को वापस करने के लिए कॉन्फ़िगर कर सकते हैं, जो मूल रूप से "सामग्री-प्रकार: टेक्स्ट/सादा" (या दूसरा, छोटा माइम प्रकार, संभावित रूप से कस्टम माइमटाइप जैसे "सामग्री-प्रकार: ए/बी") और " सामग्री-लंबाई: 0 ", इस प्रकार प्रतिक्रिया प्रतिक्रिया वापस नहीं आती है।

Answer 2

यदि आप HTTP/1.1 (वर्चुअल होस्ट पर समाप्त होने पर अधिक या कम आवश्यकता) का उपयोग करने की योजना बना रहे हैं, तो आपके GET अनुरोध को होस्ट नाम होना चाहिए, या तो Host शीर्षलेख में या एक पूर्ण यूआरआई के रूप में अनुरोध लाइन में (RFC 2616 section 5.1.2 देखें)।

आपकी प्रतिक्रिया को Content-Length या transfer encoding headers and delimiters की भी आवश्यकता होगी।

यदि आप HEAD अनुरोध का उपयोग करके HTTP को "तोड़ने" के लिए तैयार हैं, तो ऐसा लगता है कि HTTP प्रोटोकॉल का सबसे अच्छा विकल्प नहीं हो सकता है। आप कस्टम हेडर में कुछ भी वापस करने में सक्षम हो सकते हैं, लेकिन यह करने का एक साफ तरीका नहीं है।

ध्यान दें कि, यदि आप अपना प्रोटोकॉल लागू करते हैं, तो आपको Content-Length या चंकित एन्कोडिंग प्रदान करने के समान तंत्र को कार्यान्वित करने की आवश्यकता होगी, यह निर्धारित करने में सक्षम होने के लिए कि दूरस्थ पार्टी से पढ़ना बंद करना कब है (अन्यथा, आप ' बुरी तरह से बंद कनेक्शन का पता लगाने में सक्षम हो)।

संपादित करें:

यहाँ, एक त्वरित उदाहरण है यह आपके होस्ट नाम पर निर्भर करती है (यह मानते हुए HTTP 1.1)। मुझे लगता है कि आप इसके बजाय OPTIONS का उपयोग कर सकते हैं। यह आप कितना HTTP तोड़ने के लिए तैयार हैं पर निर्भर करता है ...

अनुरोध:

GET/HTTP/1.1 
Host: www.example.com 

14 + 2 + 21 + 2 + 2 = 41 बाइट (CRLF के लिए 2)

है कि उत्तर:

HTTP/1.1 200 OK 
Content-Length: 1 
Content-Type: text/plain 

a 

है यही कारण है कि 15 + 2 + 17 + 2 + 24 + 2 + 2 + 1 = 65 बाइट्स

HTTPS के लिए, वहाँ ख होगा ईएसएल/टीएलएस चैनल के लिए एक छोटा ओवरहेड, लेकिन इसमें से अधिकांश हैंडशेक द्वारा लिया जाएगा, विशेष रूप से, सर्वर प्रमाण पत्र (माना जाता है कि आप क्लाइंट-प्रमाणपत्र प्रमाणीकरण का उपयोग नहीं कर रहे हैं) सबसे बड़ा होना चाहिए। अपने प्रमाणपत्र के आकार (डीईआर प्रारूप में) की जांच करें।

Answer 3

यह एक पुराना सवाल है, लेकिन शायद किसी को यह उपयोगी लगे, क्योंकि किसी ने भी सवाल के HTTPS भाग का जवाब नहीं दिया है।

मेरे लिए यह मेरी प्रॉक्सी में HTTPS संचार की एक आसान सत्यापन के लिए आवश्यक था, जो सुरंग के माध्यम से अविश्वसनीय अन्य प्रॉक्सी को जोड़ता है।

इस साइट में यह स्पष्ट रूप से बताते हैं: लेख से http://netsekure.org/2010/03/tls-overhead/

उद्धरण: को प्रभावित करती है कि गणना के संदेशों के अधिकांश के चर आकार है को ध्यान में रखना

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

• क्लाइंटहेल्लो - प्रारंभिक क्लाइंट हैलो का औसत आकार लगभग 160 से 170 बाइट है। यह क्लाइंट द्वारा भेजे गए सिफरुइट्स की संख्या के साथ-साथ कितने टीएलएस क्लाइंटहेल्लो एक्सटेंशन मौजूद हैं, के आधार पर अलग-अलग होंगे। यदि सत्र बहाली का उपयोग किया जाता है, तो सत्र आईडी फ़ील्ड के लिए 32 बाइट्स जोड़े जाने की आवश्यकता है।
• सर्वरहेल्लो - यह संदेश क्लाइंटहेल्लो की तुलना में थोड़ा अधिक स्थिर है, लेकिन अभी भी टीएलएस एक्सटेंशन के कारण परिवर्तनीय आकार है। औसत आकार 70 से 75 बाइट है। - प्रमाण पत्र - यह संदेश वह है जो विभिन्न सर्वरों के बीच आकार में सबसे अधिक भिन्न होता है। संदेश में सर्वर का प्रमाण पत्र, साथ ही प्रमाण पत्र श्रृंखला में सभी इंटरमीडिएट जारीकर्ता प्रमाणपत्र (रूट रूट से कम) होता है। चूंकि प्रमाण पत्र आकार पैरामीटर और चाबियों के आधार पर काफी भिन्न होते हैं, इसलिए मैं प्रति प्रमाणपत्र औसतन 1500 बाइट्स का उपयोग करता हूं (स्वयं हस्ताक्षरित प्रमाणपत्र 800 बाइट्स के रूप में छोटे हो सकते हैं)। अन्य अलग-अलग कारक रूट प्रमाण पत्र तक प्रमाणपत्र श्रृंखला की लंबाई है। वेब पर क्या है इसके अधिक रूढ़िवादी पक्ष पर रहने के लिए, चलो श्रृंखला में 4 प्रमाण पत्र मान लें। कुल मिलाकर यह हमें इस संदेश के लिए लगभग 6k देता है।
• क्लाइंटकी एक्सचेंज - आइए फिर से सबसे व्यापक रूप से उपयोग किए जाने वाले मामले - आरएसए सर्वर प्रमाण पत्र मान लें। यह इस संदेश के लिए 130 बाइट्स के आकार के अनुरूप है।
• ChangeCipherSpec - 1 का निश्चित आकार (तकनीकी रूप से एक हैंडशेक संदेश नहीं)
• समाप्त - एसएसएलवी 3 का उपयोग किया जाता है या टीएलएस के आधार पर, आकार क्रमश: 36 और 12 बाइट्स भिन्न होता है।
  : अधिकांश कार्यान्वयन इन दिनों समर्थन TLSv1.0 कम से कम, तो चलो टीएलएस इस्तेमाल किया जाएगा और इसलिए बड़े आकार 12 बाइट्स हो जाएगा

तो कम से कम के रूप में बड़ी (या छोटे) हो सकता है के रूप में ग्रहण करते हैं

20 + 28 + 170 + 75 + 800 + 130 + 2*1 + 2*12 ≈ 1249 

हालांकि लेख के अनुसार, औसत 6449 बाइट्स है।

यह भी जानना महत्वपूर्ण है कि टीएलएस सत्र फिर से शुरू किए जा सकते हैं, इसलिए केवल पहले कनेक्शन में यह ओवरहेड है। अन्य सभी संदेशों में 330 बाइट्स प्लस है।