Rozwiązywanie problemów z niską przepustowością TCP Ethernet Ethernet

Ustawić

Wynajęliśmy kilka dzierżawionych linii, które przedstawiają się jako sieć warstwy 2, tzn. Masz jedną dużą rurkę w centrum danych, a odległe witryny mają mniejsze rurki. W sieci warstwy 2 możesz robić, co chcesz. Prawdopodobnie używają standardu 802.1ad, aby zapewnić każdemu klientowi oddzielną sieć w swojej sieci. AFAICS większość stron jest połączonych zwykłym VDSL.

Postanowiliśmy umieścić router w każdej witrynie i nadać każdej witrynie własną sieć VLAN. W ten sposób zapora sieciowa w DC ma tyle zdefiniowanych sieci VLAN, ile jest witryn. Każda witryna korzysta zatem z zakresu adresów we własnej sieci VLAN.

Internetowy diagram:

Problem

Teraz mamy problemy z przepustowością:

• Uruchomienie transferu FTP z witryny do DC działa dobrze przy prędkości około 10 Mb / s, co jest prędkością linii.
• Uruchomienie transferu FTP z DC do witryny nie działa poprawnie przy prędkości 6 Mb / s lub mniejszej.

Nie ma znaczenia, która strona inicjuje przeniesienie. Jedyną konsekwentną rzeczą jest to, że jeden kierunek nie działa dobrze. Szkoda, że ​​jest to kierunek w stronę witryny, ponieważ byłaby to przepustowość, której najbardziej potrzebujemy, ponieważ chcielibyśmy używać klientów serwerów terminali.

Około 10 sekund od transferu przepustowość spada. Podczas wąchania widzimy potwierdzenia DUP. Co może doprowadzić mnie do ograniczenia stawki na końcu dostawcy? (Obecnie nie mają pojęcia i lubię się upewnić, że nie jesteśmy winni przed eskalacją)

UWAGA Zdalne strony są w jakiś sposób ograniczone do 10 Mb. Ustawienie przełącznika na port Metro na 10 Mb również nie pomaga. W rzeczywistości jest to wtedy najgorsze (maks. 30 KB / s). Ustawienie 100 Mb działa dobrze, ale już zaczyna powodować zarysowany problem. To samo dla 1G.

Zrzuty przedstawiające problem można pobrać tutaj:

* http://178.63.11.6/dc-to-remote_dc-side.pcapng
* http://178.63.11.6/dc-to-remote_remote-side.pcapng

Diagnostyka

Na obrazku widać wykres IO Wireshark z pewnymi szczegółami błędu:

• po lewej: transfer FTP z DC na stronę
• po prawej: transfer FTP z witryny do DC

W przypadku, gdy druga strona zainicjuje transfer (tzn. Wstawi z DC, zamiast dostać się ze zdalnego), problem pozostaje niezmieniony.

Pozwólcie mi na to, co według was może być problemem.

AKTUALIZACJA # 1 (zintegrowana powyżej)

AKTUALIZACJA # 2 ( ZAKTUALIZOWANA )

To musi być kwestia kontroli zatorów.

Zauważ, że z DC do pilota mamy łącza 10G-> 1G-> 100M-> 10M-> 1G. <- nie działa

W przeciwnym kierunku mamy zatem odwrotność: 1G-> 10M-> 100M-> 1G-> 10G. <- w porządku

Pierwszy „1G-> 10M” to „niewidzialny” 10M w zdalnej witrynie, w którym wszystko, łącznie z prędkością portu łącza zwrotnego, jest ustawione na 1G, mimo że za nim jest tylko 10M (w sprzedaży).

Jednak 100 Mb / s na DC to rzeczywiste 100 Mb / s, interfejs jest skonfigurowany na 100 Mb / s na warstwie fizycznej.

Użyłem teraz iperf:

• Testy TCP działają poprawnie tylko w jednym kierunku (klient = DC, serwer = zdalny)

./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Serwer nasłuchuje na porcie TCP 5001
Rozmiar okna TCP: 85,3 KB (domyślnie)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klient łączy się z 192.168.x, portem TCP 5001
Rozmiar okna TCP: 16,0 KB (domyślnie)
-------------------------------------------------- ----------
[3] lokalny port 10.x 38195 połączony z portem 192.168.x port 5001
[3] 0,0- 2,0 s 1,44 MBytes 6,03 Mb / s
[3] 2,0 - 4,0 s 2,23 MBytes 9,37 Mb / s
[3] 4,0 - 6,0 s 2,28 MBytes 9,57 Mb / s
[3] 6,0 - 8,0 s 1,88 MBytes 7,90 Mb / s
[3] 8,0-10,0 s 1,00 MBytes 4,19 Mb / s
[3] 10,0-12,0 s 1,30 MBytes 5,47 Mb / s
[3] 12,0-14,0 s 688 KBytes 2,82 Mb / s
[3] 14,0-16,0 sek. 840 KBytes 3,44 Mb / s
[3] 16,0-18,0 s 1,03 MBytes 4,33 Mb / s
[3] 18,0-20,0 s 1,01 MBytes 4,23 Mb / s
[3] 20,0–22,0 s 1,03 MBytes 4,33 Mb / s
[3] 22,0-24,0 s 1,18 MBytes 4,95 Mb / s
[3] 24,0–26,0 sek. 904 KBytes 3,70 Mb / s
[3] 26,0–28,0 sek. 840 KBytes 3,44 Mb / s
[3] 28,0-30,0 s 936 KBytes 3,83 Mb / s
[3] 30,0–32,0 s 1,09 MBytes 4,59 Mb / s
[3] 32,0–34,0 s 960 KBytes 3,93 Mb / s
[3] 34,0 - 36,0 s 752 KBytes 3,08 Mb / s
[3] 36,0-38,0 s 1,09 MBytes 4,59 Mb / s
[3] 38,0-40,0 s 1,09 MBytes 4,59 Mb / s
[3] 40,0–42,0 s 840 KBytes 3,44 Mb / s
[3] 42,0–44,0 s 1,27 MBytes 5,34 Mb / s
[3] 44,0–46,0 s 1,16 MBytes 4,85 Mb / s
[3] 46,0–48,0 sek. 840 KBytes 3,44 Mb / s
[3] 48,0-50,0 s 960 KBytes 3,93 Mb / s
[3] 50,0-52,0 s 1,28 MBytes 5,37 Mb / s
[3] 52,0-54,0 s 1,09 MBytes 4,59 Mb / s
[3] 54,0-56,0 s 992 KBytes 4,06 Mb / s
[3] 56,0-58,0 s 1,00 MBytes 4,19 Mb / s
[3] 58,0-60,0 s 1,09 MBytes 4,59 Mb / s
[3] 0,0-60,2 s 33,9 MBytes 4,73 Mb / s
[5] lokalny 10.x port 5001 połączony z 192.168.x port 10965
[5] 0,0- 2,0 s 1,85 MBytes 7,75 Mb / s
[5] 2,0 - 4,0 s 1,90 MBytes 7,98 Mb / s
[5] 4,0 - 6,0 s 1,89 MBytes 7,93 Mb / s
[5] 6,0 - 8,0 s 1,92 MBytes 8,07 Mb / s
[5] 8,0-10,0 s 1,91 MBytes 8,02 Mb / s
[5] 10,0-12,0 s 1,83 MBytes 7,69 Mb / s
[5] 12,0-14,0 s 1,86 MBytes 7,78 Mb / s
[5] 14,0-16,0 s 1,79 MBytes 7,52 Mb / s
[5] 16,0-18,0 s 1,79 MBytes 7,52 Mb / s
[5] 18,0-20,0 s 1,89 MBytes 7,91 Mb / s
[5] 20,0–22,0 s 1,91 MBytes 8,00 Mb / s
[5] 22,0-24,0 s 1,88 MBytes 7,91 Mb / s
[5] 24,0–26,0 s 1,95 MBytes 8,16 Mb / s
[5] 26,0–28,0 s 1,90 MBytes 7,99 Mb / s
[5] 28,0-30,0 s 1,87 MBytes 7,84 Mb / s
[5] 30,0–32,0 s 1,85 MBytes 7,77 Mb / s
[5] 32,0–34,0 s 1,55 MBytes 6,49 Mb / s
[5] 34,0-36,0 s 1,92 MBytes 8,07 Mb / s
[5] 36,0–38,0 sek. 1,90 MBytes 7,99 Mb / s
[5] 38,0-40,0 s 1,84 MBytes 7,73 Mb / s
[5] 40,0–42,0 s 1,66 MBytes 6,95 Mb / s
[5] 42,0–44,0 s 1,92 MBytes 8,07 Mb / s
[5] 44,0–46,0 s 1,91 MBytes 7,99 Mb / s
[5] 46,0–48,0 s 1,90 MBytes 7,98 Mb / s
[5] 48,0-50,0 s 1,84 MBytes 7,70 Mb / s
[5] 50,0-52,0 s 1,93 MBytes 8,09 Mb / s
[5] 52,0-54,0 s 1,80 MBytes 7,54 Mb / s
[5] 54,0-56,0 s 1,83 MBytes 7,67 Mb / s
[5] 56,0-58,0 sek. 1,88 MBytes 7,86 Mbits / sec
[5] 58,0-60,0 s 1,85 MBytes 7,78 Mb / s
[5] 0,0-60,3 s 56,0 MBytes 7,79 Mb / s

• Aby przejść do sedna, oto testy UDP z dwóch hostów w tej samej sieci VLAN, ale korzystających z połączenia Metro, 200 = zdalne, 201 = DC

Widzimy wzrost strat pakietów wraz ze wzrostem przepustowości (gdy zbliżamy się do 10 Mb / s, mamy 0,93%, zaczyna być krytyczny ... i wyjaśniałby również, dlaczego TCP ma problemy z wydajnością)

+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Serwer nasłuchuje na porcie UDP 5001
Odbieranie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klient łączy się z 192.168.191.200, port UDP 5001
Wysyłanie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
[4] lokalny port 192.168.191.201 61759 podłączony do 192.168.191.200 port 5001
[ID] Pasmo transferu interwału
[4] 0,0–1,0 s 128 KBytes 1,05 Mb / s
[4] 1,0–2,0 s 128 KBytes 1,05 Mb / s
[4] 2,0 - 3,0 s 129 KBytes 1,06 Mb / s
[4] 3,0 - 4,0 s 128 KBytes 1,05 Mb / s
[4] 4,0 - 5,0 s 128 KBytes 1,05 Mb / s
[4] 5,0 - 6,0 s 128 KBytes 1,05 Mb / s
[4] 6,0 - 7,0 s 128 KBytes 1,05 Mb / s
[4] 7,0 - 8,0 s 128 KBytes 1,05 Mb / s
[4] 8,0 - 9,0 s 128 KBytes 1,05 Mb / s
[4] 9,0-10,0 s 129 KBytes 1,06 Mb / s
[4] 10,0-11,0 s 128 KBytes 1,05 Mb / s
[4] 11,0-12,0 s 128 KBytes 1,05 Mb / s
[4] 12,0–13,0 s 128 KBytes 1,05 Mb / s
[4] 13,0-14,0 s 128 KBytes 1,05 Mb / s
[4] 14,0-15,0 s 128 KBytes 1,05 Mb / s
[4] 15,0-16,0 s 128 KBytes 1,05 Mb / s
[4] 16,0-17,0 s 128 KBytes 1,05 Mb / s
[4] 17,0–0,0 sek. 128 KBytes 1,05 Mb / s
[4] 18,0–19,0 sek. 131 KBytes 1,07 Mb / s
[4] 19,0-20,0 s 128 KBytes 1,05 Mb / s
[4] 0,0-20,0 s 2,50 MBytes 1,05 Mb / s
[4] Wysłano 1785 datagramów
[4] Raport serwera:
[4] 0,0-20,0 s 2,50 MBytes 1,05 Mb / s 0,257 ms 0/1785 (0%)
[3] lokalny port 192.168.191.201 5001 połączony z portem 192.168.191.200 port 50749
[3] 0,0–1,0 s 128 kB 1,05 Mb / s 0,285 ms 0/89 (0%)
[3] 1,0 - 2,0 s 128 KB bajtów 1,05 Mb / s 0,313 ms 0/89 (0%)
[3] 2,0-3,0 s 128 kB 1,05 Mb / s 0,278 ms 0/89 (0%)
[3] 3,0 - 4,0 s 128 kB 1,05 Mb / s 0,241 ms 0/89 (0%)
[3] 4,0 - 5,0 s 128 KB bajtów 1,05 Mb / s 0,266 ms 0/89 (0%)
[3] 5,0 - 6,0 s 128 KBytes 1,05 Mb / s 0,293 ms 0/89 (0%)
[3] 6,0- 7,0 s 128 kB 1,05 Mb / s 0,314 ms 0/89 (0%)
[3] 7,0 - 8,0 s 128 kB 1,05 Mb / s 0,280 ms 0/89 (0%)
[3] 8,0 - 9,0 s 128 KBytes 1,05 Mb / s 0,242 ms 0/89 (0%)
[3] 9,0-10,0 s 129 KBytes 1,06 Mb / s 0,250 ms 0/90 (0%)
[3] 10,0-11,0 s 128 KBytes 1,05 Mb / s 0,275 ms 0/89 (0%)
[3] 11,0-12,0 s 128 KBytes 1,05 Mb / s 0,299 ms 0/89 (0%)
[3] 12,0–13,0 s 128 KBytes 1,05 Mb / s 0,327 ms 0/89 (0%)
[3] 13,0-14,0 s 128 KBytes 1,05 Mb / s 0,290 ms 0/89 (0%)
[3] 14,0-15,0 s 128 KBytes 1,05 Mb / s 0,251 ms 0/89 (0%)
[3] 15,0-16,0 s 128 KBytes 1,05 Mb / s 0,275 ms 0/89 (0%)
[3] 16,0-17,0 s 128 KBytes 1,05 Mb / s 0,303 ms 0/89 (0%)
[3] 17,0–0,0 sek. 128 KBytes 1,05 Mb / s 0,333 ms 0/89 (0%)
[3] 18,0–19,0 s 128 KBytes 1,05 Mb / s 0,294 ms 0/89 (0%)
[3] 19,0-20,0 s 131 KBytes 1,07 Mb / s 0,281 ms 0/91 (0%)
[3] 0,0-20,0 s 2,50 MBytes 1,05 Mb / s 0,305 ms 0/1785 (0%)

