flowgrind - Online w chmurze

PROGRAM:

IMIĘ

flowgrind - zaawansowany generator ruchu TCP dla systemów Linux, FreeBSD i Mac OS X

STRESZCZENIE

szlifowanie strumieniowe [OPCJA] ...

OPIS

flowgrind to zaawansowany generator ruchu TCP do testowania i porównywania systemu Linux,
Stosy TCP/IP FreeBSD i Mac OS X. W przeciwieństwie do innych narzędzi pomiaru wydajności, jest to
charakteryzuje się architekturą rozproszoną, w której mierzona jest przepustowość i inne metryki
pomiędzy dowolnymi procesami serwera flowgrind, demon flowgrind flowgrind(1).

Flowgrind mierzy oprócz dobrej wydajności (przepustowości) czas między przybyciem warstwy aplikacji
(IAT) i czas podróży w obie strony (RTT), liczba bloków i transakcje sieciowe. W odróżnieniu od większości krzyżówek
narzędzi do testowania platformy, flowgrind zbiera i raportuje metryki TCP zwrócone przez
Opcja gniazda TCP_INFO, które zwykle znajdują się wewnątrz stosu TCP/IP. Na Linuksie i
FreeBSD obejmuje to między innymi oszacowanie przez jądro całkowitego czasu RTT (ang. end-to-end) oraz rozmiaru
okna przeciążenia TCP (CWND) i progu wolnego startu (SSTHRESH).

Flowgrind ma architekturę rozproszoną. Jest on podzielony na dwa elementy: flowgrind
demon, flowgrind(1), oraz flowgrind kontroler. Za pomocą kontrolera przepływa pomiędzy
można skonfigurować dowolne dwa systemy z demonem flowgrind (testy stron trzecich). Regularnie
odstępach czasu podczas testu sterownik zbiera i wyświetla zmierzone wyniki
demony. Może uruchamiać wiele przepływów jednocześnie z tymi samymi lub różnymi ustawieniami
indywidualnie planuj każdego. Opcjonalnie można przekierować przyłącze testowe i sterujące
różne interfejsy.

Samo generowanie ruchu jest albo transferem masowym, z ograniczoną szybkością, albo wyrafinowanym
testy żądania/odpowiedzi. Flowgrind używa libpcap do automatycznego zrzucania ruchu
analiza jakościowa.

OPCJE

Są to dwie ważne grupy opcji: opcje sterownika i opcje przepływu. Jak
nazwa sugeruje, opcje kontrolera mają zastosowanie globalne i potencjalnie wpływają na wszystkie przepływy, natomiast
Opcje specyficzne dla przepływu mają zastosowanie tylko do podzbioru przepływów wybranych za pomocą opcji -F opcja.

Argumenty obowiązkowe dla długich opcji są obowiązkowe dla opcji krótkich.

Ogólne Opcje
-h, --help[=CO]
wyświetl pomoc i wyjdź. Opcjonalnie CO może być „socket”, aby uzyskać pomoc dotyczącą gniazda
opcje lub pomoc w generowaniu ruchu

-v, --wersja
wydrukuj informacje o wersji i wyjdź

kontroler Opcje
-c, --pokaż dwukropek=TYP[,TYP] ...
wyświetl na wyjściu kolumnę raportu pośredniego interwału TYPE. Dozwolone wartości dla
TYP to: „interwał”, „przez”, „transac”, „iat”, „jądro” (domyślnie wszystkie są wyświetlane),
i „bloki”, „rtt”, „opóźnienie” (opcjonalnie)

-d, --odpluskwić
zwiększ szczegółowość debugowania. Dodaj opcję wiele razy, aby zwiększyć szczegółowość

-e, --dump-przedrostek=PRE
dołącz przedrostek PRE, aby zrzucić nazwę pliku (domyślnie: „flowgrind-”)

-i, --interwał-raportu=#.#
interwał raportowania w sekundach (domyślnie: 0.05 s)

--plik dziennika[=FILE]
zapisz dane wyjściowe do pliku dziennika PLIK (domyślnie: flowgrind-'timestamp'.log)

-m raportuj przepustowość w 2**20 bajtów/s (domyślnie: 10**6 bitów/s)

-n, --przepływy=#
liczba przepływów testowych (domyślnie: 1)

