Mappatura delle richieste HTTP alle risposte HTTP

Question

Se eseguo più richieste di ottenere HTTP sullo stesso server e ottengo risposte HTTP 200 OK a ciascuna di esse, come faccio a sapere quale richiesta esegue la mappatura su quale risposta utilizzare Wireshark?

Attualmente sembra che sia stata effettuata una richiesta http e la successiva risposta HTTP 200 OK è stata ricevuta rapidamente, quindi tutto è nella giusta sequenza. Tuttavia ho visto cose contrarie. Ad esempio, utilizzando l'API di Google Maps v2 ho fatto diverse richieste di informazioni sulla posizione e quindi le informazioni sono ricevute in un ordine arbitrario (molto simile all'ordine in cui l'ho richiesto, ma non necessariamente perfetto)

Quindi il mio l'intuizione è che non posso presumere che le mie risposte saranno ricevute in un ordine specifico, anche se potrebbero essere in ordine per la maggior parte del tempo. Quindi mi chiedo come posso determinare questo ordine dalla risposta.

Aggiornamento: chiarimento su ciò di cui ho bisogno. Devo solo sapere che il server ha ricevuto la richiesta. Sembra che debba farlo osservando i numeri di sequenza e forse anche ACKS. Il ragionamento che sta alla base di questo approccio è che sto fondamentalmente osservando un'applicazione web e controllando che stia inviando le informazioni e che le informazioni siano state ricevute.

Aggiornamento: Questo non ha nulla a che fare con wireshark in particolare. Credo che confonda le persone e quindi lo rimuovo dal titolo. Ha a che fare con il protocollo HTTP in cima al protocollo TCP/IP e il modo in cui mappiamo le risposte alle richieste.

Grazie.

Answer 1

Sembra che questa capacità non sia fornita dal protocollo HTTP a livello di applicazione, quindi devo passare al livello di trasporto per determinarlo. Nel mio caso il livello TCP/IP utilizza numeri di sequenza.

HTTP presume solo affidabile
trasporto; qualsiasi protocollo che fornisce tali garanzie possono essere utilizzate; la mappatura della richiesta HTTP/1.1 e le strutture di risposta sulle
unità di dati di trasporto del protocollo in questione non rientrano nell'ambito di applicazione di .

Per saperne di più: http://www.faqs.org/rfcs/rfc2616.html#ixzz0e20kxKcz

Answer 2

Dopo aver smesso di pacchetti acquisizione seguire questa procedura:

1. posizionare il cursore su una richiesta GET

2. Aprire il menu

Analizzare

3. fare clic su "Segui" TCP Stream "

Si apre una nuova finestra con richieste e risposte in sequenza.

Answer 3

Non utilizzare Wireshark per eseguire il debug HTTP, utilizzare un debugger HTTP come Fiddler2

Answer 4

Mentre ero googling per una domanda completamente differente, ho visto questo e credo di poter fornire una risposta più completa:

HTTP impone che le risposte devono arrivare nell'ordine in cui sono stati richiesti, quindi, se siete alla ricerca di una singola connessione TCP in un dato momento si dovrebbe vedere:

richiesta; Risposta; Richiesta ; Risposta ...

Anche in HTTP/1.1, esiste il supporto per "Pipeline" in cui il client non deve attendere l'arrivo delle risposte per emettere la richiesta successiva. Quello che potrebbe essere osservato in questi casi è:

Richiesta; Risposta; Richiesta ; Richiesta ; Risposta; Risposta; Richiesta ; Risposta

Nella risposta HTTP, non vi è alcun riferimento alla richiesta specifica che l'ha attivata.

Il suggerimento di Filipo è classico quando si esegue il debug/osservando una singola connessione TCP, ma, quando si osservano più connessioni TCP, non è possibile fare clic sul flusso TCP successivo perché è necessario farlo per ciascuna connessione.

Se si hanno molte connessioni TCP e molte richieste/risposte si dovrà guardare la porta Source TCP nel pacchetto di richiesta e la porta di destinazione TCP nel pacchetto di risposta per sapere quale risposta è correlata a ciascuna connessione TCP, e quindi applicare le regole di richiesta/risposta HTTP.

Inoltre, Wireshark PU decom decomprimere il corpo della risposta e lo farà automaticamente se tutto il corpo della risposta è arrivato, ma lo farà NON nel flusso TCP successivo.

Uso sempre Wireshark per eseguire il debug di HTTP.