Quá nhiều 'TCP Dup ACK' & 'TCP Fast Retransmission' gây ra sự cố trên mạng. Điều gì gây ra điều này?

Tôi đang nhận quá nhiều TCP Dup ACK và TCP Fast Retransmission trên mạng của chúng tôi khi tôi truyền tệp qua liên kết MetroEthernet. Hai trang web được kết nối bởi một bộ định tuyến sonicwall, vì vậy các trang web chỉ cách một bước nhảy.

Đây là một ảnh chụp màn hình từ wireshark, và đây là toàn bộ chụp. Trong bản chụp này, máy khách là 192.168.2.153 và máy chủ là 192.168.1.101 Đây là một traceroute từ hệ thống của tôi đến máy chủ (thời gian ping thường ổn định dưới 10ms):

user@pc567:~$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:e0:b8:c8:0c:7e  
          inet addr:192.168.2.153  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:b8ff:fec8:c7e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:244994 errors:0 dropped:0 overruns:0 frame:0
          TX packets:149148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:319571991 (319.5 MB)  TX bytes:12322180 (12.3 MB)
          Interrupt:16 

user@pc567:~$ traceroute -n 192.168.1.101
traceroute to 192.168.1.101 (192.168.1.101), 30 hops max, 60 byte packets
 1  192.168.2.254  0.747 ms  0.706 ms  0.806 ms
 2  192.168.1.101  8.995 ms  9.217 ms  9.477 ms
user@pc567:~$

Bất kỳ trợ giúp về những gì gây ra điều này sẽ hữu ích! Tôi có thể đăng thêm bất kỳ chi tiết cần thiết.

CẬP NHẬT: Kể từ khi bắt đầu, tôi đã thay thế sonicwall bằng bộ định tuyến 1800 cisco. Việc chụp gói với nó được cài đặt có kết quả tương tự. Vì nó là một mạch ethernet metro, không cần bộ định tuyến. Vì vậy, tôi cũng đã thử kết nối trực tiếp với máy tính xách tay vào thiết bị của nhà cung cấp dịch vụ ở cả hai trang web và đặt chúng trên cùng một mạng con. Việc chụp gói trông giống như làm theo cách này. Điều này khiến tôi tin rằng có một vấn đề với mạch ethernet metro, mặc dù họ tiếp tục nói không có gì sai và mọi thứ đều ổn.

Tôi nhận ra rằng câu trả lời này được đơn giản hóa và không rõ ràng như tôi muốn, vì vậy nếu bạn có câu hỏi về một bước, vui lòng hỏi!

Cuộn xuống một chút sau khi mở tệp này trong Wireshark, chúng ta thấy một số khung có màu khác nhau. Trông thật tệ phải không? Chà, nó không tệ Chờ đã, chúng ta sẽ đến đó.

Kiểm tra gói SYN (khung 37), chúng ta thấy SACK và Window Scale trong Tùy chọn TCP. Tốt Điều tương tự trong quy mô SYN / ACK (khung 38), SACK và Windows. Tuyệt vời. Đừng thấy bất cứ điều gì kỳ lạ liên quan đến SACK.

Ước tính RTT không tải là thời gian giữa gói SYN và ACK đầu tiên (khung 39). Đó là khoảng 9,3 ms, phù hợp với những phát hiện của bạn. Lưu ý rằng thời gian giữa SYN / ACK và ACK (khung 38 và 39) thấp hơn nhiều so với giữa SYN và SYN / ACK (37 và 38). Điều này có nghĩa là tệp chụp này được lấy tại máy thu và để xem tại sao điều đó không lý tưởng, chúng tôi sẽ phải quay lại trường.

Giữa người gửi và người nhận có một phần của đường dẫn mạng nhỏ nhất, giới hạn băng thông. Ước tính RTT mà chúng tôi vừa nhận được từ cái bắt tay cho chúng tôi ước tính độ dài của đường dẫn mạng này. Một phép đo có bao nhiêu gói chúng ta có thể phù hợp trong đường ống này là Dung lượng ống hoặc Sản phẩm độ trễ băng thông - PC [bits] = R [bits / s] * RTT [s], trong đó R là băng thông nhỏ nhất. Công suất ống sau đó là một phép đo khối lượng.

Hãy tưởng tượng một vòi vườn. Khối lượng của nó được đo được xác định bởi chiều dài và chiều rộng của nó theo cùng một cách phải không? Để lấy được nhiều nước nhất từ ​​nó, nó cần phải được lấp đầy hoàn toàn bằng nước, nếu không sẽ có những khoảng trống không khí làm hạn chế dòng nước. Trong trường hợp chúng tôi quản lý để lấp đầy nó hoàn toàn, nó có thể tràn. Chúng ta có thể sử dụng một cái xô để chúng ta không bị ướt sàn và nếu xô tràn ra không ảnh hưởng đến dòng nước.

Hóa ra nó giống hệt nhau trong đường dẫn mạng. Chúng ta cần lấp đầy đường ống ... Nói cách khác, Dung lượng ống là byte nhỏ nhất trong chuyến bay (chúng ta có bao nhiêu nước trong ống + xô) giữa người gửi và người nhận sử dụng đầy đủ băng thông nhỏ nhất (không gây ra khe hở không khí). Vì vậy, nếu các byte trong chuyến bay> PC thì chúng ta tốt!

Nhìn vào Thống kê theo dõi TCP -> TCP StreamGraph -> Biểu đồ trình tự thời gian (tcptrace), chúng ta có thể thấy các byte trên trục Y và thời gian trên trục X. Đạo hàm của đường cong này là byte / giây hoặc thông lượng. Lưu ý cách "đường" màu đen phẳng, nghĩa là thông lượng ổn định! Tuy nhiên, nó bị gián đoạn bởi các đường màu xanh đôi lần (đó là các phạm vi SACK trong các ACK trùng lặp), nhưng như có thể thấy nó không ảnh hưởng đến thông lượng.

