Hız sınırlayıcı gelen trafik

Gelen trafiği hızlandırmanın mümkün olup olmadığını hiç anlamadım . Ben olduğunu fark doğrudan (her iki uç noktaları kontrolü sizdedir sürece) paketleri göndererek, ama dikkate bu sınırlama alma Uzak sunucunun oranını kontrol etmek sayede yöntem tam olarak nasıl indirme yöneticileri izin veriyoruz beni başarıyla set indir hız sınırları ?

TCP yavaş başlatma ve hız sınırlayıcı gelen trafik arasında herhangi bir bağlantı var mı ? Gönderenin paket gönderme hızını yapay olarak sınırlamak için yavaş başlatma ile açıklanan yöntemleri kullanmak mümkün müdür?

Ek bir husus olarak, trafik şekillendirme uygulamak istediğim sunucunun PPPoE bağlantısının kendisini oluşturduğu ve ağın geri kalanı için bir yönlendirici görevi gördüğü belirtilmelidir.

Güncelleme: Şimdiye kadar verilen cevaplar, sorduğum sorulara adil bir genel bakış sağladı, ancak yine de indirme yöneticilerinin gelen trafiği nasıl sınırlandırabildiğini ve daha spesifik olarak, Linux ağ geçidi kutusu.

İndirme yöneticileri büyük olasılıkla damlama kağıdında açıklandığı gibi çalışır .

BSD soketlerini kullanan bir işlem kendi hız sınırlamasını yapabilir. Akış yukarı sınırlama için, uygulama bunu sadece bir sokete yazılan veri hızını sınırlayarak yapabilir. Benzer şekilde, aşağı akış sınırlaması için bir uygulama bir soketten okuduğu veri hızını sınırlayabilir. Ancak, bunun neden işe yaradığı hemen belli değil. Uygulama bir soketten bazı verileri okumayı ihmal ettiğinde, soket alma tamponları dolar. Bu da, alıcı TCP'nin daha küçük bir alıcı penceresinin (rwnd) reklamını yapmasına neden olur ve alttaki TCP bağlantısı üzerinde geri basınç oluşturur ve böylece veri akışını sınırlar. Sonunda bu “damlama” etkisi uçtan uca hız sınırlaması sağlar. Ağ yığınının tüm katmanlarındaki arabelleğe alma işlemine bağlı olarak, bu etkinin yayılması biraz zaman alabilir.

Bir UNIX sistemindeki zaman zaman tek bir programı hızlandırmanız gerekiyorsa, basit bir çözüm damlamadır . Gerçek bir trafik şekillendirme, bir ağ geçidinde yaptığınız gibi, ile yapılabilir tc. Bu, Bölüm 9'da belgelenmiştir. Linux Gelişmiş Yönlendirme ve Trafik Kontrolü NASIL Bant Genişliği Yönetimi için Kuyruk Disiplinleri NASIL belgesinde yer almaktadır.

56 Mb modem ve 4 Mbps DSl hattına karşı, hız farkını yaratan (genellikle) hiçbir şekil yoktur, bu sadece bağlantının hızında bir farktır.

Gelen trafikte şekillendirmenin zor olmasının nedeni, iletim ortamında tampon bulunmamasıdır. Gelen bitleri kabul edersiniz ya da kaybolurlar. Trafik taht bir arayüz bırakmak üzereyken, paketleri istediğiniz kadar tamponlayabilir ve yeniden sipariş edebilirsiniz (veya en azından cihazdaki kullanılabilir bellek belleğine kadar).

TCP'nin üstünde bir katmana sahip protokoller için (torrentler için durumun bu olup olmadığını bilmiyorum), daha fazla veri için istekleri hızlandırmak için basit bir mesele olacaktır. Aksi takdirde, paketlerin ACKingini geciktirmek için uygulamanın işletim sistemi ile iletişim kurması gerekir. Çoğu UDP tabanlı protokol, zorunlu olarak uygulamaya özel protokolde ACK / yeniden gönderme mantığına sahip olacaktır, bu nedenle bu noktada onlara ayak uydurmak önemsizdir.

Olası bir yol, DSL yönlendiricinizin LAN tarafındaki İnternet'ten gelen trafiği şekillendirmek olacaktır, bu noktada bir çıkış bağlantı noktasında şekillendiriyor olacaksınız.

Gelen verileri şekillendirmeye izin veren (ve kafamın üst kısmından hiçbirini bilmeyen) neden herhangi bir çözüm bulamadığınıza cevap veremiyorum, ancak gönderenin alıcının ne kadar hızlı veri alabileceğini bilmesi konusunda:

TCP / IP'nin temel tasarımı, kaynağın hedefe gönderdiği her paket için, hedefin ACKpaketi aldığını söyleyerek yanıt vermesini beklemesi ( paket ile) beklemesidir .

Bu nedenle, 4 Mbps'lik bir göndericiniz ve 56Kbps'lik bir alıcınız varsa, gönderenin alıcının her bir pakete yanıt vermesi için paket gönderme arasında oturması ve beklemesi gerekir (Bu yükü azaltmak için bazı teknik ayrıntılar vardır, ancak öncül hala bir özet üzerinde tutar düzeyi).

Gönderen zaten 56Kbps veri gönderiyor ve daha sonra biraz daha göndermeye çalışırsa ne olur?

Paket kaybolur. (Potansiyel olarak bir anahtarın arabelleğinde kuyruğa alınır, ancak bu dolduğunda paket kaybolur). Paket kaybolduğundan, alıcı asla almaz ve bu nedenle asla bir ACKpaket göndermez . Gönderen bu ACKpaketi hiçbir zaman almadığından (hiçbir zaman gönderilmediğinden, aynı zamanda kaybolabilir veya bir ağ kesintisi olabilir), gönderenin ekstra paketi yeniden göndermesi gerekir . Oturup paketi geçene ve ACKcevap tekrar alana kadar yeniden göndermeye çalışır .

Özetlemek gerekirse, gönderen alıcının bant genişliğini en üst düzeye çıkardıktan sonra, geçmesi için yeterli bant genişliği olana kadar bir sonraki paketi durdurup tekrar göndermelidir. Bu, gönderme hızını istemcinin alabileceği en yüksek değere etkili bir şekilde azaltır. (Ve bu durumda bir paketin yeniden gönderilme sayısını azaltmak için optimizasyon yöntemleri vardır, burada gönderen her paketi yeniden göndermek zorunda kaldığında yavaşlar, ancak bu basitleştirilmiş açıklamanın kapsamı dışındadır.

Bir ifb arayüzü ile yapabilirsiniz.

Bir ifb arayüzü ile, eth0 (veya her neyse) giriş akışını ifb0'daki (örneğin) çıkışa yönlendirebilir ve orada sınır kurallarını uygulayabilirsiniz.

Linux Vakfı'nın bu URL'sini kontrol edin: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

Ve bu, gelen ve giden bant genişliğini sınırlayan komut dosyaları: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Wondershaper'a göz atın: http://lartc.org/wondershaper/

Gelen trafikle ilgili:

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.

UFW (Karmaşık olmayan Ateş Duvarı) kullanın http://ubuntuforums.org/showthread.php?t=1260812

Bu iş parçacığı, 30 saniye içinde 6 isabetle varsayılan IP'lerin reddedildiğine dair basit bir örneği göstermektedir:

sudo ufw limit ssh/tcp

Ayrıca zaman ve isabet sayısı için belirtilen değerlerle daha 'gelişmiş' komut

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