1
unnamedhao 2021-10-20 14:55:19 +08:00
因为 tcp 有粘包,需要拆包
|
2
MatDK 2021-10-20 15:03:13 +08:00
有没有可能是这样。 例如你用 chacha20 加密了 data1,2,3,4,5,长度都为 64 。
前面的 data1,2,3 是分别以 tcp1,2,3 packet 的形式到达的,当然没有问题 到了 data4,5 可能被合并成了 1 个 tcp packet 4,长度 128,接收方并不知道这是 2 个 64 合并成的(不知道你有没有加控制字节)。 在加密时用了 2 个 64 的 keystream 。但是解密的时候直接用了 1 个 128 的 keystream,数据就不对了。 当然可能是我理解有问题....我没理解你用 chacha20 加密流,是持续的[接受 1 个,加密 1 个,发出 1 个],还是[接受 1 个 /多个,加密 x 个定长的块,发送 x 个]。 你如果用 tcp 加密的话,升级到 tls 不就行了?把 tls 的 send,recv callback 换成你自己的。tls 会有控制字节告诉接收方到底有多少数据被加密 |
3
GeruzoniAnsasu 2021-10-20 15:03:20 +08:00
内存对齐、缓冲区分配和覆盖、分片大小的边缘条件、计数器某种溢出……
你应该本地 dump 一份远程 dump 一份然后逐环节核对,100k 也不大,二分几次应该还比较容易找到错误开始的位置 |
4
longkas239 OP 谢谢楼上兄弟们,我好像有思路了,虽然两端加密参数不动,持续加密解密数据流后两端数据应当是一致的。但是前提是一端发送的所有数据另一端必须全接收到,如果发生丢包,接收端的加密算法的状态就和服务端不一致了,后续解密也就全错。 解决办法是拆成小包加密解密,包不全丢弃,每个新包开始后对两端的加密算法统一
|
5
unnamedhao 2021-10-20 17:15:59 +08:00
tcp 不会丢包但是会粘包
发送三次[0123][456][789] -> 接收两次[1234][56789] |
6
unnamedhao 2021-10-20 17:17:40 +08:00
所以要自己做消息头,例如添加发送消息的长度,自行处理拆包
|
7
byaiu 2021-10-21 09:29:53 +08:00 via iPhone
为啥要自己重新发明一遍 tls ?
|
8
soki 2021-10-21 13:59:48 +08:00
tcp 是流,哪来的包,何来粘包一说,那是应用层的事
|
9
labulaka521 2021-10-21 17:15:20 +08:00
可以给加个 fec 来减少丢包的错误
|