That was a nice explanation :)
Have just sat here reading it whilst viewing the .pcap file.
Very informative - thanks.
Sake Blok wrote:
> On Fri, Nov 13, 2009 at 07:59:57PM -0500, Sheahan, John wrote:
>> If you look at just the conversation on port 4918, everything appears
>> to be going along fine until for some reason, the client (76.11)
>> reports a "TCP Zero Window" and then 11 seconds go by before the
>> client resets the connection..not sure what would cause this.did
>> the client run out of resources?
>
> Starting at frame 187, the window size in the ACKs from the client start
> decreasing. This means that at the client side the data is received
> properly by the TCP/IP stack, but the application is not pulling the
> data from the receive buffers quickly enough to deplete them.
> By the rate at which the window size is decreasing you can
> see that actually no data at all is pulled from the buffer (because the
> window size decreases with exactly the amount of data that has been
> sent). When the window size is zero, the receive buffer is full and no
> more data can be send by the server.
>
> This does not tell us why the webbrowser does not pull data from the
> buffer, but it does tell you that the problem lies on the client PC.
>
> The TCP-RST is caused by the user as it is going to another URL. The
> browser now closes all open connections and opens connections to the new
> site. Since the browser seems to be capable of retrieving the new site
> in a quickly manner, my guess would be that some firewall/virus-scanning
> software is actually choking on www.priceline.com.
>
>> Then the client goes to Google and gets some data but the next
>> two GETS return "HTTP 204 No Content".
>
> No problem... especially since one request has an URL that seems to
> explicitly request the 204.
>
>> The client then tries to go to yahoo.com, gets redirected (packet 449)
>> and appears to pull down quite a bit of data but when I look at the
>> HTML data in packet 611, there is only one line of text.
>
> Where do you see only 1 line of text, if you expand the "Line-based text
> data" item, you can see the whole page.
>
>> In packet 781, the client tries to go to cnn.com and gets an
>> "HTTP 304 Not Modified" then the client FINs out the connection.
>
> Have a look at the HTTP headers, in the request there is the line
> "If-Modified-Since: Wed, 28 Oct 2009 14:26:23 GMT\r\n", this means that
> the browser has a local copy in cache and is asking, only sent me the
> object if it is newer that my version. Which it is not, so the server
> tells the browser to use it's local copy and save bandwidth and delay.
>
>> What I do notice though is that all HTTP GETS are sent from the client
>> using HTTP 1.1 and the proxy always answers back with HTTP 1.0
>> responses.could this be the problem?
>
> Nope, this is allowed and is not the source of your problem.
>
> So, the only problem in the trace is the fact that the client is not
> pulling data from the receive buffer for some unknown reason.
>
> I would suggest reading some more about TCP and HTTP, it will give you
> some understanding of what you see in the traces. Some starting points
> might be the RFC's:
>
> RFC793 - Transmission Control Protocol
> RFC1945 - Hypertext Transfer Protocol -- HTTP/1.0
> RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1
>
> (see: http://www.faqs.org/faqs/)
>
> Hope this helps,
> Cheers,
>
>
> Sake
>
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
