Gzip / Brotli चेकर

gzip और Brotli से HTTP कंप्रेशन कैसे काम करता है?

ब्राउज़र Accept-Encoding में बताता है कि वह कौन-सी codings डिकोड कर सकता है (आज gzip, deflate, br और अक्सर zstd); सर्वर बॉडी को उनमें से किसी एक से कंप्रेस करके Content-Encoding में उसका नाम बताता है, और ब्राउज़र इस्तेमाल से पहले उसे डिकोड करता है। Brotli (RFC 7932) आमतौर पर टेक्स्ट को gzip (RFC 1952) से ज़्यादा छोटा करता है। HTML, CSS, JavaScript और JSON जैसे टेक्स्ट फ़ॉर्मेट बहुत छोटे होते हैं, जबकि इमेज, वीडियो और WOFF2 फ़ॉन्ट पहले से कंप्रेस्ड होते हैं, और कंप्रेस्ड रिस्पॉन्स को Vary: Accept-Encoding भेजना चाहिए ताकि कैश हर coding की एक कॉपी रखें।

Gzip / Brotli चेकर कैसे इस्तेमाल करें

1. जाँचने वाले पेज, स्क्रिप्ट, स्टाइलशीट या API रिस्पॉन्स का अंतिम URL डालें (रीडायरेक्ट फ़ॉलो नहीं होते)।
2. "कंप्रेशन जाँचें" दबाएँ।
3. पहले नतीजे पढ़ें, फिर तीनों रिक्वेस्ट: Content-Encoding कॉलम दिखाता है कि सर्वर ने सच में कौन-सी एन्कोडिंग इस्तेमाल की।
4. अगर टेक्स्ट बिना कंप्रेशन आता है या Vary ग़ायब है, तो सर्वर या CDN पर कंप्रेशन या Vary हेडर चालू करें और दोबारा जाँचें।

Gzip / Brotli चेकर की खूबियाँ

• Mutqan सर्वर से तीन GET रिक्वेस्ट भेजता है जो सिर्फ़ Accept-Encoding में अलग हैं — identity (बिना कंप्रेशन), gzip और br (Brotli) — और जवाबों की आमने-सामने तुलना करता है
• हर रिक्वेस्ट के लिए HTTP स्टेटस, सर्वर का चुना Content-Encoding, बताया गया Content-Length, डिकोड के बाद के बाइट, पहले बाइट तक का समय और कुल समय दिखाता है
• gzip और Brotli की बचत तभी गिनता है जब उस एन्कोडिंग ने सच में Content-Length के साथ जवाब दिया हो, और नाम लेकर बताता है कि बचत क्यों नहीं मापी जा सकी (chunked ट्रांसफ़र, रीडायरेक्ट, ठुकराई गई रिक्वेस्ट)
• कंटेंट टाइप के हिसाब से नतीजा समझाता है: बिना कंप्रेशन भेजा गया टेक्स्ट रिस्पॉन्स, पहले से कंप्रेस इमेज या वीडियो, सिर्फ़ gzip या सिर्फ़ Brotli देने वाला सर्वर
• जाँचता है कि कंप्रेस्ड रिस्पॉन्स Vary: Accept-Encoding भेजता है, ताकि साझा कैश हर एन्कोडिंग की अलग कॉपी रखें
• ऐसे सर्वर को चिह्नित करता है जो मना करने पर भी कंप्रेस करता है, और ऐसे नतीजे को जिसमें Brotli gzip से बड़ा हो

इनपुट और आउटपुट

इनपुट

• जाँचने के लिए URL — संसाधन का अंतिम http:// या https:// पता; सिर्फ़ होस्ट नाम देने पर https:// जोड़ा जाता है। URL रीडायरेक्ट करे तो टारगेट पर दोबारा जाँचें।
• और कुछ नहीं: तीनों Accept-Encoding वैल्यू और रिक्वेस्ट हेडर तय हैं।

आउटपुट

