问题描述
|
我注意到Google C2DM（推送）tcp连接使用端口5228。我也知道某些防火墙阻止80 443以外的端口（由于htttp和https），这导致许多用户抱怨他们无法使用例如，使用公司的wifi在手机上推广应用或GTalk。
现在我的问题是：为什么Google不选择端口443或80作为其持久的TCP连接？
解决方法
我能想到的一些原因是Google可能选择使用5228而不是80或443。
首先，在大多数（但绝对不是全部）情况下，5228不应成为问题（即被阻止），因为在设备移动时大量使用推送通知。这意味着他们使用的手机数据连接不会阻塞该端口，也不会进行防火墙保护。
其次，在可能存在防火墙的环境中（即公司内部具有WiFi），http流量也可能以某种方式被代理或控制。 C2DM不依赖于标准的HTTP协议，并且有望成为长期的连接。这意味着在80/443上运行它可能会在这些环境中引起问题。
第三，这些服务可能在C2DM发行之前就使用5228，并且没有明确的理由对其进行更改。
根据我的经验，我认为如果他们使用5228作为默认值，并在其他情况下尝试回退到443（因为在5228不能使用443的情况下肯定有很多情况），那将是理想的选择。至少在443的情况下，数据修改比在端口80上修改的可能性小，因为该协议通常会被加密。但是，仍然有可能在443上过早终止连接。但是，此风险存在于任何网络环境中，并且尝试时不会出现故障。
另外请注意，在443上启用C2DM可能要比Google看起来困难得多，因为它们的分布式前端服务器可能知道如何专门将80/443流量作为HTTP进行处理，并且需要进行大量修改才能处理C2DM。
,我怀疑他们想获取其他标准端口，这样他们就可以轻松监控C2DM流量水平。
他们并不孤单，Apple的推送实施完全相同。