एचटीटीपी कम्प्रेशन

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

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

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

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

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

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


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

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


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

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

 * एसएपी नेटवीवर
 * इंटरनेट सूचना सेवाएँ: अंतर्निहित या तृतीय-पक्ष मॉड्यूल का उपयोग करना
 * अपाचे HTTP सर्वर, mod_deflate के माध्यम से (इसके नाम के बावजूद, केवल gzip का समर्थन करता है ), और mod_brotli
 * हियावाथा (वेब ​​सर्वर): पूर्व-संपीड़ित फ़ाइलें परोसता है
 * चेरोकी (वेबसर्वर), ऑन फ्लाई गज़िप और डिफ्लेट कंप्रेशन
 * Oracle iPlanet वेब सर्वर
 * जेटी (वेब ​​सर्वर)
 * लाइटटीपीडी
 * nginx - बिल्ट-इन
 * टोरनेडो (वेब ​​​​सर्वर) पर आधारित एप्लिकेशन, यदि एप्लिकेशन सेटिंग्स में कंप्रेस_रेस्पॉन्स को ट्रू पर सेट किया गया है (4.0 से पहले के संस्करणों के लिए, gzip को ट्रू पर सेट करें)
 * जेट्टी (वेब ​​​​सर्वर) - अंतर्निहित डिफ़ॉल्ट स्थैतिक सामग्री सेवा और सर्वलेट फ़िल्टर कॉन्फ़िगरेशन के माध्यम से उपलब्ध
 * जियोसर्वर
 * अपाचे टॉमकैट
 * आईबीएम वेबस्फीयर
 * एओएलसर्वर
 * रूबी (प्रोग्रामिंग भाषा) रैक (वेब ​​सर्वर इंटरफ़ेस), रैक::डिफ्लेटर मिडलवेयर के माध्यम से
 * HAProxy
 * वार्निश (सॉफ्टवेयर) - बिल्ट-इन। एज साइड के साथ भी काम करता है
 * आर्मेरिया - पूर्व-संपीड़ित फ़ाइलों की सेवा
 * NaviServer - अंतर्निर्मित, गतिशील और स्थैतिक संपीड़न

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

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

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

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

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

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

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

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

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

बाहरी संबंध

 * Hypertext Transfer Protocol – HTTP/1.1
 * HTTP Semantics
 * HTTP Content-Coding Values by Internet Assigned Numbers Authority
 * Compression with lighttpd
 * Coding Horror: HTTP Compression on IIS 6.0
 * Using HTTP Compression by Martin Brown of Server Watch
 * Using HTTP Compression in PHP
 * Dynamic and static HTTP compression with Apache httpd
 * Dynamic and static HTTP compression with Apache httpd

Hypertext Transfer Protocol