Giả sử một ứng dụng khách gửi một yêu cầu mà không có thông tin xác thực proxy, nhận một thách thức rồi thử lại thành công. Nhật ký yêu cầu có thể chứa hai mục. Nhưng người dùng ứng dụng chỉ trải qua một thao tác đã hoàn tất.

Đó là lý do một nhật ký chia đều giữa TCP_DENIED/407 và TCP_TUNNEL/200 không tự động chứng minh tỷ lệ lỗi năm mươi phần trăm. Trước tiên hãy xác định xem các mục có tạo thành cặp thách thức và thử lại hay không.

Đếm thứ bạn thực sự quan tâm

Phép đoSố lượng
Thách thức xác thựcPhản hồi proxy yêu cầu xác thực
Lần thử qua proxyCác giao dịch riêng lẻ do trung gian ghi nhận
Công việc đã hoàn tấtCác thao tác của ứng dụng đạt kết quả dự định

Tương quan dấu thời gian, bối cảnh ứng dụng khách, đích đến và mọi mã định danh yêu cầu có sẵn. Một lần thử chưa xác thực có thể không có tên người dùng được ghi, trong khi lần thử lại thành công thì có. Hoạt động đồng thời nghĩa là chỉ những dòng liền kề là bằng chứng yếu cho việc hai mục thuộc cùng một việc.

Cũng hãy tách một đường hầm thành công khỏi một thao tác trang web thành công. Việc chấp nhận CONNECT thiết lập đường hầm; đích đến vẫn có thể thất bại trong quá trình TLS hoặc trả về lỗi ứng dụng sau đó.

Hãy điều tra các thách thức cuối cùng lặp lại, các công việc không bao giờ hoàn tất về sau, hoặc sự thay đổi đột ngột về số lần trao đổi. Những trường hợp này khác với một ứng dụng khách ổn định bắt đầu bằng thách thức và làm đúng những gì cấu hình của nó yêu cầu. Việc đè nén xác thực chỉ để làm bảng điều khiển xanh hơn sẽ thay đổi dịch vụ thay vì sửa chữa phép đo.

Bài viết liên quan