Golang Go语言中怎么避免连续读取过多字节(TCP)

Golang Go语言中怎么避免连续读取过多字节(TCP)

简单地说,服务端将一段数据 AES 加密,客户端接收到数据后解密。

伪代码展示:

// 从输入流里读取加密过的数据,解密后把原数据放到 bs 里
func (secureSocket *conn) DecodeRead(bs []byte) (data []byte, err error) {
n, err := secureSocket.Read(bs)
if err != nil {
	fmt.Println("decode read: ", err)
	return
}
fmt.Println("decode read: ", bs)
fmt.Println("decode read count: ", n)
data, err = secureSocket.Cipher.decode(bs[:n])

return

}

// 把放在 bs 里的数据加密后立即全部写入输出流 func (secureSocket *SecureTCPConn) EncodeWrite(bs []byte) (int, int, error) {

data, err := secureSocket.Cipher.encode(bs)
if err != nil {
	return
}
writedCount, err := secureSocket.Write(data)
if err != nil {
	return 0, 0, err
}
return writedCount, len(data), nil

}

环境使用 Mac,本地测试一切正常。加解密以及数据转发等都能正常进行。然后将服务端代码打包成 linux 执行文件丢到 VPS 中运行,出现了客户端解密失败,发现是因为客户端读取数据时,读取了多段字节,导致无法解密。

比如说就是,服务端依次发送,[1 2 3],[4 5 6]两端加密后的字段,客户端读取了[1 2 3 4 5 6]或者其他可能,并不是读取[1 2 3],然后[4 5 6]这样。所以无法解密。

因为服务端也是转发的数据,客户端无法确知加密后完整的一段数据长度时多少?


更多关于Golang Go语言中怎么避免连续读取过多字节(TCP)的实战教程也可以访问 https://www.itying.com/category-94-b0.html

55 回复

奇怪的地方在于,mac os 没有问题。把服务端代码打包成 darwin 后,放在同事的 macbook 上跑,也是正常的

更多关于Golang Go语言中怎么避免连续读取过多字节(TCP)的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


TCP 传输数据的时候本来就是这样的( TCP 没保证数据按照你输入的间隔发送,只是保证了顺序和输入的顺序一样),TCP 本身只是保证了数据传输的事情,你这个算协议的部分,一般解决之道都是定长,或者特定结束符之类的解决办法。

分包问题

TCP 根本就不分段的,你需要自己定义一个边界,然后在边界上把包分开再解密

TCP 是流式协议

请搜索 TCP 粘包问题。。

TLV 了解下

TCP 本来就是流式的协议,没有包的概念。

TCP 是一个数据流,你要自己定义包的概念再去切分

算了直接说吧,有两种方式,第一种就是像链路层那样添加分割符,比如 FFFF 当分隔符,那么数据里的 FF 就变成 FFFE 之类的。

第二种就是像 HTTP 那样,如果一个字段是不定长的,那么把长度写在前面。

你需要自己定制协议,比如用 int16 来标记数据长度, 发送端: len(2 bytes int16) + data

读取端链接建立后, 先读 2 bytes, 转换成 int16, 你就之后 data 数据多长了, 继续读 data. 后续又是 len + data …

tcp 是面向数据流的连接
你要从流中读取特定分段,可以:
使用转义字符分割,例如用"/0"作为数据结尾,并在发送的时候将原始数据中的 /替换为 //。这样每次读取到 /0 就可以将已经读取到的数据分离出来,然后将 //还原为 /就是原始数据
或者在开头的地方添加一个 2 字节的数据长度字段,每次先读取 2 字节,然后继续从流中读取一个确定的长度

粘包警察密切关注此贴(狗头)

使用 cipher.NewOFB + cipher.StreamWriter 等方式做加密,
加密时 [1 2 3],[4 5 6] 分开写加密,读取时 [1,2,3,4,5,6] 一次读取解密也能获得正确的明文。

TCP 是流式协议,并不保证你每次发多少字节就会每次收多少字节,这个要通过自己的分包协议实现

看到粘包两个字了,过一会怕是又干起来了。

你需要自己定个简单的协议比如[前四字节 data 长度][data]
[0x00,0x00,0x00,0xff][0x00,0x01…]
接收端先读 4 字节长度,算出长度后再接收 0xff 个字节 这就是你需要解密的数据

