这是一个创建于 1000 天前的主题，其中的信息可能已经有所发展或是发生改变。
在没使用 tls 的时候，假设规定一个数据包由（包头（ 4 字节）+包体）组成，这样就很好获取一个完整的包，那我的疑问就是使用 tls 后，数据经过加密了，因此数据包大小也会发生改变，之前的那套规则就行不通了，那在接收数据的时候，怎么才能知道接收到的是一个完整的加密数据包？
 |
1
neoblackcap 2022-02-26 15:17:16 +08:00
流加密，加密前后信息长度是一样的。
|
 |
2
GGPlayer 2022-02-26 15:18:58 +08:00
只需要加密包体即可
|
 |
3
0o0O0o0O0o 2022-02-26 15:22:48 +08:00  6
|
 |
4
sunny1688 OP @neoblackcap 这个还没注意，我试下
|
 |
5
Biwood 2022-02-26 15:25:18 +08:00
数据完整性校验恐怕不是 TLS 来干的事情，而是 TCP 协议做的事情，一个应用层，一个传输层，TLS 协议建立在 TCP 协议之上，TCP 连接成功了，TLS 数据就没问题。有问题的话那也是证书验证不通过，密钥被篡改之类的问题，而不是丢包问题。
|
 |
6
rrfeng 2022-02-26 15:42:40 +08:00 via Android
首先 TCP 是流没有包
其次 TLS 是对数据流加密，头部不变。 |
|
7
sunny1688 OP @neoblackcap 加密前 18 字节，加密后 40 字节，不理解您说的长度不变是什么意思
|
 |
8
feather12315 2022-02-26 15:54:18 +08:00 via Android
多一比特跟少一比特解密后的数据不一样，这个是雪崩效应。
换个角度想：block 类型的加密不需要关注包大小，解密后的数据包大小是固定的，协议自己验证相关的数据对不对。 |
 |
9
jinliming2 2022-02-26 16:12:16 +08:00 4
你原始的 TCP 直接传裸数据时，自己可以定义包头+包体的结构。
但是中间加了一层 TLS 之后，你自己定义的结构对于 TLS 来说都没有意义了，都看作一堆无意义的二进制流。 然后 TLS 会自己对这一堆二进制数据流进行包装，包装成一个一个的 Application Data 帧，每个 Application Data 帧里可能包含了一个你的自定义包头+包体结构，也可能包含了两个，也可能包含了半个，具体包含多少是 TLS 层面决定的（单个帧最大 16K ，通常根据实际情况动态调整。单帧大了，可能会受 MTU 、MSS 限制而在 TCP 层面再拆分；单帧小了，则会浪费帧头的传输）。 Application Data 帧的结构与你的包头+包体结构类似：1 字节的帧类型（ 0x17 Application Data ），2 字节的 TLS 协议版本号，2 字节的数据长度，然后后面跟加密初始化向量和加密后的帧数据。（注：这里的数据长度是指后面初始化向量和**加密后**的数据的总长度，与加密前的数据多长无关） |
 |
10
Rieouu 2022-02-26 16:12:54 +08:00
包是应用层协议考虑的
|
|
11
sunny1688 OP @jinliming2 非常感谢，让我一下就明白了
|
 |
12
keepMyselfClam 2022-02-26 22:17:20 +08:00
之前是直接将数据放在 tcp 上传输的. 那么加上了 TLS 层之后不应该去关心或者直接处理 tls 加密后的数据.
而应该使用 tls 解密以后的数据. 这样 TLS 层对上面是透明的,数据内容也不会变,就不会影响之前的逻辑. |
|
13
sunny1688 OP @keepMyselfClam 是的，我有点搞混了
|
 |
14
ysc3839 2022-02-27 11:40:40 +08:00 via Android
@Biwood TLS 是要保证数据完整性的，TCP 反而不需要保证。虽然 TCP 头有校验码，但是大多数网络设备都会忽略不管的。早年间 http 下载文件可能会损坏就是一个例子。
|
Select Language