+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 5m
+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Serwer nasłuchuje na porcie UDP 5001
Odbieranie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klient łączy się z 192.168.191.200, port UDP 5001
Wysyłanie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
[4] lokalny port 192.168.191.201 61760 podłączony do 192.168.191.200 port 5001
[ID] Pasmo transferu interwału
[4] 0,0–1,0 s 610 KBytes 5,00 Mb / s
[4] 1,0–2,0 s 609 KBytes 4,99 Mb / s
[4] 2,0–3,0 s 610 kB 5,00 Mb / s
[4] 3,0 - 4,0 s 609 KBytes 4,99 Mb / s
[4] 4,0 - 5,0 s 610 KBytes 5,00 Mb / s
[4] 5,0 - 6,0 s 609 KBytes 4,99 Mb / s
[4] 6,0 - 7,0 s 610 KBytes 5,00 Mb / s
[4] 7,0 - 8,0 s 609 KBytes 4,99 Mb / s
[4] 8,0 - 9,0 s 610 KBytes 5,00 Mb / s
[4] 9,0-10,0 s 619 KBytes 5,07 Mb / s
[4] 10,0-11,0 s 610 KBytes 5,00 Mb / s
[4] 11,0-12,0 s 609 KBytes 4,99 Mb / s
[4] 12,0–13,0 sek. 609 KBytes 4,99 Mb / s
[4] 13,0-14,0 s 610 KBytes 5,00 Mb / s
[4] 14,0–15,0 sek. 609 KBytes 4,99 Mb / s
[4] 15,0-16,0 s 610 KBytes 5,00 Mb / s
[4] 16,0-17,0 s 609 KBytes 4,99 Mb / s
[4] 17,0–0,0 sek. 610 KBytes 5,00 Mb / s
[4] 18,0–19,0 sek. 619 KBytes 5,07 Mb / s
[4] 19,0-20,0 s 609 KBytes 4,99 Mb / s
[4] 0,0-20,0 s 11,9 MBytes 5,00 Mb / s
[4] Wysłano 8504 datagramów
[4] Raport serwera:
[4] 0,0-20,0 s 11,9 MBytes 4,99 Mb / s 0,000 ms 12/8503 (0,14%)
[4] 0,0-20,0 sek. 1 datagramy odebrane poza kolejnością
[3] lokalny port 192.168.191.201 5001 połączony z 192.168.191.200 port 50750
[3] 0,0–1,0 s 606 KBytes 4,96 Mb / s 2,238 ms 1/423 (0,24%)
[3] 1,0 - 2,0 s 610 KBytes 5,00 Mb / s 2,739 ms 0/425 (0%)
[3] 2,0 - 3,0 s 609 KBytes 4,99 Mb / s 3,089 ms 1/425 (0,24%)
[3] 3,0 - 4,0 s 609 KBytes 4,99 Mb / s 3,605 ms 0/424 (0%)
[3] 4,0 - 5,0 s 607 KBytes 4,97 Mb / s 1,954 ms 0/423 (0%)
[3] 5,0 - 6,0 s 612 KBytes 5,01 Mb / s 2,666 ms 0/426 (0%)
[3] 6,0 - 7,0 s 607 KBytes 4,97 Mb / s 2,602 ms 0/423 (0%)
[3] 7,0 - 8,0 s 612 KBytes 5,01 Mb / s 2,960 ms 0/426 (0%)
[3] 8,0 - 9,0 s 609 KBytes 4,99 Mb / s 2,512 ms 0/424 (0%)
[3] 9,0-10,0 s 619 KBytes 5,07 Mb / s 2,133 ms 0/431 (0%)
[3] 10,0-11,0 sek. 609 KBytes 4,99 Mb / s 3,605 ms 1/425 (0,24%)
[3] 11,0-12,0 sek. 609 KBytes 4,99 Mb / s 2,509 ms 0/424 (0%)
[3] 12,0–13,0 s 610 KBytes 5,00 Mb / s 3,570 ms 0/425 (0%)
[3] 13,0-14,0 s 609 kB 4,99 Mb / s 3,077 ms 1/425 (0,24%)
[3] 14,0-15,0 sek. 609 KBytes 4,99 Mb / s 2,679 ms 0/424 (0%)
[3] 15,0-16,0 sek. 609 KBytes 4,99 Mb / s 1,887 ms 0/424 (0%)
[3] 16,0-17,0 sek. 610 KBytes 5,00 Mb / s 2,651 ms 0/425 (0%)
[3] 17,0-18,0 sek. 609 KBytes 4,99 Mb / s 3,390 ms 0/424 (0%)
[3] 18,0–19,0 s 617 KBytes 5,06 Mb / s 2,601 ms 0/430 (0%)
[3] 19,0-20,0 s 612 KBytes 5,01 Mb / s 3,525 ms 0/426 (0%)
[3] 0,0-20,0 s 11,9 MBytes 4,99 Mb / s 3,156 ms 3/8503 (0,035%)
[3] 0,0-20,0 sek. 1 datagramy odebrane poza kolejnością

