[squid-users] Individual delay pools and youtube

[dan at getbusi.com]

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.




It just occurred to me that (obviously) this is why HTTPS downloads are going too fast; because this bug must only affect HTTP traffic.




So HTTPS downloads are going at the actual speed we’ve specified and HTTP is going at half that.




Therefore, we should be able to work around it by setting different delay_parameters for HTTP and HTTPS requests.




So my question is, how best to target only those requests? By the CONNECT method?




P.S. This bug is still present in the latest Squid 3.5 HEAD.

On Mon, Apr 20, 2015 at 11:44 AM, null <dan at getbusi.com> wrote:

> Thanks Amos
> Sorry if that wasn’t clear, but yeah, 7 KB/s was the desired speed in that test. 
> 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.
> 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.
> So, if I want to configure a 56 kbps restriction our software actually writes:
> delay_parameters 1 -1/-1 14336/14336
> In order to achieve the correct limit (7 KB/s). Not sure if that could be related to this at all.
> 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.
> On Mon, Apr 20, 2015 at 1:25 AM, Amos Jeffries <squid3 at treenet.co.nz>
> wrote:
>> On 17/04/2015 1:30 p.m., djch wrote:
>>> I just wanted to revive this thread to note that:
>>> 
>>> - Delay pools apply just fine to HTTPS requests in Squid 2.7.
>>> - Delay pools in Squid 3.4.x are also applied to HTTPS but the speed is not
>>> correct. 
>>>   - If I apply a 56 Kbps limit the HTTP download tops out at ~7 KB/s.
>> That *is* correct.
>>    56K *bits* /sec == 7K *Bytes* /sec.
>>    7x8 = 56
>>> If I
>>> download the same file from the same server via HTTPS it tops out at
>>> ~90KB/s. If I download the same file over HTTPS with no delay pools
>>> configured it tops at around 3MB/s.
>> Are you sure thats actually HTTPS ?
>> CONNECT tunnels these days could contain HTTP/2, SPDY, WebSockets or
>> data in some other (compressed?) format. Any of which achieve faster
>> percieved "download" than HTTP using the same basic bytes/sec data rate.
>> NP: squid-2.7 contains a CONNECT bug that prevents SPDY HTTP/2 and
>> Websockets working properly.
>>> 
>>> So I guess that would make this a bug? Which I assume nobody wants to fix
>>> 'cause they're going to be deprecated at some point soon?
>>> 
>> Its a matter of interest. With FOSS you have to cause someone to be
>> interested in fixing the bug. Best way to do that is to fix it yourself
>> and present a patch and get it through review to merge. Second best is
>> to find someone to pay to do all that. Or you can join the many people
>> who opted just to wait and pray someone else will give it to them free
>> one day.
>> There is another option with delay pools. The pooling system is *just* a
>> packet rate limiting system. The OS these days have several such QoS
>> systems built in that work far better than Squid algorithms (admittedly
>> not on a HTTP per-message basis). If you want total traffic control give
>> those a try.
>> Amos
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150428/ab4471f4/attachment.html>