看一下 nsq 的源码: https://github.com/nsqio/nsq/blob/master/nsqd/protocol_v2.go#L54
楼上很多人都说了,TCP 是流式协议,需要自己定义协议格式,然后按照协议去读取并解析。

TCP 是流式协议

大学不讲 tcp/ip 吗?

如果不想处理流,建议上 websocket,加密数据后 base64,
以 text 模式发送。间接达到你们的一发一包的需求

偷懒的话直接 websocket 就完事了。。如果没什么特殊需求的话

粘包警察密切关注此贴(狗头)

目前仅仅一个人用作关键词,我觉得还能接受
密切关注中

这就是为什么各种协议要么定长要么传长度要么特殊结尾字符
或者使用上述三者的两者甚至三者都用上

粘包警察密切关注此贴(狗头)

真想弱弱的问一句 HTTPS 他不香吗…

粘包警察什么梗?

知道包大小后,网络流读取大小可以通过计数器设置缓冲器读取大小

起源于这个 https://www.v2ex.com/t/478610 , 其实如果做过 UART 接受数据拆包的话,很好理解的,甚至没觉得有这个问题

粘包警察密切关注此贴(狗头)

这个属于粘包问题,需要自定义协议,包头定长,包体不定长,然后包头中包含包体的长度。

请注意,粘包学家正在赶往此贴。。。

粘包警察是什么梗……看了那帖子也不清楚

粘包学家认为,这肯定是 TCP 的问题,名曰 “粘包”。
粘包警察认为, “粘包” 这个词侮辱了 TCP。

#36 学到了

粘包警察密切关注此贴(狗头)

tcp 粘包,我一般是头四个字节写包的长度,然后 tcp 再读取固定长度,最好再判断一下头四字节的长度是否合法。

6 楼已经来了(捂脸)

“粘包警察”是嘲讽普及正确概念的人?

就是有些人用水龙头接水洒了一地,冥思苦想后觉定用杯子一杯一杯接,然后把这种方法整理成册大肆宣传,声明自己解决了水龙头的一大缺陷。

粘包警察密切关注此贴(狗头)

方法 1. 处理“粘包🐶”
方法 2. 使用 CFB 之类的流加密模式

你可以参考 MODBUS 协议,增加起始符和停止符

以前面试就该问题差点和面试官干起来

粘包警察密切关注此贴(狗头)

粘包问题大家都说了

不过描述中 先是自己加密解密
完了又说不是自己加密的 。。。

粘包吧.
tcp 定义 header+data
header 作为 data 的长度

用 stream cipher 解决你的所有问题
神 tm 粘包

粘包问题,定好传输协议就不会这样了

TCP 是流协议,只有 UDP 才有包的概念。所谓粘包…就是早年国内一些不了解 TCP 原理的人发现一个自己脑袋无法理解的现象后造出来的概念… 记住了,讲这个词会被人笑话的

TCP_NODELAY 可能是这个影响的
但是还是建议自己定个包头格式

#6 什么叫做 TCP 粘包? 那特么就是自己程序没写好!!!!!!

粘包警察虽迟,但一定会到:)

在Golang中处理TCP连接时,避免连续读取过多字节的一个关键策略是采用分块读取(chunked reading)和流式处理(streaming processing)。以下是一些具体的建议:

  1. 使用bufio.Reader的Peek或ReadBytes方法:这些方法允许你预览或读取直到特定分隔符的数据,从而避免一次性读取整个消息。例如,你可以使用Peek方法检查是否有足够的数据来解析一个完整的消息,然后再使用Read方法读取这些数据。

  2. 设置合理的缓冲区大小:使用bufio.NewReaderSize创建一个具有合适缓冲区大小的Reader。这可以帮助控制内存使用,同时允许你逐步读取数据,而不是一次性加载大量数据到内存中。

  3. 实现流式处理逻辑:在读取数据时,实现一个循环,每次只读取并处理一部分数据,直到所有数据都被处理完毕。这可以通过在读取循环中检查错误和数据长度来实现。

  4. 利用goroutines和channel:将读取和处理数据的工作分散到多个goroutines中,通过channel传递数据块。这样不仅可以提高并发性,还能更有效地管理内存和资源。

  5. 设置读取超时:使用SetReadDeadline方法设置读取操作的超时时间,以防止因等待数据而导致的资源长时间占用。

通过上述方法,你可以更有效地管理TCP连接中的数据读取,避免一次性读取过多字节,从而提高程序的性能和可靠性。

回到顶部