虽然我确实知道 SSH 本身是一种带宽利用率非常低的协议，但它有时会在我们的办公环境中高峰时段占用带宽。我想知道是否有可能减少/优化 WAN 上的 SSH（rsync）流量？
我意识到 riverbed 无法做到这一点。我还能想到哪些其他设计（代理），忽略 MiTM、DPI 等安全问题。TrafficSqueezer、WANProxy 或 OpenNOP 在这里有用吗？
另外，请建议除了 rsync 之外还有其他备份数据的方法（如果有的话）。我是否可能想到在到达 Riverbed 并通过 WAN 将其传输到另一端之前使用代理服务器解密 SSH。
Sender (RSYNC) Server --> Proxy (Decrypt SSH) --> Sending Riverbed --> Receiving Riverbed --> Receiver Server
当前拓扑：
100's of Users (rsync) --> Source Riverbed --> (passed through traffic/unoptimized) --> Destination Riverbed --> Remote Machine
答案1
我最初对尝试“WAN 优化” rsync 流量的想法持反对态度，但我越想越觉得这是可能的。
基于 TCP 的字典压缩器（我相信 Riverbed Steelhead 设备可以做到这一点）可能会使未加密的 rsync 流受益。据推测，Riverbed 设备可以对“优化”流量进行加密，因此运行未加密的 rsync 不会损害 WAN 流量的完整性或机密性。（源服务器和 Riverbed 设备之间可能情况不同。）
您不必通过 SSH 运行 rsync。它可以通过 TCP 或任何其他可靠的流传输完美运行。
看起来，好的 WAN 加速架构与好的安全架构有些背道而驰，因为加密流量的熵高、冗余度低，根本不利于压缩。我认为这些都是你必须权衡的问题。我已经很多年没有关注 Riverbed 了，但这似乎是一个中间人解密加密协议可能很有意义的地方（尽管这会将 WAN 加速器变成巨大的攻击目标）。
编辑：
几个小时后我才回过头来思考这个问题，因为说实话，这个问题让我彻夜难眠。
我想澄清一下我所做的一些假设。我假设：
您正在使用的 WAN 链接明显比 LAN 慢 - 100Mbps 或更低。
您正在这些 WAN 链接上执行备份，并且希望加快速度（以挂钟时间计算）。
托管源文件和目标文件的服务器具有足够的 CPU 和网络连接，可以完全饱和 WAN 链路，而 WAN 确实是瓶颈。
您正在使用具有 TCP 实现的操作系统，可以合理地扩展接收窗口以适应 WAN 链路的带宽延迟产品。
如果服务器无法使网络链路饱和，则瓶颈就在其他地方。基本上，我假设您有一个小管道，您的服务器在运行备份时可以使其饱和。如果您的瓶颈是服务器中的 CPU 或 I/O，那么再多的网络相关“魔法”也帮不了您。
坦率地说，我对 WAN 加速设备持积极态度有点愚蠢。过去我对它们印象不深（主要是从投资回报率和成本角度来看），在听到许多关于应用程序和操作系统“奇怪”现象的恐怖故事后，我对它们持谨慎态度，这些现象在禁用 WAN 加速器后就会消失。我一直怀疑它们是一种“技术”，一般认为它们是使用设计不良的协议、糟糕的服务器放置决策或糟糕的网络架构的症状。
我花了两个多小时阅读基于字典的协议压缩器并试用 rsync。我认为，根据您使用 rsync 同步的更改中的冗余量，使用基于字典的 WAN 加速器实际上有可能看到一些轻微的性能改进。这在很大程度上取决于您的数据是什么样子。
我没有任何使用实际 WAN 加速器的数据来支持这一点。我也没有在生产中使用 WAN 加速器的个人经验，更不用说“加速”rsync 协议了。根据我在这里所说的，我当然不会出去买东西，但如果你已经有了一些东西，我会考虑通过它运行一些未加密的 rsync 流量，看看它能做什么。
答案2
当然可以参见以下答案：为什么我的 rsync 这么慢？
多年来，我一直依赖基于 rsync 的解决方案进行复制和备份。我从未需要使用任何形式的 WAN 加速（使用设备）。
多年来，我的 rsync 方法已经进化了；从基本的压缩到使用“-e ssh -c arcfour”作为轻量级密码，再到使用抗凝血酶能够控制 TCP 窗口并禁用长距离链路上的加密，最近，使用 UDR/UDT 包装 rsync进行基于 UDP 的 rsync 传输。我应该补充一点自定义测试类型是一些 WAN 加速产品在市场上。
这些都是非常深奥的解决方案，但我真的希望从了解您今天在做什么开始。让我们看看您当前的 rsync 命令字符串，并尝试看看它们是否可以优化。
- 您正在备份什么？
- 目标距源有多远？
- 您的带宽能力/限制是什么？
编辑：
你谈论的是二进制数据在 400Mbps 带宽能力下进行长距离传输。这似乎是多条双向流量在一天中的随机时间触发。
如果您担心带宽饱和，那么您是否可以简单地使用以下命令限制 rsync 传输的速率：
--bwlimit=KBPS limit I/O bandwidth; KBytes per second
或者如果你的网络设备有能力，这可能会成为流量整形或服务质量锻炼。但最终，这似乎是一个人/政策的问题。
编辑：
我的建议优德默认情况下，通过 UDP 端口 9000-9100 发送未加密的 rsync。与在守护进程模式下运行 rsync 相比，这不需要对命令行进行太多更改。是可能在您的 Riverbed 单元可以解决的范围内。从您最初的问题来看，范围、用户数量或您是否已安装 WAN 加速器尚不清楚。