La cartographie des requêtes HTTP à des réponses HTTP

Si je fais plusieurs Requêtes HTTP Get sur le même serveur et obtenir HTTP 200 OK réponses à chacun comment dois-je dire à qui demander des cartes à laquelle la réponse à l'aide de Wireshark?

Actuellement, il ressemble à une requête http, et la prochaine réponse HTTP 200 OK est reçu rapidement, donc tout est dans le bon ordre. J'ai vu des choses contraires. Par exemple à l'aide de l'API Google Maps v2 j'ai fait plusieurs demandes d'informations de localisation, puis l'information est reçue dans un ordre arbitraire (ressemblant étroitement à l'ordre dans lequel je l'ai demandé, mais pas nécessairement parfait.)

Si mon intuition est que je ne peut pas présumer que mes réponses seront reçus dans un ordre spécifique, même si elles peuvent être dans l'ordre la plupart du temps. Alors je me demandais comment je peux déterminer cet ordre à partir de la réponse.

Mise à jour: des Précisions sur ce que j'ai besoin. J'ai juste besoin de savoir que le serveur a reçu la demande. Il semble que j'ai besoin de le faire en regardant les numéros de séquence et peut-être même les accusés de réception. Le raisonnement derrière cette approche est que je suis à la base de l'observation d'une application web et de le vérifier est d'envoyer de l'information et de l'information est en cours de réception.

Mise à jour: Cela n'a rien à voir avec wireshark en particulier. Je crois que c'est déroutant de personnes donc j'ai retirer à partir du titre. Il a à voir avec le protocole HTTP sur le haut du protocole TCP/IP et comment nous la carte des réponses aux demandes.

Grâce.

OriginalL'auteur Derek Litz | 2010-01-29

  1. 13

    Après que vous avez arrêté de capture de paquets de suivre ces étapes:

    1. placez le curseur sur une requête GET

    2. Ouvrir le menu analyse

    3. cliquez sur "Follow TCP Stream"

    Vous obtenez une nouvelle fenêtre avec les demandes et les réponses dans l'ordre.

    C'est une très bonne information pour l'utilisation de Wireshark effectivement, mais je suis à la recherche de quelque chose de différent, comme une réponse.
    En fait, ce devrait être la réponse. Dans le flux tcp de vue, vous pouvez voir la séquence exacte de la demande/réponse.

    OriginalL'auteur filippo

  2. 5

    Alors que j'ai été googler pour remplir une autre question, j'ai vu ça et je pense que je peux fournir une réponse plus complète :

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

    Demande ; Réponse ; Demande ; La Réponse ...

    Également dans HTTP/1.1, il ya un soutien pour les "Pipeline" où le client n'a pas à attendre pour les réponses à arriver dans l'ordre de numéro de la demande suivante. Ce qui pourrait être observé dans de tels cas est :

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

    Dans la réponse HTTP lui-même, il n'y a pas de référence à la demande spécifique qui a déclenché cela.

    Filipo la suggestion est classique lors du débogage /de l'observation d'une seule connexion TCP, mais, lorsque l'on observe de multiples connexions TCP, vous ne pouvez pas cliquer sur le follow TCP Stream parce que vous avez à faire pour chaque connexion.

    Si vous avez plusieurs connexions TCP, et de nombreuses demandes/réponses, vous aurez à regarder TCP port Source dans le paquet de demande, et le protocole TCP dest port dans le paquet de réponse pour savoir quelle réponse est liée à chaque connexion tcp, et d'appliquer ensuite la requête/réponse HTTP règles de commande.

    Aussi, Wireshark PEUT décompresser le corps de la réponse, et il le fera automatiquement si tous les corps de la réponse est arrivée, mais elle ne le fera PAS dans le prolongement de Flux TCP.

    J'ai toujours utiliser Wireshark pour déboguer HTTP.

    ce ne sera pas le cas pour le multi threaded de l'environnement.

    OriginalL'auteur eitama

  3. 3

    Semble que cette possibilité n'est pas prévue par le protocole HTTP à l'application de la couche de si je dois aller vers le bas pour le transport de la couche de le déterminer. Dans mon cas, la couche TCP/IP à l'aide de la séquence de nombres.

    HTTP seulement, suppose un fiable

    de transport; tout protocole qui fournit
    de telles garanties peuvent être utilisés; la
    la cartographie de la requête HTTP/1.1 et
    la réponse des structures sur l'

    le transport des unités de données du protocole
    en question est en dehors de la portée de
    cette spécification.

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

    OriginalL'auteur Derek Litz

  4. 2

    Ne pas utiliser Wireshark pour déboguer HTTP, utiliser un débogueur HTTP comme Fiddler2

    Il n'y a rien de mal avec l'aide de Wireshark au lieu de Fiddler2 surtout si vous avez plus d'expérience avec elle.
    Wireshark ne pas décompresser gzip/delfate pour vous. Et il ne retirez pas de transfert de bloc de codage protocole de l'organisme.
    Aussi, Fiddler est uniquement disponible pour Windows.

    OriginalL'auteur Zombies