[T B <phreakocious@xxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe