Windows TCP Pencere Ölçeklendirme Platoda çok erken isabet

Senaryo: Düzenli olarak büyük dosyaları (FTP / SVN / HTTP PUT / SCP) ~ 100-160ms uzaklıktaki Linux sunucularına yükleyen çok sayıda Windows istemcisi var. Ofiste 1Gbit / s senkron bant genişliğine sahibiz ve sunucular ya AWS örnekleri ya da fiziksel olarak ABD DC'lerinde barındırılıyor.

İlk rapor, yeni bir sunucuya yapılan yüklemelerin olabileceğinden çok daha yavaş olmasıydı. Bu testte ve birden fazla yerden çıktı; istemciler, Windows sistemlerinden ana bilgisayara 2-5Mbit / s hızında karar veriyorlardı.

iperf -sBir AWS örneğinde ve ardından ofisteki bir Windows istemcisinden ayrıldım :

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

İkinci rakam, sonraki testlerde (AWS'in Değişkenleri) önemli ölçüde değişebilir, ancak genellikle ihtiyaçlarımız için fazlasıyla yeterli olan 70 ile 130Mbit / s arasındadır. Wiresharking oturumu, görebiliyorum:

• iperf -c Windows SYN - Pencere 64kb, Ölçek 1 - Linux SYN, ACK: Pencere 14kb, Ölçek: 9 (* 512)
• iperf -c -w1M Windows SYN - Windows 64kb, Ölçek 1 - Linux SYN, ACK: Pencere 14kb, Ölçek: 9

Açıkçası, bağlantı bu yüksek verimi sürdürebilir, ancak çoğu gerçek dünya uygulamalarının yapmama izin vermeyeceği herhangi bir kullanım için pencere boyutunu belirlemem gerekiyor. TCP el sıkışmaları her durumda aynı başlangıç ​​noktalarını kullanır, ancak zorunlu ölçekler

Tersine, aynı ağdaki bir Linux istemcisinden doğrudan bir iperf -c((varsayılan 85kb sistemi kullanarak) bana verir:

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

Herhangi bir zorlama olmadan, beklendiği gibi ölçeklenir. Bu araya giren atlamalarda veya yerel anahtarlarımızda / yönlendiricilerimizde bir şey olamaz ve aynı şekilde Windows 7 ve 8 istemcilerini de etkiler. Otomatik ayarlama konusunda birçok kılavuz okudum, ancak bunlar genellikle kötü korkunç ev ağı kitinin etrafında çalışmak için ölçeklendirmenin tamamen devre dışı bırakılmasıyla ilgilidir.

Biri bana burada neler olduğunu söyleyebilir ve düzeltmem için bir yol verebilir mi? (Tercihen GPO aracılığıyla kayıt defterine yapabileceğim bir şey.)

notlar

Söz konusu AWS Linux örneğinde, aşağıdaki çekirdek ayarları uygulanır sysctl.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

Diğer olası darboğazları ekarte etmek ve kaldırmak için sunucuya dd if=/dev/zero | ncyönlendirmeyi kullandım , ancak sonuçlar aynı. Testler ile (Cygwin, Doğal Windows, Linux) kendi platformlarda yukarıdaki iperf testlerinin hemen hemen aynı şekilde ölçeklendirilirler./dev/nulliperfncftp

Düzenle

Burada alakalı olabilecek başka bir tutarlı şey tespit ettim:

Bu, yakınlaştırılan 1 MB'lik yakalamanın ilk saniyesidir, yakınlaştırılır. Pencere genişlediğinde ve arabellek büyüdükçe, Yavaş Başlat eylemini görebilirsiniz . Daha sonra , varsayılan pencere iperf testinin sonsuza dek düzleştiği noktada tam olarak ~ 0.2s'lik bu küçük plato var . Elbette bu, çok fazla baş dönmesi yüksekliğine kadar ölçeklenir, ancak ölçeklemede bu duraklamanın (Değerler 1022bayt * 512 = 523264) ondan önce olması ilginçtir.

Güncelleme - 30 Haziran.

Çeşitli cevapları takip etmek:

• CTCP'yi Etkinleştirmek - Bu fark yaratmaz; pencere ölçeklendirmesi aynıdır. (Bunu doğru anlarsam, bu ayar ulaşabileceği maksimum boyut yerine tıkanıklık penceresinin büyütülme oranını artırır)
• TCP zaman damgalarını etkinleştirme. - Burada da değişiklik yok.
• Nagle algoritması - Bu mantıklı ve en azından grafikteki belirli patlamaları sorunun herhangi bir göstergesi olarak görmezden gelebileceğim anlamına geliyor.
• pcap dosyaları: burada mevcut Zip dosyası: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (bittwiste ile açıklanmadığı anonim, orada olduğu gibi ~ 150MB için ayıklar Karşılaştırma için her işletim sistemi istemcisinden bir tane)

Güncelleme 2 - 30 Haziran

Öyleyse Kyle'ın önerisine göre, ctcp ve devre dışı baca boşaltımını etkinleştirdim: TCP Global Parameters

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

Fakat ne yazık ki, verimde değişiklik yok.

Burada bir neden / sonuç sorum var: Grafikler, sunucunun ACK'larında istemciye ayarlanan RWIN değerinde. Windows istemcileriyle, müşterinin sınırlı CWIN’inin bu arabellek doldurulmasını bile önlediği için Linux’un bu değeri bu düşük noktadan daha fazla ölçeklemediğini düşünüyorum. Linux'un RWIN'i yapay olarak sınırlandırmasının başka bir nedeni olabilir mi?

Not: Bu cehennem için ECN'yi açmayı denedim; ama değişiklik yok, orada.

Güncelleme 3 - 31 Haziran.

Sezgisel tarama ve RWIN otomatik ayarlama işlevini devre dışı bıraktıktan sonra değişiklik yok. Functioanlity tweaks viadevice manager sekmelerini açığa çıkaran bir yazılımla Intel ağ sürücülerini en son (12.10.28.0) sürümüne yükseltin. Kart bir 82579V Chipset onboard NIC'dir - (Realtek veya diğer satıcılara sahip müşterilerden biraz daha test yapacağım)

Bir an için NIC'e odaklanarak, aşağıdakileri denedim (Çoğunlukla sadece olası suçluları dışlamak):

• Alma arabelleklerini 256'dan 2k'ye ve arabellekleri 512'den 2k'ye çıkar (Her ikisi de maksimumda) - Değişiklik yok
• Tüm IP / TCP / UDP sağlama toplamı boşaltmasını devre dışı bıraktı. - Değişiklik yok.
• Engelli Büyük Gönderme Boşaltma - Nada.
• IPv6'yı kapattı, QoS planlaması - Nowt.

Güncelleme 3 - 3 Temmuz

Linux sunucu tarafını ortadan kaldırmaya çalışırken, bir Server 2012R2 örneği başlattım ve iperf(cygwin binary) ve NTttcp kullanarak testleri tekrarladım .

Bununla birlikte iperf, bağlantının ~ 5Mbit / s'nin ötesine ölçeklenmesi -w1miçin her iki tarafta da açıkça belirtmem gerekiyordu . (Bu arada, kontrol edilebiliyordum ve 91 ms gecikmeyle ~ 5Mbit'lik BDP neredeyse tam 64kb. Limiti belirle ...)

Ntttcp ikili dosyaları şimdi böyle bir sınırlama gösterdi. Kullanılması ntttcpr -m 1,0,1.2.3.5sunucuda ve ntttcp -s -m 1,0,1.2.3.5 -t 10istemci üzerinde, çok daha iyi verim görebilirsiniz:

Copyright Version 5.28
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8MB / s, açıkça büyük pencerelerle aldığım seviyelere yerleştiriyor iperf. İşin garibi olsa da, 1273 tamponda 80MB = tekrar 64 kb tamponu. Bir başka wireshark, sunucudan geri dönen iyi, değişken bir RWIN'i gösterir (Ölçek faktörü 256), müşterinin yerine getirdiği görülüyor; belki de ntttcp gönderme penceresini yanlış rapor ediyordur.

Güncelleme 4 - 3 Temmuz

@ Karyhead'in isteği üzerine biraz daha test yaptım ve birkaç tane daha yaka yakaladım, burada: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

• Her iperfikisi de Windows’tan önceki Linux sunucusundan aynı Linux sunucusuna (1.2.3.4): 128k Soket boyutu ve varsayılan 64k penceresine sahip bir tane (tekrar ~ 5Mbit / s ile sınırlandırılır) ve 1 MB gönderme penceresi ve varsayılan 8kb soket ile bir tane daha boyut. (daha yüksek ölçekler)
• Bir ntttcpSunucu 2012R2 EC2 örneği (1.2.3.5) için aynı Windows istemciden iz. Burada, verim iyi ölçeklenir. Not: NTttcp, test bağlantısını açmadan önce 6001 numaralı bağlantı noktasında garip bir şey yapar. Orada neler olduğundan emin değilim.
• Bir FTP veri izi, /dev/urandomCygwin'i kullanarak yaklaşık aynı linux ana bilgisayara 20 MB yükleyerek (1.2.3.6) ncftp. Yine sınırı var. Kalıp, Windows Filezilla kullanılarak aynıdır.

iperfTampon uzunluğunu değiştirmek, zaman dizisi grafiğindeki beklenen farkı yaratır (çok daha fazla dikey bölüm), ancak gerçek verimlilik değişmez.

Windows 7/8 istemcilerinizde Bileşik TCP (CTCP) özelliğini etkinleştirmeyi denediniz mi?

Lütfen oku:

Yüksek BDP İletimi için Gönderen Tarafı Performansını Artırma

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

Bu algoritmalar küçük BDP'ler için daha iyi çalışır ve daha küçük boyutta pencere alma. Ancak, büyük bir alma penceresi boyutuna ve büyük bir BDP'ye sahip , örneğin 100ms'lik bir gidiş-dönüş süresine sahip yüksek hızlı bir WAN bağlantısı üzerinde bulunan iki sunucu arasında veri çoğaltma gibi bir TCP bağlantınız olduğunda , bu algoritmalar gönderme penceresini arttırmaz. bağlantının bant genişliğini tamamen kullanabilecek kadar hızlı .

Bu durumlarda TCP bağlantılarının bant genişliğini daha iyi kullanmak için, Yeni Nesil TCP / IP yığını Bileşik TCP (CTCP) içerir. CTCP, daha büyük agresif pencere ebadı ve BDP'lere sahip bağlantılar için gönderme penceresini daha agresif bir şekilde arttırır . CTCP, gecikme değişimlerini ve kayıplarını izleyerek bu tür bağlantılarda verimi en üst düzeye çıkarmaya çalışır. Ek olarak, CTCP, davranışının diğer TCP bağlantılarını olumsuz yönde etkilememesini sağlar.

...

CTCP, Windows Server 2008 çalıştıran bilgisayarlarda varsayılan olarak etkindir ve Windows Vista çalıştıran bilgisayarlarda varsayılan olarak devre dışı bırakılmıştır. CTCP'yi netsh interface tcp set global congestionprovider=ctcpkomutla etkinleştirebilirsiniz . CTCP'yi netsh interface tcp set global congestionprovider=nonekomutla devre dışı bırakabilirsiniz .

Düzenle 30.06.2014

CTCP gerçekten "açık" olup olmadığını görmek için

> netsh int tcp show global

yani

PO dedi ki:

Bunu doğru anlarsam, bu ayar ulaşabileceği maksimum boyut yerine tıkanıklık penceresinin büyütülme oranını artırır.

CTCP agresif bir şekilde gönderme penceresini artırır

http://technet.microsoft.com/en-us/library/bb878127.aspx

Bileşik TCP

Gönderen bir TCP eşinin ağı ezmesini engelleyen mevcut algoritmalar yavaş başlangıç ​​ve tıkanıklık önleme olarak bilinir. Bu algoritmalar, başlangıçta bağlantı hakkında veri gönderirken ve kaybedilen bir segmentten kurtarırken gönderen penceresi olarak bilinen gönderen gönderebilecek segment sayısını artırır. Yavaş başlatma, alınan her bir onay kesimi için (Windows XP ve Windows Server 2003'te TCP için) ya da onaylanan her kesim için (Windows Vista ve Windows Server 2008'de TCP için) gönderme penceresini bir tam TCP kesimi kadar artırır. Tıkanıklıktan kaçınma, kabul edilen her bir veri penceresi için gönderme penceresini bir tam TCP segmentiyle arttırır.

Bu algoritmalar, LAN medya hızları ve daha küçük TCP pencere boyutları için işe yarar. Bununla birlikte, büyük bir alma penceresi boyutuna ve büyük bir bant genişliği gecikme ürününe (yüksek bant genişliği ve yüksek gecikme) sahip bir TCP bağlantınız varsa, örneğin, 100 ms'lik bir gidiş-dönüş ile yüksek hızlı WAN bağlantısı üzerinde bulunan iki sunucu arasında veri kopyalama zaman, bu algoritmalar gönderme penceresini bağlantının bant genişliğini tamamen kullanacak kadar hızlı arttırmazlar. Saniyede 1 Gigabit (Gbps) 100 msn gidiş-dönüş süresi (RTT) ile bağlantıyı WAN üzerindeki Örneğin, bu olabilir gönderme pencere başlangıçta yükselmesi için bir saat kadar sürebilir alıcı tarafından reklamı yapılan büyük pencere boyutu ve Kayıp segmentleri olduğunda kurtarmak için.

Bu durumlarda TCP bağlantılarının bant genişliğini daha iyi kullanmak için , Yeni Nesil TCP / IP yığını Bileşik TCP (CTCP) içerir. CTCP, daha büyük agresif pencere boyutu ve büyük bant genişliği gecikmeli ürünleri olan bağlantılar için gönderme penceresini daha agresif bir şekilde arttırır. CTCP, gecikme değişimlerini ve kayıplarını izleyerek bu tür bağlantılarda verimi en üst düzeye çıkarmaya çalışır . CTCP ayrıca davranışının diğer TCP bağlantılarını olumsuz yönde etkilememesini sağlar.

Microsoft'ta dahili olarak yapılan testlerde, 50ms RTT ile 1 Gbps bağlantı için büyük dosya yedekleme süreleri neredeyse yarı yarıya düşürüldü. Daha büyük bant genişliği gecikmeli ürüne sahip bağlantılar daha iyi performansa sahip olabilir. CTCP ve Alma Penceresi Otomatik Ayarlama, daha fazla bağlantı kullanımı için birlikte çalışır ve büyük bant genişliği gecikmeli ürün bağlantıları için önemli performans kazanımlarına neden olabilir.

Sorunu Açıklamak:

TCP'nin iki penceresi vardır:

• Alma penceresi: Tamponda ne kadar bayt kaldı. Bu, alıcı tarafından dayatılan akış kontrolüdür. TCP üstbilgisindeki pencere boyutu ve pencere ölçeklendirme faktöründen oluştuğu için alma penceresinin boyutunu wireshark'ta görebilirsiniz. TCP bağlantısının her iki tarafı da alma pencerelerinin reklamını yapar, ancak genellikle umursadığınız, verilerin büyük kısmını alandır. Sizin durumunuzda, istemci sunucuya yüklediği için bu "sunucu" dur.
• Tıkanıklık penceresi. Bu, Gönderen tarafından uygulanan akış kontrolüdür. Bu işletim sistemi tarafından korunur ve TCP başlığında görünmez. Verilerin ne kadar hızlı gönderileceğini oranı kontrol eder.

Sağladığınız yakalama dosyasında. Alma arabelleğinin asla taşmadığını görebiliriz:

Analizim gönderenin yeterince hızlı göndermemesidir, çünkü gönderim penceresi (diğer bir deyişle kontrol kontrolü penceresi) alıcının RWIN'ini karşılayacak kadar açılmaz. Kısacası, alıcı "Bana Daha Fazla Ver" der ve Windows gönderen olduğunda yeterince hızlı göndermez.

Bu, yukarıdaki grafikte RWIN'in açık kalması ve 0,09 saniyelik gidiş-dönüş süresi ve ~ 500,000 baytlık bir RWIN ile, bant genişliği gecikme ürününe göre maksimum bir verim beklediğimizi göstermektedir (500000). /0.09) * 8 = ~ 42 Mbit / s (ve Linux yakalamanızda sadece ~ 5 kazanıyorsunuz).

Nasıl düzeltilir?

Bilmiyorum. interface tcp set global congestionprovider=ctcpbana yapılacak doğru şey gibi geliyor çünkü gönderme penceresini artıracak (tıkanıklık penceresi için başka bir terim). Bunun işe yaramadığını söyledin. Yani sadece emin olmak için:

1. Bunu etkinleştirdikten sonra yeniden başlattınız mı?
2. Baca boşaltması açık mı? Belki bir deney olarak kapatmayı deneyin. Bu etkin olduğunda tam olarak neyin boşa gittiğini bilmiyorum, ancak gönderme penceresini denetlemek onlardan biriyse, bu etkin olduğunda tıkanıklık sağlayıcısının hiçbir etkisi olmaz ... Sadece tahmin ediyorum ...
3. Ayrıca, bunun Windows 7 öncesi olabileceğini düşünüyorum, ancak HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters içindeki DefaultSendWindow ve DefaultReceiveWindow adlı iki kayıt defteri anahtarını ekleyip çalmayı deneyebilirsiniz. Bu bile işe yararsa, muhtemelen ctcp kapalı olmuştur.
4. Yine başka bir tahmin, kontrol etmeyi deneyin netsh interface tcp show heuristics. Bunun RWIN olabileceğini düşünüyorum, ama söylemedi, bu yüzden belki de gönderme penceresini etkilemesi durumunda bunu devre dışı bırakarak / etkinleştirerek oynayabiliriz.
5. Ayrıca, test istemcinizde sürücülerinizin güncel olduğundan emin olun. Belki bir şey sadece bozuldu.

Tüm bu deneyleri, ağ sürücülerinin bazı şeyleri yeniden yazma / değiştirme yapma olasılığını ortadan kaldırmak için başlatmak üzere tüm boşaltma özellikleriyle denerim (boşaltma devre dışı bırakılırken göz CPU'yu saklayın). TCP_OFFLOAD_STATE_DELEGATED yapı en azından CWnd yük boşaltma en azından mümkün olduğunu ima etmek gibi görünüyor.

@Pat ve @Kyle tarafından burada bazı harika bilgiler var. Kesinlikle @ Kyle'ın TCP alma ve gönderme pencerelerinin açıklamasına dikkat edin , bunun çevresinde bazı karışıklıklar olduğunu düşünüyorum. Meseleleri daha da karıştırmak için, iperf "TCP penceresi" -wterimini, alma, gönderme veya genel kayar pencere açısından belirsiz bir terim olan ayarlarla kullanır . Aslında, -c(istemci) örneği için soket gönderme arabelleğini ve -s(sunucu) örneği üzerinde soket alma arabelleğini ayarlar . İçinde src/tcp_window_size.c:

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

Kyle'ın da belirttiği gibi, sorun Linux kutusundaki alıcı penceresiyle değil, gönderen gönderen pencereyi yeterince açmıyor. Yeterince hızlı açılmadığı için değil, sadece 64k.

Windows 7'deki varsayılan soket tampon boyutu 64k'dir. İşte dokümantasyonda MSDN’de verim ile ilgili soket tampon büyüklüğü hakkında ne yazıyor?

Windows soketlerini kullanarak bir TCP bağlantısı üzerinden veri gönderirken, en yüksek verimi elde etmek için TCP'de yeterli miktarda verinin (henüz gönderilmiş ancak henüz onaylanmadı) saklanması önemlidir. TCP bağlantısı için en iyi verimi elde etmek için olağanüstü veri miktarı için ideal değer, ideal gönderme listesi (ISB) olarak adlandırılır. ISB değeri, TCP bağlantısının bant genişliği gecikmeli ürününün ve alıcının reklamı yapılan alım penceresinin (ve kısmen ağdaki tıkanıklık miktarının) bir fonksiyonudur.

Tamam, falan filan, Şimdi başlıyoruz:

Bir seferde bir engelleme yapan veya engellemeyan gönderme isteği yapan uygulamalar, makul bir verimlilik elde etmek için genellikle Winsock tarafından dahili gönderme arabelleğine dayanır. Belirli bir bağlantı için gönderim tamponu sınırı SO_SNDBUF soket seçeneği ile kontrol edilir. Engelleme ve engelleme yapmayan gönderme yöntemi için gönderme arabelleği sınırı, TCP'de ne kadar verinin üstün tutulduğunu belirler . Bağlantının ISB değeri gönderme arabelleği sınırından büyükse, bağlantıda elde edilen verimlilik optimum olmaz.

64k penceresini kullanarak en yeni iperf testinizin ortalama verimi 5.8 Mbps'dir. Bu , Wireshark'taki İstatistikleri> Özet . Muhtemelen, iperf, 5.7 Mbps olan TCP veri çıkışını saymaktadır. FTP testiyle de aynı performansı görüyoruz, ~ 5.6Mbps.

64k gönderme tamponu ve 91ms RTT ile teorik verim .... 5.5Mbps. Benim için yeterince yakın.

1MB pencere iperf testinize bakarsak, işlem 88.2Mbps'dir (sadece TCP verileri için 86.2Mbps). 1 MB pencereli teorik giriş 87.9 Mbps'dir. Yine, hükümet çalışmaları için yeterince yakın.

Bunun gösterdiği şey, gönderme soketi tamponunun doğrudan gönderme penceresini kontrol ettiği ve diğer taraftan alma penceresi ile birleştiğinde verimi kontrol ettiğidir. Reklamı yapılan alma penceresi odaya sahip, bu nedenle alıcı ile sınırlı değiliz.

Bekle, peki bu otomatik ayarlama işi? Windows 7 bu şeyleri otomatik olarak işlemez mi? Daha önce de belirtildiği gibi, Windows alma penceresinin otomatik olarak ölçeklenmesini işlemektedir fakat aynı zamanda gönderme tamponunu dinamik olarak da kullanabilir. MSDN sayfasına geri dönelim:

TCP için dinamik gönderme arabelleği, Windows 7 ve Windows Server 2008 R2'de eklenmiştir. Varsayılan olarak, bir uygulama akış soketinde SO_SNDBUF soketi seçeneğini ayarlamadıkça, TCP için dinamik gönderme arabelleği etkinleştirilir.

iperf SO_SNDBUF, -wseçeneği kullanırken kullanır , bu nedenle dinamik gönderme arabelleği devre dışı bırakılır. Ancak, kullanmazsanız, -wo zaman kullanmaz SO_SNDBUF. Dinamik gönderme arabelleği varsayılan olarak açık olmalıdır, ancak şunları kontrol edebilirsiniz:

netsh winsock show autotuning

Belgeler şunları devre dışı bırakabileceğinizi söylüyor:

netsh winsock set autotuning off

Ama bu benim için işe yaramadı. Kayıt defteri değişikliği yapıp bunu 0'a ayarlamam gerekiyordu:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

Bunu devre dışı bırakmanın yardımcı olacağını sanmıyorum; bu sadece bir FYI.

Neden alma penceresindeki bol miktarda yer bulunan bir Linux kutusuna veri gönderirken gönderme tamponu varsayılan 64k değerinin üzerinde ölçeklenmiyor? Harika soru Linux çekirdeğinde ayrıca otomatik ayar yapan bir TCP yığını vardır. T-Pain ve Kanye'nin birlikte otomatik ayar düetlemesi yapması gibi, kulağa hoş gelmiyor olabilir. Belki de bu iki otomatik ayarlama TCP yığınının birbiriyle konuşmasıyla ilgili bir sorun var.

Başka birinin de tıpkı sizinki gibi bir sorunu vardı ve varsayılan gönderme arabellek boyutunu artırmak için bir kayıt defteri düzenlemesiyle düzeltmeyi başardı. Maalesef, bu artık işe yaramadı, en azından denediğimde benim için yapmadı.

Bu noktada, sınırlayıcı faktörün Windows ana bilgisayarındaki gönderme arabellek boyutunun açık olduğunu düşünüyorum. Dinamik olarak doğru bir şekilde büyüyemediği göz önüne alındığında, ne yapmalı?

Yapabilirsin:

• Gönderme arabelleğini, yani pencere seçeneğini ayarlamanıza izin veren uygulamaları kullanın
• Yerel bir Linux proxy kullan
• Uzak bir Windows proxy kullan?
• Microsofhahahahahahahaha ile bir dava aç
• bira

Feragatname: Bu konuyu araştırmak için çok uzun zaman harcadım ve bu bilgim ve go-fu ile ilgili en iyisi. Ama annemin mezarı üzerine yemin etmem (hala hayatta).

TCP yığınını ayarladıktan sonra, Winsock katmanında hala bir tıkanıklık olabilir. Winsock'u (kayıt defterindeki Yardımcı İşlev Sürücüsü) yapılandırmanın Windows 7'de yükleme hızları (sunucuya veri itme) için büyük bir fark yarattığını tespit ettim. Microsoft, engellemeyen soketler için TCP otomatik ayarında bir hata olduğunu onayladı - tarayıcıların kullandığı yuva türü ;-)

DefaultSendWindow için DWORD anahtarı ekleyin ve BDP veya daha yükseğe ayarlayın. 256000 kullanıyorum.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

İndirmeler için Winsock ayarını değiştirmek yardımcı olabilir - DefaultReceiveWindow için bir anahtar ekleyin.

İstemci ve sunucu soketi arabellek boyutlarını ayarlamak için Fiddler Proxy ve komutlarını kullanarak çeşitli soket seviyesi ayarları deneyebilirsiniz :

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF

Tüm analizleri cevaplarda okuduktan sonra, bu problem sizin Windows7 / 2008R2 ve Windows 6.1 işletim sistemlerini kullanıyor gibi gözüküyor.

Windows 6.1'deki ağ yığını (TCP / IP & Winsock) korkunç derecede hatalıydı ve Microsoft'un 6.1'in ilk sürümünden bu yana uzun yıllar süren düzeltmelerde ele aldığı bir dizi hata ve performans sorununa sahipti.

Bu düzeltmeleri uygulamanın en iyi yolu, support.microsoft.com adresindeki tüm ilgili sayfaları el ile elemek ve ağ yığını düzeltmelerinin LDR sürümlerini el ile istemek ve indirmektır (bunlardan düzinelerce vardır).

İlgili düzeltmeleri bulmak için aşağıdaki arama sorgusu ile www.bing.com adresini kullanmalısınız. site:support.microsoft.com 6.1.7601 tcpip.sys

Ayrıca LDR / GDR düzeltme trenlerinin Windows 6.1'de nasıl çalıştığını anlamanız gerekir.

Genelde Windows 6.1 için kendi LDR düzeltmeleri listemi (sadece ağ yığını düzeltmeleri değil) sürdürmek için kullandım ve daha sonra bu düzeltmeleri karşılaştığım herhangi bir Windows 6.1 sunucuya / istemciye proaktif olarak uyguladım. Yeni LDR düzeltmelerini düzenli olarak kontrol etmek çok zaman alan bir işti.

Neyse ki, Microsoft, daha yeni işletim sistemi sürümleriyle LDR düzeltmelerinin uygulanmasını durdurdu ve şimdi Microsoft'tan otomatik güncelleme hizmetleriyle düzeltmeler yapıldı.

GÜNCELLEME : Windows7SP1'deki birçok ağ hatalarına yalnızca bir örnek - https://support.microsoft.com/en-us/kb/2675785

GÜNCELLEME 2 : İkinci SYN paketinin yeniden gönderilmesinden sonra Pencere ölçeklendirmesini zorlamak için bir netsh anahtarı ekleyen başka bir düzeltme (varsayılan olarak, 2 SYN paketi yeniden gönderildikten sonra pencere ölçeklendirmesi devre dışı bırakılır) https://support.microsoft.com/en- tr / kb / 2780879

Bunun biraz daha eski bir yazı olduğunu görüyorum ama başkalarına yardımcı olabilir.

Kısacası "Alma Penceresi Otomatik Ayarlama" özelliğini etkinleştirmeniz gerekir:

netsh int tcp set global autotuninglevel=normal

CTCP yukarıda etkin olmayan hiçbir şey ifade etmiyor.

"Pencere Otomatik Ayarlama Alma" seçeneğini devre dışı bırakırsanız, yüksek geniş bant bağlantılarında uzun RTT'ler üzerinde olumsuz etkisi olan 64KB paket boyutunda sıkışıp kalacaksınız. Ayrıca "sınırlı" ve "son derece kısıtlamalı" seçeneğini deneyebilirsiniz.

Çok iyi referans: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

Windows İstemcilerinde de benzer bir sorun yaşıyordum (Windows 7). Nagle algoritmasını, TCP Kanal Boşaltma ve tonlarca diğer TCP ile ilgili ayar değişikliklerini devre dışı bırakarak, yaşadığınız tüm hata ayıklama işlemlerinin üzerinden geçtim. Bunların hiçbirinin etkisi olmadı.

Benim için nihayet düzelttiği, AFD hizmetinin kayıt defterindeki varsayılan gönderme penceresini değiştirmekti. Sorun afd.sys dosyasıyla ilişkili görünüyor. Birkaç müşteriyi test ettim, bazıları yavaş yükleme yaptı, bazıları yapmadı, ancak hepsi Windows 7 makineleriydi. Yavaş davranışı sergileyen makineler aynı AFD.sys sürümüne sahipti. Kayıt defteri geçici çözümü, AFD.sys dosyasının belirli sürümlerine sahip bilgisayarlar için gereklidir (üzgünüz, sürüm # 'yi hatırlamayın).

HKLM \ CurrentControlSet \ Services \ AFD \ Parameters

Ekle - DWORD - DefaultSendWindow

Değer - Ondalık - 1640960

Bu değer burada bulduğum bir şeydi: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Uygun değeri kullanmayı düşünüyorum, kendiniz kullanarak kendiniz hesaplamanız gerekir:

Örneğin. Reklam Yüklenen: 15 Mbps = 15.000 Kbps

(15000/8) * 1024 = 1920000

Anladığım kadarıyla, istemci yazılımı genel olarak bu ayarı kayıt defterinde geçersiz kılmalı, ancak bunu yapmazsa, varsayılan değer kullanılır ve görünüşe göre AFD.sys dosyasının bazı sürümlerinde varsayılan değer çok düşüktür.

Çoğunlukla MS ürünlerinin yavaş yükleme problemi olduğunu (IE, Mini yönlendirici (WebDAV), Windows Explorer aracılığıyla FTP, vb ...) farkettim. 3. parti yazılımı kullanırken (örn. Filezilla) aynı yavaşlamalara sahip değildim. .

AFD.sys, tüm Winsock bağlantılarını etkiler, bu nedenle bu düzeltme FTP, HTTP, HTTPS, vb. İçin geçerli olmalıdır ...

Ayrıca, bu düzeltme yukarıda da bir yerde listelenmiştir, bu yüzden herhangi biri için işe yararsa kredi almak istemiyorum, ancak bu konuda bu konu hakkında çok fazla bilgi vardı.

Eh, ben de benzer bir durumla karşılaştım ( buradaki sorum var ) ve sonunda TCP ölçekleme sezgiselini devre dışı bırakmak, otomatik ayarlama profilini manuel olarak ayarlamak ve CTCP'yi etkinleştirmek zorunda kaldım:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok. 

Yorum yapmak için yeterli puanım yok, bu yüzden onun yerine "cevap" göndereceğim. Benzer / özdeş bir sorun gibi görünüyorum ( burada sunucuya sorulan soruya bakınız ). Benim (ve muhtemelen senin) sorunum, Windows'taki iperf istemcisinin gönderme tamponu. 64 KB'nin üzerinde büyümez. Windows'un, işlem tarafından açıkça boyutlandırılmadığında arabelleği dinamik olarak büyütmesi gerekiyor. Ancak bu dinamik büyüme gerçekleşmiyor.

"Yavaş" Windows durumunuz için 500.000 bayta açılan pencereyi gösteren pencere ölçekleme grafiğinizden emin değilim. Grafiğin, 5 Mbps ile sınırlı kalmanız koşuluyla yalnızca ~ 64,000 bayta açık olduğunu görmeyi umuyordum.

Bu büyüleyici bir iplik ve uzun yağ borularındaki verimi test etmek için Win7 / iperf kullandığım sorunları tam olarak eşleştiriyor.

Windows 7'nin çözümü hem iperf sunucusunda hem de istemcide aşağıdaki komutu uygulamaktır.

netsh arabirimi tcp genel global ayarlama tevp = deneysel

Not: Bunu yapmadan önce, autotuning'in mevcut durumunu kaydettiğinizden emin olun:

netsh arabirimi tcp global göster

Pencere Otomatik Ayar Seviyesi Alma: devre dışı

Ardından borunun her bir ucundaki iperf sunucusunu / istemcisini çalıştırın.

Testlerinizi takiben otomatik ayarlama değerini sıfırlayın:

netsh arabirimi tcp genel global ayarlama tevp =

   autotuninglevel - One of the following values:
                     disabled: Fix the receive window at its default
                         value.
                     highlyrestricted: Allow the receive window to
                         grow beyond its default value, but do so
                         very conservatively.
                     restricted: Allow the receive window to grow
                         beyond its default value, but limit such
                         growth in some scenarios.
                     normal: Allow the receive window to grow to
                         accomodate almost all scenarios.
                     experimental: Allow the receive window to grow
                         to accomodate extreme scenarios.