Hi,
No, it doesn't know that packet No.132 is part of packet No.134. What it
does know is that packet No.132 is not long enough to contain all the data
for this HTTP request. So it keeps on reading in the capture file. Once it
encounters packet No.133 it knows it's the next part of the HTTP request,
but still that is not complete. Then it reads packet No.134 which does make
the HTTP request complete. Therefore it lists the HTTP request at the end,
stating all previous packets which contributed to the transport of its
contents.
Thanks,
Jaap
On Wed, 11 Nov 2009 16:46:13 +0800, "Qmo (Yi-Sheng)" <qmosheng@xxxxxxxxx>
wrote:
> Thank you in advance. But I still confused.
> Do you mean when Wireshark encounter packet No.132,
> it knows it's a part of packet No.134. How does Wireshark do that?
> In the cap file, each packet is composed by a serial strings, and it
will
> be
> decoded by the information of the strings.
> In packet No.132, packet No.133 and packet No.134, I couldn't see the
> related info about them,
> even the Wireshark knows what HTTP responses look like, does it imply
some
> info in the strings?
> Thank you very much!
>
> Best Regards,
> Qmo
>
> On Wed, Nov 11, 2009 at 4:25 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
>>
>> On Nov 11, 2009, at 12:20 AM, Qmo (Yi-Sheng) wrote:
>>
>> > I want to decode the HTTP packet, but it involves the three packets.
>> > In Wireshark "Packet bytes Pane", the packet No. 134 shows
>> > [Reassembled TCP Segments (1938 bytes): #132(272) #133(1460)
>> > #134(206) ]
>> > [Frame: 132 , payload: 0-271]
>> > [Frame: 133 , payload: 272-1731]
>> > [Frame: 134, payload:1732-1937]
>> >
>> > How do Wireshark know this infomation via the cap file?
>>
>> Because it knows what HTTP responses look like - a Status-Line, a
>> bunch of {general,response,entity}-headers, a blank line, and a
>> response body, with the latter terminated either by the byte count
>> from the headers or by closing the connection - so it accumulates the
>> contents of TCP segments until it's seen all of that.
