Jak sformułować opóźnienie komunikacji w TCP / IP?

Mam trudności w uzyskaniu modelu / równania matematycznego do oszacowania opóźnienia w obie strony między dwoma węzłami komunikującymi się za pomocą TCP / IP. Węzły wymieniają dane w oparciu o protokół HTTP. W tym modelu najważniejszymi czynnikami do zbadania są odległość fizyczna między dwoma węzłami w sieci, liczba pośrednich przeskoków, szerokość pasma, opóźnienie przetwarzania w każdym przeskoku. Przeszukałem sieć, ale nic nie znalazłem w tym sensie, raczej znalazłem coś na temat sieci komutacyjnych i protokołu UDP. Czy mogę je dostosować, aby pasowały do ​​TCP?

Jest to bardzo skomplikowany proces, więc sformułowanie równania, które mogłoby być przydatne do dokładnego przewidywania RTT, jest niezwykle trudne. W najlepszym razie powiedziałbym, że możesz stworzyć model wykorzystujący kilka średnich dla każdego etapu, który możesz poprawić, jeśli zdarzy ci się „wiedzieć lepiej” w konkretnej sytuacji, tak blisko, jak to tylko możliwe. To jest coś, co obecnie studiuję, więc mogę powiedzieć ci to, co do tej pory wiem (od podstaw, zaczynając od warstwy fizycznej):

• Zobacz moje pytania na temat Electronics SE; Opóźnienie kodowania Ethernetu i związek z częstotliwością znamionową kabla i prędkością prądu (propagacja sygnału?) Przez miedź dla opóźnienia komunikacji . Ponieważ używasz standardowych prędkości (100 Mb / s, 1 Gb / s, 10 Gb / s itp.), Nie traktuj inaczej światłowodu lub miedzi. „Opóźnienie” w dół tych dwóch jest prawie tak samo, ale miedź nie może oczywiście przenosić sygnału. Mam to pytanie na stronie Physics SE, na którą znam odpowiedź. Muszę tylko znaleźć czas, aby to poprawić, więc miej oko na to, jeśli jesteś zainteresowany (będę zamieszczał więcej pytań związanych z korzystaniem ze światłowodów, na które teraz znam odpowiedź, kiedy mam szansę) ).

• Urządzenia na końcu łącza dodadzą znacznie więcej opóźnień. Nie ma standardowego sposobu powiedzenia „o 2 przełączniki na ścieżce to opóźnienie Xms, 4 przełączniki to 2 * Xms, 2 routery to Yms ... itd.”. Zakładając, że używasz na przykład 1 Gpbs i urządzeń na ścieżce do przodu z prędkością linii, wiemy, że jest to 1000000000bps, więc interfejs fizyczny działa ze stałą szybkością kodowania (od 1 nanosekundy na bit do dowolnej wartości maksymalnej stosowany schemat kodowania symboli, taki jak 10b )

• Istnieją trzy główne rodzaje opóźnień (w warstwie fizycznej), o których musisz wiedzieć i brać pod uwagę; Opóźnienie szeregowania, opóźnienie kodowania, opóźnienie propagacji (i opóźnienie przetwarzania, opóźnienie kolejkowania, opóźnienie kodowania i dekodowania, ale są one powyżej warstwy fizycznej, ale należy o tym wspomnieć!). Są one dość dobrze udokumentowane w Internecie, VoIP: An Dogłębna analiza , Slajd 13 tutaj , ładuje Google Scholar i wiele innych.

• Gdy przesuwamy się w górę stosu protokołów, działałbym przy założeniu, że docelowy MAC znajduje się w każdej tablicy kamer przełączników, a na warstwie IP docelowy MAC w tablicach ARP. Dodatkowe opóźnienie wywołane przez te procesy wykrywania występuje tylko dla pierwszego pakietu w przepływie, więc można je ominąć, zwiększając limity czasu i wysyłając bezpłatne ARP itp.

• Gdy przejdziesz do warstwy aplikacji, stanie się to naprawdę trudne, ponieważ zależy to od (na przykład) przetwarzania żądania przez serwer, co będzie podlegało opóźnieniu przerwania. Liczba przerwań wymaganych do przetworzenia żądania i przełączników kontekstu z powodu obciążenia jest nieprzewidywalna.

Bardzo chciałbym ci pomóc w twoim pytaniu, niestety to wszystko, na co teraz mam czas. Zaktualizuję tę odpowiedź może później wieczorem lub jutro chciałem opublikować to, co do tej pory.

W międzyczasie większość ludzi ma tendencję do pracy z wartością opóźnienia dla fizycznej warstwy miedzi / włókna wynoszącej około 0,6 * c (C = prędkość światła). Musisz także pomyśleć o wymianie ACK przez TCP w każdym pakiecie X, co różni się, jeśli używasz na przykład SACK i jeśli używasz dużych ramek i / lub większego rozmiaru MSS (teraz należy uwzględnić również MTU!) , jeśli wysyłasz więcej pomiędzy ACK (jeśli interesuje Cię ilość przesłanych danych). Należy również czynnik niesławnego Bandwidth Delay Produktu i nie zrobić głupiego błędnej interpretacji, że zrobiłem z tej strony. Zacząłem robić różne proste (i bardzo brzydki) kalkulatory danych tutaj. Znów trwają prace. Niedługo spróbuję je zaktualizować. Planuję dodać kalkulator podobny do tego, co próbujesz zrobić. Zrobiłem też kilka kalkulatorów światła i światłowodów, jeśli jesteś zainteresowany, ale znowu, nie ma czasu !, Jeszcze nie zacząłem ich przesyłać. Spróbuję jak najszybciej zaktualizować tę odpowiedź w najbliższych dniach.