-o nadpisz istniejące pliki dziennika (domyślnie: nie)

-p nie drukuj wartości symbolicznych (takich jak INT_MAX) zamiast liczb

-q, --cichy
bądź cicho, nie loguj się do ekranu (domyślnie: wyłączone)

-s, --tcp-stos=TYP
nie określaj automatycznie jednostki źródłowych stosów TCP. Wymuś na jednostce TYPE, gdzie
TYPE to „segment” lub „bajt”

-w zapisz dane wyjściowe do pliku dziennika (tak samo jak --plik dziennika)

Przepływ Opcje
Wszystkie przepływy mają dwa punkty końcowe, źródło i miejsce docelowe. Rozróżnienie źródła
i docelowe punkty końcowe wpływają jedynie na ustanowienie połączenia. Rozpoczynając przepływ
docelowy punkt końcowy nasłuchuje na gnieździe, a źródłowy punkt końcowy łączy się z nim. Dla
rzeczywisty test nie robi to różnicy, oba punkty końcowe mają dokładnie takie same możliwości.
Dane mogą być przesyłane w obu kierunkach, a wiele ustawień można skonfigurować indywidualnie
każdy punkt końcowy.

Niektóre z tych opcji przyjmują jako argument punkt końcowy przepływu, oznaczony w opcji przez „x”.
składnia. „x” należy zastąpić „s” dla źródłowego punktu końcowego lub „d” dla
docelowy punkt końcowy lub „b” dla obu punktów końcowych. Aby określić różne wartości dla każdego
punkty końcowe, oddziel je przecinkami. Na przykład -W s=8192,d=4096 ustawia reklamowaną
okno na 8192 u źródła i 4096 u odbiorcy.

-A x użyj minimalnego rozmiaru odpowiedzi potrzebnego do obliczenia RTT
(taki sam jak -G s=p,C,40)

-B x=# ustaw żądany bufor wysyłania w bajtach

-C x zatrzymać przepływ, jeśli występują lokalne zatory

-D x=DSCP
Wartość DSCP dla bajtu nagłówka IP typu usługi (TOS).

-E wylicza bajty w ładunku zamiast wysyłać zera

-F #[,#] ...
opcje przepływu następujące po tej opcji dotyczą tylko podanych identyfikatorów przepływów. Przydatne w
połączenie z -n aby ustawić określone opcje dla określonych przepływów. Rozpoczyna się numeracja
z 0, więc -F 1 odnosi się do drugiego przepływu. Przy -1 można odnieść się do całego przepływu

-G x=(q|p|g):(C|U|E|N|L|P|W):#1:[#2]
aktywuj stochastyczne generowanie ruchu i ustaw parametry zgodnie z używanymi
dystrybucja. Aby uzyskać dodatkowe informacje, zobacz sekcję „Opcja generowania ruchu”

-H x=HOST[/CONTROL[:PORT]]
test z/do HOST-u. Argumentem opcjonalnym jest adres i port STEROWANIA
połączenie z tym samym hostem. Zakłada się, że punkt końcowy, który nie jest określony, jest
localhost

-J # użyj losowego numeru początkowego (domyślnie: read / Dev / urandom)

-I włączyć jednokierunkowe obliczanie opóźnienia (bez synchronizacji zegara)

-L wywołaj funkcję connect() na gnieździe testowym bezpośrednio przed rozpoczęciem wysyłania danych (późno
łączyć). Jeśli nie określono, połączenie testowe zostanie nawiązane w przygotowaniu
fazie przed rozpoczęciem testu

-M x zrzuć ruch za pomocą libpcap. flowgrind(1) musi zostać uruchomiony jako root

-N Shutdown() w każdym kierunku gniazda po przepływie testowym

-O x=OPT
ustaw opcję gniazda OPT na gnieździe testowym. Dodatkowe informacje można znaleźć w rozdziale
„Opcje gniazd”

-P x nie wykonuj iteracji poprzez funkcję Select(), aby kontynuować wysyłanie, jeśli rozmiar bloku nie uległ zmianie
wystarczy do zapełnienia kolejki wysyłania (naciskowe)

-Q tylko podsumowanie, nie są obliczane żadne raporty interwałów pośrednich (cicho)