+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Serwer nasłuchuje na porcie UDP 5001
Odbieranie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klient łączy się z 192.168.191.200, port UDP 5001
Wysyłanie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
[4] lokalny port 192.168.191.201 61761 podłączony do 192.168.191.200 port 5001
[ID] Pasmo transferu interwału
[4] 0,0–1,0 s 1,07 MBytes 9,00 Mb / s
[4] 1,0–2,0 s 1,07 MBytes 8,98 Mb / s
[4] 2,0–3,0 s 1,07 MBytes 9,00 Mb / s
[4] 3,0 - 4,0 s 1,07 MBytes 8,98 Mb / s
[4] 4,0 - 5,0 s 1,07 MBytes 9,00 Mb / s
[4] 5,0 - 6,0 s 1,07 MBytes 8,98 Mb / s
[4] 6,0 - 7,0 s 1,07 MBytes 8,98 Mb / s
[4] 7,0 - 8,0 s 1,07 MBytes 9,00 Mb / s
[4] 8,0 - 9,0 s 1,07 MBytes 8,98 Mb / s
[4] 9,0-10,0 s 1,09 MBytes 9,14 Mb / s
[4] 10,0-11,0 s 1,07 MBytes 9,00 Mb / s
[4] 11,0-12,0 s 1,07 MBytes 8,98 Mb / s
[4] 12,0–13,0 s 1,07 MBytes 8,98 Mb / s
[4] 13,0-14,0 s 1,07 MBytes 9,00 Mb / s
[4] 14,0-15,0 s 1,07 MBytes 8,98 Mb / s
[4] 15,0-16,0 s 1,07 MBytes 9,00 Mb / s
[4] 16,0-17,0 s 1,07 MBytes 8,98 Mb / s
[4] 17,0–0,0 sek. 1,07 MBytes 8,98 Mb / s
[4] 18,0-19,0 ​​s 1,09 MBytes 9,14 Mb / s
[4] 19,0-20,0 s 1,07 MBytes 9,00 Mb / s
[4] 0,0-20,0 s 21,5 MBytes 9,00 Mb / s
[4] Wysłano 15315 datagramów
[4] Raport serwera:
[4] 0,0-20,0 s 21,3 MBytes 8,94 Mb / s 0,104 ms 96/15314 (0,63%) !!!!!!!!!!
[4] 0,0-20,0 sek. 1 datagramy odebrane poza kolejnością
[3] lokalny port 192.168.191.201 5001 podłączony do 192.168.191.200 portu 50751
[3] 0,0–1,0 s 1,06 MBytes 8,89 Mb / s 2,405 ms 0/756 (0%)
[3] 1,0 - 2,0 s 1,07 MBytes 9,00 Mb / s 2,308 ms 0/765 (0%)
[3] 2,0 - 3,0 s 1,07 MBytes 9,00 Mb / s 2,305 ms 0/765 (0%)
[3] 3,0 - 4,0 s 1,07 MBytes 8,97 Mb / s 2,290 ms 1/764 (0,13%)
[3] 4,0 - 5,0 s 1,07 MBytes 8,98 Mb / s 2,271 ms 1/765 (0,13%)
[3] 5,0 - 6,0 s 1,07 MBytes 8,98 Mb / s 2,313 ms 0/764 (0%)
[3] 6,0- 7,0 s 1,07 MBytes 9,00 Mb / s 2,191 ms 0/765 (0%)
[3] 7,0 - 8,0 s 1,07 MBytes 8,95 Mb / s 2,314 ms 3/764 (0,39%)
[3] 8,0 - 9,0 s 1,07 MBytes 8,98 Mb / s 2,232 ms 1/765 (0,13%)
[3] 9,0-10,0 s 1,09 MBytes 9,13 Mb / s 2,257 ms 0/776 (0%)
[3] 10,0-11,0 s 1,07 MBytes 8,98 Mb / s 2,365 ms 0/764 (0%)
[3] 11,0-12,0 s 1,07 MBytes 8,98 Mb / s 2,301 ms 1/765 (0,13%)
[3] 12,0-13,0 s 1,07 MBytes 8,98 Mb / s 2,277 ms 0/764 (0%)
[3] 13,0-14,0 s 1,07 MBytes 9,00 Mb / s 2,323 ms 0/765 (0%)
[3] 14,0-15,0 s 1,07 MBytes 9,00 Mb / s 2,176 ms 0/765 (0%)
[3] 15,0-16,0 s 1,07 MBytes 8,96 Mb / s 2,273 ms 2/764 (0,26%)
[3] 16,0-17,0 s 1,07 MBytes 8,98 Mb / s 2,313 ms 0/764 (0%)
[3] 17,0-18,0 sek. 1,07 MBytes 8,98 Mb / s 2,247 ms 1/765 (0,13%)
[3] 18,0-19,0 ​​s 1,09 MBytes 9,11 Mb / s 2,266 ms 1/776 (0,13%)
[3] 19,0-20,0 s 1,07 MBytes 8,97 Mb / s 2,394 ms 1/764 (0,13%)
[3] 0,0-20,0 s 21,5 MBytes 8,99 Mb / s 2,659 ms 11/15314 (0,072%)
[3] 0,0-20,0 sek. 1 datagramy odebrane poza kolejnością

