Golang Go语言中有什么TCP框架?
Golang Go语言中有什么TCP框架?
可以管理连接, 心跳包 处理粘包等,
web 方面的很多, tcp 的没找到,大家做 TCP 都用什么呢?
#2 不是 我要做的是 c/s , 用 net 包可以,但是连接管理, 心跳包 粘包等要自己处理,想问下 TCP/IP 有没有什么框架.大家都用什么…好像用 go 做这个的少吧.
#1 谢谢,现在好像都是用 rpc 了? 到现在也也不是太懂 rpc,以为比传统的 tcp 通讯复杂,也没仔细看过.
刚查的,是这样吗? https://www.zhihu.com/question/41189095
CS 架构其实也可以用 HTTP 的，如果需要双向通信可以 Websocket 。如果种种考虑不想选择 HTTP 的话，首选建议是 grpc，类似的替代方案也有 messagepack 或是 Go 自己的 gob 也
TCP/UDP 是在第三层（ TCP/IP 协议栈不是 OSI ）
HTTP 是在 TCP 上面的套娃，在第四层（例外：HTTP/3 是在 UDP 上面的套娃）
你说的那些常见 RPC 协议，要么是跟 HTTP 一样直接在 TCP/UDP 的上面。要么像 GRPC 那样直接在 HTTP 上面再套
你甚至可以把 HTTP 当成一种 RPC 都没问题。
所以没有必要自己基于 TCP 自创一个 RPC 协议，直接用现成成熟的就行了，像 Thrift，gRPC 这种。
不过我建议是最最最最最简单的 HTTP 一把梭。
如果你非要自己实现，可以使用像 go-netty 或者 getty 的这种，自己定义好 codec，然后框架会帮你处理所谓的“粘包半包”问题。
粘包警察的工作不到位啊，都批了这么久了，还有人以为存在“粘包”这种伪概念……
你们以为的“粘包”是 TCP 的 feature，不懂说明你没学好
你们会碰到“粘包”是因为你们在 TCP 之上定义的协议有问题，说明定义这个协议的人没学好
正是因为流协议所以才没有“粘包”的说法，TCP 就像一条水管，数据是源源不断流过去的，特性就是这样。TCP 会导致“粘包”这个说法是不对的，TCP 和粘包不存在因果关系
TCP 本就是流协议，没有包的概念。如果需要划分包，一定是要在上层协议里设计长度标识位来划分包和包之间的隔离线。例如 HTTP 里的 Content-Length，Socks 里的 domain-length 等等。
举个现实里的例子：TCP 协议就是一根水管，你拿着许多瓶矿泉水往管子对面输水，对你来说，水是一瓶瓶的，之间的区别很明显。但对于那边的人来说他只能收到一波又一波的水，至于这些水是属于哪一瓶的，他不知道。如果运气好，每一波水之间间隔也会很明显，但是这并不代表水管帮你把这些水分割了。运气不好的时候，水就连在一起下来了，这就是他们嘴里说的粘包。
TCP 协议里明明白白写了：面向流。它把数据以流的形式，可靠地发送给接收方，它的事情就完美地做完了。
你们提出的“粘包”概念是应用层自己该解决的，你们可以说，应用层的粘包问题，但说“TCP 的粘包问题”，是不严谨的
你说的这是一种,我没记错,应该叫做 “定长协议” ,就是一个数据段固定长度,比如 512 个字节.每次固定取这么长度的就可以.
但是还有"可变长度"的协议,就需要在数据段中某个固定位置上指示 本次数据自身的长度,例如: #3abc,#5abcde.
表示 #开头,随后的数字表示后续数据的长度,比如 3,5,分别表示在此之后还有若干个数据才算一段完整的数据集.
还有另外一种,固定以回车换行符为分隔符的,无论多长,只要有回车换行符就切断
“TCP 的粘包问题” 确实不严谨.这点我也承认.
“基于 TCP 传输数据,必然存在应用层数据的 粘包 /拆包问题”.
如果写过 TCP 通信(Socket 编程)的懂得自然懂,不懂得说多了也没用, 可以参考 Netty 中的
LineBasedFrameDecoder : 基于回车换行符的解码器
DelimiterBasedFrameDecoder: 分隔符解码器，可以指定消息结束的分隔符
FixedLengthFrameDecoder: 固定长度解码器，它能够按照指定的长度对消息进行自动解码
LengthFieldBasedFrameDecoder :一般协议头中带有长度字段，通过使用 LengthFieldBasedFrameDecoder 传入特定的参数，来解决拆包粘包
#62 严格来说是这样的，但是人与人沟通没必要这么抠字眼，能理解就行，就像叫人吃饭，难道就真的只吃饭不吃菜？
楼主只是想找个在应用层可以处理粘包问题的框架，并没有将“粘包问题”甩锅给 TCP 的意思，但是为什么要抓住这个点不放呢？
您好，请教下粘包的问题。TCP 有重传机制和 ACK 机制，经过 TCP 传输的数据包应该是可靠的。应用层拿到的数据包应该也是完整的、有序的，为何会出现应用层接收到数据包是不完整或者是乱序的情况。—来自没有开发经验的小学生
是个程序员都明白，人家问的就是应用层有没有“从字节流中拆出消息”的轮子。粘包警察纠着“粘包”两个字不放有意思吗？难道楼主不知道 TCP 是流协议，要你教？
楼主明明说了使用“粘包”和“拆包”是因为描述方便。粘包警察会因为老婆饼里没老婆跟老板打一架吗？
理解一下［流］协议这个说法。TCP 协议的有序性和完整性保证是针对整个流来说的，并不是代表接受端的每次 read 拿到的恰好是发送端每次 write 的内容。比如，当 TCP 一个包过大的时候，会在实际传输的时候拆开
#72 很简单的举例，水管漏了，中间有一部分数据丢掉了。但是不代表后面的数据就不能正确到达目的地。有序只是接受端和发送端会按照顺序发送数据和接受数据，并不代表每次都会等到收到接受端前一个数据已收到的状态码才发送下一段数据，这样效率是很低下的。
你要写裸 TCP ？首先就是先定义 Frame 或者 Protocol，然后基于上述将 Payload 用于业务=。=详情见 HTTP 是怎么做的。。。一个意思
54 楼 并不是虚构的协议. 可以参考
1. Modbus ASCII 在 ASCII 传输模式下，消息帧以英文冒号”:”（ 3A ）开始，以回车（ 0D ）和换行（ 0A ）结束.
2. 基恩士 PLC 中的 上位链路协议: [功能码] 开始,回车（ 0D ）结束.
TCP 保证了 有序性,完整性. 是指:
发送端 发送了 #1 2 3 4 5$ #a b c d e$ . 接收端最终收到的也是 #1 2 3 4 5$ #a b c d e$ 有序,且完整.
但是
接收过程
接收过程
接收过程
(重要的点) 会是这样的
情况 1: #1 2 3 4 5$ #a b c d e$
情况 2: #1 2 3 和 4 5$ #a b c d e$
顺序没乱,且数据没丢.
但也可以是 长度（ 4 字节）+buffer，缓冲区可读,那么查看先读长度，然后根据长度往后取 buffer,有多少取多少,因为没有取够, 那么下一次再次通知的时候,与上一次的已经取出来的拼接,直到取够 “长度” 为一次完整帧.
在Golang（Go语言）中，有多个TCP框架可供选择，这些框架各具特色，适用于不同的应用场景。以下是一些知名的TCP框架：
-
goev：
- 特性：轻量、极简方式实现Reactor模型，支持异步响应，完美解决per-connection per-goroutine的问题，对GC友好。
- 适用场景：RPC服务、游戏服务、proxy、nosql、mq等基于TCP协议的高性能网络服务。
-
TCPX：
- 特性：纯Golang开发，具备TCP通信中常见问题的解决方案，如拆包、心跳检测等。仿制HTTP框架gin，支持中间件模式，使用简便。
- 仓库地址：https://github.com/fwhezfwhez/tcpx
-
Kinx（或Zinx的变种）：
- 特性：通过线程池+任务队列来管理goroutine，提高资源利用率。支持自定义协议解决TCP粘包问题，具备心跳检测功能。
- 仓库地址：https://github.com/k-si/Kinx
此外，Go语言的标准库net也提供了丰富的TCP网络通信接口，开发者可以基于标准库创建和管理TCP网络服务。对于简单的TCP服务器和客户端实现，标准库已经足够强大和灵活。在选择TCP框架时，建议根据项目的具体需求和性能要求来选择最合适的框架。
