एचटीटीपी कम्प्रेशन: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Capability that can be built into web servers and web clients}} {{HTTP}} HTTP संपीड़न एक क्षमता है जिसे स्थ...")
 
m (Deepak moved page HTTP संपीड़न to एचटीटीपी संपीड़न without leaving a redirect)
(No difference)

Revision as of 14:53, 4 August 2023

HTTP संपीड़न एक क्षमता है जिसे स्थानांतरण गति और बैंडविड्थ उपयोग में सुधार के लिए वेब सर्वर और वेब क्लाइंट में बनाया जा सकता है।[1] HTTP डेटा सर्वर से भेजे जाने से पहले डेटा संपीड़न है: अनुरूप ब्राउज़र यह घोषणा करेंगे कि सही प्रारूप डाउनलोड करने से पहले सर्वर पर कौन से तरीके समर्थित हैं; जो ब्राउज़र अनुपालक संपीड़न विधि का समर्थन नहीं करते वे असंपीड़ित डेटा डाउनलोड करेंगे। सबसे आम संपीड़न योजनाओं में गgzip और भाईचारे से शामिल हैं; उपलब्ध योजनाओं की पूरी सूची इंटरनेट निरुपित नंबर प्राधिकरण द्वारा रखी जाती है।[2] HTTP में दो अलग-अलग तरीकों से संपीड़न किया जा सकता है। निचले स्तर पर, ट्रांसफर-एन्कोडिंग हेडर फ़ील्ड यह संकेत दे सकता है कि HTTP संदेश का पेलोड संपीड़ित है। उच्च स्तर पर, एक सामग्री-एन्कोडिंग हेडर फ़ील्ड यह संकेत दे सकता है कि स्थानांतरित किया जा रहा संसाधन, वेब कैशिंग, या अन्यथा संदर्भित संपीड़ित है। कंटेंट-एनकोडिंग का उपयोग करके संपीड़न ट्रांसफर-एनकोडिंग की तुलना में अधिक व्यापक रूप से समर्थित है, और कुछ ब्राउज़र सर्वर में बग को ट्रिगर करने से बचने के लिए ट्रांसफर-एनकोडिंग संपीड़न के लिए समर्थन का विज्ञापन नहीं करते हैं।[3]


संपीड़न योजना वार्ता

बातचीत दो चरणों में की जाती है, जिसका वर्णन RFC 2616 और RFC 9110 में किया गया है:

1. वेब क्लाइंट HTTP अनुरोध में टोकन की एक सूची शामिल करके विज्ञापन देता है कि वह कौन सी संपीड़न योजनाओं का समर्थन करता है। सामग्री-एनकोडिंग के लिए, सूची एक्सेप्ट-एनकोडिंग नामक फ़ील्ड में है; ट्रांसफर-एन्कोडिंग के लिए, फ़ील्ड को TE कहा जाता है। <सिंटैक्सहाइलाइट लैंग= http हाइलाइट=3> /एन्क्रिप्टेड-क्षेत्र HTTP/1.1 प्राप्त करें होस्ट: www.example.com स्वीकार-एन्कोडिंग: gzip, डिफ्लेट </सिंटैक्सहाइलाइट> 2. यदि सर्वर एक या अधिक संपीड़न योजनाओं का समर्थन करता है, तो आउटगोइंग डेटा को दोनों पक्षों द्वारा समर्थित एक या अधिक तरीकों से संपीड़ित किया जा सकता है। यदि यह मामला है, तो सर्वर उपयोग की गई योजनाओं के साथ HTTP प्रतिक्रिया में एक सामग्री-एनकोडिंग या ट्रांसफर-एनकोडिंग फ़ील्ड जोड़ देगा, जिसे अल्पविराम से अलग किया जाएगा।

<सिंटैक्सहाइलाइट लैंग= http हाइलाइट=9> HTTP/1.1 200 ठीक है दिनांक: सोमवार, 26 जून 2016 22:38:34 जीएमटी सर्वर: अपाचे/1.3.3.7 (यूनिक्स) (रेड-हैट/लिनक्स) अंतिम-संशोधित: बुधवार, 08 जनवरी 2003 23:11:55 GMT स्वीकार-श्रेणियाँ: बाइट्स सामग्री-लंबाई: 438 कनेक्शन: बंद करें सामग्री-प्रकार: टेक्स्ट/एचटीएमएल; वर्णसेट=यूटीएफ-8 सामग्री-एन्कोडिंग: gzip </सिंटैक्सहाइलाइट>