-R x=#.#(z|k|M|G)(b|B)
wysyłaj z określoną szybkością na sekundę, gdzie: z = 2**0, k = 2**10, M = 2**20, G =
2**30, oraz b = bity/s (domyślnie), B = bajty/s

-S x=# ustaw rozmiar bloku (wiadomości) w bajtach (taki sam jak -G s=q,C,#)

-T x=#.#
ustaw czas trwania przepływu w sekundach (domyślnie: s=10,d=0)

-U # ustaw rozmiar bufora aplikacji w bajtach (domyślnie: 8192) obcina wartości, jeśli jest używane z
stochastyczne generowanie ruchu

-W x=# ustaw żądany bufor odbiornika (ogłoszone okno) w bajtach

-Y x=#.#
ustaw początkowe opóźnienie, w sekundach, zanim host zacznie wysyłać

RUCH DROGOWY GENERACJA OPCJA

Przez opcję -G flowgrind wspiera stochastyczne generowanie ruchu, co pozwala na jego prowadzenie
oprócz zwykłych transferów masowych także zaawansowane transfery danych z ograniczoną szybkością i transfery typu żądanie-odpowiedź.

Opcja stochastycznego generowania ruchu -G przyjmuje punkt końcowy przepływu jako argument, oznaczony
przez „x” w składni opcji. „x” należy zastąpić dowolnym „s” oznaczającym źródło
punkt końcowy, „d” dla docelowego punktu końcowego lub „b” dla obu punktów końcowych. Jednak proszę zwrócić uwagę
że dwukierunkowe generowanie ruchu może prowadzić do nieoczekiwanych rezultatów. Aby określić inny
wartości dla każdego punktu końcowego, oddziel je przecinkami.

-G x=(q|p|g):(C|U|E|N|L|P|W):#1:[#2]

Parametr przepływu:

q rozmiar żądania (w bajtach)

p rozmiar odpowiedzi (w bajtach)

g żądanie przerwy między pakietami (w sekundach)

Dystrybucje:

