这是一个创建于 974 天前的主题，其中的信息可能已经有所发展或是发生改变。
可以管理连接, 心跳包 处理粘包等,
web 方面的很多, tcp 的没找到,大家做 TCP 都用什么呢?
web 方面的很多, tcp 的没找到,大家做 TCP 都用什么呢?
第 1 条附言 · 2021-08-17 23:37:01 +08:00
我要做的是 c/s , 用 net 包可以,但是连接管理, 心跳包 粘包等要自己处理,
想问下 TCP/IP 有没有什么框架.大家都用什么..好像用 go 做这个的少吧.
好像现在都是用 rpc 实现? 新学 golang , 没找到合适的 tcp 框架.做 client/server ,用 rpc 合适?
想问下 TCP/IP 有没有什么框架.大家都用什么..好像用 go 做这个的少吧.
好像现在都是用 rpc 实现? 新学 golang , 没找到合适的 tcp 框架.做 client/server ,用 rpc 合适?
第 2 条附言 · 2021-08-18 10:48:06 +08:00
谢谢各位的回复.
tcp 是数据流, 如果 client 连续发送消息, tcp 可能会将几个连续发送出去的请求合并成一个请求发出去,
server 收到合并后的一个请求. 这个时候,一般就需要自己处理消息边界问题.
使用原生 TCP 那就一定会遇到数据的粘和分这个问题吧,
我觉得粘包和拆包的描述还是挺形象的,不然怎么形容这个现象呢.
tcp 是数据流, 如果 client 连续发送消息, tcp 可能会将几个连续发送出去的请求合并成一个请求发出去,
server 收到合并后的一个请求. 这个时候,一般就需要自己处理消息边界问题.
使用原生 TCP 那就一定会遇到数据的粘和分这个问题吧,
我觉得粘包和拆包的描述还是挺形象的,不然怎么形容这个现象呢.
第 3 条附言 · 2021-08-18 14:04:03 +08:00
我只是觉的用 golang 自带 net 包中的 tcp ,有一点点麻(tou)烦(lan),所以想找个相关的框架.
麻烦大家别再纠结粘包了.
麻烦大家别再纠结粘包了.
 |
101
lesismal 2021-08-18 16:10:29 +08:00
@xuanbg http 性能比较差，http 不能推送，无法满足很多业务。即使"http 之类的应用层协议” 是指包括了 websocket 等协议，仍然面临着框架选择的问题，比如 go 的 websocket 协议，知名的 gorilla/websocket 仍然需要自行封装读写、melody 甚至存在并发 bug 可能导致宕机并且作者已经杳无音讯。所以不适合用做业务的思维去回答技术选型的问题，当某一天你成长为更高阶的新时代农民工、负责这些事情的时候，也会面临同样的选型问题。
|
 |
102
labulaka521 2021-08-18 17:12:18 +08:00
"TCP 粘包"有英文资料吗
|
 |
103
darkengine 2021-08-18 17:34:00 +08:00
有意思，原来这就是 “粘包👮♀️“啊，第一次看到这个概念，学到了。
|
 |
104
noahsophie 2021-08-18 18:35:32 +08:00
推荐一下 gnet 吧，我们自研的游戏分布式框架就是用的这个，挺好用的！
|
 |
105
BadMan 2021-08-18 19:28:55 +08:00
提一下应用层分包策略：
1. 采用固定长度 2. 采用固定分隔符（ redis 采用这种） 3. header+body，在 header 固定位置标识整包长度 另外 1. tcp 、udp 、http 、quic 是网络协议 2. grpc 、brtc 是 rpc 框架，和网络协议不是一个层面的概念，grpc 应该是使用 http 2.0 作为默认网络协议 |
 |
106
janxin 2021-08-18 21:17:34 +08:00
net 库已经很标准了，不过要真正上业务确实要自己封装很多东西出来。
想偷懒非要实现要封装一层，gnet/evio 是个不错的选择，保证了可定制性，内置优化不用自己做额外操作。如果你数据格式都没定义，那么 zinx 适合你，它是定好的格式，缺点如果接入已存在协议就很麻烦了。 如果对 TCP 不了解选择双向 RPC 框架也可以，底层 TCP 还是 Websocket 之类的并不重要，框架会帮你处理。 |
 |
107
iyaozhen 2021-08-18 22:58:04 +08:00
强烈推荐字节的 https://github.com/cloudwego/netpoll，内部一切框架的基础，但可能资料太少了
还得说下粘包，有些人可能觉得很形象，但实际是偷懒的概念理解，你都要搞 TCP 了，还有很多底层需要理解，如果不扎实后面是要吃亏的 |
|
108
lesismal 2021-08-19 01:05:50 +08:00
@iyaozhen 欢迎来跑数据对比下，包括 cloudwego/kitex-benchmark，我都有 pr 和 issue：
https://github.com/lesismal/go-net-benchmark/issues/1 |
 |
109
lewinlan 2021-08-19 08:08:21 +08:00 via Android
看了几年的👮🏻♂️了，现在看到还是想笑。
|
 |
110
raptor 2021-08-19 09:44:18 +08:00
@ming159
62 楼已经解释清楚了，这事不是 TCP 该干的，还是去复习一下 TCP 的基本原理吧。 54 楼所说的以#开头，以$结束就是定义了一个最简单的基于 TCP 的应用协议（但显然是有问题的，比如，如果数据流本身包含了#和$要怎么处理，最大长度有没有限制等等），那么实现这个协议就是你自己的事情，跟 TCP 没关系。 |
 |
111
daimazha 2021-08-19 10:33:00 +08:00
|
 |
112
wqtacc 2021-08-19 20:58:34 +08:00
你这个和粘包没关系，是要自己定义应用协议
|
 |
113
eastphoton 2021-08-20 00:43:27 +08:00  1
对楼上一些人无语，
对，TCP 是流、是传输层，包不是 TCP 该管的事，真的很正确。 可总有人得处理从流到包，楼主的意思不就是想要一个框架帮他在教科书中的应用层先处理完这些事嘛， 又有什么不合理的呢，不就是插个中间层再给 TCP 封装一层，七层五层模型本质不也是层层封装， 每次非得有人在这出警整些原教旨，显得好像就他学过。 |
 |
114
joetse 2021-08-20 00:57:19 +08:00
tcp 是保证顺序的, 你可以简单地自定协议, encode, decode, 处理头尾, 不过我是用其他语言工具写的, 用了好多锁去判断状态, 一个模版套上处理各种奇奇怪怪的设备的 process, go 应该也差不多吧, 起步挺麻烦, 模版通过测试之后就稳了. 感觉不是高并发场景就没用上框架.
有高并发需求再去看看 netpoll, gnet, evio, 学习了~ |
 |
115
WoWTxT 2021-08-20 11:42:55 +08:00 1
粘包警察就是 SB，你是真不理解还是假不理解楼主的提问，搞 TCP 的谁不知道式流式传输。大家都知道一说粘包就是要处理应用层数据问题，粘包警察非但没有解决楼主的问题，还抓着教科书式的说法不放嘲笑说粘包的。你们咬文嚼字是比解决问题挣得多还是咋地？请问你们的优越感来自哪里？
|
 |
116
fqzz 2021-08-20 12:42:52 +08:00
|
 |
117
magicrolan 2023-02-14 14:01:58 +08:00
知道楼主意思就得了
非要一堆人搁那卖弄聪明啊。 |
 |
118
awanganddong 290 天前
这里有需要的扩展包
https://github.com/alberliu/gn |
Select Language