+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Serwer nasłuchuje na porcie UDP 5001
Odbieranie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klient łączy się z 192.168.191.200, port UDP 5001
Wysyłanie datagramów 1470 bajtów
Rozmiar bufora UDP: 64,0 KB (domyślnie)
-------------------------------------------------- ----------
[4] lokalny port 192.168.191.201 61762 podłączony do 192.168.191.200 port 5001
[ID] Pasmo transferu interwału
[4] 0,0–1,0 s 1,17 MBytes 9,84 Mb / s
[4] 1,0–2,0 s 1,17 MBytes 9,84 Mb / s
[4] 2,0 - 3,0 s 1,17 MBytes 9,84 Mb / s
[4] 3,0 - 4,0 s 1,17 MBytes 9,84 Mb / s
[4] 4,0 - 5,0 s 1,17 MBytes 9,84 Mb / s
[4] 5,0 - 6,0 s 1,17 MBytes 9,83 Mb / s
[4] 6,0 - 7,0 s 1,17 MBytes 9,84 Mb / s
[4] 7,0 - 8,0 s 1,17 MBytes 9,84 Mb / s
[4] 8,0 - 9,0 s 1,17 MBytes 9,84 Mb / s
[4] 9,0-10,0 s 1,19 MBytes 10,0 Mb / s
[4] 10,0-11,0 s 1,17 MBytes 9,84 Mb / s
[4] 11,0-12,0 s 1,17 MBytes 9,84 Mb / s
[4] 12,0–13,0 s 1,17 MBytes 9,83 Mb / s
[4] 13,0-14,0 s 1,17 MBytes 9,85 Mb / s
[4] 14,0-15,0 s 1,17 MBytes 9,83 Mb / s
[4] 15,0-16,0 s 1,17 MBytes 9,85 Mb / s
[4] 16,0-17,0 s 1,17 MBytes 9,83 Mb / s
[4] 17,0–18,0 s 1,17 MBytes 9,84 Mb / s
[4] 18,0-19,0 ​​s 1,19 MBytes 10,0 Mbits / sec
[4] 19,0-20,0 s 1,17 MBytes 9,84 Mb / s
[4] 0,0-20,0 s 23,5 MBytes 9,85 Mb / s
[4] Wysłano 16765 datagramów
[4] Raport serwera:
[4] 0,0-20,0 s 23,3 MBytes 9,74 Mb / s 3,421 ms 156/16764 (0,93%) !!!!!!!!!!
[4] 0,0-20,0 sek. 1 datagramy odebrane poza kolejnością
[3] lokalny port 192.168.191.201 5001 podłączony do 192.168.191.200 portu 50752
[3] 0,0–1,0 s 1,16 MBytes 9,74 Mb / s 2,131 ms 0/828 (0%)
[3] 1,0 - 2,0 s 1,17 MBytes 9,84 Mb / s 2.140 ms 0/837 (0%)
[3] 2,0-3,0 s 1,17 MBytes 9,83 Mb / s 2,099 ms 1/837 (0,12%)
[3] 3,0 - 4,0 s 1,17 MBytes 9,84 Mb / s 2,113 ms 0/837 (0%)
[3] 4,0 - 5,0 s 1,17 MBytes 9,84 Mb / s 2,105 ms 0/837 (0%)
[3] 5,0 - 6,0 s 1,17 MBytes 9,83 Mb / s 2,058 ms 1/837 (0,12%)
[3] 6,0- 7,0 s 1,17 MBytes 9,82 Mb / s 2,165 ms 1/836 (0,12%)
[3] 7,0 - 8,0 s 1,17 MBytes 9,84 Mb / s 2,156 ms 0/837 (0%)
[3] 8,0 - 9,0 s 1,17 MBytes 9,82 Mb / s 2,135 ms 2/837 (0,24%)
[3] 9,0-10,0 s 1,19 MBytes 9,97 Mb / s 2,152 ms 2/850 (0,24%)
[3] 10,0-11,0 s 1,17 MBytes 9,83 Mb / s 2,153 ms 1/837 (0,12%)
[3] 11,0-12,0 s 1,17 MBytes 9,84 Mb / s 2,127 ms 0/837 (0%)
[3] 12,0-13,0 s 1,17 MBytes 9,83 Mb / s 2,136 ms 1/837 (0,12%)
[3] 13,0-14,0 s 1,17 MBytes 9,82 Mb / s 2,087 ms 2/837 (0,24%)
[3] 14,0-15,0 s 1,17 MBytes 9,83 Mb / s 2,061 ms 1/837 (0,12%)
[3] 15,0-16,0 s 1,17 MBytes 9,84 Mb / s 2,045 ms 0/837 (0%)
[3] 16,0-17,0 s 1,17 MBytes 9,82 Mb / s 2,203 ms 1/836 (0,12%)
[3] 17,0-18,0 sek. 1,17 MBytesa 9,84 Mb / s 2,165 ms 0/837 (0%)
[3] 18,0-19,0 ​​s 1,17 MBytes 9,83 Mb / s 2,154 ms 1/837 (0,12%)
[3] 19,0-20,0 s 1,19 MBytes 9,98 Mb / s 2,209 ms 0/849 (0%)
[3] 0,0-20,0 s 23,5 MBytes 9,84 Mb / s 2,548 ms 13/16764 (0,078%)
[3] 0,0-20,0 sek. 1 datagramy odebrane poza kolejnością

Prawdziwe pytanie pozostaje:

Nie przesadzamy z subskrypcją łącza DC, ponieważ ma on prędkość 100 Mb / s i nie może wysłać więcej niż 100 Mb / s. Jednak zdalne strony mają prędkość 10 Mb / s.

• Czy bufory po stronie zdalnej przepełniają się i upuszczają pakiety?
• Czy ruch dostawcy usług kształtuje ruch? (Czy ruch przychodzący z innego węzła miałby wpływ na urządzenie kształtujące ruch ISP, czy tylko ruch wchodzący do węzła (z zewnątrz)) ... Widzisz, co mam na myśli?

