สมมติว่าไคลเอนต์ส่งคำขอหนึ่งรายการโดยไม่มีข้อมูลรับรองพร็อกซี ได้รับการท้าทาย แล้วลองใหม่จนสำเร็จ บันทึกคำขออาจมีสองรายการ แต่ผู้ใช้แอปพลิเคชันประสบกับงานที่เสร็จสมบูรณ์เพียงงานเดียว

นี่คือเหตุผลที่บันทึกซึ่งแบ่งเท่ากันระหว่าง TCP_DENIED/407 และ TCP_TUNNEL/200 ไม่ได้พิสูจน์อัตราความล้มเหลวห้าสิบเปอร์เซ็นต์โดยอัตโนมัติ ก่อนอื่นให้พิจารณาว่ารายการเหล่านั้นเป็นคู่ของการท้าทายและการลองใหม่หรือไม่

นับสิ่งที่คุณสนใจจริง ๆ

ตัวชี้วัดจำนวน
การท้าทายการยืนยันตัวตนการตอบกลับของพร็อกซีที่ขอการยืนยันตัวตน
ความพยายามผ่านพร็อกซีธุรกรรมแต่ละรายการที่ตัวกลางบันทึก
งานที่เสร็จสมบูรณ์การทำงานของแอปที่บรรลุผลลัพธ์ที่ตั้งใจ

เชื่อมโยงเวลาที่บันทึก บริบทของไคลเอนต์ ปลายทาง และตัวระบุคำขอใด ๆ ที่มีอยู่ ความพยายามที่ไม่ได้ยืนยันตัวตนอาจไม่มีชื่อผู้ใช้ที่บันทึกไว้ ขณะที่การลองใหม่ที่สำเร็จนั้นมีชื่อผู้ใช้ หากมีกิจกรรมเกิดขึ้นพร้อมกัน บรรทัดที่อยู่ติดกันเพียงอย่างเดียวจึงเป็นหลักฐานที่อ่อนแอว่ารายการสองรายการเป็นเรื่องเดียวกัน

แยกอุโมงค์ที่สำเร็จออกจากการทำงานของเว็บไซต์ที่สำเร็จด้วย การยอมรับ CONNECT สร้างอุโมงค์ แต่ปลายทางยังคงล้มเหลวระหว่าง TLS หรือส่งคืนข้อผิดพลาดของแอปในภายหลังได้

ตรวจสอบการท้าทายสุดท้ายที่เกิดซ้ำ งานที่ไม่เคยเสร็จสมบูรณ์ในภายหลัง หรือการเปลี่ยนแปลงอย่างฉับพลันของจำนวนการแลกเปลี่ยน สิ่งเหล่านี้แตกต่างจากไคลเอนต์ที่มั่นคงซึ่งเริ่มด้วยการท้าทายและทำตามที่การกำหนดค่าของตนต้องการอย่างถูกต้อง การระงับการยืนยันตัวตนเพียงเพื่อให้แดชบอร์ดเขียวขึ้นจะเปลี่ยนบริการแทนที่จะซ่อมแซมการวัด

บทความที่เกี่ยวข้อง