On Nov 11, 2009, at 12:46 AM, Qmo (Yi-Sheng) 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,
Actually, each packet is a sequence of octets; some parts of a packet
containing part or all of an HTTP request or response happen to be
text strings, but the link-layer, IP, and TCP headers are binary data,
and even the payload of an HTTP request or response could be binary
(depending on the transfer encoding).
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?
It implies information in the raw packet data.
For example:
In your capture file, the TCP sequence numbers in the TCP headers
indicate that the TCP payload in frame 133 comes right after the TCP
payload in frame 132 (because the TCP sequence number in the TCP
header in frame 132, plus the total number of TCP payload data bytes
in frame 132, is equal to the TCP sequence number in the TCP header in
frame 133), and that the TCP payload in frame 134 comes right after
the TCP payload in frame 133. (The total number of TCP payload data
bytes in a frame is indicated by the packet length information in the
IP header in that frame.)
This allows the TCP dissector to combine the TCP payload data from
those three frames.
However, the TCP dissector doesn't know anything about HTTP, so it
doesn't know *how much* TCP payload data to combine. The HTTP
dissector gets the TCP payload of frame 132 passed to it; it sees part
of an HTTP response, but doesn't see all of an HTTP response, so it
provides an indication to the TCP dissector that it should accumulate
more data. Then, with frame 133, the TCP dissector adds the payload
from that frame to the payload from frame 132, and hands the combined
payload to the HTTP dissector; it sees that it got more of the
response, but that it still doesn't have all of the response, so it
again indicates to the TCP dissector that it needs more data. With
frame 134, the TCP dissector adds the payload from *that* frame to the
combined payload of frames 132 and 133, and hands that combination to
the HTTP dissector, which now sees a complete HTTP response, and
dissects it.
