用 chacha20 加密流，chacha20 在传输开始时初始化，之后不改变加密参数，理论上 tcp 保证了到达顺序，就算 tcp 拆包，客户端持续解包数据应该正常。现在情况是传了 100 多 k 后数据不对了，有可能是哪里问题，在用 rust 的异步调用，有可能与之有关吗
This topic created in 1669 days ago, the information mentioned may be changed or developed.
 |
1
unnamedhao Oct 20, 2021
因为 tcp 有粘包,需要拆包
|
 |
2
MatDK Oct 20, 2021
有没有可能是这样。 例如你用 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 Oct 20, 2021
内存对齐、缓冲区分配和覆盖、分片大小的边缘条件、计数器某种溢出……
你应该本地 dump 一份远程 dump 一份然后逐环节核对，100k 也不大，二分几次应该还比较容易找到错误开始的位置 |
 |
4
longkas239 OP 谢谢楼上兄弟们，我好像有思路了，虽然两端加密参数不动，持续加密解密数据流后两端数据应当是一致的。但是前提是一端发送的所有数据另一端必须全接收到，如果发生丢包，接收端的加密算法的状态就和服务端不一致了，后续解密也就全错。 解决办法是拆成小包加密解密，包不全丢弃，每个新包开始后对两端的加密算法统一
|
|
5
unnamedhao Oct 20, 2021
tcp 不会丢包但是会粘包
发送三次[0123][456][789] -> 接收两次[1234][56789] |
|
6
unnamedhao Oct 20, 2021
所以要自己做消息头,例如添加发送消息的长度,自行处理拆包
|
 |
7
byaiu Oct 21, 2021 via iPhone
为啥要自己重新发明一遍 tls ？
|
 |
8
soki Oct 21, 2021
tcp 是流，哪来的包，何来粘包一说，那是应用层的事
|
 |
9
labulaka521 Oct 21, 2021
可以给加个 fec 来减少丢包的错误
|
Select Language