求教，推送的本质是什么？服务器如何向几百万台手机设备推送的信息的

设备向服务端发起一个连接, 并定时发送心跳包维持这个连接
通知到达后服务器通过这个连接向设备推送, 如果设备不在线就放进缓冲区等待设备上线

一般操作系统会提供一个统一的服务处理所有通知, 例如 Android 的谷歌 FCM 和 iOS 的苹果 APNS

FCM 在国内可以直连, 但没有优化线路所以效果一般, 没有其他谷歌服务使用也麻烦, 所以国产都做了自己的推送服务, 但也因此出现了碎片化, App 需要给不同厂商单独接入

APNS 要求 App 把推送信息交给苹果, 苹果直接把通知推到手机, FCM 则支持让推送唤醒 App, App 去获取实际内容并生成通知; 前者更省电, 但功能有限, 例如 Signal 这种端到端加密聊天因为服务端无法解密而无法通过 APNS 推送消息内容

---

客户端轮询也可以, 但想消除延迟就需要快速唤醒所以很耗电, 一般不建议使用

微信在国内会自己挂一个推送服务并将 FCM 作为备用推送渠道, 国外则会直接用 FCM

心跳包的发送频率应当根据网络环境自动调整

主要压力在服务器后端, 能用厂商提供的设施就不要自己做

本质上就是一个千万同时在线的 im 服务器而已，只不过这个场景，绝大多数 client 在大部分时间都是只保持一个心跳状态， 真的有推送了才会有信息交互。基本上用的应该都还是 tcp

对于 iOS 设备：

使用 Apple Push Notification Service (APNs)：每个 iOS 应用在注册推送通知后会获得一个唯一的 Device Token 。服务器端将要推送的消息、目标设备的 Device Token 以及其它必要参数封装成推送请求，发送给 Apple 的 APNs 服务器。
APNs 与每台 iPhone 、iPad 等设备维持一个持久连接（长连接）。
当服务器端发送推送消息时，通过与 APNs 的连接将消息转发至对应的设备。
设备收到推送消息后，即使应用不在前台运行，也能显示通知并将消息存储，用户点击通知时可以唤醒对应的应用。
对于 Android 设备：

Google Firebase Cloud Messaging (FCM) 或其他第三方推送服务：类似 iOS ，Android 设备也会通过相应的服务获取一个 Registration ID ，并将其发送给服务器。
服务器通过与 FCM 服务器接口交互，将消息和目标设备的 Registration ID 一起发送给 FCM 。
FCM 利用自身的长连接网络服务将消息分发到各个设备。
设备接收到消息后，根据消息类型显示通知，或者静默处理。

websocket MQTT

如前面说的,
就是设备向服务器建立一个 tcp 连接,然后这个连接基本可以看作永久不关闭, 设备或服务器定时通过这个连接发送 包,并检查是否收到回应.
如果设备发现这个连接存在问题,则重新建立一个连接替换掉原来的连接.

如果服务器需要通知设备,则直接通过这个连接向设备发送数据即可.

现在服务器性能是很不错的,应付大量的这种连接没什么问题.

服务器不可以主动请求设备吧？应该都是设备向服务器发送请求。你可以了解一下物联网常用的 MQTT

https://github.com/LockGit/gochat 即时通讯系统，可以了解下

https://github.com/LockGit/gochat 即时通讯系统，可以了解下

<img src="https://api.star-history.com/svg?repos=LockGit/gochat&type=Date"/>

@vcn8yjOogEL

> 前者更省电, 但功能有限, 例如 Signal 这种端到端加密聊天因为服务端无法解密而无法通过 APNS 推送消息内容

不是 ios 开发者，但是好像有个 notification service app extension [0] 可以被系统调用主动并处理通知

[0] https://developer.apple.com/documentation/usernotifications/modifying-content-in-newly-delivered-notifications

前几楼说的足够详细了，我简略说几句：
1 ，如果是应用自己的连接，那么需要程序运行，有一个公用的 socket 服务（通常是 tcp ），作为客户端，主动连接服务端，登陆后先发送自己的 id ，所以服务器可以随时下发信息。最典型的应用是所有的实时位置服务类应用，比如打车软件。
2 ，如果应用自己没做连接，则需要借助手机系统自身的推送来实现，手机厂商维护了一个公共的连接，可以转发，因此可以做到 app 没运行都被系统通知，然后通过点击来“叫醒”app

@vcn8yjOogEL
@coderxy
@bronyakaka
@gamexg
@gochat
@opengps
@haikea
@haikea
@zed1018
谢谢大家的分享！

服务器保持这么多 TCP 连接，会不会压力很大

看下极光 push ，国内每家安卓厂商都有自己的推送渠道，可以在不打开 APP 的情况下离线推送，但是需要每家厂商都配一遍，恶心死了。之前说的统一推送联盟直接没下文?

@awesomePower 只要处理得当，低配单机承载个几万很轻松，甚至十多万也可以（但由于维护困难，比如重启一下程序需要十几分钟才能完成所有连接的重新建立，所以会用多台低端机的方案）

tcp 长连接，server 可以随时写到 channel ，而不是不断的请求

@opengps 谢谢解答

对于这种单一的业务，完全可以用 DPDK 实现用户态协议栈，单机支持几百万连接问题不大。
对于很多特定场景的业务，很多大厂都在协议栈上下了很多功夫。

dperf 的 TCP 协议栈单机可以做到几十亿并发。https://github.com/baidu/dperf

@me1onsoda
@ben666
谢谢分享