Squid બાહ્ય ACL કેશિંગ: હેલ્પરને દરેક વખતે કેમ બોલાવવામાં નથી આવતું

એક વિનંતી લોગ કરીને પછી શાંત થઈ જતું હેલ્પર સામાન્ય હોઈ શકે. Squid હેલ્પરને બીજી ક્વેરી મોકલ્યા વિના કેશ કરેલા બાહ્ય ACL પરિણામ સાથે નિયમનું મૂલ્યાંકન કરી શકે છે.

પહેલા પુનઃવાપરી શકાય તેવો નિર્ણય વ્યાખ્યાયિત કરો. “શું આ ખાતું પ્રોક્સી વાપરી શકે?” માટે “શું આ ખાતું આ ગંતવ્ય સુધી પહોંચી શકે?” કરતાં જુદા ઇનપુટ જોઈએ. વિસ્તૃત બાહ્ય ACL ફોર્મેટ કેશ કી બનાવે છે. જો હેલ્પર વપરાશકર્તાનામ અને ગંતવ્ય દ્વારા નિર્ણય લે પણ કીમાં ફક્ત વપરાશકર્તાનામ હોય, તો કેશ કરેલી મંજૂરી ધાર્યા કરતાં વધુ વ્યાપક લાગુ થઈ શકે. જવાબ બદલતું દરેક ઇનપુટ સામેલ કરો અને ફક્ત સમાન નિર્ણયોને વિખેરતી વિગતો ટાળો.

પછી તાજગી પસંદ કરો. હકારાત્મક ttl અને negative_ttl મેળ ખાતા અને ન મેળ ખાતા પરિણામો નિયંત્રિત કરે છે; grace એન્ટ્રી સમાપ્ત થવા પહેલાં રિફ્રેશ શરૂ કરી શકે છે. રદ કરાયેલા ખાતાની કેશ કરેલી મંજૂરી પછીના નિર્ણયોને કેટલા સમય સુધી અસર કરી શકે તે નક્કી કરો. આમાંનું કોઈ પણ સેટિંગ સ્થાપિત CONNECT ટનલને દરેક બાઇટ કે આંતરિક HTTPS વિનંતી માટે ફરી અધિકૃત કરતું નથી. જો હેલ્પર ટ્રાફિક કોટા લાગુ કરે, તો બાકી બદલાયા પછી પણ મંજૂર થયેલા સ્થાનાંતરણ ચાલુ રહી શકે.

હેલ્પર સ્થાયી પ્રોટોકોલ સહભાગી છે, દરેક વિનંતી માટે નવી સ્ક્રિપ્ટ પ્રક્રિયા જરૂરી નથી. તેને ક્રમિક ક્વેરી લાઇન માટે તૈયાર રાખો અને દરેક જવાબ તરત મોકલો. નિદાન બીજી ચેનલ પર મૂકો. સમવર્તીતા સક્ષમ હોય ત્યારે અનુરૂપ આપેલ ચેનલ ઓળખકર્તા પરત કરો.

છેલ્લે, ધીમું, અનુપલબ્ધ અને આંતરિક ભૂલ પરિણામો વ્યાખ્યાયિત કરો અને આસપાસનો ACL ક્રમ તેમને ઉત્પન્ન કરે તેમ કરો. જ્યારે પુનઃવાપરી શકાય તેવા જવાબની વિશિષ્ટતા અને માન્ય ઉંમર બંને પ્રવેશ આવશ્યકતા સાથે મેળ ખાય ત્યારે ડિઝાઇન પૂર્ણ થાય છે.