Mon Dec 31, 2018 2:59 pm
Yes, this really doesn't seems to be worth using. The website says for cache miss (and that will happen for HTTPS or any encrypted protocol all the time) penalty is 10%. So with usual traffic where most is encrypted (including bandwidth hogs like youtube and other streaming services) you will be losing 10% of the bandwidth to maybe improve a bit of unencrypted traffic that still exists. Unless you have some specific reason to do so (I can imagine maybe FTP or HTTP transfers where many PCs are downloading same content?) it's just not worth it.
And this doesn't even take extra latency and CPU power you need for this to run on an routerboard.
There are other methods that may improve link bandwidth and quality, see various TCP acceleration options used on satellite links, stuff like ACK spoofing and IP header compression. Implementing these would be much more interesting and useful, for example to get around MTU limits. Then there is also tinyfecvpn, that improves reliability by adding extra FEC bytes so lost packets can be reconstructed, even during link handover etc. Now THIS would be really interesting (think of an mikrotik client that roams from AP to AP, streaming UDP/TS video and not a single packet is lost in a process...).
Improving the TCP and flow control goes a long way, but data caching is pretty much dead thanks to the widespread use of encryption...