TCP akışındaki paket boyutları

10

Ben ağ trafiğiyim ve her TCP oturumunu bir dizi istek ve yanıta bölmek istiyorum (HTTP veya SSL gibi bu şekilde çalıştığım protokoller).

Basit bir varsayım vardı (sıra dışı ve yeniden gönderme paketleri yoksay) - gönderilmesi gereken bir veri kümesi verildiğinde, mümkün olan en büyük paketler kullanılarak gönderilecek ve son paket maksimum boyuttan daha küçük olacak veya takip edilecek diğer taraftan bir paket ile (ACK boş paketleri yok sayarak). Bir HTTP oturumunda şöyle bir şey görmeyi bekliyorum (yine, ack'leri göz ardı ederek) -

Paket 1 - "Al ..." iste

Paket 2 - Yanıt, boyut 1434

Paket 3 - Yanıt, boyut 1434

Paket 4 - Yanıt, boyut 1434

Paket 5 - Yanıt, boyut 500

Seansların çoğunda aldığım şey bu, ancak gördüğüm en az bir fırsat var.

Paket 1 - "Al ..." iste

Paket 2 - Yanıt, boyut 1434

Paket 3 - Yanıt, boyut 1080

Paket 4 - Yanıt, boyut 1434

Paket 5 - Yanıt, boyut 500

Yeniden iletim yok, burada sıra dışı paketler veya sunucuda istisnai gecikmeler yok.

Bilmek istiyorum - buna ne neden olabilir ve ne zaman olacak? Varsayım ne kadar yanlış?

GÜNCELLEME

Ben bir örnek pcap dosyasını koymak burada

GÜNCELLEME 2

tsharkİlgili alanlara sahip bir döküm de dahil ...

$ tshark -r http_1082.pcap -T fields -e frame.number -e frame.len \
    -e ip.src -e ip.dst -e tcp.flags.push -e http.request.method \
    -e http.request.uri -e http.response.code | head -n 47
1     66      192.168.1.103    206.33.49.126    0            
2     62      206.33.49.126    192.168.1.103    0            
3     64      192.168.1.103    206.33.49.126    0            
4     411     192.168.1.103    206.33.49.126    1    GET    /money/.element/script/3.0/video/xmp/xmp_playlistapi.js    
5     54      206.33.49.126    192.168.1.103    0            
6     1434    206.33.49.126    192.168.1.103    0            
7     1434    206.33.49.126    192.168.1.103    0            
8     64      192.168.1.103    206.33.49.126    0            
9     1434    206.33.49.126    192.168.1.103    0            
10    1434    206.33.49.126    192.168.1.103    0            
11    1434    206.33.49.126    192.168.1.103    0            
12    64      192.168.1.103    206.33.49.126    0            
13    1434    206.33.49.126    192.168.1.103    0            
14    1434    206.33.49.126    192.168.1.103    0            
15    1434    206.33.49.126    192.168.1.103    0            
16    1434    206.33.49.126    192.168.1.103    0            
17    64      192.168.1.103    206.33.49.126    0            
18    1434    206.33.49.126    192.168.1.103    0            
19    1434    206.33.49.126    192.168.1.103    0            
20    1434    206.33.49.126    192.168.1.103    0            
21    1434    206.33.49.126    192.168.1.103    0            
22    1434    206.33.49.126    192.168.1.103    0            
23    64      192.168.1.103    206.33.49.126    0            
24    1434    206.33.49.126    192.168.1.103    0            
25    1434    206.33.49.126    192.168.1.103    0            
26    1434    206.33.49.126    192.168.1.103    0            
27    1434    206.33.49.126    192.168.1.103    0            
28    1434    206.33.49.126    192.168.1.103    0            
29    1434    206.33.49.126    192.168.1.103    0            
30    64      192.168.1.103    206.33.49.126    0            
31    1434    206.33.49.126    192.168.1.103    0            
32    1434    206.33.49.126    192.168.1.103    0            
33    1434    206.33.49.126    192.168.1.103    0            
34    1082    206.33.49.126    192.168.1.103    1     <------ Packet in question        
35    1434    206.33.49.126    192.168.1.103    0            
36    1434    206.33.49.126    192.168.1.103    0            
37    1434    206.33.49.126    192.168.1.103    0            
38    64      192.168.1.103    206.33.49.126    0            
39    1434    206.33.49.126    192.168.1.103    0            
40    1434    206.33.49.126    192.168.1.103    0            
41    1434    206.33.49.126    192.168.1.103    0            
42    1434    206.33.49.126    192.168.1.103    0            
43    1434    206.33.49.126    192.168.1.103    0            
44    1434    206.33.49.126    192.168.1.103    0            
45    1434    206.33.49.126    192.168.1.103    0            
46    626     206.33.49.126    192.168.1.103    1            200
47    64      192.168.1.103    206.33.49.126    0

— Vadim
kaynak

Bu kadar çok neden olabilir ... Pencere boyutu çok küçük olabilir (sizin durumunuzda pek olası değildir), gönderilecek yeterli veri olmayabilir (çıktı bir komut dosyası tarafından mı üretiliyor?), Verileri üreten yazılım açıkça, vb it temizletmeni

— Sander Steffann

@SanderSteffann, pencere boyutu önemli görünmüyor, acks oldukça düzenli aralıklarla geliyor. Tüm yanıt bir javascript, bu yüzden başka bir komut dosyası tarafından oluşturulan sanmıyorum.

— Vadim

@vadim, bir ekran görüntüsü veya daha iyisi, 1080 bayt yükü ile pcap'e bir köprü gönderebilir misiniz?

— Mike Pennington

@MikePennington - girişiniz için teşekkürler, birkaç saat içinde pcap dosyasına bir bağlantı vereceğim.

— Vadim

@MikePennington - Bunu gösteren bir pcap dosyasına bir bağlantı ekledim.

— Vadim

6

TCP katmanı trafiği arabelleğe almak için Nagle algoritmasını kullanır (daha küçük paketler yerine daha az büyük paketler gönderir ... daha verimli hale getirir); uygulamanın 'şimdi gönder' demesinin bir yolu var. TCP başlığında, PSH (push) bit adı verilen bir bayrak görmektesiniz. Bit yığını tarafından ayarlanırken, itme uygulamanın isteği üzerine yapılır.

Yani bu amaçlanan ve normal davranış.

— fredpbaker
kaynak

Açıklama noktası ... Uygulamaların PSH biti üzerinde doğrudan kontrolü yoktur ...

— Mike Pennington

Oldukça doğru, orijinal RFC'de yapılması gerekiyordu ve

— WOS'un

pcap'a baktıktan sonra, web sunucusunun PSH'yi OP'nin trafiğine ayarlaması pek olası değildir

— Mike Pennington

3

Paket boyutu uygulamanın ve / veya işletim sisteminin ağ verilerini nasıl arabelleğe aldığını ve gönderdiğine bağlıdır. Uygulama ve / veya işletim sistemi arabellekte 1080 bayt sonra veri göndermeye karar verirse, paket 1080 bayt (artı başlıklar) olacaktır. Bunu yapmasının birçok nedeni olabilir. Sizin durumunuzda, web sunucusu kaynak koduna ve / veya işletim sistemi ağ yığınına bakmanız gerekir.

— Sebastian Wiesinger
kaynak

Maksimum boyutta ve yalnızca daha küçük boyutlu paketler görüyorum, bu yüzden bir çeşit varsayılan değil. Bir sunucu hıçkırısı olabilir mi - ağ yığını tamponda ne göndermeye karar vermek için yeterli oldu bir gecikme için başka bir şey takıldı?

— Vadim

Tabii, herhangi bir şey olabilirdi. Sunucuda ve üzerinde çalıştığı işletim sisteminde hata ayıklamadan bunu anlamanın bir yolu yoktur. Ama IMHO hakkında endişelenecek bir şey yok.

— Sebastian Wiesinger

Endişeli değilim, sadece garip görünüyordu ve bundan daha fazlası olup olmadığını öğrenmek istedim.

— Vadim

1

Wireshark'ınız varsa, PSH (push) bit için 1080 paket TCP başlığına bakın. Bu veri yığını şimdi bu veri gönderme diyor.

— fredpbaker

1

Yukarıya bakınız, çoğu durumda TCP yığını

— fredpbaker

1

Paket boyutu işletim sistemi tarafından tanımlanır (genel olarak) ve arabellekler, uygulama tarafından sağlanan veri miktarı vb. daha büyük bir paket.

Bazen çalışan uygulamaların miktarı, işletim sistemini arabelleği doyurmak yerine daha hızlı olmasını (arabelleğe sahip olan her şeyi göndermesini) isteyebilir.

Belki, birlikte çalıştığınız senaryo hakkında bize daha fazla ayrıntı verebilir (örn. Sunucu işletim sistemi, üzerinde çalışan uygulamalar).

— woliveirajr
kaynak

0

Temel olarak, TCP uygulaması uygulamanın ne yapacağını bilmiyor olmasıdır. Sunucu uygulaması bir dizi yazma işlemi yaptığında, yığın şimdiye kadar aldığı yazma işlemlerinin tüm dizilim mi yoksa yalnızca bir kısmı mı olduğunu bilmez.

Çoğu zaman sunucu uygulaması arabelleğe ağ yığınını boşaltabildiğinden daha hızlı yazar. Böylece tampon dolu ve tam boyutlu paketler çıkıyor.

Ancak bazen başka bir şey sunucu uygulamasını yavaşlatır. Belki de aşırı yüklenmiş bir disk dizisinde veya başka bir şeyde okunan bir disk bekleniyor. Bu nedenle, arabellek boşalır ve ağ yığını, daha küçük bir paket göndermek (daha fazla ek yük) veya asla gelmeyecek verileri beklemek (gecikme eklemek) arasında seçim yapmak zorundadır.

— Peter Green
kaynak

0

34. kareye bakarsanız, sunucunun 32kB arabellek ilettiğini ve PSH bitinin ayarlandığını göreceksiniz. 82'ye bakarsanız, önceki PSH bitinden aynı olan 32 kB'yi göreceksiniz. Yanıt 2kB'den az olmasına rağmen 52 numaralı paketin bir PSH biti vardır.

PSH biti genellikle ağa yazılan bir uygulama PDU'sunun son segmenti için bir TCP yığını tarafından ayarlanır. Bu yüzden uygulama 32kB tampon kullanır ve çok fazla veri olduğunda, bunu bir kerede 32kB TCP soketine yazar. 51-52 karelerinde olduğu gibi daha az veri olduğunda, bunun nedeni uygulamanın yanıtta önce bu kaydı yazması ve yalnızca 1820 bayt olmasıdır.

Bahsettiğim uygulamanın aslında sunucu uygulamasının kendisi değil, Java Sanal Makinesi (JVM) veya başka bir ara yazılım olabileceğine dikkat edin. Veri içeriğinden 1820 baytlık PDU'nun neden gönderildiği belli değil, belki o zaman 32kB'lik bir tampon mevcut değildi?

Mesele şu ki önemli değil, önemli bir performans cezası yok.

— marctxk
kaynak