1
SuperMild 2019-06-18 09:02:32 +08:00 9
你说微信是什么原理?
|
2
supuwoerc 2019-06-18 09:05:51 +08:00 via iPhone
Websocket 吧
|
3
mannixSuo 2019-06-18 09:16:04 +08:00
websocket 有点复杂了吧,应该是收到点赞然后调用通知的方法
|
4
mejee 2019-06-18 09:33:23 +08:00 via Android 1
可能是:用户点赞,事件加入消息队列,服务器异步推送消息给你
|
5
lscho 2019-06-18 09:37:37 +08:00
2、3 楼的评论什么鬼?
|
6
zwh2698 2019-06-18 09:40:10 +08:00 via Android
排除法,先说 websocket, 如果是 websocket,那么后台还要给每一个维护一个心跳,就为了给你一个通知?代价大,资源耗不起。所以不可能。
|
7
vance 2019-06-18 09:42:01 +08:00 1
不是 websocket,代价太大,
|
8
b0644170fc 2019-06-18 09:47:41 +08:00
消息队列?
|
9
jacketma 2019-06-18 09:49:24 +08:00 via Android
当前用户在活跃状态下,必然要维持一个长连接,是不是 websocket 都差不多。
一对一的推送消耗没那么大,群聊实时推送才惊人。 |
10
bertsir 2019-06-18 09:49:26 +08:00
推送解决不了?
|
11
zk123 2019-06-18 09:51:40 +08:00 via iPhone
和 websocket 有半毛钱关系?
|
12
x7395759 2019-06-18 09:54:20 +08:00
这都是业内常见解决方案了,你不知道说明你不适合这个行业
|
13
LinPH 2019-06-18 09:54:25 +08:00
推送透传消息吧
|
14
2805408253 2019-06-18 10:00:31 +08:00
4 楼的思路,倒有可能。头条的 v2er 可以出来讲下
|
15
shawndev 2019-06-18 10:10:32 +08:00
不负责任的瞎猜 HTTP/2 server push
|
16
tqyq88 2019-06-18 10:11:47 +08:00
push sdk,通用方案
|
18
janus77 2019-06-18 10:16:38 +08:00
如果单说 App 端,就是消息推送啊
|
19
southsala 2019-06-18 10:36:17 +08:00
移动推送中的透传啊
|
20
Arcy 2019-06-18 10:36:48 +08:00
消息推送服务啊。
|
21
f2ck 2019-06-18 10:57:24 +08:00
透传
|
22
bobuick 2019-06-18 11:03:24 +08:00
推送+长连方式(长连不一定是 ws)
应用内用长连是很正常的, 应用外用 app push. |
23
kulove 2019-06-18 11:05:10 +08:00
推送,接收到改变下状态就好了
|
24
Ponze 2019-06-18 11:33:28 +08:00
这如果要有点赞和 diss 的话就好了。 哈哈哈哈
|
25
mengxianliang 2019-06-18 11:38:19 +08:00
推送
|
26
liyaoo 2019-06-18 11:39:27 +08:00 via iPhone
什么是气泡提醒?
|
27
wbf1013 2019-06-18 12:05:30 +08:00 1
不就是一推送么
|
28
Sapp 2019-06-18 12:05:39 +08:00 1
@shawndev 你这一看就是道听途说了一些 http2 的内容,server push 和常规理解(你的理解) 的推送根本不是一个推送。
|
29
changdy 2019-06-18 12:35:26 +08:00
|
30
lonelygo 2019-06-18 12:54:44 +08:00 18
就不#某一楼了,不过一个消息处理的小技巧或者知识点。
就上升到不知道就不适合这个行业了。 我就好奇了,以这个规模的问题为标准,随便抛一个不知道就不适合行业了。 那估计“这个行业”就要结束了。 比不知道更可怕的是自大。 |
31
Reficul 2019-06-18 12:57:43 +08:00 via Android 1
如果 ws 是因为长连接代价太大的话,难道推送就不靠长连接了咩。。。
|
32
mengyaoss77 2019-06-18 13:10:29 +08:00 via Android
我觉得楼上说透传的就像 leetcode 用标准库直接排序一样。:-)
|
33
NicholasYX 2019-06-18 13:24:14 +08:00 via iPhone
消息队列?
|
34
shawndev 2019-06-18 13:24:49 +08:00
@Sapp 翻了一下文档,如你所说。server push 由 web 服务器配置,并行加载网页资源。而不是在获取 html 后解析当中用到的资源再请求。
|
35
AndroidEngineer 2019-06-18 13:27:34 +08:00
为啥不能是 websocket ? push sdk 不用长链接吗,靠什么实现的?
|
36
xnode 2019-06-18 13:28:24 +08:00
socket 或者 mqtt 治疗的长连接 后端是 消息队列
|
37
HarryQu 2019-06-18 13:32:10 +08:00 1
我之前做过 Android 和 iOS , 做的应用使用的是 消息推送 SDK 。
Android 使用的 小米 /华为 , 应用在前台透传,应用在后台通知栏推送。 iOS 的用的是系统的 APNs , 机制和 Android 类似。 缺点是不论 Android 和 iOS , 集成系统的消息推送都有延迟。 我们公司当时没有即时通讯的业务,前台、后台 消息推送一把梭哈 , 所以经常被用户投诉,别人回复消息,自己收不到。 但是应用在后台的时候,只能使用系统的消息推送。 因此,像微信这类即时通讯软件,应用在前台用的是自己的长连接,在后台用的是系统的推送 。 至于抖音,没有了解过,如果为了保证推送的及时率和成功率,应该采取和微信一样的机制。 如果抖音比较懒的话,那就用直接用系统的推送。 具体 IM 的原理 和 Android 消息推送原理 与 APNs。因水平有限,我也没做过这些,就不评论了。 |
38
yibeishui OP @liyaoo 抖音,评论过后,继续浏览其它视频。如果有人赞了你的评论或者回复了你的评论。底部“消息”那个按钮就会浮出一个气泡提醒你。
|
39
Vdream 2019-06-18 14:24:07 +08:00
应该就是类似 push 的推送,可能加入厂商白名单,可以长期保活接通知吧
|
40
bengcaca 2019-06-18 14:27:46 +08:00 23
都是什么鬼。没用过抖音,只说即时通讯。
如果要做到及时提醒,那肯定是有一个长链接的,不管是 http2、websocket、mptt,以上都是应用层协议,不管传输层是基于 tcp 还是 udp,本质都是一个长链接。推送就是用长链接实现的,不然你以为 server 端的消息怎么主动推到 client? 关于长链接维持,纯技术角度而言,长链接就不需要维持,如果网络正常且中间路由不做任何处理,就算没心跳,你一年后这个 tcp 依然能通讯。心跳只是业务层的逻辑( tcp 的 keepalive 算是协议层),心跳是可以优化的,有的可能几分钟一次心跳。 关于长链接的维持,微信十几亿用户都能做,抖音几亿用户为啥不能做? |
41
weidada 2019-06-18 14:43:10 +08:00
个推推送 极光推送
|
42
NieKing 2019-06-18 15:00:25 +08:00
这么多人不知道前台服务吗?
|
44
hyyou2010 2019-06-18 16:02:28 +08:00
区分一下:
1,消息推送 2,某种长连接的 socket 显然是 2,非常轻便。1 的成本很高。 |
45
summer1988 2019-06-18 16:06:27 +08:00
ws push server init
|
46
maichael 2019-06-18 16:09:00 +08:00
websocket 那门子的成本高了呀……
|
47
okwork 2019-06-18 16:13:17 +08:00 via Android
@bengcaca 心跳就是为了维持长连接吧,否则移动网络那么复杂,而且还各种网络切换,肯定出现会掉线。
|
48
wangxiaoaer 2019-06-18 16:16:08 +08:00
|
49
bengcaca 2019-06-18 16:37:09 +08:00 1
@okwork 心跳是为了维持长链接,这是业务层的,但从 tcp 协议层本身来讲,长链接不一定需要心跳,这个区分还是应该要清楚的。
如果实现得当,心跳可以根据不同的网络状况设置不同的间隔时间,比如 3G 网络下可能 30s,4G 情况下 1 分钟,wifi 情况下 5 分钟,具体值还可以根据历史网络状况做动态调整,当然这都属于业务层。 一个心跳就一个 bit,跟那一大堆 http 请求、视频流量比起来简直是九牛一毛,这是从流量角度。 再说服务器端并发,你以为抖音这种是缺钱缺机器的主?我没用过抖音,不确定抖音是怎么实现的,但是要想实现即时的服务器端主动的信息通知,长链接是必须的,实现方式是多样的。 |
50
loveuqian 2019-06-18 16:42:55 +08:00 via iPhone 1
苹果这边应该是只需要一个心跳吧
手机连着苹果的推送服务器 推送都是发到苹果的推送服务器 不是直接到 app |
51
ochatokori 2019-06-18 16:44:18 +08:00 via Android
ws 又不是不行,只不过不是最佳方案而已,11 楼怎么就和 ws 没有半毛钱关系了?
|
52
dobelee 2019-06-18 16:52:38 +08:00 via Android 1
不就是个长连接吗?这都能撕。。。
|
53
jackchao7432 2019-06-18 17:22:07 +08:00
@mengyaoss77 哈哈。。。用 01
|
54
cominghome 2019-06-18 18:03:18 +08:00
@ochatokori 不止“不是最佳方案”吧,架构师脑子正常的正常情况下消息推送都不会用 ws 来做的。
|
55
akira 2019-06-18 19:02:21 +08:00
长链接 /轮询
|
56
phithon 2019-06-18 21:00:32 +08:00 1
这帖子给我整糊涂了
|
57
genglintong 2019-06-18 21:14:50 +08:00
个人感觉,没有最好, 只有合适不合适。
在抖音这种场景下,个人觉得是长连接获取的。 在某些其他场景,比如功能活跃度较低的功能,可能使用异步推送等方式 |
58
pubby 2019-06-18 21:17:06 +08:00 via Android
@cominghome 脑子正常的架构师会怎么做?
|
59
myself659 2019-06-18 21:19:13 +08:00
实时通知
用什么实现 一般用 websokt 做成什么样 有多少实时? 取决于网络与推送的及时程序 |
60
koalli 2019-06-18 22:04:46 +08:00
@cominghome 我也想知道脑子正常的架构师会怎么做...
|
61
zk123 2019-06-18 22:47:18 +08:00 via iPhone 1
不好意思回复的有点草率,确实是一个长连接。如果非要以 ws 协议帧的实现方式也是可以,甚至见过以 HTTP 协议为载体 xml 格式的即时通信。
不过 ws 协议满足不了企业上对即时通信的反馈性,安全性,以及健壮性等诸方面的需求,且握手过程稍繁琐(协议需要从 HTTP 升级),所以 ws 不太适用终端这种场景。 |
62
lizhuoli 2019-06-18 22:51:35 +08:00 via iPhone
不就是隐式推送吗,这么玄乎……
|
63
limbo0 2019-06-18 23:18:40 +08:00 via Android
如果只是单向通信,sse 更轻便点
|
64
hyyou2010 2019-06-18 23:22:36 +08:00
|
65
dangyuluo 2019-06-19 04:22:17 +08:00
方法太多了,http comet, websocket, 或者用一些现有的服务,比如有个叫野狗的(只是听说过)
|
66
zzl22100048 2019-06-19 08:29:23 +08:00
@cominghome 脑子正常的架构师怎么做?
|
67
TomVista 2019-06-19 08:46:17 +08:00
求个标准答案,
|
68
Stlin 2019-06-19 08:56:16 +08:00
我也觉得是队列 MQ
|
69
bullettrain1433 2019-06-19 09:14:50 +08:00
插眼来求标准答案
|
70
exploreXin 2019-06-19 09:23:07 +08:00
推荐阅读《 UNIX 网络编程》两卷本。
|
71
dntsgd 2019-06-19 09:40:44 +08:00
应该说,是类似微信朋友圈的原理
|
73
xiangyuecn 2019-06-19 10:01:45 +08:00
websocket 就不是 socket 了吗,干嘛歧视呢😒
猜测推送: 如果 app 活着,就优先走自己的长连接,把消息直接推到手机,毫秒级。 app 死了、消息不可达,就走厂商的推送通道:apns、各大厂商、渣渣第三方,难免受制于人。也许低价值的也许就放弃推送,广告那些玩意高价值死命也要推到客户端。 |
74
justRua 2019-06-19 10:05:42 +08:00
听公司那些做 IM 聊得一般使用一些推送服务,如果自己在程序里实现的话用户把进程杀了他就什么消息都收不到了,华为 oppo vivo 都有自己的手机推送服务,和他们对接就好了,还有些第三方推送 极光推送 什么的。
|
75
Canon1014 2019-06-19 10:10:09 +08:00
插眼等正确答案
|
76
dongxinb 2019-06-19 10:15:41 +08:00
关闭 app 情况下走推送,开着 app 个人还是倾向于走长连的。
长连成本没那么高的,几个大厂 app 哪个没长连? api 请求什么的好多 app 也都走长连(为了快)。 抖音本身就有聊天功能,复用同个通道就行。 |
77
raiz 2019-06-19 10:21:36 +08:00
使用某种“推送”技术,目的是从服务端往客户端发送消息,在这个例子里就是把被评论的事件告诉 APP。
推送使用的具体网络技术就有多种可能,websocket 是基于 tcp 长连接的方式。还有使用“频繁定时拉取”来实现“推送”的方式,实时性在于频繁程度。 长连接需要维护 TCP 的状态,确实耗费资源,所以使用统一的推送服务可以多个 APP 共享一个推送通道,降低服务端资源使用。 现在很多 APP 都使用不同的推送服务,甚至每个手机厂商自己还弄一套,导致推送通道冗余,手机后台线程很多,这也是国内安卓手机卡顿体验差的一个因素。 对于开发者也是一种痛苦,本来 Android 使用谷歌推送就一份逻辑搞定,现在被迫取集成 N 多种推送。 |
78
zyh94946 2019-06-19 10:48:26 +08:00
那些楼上不知道的就别瞎回复了,说什么透传、推送,你们和没说有什么区别?
|
79
limuyan44 2019-06-19 10:59:53 +08:00 via Android
苹果有官方的推送服务器和接口有什么可争的搞不懂,安卓稍微乱一点而已
|
80
zmlu 2019-06-19 11:10:01 +08:00
这有啥好讨论的?
|
81
paullee 2019-06-19 11:36:08 +08:00 via iPhone
这帖子的评论,让我惊讶 v2 居然有这么多半吊子研发!
|
82
SwiftFrank 2019-06-19 11:47:44 +08:00
@paullee 请说出你的见解
|
83
wysnylc 2019-06-19 12:26:38 +08:00
消息推送极光之类的服务
最简单的就是 app 几秒轮询啊 这有啥疑问的???? |
84
wm5d8b 2019-06-19 12:54:25 +08:00
原来 V2EX 上的平均水平那么低吗。。。
一般采用长连接或者轮询,选择哪种看频率。 值得讨论的,也就是选择自己建立长连接,还是直接使用系统或者 SDK 提供的长连接 |
85
ichao1214 2019-06-19 13:58:49 +08:00
这个帖子暴露了很多人的基础短板,还 tm 只知道 cv996 吗
|
86
zwh2698 2019-06-19 14:11:12 +08:00 via Android
这种程序一定有一个 tcp 或者 udp 的长连接,这个连接里面会做很多不能描述的事情,所以推送就会放到这个里面,所以方案上一定不会用 websocket 这种要做死的方式。但是如果用了,我只能说这个方案的人比较二。
|
87
realpg 2019-06-19 16:48:25 +08:00 via Android
长连接资源开销大????
黑人问号 难道你以为的刷死服务器的轮询就不大? |
88
ragnaroks 2019-06-19 17:17:56 +08:00
看了这个贴子我学到了我用 tcp 做实时推送是消耗很大傻逼行为,我绝定改成 udp 疯狂发包
|
89
airfling 2019-06-19 17:39:55 +08:00 via Android
websocket 会消耗连接数的,每台机器的连接数是有上限的
|
90
photon006 2019-06-19 17:42:25 +08:00
正在用 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/ |
91
opengps 2019-06-19 17:44:28 +08:00
可以 http 轮训。也可以 tcp 直接实时通知
|
92
miruacle 2019-06-19 17:48:43 +08:00 via iPhone
插眼等正确答案
|
93
banksiae 2019-06-19 18:33:07 +08:00
看来搞 IM 的不多,这东西就是 tcp 或者 udp,有的 app 狠起来会开好几个长连接,更狠的还会做 android 的提权保活,进程杀掉了后台照样悄悄的跑。
大概的流程就是跟聊天一样,有人点了个赞,系统走推送渠道推给你了,走 app 自己的长连接,还是走华为小米厂商的 push 通道,看厂商高兴。 即时通讯类的社交产品,一般分两块,通讯和视频。即时通讯为了省流量,省资源,大厂都是私有协议。视频直播类的就是 rtmp+hls。其他的任何内容都属于消息协议扩展。起泡怎么冒,礼物怎么显示,商品红包什么的,业务按照 im 的协议扩展 |
94
wizardoz 2019-06-20 09:22:37 +08:00
就是推送
|
95
MCJIBA 2019-06-21 13:47:16 +08:00
[建议] 那些 [反对长连接] 的朋友和 [赞成长连接] 的朋友,互相加入黑名单。
|
96
jm00 2019-06-21 14:05:08 +08:00 via Android
手机会保持向服务器询问是否需要同步数据,但是这个询问代价很小。
|