Xem cách đường liền nét màu xám bên phải thấp hơn (phóng to một chút, đó là ACK) thực sự gần với các phân đoạn TCP màu đen? Thời gian giữa phân đoạn TCP và ACK là RTT, đây là gần 0! Điều đó có nghĩa là không có nhiều phân đoạn trong chuyến bay đã vượt qua điểm bắt giữ này. Đến lượt điều này có nghĩa là chúng ta không thể sử dụng điều đó để ước tính các byte trong chuyến bay và đây là lý do tại sao việc bắt gói bên phía người gửi là cách tốt hơn.

Các gói ở đây tự nhiên bị mất trước điểm chụp. Mỗi phân đoạn dữ liệu trong chuyến bay tại thời điểm mất sẽ kích hoạt ACK trùng lặp. Do đó, chúng ta có thể sử dụng số lượng ACK trùng lặp để ước tính các byte trong chuyến bay tại thời điểm mất gói. Ở đây chúng ta thấy khoảng 9, 16 và 23 phân khúc. Mỗi phân đoạn có 1448 byte dữ liệu, do đó, cung cấp cho chúng tôi một byte trong chuyến bay trong khoảng từ 13k đến 33k. Thông lượng ở đây là khoảng hơn 3 Mbit / s (từ biểu đồ IO ) và với RTT, chúng tôi đã đo trước khi chúng tôi có được Công suất ống nhỏ hơn 3e6 [bit / s] * 10e-3 [s] / 8 byte = 3750 byte, hoặc ít hơn 3 đoạn.

Bởi vì các byte trong chuyến bay tại thời điểm xảy ra những mất mát này không thực sự giống nhau (khó có thể nói ở đây với rất ít mẫu) Tôi thực sự không thể nói nếu đây là những mất mát ngẫu nhiên (đó là xấu xấu) hay tổn thất xảy ra do hàng đợi / xô tràn, nhưng chúng xảy ra khi byte trong chuyến bay> PC nên thông lượng không bị ảnh hưởng.

Câu trả lời của bạn dường như chỉ ra rằng chúng thực sự ngẫu nhiên, nhưng không quá nhiều để gây ra thông lượng thấp.

Chỉ cần đăng những gì tôi tìm ra. Nhà cung cấp MetroEthernet đã đến một ngày thứ Bảy tới văn phòng chính của chúng tôi. Họ ngắt kết nối mạng ở đó và cũng có người ở một chi nhánh gần đó. Họ đã kết nối thiết bị kiểm tra mạng ở cả hai đầu và nhanh chóng có thể xác định thực tế có vấn đề. Vài giờ sau, họ đã có thể cô lập vấn đề. Đó là một vấn đề với các đường dây đồng từ văn phòng trung tâm của nhà cung cấp, đến văn phòng chính của chúng tôi. Họ nói rằng các khung hình đang giảm xuống như điên, đó là nguyên nhân gây ra sự truyền lại. Họ đã khắc phục vấn đề với dây đồng tại văn phòng trung tâm của họ (họ nói rằng họ phải tháo từng dây một, từng âm thanh như BS đối với tôi), nhưng sau khi họ làm điều này tại văn phòng trung tâm của họ, vấn đề đã được giải quyết.

Nhìn vào bản chụp mà bạn cung cấp (cảm ơn bạn đã làm điều đó!) Tôi có thể thấy một mẫu truyền lại khá cổ điển về phía đầu. Bạn có thể thấy nó xung quanh gói 50. Có một gói bị thiếu trong khoảng từ 51 đến 52. Điều gì đang xảy ra là đây:

1. -> Gói 50 Dữ liệu
2. <- Gói 51 ACK gói 50.
3. -> Gói dữ liệu 52
4. <- Gói 53 Gói ACK 50.
5. -> Gói 54 Dữ liệu
6. <- Gói 55 ACK gói 50.

Một gói dữ liệu đã bị hủy và người nhận sẽ chỉ ra điều này bằng cách tiếp tục ACK gói cho đến những gì nó thấy cho đến nay. Điều thú vị ở đây là cả hai bên đã TCP SACK Permitted Option = Truethiết lập khi họ đàm phán kết nối, vì vậy gói 55 nên có tiêu đề SACK trong đó và không. Lời cảm ơn có chọn lọc cho phép người nhận cho biết "Tôi đã thấy mọi thứ lên tới 51, nhưng cũng có 53-55", điều này làm giảm lượng truyền lại cần thiết để đưa mọi thứ trở lại tốc độ tối đa.

Điều xảy ra vì nó không thể sử dụng SACK là nó quay trở lại phương thức truyền lại TCP tiêu chuẩn để lặp lại "Tôi đã thấy tới 50" cho đến khi phía bên kia phát hiện ra và truyền lại mọi thứ từ 50 trở đi.

Có một truyền lại trong gói 66, ngay sau đó là một ACK cho đến gói 56. Sau khi truyền lại lần thứ hai (gói 72), kết nối trở lại đúng hướng.

Trước hết, có vẻ như các tiêu đề SACK đang bị loại bỏ bởi các sonicwalls đang ngăn việc truyền lại phục hồi nhanh như họ đã đàm phán. Cá nhân, tôi cho rằng SACK tước là vô nghĩa, nhưng người khác có thể không đồng ý.

Từ những gì tôi có thể nói về bản chụp này, bạn sẽ thấy mất gói thỉnh thoảng, điều này khiến các kết nối TCP đi qua các giao thức truyền lại thông thường. Tường lửa đang cản trở như một phương thức truyền lại mà cả hai bên đã đàm phán không được phép.