Re: Multiple syn's , syn/ack and ack received for single connection?

[T B <phreakocious () gmail com>]

Introducing the reverse proxy adds a bit of complexity when analyzing a
problem at the network layer.  In particular, your RTTs as well as
negotiated TCP options only reflect communication to the proxy and not the
actual server with the content.  To fully understand what's happening in
this scenario, you'd probably need a capture on the other side of the proxy
as well.

On Tue, Aug 4, 2015 at 3:18 PM, asad <a.alii85 () gmail com> wrote:

> TB indeed diversity is beautiful thing but so is present "by the book"
> acknowledge where the classical case is discussed as a rule of thumb. Only
> in forums like this one expects to see lot of variations in responses.
>
> Coming back to my original question, parallel connections in my cases
> doesn't seem to improve server response time which theoretically speaking
> isn't having parallel performance impact.
>
> The time between GER request and ack are in miliseconds. To give more
> context the server is acting as reverse proxy with modsec rules turned on.
> It's WAF.
>
> Detecting slow server response is there a benchmark I can get from
> anywhere e.g university experiments data etc.
> On 5 Aug 2015 00:02, "T B" <phreakocious () gmail com> wrote:
>
> > Can't speak to your anecdotal experiences, but it definitely can and does
> > happen in parallel depending on the browser/client.  There is also nothing
> > non-"classical" about this behavior.  Each connection operates in exactly
> > the classical way, there are just more of them. :)
> >
> > On Tue, Aug 4, 2015 at 2:28 PM, asad <a.alii85 () gmail com> wrote:
> >
> > > Thanks, for the fast response.
> > >
> > > I have tested the same by visiting home-pages of other websites as well
> > > and none had such behavior parallel requests by browser. It mostly works as
> > > classical.
> > >
> > > syn
> > > syn-ack
> > > ack
> > >
> > > Now, consecutive syn's. Yes you were right, down the packet-capture I
> > > see all the syn,syn-ack and ack packets. Thanks for mentioning.
> > >
> > > regards
> > > asad
> > >
> > > On Tue, Aug 4, 2015 at 11:05 PM, T B <phreakocious () gmail com> wrote:
> > >
> > > > A web browser can make multiple connections to the same server to fetch
> > > > different resources in parallel.  The other syn/ack responses are probably
> > > > in the capture as well, but further down.  The sockets should be processed
> > > > in the order they're received, but there are lots of reasons why it might
> > > > not all happen immediately.  None of this seems strange so far.
> > > >
> > > > Hope this helps.
> > > >
> > > > On Tue, Aug 4, 2015 at 11:13 AM, asad <a.alii85 () gmail com> wrote:
> > > >
> > > > > I have a scenario, I'm analyzing ssl (decrpyt) traffic to my
> > > > > webserver. I'm investigating server and end-to-end delay issues. In between
> > > > > this I'm stuck at following traffic pattern for which I need some
> > > > > advice/suggestion. The patter shows:-
> > > > >
> > > > >      client       server
> > > > >     src port 1 -> 80 (syn)
> > > > >     src port 2 -> 80 (syn)
> > > > >     src port 3 -> 80 (syn)
> > > > >     src port 4 -> 80 (syn)
> > > > >     .....
> > > > >
> > > > >      server        client
> > > > >     src port 80 -> 1  (syn/ack)
> > > > >     src port 80 -> 2  (syn/ack)
> > > > >
> > > > >     client         server
> > > > >     src port 1 -> 80  (ack)
> > > > >     src port 2 -> 80  (ack)
> > > > >
> > > > > After, complete of handshake I see <code>"http get request"</code>
> > > > > from client. My issues is:-
> > > > >
> > > > >  1. why are multiple syns send from
> > > > >     client to server from different
> > > > >     source port
> > > > >  2. why server choose to
> > > > >     reply on NOT all ports mainly the
> > > > >     syn/ack is received by first 3
> > > > >     ports.
> > > > >  3. Multiple acks to different
> > > > >     ports?
> > > > >
> > > > > a sample SYN request just for analysis looks like
> > > > >
> > > > > "694    47.583499000    192.168.1.56    192.168.1.22    TCP    66
> > > > > 0.000173000    50844→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4
> > > > > SACK_PERM=1"
> > > > >
> > > > > Please help me understand this behavior.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ___________________________________________________________________________
> > > > > Sent via:    Wireshark-users mailing list <
> > > > > wireshark-users () wireshark org>
> > > > > Archives:    https://www.wireshark.org/lists/wireshark-users
> > > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > > > >              mailto:wireshark-users-request () wireshark org
> > > > > ?subject=unsubscribe
> > > >
> > > >
> > > >
> > > > ___________________________________________________________________________
> > > > Sent via:    Wireshark-users mailing list <
> > > > wireshark-users () wireshark org>
> > > > Archives:    https://www.wireshark.org/lists/wireshark-users
> > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > > >              mailto:wireshark-users-request () wireshark org
> > > > ?subject=unsubscribe
> > >
> > >
> > >
> > > ___________________________________________________________________________
> > > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org
> > > >
> > > Archives:    https://www.wireshark.org/lists/wireshark-users
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > >              mailto:wireshark-users-request () wireshark org
> > > ?subject=unsubscribe
> >
> >
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > Archives:    https://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >              mailto:wireshark-users-request () wireshark org
> > ?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe