golang 有什么 TCP 框架?

[zyxk]

可以管理连接, 心跳包 处理粘包等,
web 方面的很多, tcp 的没找到,大家做 TCP 都用什么呢?

[maplelin]

@deavorwei #72 很简单的举例，水管漏了，中间有一部分数据丢掉了。但是不代表后面的数据就不能正确到达目的地。有序只是接受端和发送端会按照顺序发送数据和接受数据，并不代表每次都会等到收到接受端前一个数据已收到的状态码才发送下一段数据，这样效率是很低下的。

[Michaelssss]

你要写裸 TCP ？首先就是先定义 Frame 或者 Protocol，然后基于上述将 Payload 用于业务=。=详情见 HTTP 是怎么做的。。。一个意思

[ming159]

@darknoll 54 楼 并不是虚构的协议. 可以参考
1. Modbus ASCII 在 ASCII 传输模式下，消息帧以英文冒号”:”（ 3A ）开始，以回车（ 0D ）和换行（ 0A ）结束.
2. 基恩士 PLC 中的 上位链路协议: [功能码] 开始,回车（ 0D ）结束.

[dbpe]

哈哈哈....笑死

谁知道 http1.1 的长链接是怎么做的呢...


斜眼笑

[ming159]

@deavorwei
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$
顺序没乱,且数据没丢.

[jsq2627]

23333 当看到 LZ 写了“粘包”两字就猜到帖子的走向了。

[wengang285]

@ming159 长度（ 4 字节）+buffer，缓冲区可读，那么查看先读长度，然后根据长度往后取 buffer，长度不够这次就不取，等待底层（ epoll ）的再次通知

[ace12]

看到粘包，我就兴奋了哈哈哈

[SillyChenBrother]

TCP 没有所谓的粘包说法

网络层，IP 数据报帮你分报，在这里会切块
传输层，TCP 帮你分块，这里也会分块，但 UDP 就不会分

TCP 传过来，你通过程序收到的数据肯定是不会破损的，都三次握手四次放手，拥塞控制，失败重传，流水线运输，传过来就都是对的数据。

数据是一个流，过来的一个个报文，也就是所谓的包，你要自己处理数据边界，也就是说你自己定义的应用层协议必须处理如何区分边界的问题，比如发现开头是 Xx 就是你的一个切确的文本的开始，或者叫结构体的开始，直到 yyy 就是文本的结束，以此反复，也就是解码和编码的问题，也就是说这已经不是传输层的问题了，这是应用层了，参考 http，ftp 等协议，gRPC/thrift 这种序列化解编码就是你文中描述所需要用到，所以粘包的描述是多年来的玄之又玄的说法，每次听起来一头雾水，然后面试官还喜欢装逼问这个。

设计好解编码二进制的序列化应用层协议，就没有所谓的粘包，拆包，朦朦胧胧，龙龙萌萌

[ming159]

@wengang285
但也可以是 长度（ 4 字节）+buffer，缓冲区可读,那么查看先读长度，然后根据长度往后取 buffer,有多少取多少,因为没有取够, 那么下一次再次通知的时候,与上一次的已经取出来的拼接,直到取够 "长度" 为一次完整帧.

[tonyan93]

粘包并不是 TCP 协议造成的，它的出现是因为应用层协议设计者对 TCP 协议的错误理解，忽略了 TCP 协议的定义并且缺乏设计应用层协议的经验。

[JoeBreeze]

TCP: 你们在说啥?

[lesismal]

足够满足楼主和各位各种业务场景：
https://github.com/lesismal/arpc

[lesismal]

@abersheeran 没办法，"粘包" 虽然是错误的概念，但已约定俗成，懂的人只是用这个词沟通问题

[D3EP]

Golang 这种阻塞 IO 模型还要什么框架..

[wengang285]

@ming159 也可以，但是这样会导致解码的逻辑多处理一个分支，增加代码的复杂性，但是并没有带来性能的提升，实际工程中不会这么写

[ming159]

@wengang285 根据实际场景选择吧,例如 数据量相对较大,且 buffer 小的时候,如果不尽快从 buffer 中取出数据, 引发 流量控制机制,反而导致整体传输变慢.

[LewisW]

@noe132 你也太神了 顶级预测

[xuanbg]

老老实实用一个 http 之类的应用层协议，而不是把 TCP 协议当应用层协议用，哪来的粘包。

[lesismal]

介绍下自己俩库，arpc 和 nbio：
https://www.v2ex.com/t/794435#reply0

这两个库可以覆盖绝大多数应用业务场景，比如：RPC 、IM 、游戏、广播 /推送服务、其他自家功能交互等。
支持 tcp/kcp/quic/websocket 各种协议作为传输载体。
单机连接数量不特别大比如 10k-100k 这种级别的（普通人眼里觉得 10k 已经算大了，但是对于网络框架而言，这个量级很小，那些性能差的脚本语言就不要来讨论性能了），配置能扛得住就默认标准库方案。
海量并发比如单机 100k-1000k 这种级别的，可以 arpc+nbio，照样能扛。
这个领域里，一是性能，二是易用性，有兴趣的同学可以自行对比。
关于性能，有兴趣的同学可以去看下鸟窝老师和字节同学的 benchmark 库，硬件不同压测结果可能存在差异，所以有兴趣的同学不要看仓库文档展示的结果，请自己机器实测看效果：
github.com/rpcxio/rpcx-benchmark
github.com\cloudwego\kitex-benchmark