On 1/06/2014 3:49 a.m., Alex Crow wrote:
<snip>
>
> But given all you really need is QoS, why don't you either (a) dispense
> with Squid and just to QoS on the firewall for your Wifi subnet or (b)
> put a transparent firewall between your clients and the Squid server
> that does QoS? Or just see if Squid delay pools work for SSL (I think
> they *do*, the traffic still passes via Squid as a CONNECT request -
> it's just that Squid can't "see" or proxy the plaintext content.)
>
I second all of the above. In particular that the built-in QoS features
of the firewall or router device neworking config is far better place to
be doing the delay actions than Squid.
In regards to delay pools and HTTPS. As far as I know the pools work
without decrypting, although you may encounter one of a handful of bugs
which trigger over or under counting of bytes (depending on the bug
hit). So you may need a special delay pool configured with a hack on the
speed value of port 443 traffic to make the user-visible speed what they
expect.
Amos
Received on Sat May 31 2014 - 16:54:10 MDT
This archive was generated by hypermail 2.2.0 : Sat May 31 2014 - 12:00:07 MDT