C stała (#1: wartość, #2: nieużywany)

U mundur (#1: min., #2: maks.)

E wykładniczy (#1: lamba - dożywotnia, #2: nieużywany)

N normalny (#1: mu - wartość średnia, #2: sigma_square - wariancja)

L lognormalny (#1: zeta - oznacza, #2: sigma — wersja standardowa)

P Pareto (#1: k - kształt, #2: x_min - skala)

W Weibull (#1: lambda - skala, #2: k - kształt)

Zaawansowane dystrybucje, takie jak Weibull, są dostępne tylko wtedy, gdy skompilowany jest flowgrind
z obsługą libgsl.

-U # określ wymagany limit obliczonych wartości rozmiarów żądań i odpowiedzi
ponieważ zaawansowane wartości rozproszone są nieograniczone, ale musimy znać
rozmiar bufora (nie jest potrzebny w przypadku stałych wartości lub równomiernego rozkładu). Wartości
poza granicami są przeliczane ponownie, aż do uzyskania prawidłowego wyniku, ale maksymalnie do 10
razy (wtedy używana jest wartość związana)

GNIAZDO ELEKTRYCZNE OPCJA

Flowgrind umożliwia ustawienie następujących standardowych i niestandardowych opcji gniazd za pomocą opcji
-O.

Wszystkie opcje gniazd przyjmują jako argument punkt końcowy przepływu, oznaczony w opcji przez „x”.
składnia. „x” należy zastąpić „s” dla źródłowego punktu końcowego lub „d” dla
docelowy punkt końcowy lub „b” dla obu punktów końcowych. Aby określić różne wartości dla każdego
punkty końcowe, oddziel je przecinkami. Co więcej, możliwe jest wielokrotne przechodzenie tego samego
endpoint, aby określić wiele opcji gniazd.

Standard gniazdo Opcje
-O x=TCP_CONGESTION=ALG
ustaw algorytm kontroli przeciążenia ALG na gnieździe testowym

-O x=TCP_CORK
ustaw TCP_CORK na gnieździe testowym

-O x=OPÓŹNIENIE TCP_NOD
wyłącz nagły algorytm na gnieździe testowym

-O x=SO_DEBUG
ustaw SO_DEBUG na gnieździe testowym

-O x=IP_MTU_ODKRYJ
ustaw IP_MTU_DISCOVER na gnieździe testowym, jeśli nie jest jeszcze włączone domyślnie w systemie

-O x=REKORD_TRASY
ustaw ROUTE_RECORD na gnieździe testowym

Niestandardowe gniazdo Opcje
-O x=TCP_MTCP
ustaw TCP_MTCP (15) na gnieździe testowym

-O x=TCP_ELCN
ustaw TCP_ELCN (20) na gnieździe testowym

-O x=TCP_LCD
ustaw TCP_LCD (21) na gnieździe testowym

PRZYKŁADY

flowgrind
testowanie wydajności lokalnego hosta IPv4 TCP z ustawieniami domyślnymi, takimi samymi jak flowgrind -H
b=127.0.0.1 -T s=10,d=0. Demon flowgrind musi być uruchomiony na hoście lokalnym

flowgrind -H b=::1/127.0.0.1
tak samo jak powyżej, ale testuję wydajność lokalnego hosta IPv6 TCP z ustawieniami domyślnymi

flowgrind -H s=host1,d=host2
masowy transfer TCP między hostem 1 i hostem 2. Host1 działa jako źródło, host2 jako
docelowy punkt końcowy. Na obu punktach końcowych należy uruchomić demona flowgrind. The
używane są domyślne opcje przepływu, z czasem trwania przepływu wynoszącym 10 sekund i strumieniem danych
z hosta 1 do hosta 2

flowgrind -H s=host1,d=host2 -T s=0, d=10
tak samo jak powyżej, ale zamiast tego z przepływem wysyłającym dane przez 10 sekund z hosta2 do
host1

flowgrind -n 2 -F 0 -H s=192.168.0.1, d=192.168.0.69 -F 1 -H s=10.0.0.1, d=10.0.0.2
skonfiguruj dwa równoległe przepływy, pierwszy przepływ między 192.168.0.1 a 192.168.0.69, drugi
przepływ pomiędzy 10.0.0.1 a 10.0.0.2

flowgrind -p -H s=10.0.0.100/192.168.1.100,d=10.0.0.101/192.168.1.101 -A s
skonfiguruj jeden przepływ między 10.0.0.100 a 10.0.0.101 i użyj adresów IP 192.168.1.x
do kontroli ruchu. Aktywuj minimalną odpowiedź do obliczenia RTT

flowgrind -i 0.001 -T s = 1 | egrep ^S | gnuplot -trwać -e 'działka "-" za pomocą 3:5 w linie
tytuł "Wydajność" '
skonfiguruj jedno urządzenie z pętlą zwrotną i za jego pomocą wykreśl dane nadawcy
z gnuplot

flowgrind -G s=q,C,400 -G s=p,N,2000,50 -G s=g, U, 0.005,0.01, XNUMX -U 32000
-G s=q,C,400: użyj stałego rozmiaru żądania wynoszącego 400 bajtów
-G s=p,N,2000,50: użyj normalnego rozmiaru odpowiedzi rozproszonej ze średnią 2000 bajtów i
różnica 50
-G s=g,U,0.005,0.01: użyj jednolitej rozproszonej przerwy między pakietami z min. 0.005 s i
i maksymalnie 10 ms
-U 32000: obcina rozmiary bloków do 32 kilobajtów (potrzebne do dystrybucji normalnej)

RUCH DROGOWY SCENARIUSZE

Poniższe przykłady pokazują, jakie mogą być możliwości generowania ruchu przez flowgrind
używany. Zostały one uwzględnione w różnych testach flowgrind i zostały sprawdzone
znaczący. Ponieważ jednak ruch internetowy jest zróżnicowany, nie ma gwarancji, że tak jest
odpowiedni w każdej sytuacji.

PROŚBA Odpowiedź Styl (HTTP)
Ten scenariusz opiera się na pracy w
http://www.3gpp2.org/Public_html/specs/C.R1002-0_v1.0_041221.pdf.

flowgrind -M s -G s=q,C,350 -G s=p,L,9055,115.17 -U 100000
-M s: zrzuć ruch po stronie nadawcy
-G s=q,C,350: użyj stałych żądań o rozmiarze 350 bajtów
-G s=p,L,9055,115: użyj rozkładu logarytmiczno-normalnego ze średnią 9055 i wariancją 115 dla
rozmiar odpowiedzi
-U 100000: Obetnij odpowiedź o 100 kilobajtach

W tym scenariuszu zalecamy skupienie się na RTT (niższe wartości są lepsze) i sieci
Transakcje/y jako metryka (wyższe wartości są lepsze).

Interaktywny Sesja (Telnetu)
Ten scenariusz emuluje sesję telnet.

flowgrind -G s=q,U,40,10000 -G s=q,U,40,10000 -O b=OPÓŹNIENIE_TCP
-G s=q,U,40,10000 -G s=q,U,40,10000: użyj równomiernie rozproszonego żądania i odpowiedzi
rozmiar od 40B do 10kB
-O b=TCP_NODELAY: ustaw opcje gniazda TCP_NODELAY używane przez aplikacje telnetowe

W tym scenariuszu RTT (niższy tym lepszy) i transakcje sieciowe są przydatnymi metrykami
(wyżej jest lepiej).

Kurs Ograniczony (Transmisja strumieniowa Średni)
W tym scenariuszu emulowany jest transfer strumienia wideo z szybkością transmisji bitów 800 kbit/s.

flowgrind -G s=q,C,800 -G s=g,N,0.008,0.001
Użyj normalnie rozłożonej przerwy między pakietami ze średnią 0.008 i małą wariancją
(0.001). W połączeniu z rozmiarem żądania 800 bajtów, średnia przepływność wynosi około 800
kbit/s został osiągnięty. Wariancja jest dodawana w celu emulacji zmiennej szybkości transmisji bitów
stosowane we współczesnych kodekach wideo.

W tym scenariuszu ważne są IAT (im niższa, tym lepsza) i minimalna przepustowość (wyższa, tym lepsza).
ciekawe wskaźniki.

WYDAJNOŚĆ KOLUMNY

Przepływ/punkt końcowy identyfikatory
# punkt końcowy przepływu, albo „S” dla źródła, albo „D” dla miejsca docelowego

ID numeryczny identyfikator przepływu

rozpocząć i zakończenia
granice przedziału pomiarowego w sekundach. Wyświetlany czas to czas, który upłynął
czas od otrzymania komunikatu RPC, aby rozpocząć test z punktu demona
widok

Zastosowanie warstwa metryka
przez
przesyłanie dobrego sygnału punktu końcowego przepływu w tym przedziale pomiarowym,
mierzone w Mbit/s (domyślnie) lub MB/s (-m)

transakcja
liczba pomyślnie odebranych bloków odpowiedzi na sekundę (nazywamy to siecią
transakcje/y)

wymaganie/odp
liczba bloków żądań i odpowiedzi wysłanych w tym przedziale pomiarowym (kolumna
domyślnie wyłączone)

IAT blokować czas między przylotami (IAT). Razem z minimum i maksimum
wyświetlana jest średnia arytmetyczna dla tego konkretnego przedziału pomiarowego. Jeśli nie ma bloku
odebrane w okresie raportowania, wyświetlane jest „inf”.

DLY i RTT
Blok 1- i 2-kierunkowy opóźnia odpowiednio opóźnienie bloku i przepływ bloku w obie strony
czas (RTT). Dla obu opóźnień minimalne i maksymalne napotkane wartości w tym
przedział pomiarowy wyświetlany jest wraz ze średnią arytmetyczną. Jeśli nie ma blokady,
odpowiednio potwierdzenie bloku nadejdzie w tym przedziale czasu raportowania, „inf” wynosi
wystawiany. Zarówno 1-kierunkowe, jak i 2-kierunkowe opóźnienie blokowe są domyślnie wyłączone (patrz
opcja -I i -A).

Jądro metryka (TCP_INFO)
Wszystkie poniższe metryki specyficzne dla protokołu TCP są uzyskiwane z jądra poprzez protokół TCP_INFO
opcja gniazda w zakończenia każdego interwału raportu. Częstotliwość próbkowania można zmienić za pomocą
opcja -i.

cwnd (tcpi_cwnd)
rozmiar okna przeciążenia TCP (CWND) w liczbie segmentów (Linux) lub bajtów
(FreeBSD)

coś takiego (tcpi_snd_sshtresh)
rozmiar progu powolnego startu w liczbie segmentów (Linux) lub bajtów (FreeBSD)

uak (tcpi_unacked)
liczba aktualnie niepotwierdzonych segmentów, tj. liczba segmentów w locie
(Rozmiar lotu) (tylko Linux)

worek (tcpi_sacked)
liczba selektywnie potwierdzanych segmentów (tylko Linux)

stracił (tcpi_lost)
zakładana liczba segmentów utraconych (tylko Linux)

powrót (tcpi_retrans)
liczba niepotwierdzonych, retransmitowanych segmentów (tylko Linux)

tret (tcpi_retransmits)
liczba retransmisji wywołanych przekroczeniem limitu czasu retransmisji (RTO) (tylko Linux)

fałd (tcpi_fackets)
liczba segmentów pomiędzy SND.UNA a najwyższym, selektywnie potwierdzonym
numer kolejny (SND.FACK) (tylko Linux)

ponownie (tcpi_reordering)
metryka zmiany kolejności segmentów. Jądro Linuksa potrafi wykryć i poradzić sobie ze zmianą kolejności
bez znaczącej utraty wydajności, jeśli odległość przemieszczenia segmentu tak
nie przekraczać metryki zmiany kolejności (tylko Linux)

rtt (tcpi_rtt) i rttvar (tcpi_rttvar)
Czas podróży w obie strony protokołu TCP i jego wariancja podana w ms

rto (tcpi_rto)
limit czasu retransmisji podany w ms

bkof (tcpi_backoff)
liczba wycofań RTO (tylko Linux)

ca były (tcpi_ca_state)
stan wewnętrzny maszyny stanu kontroli przeciążenia TCP, zgodnie z implementacją w
Jądro Linuksa. Może być jednym z koncepcja, nieporządek, cwr, regeneracja or od (Tylko Linux)

Otwarte jest stanem normalnym. Wskazuje, że nie ma duplikatu potwierdzenia (ACK).
odebrany i żaden segment nie jest uważany za utracony

Nieład
jest wprowadzany po odebraniu pierwszego z rzędu duplikatu ACK lub
selektywne potwierdzanie (SACK)

CWR jest wprowadzany w przypadku powiadomienia z jawnego powiadomienia o zatorze (ECN)
jest otrzymywany

regeneracja
jest wprowadzany w przypadku trzech zduplikowanych potwierdzeń lub równoważnej liczby potwierdzeń
otrzymane. W tym stanie obowiązują procedury kontroli zatorów i odzyskiwania strat, np
Wykonywane są szybka retransmisja i szybkie odzyskiwanie (RFC 5861).

Utrata jest wprowadzany w przypadku wygaśnięcia RTO. Ponownie kontrola zatorów i odzyskiwanie strat
procedury są wykonywane

sms i pmtu
maksymalny rozmiar segmentu nadawcy i maksymalna jednostka transmisji ścieżki w bajtach

Wewnętrzne flowgrind były (tylko włączony in debug buduje)
status stan przepływu wewnątrz flowgrind w celach diagnostycznych. Jest to krotka dwóch
wartości, pierwsza do wysyłania, druga do odbierania. Idealnie stany
zarówno źródłowy, jak i docelowy punkt końcowy przepływu powinny być symetryczne, ale ponieważ
nie są zsynchronizowane i nie mogą się zmieniać w tym samym czasie. Możliwe wartości
należą:

c Kierunek został zakończony, wysyłanie/odbieranie

d Oczekiwanie na początkowe opóźnienie

f Stan usterki

l Stan aktywny, nic jeszcze nie zostało przesłane ani odebrane

n Normalna aktywność, niektóre dane zostały przesłane lub odebrane

o Przepływ w tym kierunku ma zerowy czas trwania i żadne dane nie będą wymieniane

AUTORSKI

Flowgrind został pierwotnie założony przez Daniela Schaffratha. Pomiar rozproszony
architektura i zaawansowane generowanie ruchu zostały później dodane przez Tima Kosse i
Christian Samzel. Obecnie flowgrind jest rozwijany i utrzymywany przez Arnda Hannemanna i
Aleksander Zimmermann.

Korzystaj z flowgrind online, korzystając z usług onworks.net