我的 2048 Kb/S ADSL 连接以预期的 220 KB/s 速度下载，但需要很长时间才能达到该速度，换句话说，最高速度不错，但加速很糟糕。这不是大容量下载的问题，因为速度最终会达到最大速率。问题在于通过 SSH 浏览或输入，因为它取决于数据包的初始速度，该速度可能低至 3 KB/s！延迟非常糟糕，ISP 无法理解这一点。尽管线路衰减（14.0）和 SNR 裕度（32.4）的值是可接受的
没有使用代理...
我在 Google 上找不到类似的答案。也许我无法描述问题？我不知道定义此问题的术语是什么（如延迟、数据包丢失）。我能告诉我的 ISP 什么？
编辑：这是输出traceroute google.com
笔记本电脑：〜$ traceroute google.com 跟踪路由到 google.com (173.194.38.102)，最大 30 跳，60 字节数据包
1 192.168.1.254 (192.168.1.254) 5.538 毫秒 5.772 毫秒 12.180 毫秒
2 * KHANKA-R01C-C-EG (163.121.170.229) 38.951 毫秒 53.544 毫秒
3 host-163.121.211.134.tedata.net (163.121.211.134) 1022.649 毫秒 1157.199 毫秒 1171.533 毫秒
4 host-163.121.211.134.tedata.net (163.121.211.134) 1368.481 ms 1392.954 ms 1456.449 ms
5 host-163.121.211.125.tedata.net (163.121.211.125) 1483.733 ms 1485.976 ms 1559.233 ms
6 10.42.0.3 (10.42.0.3) 2137.709 ms 984.750 ms 1311.599 ms
7 10.32.8.107 (10.32.8.107) 1184.654 ms 1188.532 ms 1529.284 毫秒
8 主机-163.121.215.194.tedata.net (163.121.215.194) 1537.709 毫秒 主机-163.121.209.170.tedata.net (163.121.209.170) 1525.038 毫秒 主机-163.121.215.194.tedata.net (163.121.215.194) 1784.301 毫秒
9 72.14.212.13 (72.14.212.13) 1779.373 毫秒 1863.601 毫秒 2083.181 毫秒
10 * 209.85.252.194 （209.85.252.194） 2598.120 毫秒 209.85.252.36 （209.85.252.36） 2643.383 毫秒
11 216.239.43.42 （216.239.43.42） 2670.846 毫秒 2674.115 毫秒 3114.124 毫秒
12 216.239.43.4 （216.239.43.4） 2970.444 毫秒 2983.826 毫秒 216.239.46.218 （216.239.46.218） 1316.574 毫秒 13
209.85.249.11 （209.85.249.11） 1287.924 毫秒 1309.304 毫秒 72.14.239.93 （72.14.239.93） 1309.548 毫秒
14 216.239.48.69 （216.239.48.69） 1327.934 毫秒 1333.812 毫秒 1418.224 毫秒
15 66.249.94.24 （66.249.94.24） 1426.165 毫秒 1435.831 毫秒 66.249.94.22 （66.249.94.22） 1434.125 毫秒 16
72.14.239.83 （72.14.239.83） 1642.336 毫秒 1647.606 毫秒 1663.440 毫秒
17 64.233.174.177 （64.233.174.177） 1767.621 毫秒 1806.839 毫秒 *
18 209.85.255.37 （209.85.255.37） 1554.591 毫秒 1483.272 毫秒 1498.464 毫秒
19 209.85.251.239 （209.85.251.239） 1301.597 毫秒 1308.220 毫秒 1319.829 毫秒
20 nrt19s18-in-f6.1e100.net (173.194.38.102) 1321.308 毫秒 1323.904 毫秒 1338.072 毫秒
答案1
仅凭您问题中提供的信息，我们真的无法帮助您。事实上，如果您收集到的信息只有这些，您甚至无法自救。故障排除有三条规则：
- 收集资料
- 收集资料
- 收集资料
可能还有其他一些规则，但它们都服从于前三条。您需要在分界点收集尽可能多的信息。无论您的 CPE 是什么（在您的例子中是 DSL 调制解调器），您都需要从中获取尽可能多的信息。轮询它以获取 SNMP 信息，从中获取系统日志，检查其手册以查找任何特殊 API，等等。
您还需要进行定时间隔测试，测试延迟、带宽、数据包丢失等。设置 SmokePing。使用计划的 iperf 脚本并记录相关信息。您（客户）始终有责任证明 ISP 是问题所在。除非另有发现，否则您和您的设备将被视为有罪。此外，您提供的证明您无罪的证据需要一式三份，并配有精美的图表和介绍音乐。
它可能像一些不稳定的拥塞控制一样简单（慢启动（我想到了）。这可能是 DSLAM 线路不好。可能是很多原因，但除非您从线路末端获取尽可能多的数据，否则您无法知道任何可能性。
总结
继续前进并收集数据。
答案2
如果延迟过高，那么您可能无法对 ssh 采取任何措施，因为 ssh 通常不需要速度，而是需要交互性。
对于网页浏览，如果您可以与延迟不那么严重的代理建立连接，则可能会有所改善（如果慢启动是问题的根源）。至少您与代理的连接将尽可能快，并且您可以将所有 Web 请求排队在另一端。