Bộ đếm byte VPN trên Mac chứng minh điều gì và không chứng minh điều gì

Mở cửa sổ trạng thái của ứng dụng khách và các con số trông đáng yên tâm: byte tăng lên, đường hầm đã kết nối. Đóng cửa sổ và ứng dụng văn phòng vẫn thất bại, nghĩa là các bộ đếm đã trả lời một câu hỏi không ai đặt ra. Đếm byte trên một giao diện chỉ đo lưu lượng tại đúng điểm quan sát đó và không hơn. Hãy đi từ con số bạn đang nhìn tới lớp mà nó báo cáo, rồi tới kết quả mà ứng dụng thực sự đã cho bạn.

Chọn giao diện trước khi chọn con số

Bắt đầu từ nơi con số được hiển thị và đọc nhãn bên cạnh. Cửa sổ ứng dụng khách có thể hiển thị tổng phiên, giao diện đường hầm có thể hiển thị byte IP bên trong, và bộ điều hợp vật lý có thể hiển thị byte bên ngoài đã mã hóa; ba bộ đếm khác nhau tình cờ đều tính bằng byte. Trên dòng lệnh, netstat -ibn in một hàng cho mỗi địa chỉ trên từng giao diện, nên một đường hầm có thể xuất hiện nhiều lần. Khớp hàng đó với giao diện mà ứng dụng khách thực sự sở hữu, và xác nhận bằng tuyến đường mà đích chọn. Một thiết bị tên là utun có thể thuộc VPN, thuộc đường hầm khác, hoặc thuộc thứ gì đó bạn không quan tâm.

Đừng thay bằng bộ đếm Wi-Fi chỉ vì dễ đọc hơn. Một điểm quan sát khác trả lời một câu hỏi khác.

Lấy mức chênh, không lấy tổng từ lúc khởi động

Đọc hàng đó, thực hiện một yêu cầu nhỏ đã được phép, rồi đọc lại đúng hàng đó. Mức chênh chính là bằng chứng, vì tổng từ lúc khởi động bao gồm mọi thứ máy đã làm. Giữ khoảng thời gian ngắn để lưu lượng nền có ít cơ hội làm nhiễu nó. Trên máy bận rộn, nettop có thể quy thông lượng cho một tiến trình, điều này thu hẹp phạm vi trước khi bạn quay lại các bộ đếm giao diện.

Chấp nhận rằng mức chênh không sạch. Thư, bản cập nhật và chính các thông điệp giữ kết nối của ứng dụng khách đều góp phần, nên hãy coi con số là giới hạn trên chứ không phải phép đo. Nếu ứng dụng là thứ duy nhất bạn làm trong khoảng đó, giới hạn thường đủ chặt để hữu ích.

Bộ đếm bên trong và bên ngoài đo những thứ khác nhau

Bộ điều hợp vật lý đếm các gói đã mã hóa kể cả tiêu đề bên ngoài của chúng, trong khi giao diện đường hầm hạch toán phần tải mà nó nhận hoặc chuyển giao. Cộng hai thứ đó lại là đếm một lần truyền hai lần. Chi phí phụ, truyền lại và đóng gói cũng khiến một đẳng thức đơn giản trở nên bất khả thi.

Hai bộ đếm đi ngược chiều nhau là một phát hiện, không phải mâu thuẫn. Thông thường điều đó nghĩa là lưu lượng đã vào một lớp và chưa bao giờ rời lớp kia.

Ghép bộ đếm với kết quả của ứng dụng

Tổng nhận được có thể tăng do trao đổi giao thức trong khi dịch vụ bạn muốn vẫn thất bại. Mức tăng khi gửi nói còn ít hơn: nó chứng minh nhân đã nhận một gói, không phải rằng có thứ gì đã trả lời.

Ghi lại kết quả chính xác bên cạnh các bộ đếm: phân giải tên thất bại, kết nối hết thời gian, TLS bị từ chối, hoặc một phản hồi HTTP đã đến. Đó là bốn lỗi khác nhau, và chỉ một trong số đó liên quan đến đường hầm. Nếu bằng chứng cần đi xa hơn, điểm quan sát tiếp theo là cổng hoặc ranh giới dịch vụ, nơi ai đó có thể thấy yêu cầu có đến hay không. Đặt lại tùy chọn mạng của Mac sẽ phá hủy trạng thái bạn đang đo và không cho bạn biết gì.

Viết ghi chú mà người tiếp theo cần

Tên giao diện, nhãn bộ đếm, khoảng thời gian, giá trị trước và sau, và kết quả của ứng dụng. Thế là đủ để đồng nghiệp tái tạo quan sát mà không phải lặp lại buổi chiều của bạn. Thêm phiên bản ứng dụng khách và phiên bản macOS, vì ý nghĩa của các bộ đếm có thể thay đổi giữa các bản phát hành.

Bỏ qua việc bắt gói đầy đủ và kết xuất hệ thống. Chúng hiếm khi cần để giải thích bộ đếm cục bộ nào đã dịch chuyển trong một yêu cầu, và chúng làm chậm mọi người đọc báo cáo. Nếu ứng dụng khách hiển thị số liệu của riêng nó, hãy trích nguyên nhãn của nó thay vì dịch sang nhãn của bạn. Mục đích của ghi chú là ghi lại những gì đã đo, không phải tranh luận nó có nghĩa gì.