PS Zapomniałem wspomnieć o QoS! Jeśli QoS jest w grze w dowolnym miejscu na ścieżce, naprawdę trudno będzie obliczyć RTT!

(Chcę podkreślić, że inni opublikowali doskonałe odpowiedzi na temat tego, jak działają opóźnienia i co je powoduje. Ale OP zapytał o modelowanie; Podstawowy model jest prosty i wystarczy podać przykładowe liczby. Jeśli chcesz wiedzieć, dlaczego opóźnienia są takie, jakie są, a następnie zobacz odpowiedzi innych: ^)

Opóźnienie sieci to po prostu czas tranzytu od jednego punktu końcowego do drugiego punktu końcowego, obejmujący N przeskoków między nimi .

Masz więc N segmentów (chmiel) z N-1 węzłami pośrednimi. Każdy węzeł ma opóźnienie (łączny wpływ kilku rzeczy na ten węzeł, takie jak opóźnienie kolejki, opóźnienia przetwarzania itp.), A każdy segment ma opóźnienie tranzytu. Ogólnie to 2N - 1 zmienne niezależne. Więc to seg1 + węzeł1 + seg2 ... + węzeł (N-1) + segN Jeden skok, to po prostu = seg1, dwie nadzieje to seg1 + węzeł1 + seg2 itd.

Następnie musisz zdefiniować, jakie są wszystkie te elementy. Możesz więc zbudować modelową sieć z siecią CATV, łączem satelitarnym, łączem światłowodowym, ethernetem itp. Dla każdej z tych technologii musisz wyszukać przykładowe informacje.

Opóźnienia tranzytowe byłyby w przybliżeniu wielkościami danych podzielonymi przez prędkość transmisji segmentu. Jeśli potrzebujesz dokładniejszego modelu, dodałeś opóźnienie czasu lotu - w przybliżeniu długość odcinka podzieloną przez prędkość przepływu danych (przybliżona prędkość światła). Ma to znaczenie, jeśli masz połączenie satelitarne; W górę iw dół do geosynchronicznego satelity jest znaczący.

Opóźnienia w każdym węźle należy oszacować na podstawie wyposażenia umieszczonego w modelu.

Jeśli chcesz mieć opóźnienie aplikacji (na przykład opóźnienie do rozpoczęcia przepływu danych transferu FTP), możesz budować, licząc, ile razy opóźnienie sieciowe występuje. Na przykład trójdrożny uścisk dłoni TCP potrójnie opóźnia działanie sieci i tym samym buduje to, co widzi aplikacja.

Możesz oszacować opóźnienie w obie strony, przechwytując pakiet po obu stronach, a następnie mierzyć opóźnienie między żądaniami wychodzącymi z monitorowanej maszyny a odpowiedziami powracającymi. Na przykład, jeśli zaznaczysz czas, w którym SYN wyszedł na zdalną maszynę, a następnie zaznaczysz czas, w którym pojawiła się odpowiedź SYN + ACK, różnica dałaby całkiem niezły bilans opóźnień TCP w obie strony.

Należy pamiętać, że będzie to większe niż rzeczywiste opóźnienie sieci, a to, o ile większe, zależy od obciążenia dowolnego komputera.

Opóźnienie między dwoma hostami będzie zależeć od kilku czynników:

• Opóźnienie propagacji
• Opóźnienie serializacji
• Opóźnienie kolejkowania / buforowania

Opóźnienie propagacji to czas, jaki fizycznie zajmuje pakietom podróżowanie między dwoma lokalizacjami. Prędkość światła we włóknie wynosi około 200000 km / s. Mieszkam w Szwecji, gdzie jest około 1570 km, czyli 7,85 ms, ale w rzeczywistości jest to więcej, ponieważ jest to odległość z lotu ptaka.

Opóźnienie szeregowania to czas, jaki zajmuje szeregowanie pakietu za pośrednictwem nośnika fizycznego, czyli interfejsów w urządzeniu sieciowym. Jeśli masz połączenie 2 Mbit i wysyłasz pakiet 1500 bajtów, który byłby 6 ms na serializację pakietu (12000/2000000).

Opóźnienie kolejkowania / buforowania określa, ile czasu pakiet musi pozostać w kolejce / buforze, zanim zostanie wysłany do interfejsu. W zależności od szybkości interfejsu i od tego, jak duże bufory są używane, może to być później brak lub znaczące opóźnienie.

Wtedy hosty będą opóźnione w generowaniu pakietów i obsłudze aplikacji. Istnieją aplikacje do pomiaru opóźnienia HTTP. Ludzie nie akceptują dużych opóźnień na stronach internetowych, zanim się z nich zrezygnują, więc jest to ważny czynnik.