کش ACL خارجی Squid: چرا هر بار کمککننده فراخوانی نمیشود
کمککنندههای ACL خارجی Squid را بر پایه فرآیندهای پایدار، کلیدهای کش تصمیم و نیاز صریح به تازگی مجوز طراحی کنید.
کمککنندهای که یک درخواست را ثبت میکند و سپس ساکت میماند میتواند عادی باشد. Squid ممکن است قاعده را با نتیجه ACL خارجی کششده ارزیابی کند بدون آنکه پرسوجوی دیگری برای کمککننده بفرستد.
نخست تصمیم قابل استفاده مجدد را تعریف کنید. «آیا این حساب میتواند از پروکسی استفاده کند؟» ورودیهای متفاوتی از «آیا این حساب میتواند به این مقصد برسد؟» میخواهد. قالب گسترده ACL خارجی کلید کش را میسازد. اگر کمککننده بر اساس نام کاربری و مقصد تصمیم بگیرد اما کلید فقط نام کاربری را در بر داشته باشد، تأیید کششده ممکن است گستردهتر از قصد اعمال شود. هر ورودی که پاسخ را تغییر میدهد بگنجانید و از جزئیاتی که فقط تصمیمهای همارز را تکهتکه میکنند بپرهیزید.
سپس تازگی را انتخاب کنید. ttl و negative_ttl مثبت نتایج منطبق و نامنطبق را کنترل میکنند؛ grace میتواند پیش از انقضای یک ورودی، تازهسازی را آغاز کند. تعیین کنید تأیید کششده یک حساب لغوشده چه مدت میتواند بر تصمیمهای بعدی اثر بگذارد. هیچیک از این تنظیمات تونل CONNECT برقرارشده را برای هر بایت یا هر درخواست HTTPS داخلی دوباره مجاز نمیکند. اگر کمککننده سهمیه ترافیک را اعمال کند، انتقالهای پذیرفتهشده ممکن است پس از تغییر موجودی ادامه یابند.
کمککننده یک شرکتکننده پایدار در پروتکل است، نه لزوماً یک فرآیند اسکریپت تازه برای هر درخواست. آن را برای خطوط پرسوجوی پیاپی آماده نگه دارید و هر پاسخ را بیدرنگ بفرستید. تشخیصها را روی کانال دیگری بگذارید. وقتی همزمانی فعال است، شناسه کانال دادهشده مربوط را برگردانید.
در پایان، نتایج کند، در دسترس نبودن و خطای داخلی را تعریف کنید و ترتیب ACL پیرامون را وادارید آنها را تولید کند. طراحی زمانی کامل است که هم ویژگی و هم عمر مجاز یک پاسخ قابل استفاده مجدد با نیاز دسترسی بخواند.