Ograniczający prędkość ruch przychodzący

Nigdy do końca nie rozumiałem, czy możliwe jest ograniczenie prędkości ruchu przychodzącego . Zdaję sobie sprawę, że nie ma bezpośredniej metody, za pomocą której można kontrolować szybkość wysyłania pakietów przez serwer zdalny (chyba że kontrolujesz oba punkty końcowe), ale biorąc pod uwagę to ograniczenie, w jaki sposób menedżerowie pobierania pozwalają mi skutecznie ustawiać ograniczenia prędkości pobierania ?

Czy istnieje jakiś związek między powolnym startem TCP a ruchem przychodzącym ograniczającym szybkość? Czy można zastosować metody opisane przez powolny start, aby sztucznie ograniczyć szybkość wysyłania pakietów przez nadawcę?

Jako dodatkową uwagę należy zauważyć, że serwer, na którym chciałbym zaimplementować kształtowanie ruchu, ustanawia samo połączenie PPPoE i działa jako router dla reszty sieci.

Aktualizacja: dotychczasowe odpowiedzi zawierały rzetelny przegląd pytań, które zadałem, ale nadal nie wiem, w jaki sposób menedżerowie pobierania są w stanie ograniczyć ruch przychodzący, a dokładniej, czy możliwe jest wdrożenie podobnej strategii na Brama systemu Linux.

Menedżerowie pobierania najprawdopodobniej działają tak, jak wyjaśniono w broszurze .

Proces wykorzystujący gniazda BSD może przeprowadzać własne ograniczenie prędkości. Aby ograniczyć przesyłanie danych, aplikacja może to zrobić, ograniczając po prostu szybkość danych zapisywanych w gnieździe. Podobnie, w celu ograniczenia pobierania danych, aplikacja może ograniczyć szybkość odczytu danych z gniazda. Jednak powód, dla którego to działa, nie jest od razu oczywisty. Gdy aplikacja nie chce odczytać niektórych danych z gniazda, jego gniazdo zapełnia się buforami odbiorczymi. To z kolei spowoduje, że odbierający TCP zareklamuje mniejsze okno odbiornika (rwnd), powodując presję wsteczną na bazowe połączenie TCP, ograniczając w ten sposób przepływ danych. Ostatecznie ten efekt „spływania w dół” osiąga ograniczenie prędkości od końca do końca. W zależności od buforowania na wszystkich warstwach stosu sieciowego propagacja tego efektu może zająć trochę czasu.

Jeśli od czasu do czasu potrzebujesz ograniczyć szybkość pojedynczego programu w systemie UNIX, proste rozwiązanie jest trudne . Rzeczywiste kształtowanie ruchu, tak jak w przypadku bramy, można wykonać tc. Jest to udokumentowane w Rozdziale 9. Dyscypliny kolejkowania w zarządzaniu przepustowością zaawansowanego systemu routingu i kontroli ruchu w Linuksie HOWTO.

W przypadku modemu 56k w porównaniu z linią DSl 4 Mb / s (zwykle) nie ma kształtowania, które różnicuje prędkość, to tylko różnica w szybkości łącza.

Powodem, dla którego trudno jest kształtować ruch przychodzący, jest brak bufora w medium transmisyjnym. Albo akceptujesz przychodzące bity, albo są zgubione. W przypadku ruchu, który wkrótce opuści interfejs, możesz buforować i zamawiać pakiety tyle, ile chcesz (lub przynajmniej do dostępnej pamięci bufora w urządzeniu).

W przypadku protokołów, które mają warstwę na wierzchu TCP (nie wiem, czy tak jest w przypadku torrentów), byłoby to proste, aby stymulować żądania dalszych danych. W przeciwnym razie aplikacja musiałaby komunikować się z systemem operacyjnym, aby opóźnić sprawdzenie pakietów. Większość protokołów opartych na UDP będzie z konieczności mieć logikę ACK / ponownego wysyłania w protokole specyficznym dla aplikacji, więc w tym momencie granice z nimi są trywialne.

Jedną z możliwych tras byłoby ukształtowanie ruchu z Internetu po stronie LAN routera DSL, ponieważ w tym momencie kształtowałbyś się na porcie wyjściowym.

Nie potrafię odpowiedzieć na pytanie, dlaczego nie znalazłeś żadnych rozwiązań, które pozwalają kształtować przychodzące dane (i nie znam żadnych z góry mojej głowy), ale co do tego, jak nadawca wie, jak szybko odbiorca może odbierać dane:

Podstawowa konstrukcja protokołu TCP / IP polega na tym, że dla każdego pakietu wysyłanego przez źródło do miejsca docelowego musi on czekać na odpowiedź odbiorcy (z ACKpakietem), mówiąc, że otrzymał pakiet.

Więc jeśli masz nadawcę 4 Mb / s i odbiornik 56 Kb / s, nadawca musi usiąść i czekać między wysyłaniem pakietów, aby odbiornik odpowiedział na każdy pakiet (istnieją pewne szczegóły techniczne, aby zmniejszyć ten narzut, ale przesłanka nadal jest abstrakcyjna poziom).

Co się stanie, jeśli nadawca już przesyła 56 Kb / s danych, a następnie próbuje wysłać trochę więcej?

Pakiet się gubi. (Cóż, potencjalnie w kolejce w buforze przełącznika, ale gdy się zapełni, pakiet się zgubi). Ponieważ pakiet został zgubiony, odbiorca nigdy go nie odbiera, a zatem nigdy nie wysyła ACKpakietu. Ponieważ nadawca nigdy nie odbiera tego ACKpakietu (ponieważ nigdy nie został wysłany, ale również może zostać utracony lub może wystąpić przerwa w sieci), nadawca jest zobowiązany do ponownego wysłania dodatkowego pakietu. Siedzi i próbuje ponownie wysłać pakiet, dopóki nie przejdzie i ACKodpowiedź nie wróci.

Podsumowując, gdy nadawca zmaksymalizuje przepustowość odbiornika, musi zatrzymać i ponownie wysyłać następny pakiet w kółko, dopóki nie będzie wystarczającej przepustowości, aby mógł się przełączyć. To skutecznie zmniejsza prędkość wysyłania do maksimum, które klient może odebrać. (W tym przypadku istnieją metody optymalizacji zmniejszające liczbę ponownych wysyłek pakietu, w których nadawca spowalnia za każdym razem, gdy musi ponownie wysłać pakiet, ale jest to poza zakresem tego uproszczonego opisu.

Możesz to zrobić za pomocą interfejsu ifb.

Dzięki interfejsowi ifb możesz skierować przepływ wejścia eth0 (lub cokolwiek) do wyjścia w ifb0 (na przykład) i zastosować tam reguły limitów.

Sprawdź ten adres URL Linux Foundation: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

A te skrypty, które ograniczają przychodzące i wychodzące pasmo: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Sprawdź wondershaper: http://lartc.org/wondershaper/

W odniesieniu do ruchu przychodzącego:

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

użyj UFW (nieskomplikowana ściana przeciwpożarowa) http://ubuntuforums.org/showthread.php?t=1260812

Wątek pokazuje prosty przykład, który domyślnie przyjmuje adresy IP z 6 trafieniami w ciągu 30 sekund:

sudo ufw limit ssh/tcp

Również bardziej „zaawansowane” polecenie z określonymi wartościami czasu i liczby trafień

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP