17
golang 有什么 TCP 框架?
source link: https://www.v2ex.com/t/796420
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
可以管理连接, 心跳包 处理粘包等,
web 方面的很多, tcp 的没找到,大家做 TCP 都用什么呢?
web 方面的很多, tcp 的没找到,大家做 TCP 都用什么呢?
第 1 条附言 · 2 天前
我要做的是 c/s , 用 net 包可以,但是连接管理, 心跳包 粘包等要自己处理,
想问下 TCP/IP 有没有什么框架.大家都用什么..好像用 go 做这个的少吧.
好像现在都是用 rpc 实现? 新学 golang , 没找到合适的 tcp 框架.做 client/server ,用 rpc 合适?
想问下 TCP/IP 有没有什么框架.大家都用什么..好像用 go 做这个的少吧.
好像现在都是用 rpc 实现? 新学 golang , 没找到合适的 tcp 框架.做 client/server ,用 rpc 合适?
第 2 条附言 · 1 天前
谢谢各位的回复.
tcp 是数据流, 如果 client 连续发送消息, tcp 可能会将几个连续发送出去的请求合并成一个请求发出去,
server 收到合并后的一个请求. 这个时候,一般就需要自己处理消息边界问题.
使用原生 TCP 那就一定会遇到数据的粘和分这个问题吧,
我觉得粘包和拆包的描述还是挺形象的,不然怎么形容这个现象呢.
tcp 是数据流, 如果 client 连续发送消息, tcp 可能会将几个连续发送出去的请求合并成一个请求发出去,
server 收到合并后的一个请求. 这个时候,一般就需要自己处理消息边界问题.
使用原生 TCP 那就一定会遇到数据的粘和分这个问题吧,
我觉得粘包和拆包的描述还是挺形象的,不然怎么形容这个现象呢.
第 3 条附言 · 1 天前
我只是觉的用 golang 自带 net 包中的 tcp ,有一点点麻(tou)烦(lan),所以想找个相关的框架.
麻烦大家别再纠结粘包了.
麻烦大家别再纠结粘包了.
114 条回复 • 2021-08-20 00:57:19 +08:00
lesismal 1 天前
@xuanbg http 性能比较差，http 不能推送，无法满足很多业务。即使"http 之类的应用层协议” 是指包括了 websocket 等协议，仍然面临着框架选择的问题，比如 go 的 websocket 协议，知名的 gorilla/websocket 仍然需要自行封装读写、melody 甚至存在并发 bug 可能导致宕机并且作者已经杳无音讯。所以不适合用做业务的思维去回答技术选型的问题，当某一天你成长为更高阶的新时代农民工、负责这些事情的时候，也会面临同样的选型问题。
BadMan 1 天前
提一下应用层分包策略：
1. 采用固定长度
2. 采用固定分隔符（ redis 采用这种）
3. header+body，在 header 固定位置标识整包长度
另外
1. tcp 、udp 、http 、quic 是网络协议
2. grpc 、brtc 是 rpc 框架，和网络协议不是一个层面的概念，grpc 应该是使用 http 2.0 作为默认网络协议
1. 采用固定长度
2. 采用固定分隔符（ redis 采用这种）
3. header+body，在 header 固定位置标识整包长度
另外
1. tcp 、udp 、http 、quic 是网络协议
2. grpc 、brtc 是 rpc 框架，和网络协议不是一个层面的概念，grpc 应该是使用 http 2.0 作为默认网络协议
janxin 1 天前
net 库已经很标准了，不过要真正上业务确实要自己封装很多东西出来。
想偷懒非要实现要封装一层，gnet/evio 是个不错的选择，保证了可定制性，内置优化不用自己做额外操作。如果你数据格式都没定义，那么 zinx 适合你，它是定好的格式，缺点如果接入已存在协议就很麻烦了。
如果对 TCP 不了解选择双向 RPC 框架也可以，底层 TCP 还是 Websocket 之类的并不重要，框架会帮你处理。
想偷懒非要实现要封装一层，gnet/evio 是个不错的选择，保证了可定制性，内置优化不用自己做额外操作。如果你数据格式都没定义，那么 zinx 适合你，它是定好的格式，缺点如果接入已存在协议就很麻烦了。
如果对 TCP 不了解选择双向 RPC 框架也可以，底层 TCP 还是 Websocket 之类的并不重要，框架会帮你处理。
iyaozhen 1 天前
强烈推荐字节的 https://github.com/cloudwego/netpoll，内部一切框架的基础，但可能资料太少了
还得说下粘包，有些人可能觉得很形象，但实际是偷懒的概念理解，你都要搞 TCP 了，还有很多底层需要理解，如果不扎实后面是要吃亏的
还得说下粘包，有些人可能觉得很形象，但实际是偷懒的概念理解，你都要搞 TCP 了，还有很多底层需要理解，如果不扎实后面是要吃亏的
raptor 16 小时 4 分钟前
@ming159
62 楼已经解释清楚了，这事不是 TCP 该干的，还是去复习一下 TCP 的基本原理吧。
54 楼所说的以#开头，以$结束就是定义了一个最简单的基于 TCP 的应用协议（但显然是有问题的，比如，如果数据流本身包含了#和$要怎么处理，最大长度有没有限制等等），那么实现这个协议就是你自己的事情，跟 TCP 没关系。
62 楼已经解释清楚了，这事不是 TCP 该干的，还是去复习一下 TCP 的基本原理吧。
54 楼所说的以#开头，以$结束就是定义了一个最简单的基于 TCP 的应用协议（但显然是有问题的，比如，如果数据流本身包含了#和$要怎么处理，最大长度有没有限制等等），那么实现这个协议就是你自己的事情，跟 TCP 没关系。
eastphoton 1 小时 4 分钟前
对楼上一些人无语，
对，TCP 是流、是传输层，包不是 TCP 该管的事，真的很正确。
可总有人得处理从流到包，楼主的意思不就是想要一个框架帮他在教科书中的应用层先处理完这些事嘛，
又有什么不合理的呢，不就是插个中间层再给 TCP 封装一层，七层五层模型本质不也是层层封装，
每次非得有人在这出警整些原教旨，显得好像就他学过。
对，TCP 是流、是传输层，包不是 TCP 该管的事，真的很正确。
可总有人得处理从流到包，楼主的意思不就是想要一个框架帮他在教科书中的应用层先处理完这些事嘛，
又有什么不合理的呢，不就是插个中间层再给 TCP 封装一层，七层五层模型本质不也是层层封装，
每次非得有人在这出警整些原教旨，显得好像就他学过。
joetse 51 分钟前
tcp 是保证顺序的, 你可以简单地自定协议, encode, decode, 处理头尾, 不过我是用其他语言工具写的, 用了好多锁去判断状态, 一个模版套上处理各种奇奇怪怪的设备的 process, go 应该也差不多吧, 起步挺麻烦, 模版通过测试之后就稳了. 感觉不是高并发场景就没用上框架.
有高并发需求再去看看 netpoll, gnet, evio, 学习了~
有高并发需求再去看看 netpoll, gnet, evio, 学习了~
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK