कम्प्रेस गर्ने प्रोक्सीले कहाँ ब्यान्डविथ बचत गर्न सक्छ

सामग्री घटाउने काम सीमित ग्राहक लिङ्कभन्दा अघि राख्नुहोस् र छवि गुणस्तर, विद्यमान कम्प्रेसन तथा HTTPS देखिने क्षमता विचार गर्नुहोस्।

प्रतिक्रिया मार्गमा सीमित लिङ्कभन्दा अघि सामग्री घटाउने काम राख्नुहोस्:

website → proxy transforms response → slow or metered link → browser

यदि पूरै बडी पहिले नै त्यो लिङ्क पार गरिसकेको छ भने, पछि सानो बनाउनुले ती बाइट फिर्ता ल्याउन सक्दैन। छिटो अपस्ट्रिम भएको टाढाको रूपान्तरणकर्ताले ब्राउजरको छेउको स्थानीय प्रोक्सीभन्दा फरक उद्देश्य पूरा गर्न सक्छ।

Ziproxy यो दृष्टिकोण देखाउँछ: यसको परियोजनाले पाठजस्तो सामग्री gzip गर्ने र साना, कम गुणस्तरका छविहरू उत्पादन गर्न सक्ने क्यास नगर्ने HTTP प्रोक्सी वर्णन गर्छ।

प्रतिक्रिया मार्गसम्भावित कमी
gzip इन्कोडिङहानिरहित; ब्राउजरले मूल डेटा डिकोड गर्छ
छवि पुनः कम्प्रेसनविवरण छोड्न सक्छ र सटीक छवि महत्त्वपूर्ण हुँदा अनुपयुक्त हुन सक्छ
पहिले नै कुशलतापूर्वक कम्प्रेस गरिएको सामग्रीथप कमीका लागि कम ठाउँ
सामान्य HTTPS CONNECTअपारदर्शी TLS ले अर्को विश्वसनीय स्पष्ट-पाठ पहुँच व्यवस्था बिना HTML वा छवि रूपान्तरण रोक्छ

प्रशोधन र अतिरिक्त हपले पनि समय लिन्छ, त्यसैले कम बाइटले छिटो समाप्तिको ग्यारेन्टी दिँदैन। क्यासले योग्य भण्डारित प्रतिक्रिया पुनः प्रयोग गर्छ; कम्प्रेसनले नयाँ प्राप्त प्रतिक्रियालाई भण्डारण नगरी रूपान्तरण गर्न सक्छ।

HTTP सामग्री देखिने ठाउँमा Cache-Control: no-transform पालना गर्नुहोस्। no-transform प्रतिक्रिया नीतिले अनुरूप सामग्री व्यवस्थापन नियन्त्रण गर्छ; यो यातायात इन्क्रिप्शनबाट अलग छ। लाभहरू वास्तविक सामग्री र इन्क्रिप्शन मार्गबाट अनुमान गर्नुहोस्, पुरानो स्पष्ट-पाठ छवि प्रदर्शनबाट होइन।

सम्बन्धित लेखहरू