抖音上评论后如果有人点赞我的评论，会马上收到气泡提醒，这是什么原理实现的？

你说微信是什么原理？

Websocket 吧

websocket 有点复杂了吧，应该是收到点赞然后调用通知的方法

可能是:用户点赞，事件加入消息队列，服务器异步推送消息给你

2、3 楼的评论什么鬼？

排除法，先说 websocket, 如果是 websocket,那么后台还要给每一个维护一个心跳，就为了给你一个通知？代价大，资源耗不起。所以不可能。

不是 websocket,代价太大，

当前用户在活跃状态下，必然要维持一个长连接，是不是 websocket 都差不多。
一对一的推送消耗没那么大，群聊实时推送才惊人。

推送解决不了？

和 websocket 有半毛钱关系？

这都是业内常见解决方案了，你不知道说明你不适合这个行业

推送透传消息吧

4 楼的思路，倒有可能。头条的 v2er 可以出来讲下

不负责任的瞎猜 HTTP/2 server push

push sdk，通用方案

@x7395759 你详细说说

如果单说 App 端，就是消息推送啊

移动推送中的透传啊

消息推送服务啊。

透传

推送+长连方式(长连不一定是 ws)
应用内用长连是很正常的, 应用外用 app push.

推送，接收到改变下状态就好了

这如果要有点赞和 diss 的话就好了。 哈哈哈哈

推送

什么是气泡提醒？

不就是一推送么

@shawndev 你这一看就是道听途说了一些 http2 的内容，server push 和常规理解（你的理解） 的推送根本不是一个推送。

@vance
@zwh2698
@zk123
楼上几位 不同意是 WS,那请问会是什么的? 另外 push sdk 是通过什么实现的?


@Sapp 看了下 HTTP2 push 大概是说 推送 css 之类的? 这样的话 貌似的确 和我之前理解的很不一样.

就不#某一楼了，不过一个消息处理的小技巧或者知识点。
就上升到不知道就不适合这个行业了。
我就好奇了，以这个规模的问题为标准，随便抛一个不知道就不适合行业了。
那估计“这个行业”就要结束了。
比不知道更可怕的是自大。

如果 ws 是因为长连接代价太大的话，难道推送就不靠长连接了咩。。。

我觉得楼上说透传的就像 leetcode 用标准库直接排序一样。:-)

消息队列？

@Sapp 翻了一下文档，如你所说。server push 由 web 服务器配置，并行加载网页资源。而不是在获取 html 后解析当中用到的资源再请求。

为啥不能是 websocket ？ push sdk 不用长链接吗，靠什么实现的？

socket 或者 mqtt 治疗的长连接 后端是 消息队列

我之前做过 Android 和 iOS , 做的应用使用的是 消息推送 SDK 。
Android 使用的 小米 /华为 , 应用在前台透传,应用在后台通知栏推送。
iOS 的用的是系统的 APNs , 机制和 Android 类似。

缺点是不论 Android 和 iOS , 集成系统的消息推送都有延迟。
我们公司当时没有即时通讯的业务,前台、后台 消息推送一把梭哈 , 所以经常被用户投诉,别人回复消息,自己收不到。
但是应用在后台的时候,只能使用系统的消息推送。

因此,像微信这类即时通讯软件,应用在前台用的是自己的长连接,在后台用的是系统的推送 。

至于抖音,没有了解过,如果为了保证推送的及时率和成功率,应该采取和微信一样的机制。
如果抖音比较懒的话，那就用直接用系统的推送。

具体 IM 的原理 和 Android 消息推送原理 与 APNs。因水平有限，我也没做过这些，就不评论了。

@liyaoo 抖音，评论过后，继续浏览其它视频。如果有人赞了你的评论或者回复了你的评论。底部“消息”那个按钮就会浮出一个气泡提醒你。

应该就是类似 push 的推送,可能加入厂商白名单,可以长期保活接通知吧

都是什么鬼。没用过抖音，只说即时通讯。

如果要做到及时提醒，那肯定是有一个长链接的，不管是 http2、websocket、mptt，以上都是应用层协议，不管传输层是基于 tcp 还是 udp，本质都是一个长链接。推送就是用长链接实现的，不然你以为 server 端的消息怎么主动推到 client?