• सारांश — gzip और Brotli इस्तेमाल होते हैं या नहीं, मापी जा सके तो हर एक की बचत, और बिना कंप्रेस साइज़।
• नतीजे — इस कंटेंट टाइप के लिए जवाबों का मतलब, ग़ायब Vary: Accept-Encoding, और छोटे या पहले से कंप्रेस्ड रिस्पॉन्स।
• तीन रिक्वेस्ट — identity, gzip और br के लिए स्टेटस, Content-Encoding, Content-Length, डिकोड के बाद बाइट और समय; CSV में डाउनलोड हो सकता है।
• रिस्पॉन्स — URL, Content-Type और Vary हेडर, और माप कहाँ से हुआ; नोट उन सभी मामलों को समझाते हैं जो मापे नहीं जा सके।

Gzip / Brotli चेकर का उदाहरण

जाँचने के लिए URL: https://www.example.com/

gzip Used · Brotli Used · gzip saving 76.4 % · Brotli saving — (not measurable) · Uncompressed size 84210 B
identity → 200, no Content-Encoding, Content-Length 84210
gzip → 200, gzip, Content-Length 19870
br → 200, br, Content-Length not sent (chunked)
The server compresses with both Brotli and gzip, choosing by the Accept-Encoding the client sends.
The server compresses but does not send Vary: Accept-Encoding; a shared cache may hand the compressed copy to a client that cannot decode it.
The Brotli response was sent without Content-Length (chunked), so its compressed size is not reported.

Gzip / Brotli चेकर के नतीजे कैसे पढ़ें

"इस्तेमाल हुआ" का मतलब है कि उस एन्कोडिंग को माँगने वाली रिक्वेस्ट को मेल खाते Content-Encoding के साथ 2xx जवाब मिला। "इस्तेमाल नहीं हुआ" का मतलब है उसके बिना 2xx जवाब; "—" का मतलब है 2xx जवाब नहीं मिला, इसलिए कुछ नहीं कहा जा सकता।

बचत तभी दिखती है जब कंप्रेस्ड जवाब में Content-Length हो। "मापी नहीं जा सकती" साइट की कमी नहीं: बहुत से सर्वर कंप्रेस्ड रिस्पॉन्स टुकड़ों में भेजते हैं, जो सामान्य है।

HTML, CSS, JavaScript, JSON, XML और SVG में कोई कंप्रेशन न होना ठीक करने लायक़ है। JPEG, PNG, WebP, वीडियो, WOFF2 या ZIP के लिए कंप्रेशन न करना ही सही है।

समय Mutqan सर्वर से मापा जाता है और इसमें पहला कनेक्शन शामिल है; तीनों की तुलना मोटे तौर पर ही करें, क्योंकि एक रिक्वेस्ट अगली के लिए कोई कैश गर्म कर सकती है।

Gzip / Brotli चेकर कब इस्तेमाल करें

• सर्वर, CDN या फ़्रेमवर्क बदलने के बाद पक्का करें कि HTML, स्क्रिप्ट और स्टाइलशीट अब भी कंप्रेस होकर जाती हैं।
• जाँचें कि आपकी टेक्स्ट फ़ाइलों के लिए CDN पर सच में Brotli चालू है, सिर्फ़ gzip नहीं।
• ऐसे धीमे पेज या कम परफ़ॉर्मेंस स्कोर की पड़ताल करें जो टेक्स्ट कंप्रेशन की ओर इशारा करता हो।
• पक्का करें कि API, क्लाइंट के माँगने पर कंप्रेस्ड JSON लौटाता है और कैश के लिए Vary: Accept-Encoding सेट है।

समस्या निवारण

• तीनों रिक्वेस्ट 301 या 302 लौटाती हैं: URL रीडायरेक्ट करता है और चेकर रीडायरेक्ट फ़ॉलो नहीं करता। नोट टारगेट बताते हैं; वही URL जाँचें।
• जिस पेज को आपका ब्राउज़र कंप्रेस्ड दिखाता है, उस पर gzip और Brotli दोनों "इस्तेमाल नहीं हुआ": कुछ सर्वर सिर्फ़ कुछ User-Agent के लिए या पहली रिक्वेस्ट से कैश गर्म होने के बाद ही कंप्रेस करते हैं। दोबारा जाँचें, और सर्वर के कंप्रेशन नियम देखें।
• identity रिक्वेस्ट भी कंप्रेस होकर लौटी: सर्वर Accept-Encoding: identity को अनदेखा करता है। ब्राउज़र हमेशा gzip मानते हैं, इसलिए यह कम ही मायने रखता है, पर डिकोड न कर पाने वाले क्लाइंट नाकाम होंगे।
• "This address cannot be reached from the Mutqan server" जैसा इनकार: निजी और आरक्षित पते कभी नहीं माँगे जाते। सिर्फ़ सार्वजनिक URL जाँचे जा सकते हैं।

