DevOps知识中心
DevOps知识中心

使用 ZLib 压缩优化 SSH 性能的完整指南

精通使用 ZLib 压缩优化 SSH 性能。本全面指南将解释何时以及如何利用 ZLib，以实现最大数据传输效率和提升终端响应速度，尤其是在低带宽或高延迟连接上。学习客户端和服务器端配置、最佳实践以及实用示例，以优化您针对高度重复数据的 SSH 工作流程，从而确保更快、更流畅的远程交互。让您的 SSH 会话事半功倍。

39 浏览量

使用 ZLib 压缩优化 SSH 性能的完整指南

安全外壳 (SSH) 是远程访问不可或缺的协议，可实现设备之间的安全通信通道。虽然其主要优势在于安全性，但数据传输效率和交互式会话的响应速度有时会成为瓶颈，尤其是在高延迟或低带宽连接上。对于任何依赖 SSH 进行开发、系统管理或数据传输的人来说，优化 SSH 性能至关重要。

本指南深入探讨了一种最有效的 SSH 优化技术：ZLib 压缩。我们将探讨 ZLib 压缩在 SSH 协议中的工作原理，确定它能带来最显著优势的场景，并提供在客户端和服务器端启用和配置它的详细说明。阅读完本文，您将全面了解如何利用 ZLib 最大限度地提高 SSH 数据传输效率并增强终端响应速度。

理解 SSH 性能和压缩

SSH 性能会受到多种因素的影响，包括网络延迟、可用带宽以及传输数据本身的性质。例如，在慢速连接上传输大型文本文件、日志归档或与冗长的命令行应用程序进行交互可能会感觉迟缓。这时压缩就派上用场了。

ZLib 压缩是一个广泛使用的数据压缩库，在压缩率和速度之间取得了良好的平衡。当集成到 SSH 中时，ZLib 会在数据加密并通过网络发送之前对其进行压缩，并在接收后进行解压缩。这会减少传输的总数据量，从而可能加快传输速度并提供更快的响应体验。

ZLib 在 SSH 中的工作原理

启用 SSH 压缩时，客户端和服务器会协商使用 ZLib。一旦建立连接，任何数据负载（例如，shell 输出、scp/sftp 期间的文件内容）都会由发送方压缩，由接收方解压缩。实际的 SSH 协议开销，如头部和加密密钥，通常不会被压缩。SSH 客户端和服务器中的 Compression 选项通常指的是 ZLib 压缩。

何时使用 SSH 压缩（以及何时不使用）

启用压缩并非万能解决方案；其优势高度依赖于您的具体用例和网络条件。了解何时应用它是在进行真正优化时关键。

SSH 压缩的理想场景

  • 低带宽连接：当您的网络连接带宽有限时（例如，DSL、卫星互联网或拥挤的 Wi-Fi），减少传输数据量可以显著提高有效吞吐量。通过传输较少数据节省的时间远远超过了用于压缩/解压缩的 CPU 周期。
  • 高延迟连接：即使有不错的带宽，高延迟也会让交互式 SSH 会话感觉不响应。压缩可以带来巨大改善，因为它能确保数据在传输时尽可能紧凑，从而减少大型输出的“首次字节到达时间”。
  • 传输高度重复的数据：文本文件、日志文件、配置文件、源代码以及其他形式的结构化或半结构化数据通常包含高度冗余。ZLib 在压缩此类数据方面非常有效，可大幅减小尺寸。
  • 具有冗长输出的交互式终端会话：如果您经常运行产生大量文本输出的命令（例如，dmesg、journalctl、大型存储库上的 git log），压缩可以使这些输出在您的终端中显示得更快。

何时避免或谨慎使用 SSH 压缩

  • 高带宽、低延迟的局域网连接：在快速的局域网中，压缩和解压缩数据的开销可能会消耗比节省的数据传输时间更多的 CPU 周期。在这种情况下，网络链路可能不是瓶颈，CPU 使用率成为限制因素。
  • 传输已压缩的数据：尝试压缩已压缩的文件（例如，JPEG 图像、MP3 音频、ZIP 归档、GZipped 文件、MP4 视频）效果不大。ZLib 几乎找不到进一步的冗余，只会产生微不足道的尺寸减小，并增加不必要的 CPU 开销。
  • CPU 密集型系统（客户端或服务器）：如果您的客户端机器或 SSH 服务器已经处于重度 CPU 负载下，启用压缩可能会加剧性能问题而不是解决它们。监控 CPU 使用率，确保压缩不会增加过度的压力。

在 SSH 中启用 ZLib 压缩

SSH 压缩可以在客户端、服务器端启用，或者通过配置文件进行持久化设置。

客户端配置

您通常从本地机器（SSH 客户端）控制压缩。

1. 使用 -C 命令行选项

为单个 SSH 命令启用压缩的最简单方法是使用 -C 标志：

ssh -C user@hostname
scp -C local_file user@hostname:/remote/path
sftp -C user@hostname

此选项强制为该命令发起的特定会话进行压缩。它适用于测试或一次性传输，您知道压缩会有益。

2. 使用 ~/.ssh/config 文件

要为特定主机或所有主机进行持久化压缩，您可以编辑 SSH 客户端配置文件，在类 Unix 系统上通常位于 ~/.ssh/config。如果文件不存在，您可以创建它。

# 默认情况下为所有主机启用压缩
Host *
    Compression yes

# 仅为特定主机启用压缩
Host my_remote_server
    HostName 192.168.1.100
    User remote_user
    Compression yes
    Port 2222

# 为特定主机禁用压缩（覆盖全局设置）
Host fast_lan_server
    HostName 10.0.0.5
    Compression no

