【发布时间】：2011-05-24 06:01:23
【问题描述】：
我注意到 Google C2DM (push) tcp 连接使用端口 5228。我还知道一些防火墙会阻止 80 443 以外的端口（因为 htttp 和 https），这导致很多用户抱怨他们不能例如，使用公司 wifi 在手机上使用 Market 应用或 GTalk。
现在我的问题是：为什么 Google 没有选择 443 或 80 端口作为他们的持久 tcp 连接？
【问题讨论】：
标签： android-c2dm
【发布时间】：2011-05-24 06:01:23
【问题描述】：
我能想到 Google 可能选择使用 5228 而不是 80 或 443 的原因有几个。
首先，在大多数（但绝对不是全部）情况下，5228 应该不是问题（即被阻止），因为推送通知主要在设备移动时使用。这意味着他们使用的手机数据连接不会阻止此端口并且没有防火墙。
其次，在可能存在防火墙的环境中（即公司内部有 WiFi），http 流量也可能以某种方式被代理或控制。 C2DM 不依赖于标准的 HTTP 协议，预计将是一个长期的连接。这意味着在 80/443 上运行它可能会在这些环境中导致问题。
第三，这些服务很可能在 C2DM 发布之前使用 5228，并且没有明确的理由来更改它。
根据我的经验，我认为如果他们使用 5228 作为默认值，并在其他情况下尝试回退到 443，那将是理想的（因为在很多情况下 443 可以工作而 5228 不会工作） ）。至少在 443 的情况下，修改数据的可能性低于在端口 80 上的情况，因为协议通常会被加密。但是，443上的连接还是有可能提前终止的。但是，这种风险在任何网络环境中都存在，尝试也不会失败。
另外，在 443 上启用 C2DM 可能比 Google 看起来更困难，因为他们的分布式前端服务器可能知道如何专门处理 80/443 流量作为 HTTP 并且需要大量重新- 处理 C2DM。
【讨论】：
-
很好的解释！我只是想知道如何决定是否回退到443？我这样说是因为可能存在其他情况，例如没有互联网连接，这与 wifi 阻塞某些端口无法区分。我没有调查过这个，但这似乎是正确的做法。谢谢！
-
您认为运营商是否仅根据端口号限制/切断短连接？或者他们是否将例如 google ip 列入白名单，在这种情况下端口号选择无关紧要？
-
它们可能会限制某些端口 - 但我怀疑端口 80 或端口 443 或任何任意端口的情况。更有可能是用于文件共享的常用端口（但在大多数情况下，这些端口是随机的，更有可能需要某种类型的流量嗅探来进行整形）。我怀疑 Google 的流量是否得到任何特殊处理。
-
保持活动超时怎么办？您对哪些值是安全的有任何指示吗？
我怀疑他们想要获得其他东西的标准端口，这样他们就可以轻松监控 C2DM 流量的流量水平。
他们并不孤单，Apple 的推送实现也完全一样。
【讨论】：