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
