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

एचटीटीपी कम्प्रेशन (HTTP compression) एक क्षमता है जिसे स्थानांतरण गति और बैंडविड्थ उपयोग में सुधार के लिए वेब सर्वर और वेब क्लाइंट में बनाया जा सकता है।

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

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

1. वेब क्लाइंट एचटीटीपी अनुरोध में टोकन की एक सूची सम्मिलित करके विज्ञापन देता है कि वह कौन सी कम्प्रेशन योजनाओं का समर्थन करता है। सामग्री-एनकोडिंग के लिए, सूची एक्सेप्ट-एनकोडिंग नामक फ़ील्ड में है; ट्रांसफर-एन्कोडिंग के लिए, फ़ील्ड को TE कहा जाता है।

2. यदि सर्वर एक या अधिक कम्प्रेशन योजनाओं का समर्थन करता है, तो आउटगोइंग डेटा को दोनों पक्षों द्वारा समर्थित एक या अधिक तरीकों से कंप्रेस्ड किया जा सकता है। यदि यह स्थिति है, तो सर्वर उपयोग की गई योजनाओं के साथ एचटीटीपी प्रतिक्रिया में एक सामग्री-एनकोडिंग या ट्रांसफर-एनकोडिंग फ़ील्ड जोड़ देगा, जिसे अल्पविराम से अलग किया जाएगा।

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

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


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

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


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

सर्वर जो एचटीटीपी कम्प्रेशन का समर्थन करते हैं

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

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

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

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

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

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

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

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

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

2016 तक, टाइम (TIME) अटैक और हेस्ट (HEIST) अटैक अब सार्वजनिक ज्ञान हैं।

बाहरी संबंध

 * Hypertext Transfer Protocol – एचटीटीपी/1.1
 * एचटीटीपी Semantics
 * एचटीटीपी Content-Coding Values by Internet Assigned Numbers Authority
 * Compression with ligएचटीटीपीd
 * Coding Horror: एचटीटीपी Compression on IIS 6.0
 * Using एचटीटीपी Compression by Martin Brown of Server Watch
 * Using एचटीटीपी Compression in PHP
 * Dynamic and static एचटीटीपी compression with Apache एचटीटीपीd
 * Dynamic and static एचटीटीपी compression with Apache एचटीटीपीd

Hypertext Transfer Protocol