一、L6 表示层是什么目录一、L6 表示层是什么二、L6 的功能和特性三大功能OSI 7498 给的标准定义三个特性三、L6 专业术语 专有名词表 术语表 重点挑讲 4 个1. 抽象语法 vs 传输语法2. TLSL6 的门面担当3. MIME表示协商的现实例子4. ASN.1 BER/DER补充TLS介绍一、TLS 是什么定位 来龙去脉版本演进二、TLS 的四个作用1️⃣ 机密性 —— 别人看不懂2️⃣ 完整性 —— 数据中途被改能发现3️⃣ 身份认证 —— 你连的确实是 google.com不是伪装的4️⃣ 密钥协商 —— 双方算出同一个会话密钥且不希望服务器私钥泄露就连累历史会话三、TLS 协议的内部结构四子协议四、TLS 的几个常见工程扩展纯介绍不深—OSI 第 6 层它解决的核心问题是“发送端和接收端对’数据的样子’理解不一致”——字节序不同、编码不同、加密没商量好L7 直接解析就炸。所以 L6 不关心这坨数据是 GET 还是 POST、是邮件还是网页那是 L7只关心数据在线上长什么样、到了对面能不能原样还原。类比收口一下前三层L4 传输层管送到可靠/不可靠端口寻址L5 会话层管对话怎么组织建/断/续/令牌L6 表示层管数据怎么表示编码/加密/压缩二、L6 的功能和特性三大功能OSI 7498 给的标准定义1. 语法转换Syntax Transformation不同机器字节序大端/小端、字符集ASCII/EBCDIC/UTF-8、数据结构描述方式不一样L6 负责把发送端的抽象数据翻译成线上通用字节流对面 L6 再翻回来。例x86 是小端网络协议全是大端网络字节序所以有了htons/htonl/ntohs/ntohl——这四个函数本质就是 L6 语义。2. 数据加密与解密对 L7 下来的数据做加密对面 L6 解密后再上交 L7。加密/解密动作本身不关心上层是 HTTP 还是 FTP 还是 SMTP——这也是为什么 TLS 被归到 L6它是最纯的 L6 协议。3. 数据压缩与解压减少传输量gzip/deflate/brotli 都属这类。早期 SSL 是先压再加密后来出了 CRIME 攻击TLS 1.3 直接砍掉压缩——所以这功能现在基本只剩应用层自己压HTTPContent-EncodingL6 本身不怎么动了。三个特性特性说明透明性L7 不感知下面有没有加密/转码L6 对 L7 是透明的当然 TLS 例外L7 得配合 ALPN 啥的但理论上透明上下文协商会话建立时 L6 先商量咱俩用啥编码、啥加密套件、啥压缩TLS ClientHello 里的 cipher suites 就是这语义与 L7 强耦合现实里数据表示和数据语义分不开HTTP 既要管 GET 也要管Content-Type所以 TCP/IP 把 L6L7 合并了L6 独立存在的意义主要靠 TLS 撑着三、L6 专业术语 专有名词表 术语表类别术语是否重点一句话核心协议TLS / SSL⭐⭐⭐L6 的门面加密认证完整性HTTPS⭐⭐HTTP(L7) TLS(L6)编码/序列化ASN.1⭐⭐抽象语法定义证书/SNMP 用BER / DER⭐⭐ASN.1 的传输编码DER 是证书用的严格版XDR略Sun RPC 的序列化老字符编码ASCII / EBCDIC / UTF-8 / Unicode略跨机字符表示概念知道就行压缩gzip / deflate / brotli⭐HTTP Content-Encoding 那堆表示协商MIME (Multipurpose Internet Mail Extensions)⭐⭐Content-Type; charset这套最初为邮件设计HTTP 继承概念对抽象语法 vs 传输语法⭐⭐⭐L6 教材最爱考的一对接口概念表示上下文Presentation Context⭐L6 协商这次会话用哪种抽象语法哪种传输语法的统称 重点挑讲 4 个1. 抽象语法 vs 传输语法抽象语法“我要传一个整数 65535 字符串 ‘hello’”——这是语义描述跟字节怎么排无关传输语法按某种规则编码成线上字节比如 ASN.1DERTLS 证书里就是02 03 00 FF FF ...L6 的本分L7 给抽象语法 → L6 转传输语法发出去 → 对面 L6 转回抽象语法 → 交 L7。 映射到现代协议更好懂Protobuf 的.proto文件 抽象语法protobuf wire format 传输语法。gRPC 整套就是 L6 思维只是没单独抽一层。2. TLSL6 的门面担当严格说 OSI 里 L6 应该只加密不关心业务TLS 完美符合协商加密套件AES-256-GCM? ChaCha20?密钥交换ECDHE对称加密 AEAD 完整性证书链校验PKITLS 之上可以跑 HTTP→HTTPS、FTP→FTPS、SMTP→STARTTLS——这就是 L6 跟业务解耦的体现。后面你切安全视角TLS 握手、证书、Heartbleed/POODLE 全是这层的戏。3. MIME表示协商的现实例子最早为邮件设计Content-Type: text/plain; charsetus-ascii被 HTTP 全盘继承Content-Type: application/json; charsetutf-8 ← charset 是 L6编码application/json 是 L7语义 Content-Encoding: gzip ← 压缩L6一个 Header 里 L6L7 叠着正好解释为啥 TCP/IP 把这两层合并——现实里表示和语义拆不开。4. ASN.1 BER/DERASN.1 怎么描述数据抽象语法INTEGER { 65535 }BER 怎么编码成字节传输语法变长 tag-length-value 结构DER BER 的一个严格子集证书强制用保证同一数据只有一种编码方便签名校验补充TLS介绍一、TLS 是什么定位 来龙去脉TLSTransport Layer Security传输层安全 在可靠传输TCP之上、应用层HTTP/FTP/SMTP…之下插的一层安全子协议负责把 L7 的明文数据加密 → 完整性保护 → 交给 TCP 发出去对面对等层解密后上交 L7。 OSI 里归L6 表示层加密表示协商是 L6 本职TCP/IP 四层里它算应用层里抠出来的一块因为 TCP/IP 没 L6。版本演进版本年份状态SSL 2.01995Netscape已废弃SSL 3.01996已废弃POODLETLS 1.01999RFC 2246SSL 3.0 的小改已基本淘汰TLS 1.12006RFC 4346淘汰TLS 1.22008RFC 5246当前主力但新系统建议 1.3TLS 1.32018RFC 8446重设计砍掉大量旧特性浏览器/合规里 TLS 1.0/1.1 已经全禁了现在生产看 1.2 1.3。二、TLS 的四个作用1️⃣ 机密性 —— 别人看不懂实现握手阶段协商出会话密钥→ 之后应用数据用对称加密算AES-GCM、ChaCha20-Poly1305为什么不用非对称直接加密数据非对称太慢只用来协商对称密钥后面全走对称TLS 1.2 支持 AES-128-GCM、AES-256-GCM、ChaCha20-Poly1305 等2️⃣ 完整性 —— 数据中途被改能发现实现TLS 1.2 老套件HMAC-SHA256 单独算 MAC拼在密文后TLS 1.2 AEAD 套件 / TLS 1.3 全量AEAD 模式GCM/ChaCha20-Poly1305加密完整性一步出不用单独 MAC3️⃣ 身份认证 —— 你连的确实是 google.com不是伪装的实现X.509 证书 PKI 信任链服务器握手时发证书含公钥 域名 有效期 CA 签名客户端内置 ~100-200 个根 CA 公钥沿根 CA → 中间 CA → 服务器证书验签名可选双向认证客户端也发证书银行/U盾/企业内网场景一般 Web 只验服务器4️⃣ 密钥协商 —— 双方算出同一个会话密钥且不希望服务器私钥泄露就连累历史会话实现密钥交换算法RSATLS 1.2 可选客户端生成 pre-master → 用服务器证书 RSA 公钥加密 → 服务器私钥解。简单但无前向保密DHE / ECDHETLS 1.2 推荐TLS 1.3 强制双方临时 DH 参数交换 → 算共享秘密。服务器长期私钥只用来签名 DH 参数不用来解密私钥日后泄露也破不了历史会话 → 这叫前向保密 PFS三、TLS 协议的内部结构四子协议很多人以为 TLS “握手 加密”其实它内部是四个子协议叠在一起┌─────────────────────────────────────┐ │ 应用数据 (HTTP/FTP/SMTP...) ← L7 │ │ ───────────────────────────────── │ │ TLS 握手协议 (Handshake) │ ← 协商版本/套件/密钥/证书 │ TLS 记录协议 (Record) │ ← 分片(≤16KB)/加密/MAC/组装 │ TLS 变更密码规格 (ChangeCipherSpec) │ ← 从此刻起切新密钥 │ TLS 警报协议 (Alert) │ ← 报错 Warning/Fatal │ ───────────────────────────────── │ │ TCP ← L4 │ └─────────────────────────────────────┘记录协议Record是真正的搬运工L7 数据下来 → 按 ≤16KB 分片 → 压缩TLS 1.3 已砍→ 加密MAC → 前加 5 字节 Record 头类型/版本/长度→ 交 TCP握手协议只在建连阶段跑跑完后就退休后面全是 Record 搬应用数据ChangeCipherSpec告诉对面我这边已经把密钥切过去了下一刀开始加密Alert出错时发比如bad_certificate、handshake_failure、close_notify四、TLS 的几个常见工程扩展纯介绍不深扩展名干什么SNI (Server Name Indication)ClientHello 里明文说我要连 www.google.com——一台服务器挂多个 HTTPS 虚拟主机时必须否则服务器不知道发哪张证书ALPN (Application-Layer Protocol Negotiation)协商TLS 里面跑啥 L7最常见h2vshttp/1.1让服务器不用先解密就知道是不是 HTTP/2OCSP Stapling服务器把我证书没被吊销的证明(OCSP 响应)顺便夹在握手发客户端不用自己再去 CA 查Session ID / Session Ticket会话复用——第二次连不用重新握手Session ID 靠服务端缓存Session Ticket 靠服务端发个加密 ticket 客户端存着重连带 ticket 上来 →1-RTT 甚至 0-RTT
一、L6 表示层是什么目录一、L6 表示层是什么二、L6 的功能和特性三大功能OSI 7498 给的标准定义三个特性三、L6 专业术语 专有名词表 术语表 重点挑讲 4 个1. 抽象语法 vs 传输语法2. TLSL6 的门面担当3. MIME表示协商的现实例子4. ASN.1 BER/DER补充TLS介绍一、TLS 是什么定位 来龙去脉版本演进二、TLS 的四个作用1️⃣ 机密性 —— 别人看不懂2️⃣ 完整性 —— 数据中途被改能发现3️⃣ 身份认证 —— 你连的确实是 google.com不是伪装的4️⃣ 密钥协商 —— 双方算出同一个会话密钥且不希望服务器私钥泄露就连累历史会话三、TLS 协议的内部结构四子协议四、TLS 的几个常见工程扩展纯介绍不深—OSI 第 6 层它解决的核心问题是“发送端和接收端对’数据的样子’理解不一致”——字节序不同、编码不同、加密没商量好L7 直接解析就炸。所以 L6 不关心这坨数据是 GET 还是 POST、是邮件还是网页那是 L7只关心数据在线上长什么样、到了对面能不能原样还原。类比收口一下前三层L4 传输层管送到可靠/不可靠端口寻址L5 会话层管对话怎么组织建/断/续/令牌L6 表示层管数据怎么表示编码/加密/压缩二、L6 的功能和特性三大功能OSI 7498 给的标准定义1. 语法转换Syntax Transformation不同机器字节序大端/小端、字符集ASCII/EBCDIC/UTF-8、数据结构描述方式不一样L6 负责把发送端的抽象数据翻译成线上通用字节流对面 L6 再翻回来。例x86 是小端网络协议全是大端网络字节序所以有了htons/htonl/ntohs/ntohl——这四个函数本质就是 L6 语义。2. 数据加密与解密对 L7 下来的数据做加密对面 L6 解密后再上交 L7。加密/解密动作本身不关心上层是 HTTP 还是 FTP 还是 SMTP——这也是为什么 TLS 被归到 L6它是最纯的 L6 协议。3. 数据压缩与解压减少传输量gzip/deflate/brotli 都属这类。早期 SSL 是先压再加密后来出了 CRIME 攻击TLS 1.3 直接砍掉压缩——所以这功能现在基本只剩应用层自己压HTTPContent-EncodingL6 本身不怎么动了。三个特性特性说明透明性L7 不感知下面有没有加密/转码L6 对 L7 是透明的当然 TLS 例外L7 得配合 ALPN 啥的但理论上透明上下文协商会话建立时 L6 先商量咱俩用啥编码、啥加密套件、啥压缩TLS ClientHello 里的 cipher suites 就是这语义与 L7 强耦合现实里数据表示和数据语义分不开HTTP 既要管 GET 也要管Content-Type所以 TCP/IP 把 L6L7 合并了L6 独立存在的意义主要靠 TLS 撑着三、L6 专业术语 专有名词表 术语表类别术语是否重点一句话核心协议TLS / SSL⭐⭐⭐L6 的门面加密认证完整性HTTPS⭐⭐HTTP(L7) TLS(L6)编码/序列化ASN.1⭐⭐抽象语法定义证书/SNMP 用BER / DER⭐⭐ASN.1 的传输编码DER 是证书用的严格版XDR略Sun RPC 的序列化老字符编码ASCII / EBCDIC / UTF-8 / Unicode略跨机字符表示概念知道就行压缩gzip / deflate / brotli⭐HTTP Content-Encoding 那堆表示协商MIME (Multipurpose Internet Mail Extensions)⭐⭐Content-Type; charset这套最初为邮件设计HTTP 继承概念对抽象语法 vs 传输语法⭐⭐⭐L6 教材最爱考的一对接口概念表示上下文Presentation Context⭐L6 协商这次会话用哪种抽象语法哪种传输语法的统称 重点挑讲 4 个1. 抽象语法 vs 传输语法抽象语法“我要传一个整数 65535 字符串 ‘hello’”——这是语义描述跟字节怎么排无关传输语法按某种规则编码成线上字节比如 ASN.1DERTLS 证书里就是02 03 00 FF FF ...L6 的本分L7 给抽象语法 → L6 转传输语法发出去 → 对面 L6 转回抽象语法 → 交 L7。 映射到现代协议更好懂Protobuf 的.proto文件 抽象语法protobuf wire format 传输语法。gRPC 整套就是 L6 思维只是没单独抽一层。2. TLSL6 的门面担当严格说 OSI 里 L6 应该只加密不关心业务TLS 完美符合协商加密套件AES-256-GCM? ChaCha20?密钥交换ECDHE对称加密 AEAD 完整性证书链校验PKITLS 之上可以跑 HTTP→HTTPS、FTP→FTPS、SMTP→STARTTLS——这就是 L6 跟业务解耦的体现。后面你切安全视角TLS 握手、证书、Heartbleed/POODLE 全是这层的戏。3. MIME表示协商的现实例子最早为邮件设计Content-Type: text/plain; charsetus-ascii被 HTTP 全盘继承Content-Type: application/json; charsetutf-8 ← charset 是 L6编码application/json 是 L7语义 Content-Encoding: gzip ← 压缩L6一个 Header 里 L6L7 叠着正好解释为啥 TCP/IP 把这两层合并——现实里表示和语义拆不开。4. ASN.1 BER/DERASN.1 怎么描述数据抽象语法INTEGER { 65535 }BER 怎么编码成字节传输语法变长 tag-length-value 结构DER BER 的一个严格子集证书强制用保证同一数据只有一种编码方便签名校验补充TLS介绍一、TLS 是什么定位 来龙去脉TLSTransport Layer Security传输层安全 在可靠传输TCP之上、应用层HTTP/FTP/SMTP…之下插的一层安全子协议负责把 L7 的明文数据加密 → 完整性保护 → 交给 TCP 发出去对面对等层解密后上交 L7。 OSI 里归L6 表示层加密表示协商是 L6 本职TCP/IP 四层里它算应用层里抠出来的一块因为 TCP/IP 没 L6。版本演进版本年份状态SSL 2.01995Netscape已废弃SSL 3.01996已废弃POODLETLS 1.01999RFC 2246SSL 3.0 的小改已基本淘汰TLS 1.12006RFC 4346淘汰TLS 1.22008RFC 5246当前主力但新系统建议 1.3TLS 1.32018RFC 8446重设计砍掉大量旧特性浏览器/合规里 TLS 1.0/1.1 已经全禁了现在生产看 1.2 1.3。二、TLS 的四个作用1️⃣ 机密性 —— 别人看不懂实现握手阶段协商出会话密钥→ 之后应用数据用对称加密算AES-GCM、ChaCha20-Poly1305为什么不用非对称直接加密数据非对称太慢只用来协商对称密钥后面全走对称TLS 1.2 支持 AES-128-GCM、AES-256-GCM、ChaCha20-Poly1305 等2️⃣ 完整性 —— 数据中途被改能发现实现TLS 1.2 老套件HMAC-SHA256 单独算 MAC拼在密文后TLS 1.2 AEAD 套件 / TLS 1.3 全量AEAD 模式GCM/ChaCha20-Poly1305加密完整性一步出不用单独 MAC3️⃣ 身份认证 —— 你连的确实是 google.com不是伪装的实现X.509 证书 PKI 信任链服务器握手时发证书含公钥 域名 有效期 CA 签名客户端内置 ~100-200 个根 CA 公钥沿根 CA → 中间 CA → 服务器证书验签名可选双向认证客户端也发证书银行/U盾/企业内网场景一般 Web 只验服务器4️⃣ 密钥协商 —— 双方算出同一个会话密钥且不希望服务器私钥泄露就连累历史会话实现密钥交换算法RSATLS 1.2 可选客户端生成 pre-master → 用服务器证书 RSA 公钥加密 → 服务器私钥解。简单但无前向保密DHE / ECDHETLS 1.2 推荐TLS 1.3 强制双方临时 DH 参数交换 → 算共享秘密。服务器长期私钥只用来签名 DH 参数不用来解密私钥日后泄露也破不了历史会话 → 这叫前向保密 PFS三、TLS 协议的内部结构四子协议很多人以为 TLS “握手 加密”其实它内部是四个子协议叠在一起┌─────────────────────────────────────┐ │ 应用数据 (HTTP/FTP/SMTP...) ← L7 │ │ ───────────────────────────────── │ │ TLS 握手协议 (Handshake) │ ← 协商版本/套件/密钥/证书 │ TLS 记录协议 (Record) │ ← 分片(≤16KB)/加密/MAC/组装 │ TLS 变更密码规格 (ChangeCipherSpec) │ ← 从此刻起切新密钥 │ TLS 警报协议 (Alert) │ ← 报错 Warning/Fatal │ ───────────────────────────────── │ │ TCP ← L4 │ └─────────────────────────────────────┘记录协议Record是真正的搬运工L7 数据下来 → 按 ≤16KB 分片 → 压缩TLS 1.3 已砍→ 加密MAC → 前加 5 字节 Record 头类型/版本/长度→ 交 TCP握手协议只在建连阶段跑跑完后就退休后面全是 Record 搬应用数据ChangeCipherSpec告诉对面我这边已经把密钥切过去了下一刀开始加密Alert出错时发比如bad_certificate、handshake_failure、close_notify四、TLS 的几个常见工程扩展纯介绍不深扩展名干什么SNI (Server Name Indication)ClientHello 里明文说我要连 www.google.com——一台服务器挂多个 HTTPS 虚拟主机时必须否则服务器不知道发哪张证书ALPN (Application-Layer Protocol Negotiation)协商TLS 里面跑啥 L7最常见h2vshttp/1.1让服务器不用先解密就知道是不是 HTTP/2OCSP Stapling服务器把我证书没被吊销的证明(OCSP 响应)顺便夹在握手发客户端不用自己再去 CA 查Session ID / Session Ticket会话复用——第二次连不用重新握手Session ID 靠服务端缓存Session Ticket 靠服务端发个加密 ticket 客户端存着重连带 ticket 上来 →1-RTT 甚至 0-RTT
