<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 14/09/2015 07:52, Fakrul Alam wrote:<br>
</div>
<blockquote
cite="mid:%3CCA+GOhEycnFrDNyTvGWChM5WXmjdb+yfihbY-=rkj11XGtMEqEg@mail.gmail.com%3E"
type="cite"><a moz-do-not-send="true" href="http://www.bb.org.bd">www.bb.org.bd</a>
site are seriously overloaded...
<div><br>
</div>
</blockquote>
That is one theory. However, people say that if they connect via
Qubee they get fast response.<br>
<br>
Another theory is that there is substantial packet loss over certain
paths, causing TCP delays / retransmissions. You may be able to
infer this by taking a packet capture:<br>
<br>
tcpdump -i eth0 -w bb.pcap -nn<br>
<br>
and then analysing bb.pcap looking for retransmissions, e.g. by
hand, or by using tcptrace and xplot.<br>
<a class="moz-txt-link-freetext" href="http://www.tcptrace.org/tcptrace-manual/manual/node12_ct.html">http://www.tcptrace.org/tcptrace-manual/manual/node12_ct.html</a><br>
<br>
If it's a load problem (either server load or network load) I would
expect the issue to vary by time of day, and be noticeably better in
the middle of the night.<br>
<br>
By the way: this is a *bank*, and this is 2015. Do you really still
need to force SSLv3 to connect to them, rather than TLS? That is
totally broken. It won't be long before web browsers disable SSLv3,
because of its known security problems.<br>
<br>
<blockquote
cite="mid:%3CCA+GOhEycnFrDNyTvGWChM5WXmjdb+yfihbY-=rkj11XGtMEqEg@mail.gmail.com%3E"
type="cite">
<div>
<div>$ curl -o /dev/null -s -w
%{time_connect}:%{time_starttransfer}:%{time_total}\\n --sslv3
<a moz-do-not-send="true" href="https://www.bb.org.bd:443">https://www.bb.org.bd:443</a></div>
<div>0.072:120.083:704.965</div>
</div>
</blockquote>
That is an excellent start. It would be really helpful if people
could make measurements like this from different points and at
different times of day, and for someone to collate the results. This
will help to demonstrate that there *is* really a problem, and help
to pinpoint what it is.<br>
<br>
For comparison, here's what I get from a VM in the UK (at
bytemark.co.uk): three successive tests made on 2015-09-14 at 07:40
UTC<br>
<br>
3.912:0.000:3.912<br>
1.001:0.000:1.001<br>
0.448:0.000:0.447<br>
<br>
Given the latency from UK to Bangladesh I'd say this is
understandable, although if everything is working well I would
expect the third result to be consistently achieved, not the first
result.<br>
<br>
Regards,<br>
<br>
Brian.<br>
<br>
</body>
</html>