我注意到Google C2DM（推送）tcp连接使用端口5228。我还知道，一些防火墙会屏蔽80 443以外的端口（因为htttp和https），这导致许多用户抱怨他们无法使用公司wifi在手机上使用Market应用程序或GTalk。
现在我的问题是：为什么谷歌没有选择443或80端口作为他们的持久tcp连接？
我能想到的原因有几个，谷歌可能选择使用5228而不是80或443。
首先，在大多数（但肯定不是所有）情况下，5228应该不是问题（即被阻止），因为推送通知主要用于设备移动时。这意味着他们使用的手机数据连接不会阻塞该端口，也没有防火墙。
其次，在可能有防火墙的环境中（即公司内部有WiFi），http流量也可能以某种方式被代理或控制。C2DM不依赖于标准的HTTP协议，预计它是一种长寿命的连接。这意味着在80/443上运行它可能会在这些环境中引发问题。
第三，在C2DM发布之前，这些服务可能使用5228，并且没有明确的理由更改它
根据我的经验，我认为如果他们使用5228作为默认值，并在其他情况下尝试回落到443，那将是理想的（因为在许多情况下，443可以工作，而5228不可以）。至少在443的情况下，修改数据的可能性比在端口80上修改的可能性小，因为协议通常是加密的。然而，连接仍有可能在443上提前终止。然而，这种风险在任何网络环境中都存在，尝试不会失败。
另外，在443上启用C2DM可能比谷歌看起来更困难，因为他们的分布式前端服务器可能知道如何将80/443流量专门处理为HTTP，并且需要大量的重新工作来处理C2DM。
我怀疑他们想获得其他东西的标准端口，这样他们就可以轻松监控C2DM流量的流量水平。
他们并不孤单，苹果在推送实现方面也做了同样的事情。