Linux Yavaş Başlatma: ip yolunun değiştirilmesinin ilk pencerede bir etkisi yoktur

Makinemdeki tcp başlangıç ​​penceresini aşağıda gösterildiği gibi 10 olarak değiştirdim

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 

Ve tcp_slow_start_after_idleaşağıda gösterildiği gibi değiştirildi

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

bir ip güzergah gösterisi onayı aşağıda verilmiştir

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

Şimdi web sitesinde bir tcpdump yaptığımda başlangıç ​​penceresinde WIN / MSS varsayılan 4 olarak kalan bir değişiklik görmüyorum . 5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

Web sayfasına yaptığım curl hit yaklaşık 30 KB veri istedi .

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

Yaklaşımımda yanlış olan ne olabilir?

Çekirdek

[user~]$ uname -r
3.0.4x86_64-linode21

Güncelleme olarak, google.com'u denediğimde sonuçlar

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

Gördüğünüz gibi WIN / MSS bu durumda 14600/1460 = 10

Siteme sunucu makinesinden kıvrılma yoluyla vurmayı denedim ve sonuç:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

Bu durumda WIN / MSS 32792/16396 = 2'dir

TCP'nin nasıl çalıştığını yanlış anladığınızı düşünüyorum.

Gönderilen her paket her zaman bir alıcı penceresi (diğer adıyla RWIN) ve isteğe bağlı bir ölçeklendirme faktörünün reklamını yapar, bkz. RFC 1323

Gönderici göndermesine izin verilmez daha da kabul almadan RWIN belirtilen veri miktarı. Tıkanıklık penceresine bağlı olarak, gönderen RWIN'i doldurup doldurmamaya karar verebilir.

Bu nedenle, TCP paketlerinde ortak olan iki bilgi parçası vardır. Sunucudaki RWIN ve istemcideki RWIN. Bu şekillerin her ikisi de, tıkanıklık penceresinin maksimum boyutunun her iki uçta ne olabileceğini belirler.

Sunucudaki RWIN, söz konusu dosya yüklemeleri için performansı optimize etmeye çalışırken ilginçtir.

İndirme hızını belirlemeye çalışırken istemcideki RWIN ilginçtir.

Bu numaraların hiçbiri diğer uçtaki tıkanıklık penceresini herkese açık yapmaz .

Eğer 64k RWIN varsa, sunucuda tıkanıklık penceresi 64k'den daha düşük herhangi bir sayı olabilir .

Gerçek tıkanıklık penceresinin ne olduğunu belirlemenin tek yolu paketleri saymaktır.

Biliyorsam:

1. Gidiş-dönüş zamanım (RTT) ~ 200 ms.
2. Ben sadece 100k kaynak istedim.
3. 64k'lık bir RWIN'im var.

~ 200ms içinde 1452 bayt uzunluğunda sunucudan 2 paket geri alırsam, muhtemelen sunucudaki tıkanıklık penceresi 4356'dan küçüktür, çünkü daha büyük olsaydı 3 paket gönderilirdi. IW 10 olarak ayarlanmış olsaydı, 200ms işareti etrafında 10 paketlik bir patlama görürdüm.

IW'nizi değiştirirseniz ve değişikliğin çalıştığını onaylamak istiyorsanız , sunucudaki tıkanıklık pencere boyutu hakkında bir tahmin almak için paketleri saymanız gerekir .

Unutmayın, muhtemelen bir görüşmenin ortasına bakmamanız için (tıkanıklık penceresinin zaten büyüyebileceği) SYN, SYN-ACK, ACK'dan hemen sonra konuşmaya bakmak istersiniz.

Pencere boyutu hangisi daha küçük olursa: sunucu başlangıç ​​pencere boyutu veya istemci RWIN. 5840, Linux 2.6 için varsayılan RWIN olduğundan, istemcinizin burada sınırlayıcı faktör olduğu görülmektedir.

Bir pencere kutusundan deneyin. Windows XP'nin 64k, daha yeni sürüm 8k RWIN'si var.

Kaynak: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (İlginç kısım videonun altında)

Düzenleme: Cevabı daha açık hale getirmek için genişletme:

• TCP el sıkışmasında, istemci sunucuya izin verilen maksimum pencere boyutunu gönderen bir SYN paketi gönderir. (Tcpdump çıktınızın gösterdiği gibi, bunlar 5840 bayttır)
• Sunucu şimdi SYN ACK ve üzerinde anlaşmak istediğiniz pencere boyutu ile yanıt veriyor. Bu pencere boyutu yalnızca istemcinin önerdiğinden daha küçük olamaz, daha büyük olamaz. Sunucu nasıl yapılandırılırsa yapılandırılsın, hiçbir zaman bu istemciyle 5840 bayttan daha büyük pencere boyutlarına sahip olamaz.
• İstemci ACK döndürür ve sonsuza dek mutlu bir şekilde veri alışverişi yapar.

Edit2: Soruya eklenen tcpdumps sunucunun google ve kendisi MÜŞTERİ OLARAK HAREKET bağlantıları gösterir.