闲得蛋痛，用 go+websocket 写了个聊天组件。。。

2014 年 8 月 9 日
 barbery
这个想法是源自于，某某公司一台机器用go写的可以抗30W长连接。。。

性能是程序猿的G点，我信了。。。
边学习，边折腾。。。花了1周，终于搞掂。。。把服务挂在digitalocean上，不知道5刀的机器可以抗多少连接。。

引入组件的话, 请看gist: https://gist.github.com/Barbery/8f36d999193da2a29ab3
4851 次点击
所在节点    分享创造
7 条回复
huangyan9188
2014 年 8 月 9 日
ws 实现聊天非常简单但是其实并不适合做im 因为长连接的非常不好
使用http的方法或者udp 来实现是最理想的~~
我以前也用socket.io写过效率一般，使用http post 或者udp 的方法效率最高，根本不用担心并发性
其实长连接的话大部分网络带宽都是heartbeat
barbery
2014 年 8 月 9 日
@huangyan9188 谢谢你的经验之谈，不过http post的话，怎么推送消息到客户端？是轮询么？
mengskysama
2014 年 8 月 9 日
@huangyan9188 有点误人子弟啊，post不可能效率高，光头部就比websocket大几倍到十几。而且客户端不断轮询，后台招架不住的。udp在web里没有原生支持。
skybr
2014 年 8 月 9 日
@huangyan9188 socket.io只是把websocket做为backends之一, 实质上已经封好了一堆心跳超时、protocol && event的基础业务和rooms && broadcast高级业务进去了, 单单和纯websocket比就已经够重型了.
jedihy
2014 年 8 月 10 日
@barbery post长轮训
barbery
2014 年 8 月 10 日
@jedihy 我觉得，不考虑兼容性的话，轮询《comet《socket
jedihy
2014 年 8 月 10 日
@barbery 确实，长轮训是无奈之举

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://study.congcong.us/t/126938

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX