CONNECT အသွားအလာက Squid ၏ အရာဝတ္ထု cache ကို ဘာကြောင့် မဖြည့်သနည်း
သာမန် HTTPS tunnel က forward proxy သို့ ပြန်သုံးနိုင်သည့် HTTP တုံ့ပြန်မှုအရာဝတ္ထုများ မပေးဘဲ byte များစွာကို ဘာကြောင့် လွှဲပြောင်းနိုင်သနည်း။
သာမန် CONNECT tunnel က Squid သို့ cache လုပ်နိုင်သည့် ဝဘ်ဆိုက်တုံ့ပြန်မှုအစား ကုဒ်ဝှက်ထားသော byte များကို ပေးသည်။ ထို့ကြောင့် ကြီးမားသည့် HTTPS ဒေါင်းလုဒ်တစ်ခုသည် အရာဝတ္ထု cache ထဲသို့ ပြန်သုံးနိုင်သည့် မှတ်တမ်းတစ်ခုမျှ မထည့်ဘဲ အသွားအလာများစွာ ဖြစ်စေနိုင်သည်။
Squid သည် tunnel ၏ ဦးတည်ရာ၊ ကြာချိန်နှင့် byte အရေအတွက်ကို မှတ်တမ်းတင်နိုင်သည်။ အတွင်းဘက် URL လမ်းကြောင်း၊ cache ညွှန်ကြားချက်များ၊ ကိုယ်စားပြုအချက်အလက်နှင့် စစ်ဆေးအတည်ပြုတန်ဖိုးများကို သိမ်းဆည်း၍ ပြန်သုံးနိုင်သည့် သာမန် HTTP စာများအဖြစ် မရရှိပါ။ Disk နေရာ ပိုပေးခြင်း သို့မဟုတ် အရာဝတ္ထုအရွယ်အစား ကန့်သတ်ချက် တိုးခြင်းက ယင်းတို့ကို ဖော်ထုတ်မပေးနိုင်ပါ။
Cache ပျက်နေသည်ဟု မဆုံးဖြတ်မီ request method များနှင့် tunnel မှတ်တမ်းများကို စစ်ပါ။ CONNECT အများစုပါဝင်သည့် အလုပ်ဝန်တွင် ဒေတာလွှဲပြောင်းမှုများပြီး အရာဝတ္ထုပြန်သုံးမှု နည်းခြင်းသည် ကိုက်ညီပါသည်။ Cache ကို အမှန်တကယ် စစ်ရန် သင်ထိန်းချုပ်သည့် HTTP resource ကို ရှင်းလင်းသော cache header များနှင့် သိပြီးသားအကြောင်းအရာဖြင့် သုံးပါ။ Tunnel၊ browser cache သို့မဟုတ် ဦးတည်ရာ CDN မဟုတ်ဘဲ Squid ၏ အရာဝတ္ထုလုပ်ဆောင်မှုလမ်းကြောင်းကို စမ်းသပ်နေကြောင်း အတည်ပြုပါ။
Proxy သို့သွားသည့် TLS သည် သီးခြားအလွှာတစ်ခု ဖြစ်သည်။ မိမိ၏ listener တွင် TLS ချိတ်ဆက်မှုကို အဆုံးသတ်ပြီးနောက် Squid သည် HTTP ဦးတည်ရာသို့ သာမန် request ကို လုပ်ဆောင်နိုင်သည်။ ထိုချိတ်ဆက်မှုက HTTPS သို့ CONNECT ကို အစားထိုးတောင်းဆိုပါက အတွင်းဘက် ဦးတည်ရာ TLS သည် သီးခြားဖြစ်ပြီး အကြောင်းအရာကို မမြင်နိုင်သေးပါ။
HTTPS ကို ကြားဝင်ဖမ်းယူဖြည်ခြင်းသည် certificate ယုံကြည်မှု၊ ခွင့်ပြုချက်နှင့် ကိုယ်ရေးလုံခြုံမှု လိုအပ်ချက်များကို ပြောင်းလဲစေသည်။ ယင်းသည် ပုံမှန် cache နေရာပြင်ဆင်ခြင်း မဟုတ်ဘဲ သာမန် forward proxy တစ်ခု လည်ပတ်ရန် ထိုကြားဝင်ဖမ်းယူမှု မလိုပါ။