Zephyrnet Logosu

Bufferbloat, İnternet ve Nasıl Düzeltilir

Tarih:

İnternet Servis Sağlayıcılarını yıllardır rahatsız eden korkunç bir hastalık var. Tamam, muhtemelen birkaç hastalık var, ama bugün hakkında konuşuyoruz tampon şişkinliği. Nedir, nasıl test edilir ve son olarak bu konuda ne yapabilirsiniz. Oh, ve bu problem üzerinde çalışan tüm insanlara büyük bir haykırış. Vint Cerf, Dave Taht, Jim Gettys ve daha pek çoğu gibi birçok programcı ve mühendis, ortak yararımız için bu somunu kırdı.

Bilgisayarınız İnternet'teki başka bir ana bilgisayara bir TCP/IP paketi gönderdiğinde, bu paket bilgisayarınız üzerinden, ağ kartı aracılığıyla, bir anahtar aracılığıyla, yönlendiriciniz aracılığıyla, bir ISP modem aracılığıyla, birkaç ISP yönlendirici aracılığıyla ve son olarak da yönlendirilir. veri merkezine giderken bazı çok büyük yönlendiriciler aracılığıyla. Ya da belki başka bir masaüstüne ulaşmak için bu dolambaçlı cihaz zincirini tersine çevirerek. Her şeyin gerçekten işe yaraması inanılmaz. Bu atlamaların her biri, işlerin ters gitmesi için başka bir yeri temsil ediyor. Ve eğer bir şeyler gerçekten ters giderse, bunu hemen anlarsınız. Sayfalar aniden yüklenmiyor. VoIP aramalarınız kesiliyor veya kesintiler oluyor. Bulmak ve onarmak o kadar da önemsiz olmasa bile, kopuk bir bağlantıyı tespit etmek oldukça kolaydır.

Bu bariz bir problem. Ya belirgin olmayan bir sorununuz varsa? Siteler yükleniyor, ancak eskiden göründüğünden biraz daha yavaş. Komut satırını nasıl kullanacağınızı biliyorsunuz, bu yüzden bir ping Ölçek. Hah, Google.com'a 15.0 ms kapalı. Yüz paket için çalışmasına izin verin ve esasen paket kaybı yok. Ama bir şey doğru değil. Bir başkası film akışı yaptığında veya bir makine uzak bir sunucuya yedekleme gönderdiğinde, her şey alt üst olur. Bu tampon şişirme ve bunu tespit etmek için basit bir test yapmak gerçekten çok kolay. Bir hız testi yapın ve bağlantınız doygun hale gelirken bir ping testi yapın. Yük altındaki gecikmeniz tavandan geçerse, muhtemelen tampon şişkinliğiniz vardır. Artık tampon şişirme testleri sunan birkaç büyük hız testi sitesi bile var. Ama önce, biraz tarih.

Çöküşün Tarihi

1980'lerde internet çok farklı bir yerdi. Alan Adı Sistemi değiştirildi hosts.txt IP çözümlemesi için ana bilgisayar adı yolu 1982'de yapıldı. 1 Ocak 1983, ARPANET TCP/IP'yi kabul etti - İnternet'in doğum günü. 1984'e gelindiğinde, bir sorun ortaya çıktı ve 1986'da İnternet, kalp krizi geçirdi. tıkanıklık çökmesi.

O günlerde, son teknoloji yerel ağlar saniyede 10 megabit hızında çalışıyordu, ancak siteden siteye bağlantılar en iyi ihtimalle saniyede yalnızca 56 kilobayt aktarıyordu. 1986'nın sonlarında, Lawrence Berkeley Laboratuvarı ile Berkeley'deki California Üniversitesi arasındaki 400 yarda bağlantı gibi, bağlantılar aniden aşırı yavaşlamalar gördü. 56 Kbps yerine, bu bağlantı aniden saniyede 40 bit efektif bir hızda aktarıyordu. Sorun tıkanıklıktı. Bu, aynı otoyolda çok fazla araba olduğunda olanlara çok benzer bir modeldir - trafik yavaşlar.

BSD'nin 4.3 sürümü, birkaç ilginç şey yapan bir TCP uygulamasına sahipti. İlk olarak, paketleri hemen tam kablo hızında göndermeye başlar. İkincisi, eğer bir paket yolda bırakılırsa, mümkün olan en kısa sürede yeniden gönderirdi. Tek tip bir ağ hızının olduğu bir Yerel Alan Ağında bu gayet iyi sonuç verir. İnternetin ilk zamanlarında, özellikle bu Berkeley bağlantısında, 10 Mb/sn LAN bağlantısı 32 kbps veya 56 kbps'ye düşürüldü.

