如题
或许问题很菜 希望可以真诚的解答下疑惑。感谢~~
1
402645707 2015-08-24 12:40:47 +08:00 via Android
同时在线 5000 人
阿里云 10 月杭州大会欢迎你 |
2
loading 2015-08-24 12:43:04 +08:00 via Android
早上看到知乎一个地方, yy 一个月,要差不多 2 亿块~
|
4
jamesfuxk 2015-08-24 12:48:47 +08:00
好像是要不错的带宽才能支持这么多人同时在线语音的哦
|
5
loading 2015-08-24 12:48:51 +08:00 via Android
@lsylsy2 人多,而且不卡不延时这些要求其实比视频要求更好。因为你看别人玩,和自己玩是不同的,卡几次就换软件,你觉得呢?
|
6
loading 2015-08-24 12:55:30 +08:00 via Android
|
7
loading 2015-08-24 12:58:05 +08:00 via Android
上面提到的 yy 是 一季度… 2015Q2 , 1.3 亿!
|
8
ckk163 OP 感谢各位的热心回复,补充下不是 yy 的全部功能就一个房间实时聊天的,原来有个比较老的软件 teamspeak ,只是实现房间 1-20 人然后有很多房间能够实时语音聊天这样的功能。不考虑视频或者语音直播。
|
9
ljbha007 2015-08-24 13:48:42 +08:00
建议用腾讯的云服务 毕竟是自己老本行:
http://www.qcloud.com/product/avc.html |
10
ljbha007 2015-08-24 13:50:11 +08:00
用这个开发成本很低 但是使用费用大概 5000 人峰值是 15000 一个月
|
11
ss098 2015-08-24 13:50:42 +08:00 via iPad
据我感觉在使用 YY 时流量跑的不是太快,约 10 KByte / 秒,有时不到,场景是几个小伙伴时断时续的聊天。
如果有优化良好的通讯协议,比如 10 KByte / 秒,那么每 MBits 可以支撑约 10 人。可以得出 5000 人至少需要 0.5 GBits 宽带。 |
12
ckk163 OP @ljbha007 看了下腾讯的那个 计费简单粗暴呀 而且客户端开发得照腾讯的规则来比较受限制。其实我是想服务端和客户端能自主开发然后买带宽和服务器
|
15
eae29qvc 2015-08-24 14:12:32 +08:00
需求简单的话 2 、 3 个月可以搞定
5000 人大概 2-5MB 下行 50-100MB/s 上行(根据语音质量还有房间人数) 一台 4 核服务器可以跑 5 万人左右(优化好的话可以更多) |
16
wy315700 2015-08-24 14:16:34 +08:00 1
@ss098
不是这么算的, 假如你发送语音的是 10KB/S ,一个聊天室有 100 人的话,你的语音是要发送给 100 人,假如 100 人同时在说话,那就要发送 100*100 = 10000 份,也就是 100MB/S |
17
ckk163 OP 如果可以开发 软件在开房间后 语音的传输是 p2p 式的就好了 ,比如说房间有 5 个人聊天这 5 个的语音流可以不经过服务器而是说话本人只传输到其他人
|
19
ss098 2015-08-24 14:22:43 +08:00 via iPad
|
20
akira 2015-08-24 14:24:37 +08:00
软件开发成本还好,后期带宽费用比较贵。
另外,单台服务器肯定不能满足负荷的。 |
21
ckk163 OP 关键看能不能开发 p2p 式的 如果可以的话就可以极大压缩客户端与服务端直接的带宽需求,不知道有没有内行人进来指点下
|
23
lty1993 2015-08-24 14:45:03 +08:00
@wy315700
这很明显不对的 以纯语音 G729 为例,需要消耗 31.2Kbps 的带宽每路,每个用户需要 2 路,一上一下,也就是 62.4Kbps 。 一个聊天室有 100 个人,就是 62.4Kbps * 100 。 100 个人 10000 倍什么鬼?你的服务器只转发数据,客户端 Mixing ?你逗我? |
24
eae29qvc 2015-08-24 14:49:21 +08:00
@ckk163 p2p 要考虑的因素太多了,各种穿透,以国内的网络环境很麻烦,举个最简单的例子,一个 50 个人的房间,你要跟 49 个人说话, 2kB 每秒,也就是你需要 49x2=98kB 的上传带宽,国内的带宽大部分是上下行不对等的,标称 4m 的带宽也就 256kb 的上行,根本达不到要求
|
26
lty1993 2015-08-24 14:51:58 +08:00
@eae29qvc 是的,这个场景完全不适合 P2P 。而且再加上 Voice Activity Detection 基本上可以服务器下行可以压缩到很小很小。
|
27
ckk163 OP @eae29qvc 是这么计算的吗?我感觉这个解释是一个人说了一句话 50 人房间的话要传输 49 次在同一时间。不可以只传输一次然后有客户端负责协调复制到其他 49 个客户端吗 不知道我这个理解是不是可以实现
|
28
eae29qvc 2015-08-24 14:55:20 +08:00
|
29
lty1993 2015-08-24 14:55:46 +08:00
|
30
eae29qvc 2015-08-24 14:58:18 +08:00
@ckk163 同步怎么办,语音实时性要求很高的,按你那么搞一个人说了一句话,下一句话不知道什么时候传过来,然后就各种断断续续的,还有每个人听到的声音的先后顺序都不一样怎么搞
|
33
lty1993 2015-08-24 15:09:46 +08:00
@eae29qvc 话说你跑的什么平台?
不过我觉得性能实在不够。。。可以上 Cisco 的硬件 UCM ,或者 PCIE 的 Encode/Decode 卡。。。 4134 Transit 这么贵,省下带宽的钱轻轻松松买硬件设备阿。如果客户端 mixing ,这是指数倍节约带宽阿。 |
34
ckk163 OP 不知道你们有没研究过 比邻 那个房间聊天是怎么实现的 我感觉他那个好像是 p2p 的
|
41
wy315700 2015-08-24 15:25:58 +08:00
@lty1993 你每个人发出去的 要发给 100 人,如果 100 人同时说话呢,聊天室不是只能一个人说其他人听,是可以同时说话的
|
44
lty1993 2015-08-24 15:31:02 +08:00
@ckk163 我这边跑的 PBX ,并不是个聊天室系统。。。
理论上来说你需要写个客户端,用 SIP 或者 Skinny 或者 IAX2 作为语音通信, XMPP 作为文字通信,自己写个 REST API 用来给客户创建自己的聊天室。 然后连接 FreeSwitch/Asterisk 这类软电话交换机交换语音, eJabberd 用来处理文字,自己写个服务器端在用户创建聊天室的时候自动去电话交换机和 eJabberd 创建同 ID 的聊天室,然后把 ID 返回客户端。 客户端 Join 聊天室,就等于 VOIP 打聊天室的内线号码+XMPP 登陆那个聊天室。 |
46
lty1993 2015-08-24 15:34:41 +08:00
@wy315700 对阿,每个人都只有和服务器的一上一下两个 Channel ,所有人都可以同时说话和听到别的所有人说的话阿
服务器会去把所有人 Uplink 的音频信号 Mix 阿。然后发给每个客户的只是 Mix 后的那一路音频阿。 |
49
ckk163 OP @eae29qvc 你那个项目的带宽需求的计算方法和这个的计算方法接近吗 同样人数的话需求的带宽是不是和这个差不多的 https://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/7/12/how-much-bandwidth-does-teamspeak-require
|
51
lty1993 2015-08-24 16:05:26 +08:00
@wy315700 是的。就算没有定向屏蔽一样需要 MIX 100 次。自己的 Upstream 不会被 Mix 进自己的 Downstream 。
PCM Mixing 并不需要很多 CPU Cycle ,服务器 Mixing 最大的 CPU 消耗是在这 100 路 Encoding 和 100 路 Decoding 上。 编解码现成板卡一大堆,你要高兴还可以买块 NETFPGA-SUME , G711 和 PCIE 通信的 Verilog 代码满地都是,基本上可以单卡轻松完成 7000+路 G711 的编码 /解码。 |
57
ckk163 OP @eae29qvc 限制到 9 人的话 我按照刚才那个链接里的带宽需求算了下 一般用户的带宽都可以满足 剩下的就是可以不可以以 p2p 的方式来解决这个问题了
|
60
ljbha007 2015-08-24 16:40:08 +08:00
|
62
ljbha007 2015-08-24 16:48:35 +08:00
@ckk163 哈哈哈 这个就是 p2p 的线路 视频+语音流量在 10KB/s 左右 光语音大概 1KB
可以选择走服务器中转 也可以直接连 客户端代码决定的 |
63
ckk163 OP |
64
lcqtdwj 2015-08-24 17:14:20 +08:00
b 站么。。。
|