वेब सर्वर किसी भी तरह से किसी भी संपीड़न विधि का उपयोग करने के लिए बाध्य नहीं है - यह वेब सर्वर की आंतरिक सेटिंग्स पर निर्भर करता है और संबंधित वेबसाइट की आंतरिक वास्तुकला पर भी निर्भर हो सकता है।

सामग्री-एन्कोडिंग टोकन

सर्वर और क्लाइंट के लिए उपलब्ध टोकन की आधिकारिक सूची IANA द्वारा रखी जाती है,[4] और इसमें शामिल हैं:

  • br - ब्रॉटली, एक संपीड़न एल्गोरिदम जो विशेष रूप से HTTP सामग्री एन्कोडिंग के लिए डिज़ाइन किया गया है, में परिभाषित किया गया है RFC 7932 और सभी आधुनिक प्रमुख ब्राउज़रों में लागू किया गया।
  • संकुचित करें - UNIX कंप्रेस प्रोग्राम विधि (ऐतिहासिक; अधिकांश अनुप्रयोगों में अप्रचलित और gzip या हवा निकालना द्वारा प्रतिस्थापित)
  • डिफ्लेट - डिफ्लेट एल्गोरिथम पर आधारित संपीड़न (में वर्णित है)। RFC 1951), LZ77_and_LZ78#LZ77 एल्गोरिदम और हफमैन कोडिंग का एक संयोजन, जो zlib डेटा प्रारूप के अंदर लपेटा गया है (RFC 1950);
  • exi - W3C कुशल XML इंटरचेंज
  • जीज़िप - जीएनयू ज़िप प्रारूप (में वर्णित है)। RFC 1952). संपीड़न के लिए डिफ्लेट एल्गोरिदम का उपयोग करता है, लेकिन डेटा प्रारूप और चेकसम एल्गोरिदम डिफ्लेट सामग्री-एन्कोडिंग से भिन्न होता है। मार्च 2011 तक यह पद्धति सर्वाधिक व्यापक रूप से समर्थित है।[5]
  • पहचान फ़ंक्शन - किसी परिवर्तन का उपयोग नहीं किया जाता है। यह सामग्री कोडिंग के लिए डिफ़ॉल्ट मान है.
  • पैक200|पैक200-जीज़िप - जावा अभिलेखागार के लिए नेटवर्क स्थानांतरण प्रारूप[6]
  • zstd - Zstandard संपीड़न, में परिभाषित RFC 8478

इनके अलावा, सर्वर या क्लाइंट द्वारा कई अनौपचारिक या गैर-मानकीकृत टोकन का उपयोग किया जाता है:

  • Bzbq - मुफ़्त बीज़िप2 प्रारूप पर आधारित संपीड़न, lighttpd द्वारा समर्थित[7]
  • लेम्पेल-ज़िव-मार्कोव_चेन_एल्गोरिदम - (कच्चे) एलजेडएमए पर आधारित संपीड़न ओपेरा 20 में उपलब्ध है, और एक संकलन-समय विकल्प के माध्यम से एलिंक्स में उपलब्ध है[8]
  • पीडिस्ट[9] - माइक्रोसॉफ्ट पीयर कंटेंट कैशिंग और पुनर्प्राप्ति
  • rsync[10] - Delta_encoding#Delta_encoding_in_HTTP, rproxy प्रॉक्सी की एक जोड़ी द्वारा कार्यान्वित।
  • एक्सप्रेस - माइक्रोसॉफ्ट कम्प्रेशन प्रोटोकॉल का उपयोग विंडोज 8 और बाद में विंडोज स्टोर एप्लिकेशन अपडेट के लिए किया जाता है। वैकल्पिक रूप से हफ़मैन एन्कोडिंग का उपयोग करके LZ77_and_LZ78#LZ77-आधारित संपीड़न।[11]
  • XZ यूटिल्स - LZMA2-आधारित सामग्री संपीड़न, एक गैर-आधिकारिक फ़ायरफ़ॉक्स पैच द्वारा समर्थित;[12] और 2013-12-31 से एमजीईटी में पूरी तरह से लागू किया गया।[13]


सर्वर जो HTTP संपीड़न का समर्थन करते हैं

कई सामग्री वितरण नेटवर्क अंतिम उपयोगकर्ताओं तक संसाधनों की त्वरित डिलीवरी को बेहतर बनाने के लिए HTTP संपीड़न भी लागू करते हैं।

HTTP में संपीड़न PHP जैसी सर्वर-साइड स्क्रिप्टिंग भाषाओं, या जावा (प्रोग्रामिंग भाषा) जैसी प्रोग्रामिंग भाषाओं की कार्यक्षमता का उपयोग करके भी प्राप्त किया जा सकता है।