Bu uyumsuzlukla başa çıkmak için, bağlantının her iki tarafındaki ağ geçitleri, yaklaşık 30 paket değerinde küçük bir arabelleğe sahiptir. Bir tıkanıklık senaryosunda, ağ geçidinde 30'dan fazla paket yedeklenir ve fazladan paketler hemen bırakılır. Paketler düştüğünde veya tıkanıklık gidiş dönüş süresini zaman aşımı eşiğinin ötesine ittiğinde, gönderen hemen yeniden gönderilir ve daha fazla trafik oluşturur. Çok dar bağlantı üzerinden çok fazla veri göndermeye çalışan birkaç ana bilgisayar, bir trafik geri besleme döngüsü olan tıkanıklık çökmesine neden olur. Erken İnternet, istemeden kendisini DDoS'a kaptırdı.

[Gömülü içerik]

Çözüm oldu BSD'nin TCP uygulamasına eklenen bir dizi algoritmaartık standardın bir parçası olarak kabul edilmiştir. Basitçe söylemek gerekirse, mümkün olduğunca hızlı göndermek için trafiğin akıllıca yavaşlatılması gerekiyordu. Tanıtılan ilk teknik yavaş başlangıçtı. Bir hız testi çalıştırdığınızda bunun hala kullanıldığını görebilirsiniz ve bağlantı çok yavaş bir hızda başlar ve ardından hızla yükselir. Spesifik olarak, iletimin başlangıcında yalnızca bir paket gönderilir. Alınan her paket için bir alındı ​​paketi (bir onay) döndürülür. Bir onay alındıktan sonra, telden iki paket daha gönderilir. Bu, bağlantı zincirindeki en yavaş bağlantının maksimum hızının iki katına kadar hızlı bir rampa ile sonuçlanır. Bir seferde "dışarıda" olan paket sayısı, tıkanıklık penceresi boyutu olarak adlandırılır. Bu nedenle, konuya bakmanın bir başka yolu da, her gidiş-dönüş başarısının tıkanıklık penceresini birer birer artırmasıdır.

Yavaş başlatma işini bitirdiğinde ve ilk paket bırakıldığında veya zaman aşımına uğradığında, TCP akışı bir tıkanıklık önleme algoritması kullanmaya geçer. Bu, sabit bir veri hızının korunmasına vurgu yapıyor. Bir paket düşürülürse, pencereler yarıya iner ve tam bir pencere değerindeki paketlerin her alındığında, pencere bir artar. Sonuç, tüm veri yolunun maksimum verimi etrafında sürekli olarak sıçrayan bir testere dişi grafiğidir. Bu biraz aşırı basitleştirme ve algoritmalar zaman içinde daha da geliştirildi, ancak mesele şu ki bu uzantıyı TCP/IP'ye yaymak interneti kurtardı. Bazı durumlarda güncellemeler, tüm ağın sert bir şekilde yeniden başlatılması gibi bir şey olarak, posta yoluyla kasete gönderildi.

[Gömülü içerik]

2009'a Hızlı İleri

İnternet 1986'dan beri biraz gelişti. Değişen şeylerden biri, donanım fiyatlarının düşmesi ve yeteneklerin çarpıcı biçimde artmasıdır. 1986'dan bir ağ geçidi, arabelleğini kilobayt olarak ölçebilir ve bu da 100'den az olur. Bugün, sorunlara megabaytlar ve gigabaytlarca bellek atmak oldukça önemsiz ve yönlendirici arabellekleri de bir istisna değil. 50 kB arabellek boyutları için yazılan algoritmalar, modern cihazlarda 50 MB arabellek ile karşılandığında ne olur? Tahmin edilebileceği gibi işler ters gidiyor.

Büyük bir İlk Giren İlk Çıkar (FIFO) arabelleği darboğazdayken, paketler bırakılmadan önce bu arabellek tamamen doldurulmalıdır. Bir TCP akışının, kullanılabilir bant genişliğinin 2 katına kadar yavaş başlaması, paketleri çok hızlı bir şekilde bırakmaya başlaması ve bant genişliği kullanımını yarıya indirmesi amaçlanır. Bufferbloat, bu akış, mevcut hızın iki katı hızda göndermek için çok fazla zaman harcadığında ve arabelleğin dolmasını beklediğinde olan şeydir. Ve bağlantı kararlı tıkanıklık önleme moduna geçtiğinde, bu algoritma ya bırakılan paketlere ya da zaman aşımı eşiğinin gözlemlenen gidiş-dönüş zamanından türetildiği zaman aşımlarına bağlıdır. Sonuç, herhangi bir bağlantı için, yoldaki arabelleğe alınan paketlerin sayısıyla birlikte gidiş-dönüş gecikmesinin artmasıdır. Ve yük altındaki bir bağlantı için, TCP tıkanıklığı önleme teknikleri, tıkanıklık penceresini azaltmadan önce bu arabellekleri doldurmak üzere tasarlanmıştır.

