Squid maxconn ဖြင့် ချိတ်ဆက်မှုများ ရေတွက်ခြင်း
maxconn ကို စက်ပစ္စည်း သို့မဟုတ် အတည်ပြုပြီး အသုံးပြုသူ အရေအတွက်အဖြစ် မယူဘဲ၊ ရင်းမြစ်တစ်ခုစီအတွက် ချိတ်ဆက်မှု အရေအတွက်၏ အခြေအနေအဖြစ် အသုံးပြုပါ။
maxconn 5 သည် သင့် proxy အတွက် စက်ပစ္စည်းငါးလုံး လိုင်စင် မဟုတ်ပါ။ ၎င်းသည် ကလိုင်းယင့်၏ ရင်းမြစ်လိပ်စာနှင့် ချိတ်ဆက်ထားသော ချိတ်ဆက်မှု အရေအတွက် အခြေအနေ ဖြစ်သည်။
စည်းမျဉ်း အပိုင်းအစ ငယ်တစ်ခုသည် ဤသို့ ဖြစ်သည် —
acl over_connection_limit maxconn 5
http_access deny over_connection_limitSquid ၏ မှတ်တမ်းတင်ထားသော ကိုက်ညီမှုသည် ပေးထားသော တန်ဖိုးထက် “ကြီးသည်”။ ငြင်းပယ်သည့် စည်းမျဉ်းက ထို အခြေအနေကို သုံးစွဲသည်။ ACL ကို ကြေညာရုံဖြင့် မည်သည့်အရာကိုမျှ ငြင်းပယ်မည် မဟုတ်ပါ။ ကန့်သတ်ရန် ရည်ရွယ်သည့် တောင်းဆိုမှုများကို ရှိပြီးသား ခွင့်ပြုမည့် ကျယ်ပြန့်သော စည်းမျဉ်းများ၏ အရှေ့တွင် ထားပါ။
ဤအပိုင်းအစ၏ ပတ်လည်တွင် ပုံမှန် ခွင့်ပြုချက် မူဝါဒကို ထားရှိပါ။ ဤသည် ပြည့်စုံသော ဝင်ရောက်ခွင့် ဖွဲ့စည်းမှု မဟုတ်ပါ။ ACL သည် Squid ၏ ကလိုင်းယင့် ဒေတာဘေ့စ် ဖွင့်ထားမှုအပေါ်လည်း မူတည်သည်။ အလုပ်လုပ်မည်ဟု မမျှော်လင့်မီ client_db ကို စစ်ဆေးပါ။
စက်ပစ္စည်းတစ်လုံးသည် ချိတ်ဆက်မှု များစွာကို ဖွင့်နိုင်သည်။ NAT နောက်ကွယ်ရှိ စက်ပစ္စည်း အများအပြားသည် ရင်းမြစ်လိပ်စာ တစ်ခုတည်းအဖြစ် ပေါ်နိုင်သည်။ မျှဝေထားသော စက်တစ်လုံးသည် အသုံးပြုသူ အများအပြားကို ဝန်ဆောင်နိုင်ပြီး၊ တိတ်ဆိတ်သော စက်ပစ္စည်းတစ်ခုသည် ရေတွက်သည့် အခိုက်တွင် ချိတ်ဆက်မှု လုံးဝ မရှိနိုင်ပါ။ ထို ဆက်စပ်မှုများထဲမှ တစ်ခုမျှ တစ်ခုနှင့်တစ်ခု မဟုတ်ပါ။
အမှန်တကယ် လိုအပ်ချက်သည် အမည်ပေးထားသော အကောင့်များ၊ မှတ်ပုံတင်ထားသော စက်ပစ္စည်းများ သို့မဟုတ် သက်ဝင်နေသော ဆက်ရှင်များအပေါ် ကန့်သတ်ချက် ဖြစ်ပါက ထို အထောက်အထားနှင့် ၎င်း၏ သက်တမ်းစက်ဝန်းကို ရှင်းလင်းစွာ သတ်မှတ်ပါ။ ရင်းမြစ်တစ်ခုစီအတွက် socket ကန့်သတ်ချက်သည် စွမ်းရည်ကို ကာကွယ်နိုင်သော်လည်း ၎င်း၏ ဂဏန်းကို လူများ သို့မဟုတ် စက်ပစ္စည်းများ အဖြစ် မဟုတ်ဘဲ ချိတ်ဆက်မှုများ အဖြစ် ဖော်ပြသင့်သည်။