我在 Amazon EC2 上有一个实例，它保存着一个较大的文件（~180MB）。我需要将该文件复制到本地计算机，因此我自然而然地尝试了scp。在多次尝试后，我只能获得 20-30kb/s 的最大速度并断开连接（只有一次我短暂地达到了 ~200KB/s，但随后连接断开），我尝试了 HTTP。通过 HTTP，我获得了 1MB/s，然后上升到 2MB/s，在两分钟内完成了传输。通过 scp，预计到达时间约为三个小时。
我知道scp由于加密，HTTP 比 HTTP 慢，但我认为单凭这一点不足以解释性能下降约 30 倍的原因。所以我猜想可能存在某种限制，可能是我的 ISP。有什么方法可以确定吗？还是有其他原因？
答案1
网络节流的典型特征是速度接近恒定（在 10-20KB/s 左右），因此如果您受到节流，则需要注意这种模式。另一种模式是“聚集”或“爆发”，即您获得一两秒的高速连接，然后是一段时间的低速连接。如果是这种情况，您的问题更有可能是某个时刻的缓冲/缓存。
通常，您的 ISP 的上游路由设备将配置为 QoS HTTP（或更具体地说，端口 80）流量，其优先级高于所有其他流量，因为他们的大多数客户都会浏览网页（这并不完全正确），他们不希望别人的 SCP/FTP/Skype/点对点流量阻塞他们的管道。
据我所知，Amazon 本身并不对其实例应用任何 QoS。也就是说，您可能会遇到 CPU 受限问题，尤其是当您运行具有低功耗（或低优先级）CPU 资源的 t1.micro（或其他小型）EC2 实例时。检查您的 CPU 窃取百分比（运行top并检查右上角的 %st 值）以查看您的 CPU 是否被其他 EC2 实例“窃取” - 这通常是低使用率实例的情况 - CPU 窃取允许 Amazon 从休眠/空闲实例中回收 CPU 周期以满足需求。
答案2
SSHD 有一些与安全和 TCP 卡住相关的开销。这就是为什么它比较慢，您可以使用 scp-hpn 补丁，它更快！您可以在 http://www.psc.edu/index.php/hpn-ssh
答案3
可能是您的 ISP 或 Amazon 在进行限制。Amazon 应用高度优先考虑 HTTP 的 QoS 是合理的，因为这是他们最常见的用例。
您可以使用 netcat 通过每个端口发送流量进行测试。您还可以重新配置 SCP (sshd) 以通过端口 80 运行，并查看获得的速度（反之亦然，重新配置您的 Web 服务器以通过端口 22 运行）。