Dlaczego TCP nie może sobie z tym wszystkim poradzić?

Aktualizacja nr 3 Użyłem teraz następującego scenariusza:

Laptop ------- ... LAN ... --- DC switch --- Metro-Eth --- Laptop (directly connected)
NIC@10Mbps                       100Mbps                  NIC@10Mbps

Oto utrata pakietu w kierunku zdalnym DC->: (test Uper iperf 9 Mbps)

[  3] local 192.168.191.200 port 5001 connected with 192.168.191.201 port 55236
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   912 KBytes  7.47 Mbits/sec   2.713 ms    0/  635 (0%)
[  3]  1.0- 2.0 sec  1001 KBytes  8.20 Mbits/sec   2.168 ms    0/  697 (0%)
[  3]  2.0- 3.0 sec  1001 KBytes  8.20 Mbits/sec   2.478 ms    0/  697 (0%)
[  3]  3.0- 4.0 sec   999 KBytes  8.18 Mbits/sec   0.933 ms    0/  696 (0%)
[  3]  4.0- 5.0 sec  1001 KBytes  8.20 Mbits/sec   2.620 ms    0/  697 (0%)
[  3]  5.0- 6.0 sec  1001 KBytes  8.20 Mbits/sec   2.721 ms    0/  697 (0%)
[  3]  6.0- 7.0 sec  1001 KBytes  8.20 Mbits/sec   2.089 ms    0/  697 (0%)
[  3]  7.0- 8.0 sec   999 KBytes  8.18 Mbits/sec   2.641 ms    0/  696 (0%)
[  3]  8.0- 9.0 sec  1002 KBytes  8.21 Mbits/sec   0.896 ms    0/  698 (0%)
[  3]  9.0-10.0 sec  1015 KBytes  8.31 Mbits/sec   2.557 ms    0/  707 (0%)
[  3] 10.0-11.0 sec   999 KBytes  8.18 Mbits/sec   2.822 ms    1/  697 (0.14%)
[  3] 11.0-12.0 sec   999 KBytes  8.18 Mbits/sec   1.551 ms    1/  697 (0.14%)
[  3] 12.0-13.0 sec   998 KBytes  8.17 Mbits/sec   2.504 ms    2/  697 (0.29%)
[  3] 13.0-14.0 sec   995 KBytes  8.15 Mbits/sec   2.038 ms    3/  696 (0.43%)
[  3] 14.0-15.0 sec   991 KBytes  8.11 Mbits/sec   2.539 ms    7/  697 (1%)
[  3] 15.0-16.0 sec   992 KBytes  8.13 Mbits/sec   2.759 ms    6/  697 (0.86%)
[  3] 16.0-17.0 sec   998 KBytes  8.17 Mbits/sec   2.229 ms    2/  697 (0.29%)
[  3] 17.0-18.0 sec   993 KBytes  8.14 Mbits/sec   2.723 ms    4/  696 (0.57%)
[  3] 18.0-19.0 sec   998 KBytes  8.17 Mbits/sec   2.038 ms    2/  697 (0.29%)
[  3] 19.0-20.0 sec  1012 KBytes  8.29 Mbits/sec   2.575 ms    3/  708 (0.42%)
[  3]  0.0-20.0 sec  19.5 MBytes  8.15 Mbits/sec   2.775 ms   31/13917 (0.22%)
[  3]  0.0-20.0 sec  1 datagrams received out-of-order

Drugi kierunek jest w porządku. Jednak podczas uruchamiania testu TCP kierunek zdalny> DC nie działa znacznie lepiej niż kierunek zdalny DC>> (około 5 Mb / s) .......

Nie jestem pewien, czy osiągnęliśmy sedno tego.

Odwoływanie się do naszego czatu Stack Exchange ...

Krótka historia, musisz kontrolować niedopasowania prędkości po obu stronach łączy metra Ethernet ... Zmieniłem twój schemat dla jasności ... ^{Uwaga 1}

• DC (pokazany na zielono) bardzo szybko przechodzi z 10GE do 100M ... jest to 100-krotna zmiana prędkości i zwykle musisz zaimplementować jakąś formę qos (taką jak kształtowanie), aby złagodzić tak duże przejście. U dołu tej odpowiedzi znajdują się dowody, że DC wymaga kształtowania (na stronę) ...
• Odległa strona bardzo szybko przechodzi z 1GE do 10M CIR ... to znowu jest 100-krotna zmiana prędkości. Zazwyczaj wymagane są obejścia związane z kształtowaniem lub innymi Qos.
• Wydaje się również, że występuje niedopasowanie prędkości między DC UNI (100M) a zdalnym UNI (10M); samo to wymaga rozwiązania do zarządzania przepustowością dla poszczególnych witryn.

Do Twojej wiadomości, jeśli Twój dostawca wdraża usługi zgodne z MEF , nie kształtuje, tylko nadzoruje . Ruch TCP zwykle lepiej radzi sobie z kształtowaniem .

Potrzeba własnego QoS

Wydaje się, że kwestionujesz potrzebę qos , dlatego zacytuję z oficjalnego dokumentu MEF „Understanding Carrier Ethernet Throughput” , strona 9 ... w ramach przeglądu, klient w dokumencie 2 oficjalnego raportu MEF ma lepsze sytuacji niż ty. .. zakupili CIR 50 Mb / s, ale ich UNI jest dostarczany na 1GE ... Twoja zdalna strona ma CIR 10 Mb / s na UNI 1GE.

The transition from legacy services such as T1, T3, Frame Relay and ATM
to Carrier Ethernet has created some unintended consequences. Not all customers have 
conforming equipment facing the network which properly limits/shapes the traffic outbound
to the network, with deleterious results.  For instance, on the 1 GigE interface of
Figure 2, if the customer’s equipment accidentally transmits long bursts of data at 
150 Mbits instead of the SLA’s Committed Information Rate of 50 Mbits, 67% of the data 
may be lost and network breakdown will likely result.

Odpowiadanie na inne pytania TCP w edycji ...

