Wireshark-users: Re: [Wireshark-users] [TCP segment of a reassembled PDU] question...
On Sun, Jan 04, 2009 at 09:15:19PM +0100, Gergely Bacskó wrote:
>
> I found the following, hope that helps:
> (I used this filter because I assume this is between host and the
> appropriate server: ip.addr==10.200.50.111 && ip.addr==208.109.181.58 )
>
> I think the server is not slow, because in packet 7-8-9-10 (use my
> filter) the IP IDs are 13908 13909 13910 13911 so I think that means
> that the server in not busy, because it is sending you continuous IP
> IDs. If the server would have been busy (eg serving other clients at the
> same time) IP IDs would have been like 13908-14258-15689-16898...
Well, from RFC 791:
"The identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of
an internet datagram sets the identification field to a value that
must be unique for that source-destination pair and protocol for the
time the datagram will be active in the internet system."
Since the first connection to the server will be a single one, the ip
identification only needs to be unique within the
10.200.50.111/208.109.181.58/6(tcp) conversation. Which can be
accomplished by increasing the id by 1 for every new ip packet. So this
tells you nothing about how busy the server is serving data to other
clients.
> TCP receive window size is also OK.
> Maybe need some Apache fine-tuning ???
Since the request (frame 5&6) are ACK'd after about 90ms (frame 7&8),
there is not much network delay. So, it seems the delay is caused on the
server.
What does strike me as odd, is the fact that the server first anounces a
tcp window size of 0, but the after the 3way handshake, it announces a
new window size of 5840. But that does not seem to be related to the
slowness of the first response, cause the following requests get a 304
response back quickly, while showing the same window size oddness.
I would take a look on the server on why it is server the answer so
slowly.
HTH,
Cheers,
Sake
