推送到手机的通知真的是推送的吗？
Are pushed notifications to mobile phones really pushed?
我知道可以使用 http/s 将通知推送到服务器，但手机真的可以从这些服务器推送到吗？从技术上讲，我猜测移动设备实际上会轮询通知服务器以查看是否有任何新通知，这是一种 'pseudo push'.
所以这就是我的问题 - 手机是否真正接收实时推送通知，或者它们实际上是在轮询？我问的原因是，当用户四处走动时，移动电话在网络上拥有一个持续开放的桅杆通道似乎是非常昂贵的。有人知道技术细节是什么吗？
云 Google 服务器上只有一个 TCP 套接字在接受模式下等待。 Goggle Play 应用程序已启动 TCP 连接。这就是为什么必须在设备上安装 Google Play 才能使 Google 云消息传递 (GCM)（以前称为 Android 云到设备消息传递服务 - C2DM）工作。
当此 TCP 客户端套接字接收到一些消息时，该消息包含信息，例如它应该寻址到的应用程序的包名称，当然还有数据本身。此数据被解析并打包到一个意图中，该意图被广播并最终被应用程序接收。
即使设备的无线电状态变为 "idle" 模式，TCP 套接字仍保持打开状态。应用程序不必 运行 接收意图。
Apple 推送通知通过 TCP 连接传送到设备。 iOS 设备在 port 5223 上启动 TCP 连接（如果无法到达 5223，则在 WiFi 上回退到 443）。
建立 TCP 会话后，只需很少的流量即可保持 TCP 连接活动 - 只需一个偶尔的保持活动数据包。
发送推送通知时，Apple 服务器会查找与设备的现有连接。如果找到连接，则数据流将通过已建立的连接发送，因此从这个意义上讲，它是 "push"。
如果没有与目标设备的现有连接，则消息将保留在 Apple 服务器上，直到设备连接（或消息过期），因此在这个级别它更像是 "pull" -设备在可以时启动连接。
我想 GCM 的工作方式类似。
我知道可以使用 http/s 将通知推送到服务器，但手机真的可以从这些服务器推送到吗？从技术上讲，我猜测移动设备实际上会轮询通知服务器以查看是否有任何新通知，这是一种 'pseudo push'.
所以这就是我的问题 - 手机是否真正接收实时推送通知，或者它们实际上是在轮询？我问的原因是，当用户四处走动时，移动电话在网络上拥有一个持续开放的桅杆通道似乎是非常昂贵的。有人知道技术细节是什么吗？
云 Google 服务器上只有一个 TCP 套接字在接受模式下等待。 Goggle Play 应用程序已启动 TCP 连接。这就是为什么必须在设备上安装 Google Play 才能使 Google 云消息传递 (GCM)（以前称为 Android 云到设备消息传递服务 - C2DM）工作。
当此 TCP 客户端套接字接收到一些消息时，该消息包含信息，例如它应该寻址到的应用程序的包名称，当然还有数据本身。此数据被解析并打包到一个意图中，该意图被广播并最终被应用程序接收。
即使设备的无线电状态变为 "idle" 模式，TCP 套接字仍保持打开状态。应用程序不必 运行 接收意图。
Apple 推送通知通过 TCP 连接传送到设备。 iOS 设备在 port 5223 上启动 TCP 连接（如果无法到达 5223，则在 WiFi 上回退到 443）。
建立 TCP 会话后，只需很少的流量即可保持 TCP 连接活动 - 只需一个偶尔的保持活动数据包。
发送推送通知时，Apple 服务器会查找与设备的现有连接。如果找到连接，则数据流将通过已建立的连接发送，因此从这个意义上讲，它是 "push"。
如果没有与目标设备的现有连接，则消息将保留在 Apple 服务器上，直到设备连接（或消息过期），因此在这个级别它更像是 "pull" -设备在可以时启动连接。
我想 GCM 的工作方式类似。