TCP Zero Window qua proxy: xác định bên nhận

Xác định nơi kiểm soát luồng TCP nằm ở phía client hay server của proxy trước khi quy một lượt tải bị treo cho window scaling hay kích thước buffer.

Một bản bắt gói cho thấy TCP ZeroWindow. Trước khi đổi thiết lập kernel, hãy xác định endpoint nào đang quảng bá giá trị zero.

Endpoint đó đang mô tả khả năng nhận của nó trên kết nối TCP ấy, chứ không thông báo toàn bộ băng thông mà proxy có. Probe zero-window cho phép bên gửi biết khả năng nhận đã quảng bá có thay đổi hay không; bản thân probe không chứng minh mất gói hay proxy hỏng.

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

Đây là hai cuộc hội thoại TCP riêng biệt. Giả sử trình duyệt ngừng đọc một phản hồi lớn và quảng bá zero trên A. Proxy có thể dần ngừng đọc B khi buffer của chính nó đầy. Một zero window xuất hiện sau đó trên B có thể là hệ quả của client chậm, chứ không phải nguyên nhân ban đầu.

Trường hợp ngược lại có thể xảy ra khi tải lên. Nếu ứng dụng đích ngừng tiêu thụ dữ liệu, window của nó trên B có thể đóng lại. Áp lực sau đó có thể lan ngược về phía client qua buffer của proxy.

Sắp xếp các quan sát theo thứ tự

  1. Ghi lại các endpoint của kết nối và hướng của luồng dữ liệu bị ảnh hưởng.
  2. Xác định endpoint nào đầu tiên quảng bá receive window bị thu hẹp hoặc bằng zero.
  3. Kiểm tra xem ứng dụng của nó đang đọc, đang tạm dừng vì thao tác khác, hay bị giới hạn bởi tài nguyên.
  4. So sánh thời điểm trên kết nối còn lại của proxy trước khi gán nguyên nhân ban đầu.

Nhãn phân tích window của Wireshark là cách diễn giải hữu ích cho bản capture, không phải chỉ dẫn tăng mọi receive buffer. Window scaling cũng phải được hiểu trong bối cảnh thương lượng của kết nối.

Thử một endpoint khác từ danh sách proxy và thấy đường truyền hồi phục là bằng chứng hữu ích rằng đường đi đã thay đổi. Điều đó tự nó không chứng minh phần TCP của một hệ điều hành bị lỗi. Hãy giữ cách lý giải gắn với tiến trình nhận và kết nối nơi sự chờ đợi bắt đầu.

Bài viết liên quan