HTTP संपीड़न के कार्यशील कार्यान्वयन को सत्यापित करने के लिए विभिन्न ऑनलाइन उपकरण मौजूद हैं। ये ऑनलाइन उपकरण आम तौर पर एक यूआरएल के कई वेरिएंट का अनुरोध करते हैं, प्रत्येक अलग-अलग अनुरोध हेडर (अलग-अलग स्वीकृति-एनकोडिंग सामग्री के साथ) के साथ। जब सर्वर किसी दस्तावेज़ को संपीड़ित प्रारूप में लौटाता है तो HTTP संपीड़न को सही ढंग से लागू माना जाता है।[17] लौटाए गए दस्तावेज़ों के आकार की तुलना करके, प्रभावी संपीड़न अनुपात की गणना की जा सकती है (विभिन्न संपीड़न एल्गोरिदम के बीच भी)।

HTTP संपीड़न के उपयोग को रोकने में समस्याएँ

Google इंजीनियरों अरविंद जैन और जेसन ग्लासगो के 2009 के एक लेख में कहा गया है कि 99 से अधिक व्यक्ति-वर्ष बर्बाद हो गए हैं[18] प्रतिदिन पेज लोड समय में वृद्धि के कारण जब उपयोगकर्ताओं को संपीड़ित सामग्री प्राप्त नहीं होती है। ऐसा तब होता है जब एंटी-वायरस सॉफ़्टवेयर कनेक्शन में हस्तक्षेप करके उन्हें असंपीड़ित होने के लिए बाध्य करता है, जहां प्रॉक्सी का उपयोग किया जाता है (अत्यधिक सतर्क वेब ब्राउज़र के साथ), जहां सर्वर गलत कॉन्फ़िगर किए जाते हैं, और जहां ब्राउज़र बग संपीड़न का उपयोग करना बंद कर देते हैं। इंटरनेट एक्सप्लोरर 6, जो प्रॉक्सी के पीछे HTTP 1.0 (संपीड़न या पाइपलाइनिंग जैसी सुविधाओं के बिना) पर चला जाता है - कॉर्पोरेट वातावरण में एक सामान्य कॉन्फ़िगरेशन - मुख्यधारा का ब्राउज़र था जो असम्पीडित HTTP पर वापस विफल होने का सबसे अधिक खतरा था।[18]

HTTP संपीड़न को बड़े पैमाने पर तैनात करते समय पाई गई एक और समस्या डिफ्लेट एन्कोडिंग परिभाषा के कारण है: जबकि HTTP 1.1 डिफ्लेट एन्कोडिंग को एक zlib स्वरूपित स्ट्रीम (RFC 1950) के अंदर डिफ्लेट (RFC 1951) के साथ संपीड़ित डेटा के रूप में परिभाषित करता है, Microsoft सर्वर और क्लाइंट उत्पाद ऐतिहासिक रूप से इसे एक अपरिष्कृत अपस्फीति धारा के रूप में कार्यान्वित किया,[19] इसकी तैनाती को अविश्वसनीय बनाना।[20][21] इस कारण से, Apache HTTP सर्वर सहित कुछ सॉफ़्टवेयर, केवल gzip एन्कोडिंग लागू करते हैं।

सुरक्षा निहितार्थ

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

2012 में, डेटा संपीड़न के उपयोग के विरुद्ध एक सामान्य हमले की घोषणा की गई, जिसे CRIME कहा गया। जबकि CRIME हमला बड़ी संख्या में प्रोटोकॉल के खिलाफ प्रभावी ढंग से काम कर सकता है, जिसमें टीएलएस और एसपीडीवाई या एचटीटीपी जैसे एप्लिकेशन-लेयर प्रोटोकॉल शामिल हैं, लेकिन केवल इन्हीं तक सीमित नहीं हैं, केवल टीएलएस और एसपीडीवाई के खिलाफ शोषण का प्रदर्शन किया गया और ब्राउज़र और सर्वर में काफी हद तक कम किया गया। HTTP संपीड़न के विरुद्ध CRIME शोषण को बिल्कुल भी कम नहीं किया गया है, भले ही CRIME के ​​लेखकों ने चेतावनी दी है कि यह भेद्यता SPDY और TLS संपीड़न से भी अधिक व्यापक हो सकती है।