关于长链接维持，纯技术角度而言，长链接就不需要维持，如果网络正常且中间路由不做任何处理，就算没心跳，你一年后这个 tcp 依然能通讯。心跳只是业务层的逻辑（ tcp 的 keepalive 算是协议层），心跳是可以优化的，有的可能几分钟一次心跳。

关于长链接的维持，微信十几亿用户都能做，抖音几亿用户为啥不能做？

个推推送 极光推送

这么多人不知道前台服务吗？

@bengcaca v2 还是有靠谱的回答的

区分一下：
1，消息推送
2，某种长连接的 socket
显然是 2，非常轻便。1 的成本很高。

ws push server init

websocket 那门子的成本高了呀……

@bengcaca 心跳就是为了维持长连接吧，否则移动网络那么复杂，而且还各种网络切换，肯定出现会掉线。

@hyyou2010 #44

1 和 2 能放到同级吗？ 1 是功能，2 是可能的实现方式

@okwork 心跳是为了维持长链接，这是业务层的，但从 tcp 协议层本身来讲，长链接不一定需要心跳，这个区分还是应该要清楚的。

如果实现得当，心跳可以根据不同的网络状况设置不同的间隔时间，比如 3G 网络下可能 30s，4G 情况下 1 分钟，wifi 情况下 5 分钟，具体值还可以根据历史网络状况做动态调整，当然这都属于业务层。

一个心跳就一个 bit，跟那一大堆 http 请求、视频流量比起来简直是九牛一毛，这是从流量角度。

再说服务器端并发，你以为抖音这种是缺钱缺机器的主？我没用过抖音，不确定抖音是怎么实现的，但是要想实现即时的服务器端主动的信息通知，长链接是必须的，实现方式是多样的。

苹果这边应该是只需要一个心跳吧

手机连着苹果的推送服务器
推送都是发到苹果的推送服务器
不是直接到 app

ws 又不是不行，只不过不是最佳方案而已，11 楼怎么就和 ws 没有半毛钱关系了？

@mengyaoss77 哈哈。。。用 01

@ochatokori 不止“不是最佳方案”吧，架构师脑子正常的正常情况下消息推送都不会用 ws 来做的。

长链接 /轮询

这帖子给我整糊涂了

个人感觉,没有最好, 只有合适不合适。
在抖音这种场景下，个人觉得是长连接获取的。

在某些其他场景，比如功能活跃度较低的功能，可能使用异步推送等方式

@cominghome 脑子正常的架构师会怎么做？

实时通知
用什么实现 一般用 websokt
做成什么样 有多少实时？ 取决于网络与推送的及时程序

@cominghome 我也想知道脑子正常的架构师会怎么做...

不好意思回复的有点草率，确实是一个长连接。如果非要以 ws 协议帧的实现方式也是可以，甚至见过以 HTTP 协议为载体 xml 格式的即时通信。

不过 ws 协议满足不了企业上对即时通信的反馈性，安全性，以及健壮性等诸方面的需求，且握手过程稍繁琐(协议需要从 HTTP 升级)，所以 ws 不太适用终端这种场景。

不就是隐式推送吗，这么玄乎……

如果只是单向通信，sse 更轻便点

@wangxiaoaer

我认为这是两个不同的途径。推送是走第三方通道到手机系统，再到 app，socket 完全是 app 内部的事。

方法太多了，http comet, websocket, 或者用一些现有的服务，比如有个叫野狗的（只是听说过）

@cominghome 脑子正常的架构师怎么做？

求个标准答案,

我也觉得是队列 MQ

插眼来求标准答案

推荐阅读《 UNIX 网络编程》两卷本。

应该说，是类似微信朋友圈的原理

@dntsgd 应该说，是类似快手点赞的原理 狗头保命

websocket 就不是 socket 了吗，干嘛歧视呢

猜测推送：

如果 app 活着，就优先走自己的长连接，把消息直接推到手机，毫秒级。

app 死了、消息不可达，就走厂商的推送通道：apns、各大厂商、渣渣第三方，难免受制于人。也许低价值的也许就放弃推送，广告那些玩意高价值死命也要推到客户端。