指令说明：

  • Host *: 将以下设置应用于所有 SSH 连接，除非被更具体的 Host 块覆盖。
  • Host my_remote_server: 仅当您使用 ssh my_remote_server 连接时应用设置。
  • Compression yes|no: 为指定主机或全局明确启用或禁用压缩。

服务器端配置（可选，但推荐用于控制）

虽然客户端启用通常足以协商压缩（如果服务器支持），但 SSH 服务器 (sshd) 也有与压缩相关的配置选项。这些选项通常位于 /etc/ssh/sshd_config。

1. Compression 指令

默认情况下，sshd 通常允许在客户端请求时进行压缩。但是，您可以显式设置它：

# /etc/ssh/sshd_config
Compression yes

在服务器上设置 Compression yes 允许服务器接受并处理来自客户端的压缩请求。将其设置为 no 将禁用压缩，即使客户端请求了它。

2. 带 delayed 的 Compression 指令（OpenSSH 6.7+）

为了获得最佳服务器性能，尤其是在处理大量并发连接时，OpenSSH 引入了 Compression delayed 选项。此设置会延迟压缩的启动，直到用户成功通过身份验证为止。这可以防止将不必要的 CPU 周期浪费在压缩身份验证尝试（通常很小且非重复）上，这些尝试可能来自恶意或机器人客户端。

# /etc/ssh/sshd_config
Compression delayed

如果您修改了 /etc/ssh/sshd_config，则必须重启 sshd 服务才能使更改生效：

# 在使用 systemd 的系统上（例如，Ubuntu、CentOS 7+）
sudo systemctl restart sshd

# 在使用 init.d 的系统上（例如，较旧的 Debian/Ubuntu）
sudo service ssh restart

# 在使用不同 init 系统的系统上
sudo /etc/init.d/ssh restart # 或类似命令

实际示例和用例

让我们看看压缩如何转化为实际的好处。

示例 1：使用 scp 传输大型日志文件

假设您需要通过相对较慢的连接从远程服务器下载一个多 GB 的日志文件。该日志文件（application.log）包含高度重复的文本数据。

不带压缩：

time scp user@remote_host:/var/log/application.log .

带压缩：

time scp -C user@remote_host:/var/log/application.log .

通过添加 -C，scp 命令将使用压缩。您可能会观察到传输时间显著减少，特别是如果日志文件压缩效果良好。

示例 2：提高 SSH 上的 rsync 性能

rsync 也可以利用 SSH 压缩。当 rsync 使用 SSH 作为其传输协议时，您可以通过 rsync 的 -e 选项将 -C 标志传递给 SSH。

rsync -avz -e "ssh -C" /local/path/to/sync user@remote_host:/remote/destination/
  • -a: 归档模式（保留权限、时间戳等）
  • -v: 详细输出
  • -z: rsync 自身的压缩（在 SSH 加密文件数据之前）。这通常是额外与 SSH 压缩一起使用的，因为 rsync -z 会在数据被传递给 SSH 之前进行压缩，然后 ssh -C 会进一步压缩由此产生的流。对于慢速链接上的高度可压缩数据，这种组合可能非常强大。
  • -e "ssh -C": 指定 ssh -C 作为远程 shell。

示例 3：增强交互式 Shell 响应速度

在大型文件系统上运行 ls -lR / 等命令或获取冗长的诊断输出时，压缩可以减少输出开始显示和打印完成之前的时间延迟。

ssh -C user@hostname "ls -lR /"

与在糟糕的网络连接上进行非压缩会话相比，这将使交互式体验感觉更加流畅。

衡量压缩的影响

要真正理解其好处，您需要衡量更改前后的性能。time 等工具（如示例所示）可以衡量总执行时间。对于网络吞吐量，您可以使用 iperf3（尽管这测量的是原始网络速度，而不是 SSH 开销）。最直接的方法是比较实际的文件传输时间和观察交互式会话的响应速度。

您还可以使用 ssh -v 查看详细的调试输出，这偶尔会指示压缩使用情况，但直接的性能测量更具指示性。

最佳实践和高级技巧

  • 在您的环境中进行测试：始终使用您的特定网络条件和数据类型测试压缩。一种场景有效的做法可能对另一种场景有害。
  • 监控 CPU 使用率：在启用压缩的情况下进行大量传输或长时间交互式会话期间，检查客户端和服务器上的 CPU 负载。如果 CPU 使用率异常飙升，压缩可能会适得其反。
  • 与其他优化结合使用：压缩只是 SSH 优化的一个方面。考虑将其与以下结合使用：
    • 连接多路复用：重用现有的 SSH 连接（~/.ssh/config 中的 ControlMaster、ControlPath）以避免重复的握手开销。
    • 密码选择：如果安全要求允许，选择更快的密码（例如，[email protected]、[email protected]），因为某些密码比其他密码占用的 CPU 更少。
    • KeepAlive 设置：使用 ServerAliveInterval 和 ClientAliveInterval 防止连接因不活动而断开。
  • 配置要具体：不要在 ~/.ssh/config 中全局启用 Compression yes，而是使用 Host 块将其仅应用于您知道它会有益的主机。

结论

SSH 中的 ZLib 压缩是一种强大的性能优化工具，尤其是在带宽受限或延迟高昂的环境中，或在处理高度重复的数据时。通过减少传输的数据量，它可以显著加快文件传输速度并提高交互式会话的响应速度。

然而，它并非一刀切的解决方案。理解其底层机制并仔细评估您的具体用例、网络条件和系统资源对于有效实施至关重要。通过遵循本指南中提供的说明和实际示例，您可以掌握 SSH 压缩的使用，并确保您的远程交互尽可能高效和富有成效。