2013 में, HTTP संपीड़न के विरुद्ध CRIME हमले का एक नया उदाहरण, जिसे BREACH कहा गया, प्रकाशित किया गया था। एक BREACH हमला टीएलएस एन्क्रिप्टेड वेब ट्रैफ़िक से लॉगिन टोकन, ईमेल पते या अन्य संवेदनशील जानकारी को कम से कम 30 सेकंड में (निकाले जाने वाले बाइट्स की संख्या के आधार पर) निकाल सकता है, बशर्ते हमलावर पीड़ित को किसी दुर्भावनापूर्ण वेब लिंक पर जाने के लिए प्रेरित करे।[22] उपयोग किए गए एन्क्रिप्शन एल्गोरिदम या सिफर की परवाह किए बिना टीएलएस और एसएसएल के सभी संस्करण BREACH से जोखिम में हैं।[23] CRIME (सुरक्षा शोषण) के पिछले उदाहरणों के विपरीत, जिसे TLS संपीड़न या SPDY हेडर संपीड़न को बंद करके सफलतापूर्वक बचाव किया जा सकता है, BREACH HTTP संपीड़न का शोषण करता है जिसे वास्तविक रूप से बंद नहीं किया जा सकता है, क्योंकि लगभग सभी वेब सर्वर डेटा ट्रांसमिशन गति में सुधार के लिए इस पर भरोसा करते हैं। उपयोगकर्ताओं के लिए.[22]

2016 तक, TIME हमला और HEIST हमला अब सार्वजनिक ज्ञान हैं।[24][25][26][27]


संदर्भ

  1. "Using HTTP Compression (IIS 6.0)". Microsoft Corporation. Retrieved 9 February 2010.
  2. RFC 2616, Section 3.5: "The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens."
  3. 'RFC2616 "Transfer-Encoding: gzip, chunked" not handled properly', Chromium Issue 94730
  4. "हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल पैरामीटर्स - HTTP सामग्री कोडिंग रजिस्ट्री". IANA. Retrieved 18 April 2014.
  5. "Compression Tests: Results". Verve Studios, Co. Archived from the original on 21 March 2012. Retrieved 19 July 2012.
  6. "JSR 200: Network Transfer Format for Java Archives". The Java Community Process Program.
  7. "मॉडकंप्रेस - लाइटटीपीडी". lighty labs. Retrieved 18 April 2014.
  8. elinks LZMA decompression
  9. "[MS-PCCRTP]: Peer Content Caching and Retrieval: Hypertext Transfer Protocol (HTTP) Extensions". Microsoft. Retrieved 19 April 2014.
  10. "rproxy: Protocol Definition for HTTP rsync Encoding". rproxy.samba.org.
  11. "[MS-XCA]: Xpress Compression Algorithm". Retrieved 29 August 2015.
  12. "LZMA2 Compression - MozillaWiki". Retrieved 18 April 2014.
  13. "mget GitHub प्रोजेक्ट पेज". GitHub. Retrieved 6 January 2017.
  14. "mod_deflate - Apache HTTP Server Version 2.4 - Supported Encodings".
  15. "Extra part of Hiawatha webserver's manual".
  16. "Serving static files part of Armeria's documentation".
  17. "How does the gzip compression check work?". httptools.dev, retrieved 10 April 2022.
  18. 18.0 18.1 "वेब को तेज़ बनाने के लिए संपीड़न का उपयोग करें". Google Inc. Retrieved 22 May 2013.
  19. "deflate - Why are major web sites using gzip?". Stack Overflow. Retrieved 18 April 2014.
  20. "Compression Tests: About". Verve Studios. Archived from the original on 2 January 2015. Retrieved 18 April 2014.
  21. "Lose the wait: HTTP Compression". Zoompf Web Performance. Retrieved 18 April 2014.
  22. 22.0 22.1 Goodin, Dan (1 August 2013). "Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages". Ars Technica. Condé Nast. Retrieved 2 August 2013.
  23. Leyden, John (2 August 2013). "Step into the BREACH: New attack developed to read encrypted web data". The Register. Retrieved 2 August 2013.
  24. Sullivan, Nick (11 August 2016). "CRIME, TIME, BREACH and HEIST: A brief history of compression oracle attacks on HTTPS". Retrieved 16 August 2016.
  25. Goodin, Dan (3 August 2016). "HEIST exploit — New attack steals SSNs, e-mail addresses, and more from HTTPS pages". Retrieved 16 August 2016.
  26. Be'ery, Tal. "A Perfect Crime? TIME will tell" (PDF).
  27. Vanhoef, Mathy. "HEIST: HTTP Encrypted Information can be Stolen through TCP-windows" (PDF).


बाहरी संबंध