通过在端口 443 上使用 ssh 来避免流量整形答案

【问题标题】：Avoid traffic shaping by using ssh on port 443通过在端口 443 上使用 ssh 来避免流量整形
【发布时间】：2010-09-06 20:04:24
【问题描述】：

我听说如果你使用 443 端口（通常用于 https 的端口）进行 ssh，加密的数据包在你的 isp 看来是一样的。

这是否可以避免流量整形/限制？

【问题讨论】：

标签： linux ssh https trafficshaping

【解决方案1】：

我不确定任何给定的 ssh 数据包“看起来”是否与任何给定的 https 数据包相同。

但是，在他们的一生中，他们的行为方式并不相同。会话设置和拆除看起来不一样（一方面，SSH 在初始连接期间提供纯文本横幅）。此外，通常 https 会话不会是短暂的吗？连接、获取数据、断开连接，而 ssh 会连接并持续很长时间？我认为也许使用 443 而不是 22 可能会通过简单的过滤器，但我认为它不会欺骗专门寻找主动尝试绕过过滤器的人。

限制 ssh 是否经常发生？我经历过有人阻止它，但我认为我没有经历过节流。哎呀，我通常使用 ssh 隧道绕过其他块，因为人们通常不关心它。

【讨论】：

HTTP/1.1 会话可以是持久的。

【解决方案2】：

443 在用于 HTTPS 时，依赖 SSL（不是 SSH）进行加密。 SSH 看起来与 SSL 不同，因此这取决于您的 ISP 实际在寻找什么，但他们完全有可能检测到差异。不过，根据我的经验，您更有可能看到一些个人防火墙软件阻止这种行为，因为它是非标准的。幸运的是，使用某种类型的 SecureSocket 编写 SSL 隧道非常容易。

一般来说，他们可以看到您使用了多少带宽，无论流量是否加密。他们仍然会知道连接的端点、打开了多长时间以及发送了多少数据包，所以如果他们将他们的整形指标基于这类数据，那么你真的无法阻止他们限制你的连接。

【讨论】：

通过隧道程序过滤 ssh 输入/输出（stunnel 没有提供类似的东西吗？），您可以在初始 SSH 握手之前使用 CONNECT 预先（和剥离）未使用的 HTTP 标头。

【解决方案3】：

您的 ISP 可能更有可能通过 22 传输形状端口 443，因为 22 需要更高的实时响应能力。

虽然不是真正的编程问题，也许你会在其他地方得到更准确的回答..

【讨论】：