find and reroute high bandwidth connection through other WAN

can i find current mbps (ok averaged over last n seconds) for each connection? i believe that should be possible at least can scan bytes recvd now and in n seconds and divide.

question if i kill it can i reroute it through another WAN (different public API) - would it reestablish?

i.e looking into how can do some dual WAN setup for different links (low latency 80mbps WAN and higher latency 700mpbs WAN)
want just to kick bandwidth hungry connections (file downloads or 4k video streams onto second WAN)

There is a connection-rate match condition, which matches if the current connection rate in bits per second fits into a specified from-to range; the maximum value that can be expressed is 4Gbit/s. So what you could do is to add the destination address of a high-bandwidth connection to an address-list with a lifetime of several seconds, then send a RST to that connection (so the whole trick could work only with TCP), and assign a particular connection-mark to new connections whose destination address would match that address list.

This approach may work but the connections must be TCP ones (there is no way to quickly drop any other type of connection and the giveup timeout may be way too high to fit the purpose), the application must initiate a new connection automatically, and it must connect to the same IP address like it did in the previous attempt. I am not sure how reliable this may be.

I’d say you’d get more reliable outcome if you could run a CHR somewhere in a datacenter and switch the connections between two tunnels terminated on that CHR, without breaking the connections, one tunnel via each WAN. How this approach would increase the latecy of the low latency connection is another question, though.

yes i understand that there would be a reetsblish time which might be ok if one downloads file size of multiple gigabytes, waiting couple seconds to restablish connection to jump to faster interface seems fine. Or while watching 4k video, 1-2 second glitch in the beginning seems reasonable might be hidden by buffering. i would hope most of that stuff uses TCP. Voip is the major thing which uses UDP these days (beside from torrents) am i right?

but i am realy curious about running CHR in the cloud, if that is easier and i can get 1gbit throughput for 5-10$/month it could be worth a try - is there any doc of how can i setup such kinda thing with two load-balancing tunnels?