Розміри пакетів у потоці TCP

10

Я є мережевим трафіком і хочу поділити кожен сеанс TCP на ряд запитів і відповідей (протоколи, з якими я працюю, усі вони працюють таким чином, як HTTP або SSL).

У мене було просте припущення (ігнорування пакетів, що не вийшли з ладу і обурені пакетами) - з огляду на шматок даних, який потрібно надіслати, він буде надісланий за допомогою найбільших можливих пакетів, а останній пакет буде або меншим за максимальний розмір, або буде дотримуватися пакетом з іншого боку (ігноруючи порожні пакети ACK). Тож на сесії HTTP я очікую, що я побачу щось на зразок (знову ж таки, нехтування акками) -

Пакет 1 - Запит "Отримати ..."

Пакет 2 - Відповідь, розмір 1434

Пакет 3 - Відповідь, розмір 1434

Пакет 4 - Відповідь, розмір 1434

Пакет 5 - Відповідь, розмір 500

Це те, що я отримую на більшості сесій, проте я побачив принаймні один випадок, який виглядав так

Пакет 1 - Запит "Отримати ..."

Пакет 2 - Відповідь, розмір 1434

Пакет 3 - Відповідь, розмір 1080

Пакет 4 - Відповідь, розмір 1434

Пакет 5 - Відповідь, розмір 500

Ніяких повторних передач, пакетів поза замовленням тут або відсутні виняткові затримки на сервері.

Хочу знати - що може спричинити це і коли це станеться? Наскільки неправильне моє припущення?

ОНОВЛЕННЯ

Я поклав файл приклад PCAP тут

ОНОВЛЕННЯ 2

Включаючи tsharkдамп із відповідними полями ...

$ 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

— Вадим
джерело

Причин може бути так багато ... Розмір вікна може бути занадто малим (хоча це дуже малоймовірно у вашому випадку), може бути недостатньо даних для надсилання (чи є вихід, створений сценарієм?), Програмне забезпечення, що генерує дані, може явно промили його тощо.

— Сандер Стеффан

@SanderSteffann, розмір вікна не здається релевантним, аки надходять через досить регулярні проміжки часу. Вся відповідь - це javascript, тому я не думаю, що він генерується іншим сценарієм.

— Вадим

@vadim, чи можете ви, будь ласка, опублікувати скріншот або краще гіперпосилання на pcap з корисним навантаженням 1080 байт?

— Майк Пеннінгтон

@MikePennington - дякую за ваш внесок, я надішлю посилання на файл pcap через кілька годин.

— Вадим

@MikePennington - я додав посилання на файл pcap, який демонструє це.

— Вадим

6

Рівень TCP використовує алгоритм Nagle для буферизації трафіку (він надсилає менше великих пакетів, а не більше маленьких пакетів ... роблячи це більш ефективним); є додаток, щоб сказати "надіслати зараз". Ви бачите, що в заголовку TCP з прапором називається біт PSH (push). Поки біт встановлюється стеком, натискання виконується на вимогу програми.

Так це задумано і нормальна поведінка.

— fredpbaker
джерело

Точка уточнення ... Програми не мають прямого контролю над бітом PSH ...

— Майк Пеннінгтон

Цілком вірно, було те, що ПОДАЄТЬСЯ зробити це в оригінальному RFC, і що

— БЕЗ РОБИТИ

подивившись на pcap, дуже малоймовірно, що веб-сервер встановив PSH на трафік ОП

— Майк Пеннінгтон

3

Розмір пакету залежить від того, як програма та / або ОС буферизує та передає мережеві дані. Якщо програма та / або ОС вирішили надіслати дані після того, як 1080 байтів знаходяться в буфері, пакет буде становити 1080 байт (плюс заголовки). Для цього може бути багато причин. У вашому випадку вам доведеться шукати вихідний код веб-сервера та / або мережевий стек ОС.

— Себастьян Візінгер
джерело

Я бачу безліч пакетів з максимальним розміром, і лише цей з меншим розміром, тому це не за замовчуванням якесь. Можливо, це був хікет сервера - він застряг на чомусь іншому для затримки, що було достатньо для того, щоб мережевий стек вирішив надіслати те, що було в буфері?

— Вадим

Звичайно, могло бути що завгодно. Немає способу сказати без налагодження сервера та ОС, на якій він працює. Але хвилювати ІМХО нічого не варто.

— Себастьян Візінгер

Я не насторожений, це просто здалося дивним, і я хотів з’ясувати, чи є в ньому більше, ніж це.

— Вадим

1

Якщо у вас є проводка, ознайомтеся з заголовком TCP 1080 пакетів для біта PSH (push). Тобто стек додатків говорить, що зараз надсилайте ці дані.

— fredpbaker

1

Дивіться вище, його стек TCP у більшості випадків

— fredpbaker

1

Розмір пакету визначається ОС (загалом) і пов'язаний з буферами, кількістю даних, що надаються додатком тощо. Для досягнення максимальної продуктивності можна використовувати багато стратегій, а іноді надсилання менших пакетів може бути швидше, ніж чекати створення більший пакет.

Іноді кількість запущених програм може вимагати, щоб ОС була швидшою (надсилайте все, що є в буфері поки що) замість насичення буфера.

Можливо, ви могли б дати більш детальну інформацію про сценарій, з яким працювали (напр .: ОС сервера, програми, що працюють на ньому).

— woliveirajr
джерело

0

По суті, проблема полягає в тому, що реалізація TCP не знає, що буде робити далі. Коли серверне додаток робить послідовність запису стека, не відомо, чи отримані ним записи поки що є цілою послідовністю або лише її частиною.

Більшу частину часу серверна програма робить записування в буфер швидше, ніж мережевий стек здатний випорожнити його. Так буфер заповнений і виходять повнорозмірні пакети.

Але іноді щось інше уповільнює серверну програму. Можливо, чекаєте, коли диск буде прочитаний на перевантаженому дисковому масиві чи щось таке. Тож буфер спорожняється, і мережевий стек повинен вибирати між відправленням меншого пакету (більше накладних витрат) або очікуванням даних, які ніколи не прийдуть (додавання затримки).

— Пітер Грін
джерело

0

Якщо ви подивитесь на кадр 34, ви побачите, що сервер передав 32 кБ буфера і що встановлений біт PSH. Якщо ви подивитесь на 82, ви побачите те саме, 32 кБ від попереднього біта PSH. Пакет 52 має біт PSH, хоча відповіді було менше 2 кБ.

Біт PSH зазвичай встановлюється стеком TCP для останнього сегмента PDU програми, записаного в мережу. Таким чином, програма використовує буфер 32 кБ і коли є багато даних, записує її в TCP-розетку 32 кБ за один раз. Коли є менше даних, як у кадрах 51-52, це тому, що програма записувала цей запис першим у відповіді, і це було лише 1820 байт.

Зауважте, що програма, на яку я посилаюсь, насправді може бути не саме серверним додатком, а деяким проміжним програмним забезпеченням, таким як віртуальна машина Java (JVM) або іншим способом. Зі змісту даних незрозуміло, чому було відправлено PDU 1820 байтів, можливо, буфер 32 кБ тоді не був доступний?

Справа в тому, що це не має значення, немає суттєвого штрафу за виконання.

— marctxk
джерело