Nie przesadzamy z subskrypcją łącza DC, ponieważ ma on prędkość 100 Mb / s i nie może wysłać więcej niż 100 Mb / s ...

Nie zgadzam się, możesz wysłać mikroburst s przy 10GE ponieważ DC ma 10GE linki, ale metro UNI jest 100Mbps. Jedno otwarte pytanie dotyczy ilości buforowania na przełączniku Enterasys LAN (Switch A) podczas przejścia z 10GE na 100M.

Dlaczego TCP nie może sobie z tym wszystkim poradzić?

TCP radzi sobie ze spowolnieniem, gdy widzi utratę pakietów ... naprawdę spowalnia (i może przerwać połączenie), powodując poważną utratę pakietów. Tak więc TCP robi to, co powinien ... jako inżynier sieci, Twoim celem jest zbudowanie sieci z warunkami, które uszczęśliwią TCP.

Inne pytania TCP z czatu

Marki powiedział : Nie rozumiem, co jest upuszczane gdzie i przez kogo oraz dlaczego i dlaczego TCP nie zajmuje się po prostu faktem, że na jednym końcu jest (rzeczywista) 100 Mb, a na drugim tylko 10 Mb / s.

Odnośnie potrzeby buforowania przez TCP i konsekwencji braku buforów :

Fakt nr 1: TCP potrzebuje buforowania dla zmian prędkości, ponieważ jest zaprojektowany jako system kontroli sprzężenia zwrotnego .

Korzystając z analogii jazdy: jako dobrzy kierowcy zawsze zostawiamy kilka sekund przestrzeni między nami a samochodem przed nami; pod pewnymi względami ta przestrzeń między samochodami jest z grubsza analogiczna do bufora sieciowego. Jeśli osoba przed nami wciśnie hamulec, gdy zwierzę biegnie przed nimi, przestrzeń między naszymi samochodami (miejmy nadzieję) uniemożliwia nam uderzenie w ich samochód. Opuszczamy przestrzeń, ponieważ oczy potrzebują czasu, aby zobaczyć światła stopu, reakcję stopy i hamulce, aby rozproszyć wystarczającą ilość ciepła; nasze oczy dają nam wizualny system kontroli sprzężenia zwrotnego.

Podobnie, gdy sesja FTP zostanie wysadzona przy 10GE, gwałtowny wzrost ruchu może wynosić do 4 MB (w twoim przypadku) ze względu na rozmiar okna skalowanego TCP, zanim gniazdo musi się zatrzymać i poczekać na ACK TCP. Tymczasem jeśli strumień ruchu 10GE nagle uderza w „Fast Ethernet”, TCP musi stopniowo zwalniać. Głębokie bufory w sprzęcie sieciowym pozwalają TCP na upuszczenie znacznie mniejszej liczby pakietów, gdy wykonuje zmiany prędkości; Jeśli jednak nie masz buforów, możesz upuścić 99% okna 4 MB TCP, gdy jest ono zmniejszone z 10GE do 100M. Pomyśl o tej poważnej 99% stracie jako awarii gniazda TCP; TCP reaguje przewidywalnie na względnie stopniową utratę pakietów. TCP reaguje znacznie mniej przewidywalnie na trwającą, poważną utratę pakietów ^{Uwaga 3} .

Na pytanie, dlaczego nie należy używać asymetrycznego CIR metra Ethernet z 100 M na DC i 10 M na pilocie, zadaj sobie retoryczne pytanie „kto buforuje ten ruch o przepustowości 100 Mb / s, gdy trafi na tani NID Ethernet 10 Mb / s, że twoje metro -Dostawca sieci dał ci?

Jeśli nikt nie buforuje dużych (patrz Uwaga 2) zmian prędkości, punkty te są potencjalnymi miejscami do przerywania ruchu.

Co jest upuszczane przez kogo :

Gdy ruch TCP opuszcza centrum danych, można go usunąć z trzech miejsc:

• W D1: ponieważ przełączniki LAN rzadko mają wystarczająco głębokie buforowanie dla przejścia prędkości 100: 1
• W D2: jeśli NID kiedykolwiek negocjował łącze UNI z większą prędkością niż CIR ; obecnie tak nie jest, więc nie oczekuję spadków.
• W D3: ze wszystkich powodów, które właśnie opisałem o asymetrycznych CIR Metro Ethernet .

Gdy ruch TCP trafia do centrum danych ...

• W D4: ponieważ masz 1GE UNI i 10M CIR ; jest to patologiczny przypadek D2, o którym wspomniałem powyżej.

Jak złagodzić niedopasowania prędkości:

Przykładowe rozwiązanie EVPL :

• W takiej topologii przełączanej EVPL z punktowymi punktami EVC od prądu stałego do każdego pilota jest prawdopodobnie najlepszą opcją (patrz schemat powyżej). Spowodowałoby to zastosowanie indywidualnego CIR do każdego EVC. Uwaga: wszystkie inne wytyczne QoS zawarte w tej odpowiedzi mają zastosowanie ... tzn. Unikaj dużych prędkości przejścia ^{Uwaga 2} bez testowania, czy Twój sprzęt poradzi sobie z tym wystarczająco dobrze.
• Alternatywnie, możesz rozważyć zakup usług metrae, które mają symetryczne stawki między DC a pilotem; chociaż przyznałbym, że może to nie być najbardziej praktyczna wskazówka.
• Do Twojej wiadomości, klasycznym rozwiązaniem tego problemu dla usług routowanych jest zakup routerów, które obsługują kształtowanie przy wymaganych prędkościach, a następnie kształtowanie ruchu Metroe do odpowiedniego CIR (na zdalną stronę). FYI, strona zdalna mogłaby uciec z dość małym routerem, ponieważ jest to tylko wejście 1GE i 10 Mb / s CIR ... Miesiące temu, kiedy rozmawialiśmy o projekcie tej usługi, zaleciłem routing, jeśli nie podoba ci się technologia ...