Gzip / Brotli चेकर के बारे में अक्सर पूछे जाने वाले सवाल

तकनीकी नोट्स

HTTP content coding RFC 9110 §8.4 में परिभाषित है: क्लाइंट Accept-Encoding में अपनी मानी जाने वाली codings बताता है, और सर्वर Content-Encoding में बताता है कि उसने कौन-सी लगाई। gzip RFC 1952 का फ़ॉर्मेट है और br RFC 7932 का Brotli फ़ॉर्मेट; "identity" का मतलब है कोई coding नहीं।

POST /api/v1/internet/http/compression तय Mutqan हेडर प्रोफ़ाइल के साथ तीन GET रिक्वेस्ट भेजता है, Accept-Encoding को identity, gzip और br रखकर, रीडायरेक्ट फ़ॉलो किए बिना। Cloudflare Workers runtime कंप्रेस्ड बॉडी को जाँच के पढ़ने से पहले डिकोड कर देता है, इसलिए कंप्रेस्ड साइज़ वही Content-Length है जो सर्वर ने बताया; बॉडी chunked हो तो यह हेडर नहीं होता और बचत नहीं गिनी जाती। बॉडी 1 MiB तक पढ़ी जाती है।

बचत = 1 − कंप्रेस्ड ÷ बिना कंप्रेस, जहाँ बिना कंप्रेस साइज़ identity जवाब के Content-Length से लिया जाता है, या उसकी डिकोड हुई बॉडी से — अगर सर्वर ने identity रिक्वेस्ट को फिर भी कंप्रेस किया हो या chunked भेजा हो।

सीमाएँ और कार्यप्रणाली

कंप्रेस्ड साइज़ सिर्फ़ सर्वर के बताए Content-Length से आते हैं; Mutqan सर्वर कंप्रेस्ड बाइट ख़ुद कभी नहीं देखता, इसलिए chunked रिस्पॉन्स की कोई मापी गई बचत नहीं होती।

हर एन्कोडिंग Cloudflare नेटवर्क पर चलने वाले Mutqan सर्वर से एक बार माँगी जाती है। CDN दूसरे एज पर, दूसरे क्लाइंट के लिए या कैश गर्म होने के बाद अलग तरह से कंप्रेस कर सकता है।

सिर्फ़ gzip और Brotli जाँचे जाते हैं; Zstandard (zstd) और deflate नहीं माँगे जाते, और हर बॉडी का ज़्यादा से ज़्यादा 1 MiB पढ़ा जाता है।

सुरक्षा और गोपनीयता

Mutqan सर्वर को URL मिलता है, वह आपकी किसी कुकी या क्रेडेंशियल के बिना तीन तय GET रिक्वेस्ट भेजता है, बॉडी सिर्फ़ बाइट गिनने के लिए पढ़ता है और कुछ स्टोर नहीं करता।

संदर्भ

• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
• RFC 1952: GZIP file format specification version 4.3IETF · 1996gzip फ़ॉर्मेट: हेडर, DEFLATE से कंप्रेस डेटा और CRC-32 व लंबाई वाला trailer — HTTP की gzip content coding के पीछे यही फ़ॉर्मेट है।
• RFC 7932: Brotli Compressed Data FormatIETF · 2016Brotli फ़ॉर्मेट, जो HTTP में br content coding के रूप में रजिस्टर्ड है: LZ77 के साथ Huffman coding, context modelling और आम वेब टेक्स्ट की बिल्ट-इन डिक्शनरी।