On 2013-08-13 05:20, SaRaVanAn wrote:
Hi All,
I observed there is a difference in tcp state machine in both
working(without squid) and Not working scenario.(without squid)
State machine in working scenario (without squid)
----------------------------------------------------
client Server
SYN
--------------->
SYN + ACK
<-------------------------
ACK
-------------------------->
GET
--------------------------->
ACK
<----------------------------
TCP segment of a resembled PDU (MTU 1514)
<---------------------------
HTTP/1.1 200 ok (MTU 293)
<------------------------
then connection terminates
State machine in Not-working scenario (with squid)
You say "with squid". But when Squid is in the picture there are *two*
TCP connections operating asynchronously to transfer the request and
response client<->squid and squid<->server.
What you describe below appears to be a single TCP connections
operations, except that there are things happenign on it which are
impossible (RST followed by successful packets exchanges). TCP level
aborts and resets on one connection affect the other in various ways
defined by HTTP semantics and recovery (not TCP synchronous).
So what we need is labeling the packets as per which TCP connection it
occured on and how the packets on each are sequenced/interleaved across
both.
For example:
----------------------------------------------------
client Server
SYN
--------------->
SYN + ACK
<-------------------------
ACK
-------------------------->
GET
--------------------------->
ACK
<----------------------------
SYN + ACK
<---------------------------
RST
------------------------>
... after a RST packet is received Squid runs through the connection
shutdown code which *doe not* involve delivering any more HTTP on *that*
connection.
I assume that this is the squid<-><server connection dying.
TCP previous segment not captured
<------------------------------
RST
------------------------>
TCP last segment not captured
<------------------------------
.........
TCP segment of a resembled PDU (MTU 1514)
<-------------------------
TCP segment of a resembled PDU (MTU 1514)
<-------------------------
HTTP/1.0 504 Gateway timeout (MTU 1050)
<-----------------------------
.. so this response
then connection terminates
In case of squid running ,
1) Why web-server is sending "SYN+ACK" instead of "TCP last segment
not captured" PDU?
Because Squid opened the second (squid<->server) connection with a SYN
packet that you missed out of the trace?
2) Why there is a delay in sending "TCP last segment not captured" PDU?
Unknown. What does that "last segment not captured" mean exactly?
I think you mean the packet was not fully recorded by the tcpdump
program? Try using "-s 0" parameter (or 65535) to do full packet payload
capture.
I also recommend saving the trace to a file (-w option) and using
wireshark to read the capture instead of trying to read the tcpdump
command-line abbreviations.
Moreover I could see there is a variation in HTTP version (1.0 and
1.1) .
Because each of the three agents is advertising to each other what
highest minor version of HTTP/1.x they are compliant with.
Amos
