Mappage des requêtes HTTP aux réponses HTTP

Question

Si je fais plusieurs requêtes get HTTP sur le même serveur et que je reçois des réponses HTTP 200 OK, comment puis-je déterminer quelle requête correspond à quelle réponse avec Wireshark?

Actuellement, il semble qu'une requête http est faite, et la prochaine réponse HTTP 200 OK est rapidement reçue, donc tout est dans la bonne séquence. J'ai cependant vu des choses contraires. Par exemple, en utilisant l'API Google Maps v2, j'ai fait plusieurs demandes d'informations de localisation et ensuite les informations sont reçues dans un ordre arbitraire (ressemblant étroitement à l'ordre dans lequel je l'ai demandé, mais pas nécessairement parfait.)

intuition est que je ne peux pas supposer que mes réponses seront reçues dans un ordre spécifique, même si elles peuvent être en ordre la plupart du temps. Donc, je me demande comment je peux déterminer cet ordre à partir de la réponse.

Mise à jour: Clarification de ce dont j'ai besoin. J'ai juste besoin de savoir que le serveur a reçu la demande. Il semble que j'ai besoin de faire cela en regardant les numéros de séquence et peut-être même ACKS. Le raisonnement derrière cette approche est que j'observe fondamentalement une application Web et la vérifie envoie l'information et l'information est reçue.

Mise à jour: Cela n'a rien à voir avec wireshark spécifiquement. Je crois que cela déroute les gens, alors je l'enlève du titre. Cela a à voir avec le protocole HTTP au-dessus du protocole TCP/IP et la manière dont nous mappons les réponses aux demandes.

Merci.

Answer 1

On dirait que cette capacité n'est pas fournie par le protocole HTTP au niveau de la couche d'application, donc je dois descendre à la couche de transport pour le déterminer. Dans mon cas, la couche TCP/IP utilise des numéros de séquence.

HTTP suppose seulement un
de transport fiable; tout protocole qui fournit de telles garanties peut être utilisé; le mappage du HTTP/1.1 demande et structures d'intervention sur les
unités de données de transport du protocole en question est en dehors du champ d'application de la présente spécification .

En savoir plus: http://www.faqs.org/rfcs/rfc2616.html#ixzz0e20kxKcz

Answer 2

Après avoir arrêté les paquets de capture suivre les étapes suivantes:

1. positionner le curseur sur une requête GET

2. Ouvrez le menu Analyser

3. cliquez sur "Suivre" TCP Stream "

Vous obtenez une nouvelle fenêtre avec des demandes et des réponses dans la séquence.

Answer 3

Ne pas utiliser Wireshark pour déboguer HTTP, utilisez un débogueur HTTP tels que Fiddler2

Answer 4

Pendant que je googler une question complètement différente, j'ai vu celui-ci et je pense que je peux apporter une réponse plus complète:

HTTP dicte que les réponses doivent arriver dans l'ordre où ils ont été demandés, donc, si vous êtes à la recherche à une seule connexion TCP à un moment donné, vous devriez voir:

demande; Réponse Demande ; Réponse ...

Également dans HTTP/1.1, il existe un support pour "Pipeline" où le client n'a pas besoin d'attendre l'arrivée des réponses pour émettre la prochaine requête. Ce qui peut être observé dans de tels cas est:

Demande; Réponse Demande ; Demande ; Réponse Réponse Demande ; Réponse

Dans la réponse HTTP elle-même, il n'y a pas de référence à la requête spécifique qui l'a déclenchée. La suggestion de Filipo est classique lors du débogage/observation d'une connexion TCP unique, mais lorsque vous observez plusieurs connexions TCP, vous ne pouvez pas cliquer sur le flux TCP suivant car vous devez le faire pour chaque connexion. Si vous avez beaucoup de connexions TCP, et de nombreuses demandes/réponses, vous devrez regarder le port source TCP dans le paquet de requête, et le port dest TCP dans le paquet de réponse pour savoir quelle réponse est liée à chaque connexion tcp, puis appliquez les règles de requête/réponse HTTP. De plus, Wireshark peut décompresser le corps de la réponse, et il le fera automatiquement si tout le corps de la réponse est arrivé, mais il ne le fera PAS dans le flux Follow TCP.

J'utilise toujours Wireshark pour déboguer HTTP.