Peki ne kadar kötü olabilir? Yerel bir ağda gidiş-dönüş süreniz mikrosaniye cinsinden ölçülür. Bir İnternet ana bilgisayarına ayırdığınız süre milisaniye cinsinden ölçülmelidir. Bufferbloat bunu saniyelere ve bazı en kötü durumlarda onlarca saniyeye iter. Bunun gerçekten sorunlara neden olduğu yer, trafiğin uygulama katmanında zaman aşımına uğramasına neden olduğu zamandır. Bufferbloat, tüm trafiği geciktirir, bu nedenle DNS zaman aşımlarına neden olabilir, VoIP aramalarını bozuk bir karmaşaya dönüştürebilir ve İnternet'i acı verici bir deneyim haline getirebilir.

çözüm Akıllı Kuyruk Yönetimi. 1986'dan bu yana bu konsept üzerinde yapılmış çok sayıda çalışma var. Adil sıraya alma, ilk çözümlerden biriydi, ara arabellekleri akıllı hale getirdi ve bireysel trafik akışlarını ayrı kuyruklara böldü. Bağlantı tıkandığında, her sıra bir seferde tek bir paket yayınlar, bu nedenle Bittorrent üzerinden bir ISO indirmek VoIP trafiğinizi tamamen engellemez. Birçok yinelemeden sonra CAKE algoritması geliştirildi ve yaygın olarak dağıtıldı. Bu çözümlerin tümü, önemli ölçüde azaltılmış gecikme sağlamak için esasen biraz maksimum verimden ödün verir.

Bufferbloat'ta FLENT misiniz?

Bufferbloat'ın çözülmüş bir sorun olduğunu ve ağınızda kesinlikle bununla ilgili bir sorununuz olmadığını söylemeyi çok isterim. Maalesef durum pek de öyle değil. Bir sorununuz olup olmadığını kabaca anlamak için, adresindeki hız testlerini kullanın. dslreports, fast.comya da speedtest.net. Bu üçünün her biri ve muhtemelen diğerleri, yük ölçümü altında bir tür gecikme süresi verir. var dalga formu tarafından barındırılan bir Bufferbloat'a özgü test, ve tarayıcıda çalıştırmak için en iyisi gibi görünüyor. İdeal bir ağ, tıkanıklık olduğunda hala düşük gecikme süresi gösterecektir. Gecikme süreniz test sırasında önemli ölçüde yükselirse, muhtemelen bir arabellek şişkinliği vakanız vardır.

İnekler için bir komut satırı aracı var, flent, bu derinlemesine bir tampon şişirme testi yapar. komutunu kullandım, flent rrul -p all_scaled -H flent-fremont.bufferbloat.net Bu grafiği oluşturmak için ve yük altında gecikme süresinin 100 ms'nin üzerinde hızla ölçeklendiğini görürsünüz. Bu, Yük testi altında Gerçek Zamanlı Yanıtı çalıştırıyor ve ağımda biraz arabellek sorunu olduğunu açıkça gösteriyor. Sorun tespit edildi, bu konuda ne yapabilirim?

Pastanızı yiyebilirsiniz

Hepimiz ağlarımızda OpenWRT yönlendiricileri çalıştırdığımız için… Açık kaynaklı bir yönlendirici çalıştırıyorsunuz, değil mi? Alternatif olarak bir avuç ticari yönlendirici bir tür yerleşik SQM'ye sahip, ancak Hackaday'da bundan kesinlikle memnun değiliz. FOSS çözümü burada KEK, bir kuyruk yönetim sistemidir ve OpenWRT deposunda zaten mevcuttur. Aradığınız paket luci-app-sqm. Bunu yüklemek size web arayüzünde Ağ -> SQM QoS altında yeni bir sayfa verir.

Bu sayfada, WAN arayüzünüzü şu şekilde seçin: Interface name. Ardından, hız testi sonuçlarınızı Kilobit/saniyeye dönüştürün, yaklaşık %5'i azaltın ve bunları yükleme ve indirme hızlarına ekleyin. Şuna çevir: Queue Discipline ideal olarak kullanmak istediğimiz sekme Cake ve piece_of_cake.qos seçenekler olarak. Bu son sekme gerektirir biraz ev ödevi en iyi değeri belirlemek için, ancak Ethernet with overhead ve 22 Başlangıç ​​için makul değerler gibi görünüyor. SQM örneğini etkinleştirin ve ardından kaydedip uygulayın.

Ve şimdi ayarlayıp test ediyoruz. İlk kurulumda, çekirdek modülünün yüklenmesi için yönlendiricinin gerçekten yeniden başlatılması gerekebilir. Ancak tampon şişirme testlerinden birinde hemen bir fark görmelisiniz. Yükleme veya indirme arabelleğiniz hala aşırıysa, bu yönün hızını yüzde birkaç oranında biraz daha düşük ayarlayın. Bufferbloat'ınız 0'a düşerse, hızı biraz artırmayı deneyin. Maksimum hız üzerinde minimum etki ve arabellek üzerinde maksimum etki arıyorsunuz. Ve bu kadar! Bufferbloat Beast'i öldürdün!

[Gömülü içerik]

spot_img

En Son İstihbarat

spot_img