I was initially going to be a naysayer to the idea of trying to "WAN optimize" rsync traffic, but the more I thought about it the more I decided that it was possible.
A TCP-based dictionary compressor (which I believe the Riverbed Steelhead appliances can do) would probably benefit an unencrypted rsync stream. Presumably the Riverbed devices can do encryption on the "optimized" traffic, so running rsync unencrypted shouldn't be compromising the integrity or confidentiality of traffic to the WAN. (Between the source server and the Riverbed device may be a different story.)
You don't have to run rsync over SSH. It will run perfectly fine over TCP or any other reliable stream transport.
It seems like a good WAN acceleration architecture would run somewhat counter to a good security architecture, since encrypted traffic would be high-entropy and low redundancy and not at all conducive to compression. I think these are concerns you'd have to balance. I haven't kept up with Riverbed in a number of years, but this actually seems like a place where man-in-the-middle decryption of encrypted protocols might make good sense (albeit that turns the WAN accelerator into a huge target for attacks).
Edit:
I'm coming back to this answer a few hours later because, frankly, it's keeping me up at night.
I want to clarify some assumptions that I'm making. I am assuming:
You're working with WAN links that are significantly slower than a LAN-- 100Mbps or less.
You're performing backups across these WAN links that you'd like to speed-up, in terms of wallclock time.
The servers hosting the source and destination files have sufficient CPU and network connectivity to completely saturate the WAN link and the WAN really is the bottleneck.
You're using operating systems with TCP implementations that can reasonably scale the receive window to accommodate the bandwith delay product of your WAN link.
If the servers can't saturate the network link then your bottleneck is somewhere else. Basically, I'm assuming that you've got a small pipe that your servers can saturate when running backups. If you're bottlenecking on CPU or I/O in the servers then no amount of network-related "magic" is going to help you.
Speaking rather bluntly, I feel a bit silly speaking positively about WAN acceleration appliances. I've been less than impressed with them in the past (mainly from an ROI and cost perspective) and wary of them after hearing numerous horror stories about application and operating system "strangeness" that would disappear when the WAN accelerators were disabled. I've been suspicious of them as a "technology" and generally have felt like they are a symptom of using poorly-engineered protocols, poor server-placement decisions, or poor network architecture.
I've spent the better part of two hours reading-up on dictionary-based protocol compressors and playing around with rsync. I think that, depending on the amount of redundancy in the changes you're synchronizing with rsync, there's actually a potential for seeing some minor performance improvement using a dictionary-based WAN accelerator. It's going to depend a lot on what your data looks like.
I don't have any numbers using an actual WAN accelerator to back that up. Nor do I have any personal experience with WAN accelerators in production use, let alone "accelerating" the rsync protocol. I certainly wouldn't go out and buy something based on what I'm saying here, but if you already have something in place I'd consider running some unencrypted rsync traffic through it to see what it does.
Best Answer
UDPSpeeder
One that showed up on HN recently was UDPSpeeder and may have what you were looking for. UDPSpeeder implements FEC. Apologies for answering several years late.