• Jeśli nie ma dodatkowych pieniędzy do wydania i nie może ponownie inżynier swoją usługę Metro Ethernet, można masować niedopasowania szybkości bardziej stopniowo. Nigdy tego nie robiłem, ale w zasadzie można spróbować wykonać zmiany prędkości od 10 do 1, zamiast od 100 do 1 (to jest to, co obecnie masz zarówno na DC, jak i na odległość):

  • Zamiast kupować router w celu ukształtowania pilota w 10M, możesz spróbować zmusić zdalny UNI do automatycznej negocjacji przy 100M zamiast 1GE; GigabitEthernet wymaga wszystkich pinów w kablu Cat5e , więc możesz skutecznie zmusić go do 100M za pomocą wtyczki mod RJ45, która tylko łączy piny 1, 2, 3 i 6.
  • Zamiast kupować router w celu ukształtowania DC na 100 M, użyj Enterasys do nadzorowania łącza 10GE do 1GE podczas wysyłania ruchu do łącza 100M

Analiza iperfwyników ...

Należy pamiętać o dwóch kluczowych kwestiach iperf(wszystkie informacje oparte na iperfwersji 2):

• iperfmierzy przepustowość ładunku TCP lub UDP ; innymi słowy, ignoruje narzut nagłówków TCP, UDP, IP i Ethernet. Ponieważ masz usługę Ethernet, pamiętaj o odpowiednim zmodyfikowaniu iperfwyników
• iperfKlient wysyła dane do serwera podczas testów.

W związku z tym następujące dane wyjściowe pokazują, że maszyna prądu stałego (w iperf -ctrybie) łączy się z iperfserwerem w zdalnej lokalizacji (192.168.x) i przesyła dane z DC (100M UNI) do zdalnej strony (10M UNI) ...

./iperf -c 192.168.x -i2 -t 60 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.x port 38195 connected with 192.168.x port 5001
[  3]  0.0- 2.0 sec  1.44 MBytes  6.03 Mbits/sec
[  3]  2.0- 4.0 sec  2.23 MBytes  9.37 Mbits/sec
[  3]  4.0- 6.0 sec  2.28 MBytes  9.57 Mbits/sec
[  3]  6.0- 8.0 sec  1.88 MBytes  7.90 Mbits/sec
[  3]  8.0-10.0 sec  1.00 MBytes  4.19 Mbits/sec
[  3] 10.0-12.0 sec  1.30 MBytes  5.47 Mbits/sec
[  3] 12.0-14.0 sec    688 KBytes  2.82 Mbits/sec

Powyższe dane wyjściowe wyraźnie pokazują problemy w DC w kierunku zdalnym; powinniśmy oczekiwać 9 Mb / s lub więcej, gdy wszystko działa dobrze (tzn. oczekujesz co najmniej 90% przepustowości - 10 Mb / s w zdalnej lokalizacji). Teraz spójrzmy na ruch w przeciwnym kierunku (kiedy iperfwypycha dane ze zdalnej strony do DC) ...

[  5] local 10.x port 5001 connected with 192.168.x port 10965
[  5]  0.0- 2.0 sec  1.85 MBytes  7.75 Mbits/sec
[  5]  2.0- 4.0 sec  1.90 MBytes  7.98 Mbits/sec
[  5]  4.0- 6.0 sec  1.89 MBytes  7.93 Mbits/sec
[  5]  6.0- 8.0 sec  1.92 MBytes  8.07 Mbits/sec
[  5]  8.0-10.0 sec  1.91 MBytes  8.02 Mbits/sec
[  5] 10.0-12.0 sec  1.83 MBytes  7.69 Mbits/sec
[  5] 12.0-14.0 sec  1.86 MBytes  7.78 Mbits/sec

Jesteś w stanie wysłać około 80% pojemności swojego zdalnego CIR, ale to wciąż mniej niż się spodziewam.

Ilustracja niedopasowania prędkości prądu stałego (10 Gb / s -> 100 Mb / s)

marki powiedział : Nie zapomnij, problem pojawia się tylko wtedy, gdy przepływ wynosi 100 Mb -> 10 Mb, a nie odwrotnie.

Problem pojawia się w obu kierunkach, ale iperfobjawy wydają się być gorsze w DC -> w kierunku zdalnym. Zobacz moją analizęiperf wyników powyżej.

Aby to skonkretyzować, spójrzmy na twój pcap FTP podczas wypychania pliku z serwera DC DC (130.1.6.4) na zdalną stronę (192.168.191.2). Przeniesienie ze strony sieci Ethernet 100 M metra jest ograniczone w kilku punktach podczas przesyłania. Możesz to zobaczyć, jeśli spojrzysz na dc-to-remote_remote-side.pcapngpcap i przefiltrujeszexpert.message contains "segment not captured"

^{Uwaga 1} Wybieram wartości CBS 25 KB na 1 Mb / s MetroEthernet CIR; jest to częsty stosunek stosowany przez dostawców ... YMMV
^{Uwaga 2} Moja osobista reguła: „duża” to zmiana prędkości, która jest znacznie większa niż zmiana prędkości 10: 1
^{Uwaga 3}Nie mogę podać twardych liczb za to, co jest i nie jest zbyt dużą utratą pakietów dla TCP. Jeśli utrata jest na tyle poważna, że ​​cierpią twoje aplikacje, oznacza to, że jest to zbyt wiele. Moja osobista zasada: gdy mam do czynienia z przewodową siecią korporacyjną całkowicie pod moją kontrolą, każda (niezamierzona) utrata pakietów jest zbyt duża. To powiedziawszy, istnieje kilka modeli przełączników, które ograniczają buforowanie; te przełączniki mogą czasami upuszczać pakiety ... to jest decyzja, czy trzeba żyć z problemem, czy kupić lepsze przełączniki. FYI: Nie zawsze jest to oczywiste, ale TCP okresowo zwiększa szybkość transmisji gniazda, aby zapewnić jak największą przepustowość; wiele implementacji TCP wie, że idą zbyt szybko, gdy widzą spadające pakiety.

Podczas gdy omawianie tego problemu było bardzo interesujące, dostawca usług internetowych rozpoczął w międzyczasie wymianę modemów DSL w różnych witrynach przez inną markę. Mówią, że mają problem z fragmentacją pakietów. Hej, 9,5 Mbps w obu kierunkach bez żadnych problemów i specjalnych ustawień.