Algorytm testu szybkości TCP pytanie

Question

Pracuję w firmie ISP. Opracowujemy tester prędkości dla naszych klientów, ale mamy problemy z testowaniem szybkości TCP.

Jeden klient miał łączny czas w ciągu 102 sekund, przesyłając 100 MB z pakietem 8192. 100.000.000/8192 = 12.202 pakietów. Jeśli klient wysyła ACK co drugi pakiet, który wydaje się dużo czasu, po prostu przesyła ACK. Powiedzmy, że klient wysyła 6000 ACK, a RTT to 15 ms - to 6000 * 7.5 = 45.000ms = 45 sekund tylko dla ACK-ów?

Jeśli używam tego obliczenia dla Mbit/s:

(((sizeof_download_in_bytes/durationinseconds) /1000) /1000) * 8 = Mbp/s 

będę uzyskać wynik w MBP/s, ale wtedy wyższa TTL jest między nadawcą a klientem im niższa Mbp/s prędkość się zmieni.

Aby zasymulować, że użytkownik znajduje się bliżej serwera, czy "legalne" byłoby usunięcie czasu odpowiedzi ACK w ostatecznym wyniku na Mb/s? To byłoby jak symulowanie użytkownika końcowego blisko serwera?

Więc chciałbym wyświetlić ten obliczenia dla użytkownika końcowego:

(((sizeof_download_in_bytes/(durationinseconds - 45sec)) /1000)/1000) * 8 = Mbp/s 

Czy to ważne?

Answer 1

Problem polega na tym, że protokół RTT jest zbyt duży, aby nie była używana cała przepustowość. Możesz zwiększyć rozmiar okna TCP, który można wykonać dla poszczególnych gniazd dla celów testowych, a także dla system-wide.

Jako klient uważam, że jest to świetna usługa, jeśli program do testowania prędkości poinformuje mnie o nieoptymalnych ustawieniach systemu i zaoferuje mi opcję ich poprawienia.

Jeśli ustawienia okna TCP są poprawne, RTT nie powinno mieć znaczenia w teście prędkości TCP, chyba że tracisz znaczną liczbę pakietów (ale po tym wszystkim jest to, co chcesz wykryć w pierwszej kolejności).

Answer 2

TCP wykorzystuje sterowanie przepływem okna i zwykle nie czeka na potwierdzenia ACK przed wysłaniem następnej ramki. ACK idą jednocześnie z ramkami danych i nie wymagają dodatkowego czasu zegara ściennego. Każda ostatnia implementacja TCP może obsłużyć takie RTT i bitrate bez utraty prędkości.

więc prawidłowe obliczenie jest numer 1.

Ponadto, są na pewno swoją sieć naprawdę mają 8192 MTU z komputera klienta do serwera testowego? Jest całkiem prawdopodobne, że istnieje segment Ethernet z 1500 MTU i twoje 8192 bajty wysyłania buforów są dzielone przez stos TCP na standardowe segmenty TCP o szerokości 1500 bajtów.

I na koniec jest 1024 bajtów w kilobajtach i 1024 kilobajtach w megabajtach.