کمپریس کرنے والا پراکسی کہاں بینڈوڈتھ بچا سکتا ہے
مواد میں کمی کو محدود کلائنٹ لنک سے پہلے رکھیں اور تصویر کے معیار، موجودہ کمپریشن اور HTTPS کی نمائش کو مدنظر رکھیں۔
جواب کے راستے پر محدود لنک سے پہلے مواد میں کمی رکھیں:
website → proxy transforms response → slow or metered link → browser
اگر پورا باڈی وہ لنک پہلے ہی عبور کر چکا ہے تو بعد میں اسے چھوٹا کرنا ان بائٹس کو واپس نہیں لا سکتا۔ تیز اپ اسٹریم والا دور دراز تبدیل کنندہ براؤزر کے پاس والے مقامی پراکسی سے مختلف مقصد پورا کر سکتا ہے۔
Ziproxy اس طریقے کی مثال دیتا ہے: اس کا منصوبہ ایک غیر کیشنگ HTTP پراکسی بیان کرتا ہے جو متن جیسے مواد کو gzip کرتا ہے اور چھوٹی، کم معیار کی تصاویر بنا سکتا ہے۔
| جواب کا راستہ | ممکنہ کمی |
|---|---|
| gzip انکوڈنگ | بلا نقصان؛ براؤزر اصل ڈیٹا ڈی کوڈ کرتا ہے |
| تصاویر کا دوبارہ کمپریشن | تفصیلات چھوڑ سکتا ہے اور جب درست تصاویر اہم ہوں تو نامناسب ہو سکتا ہے |
| پہلے ہی مؤثر طریقے سے کمپریس شدہ مواد | مزید کمی کے لیے کم گنجائش |
| عام HTTPS CONNECT | غیر شفاف TLS کسی دوسرے قابل اعتماد صاف متن رسائی انتظام کے بغیر HTML یا تصویر کی تبدیلی روکتا ہے |
پروسیسنگ اور اضافی ہاپ وقت بھی لیتے ہیں، اس لیے کم بائٹس تیز تکمیل کی ضمانت نہیں دیتے۔ کیش موزوں محفوظ جواب دوبارہ استعمال کرتا ہے؛ کمپریشن نئے حاصل کردہ جواب کو محفوظ کیے بغیر تبدیل کر سکتا ہے۔
جہاں HTTP مواد نظر آتا ہے، Cache-Control: no-transform کی پاسداری کریں۔ no-transform جواب پالیسی موافق مواد کی handling کو کنٹرول کرتی ہے؛ یہ نقل و حمل کی انکرپشن سے الگ ہے۔ فوائد کا اندازہ اصل مواد اور انکرپشن راستے سے لگائیں، پرانی صاف متن تصویر کی مظاہرے سے نہیں۔