Je fais du trafic réseau et je souhaite diviser chaque session TCP en une série de demandes et de réponses (les protocoles avec lesquels je travaille fonctionnent de cette façon, comme HTTP ou SSL).
J'avais une supposition simple (ignorer les paquets en panne et renvoyés) - étant donné un bloc de données qui doit être envoyé, il sera envoyé en utilisant les plus grands paquets possibles et le dernier paquet sera soit plus petit que la taille maximale, soit suivi par un paquet de l'autre côté (en ignorant les paquets vides ACK). Donc, dans une session HTTP, je m'attends à voir quelque chose comme (encore une fois, sans tenir compte des acks) -
Paquet 1 - Demande "Get ..."
Paquet 2 - Response, taille 1434
Paquet 3 - Response, taille 1434
Paquet 4 - Response, taille 1434
Paquet 5 - Response, taille 500
C'est ce que j'obtiens sur la plupart des séances, mais il y a au moins une occasion que j'ai vue qui ressemblait à
Paquet 1 - Demande "Get ..."
Paquet 2 - Response, taille 1434
Paquet 3 - Réponse, taille 1080
Paquet 4 - Response, taille 1434
Paquet 5 - Response, taille 500
Pas de retransmissions, de paquets en panne ici ou pas de retards exceptionnels sur le serveur.
Je veux savoir - qu'est-ce qui peut provoquer cela et quand cela se produira-t-il? À quel point mon hypothèse est-elle fausse?
METTRE À JOUR
Je mets un exemple de fichier pcap ici
MISE À JOUR 2
Y compris un tsharkvidage avec les champs pertinents ...
$ 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
Réponses:
La couche TCP utilise l'algorithme Nagle pour tamponner le trafic (elle envoie moins de gros paquets, au lieu de plus de petits paquets ... ce qui la rend plus efficace); il existe un moyen pour l'application de dire «envoyez-le maintenant». Vous voyez cela dans l'en-tête TCP avec un indicateur appelé le bit PSH (push). Pendant que le bit est positionné par la pile, le push se fait à la demande de l'application.
Il s'agit donc d'un comportement voulu et normal.
la source
La taille du paquet dépend de la façon dont l'application et / ou les tampons du système d'exploitation et envoient les données réseau. Si l'application et / ou le système d'exploitation décide d'envoyer les données une fois que 1080 octets sont dans la mémoire tampon, le paquet sera de 1080 octets (plus les en-têtes). Il pourrait y avoir de nombreuses raisons pour cela. Dans votre cas, vous devrez rechercher dans le code source du serveur Web et / ou la pile réseau du système d'exploitation.
la source
La taille des paquets est définie par le système d'exploitation (en général) et est liée aux tampons, à la quantité de données fournies par l'application, etc. un plus gros paquet.
Parfois, la quantité d'applications en cours d'exécution peut exiger que le système d'exploitation soit plus rapide (envoyer tout ce qu'il contient dans le tampon jusqu'à présent) au lieu de saturer le tampon.
Peut-être pourriez-vous nous donner plus de détails sur le scénario avec lequel vous travailliez (ex.: OS du serveur, applications fonctionnant dessus).
la source
Fondamentalement, le problème est que l'implémentation TCP ne sait pas ce que l'application va faire ensuite. Lorsque l'application serveur effectue une séquence d'écritures, la pile ne sait pas si les écritures qu'elle a reçues jusqu'à présent sont la séquence entière ou seulement une partie de celle-ci.
La plupart du temps, l'application serveur effectue des écritures dans le tampon plus rapidement que la pile réseau ne peut le vider. Ainsi, le tampon est plein et des paquets de taille réelle sortent.
Mais parfois, quelque chose d'autre ralentit l'application serveur. Peut-être en attente d'une lecture de disque sur une matrice de disques surchargée ou quelque chose. Ainsi, le tampon se vide et la pile réseau doit choisir entre l'envoi d'un petit paquet (plus de surcharge) ou l'attente de données qui pourraient ne jamais arriver (en ajoutant du retard).
la source
Si vous regardez la trame 34, vous verrez que le serveur a transmis une mémoire tampon de 32 Ko et que le bit PSH est défini. Si vous regardez 82, vous verrez la même chose, 32 Ko par rapport au bit PSH précédent. Le paquet 52 a un bit PSH même s'il y a eu moins de 2 Ko de réponse.
Le bit PSH est généralement défini par une pile TCP pour le dernier segment d'une PDU d'application écrite sur le réseau. Ainsi, l'application utilise un tampon de 32 Ko et lorsqu'il y a beaucoup de données, l'écrit sur le socket TCP 32 Ko à la fois. Quand il y a moins de données que dans les trames 51-52, c'est parce que l'application a écrit cet enregistrement en premier dans la réponse et que ce n'était que 1820 octets.
Notez que l'application à laquelle je fais référence peut en fait ne pas être l'application serveur elle-même mais certains logiciels intermédiaires tels qu'une machine virtuelle Java (JVM) ou autre. Le contenu des données ne permet pas de savoir pourquoi cette PDU de 1820 octets a été envoyée, peut-être qu'un tampon de 32 Ko n'était pas disponible à l'époque?
Le fait est que cela ne devrait pas avoir d'importance, il n'y a pas de pénalité de performance substantielle.
la source