<span id="mailbox-conversation"><div>I mentioned last time that we had to x2 all our delay_parameter’s bytes because of a weird bug where squid would apply it at half speed for no reason.</div>
<div><br></div>
<div>It just occurred to me that (obviously) this is why HTTPS downloads are going too fast; because this bug must only affect HTTP traffic.</div>
<div><br></div>
<div>So HTTPS downloads are going at the actual speed we’ve specified and HTTP is going at half that.</div>
<div><br></div>
<div>Therefore, we should be able to work around it by setting different delay_parameters for HTTP and HTTPS requests.</div>
<div><br></div>
<div>So my question is, how best to target only those requests? By the CONNECT method?</div>
<div><br></div>
<div>P.S. This bug is still present in the latest Squid 3.5 HEAD.</div>
<div><br></div>
<div><br></div></span><div class="mailbox_signature">
<br> </div>
<br><br><div class="gmail_quote"><p>On Mon, Apr 20, 2015 at 11:44 AM, dan@getbusi.com <span dir="ltr"><<a href="mailto:dan@getbusi.com" target="_blank">dan@getbusi.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<span id="mailbox-conversation"><div>Thanks Amos</div>
<div><br></div>
<div>Sorry if that wasn’t clear, but yeah, 7 KB/s was the desired speed in that test. </div>
<div><br></div>
<div>I was testing against an ISO in an S3 bucket of ours. I would start the download using http:// and get 7 KB/s (great). Then cancel it and edit the URL to https:// and get ~90 KB/s.</div>
<div><br></div>
<div>Oh, and I almost forgot: (I can’t remember whether this has been reported but) there’s also a problem with delay_parameters, such that our software has to x2 any restriction that’s configured when generating the squid config.</div>
<div><br></div>
<div>So, if I want to configure a 56 kbps restriction our software actually writes:</div>
<div>
<div id="mb-reply">delay_parameters 1 -1/-1 14336/14336</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">In order to achieve the correct limit (7 KB/s). Not sure if that could be related to this at all.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">P.S. We’re pretty fond of delay_pools and their simplicity—including the fact that it can all be handled by Squid without any lower-level networking concerns.</div>
</div></span><div class="mailbox_signature">
<br> </div>
<br><br><div class="gmail_quote">
<p>On Mon, Apr 20, 2015 at 1:25 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>></span> wrote:<br></p>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>On 17/04/2015 1:30 p.m., djch wrote:<br>> I just wanted to revive this thread to note that:<br>> <br>> - Delay pools apply just fine to HTTPS requests in Squid 2.7.<br>> - Delay pools in Squid 3.4.x are also applied to HTTPS but the speed is not<br>> correct. <br>> - If I apply a 56 Kbps limit the HTTP download tops out at ~7 KB/s.<br><br>That *is* correct.<br><br> 56K *bits* /sec == 7K *Bytes* /sec.<br><br> 7x8 = 56<br><br><br>> If I<br>> download the same file from the same server via HTTPS it tops out at<br>> ~90KB/s. If I download the same file over HTTPS with no delay pools<br>> configured it tops at around 3MB/s.<br><br>Are you sure thats actually HTTPS ?<br><br>CONNECT tunnels these days could contain HTTP/2, SPDY, WebSockets or<br>data in some other (compressed?) format. Any of which achieve faster<br>percieved "download" than HTTP using the same basic bytes/sec data rate.<br><br>NP: squid-2.7 contains a CONNECT bug that prevents SPDY HTTP/2 and<br>Websockets working properly.<br><br>> <br>> So I guess that would make this a bug? Which I assume nobody wants to fix<br>> 'cause they're going to be deprecated at some point soon?<br>> <br><br>Its a matter of interest. With FOSS you have to cause someone to be<br>interested in fixing the bug. Best way to do that is to fix it yourself<br>and present a patch and get it through review to merge. Second best is<br>to find someone to pay to do all that. Or you can join the many people<br>who opted just to wait and pray someone else will give it to them free<br>one day.<br><br>There is another option with delay pools. The pooling system is *just* a<br>packet rate limiting system. The OS these days have several such QoS<br>systems built in that work far better than Squid algorithms (admittedly<br>not on a HTTP per-message basis). If you want total traffic control give<br>those a try.<br><br>Amos<br><br><br>_______________________________________________<br>squid-users mailing list<br>squid-users@lists.squid-cache.org<br>http://lists.squid-cache.org/listinfo/squid-users<br></p></blockquote>
</div>
<br></div></blockquote></div><br>