听公司那些做 IM 聊得一般使用一些推送服务，如果自己在程序里实现的话用户把进程杀了他就什么消息都收不到了，华为 oppo vivo 都有自己的手机推送服务，和他们对接就好了，还有些第三方推送 极光推送 什么的。

插眼等正确答案

关闭 app 情况下走推送，开着 app 个人还是倾向于走长连的。
长连成本没那么高的，几个大厂 app 哪个没长连？ api 请求什么的好多 app 也都走长连（为了快）。
抖音本身就有聊天功能，复用同个通道就行。

使用某种“推送”技术，目的是从服务端往客户端发送消息，在这个例子里就是把被评论的事件告诉 APP。
推送使用的具体网络技术就有多种可能，websocket 是基于 tcp 长连接的方式。还有使用“频繁定时拉取”来实现“推送”的方式，实时性在于频繁程度。
长连接需要维护 TCP 的状态，确实耗费资源，所以使用统一的推送服务可以多个 APP 共享一个推送通道，降低服务端资源使用。
现在很多 APP 都使用不同的推送服务，甚至每个手机厂商自己还弄一套，导致推送通道冗余，手机后台线程很多，这也是国内安卓手机卡顿体验差的一个因素。 对于开发者也是一种痛苦，本来 Android 使用谷歌推送就一份逻辑搞定，现在被迫取集成 N 多种推送。

那些楼上不知道的就别瞎回复了，说什么透传、推送，你们和没说有什么区别？

苹果有官方的推送服务器和接口有什么可争的搞不懂，安卓稍微乱一点而已

这有啥好讨论的？

这帖子的评论，让我惊讶 v2 居然有这么多半吊子研发！

@paullee 请说出你的见解

消息推送极光之类的服务
最简单的就是 app 几秒轮询啊
这有啥疑问的????

原来 V2EX 上的平均水平那么低吗。。。
一般采用长连接或者轮询，选择哪种看频率。
值得讨论的，也就是选择自己建立长连接，还是直接使用系统或者 SDK 提供的长连接

这个帖子暴露了很多人的基础短板，还 tm 只知道 cv996 吗

这种程序一定有一个 tcp 或者 udp 的长连接，这个连接里面会做很多不能描述的事情，所以推送就会放到这个里面，所以方案上一定不会用 websocket 这种要做死的方式。但是如果用了，我只能说这个方案的人比较二。

长连接资源开销大？？？？
黑人问号

难道你以为的刷死服务器的轮询就不大？

看了这个贴子我学到了我用 tcp 做实时推送是消耗很大傻逼行为,我绝定改成 udp 疯狂发包

websocket 会消耗连接数的，每台机器的连接数是有上限的

正在用 socketcluster （ typescript ）写一个包含聊天、系统通知功能的应用，客户端有 web、ios、android，前期单台服务器，后期量起来了可以上 k8s 自动扩容，应用内走 websocket 应用外走 ios、第三方推送（ android ）。

websocket 消耗大？
以前对单台服务器有个 c10k 挑战，现在都上升到 c1000k 了，各语言性能测试传送门： https://colobu.com/2015/05/22/implement-C1000K-servers-by-spray-netty-undertow-and-node-js/

可以 http 轮训。也可以 tcp 直接实时通知

插眼等正确答案

看来搞 IM 的不多，这东西就是 tcp 或者 udp，有的 app 狠起来会开好几个长连接，更狠的还会做 android 的提权保活，进程杀掉了后台照样悄悄的跑。
大概的流程就是跟聊天一样，有人点了个赞，系统走推送渠道推给你了，走 app 自己的长连接，还是走华为小米厂商的 push 通道，看厂商高兴。
即时通讯类的社交产品，一般分两块，通讯和视频。即时通讯为了省流量，省资源，大厂都是私有协议。视频直播类的就是 rtmp+hls。其他的任何内容都属于消息协议扩展。起泡怎么冒，礼物怎么显示，商品红包什么的，业务按照 im 的协议扩展

就是推送

[建议] 那些 [反对长连接] 的朋友和 [赞成长连接] 的朋友，互相加入黑名单。

手机会保持向服务器询问是否需要同步数据，但是这个询问代价很小。

@jm00 #96 要不要感受一下 5000 万请求轮询的压力？ 2333