WAN'da trafik olduğunda yüksek gecikmeye ne sebep olur?

Yavaş internet hızları yaşayan bir ağım var. Çok fazla sorun giderme işleminden sonra, herhangi bir akış içeriğinin / indirmenin WAN trafiğinin gecikmesinin patlamasına neden olacağını belirledim.

Örneğin, yük altında, yaklaşık 30 ms'de 8.8.8.8'e ping atıyorum. YouTube'u aynı bilgisayarda oynatmaya başlarsam gecikme süresi yaklaşık 500ms, yaklaşık 400ms'lik bir farkla atlar. Videoyu kapatırsam gecikme 30 ms'ye döner. Ancak, aynı LAN üzerinde pandora akışını başlatan bir kullanıcı varsa, sorun geri döner.

Ağımın tek bir 10/100 anahtarı kapalı. Anahtar doğrudan DSL yönlendiriciye bağlanır. Genelde 6Mb'lik bir bağlantım var.

Sorun giderme işleminde aşağıdakileri tamamladım:

• Hatalı paketler arayan birkaç iş istasyonundan wireshark ile tarandı. (Ben dahil ediyorum ama taramalar gizli bilgi var). Uzaktan bile sıradan bir şey yok.
• Yönlendiriciyi yükseltilmiş bir modelle değiştirdikten sonra yükseltilmiş ürün yazılımı
• ISS, speedtest.net'te doğru şekilde ölçülen hızı artırdı (10 aşağı, 1,5 yukarı). Sorun aynıydı.
• ISP, kötü donanım / bağlantı noktasına sahip olma ihtimaline karşı kartlarını uçlarından değiştirmişti.
• Aynı ISS / paket ile başka bir ofiste test edildi. Gecikmeyi etkilemeden YouTube @ 1080p ve pandora akışında birden fazla bilgisayar vardı.
• Her bilgisayarı kapatın ama bir gece ve hiçbir kullanıcı nerede orada koştu gece.
• Gecikme problemi yaşamayan izlenen LAN trafiği.

Bir bant genişliği sınırına ulaşırsam veya hızın bazı donanımlarda tıkanıklık yaratıyorsa, bu soruna neden olacağının farkındayım. Ancak, hiç de öyle görünmüyor. WAN üzerinden neredeyse her trafik gecikmeyi artıracaktır. Bağlantı hızını neredeyse ikiye katladığımda bile sorun aynıydı. Pandora ve birkaç sörf yaparken iki kullanıcı aldığımda, internet hiçbir şeye gitmez (bırakılan paketler, sayfalar yüklenmez). Evde bağlantımın yarısı var ve aynı anda netflix / youtube / pandora akışımız 5 Mb'ime bile dokunmuyor.

Soru: Trafik WAN üzerinden geçtiğinde yüksek gecikmeye neden olan şey nedir?

Bu muhtemelen DSLM / LNS'nin 6Mb hız sınırlamasını gerçekleştiren kısmında bir çeşit " bufferbloat " gibi görünüyor .

CPE kutunuz olabilir, ancak bu biraz daha az olasıdır.

Gecikmenin nerede meydana geldiğini doğrularım. Her sekmede gecikmeyi kontrol eden MTR gibi bir araç kullanın . MTR, her atlama için ping istatistiklerini bir izleme rotasıyla birleştirir ve bu tür bir sorunun daraltılmasına büyük ölçüde yardımcı olabilir.

Bir linux kutusunda komut , bu aracın mtr 8.8.8.8bir Windows sürümü de vardır .

Çıktı size gecikmenin nerede başladığını gösterecektir. ISS ağındaysa, çıkışı ISS'ye iletebilir ve ağ sorunlarını gidermek için kullanmalarına yardımcı olabilirsiniz.

Gecikme ağınızın içinde başlarsa, sorunu kendiniz de daraltabilirsiniz.

DSL hattı istatistiklerini kontrol edin. (aralıklı ve hızlı yol, hata sayaçları vb.)

Farklı bir konumdaki test , belki farklı bir DSLAM'da farklı bir çizgiyi test etti . Bu, ISS altyapısının suçlamadığını göstermektedir. DSL hattınızın hatalı olduğunu şiddetle önerir. Muhtemelen DSLAM'ın kendisi tıkanmış, ancak öngörülebilir ve tekrar tekrar çizgiyi iten kişi olmanız pek olası değildir.

ATM hücreleri bozuluyorsa (çoğu DSL için aktarım), tüm çerçevenin yeniden gönderilmesi gerektiği için bunun gibi önemli yavaşlamalar görürsünüz.

Bir müşterinin ağda gecikme yaşadığı durumlar olduğunda, yapılacak ilk şey ağdaki her bir bağlantıyı kontrol etmektir. Genellikle bir darboğazın meydana geldiği bir cihaz vardır.

