[Markos Grokus <mg7140@xxxxxxx>]

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
>