从 HTTPS 到 MySQL：会话保持的攻防，与数据库的真面目

我的github：(https://github.com/xcx55/ubuntu-linux-project)
感谢各位大佬参观我的github！！

源笔记：http8（26-9-16）、HTTP9→https（26-9-16）、HTTP10结尾 会话（26-9-16）、mysql1 配置mysql（26-9-14）、mysql是什么/主流mysql/服务器数据库表三者关系（26-9-17）

HTTP 章的最后一天，两块硬骨头一次啃完：HTTPS 为什么安全、登录之后服务器凭什么"记住你"。啃完顺理成章推开下一扇门——表单提交的数据最后去哪了？MySQL。

一、HTTP 的软肋：不安全是全方位的

先立结论：HTTP 比 HTTPS 快，但 HTTPS 安全。而且要补一刀：HTTP 的 POST 方法提交参数和 GET 方法提交参数，都不安全——一个裸奔在 URL 里，一个裸奔在正文里，线路上的中间人看得一清二楚。

还有个阴暗的玩法叫代理：URL 的功能路由花样多，就可以有代理服务——浏览器作为代理，你输入对象、触发搜索服务、传参数，浏览器替你去请求。往坏了用就是木马病毒：HTK 这种工具是劫持了几乎所有进程——木马开启一个代理软件，网络传输的数据就都被劫持了，你发什么它先看什么。

二、HTTPS：加密层加在应用层里

HTTPS 架在整改后的 HTTP 之上——HTTP 协议和 SSL 协议之间做了加密解密的封装：

• 发送方向：在 HTTP 报文交给传输层之前，先完成加密；
• 接收方向：在第一次回调函数之前，将完整报文进行解密——回调拿到的已经是明文，所以应用层代码完全不用改。

一个精妙的问题：为什么不在传输层上、HTTP 变 HTTPS 之前被恶意读取？ 答案不在网络里，在操作系统里：

这时它们在一个进程内——拥有栈、内核栈，其他进程是不能读取的，操作系统给予保护，进程/线程之间相互独立！直到消息从网卡出来，才有机会被截获。

所以加密必须在应用层内部完成：出了网卡的消息必须是密的。这又一次印证了分层思想——安全是跨层需求，但在能被保护的最后一层（应用层）落地。

三、会话保持：HTTP 为什么要"记性"

HTTP 本身是无连接的（只是底层 TCP 的第一层是连接的），每个请求都是新面孔。但现实是：

• 一个站点记不住你，这个站点就很难用；
• 就算登录成功了、3xx 重定向到了首页——后面看视频，**后端蒙蔽了：你是谁？**很多功能都要求登录，而没有登录数据，服务端怎么办？

所以 HTTP 需要会话保持功能。第一版方案：Cookie。

第一版：Cookie——把凭证存在客户端

• 应答里有 Cookie 报头，浏览器把它存进本地客户端文件（或内存），还有过期时间；
• 后面每次发起请求，浏览器主动把 Cookie 数据带上，服务端每次就这样验证你是不是合法用户——需要用户认证的功能就通了；
• Cookie 值本质是名字和密码的映射。

但 Cookie 保存在本地，就是有危险的：一旦有人把你的 Cookie 文件盗走了，就是盗号——伪造报头、直接冒充浏览器，服务端分不出真假。

第二版：Session ID——把账本搬到服务器

改进方案一般叫 session + id：

• 将登录的名称和密码维护在服务器，放在其机器的文件里；
• 服务端只把一个**编号（session id）**返回给客户端放在本地——客户端丢的不再是密码，而是一张"取件码"；
• 就算 id 被截获，账本（用户名密码）还在服务端手里。

但 id 还是没有彻底解决安全问题，于是服务端再加一道：IP 相较于之前发生了改变，就拦截这次 Cookie 访问，发起重新登录的 HTML 请求——凭证+环境双验证。

这轮攻防的启示：客户端持有的秘密越少、越廉价，系统越安全——从"存密码"到"存编号"再到"编号绑定环境"，安全性是一步步把秘密往服务端收的过程。

四、HTTP 章收官：回顾一下整条链

从手搓 len\r\n 协议出发，一路走过：URL 全网唯一文件路径 → 请求/应答报文 → 状态码驱动的浏览器行为 → GET/POST 表单传参 → 资源路由和功能路由 → HTTPS 加密 → Cookie/Session 会话保持。应用层的三大件也定型了：Request、Response、Protocol 三类——序列化和反序列化是为了去语言化、更是为了拓展和屏蔽差异（把所有语言统一转成一个字符串），解包固定三层，这样解耦写法才优秀。

五、推开 MySQL 的门：数据库的真面目

表单提交的数据、session 文件里的账本——总要有个地方放。文件能放，为什么还要数据库？

笔记里的回答很直白：从用户角度，文件不方便。不方便在哪？继续往下拆。

MySQL 是一种网络服务

• MySQL 实际上是一种网络服务，本质是基于 C（mysql）/ S（mysqld）的结构——客户端叫 mysql，服务端叫 mysqld，带 d 的就是守护进程；
• 安装之初只支持一个超级账号——root 管理员，先保证 root 能登录，再依据 root 批量创建管理员和普通用户；
• 数据库是操作系统的一部分：默认只能超级管理员安装，装完只有超管能进，之后才有账号管理，普通用户才能使用。

数据库本质还是文件

最锋利的一句话来了：

数据库本质还是操作文件，本质还是文件——建立数据库就是建立文件夹，建立表就是建立文件。

只是这些文件不由程序员直接操作，而是程序员通过数据库服务来操作——一个程序员专门写好的服务，就叫数据库。

所以：DB（数据库）= 目录，表 = 文件；一般一个应用建立一个数据库。

服务器、数据库、表：三者关系

• 服务器（mysqld）：跑在网络上的守护进程，管理下面所有的数据库；
• 数据库（DB）：一个目录，一个应用的账本总量；
• 表：目录下的文件，装着具体数据。

数据库呈现给用户的是行列式结构——真实的文件数据并不是按行列式储存的，但用户角度就是行列式的增删查改。这就是数据库的核心价值：文件在磁盘上怎么躺是它的事，你永远在操作一张规整的二维表。

架构上也延续了熟悉的味道：上三层都是用户层，下面是操作系统层；存储引擎的插件就类似一个类——new 出来用，按需换（InnoDB、MyISAM 各有脾气）。而和这个服务打交道靠 SQL 语句——按功能分类的专用语言。

MySQL 章到此起步，和 HTTP 章的衔接天衣无缝：服务函数收参数 → 分割 → 接入数据库，网页的"动"，最终都动在数据库的表里。

总结

• HTTP 快但不安全，GET/POST 传参都不安全；代理能帮你也能劫持你（木马就是进程级劫持+代理）；
• HTTPS = HTTP + SSL：出网卡前必加密；应用层进程内受操作系统进程隔离保护——加密在"最后一道受保护的层"落地；
• 会话保持两代方案：Cookie（凭证在客户端，可被盗号）→ Session ID（账本在服务端，id+IP 环境双验证）；秘密越往服务端收越安全；
• MySQL = mysqld 守护进程 + mysql 客户端的 C/S 网络服务；root 先行，账号再管；
• 数据库本质是文件：DB=目录、表=文件，只是操作权交给了专门写的服务；
• 用户看到的是行列式的抽象，真实储存它自己安排；上三层用户层、下两层操作系统层，插件=类。

下一篇进入 SQL 语句：那张规整的二维表，怎么增删查改。