Düşük kullanım ağı ise, internete bağlı cihaz dışında her şeyde QoS'yi tamamen devre dışı bırakardım (QoS bir anahtarlama ortamındaki trafiği yavaşlatacağından).

Paket yakalamalarınızda I / O analizi yaparım ve herhangi bir yerde yayla alıp almadığınızı görürüm. Bu, paketlerin teslimini geciktirecek veya paketlerden tamamen kurtulacak kuyruğa neden olabilecek yoğun trafiği gösterebilir.

Ayrıca, sorun olduğunda her bir cihazın CPU'sunu da kontrol ederim. CPU'nun yukarı atladığını görürseniz, muhtemelen sorunlu cihazınızdır. Hata olup olmadığını görmek için günlükleri de kontrol edin.

Ayrıca, tüm bağlantıların tam hızda (hız 100 tam çift yönlü) görüştüğünden emin olabilirim.

Ayrıca, güvenlik duvarını veya güvenlik hizmetlerini devre dışı bırakmayı deneyin.

Bakılacak başka bir şey, anahtarınız ve DSL modem arasındaki bağlantı olacaktır. Tanımladığınız belirtiler, ikisi arasında dubleks uyumsuzluk varmış gibi neredeyse ses çıkarıyor.

Anahtarı devre dışı bırakmanın bir başka yolu, anahtarı tamamen çıkarmak ve doğrudan DSL modeme bağlı bir makine ile bağlantıyı test etmektir.

Trafik yüksek olduğunda yüksek gecikme / kötü verim bazen bir L1 probleminin (dubleks uyumsuzluğu / kötü kablo / kirli fiber) göstergesidir. Durumun böyle olup olmadığını kontrol ettiniz mi?

Bu, yukarı yönlü bir darboğaz olabilir mi? Dünyanın neresinde olduğunuzdan emin değilim, ama belki de İSS'nin korkunç uluslararası bant genişliği var. Speedtest.net varsayılan olarak en yakın sunucuyu kullanır.

Kullandığım basit yöntem, izlerde yüksek yanıt sürelerini arayan ve bu sistemi donanım, DOS saldırıları, QoS uygunsuz sınıflandırmalar ve benzeri için kontrol eden traceroute işleviydi. Tabii ki yoldaki tüm ekipmanlara erişmeniz gerekiyor. Bir telekom için çalıştığımdan beri o zamanlar benim için kolaydı.

Bunu test ettiğiniz işletim sistemi nedir? Windows ise, varsayılan olarak ağ arayüzüne "QoS Packet Scheduler" hizmeti yüklenmiş ve bağlanmıştır. Ağ yığınının temel ayarlarına bağlı olarak devreye girecek ve "multimedya" olarak sınıflandırılmamış trafiği proaktif olarak geciktirecektir.

Arayüzden silmeyi ve sonuçlarınızı tekrar kontrol etmeyi deneyin.

Ya da daha iyisi, doğru bir şekilde yeniden yapılandırın: http://www.dslreports.com/faq/3688

Deneyimlerimden, bazı ISP'lerin ICMP paketini en düşük öncelikle ele aldığını ekliyorum. Bir kez oldu, her zaman ben bile "istekleri zaman aşımına" sahip youtube başlatmak.

Mesaj winmtr video başlatma ve video oynatılırken önce. 2. bir akış başlatın ve bunun hem ICMP paketlerini hem de 1. videoyu nasıl etkileyeceğini görelim.

Bir 10/100 anahtar üzerinden bağlanıyorsanız ve bir kısmında otomatik anlaşma yaptıysanız, dubleks uyumsuzluğunuz olabilir. Bu, ağda, işler nispeten sessiz olduğunda görünmeyecek bir yük olduğunda sık sık çarpışmalara neden olur. Çarpışmalar, iletişimi geri çekmeye zorladığı gibi yeniden ortaya çıkacak ve makul olmayan bir yavaşlamaya neden olabilir.

Eski bir ileti dizisini yeniden canlandırdığım için üzgünüm. OP şunu yazdı:

... WAN üzerinden neredeyse her trafik gecikmeyi artıracak ...

Bunlar Tamponbloat'ın kesin semptomlarıdır. Yönlendirici büyük olasılıkla çok fazla trafik kuyruğa alıyor ve küçük akışları (açlık sağlamak için gerekli olan) açlık çekiyor.

Yönlendiricinizin "yük altında gecikme" sorununu azaltmak için bir yola ihtiyacı vardır. QoS ile uğraşabilirsiniz, ancak bu çok fazla yapılandırma ve sürekli ayarlama gerektirir.

Tekniğin bilinen durumu OP'den bu yana ilerlemiştir, bu nedenle Bufferbloat, AQM, CoDel, fq_codel, Cake, PIE veya diğer tekniklere bakın.