Điều gì gây ra các bản ghi ACK trùng lặp?

Chúng tôi đang xem xét các bản chụp Wireshark từ một số máy khách đang hiển thị nhiều bản ghi ACK trùng lặp, sau đó kích hoạt các gói truyền lại và các chuỗi ngoài chuỗi.

Chúng được hiển thị trong ảnh chụp màn hình sau đây. 0,26 là máy khách và 0,252 là máy chủ.

Điều gì gây ra các bản ghi ACK trùng lặp?

Thêm nền nếu nó giúp:

Chúng tôi đang điều tra mối quan tâm thông lượng mạng tại một trang web khách hàng cụ thể. Vấn đề được nhận thức từ góc độ giao diện người dùng là dữ liệu đang được truyền chậm mặc dù kết nối WAN 1gbps không được sử dụng đúng mức.

Hầu như tất cả các máy khách đều có cùng một vấn đề, được thử nghiệm tại hơn 20 máy. Chúng tôi đã tìm thấy hai máy không có vấn đề. Chúng tôi đang trong quá trình xác định những gì khác nhau trong cấu hình của họ. Chúng tôi đã nhận thấy rằng trong hai máy không có vấn đề, chúng tôi chỉ thấy nhiều nhất một bản ghi ACK trùng lặp. Các máy có vấn đề thường có ba bản ghi ACK trùng lặp. Một điểm khác biệt đáng chú ý là các máy hoạt động tốt đều thuộc về các thành viên của nhóm vận hành mạng và tất cả các máy khác đều dành cho nhân viên "thông thường". Các máy được cho là tiêu chuẩn nhưng quản trị viên mạng có thể đã thực hiện thay đổi trên hệ thống cục bộ của họ, đó là một khía cạnh khác mà chúng tôi đang nghiên cứu.

Chúng tôi đã thử thay đổi cài đặt TcpMaxDupAcks trên máy chủ nhưng giá trị chúng tôi thực sự cần là 5 và phạm vi hợp lệ chỉ là 1-3.

Máy chủ là Windows Server 2003. Khách hàng là tất cả Windows XP do doanh nghiệp quản lý. Tất cả các máy khách, bao gồm cả hai máy đang hoạt động, đã cài đặt chương trình chống vi-rút Symantec.

Đây là trang web khách hàng duy nhất trong số hàng trăm người đã thể hiện vấn đề này.

pathping hiển thị 56ms RTT và mất gói 0/100 nhất quán ngay cả từ các máy có vấn đề.

Cảm ơn,

Sam

Lưu ý: Tôi giả sử rằng bản chụp này được chụp trên máy khách.

Một bản tóm tắt ngắn gọn về trình tự TCP: TCP đáng tin cậy cung cấp các luồng byte giữa hai ứng dụng. "Đáng tin cậy" trong trường hợp này có nghĩa là, trong số những thứ khác, TCP đảm bảo không bao giờ cung cấp dữ liệu ngoài đơn hàng cho một ứng dụng nghe.

Theo thứ tự, giao hàng đáng tin cậy được thực hiện thông qua việc sử dụng số thứ tự. Mỗi gói trong mỗi luồng được gán một số thứ tự 32 bit (hãy nhớ rằng TCP thực sự là hai luồng dữ liệu độc lập, A-> B và B-> A). Nếu A gửi ACK đến B, giá trị trong trường ACK là số thứ tự tiếp theo A dự kiến ​​sẽ thấy từ B.

Từ những điều trên, có vẻ như ít nhất một phân đoạn TCP được gửi từ máy chủ đến máy khách đã bị mất. Ba ACK trùng lặp theo trình tự là một nỗ lực của khách hàng để kích hoạt truyền lại nhanh . Khi người gửi TCP nhận được 3 xác nhận trùng lặp cho cùng một dữ liệu (nghĩa là 4 ACK cho cùng một phân đoạn, không phải là phần dữ liệu được gửi gần đây nhất), có thể giả định rằng phân đoạn đó ngay sau khi phân đoạn bị ACKed bị mất trong mạng và dẫn đến việc truyền lại ngay lập tức.

Trong trường hợp này, việc truyền lại được thông qua và được Wireshark xác định là không theo thứ tự.

Như joeqwerty đã đề cập , mất gói thường xảy ra do tắc nghẽn. Nó cũng có thể là kết quả của CRC hoặc các lỗi khác trên một liên kết, do thẻ giao diện xấu, cáp lỏng lẻo, v.v. Tôi sẽ xem xét các số liệu thống kê của mỗi liên kết dọc theo đường dẫn để xem liệu có được sử dụng nhiều và / hoặc đang gặp một số lượng lớn lỗi.

