我在Amazon EC2上有一个实例，它包含一个大型文件（〜180MB）。 我需要将该文件复制到我的本地机器，所以自然我尝试了scp 。 经过多次尝试，最高速度达到20-30kb / s，连接断开（我只有一次达到〜200KB / s一段时间，但连接断开），我尝试了HTTP。 通过HTTP，我得到了1MB / s，并上升到2MB / s，在两分钟内完成转移。 在scp上，ETA大概是三个小时。
我知道，由于encryption， scp比HTTP要慢，但是我不认为这可能会导致性能降低大约30倍。 所以我猜测有一些节stream，可能是在我的ISP。 任何方式我可以find肯定？ 还是有其他原因？
networking节stream的典型特征是接近恒定的速度（在10-20KB / s左右），所以如果你被扼杀，这是一个寻找的模式。 另一种模式是“聚束（bunching）”或“突发（burst）”，其中高速连接需要一秒或两秒钟，然后是低速连接。 如果是这样的话，你的问题更可能是缓冲/caching在某个时刻。
通常情况下，您的ISP的上游路由设备将被configuration为具有比所有其他stream量更高优先级的QoS HTTP（或者更具体地说，端口80）stream量，其中大多数客户将浏览网页（并非完全不正确）他们不希望别人的SCP / FTP / Skype /点对点stream量阻塞他们的pipe道。
亚马逊本身并没有将任何QoS（我知道的）应用于他们的实例。 也就是说，你可能会碰到CPU绑定的问题，特别是如果你正在运行一个低功耗（或低优先级）CPU资源的t1.micro（或其他小型）EC2实例。 检查你的CPU窃取百分比（运行在top并检查top的％st值），看看你的CPU是否被其他EC2实例“盗取” – 这是低使用率情况下的典型情况 – CPU窃取允许亚马逊从hibernate/空闲实例中回收CPU周期以满足需求。
SSHD有一些与安全和TCP卡住有关的开销。 这就是为什么它是慢的，你可以使用scp-hpn补丁，这是更快！ 你可以在http://www.psc.edu/index.php/hpn-ssh看到更多
它可能是你的ISP或亚马逊的节stream。 对亚马逊来说，应用严重偏好HTTP的QoS是有意义的，因为这将是他们最常见的用例。
您可以使用netcat通过每个端口发送stream量来testing。 您也可以重新configurationSCP（sshd），使其通过端口80运行，并查看您获得的速度（反之亦然，重新configurationWeb服务器以通过端口22运行）。