Network Bottleneck

Bir network darboğazı(Network Bottleneck), veri akışının bilgisayar veya network kaynakları tarafından sınırlandırıldığı durumu ifade eder. Veri akışı, çeşitli sistem kaynaklarının bant genişliğine göre kontrol edilir. Bir ağ üzerinde çalışan sistem, ağın mevcut kapasitesi tarafından desteklenenden daha yüksek hacimde veri sağlıyorsa, network darboğazı meydana gelir. Adından da anlaşılacağı gibi, bir network darboğazı, veri iletişiminin yavaşlamasına neden olur ve bir ağdaki kullanıcı verimliliğini ve üretkenliğini sınırlar. Tüm bu sorunlardan kaçınmak için sistemler belirli bir veri akış kapasitesini destekleyecek şekilde inşa edilir, böylece işler sorunsuz şekilde devam edebilir. Bu dökümanda network darboğaz sebebleri ve çözümleri araştırılacaktır.

SYN-RECV

Kernel, LISTEN modunda olan bir bağlantı noktası için bir SYN paketi aldığında, arka uç ACK ile yanıt vermediğinden bağlantı SYN_RECV durumuna gelmektedir. Normal bir TCP bağlantısı üç aşamadan(3 yönlü el sıkışma) oluşur. İstemci bir SYN paketi gönderir, Sunucu bir ACK paketi ile yanıt verir, İstemci bir SYN+ACK paketi ile yanıt verir, TCP bağlantısı “established” moda girer.

Sunucu çok meşgulse genellikle (Linux sistemlerinde) SYN-ACK yanıtını göndermeyi bekleyecektir. SYN alındıktan sonra ve SYN-ACK geri gönderilmeden önce bağlantı SYN-RECV durumundadır. SYN-RECV durumundaki mevcut bağlantı sayısı şu şekilde kontrol edilebilir:

netstat -an | grep -c SYN_RECV

Çoğu durumda, sayının 0 olmasını beklenmektedir, aksi takdirde bu, bir yerlerde bir darboğaz olduğu anlamına gelebilir.

Bu sayı aynı zamanda, birisi “SYN flood” adı verilen bir saldırı gerçekleştirirse, temelde bir saldırganın birçok SYN paketi gönderdiği, ancak ACK paketini asla göndermediği anlamına gelir. Sunucu tüm bağlantıları bekleme durumunda tutacak ve çok geçmeden mevcut tüm kaynakları işgal edecektir.

NIC Ring Buffer

Ağ kartı, gelen bir pakete ilk yanıt verendir. Ağ kartı, Ağ Arabirim Kartının kısaltması olan NIC olarak adlandırılır. NIC’nin içinde küçük bir DAM bellek yongası (Doğrudan erişim belleği) vardır; bu yonga, çekirdek tarafından sisteme kopyalanıncaya kadar yeni bağlantıların depolandığı yerdir. Paketler için bu geçici depolama, NIC Ring Buffer veya DMA Ring Buffer olarak adlandırılır. Bu dairesel bir arabellektir, bu nedenle dolarsa paketler düşecektir.

Ring arabelleğinin boyutu, NIC yazılımı izin veriyorsa, genellikle kernel sürücüsü üzerinden değerleri ayarlanabilir. Sanal bir makine değilse;

ethtool -G eth0

Sanal bir makineyse;

sysctl net.core.netdev_max_backlog

Kontrol gerçekleştirilebilir.

Socket Drop

netstat -s içindeki istatistiklere bakarak inceleyeceğimiz bu durum; soket taşması nedeniyle reddedilen yeni bağlantıların sayısını bize göstermektedir. Kabul kuyruğundan dolayı SYN paketinin düştüğü doğrulanırsa, bir çözüm olarak kuyruğunun uzunluğunu artırmak olduğunu düşünmek doğaldır. Biriktirme listesi ve net.core.somaxconn parametreleri aynı anda artırmak, kuyruğunun uzunluğunu artırabilir. Ancak genel olarak, bu yöntem sorunu yalnızca hafifletebilir ve en olası durum, uzayan kuyruğunun hızlı bir şekilde yeniden doldurulmasıdır. Bu nedenle, bu sorunu çözmenin en iyi yolu, uygulamayı kontrol etmek ve yeni bağlantıları neden bu kadar yavaş kabul ettiğini görmek ve temel nedeni çözmektir.

netstat -s | grep -i listen

Sayı sürekli artan bir durumda değilse genellikle bir sorun gözükmemektedir. Çünkü bu sayıyı artıran çekirdekte bir kod bloğu bulunmaktadır ve her bir düşen soketi saymaktadır. Bu durumda ilk gözlemlenecek ağ arayüzündeki iletim kuyruğunun boyutunu kontrol etmektedir.

ifconfig eth0 | grep txqueuelen

Ardından, arabirimin iletim kuyruğu nedeniyle paketleri bırakıp bırakmadığını kontrol edilmesi gerekmektedir.

tc -s qdisc show dev eth0 | grep dropped

Son olarak, herhangi bir paket parçalanma sorunu olup olmadığını kontrol edilmesi tavsiye edilir:

cat /proc/net/snmp | grep '^Ip:' | cut -f17 -d' '

Dinlenilen servisler için kuyruk boyutlarını çıktısı kontrol edilir. Recv-Q, kabul kuyruğu sayısını gösterir ve Send-Q biriktirme listesi parametresini gösterir:

ss -plnt sport = :80

Kabul kuyruğunda gerçekten birşey olmadığı gözlemlenirse, SYN-RECV durumunda kaç bağlantı olduğunu kontrol etmekte fayda vardır.

ss -n state syn-recv sport = :80 | wc -l

Bağlantılar oldukça hızlı bir şekilde “ESTABLISHED” oluyorsa. Yeterli dosya tanımlayıcısı sahip olduğunuzdan emin olmanız gerekir.

sysctl fs.file-nr

Half-Closed bağlantıları kontrol edilmeli, FIN, ACK , toplam ESTABLISHED sayıları kontrol edilerek

ss -n state time-wait | wc -l
ss -n state established | wc -l

Toplam bağlantı sayısına göre azalan veya sabit bir oranda ilerliyorsa çözüm için diğer kaynaklara göz atmak gerekebilir. SYN hatalarının oranını ölçümü yapılır, SYN ve Kabul kuyruğu kullanımlarını kontrol edildikten ve Gelen bağlantıların biriktirme listesi sırasının sayısı artırılmak istenirse;

sysctl -w net.core.netdev_max_backlog=3000000

Bu kuyruk, INPUT tarafında sıraya alınan maksimum paket sayısını belirler.

“dmesg” çıktısında;

TCP: out of memory -- consider tuning tcp_mem

var ise; TCP düzeyinde yetersiz bellek hatası olduğu anlamına gelir. Yetersiz ram hatasının sadece uygulama seviyesinde gerçekleştiğini ve asla TCP seviyesinde gerçekleşmemektedir. Ayrılabilir maksimum toplam arabellek alanını artırmak hızlı bir çözüm olabilir.

sysctl -w net.ipv4.tcp_mem=’758316 1011092 1516632’

Network Darboğaz sorunu NIC ve ayarlamalarından veya saldırılardan dolayı olduğu gibi RAM,CPU,DISK kaynaklı olabilmektedir. Bu durumda darboğaz yaşandığı durumlardaki CPU,DISK,RAM istatisliklerinin izlenmesi gerçekleştirmek gerekmektedir.

Case study: Network bottlenecks on Linux: Part 1 — The NIC

https://medium.com/@oscar.eriks/case-study-network-bottlenecks-on-a-linux-server-part-2-the-kernel-88cf614aae70