گزارش‌های Squid: آیا 407 که پس از آن 200 می‌آید شکست حساب می‌شود؟
وقتی Squid چالشی را ثبت می‌کند که پس از آن تونلی موفق می‌آید، عملیات تکمیل‌شده را جدا از تبادل‌های احراز هویت بشمارید.
فرض کنید یک کلاینت یک درخواست بدون اعتبارنامه پراکسی می‌فرستد، یک چالش دریافت می‌کند و با موفقیت دوباره تلاش می‌کند. یک گزارش درخواست می‌تواند دو ورودی داشته باشد. اما شخصی که از برنامه استفاده می‌کند یک عملیات تکمیل‌شده را تجربه کرده است.
به همین دلیل، گزارشی که به‌طور مساوی بین TCP_DENIED/407 و TCP_TUNNEL/200 تقسیم شده است، به‌طور خودکار نرخ شکست پنجاه درصدی را اثبات نمی‌کند. نخست تعیین کنید که آیا این ورودی‌ها جفت‌های چالش و تلاش دوباره را تشکیل می‌دهند.
چیزی را بشمارید که واقعاً برایتان مهم است
| سنجه | شمارش |
|---|---|
| چالش‌های احراز هویت | پاسخ‌های پراکسی که احراز هویت می‌خواهند |
| تلاش‌های پراکسی | تراکنش‌های فردی که واسطه ثبت می‌کند |
| کارهای تکمیل‌شده | عملیات برنامه که به نتیجه مورد نظر می‌رسند |
زمان‌ها، بافت کلاینت، مقصد و هر شناسه درخواست موجود را به هم مرتبط کنید. یک تلاش بدون احراز هویت ممکن است نام کاربری ثبت‌شده نداشته باشد، در حالی که تلاش دوباره موفق آن دارد. فعالیت هم‌زمان یعنی خطوط مجاور به‌تنهایی شواهد ضعیفی برای تعلق دو ورودی به یکدیگر هستند.
همچنین تونل موفق را از عملیات موفق وب‌سایت جدا نگه دارید. پذیرش CONNECT تونل را برقرار می‌کند؛ مقصد همچنان می‌تواند در طول TLS شکست بخورد یا بعداً خطای برنامه برگرداند.
چالش‌های پایانی مکرر، کارهایی که بعداً هرگز تکمیل نمی‌شوند، یا تغییر ناگهانی در تعداد تبادل‌ها را بررسی کنید. این‌ها با کلاینتی پایدار که ابتدا چالش می‌گیرد و دقیقاً همان کاری را می‌کند که پیکربندی‌اش می‌خواهد متفاوت‌اند. سرکوب احراز هویت فقط برای سبزتر کردن یک داشبورد، سرویس را تغییر می‌دهد نه اینکه سنجش را اصلاح کند.