Rozmiary pakietów w strumieniu TCP

Jestem ruchem sieciowym i chcę podzielić każdą sesję TCP na serię żądań i odpowiedzi (protokoły, nad którymi pracuję, działają w ten sposób, np. HTTP lub SSL).

Miałem proste założenie (ignorowanie nieporządku i ponowne wysyłanie pakietów) - biorąc pod uwagę fragment danych, które należy wysłać, zostaną one wysłane przy użyciu możliwie największych pakietów, a ostatni pakiet będzie albo mniejszy niż maksymalny rozmiar, albo będzie śledzony przez pakiet z drugiej strony (ignorowanie pustych pakietów ACK). Tak więc w sesji HTTP oczekuję, że zobaczę coś takiego (ponownie, bez uwzględnienia acks) -

Pakiet 1 - Poproś o „Get ...”

Pakiet 2 - Odpowiedź, rozmiar 1434

Pakiet 3 - Odpowiedź, rozmiar 1434

Pakiet 4 - Odpowiedź, rozmiar 1434

Pakiet 5 - Odpowiedź, rozmiar 500

Tak się dzieje na większości sesji, jednak widziałem przynajmniej jedną okazję, która wyglądała

Pakiet 1 - Poproś o „Get ...”

Pakiet 2 - Odpowiedź, rozmiar 1434

Pakiet 3 - Odpowiedź, rozmiar 1080

Pakiet 4 - Odpowiedź, rozmiar 1434

Pakiet 5 - Odpowiedź, rozmiar 500

Brak retransmisji, pakiety poza kolejnością lub wyjątkowe opóźnienia na serwerze.

Chcę wiedzieć - co może to spowodować i kiedy to nastąpi? Jak błędne jest moje założenie?

AKTUALIZACJA

I umieścić plik przykład pcap tutaj

AKTUALIZACJA 2

W tym tsharkzrzut z odpowiednimi polami ...

$ 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 

Warstwa TCP wykorzystuje algorytm Nagle do buforowania ruchu (wysyła mniej dużych pakietów, zamiast więcej małych pakietów ... co czyni go bardziej wydajnym); aplikacja może powiedzieć „wyślij ją teraz”. Widzisz to w nagłówku TCP z flagą zwaną bitem PSH (push). Podczas gdy bit jest ustawiany przez stos, wypychanie odbywa się na żądanie aplikacji.

To jest zamierzone i normalne zachowanie.

Rozmiar pakietu zależy od tego, jak aplikacja i / lub system operacyjny buforuje i wysyła dane sieciowe. Jeśli aplikacja i / lub system operacyjny zdecydują się wysłać dane po tym, jak w buforze znajdzie się 1080 bajtów, pakiet będzie miał 1080 bajtów (plus nagłówki). Może to być wiele powodów. W twoim przypadku musisz zajrzeć do kodu źródłowego serwera WWW i / lub stosu sieciowego systemu operacyjnego.

Rozmiar pakietu jest definiowany przez system operacyjny (ogólnie) i jest związany z buforami, ilością danych dostarczanych przez aplikację itp. Wiele strategii można wykorzystać w celu osiągnięcia maksymalnej wydajności, a czasami wysyłanie mniejszych pakietów może być szybsze niż oczekiwanie na utworzenie większy pakiet.

Czasami liczba uruchomionych aplikacji może wymagać szybszego działania systemu operacyjnego (wysyłanie tego, co do tej pory było w buforze) zamiast nasycania bufora.

Być może możesz podać nam więcej szczegółów na temat scenariusza, z którym pracujesz (np .: system operacyjny serwera, uruchomione na nim aplikacje).

Zasadniczo problem polega na tym, że implementacja TCP nie wie, co aplikacja zrobi dalej. Kiedy aplikacja serwera wykonuje sekwencję zapisów, stos nie wie, czy dotychczas otrzymane zapisy stanowią całą sekwencję, czy tylko jej część.

Przez większość czasu aplikacja serwera zapisuje do bufora szybciej niż stos sieciowy jest w stanie go opróżnić. Bufor jest pełny i wychodzą pełnowymiarowe pakiety.

Ale czasami coś innego spowalnia aplikację serwera. Może czekanie na odczyt dysku na przeciążonej macierzy dyskowej lub coś w tym rodzaju. Bufor opróżnia się, a stos sieciowy musi wybierać między wysyłaniem mniejszego pakietu (większy narzut) lub czekaniem na dane, które mogą nigdy nie nadejść (dodanie opóźnienia).

Jeśli spojrzysz na ramkę 34, zobaczysz, że serwer przesłał bufor 32kB i że bit PSH jest ustawiony. Jeśli spojrzysz na 82, zobaczysz to samo, 32 kB z poprzedniego bitu PSH. Pakiet 52 ma bit PSH, mimo że odpowiedź była mniejsza niż 2 kB.

Bit PSH jest zwykle ustawiany przez stos TCP dla ostatniego segmentu PDU aplikacji zapisanego w sieci. Dlatego aplikacja używa bufora 32kB, a gdy jest dużo danych, zapisuje je jednocześnie do gniazda TCP 32kB. Kiedy danych jest mniej niż w ramkach 51-52, dzieje się tak dlatego, że aplikacja zapisała ten rekord jako pierwszy w odpowiedzi i miał on tylko 1820 bajtów.

Zauważ, że aplikacja, o której mówię, może w rzeczywistości nie być samą aplikacją serwera, ale jakimś oprogramowaniem pośrednim, takim jak Java Virtual Machine (JVM) lub czymkolwiek. Z treści danych nie wynika jasno, dlaczego wysłano PDU o wielkości 1820 bajtów, być może bufor 32kB nie był wtedy dostępny?

Chodzi o to, że nie powinno to mieć znaczenia, nie ma istotnej kary za wydajność.