Nếu bạn không thể thấy bất kỳ ứng cử viên rõ ràng nào, hãy thực hiện các gói chụp đồng thời tại nhiều điểm trên đường dẫn để thử và cách ly nơi xảy ra mất mát.

Loại kết nối WAN nào đang được sử dụng ở đây? Có phải là một dòng chuyên dụng? Liên kết MPLS VPN? IPsec VPN qua internet công cộng? Thứ gì khác?

Trong khi bạn đang cách ly vấn đề ở đâu, hãy nghĩ rằng một gói dữ liệu chỉ là một trong những triệu chứng ... Tương tự như vậy, nếu ai đó đi vào phòng mạch của bác sĩ với những cơn đau ngực, tài liệu sẽ không dành ba giờ để điều tra bản chất của nỗi đau. Anh ta dành khoảng hai phút cho việc đó và sau đó biết rằng 95% nguyên nhân là do ợ nóng hoặc đau thắt ngực ... Theo cách tương tự, nếu bạn thấy ACK trùng lặp, đừng bỏ chuột vào vết cỏ dại ngay lập tức .

Sau khi kết nối được thiết lập, hiệu suất TCP chậm không phải lúc nào cũng do sự cố mạng chuyển tiếp; đôi khi nó xuất phát từ kết quả của CPU máy chủ hoặc giới hạn đĩa ... và đôi khi do một số vấn đề trên PC khách. Tôi đã đuổi theo đuôi của mình trong nhiều tuần để đào sâu vào đám cỏ của dấu vết dây chỉ để từ bỏ và tìm ra vấn đề tương đối nhanh chóng với mtr , hoặc bằng cách xem xét các số liệu máy chủ khác như CPU ​​và I / O của đĩa.

Nhiệm vụ đầu tiên của bạn là chứng minh xem đây là sự cố mạng hay sự cố cấp máy chủ. Tập trung vào việc gửi lưu lượng truy cập thực qua mạng của bạn và chứng minh xem bạn có đang xếp hàng / mất / đặt hàng lại ^{Lưu ý 1} không; đó luôn là điểm mấu chốt cho một vấn đề mạng tiềm năng như thế này .

Tôi sẽ thực hiện pinglấy mẫu trong một khoảng thời gian dài (thường là một giờ đối với tôi) giữa máy khách và máy chủ trong khi sự cố thông lượng đang xảy ra; bạn có thể sử dụng phần mềm miễn phí mtr hoặc ping cốt truyện cho việc này. Nếu bạn liên tục mất các gói tại một số bước nhảy và tất cả các bước nhảy sau đó mất nhiều hoặc nhiều , thì bạn có một nghi ngờ mạng tiềm năng. Hãy nhớ rằng việc giới hạn tốc độ ICMP của thiết bị có thể khiến một số bước nhảy xuất hiện khiến chúng mất các gói ... đó là lý do tại sao bạn muốn tìm kiếm một xu hướng bắt đầu từ bước nhảy đó và những bước tiếp theo.

^{Lưu ý 1} Nếu bạn đang đặt hàng lại lưu lượng truy cập, điều đó sẽ hiển thị khá nhanh trong trường thông tin chuyên gia mà wireshark cung cấp

Bằng cách nhìn thấy rất nhiều [phân đoạn TCP của PDU được ghép lại] mà không có ACK - tôi muốn nói rằng các ACK đó có khả năng được hiển thị dưới dạng [TCP Dup ACK ...] do hành vi Xác nhận chọn lọc (còn gọi là SACK) .

Thí dụ:

• khách hàng gửi các phần dữ liệu (..., 0,1,2,3,4,5,6, ...)

• máy chủ acked (0), sau đó nhận (2,4,3), sau đó (5), sau đó (6) và không bao giờ có (1)

Trong kịch bản trên - máy chủ có thể chọn một cách hợp pháp để ack (2-4) phạm vi trước, sau đó (2-5) phạm vi, sau đó (2-6) phạm vi. Trong khi hình thành gói "(AB) phạm vi ack" - máy chủ phải chỉ định phần được đánh dấu cuối cùng (0) trong tiêu đề TCP. Wireshark đánh dấu acks phạm vi (SACK) là [TCP Dup ACK ...] bởi vì tất cả các ack phạm vi đó có cùng giá trị phần được đánh dấu cuối cùng trong tiêu đề TCP (Ack = 872619 trong trường hợp của bạn).

Sao chép ACK kết hợp với hiệu suất mạng chậm có vẻ như là một vấn đề tắc nghẽn mạng đối với tôi. Nhìn vào khối lượng và tốc độ lưu lượng phát trên mạng. Hãy chắc chắn để xem các lớp phát sóng vật lý và lớp mạng cũng như đa tuyến.