Cách đọc mất gói trước khi đổ lỗi cho cáp

Mất gói hai phần trăm trong một lượt ping dài nghe như một con số có thể hành động dựa trên nó, và hiếm khi là vậy. Nó không cho biết các phản hồi biến mất ở đâu, chúng biến mất cùng nhau hay không, hay một ứng dụng cụ thể đã trải qua khoảng thời gian đó như thế nào. Mất gói rải đều trong một phút và mất gói dồn vào một lần trao đổi duy nhất cho kết quả rất khác nhau với cùng một tỷ lệ phần trăm.

So sánh ba phép đo thay vì tin vào một: những gì đầu dò thấy, những gì các bộ đếm giao diện làm và những gì ứng dụng thực sự chờ đợi.

Tỷ lệ phần trăm ping thực sự đo cái gì

Đầu dò phản hồi kiểm tra một hướng của một giao thức với một kích thước gói, ở bất kỳ tốc độ nào bạn chọn. Một đường hầm mang tải lên lớn đang làm việc hoàn toàn khác, và một liên kết làm rơi các đầu dò nhỏ không nhất thiết là liên kết đang gây hại cho việc truyền. Tỷ lệ phần trăm còn nghiền nát thông tin thời gian quan trọng nhất, vì mười phản hồi mất trong một đợt bùng không giống mười phản hồi mất cách nhau một giờ. Nó cũng không thể cho bạn biết phía nào của đường hầm đã làm rơi thứ gì.

Giữ kết quả đầu dò như một gợi ý về đường đi. Sau đó tìm kiếm thời điểm và ranh giới đã tạo ra nó.

So sánh chênh lệch bộ đếm, không phải tổng cả đời

Lấy các số đọc có dấu thời gian trước và sau cửa sổ nơi triệu chứng xuất hiện, ở cả hai đầu và trên bất kỳ cổng chuyển mạch nào bạn kiểm soát. Ghi lại lưu lượng cùng với lỗi, bị loại bỏ và thay đổi trạng thái liên kết, vì một tổng khác không tích lũy qua nhiều tháng mô tả lịch sử chứ không phải sự cố này. Một bộ đếm nhích thêm ba trong lúc dừng là quan sát khác với bộ đếm hiển thị ba nghìn và chưa bao giờ thay đổi.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Các gói bị loại vì lỗi nhận và các gói bị loại vì lý do khác sống trong các bộ đếm riêng, và sự phân biệt này thay đổi bước tiếp theo. Bộ đếm lỗi chỉ vào lớp vật lý hoặc lớp trình điều khiển, trong khi áp lực hàng đợi và việc loại bỏ theo chính sách chỉ vào đâu đó phía trên. Giữ cả hướng và tên giao diện, vì mức tăng lỗi nhận trên một liên kết lên và bộ đếm gói của đường hầm không thể thay thế cho nhau.

Nếu trình điều khiển công bố các bộ đếm vật lý chi tiết, hãy đọc chúng qua tài liệu của bộ điều hợp đó. Gán một ý nghĩa duy nhất cho mọi trường có tên “drop” ở hai nhà sản xuất là cách một nét lạ kế toán bình thường trở thành chẩn đoán phần cứng.

Làm sao một phân đoạn bị mất trở thành một lần chờ dài

Một ứng dụng có thể chờ lâu hơn nhiều so với một lượt khứ hồi sau khi mất một phân đoạn. TCP ước lượng thời gian khứ hồi, tính bộ hẹn giờ truyền lại từ ước lượng đó và lùi lại khi việc truyền lại cũng thất bại, nên một phân đoạn bị mất đúng lúc có thể làm dừng một yêu cầu trong một khoảng đáng chú ý. Cơ chế đó được quy định trong RFC 6298, và nó giải thích vì sao một tỷ lệ mất gói trông tầm thường vẫn có thể cảm nhận được.

Nhưng không phải mọi khoảng dừng đều là hết giờ truyền lại. Cùng một sự chờ đợi có thể đến từ phân giải tên, một máy chủ chậm hoặc một ứng dụng thử lại yêu cầu của chính nó sau thất bại. Hãy tách các trường hợp đó bằng cách căn chỉnh thao tác thất bại với các quan sát truyền tải và với các sự kiện phiên của chính đường hầm. Một gián đoạn trên đường dữ liệu mà không kết nối lại là sự kiện khác với một lần bắt tay mới và trao đổi thông tin xác thực.

Nơi được phép bắt gói, hãy giữ phạm vi hẹp. Điều bạn cần là liệu các gói hoặc xác nhận mong đợi có dừng tại một ranh giới cụ thể hay không, chứ không phải việc có một lần truyền lại ở đâu đó trong một vết bận rộn.

Thay đổi một ranh giới mà không dịch chuyển các ranh giới khác

Nếu bằng chứng chỉ vào một liên kết cục bộ, hãy thay một cáp hoặc cổng đã được phê duyệt làm phép so sánh có kiểm soát và để mọi thứ khác yên. Giữ đầu cuối, ứng dụng và khối lượng công việc tương đương, và chỉ thay đúng một ranh giới mỗi lần thử. So sánh một máy tính xách tay có dây với một máy không dây trong khi cũng đổi lối ra và giao thức không cho bạn biết điều gì có thể quy cho nguyên nhân.

Các bộ đếm cục bộ sạch không chứng nhận phần còn lại của đường đi. Chúng giới hạn phần bạn nhìn thấy, và báo cáo trung thực nói rõ ranh giới nào đã được quan sát và ranh giới nào không. Cuối cùng điều bạn muốn là một tuyên bố rằng một quan sát đã thay đổi khi một can thiệp xảy ra, chứ không phải một giai thoại về sợi cáp tồi được nâng lên thành quy tắc phổ quát.