Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] [TCP segment of a reassembled PDU] question...

From: Sake Blok <sake@xxxxxxxxxx>
Date: Sun, 4 Jan 2009 22:03:02 +0100
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