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

[dying4death]

简单地说，服务端将一段数据 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]这样。所以无法解密。

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

[newtype0092]

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

[lingxi27]

粘包警察密切关注此贴（狗头）

[zhujinliang]

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

[mosfet]

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

[wanglufei]

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

[hzwjz]

粘包警察密切关注此贴（狗头）

[cs419]

粘包问题大家都说了

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

[back0893]

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

[alphatoad]

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

[liuguang]

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

[Mohanson]

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

[lxz6597863]

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

[nnnToTnnn]

@zappos #6 什么叫做 TCP 粘包？ 那特么就是自己程序没写好！！！！！！

[wlgq2]

粘包警察虽迟，但一定会到：)