HTTP和HTTPS终极解析：从明文到加密，web安全的核心防线
这篇博客打算详细介绍http协议，我会把自己学习过程中遇到的难点都讲给大家~~~
用红色标注的是我认为最最最最最最最最最最最最最最最重要的
目录
302 Found / 302 Move Temporarily：临时串门
5xx：服务器错误 (这是我们需要关注的地方，这个是直接是我们代码有问题)
500 Internal Server Error：服务器崩溃了
· 含义：服务器暂时无法处理请求· 场景：服务器维护中，流量过大
****那我用一段HTTPS的进化史一场攻防大战，来将这个https的安全来讲清楚吧~~~
问题：这里我在学的时候一开始没有明白为什么后面还继续要用对称密钥，这玩意不是容易被窃听吗？
重点：那么我们就要明白证书是用来保证非对称密钥的公钥是正确的，没有被黑客替换！！
Q4:如果黑客自己伪造了一份“假证书”，并且在证书里填了自己的公钥（不是真实服务器的公钥），客户端能识别出这是假证书吗？为什么？
HTTP超详细讲解：从入门到精通
1. HTTP是什么？
想象一下，你要在餐厅点餐：
你："服务员，来份炸鸡！"（请求），服务员："好的，马上来！"（响应），http协议就是这种一问一答的模式，客户端发出一个请求，然后服务器回一个响应。
幽默理解：
"HTTP就像互联网世界的通用语——没有它，浏览器和服务器就是鸡同鸭讲！"
2. 理解"应用层协议"—— 通信的规则手册
们已经学过 TCP/IP , 已经知道⽬前数据能从客⼾端进程经过路径选择跨⽹络传送到服务器端进程
[ IP+Port ].可是，仅仅把数据从A点传送到B点就完了吗？这就好⽐，在淘宝上买了⼀部⼿机，卖家[ 客⼾端 ]把⼿机通过顺丰[ 传送+路径选择 ] 送到买家 [ 服务
器 ] ⼿⾥就完了吗？当然不是，买家还要使⽤这款产品，还要在使⽤之后，给卖家打分评论。
所以，我们把数据从A端传送到B端， TCP/IP 解决的是顺丰的功能，⽽两端还要对数据进⾏加⼯处理，或者使⽤，所以我们还需要⼀层协议，不关⼼通信细节，关⼼应⽤细节！这层协议叫做应⽤层协议。⽽应⽤是有不同的场景的，所以应⽤层协议是有不同种类的，其中经典协议之⼀的HTTP就是其中的佼佼者.
3. HTTP工作过程
你(客户端) → 请求 → 服务器
你(客户端) ← 响应 ← 服务器
详细步骤：
1. 建立连接：浏览器向服务器"打招呼"
2. 发送请求：浏览器说出想要什么
3. 处理请求：服务器思考如何回应
4. 返回响应：服务器给出答案
5. 关闭连接：对话结束
HTTP协议格式
抓包工具：网络世界的"窃听器"，我们用到的以 Fiddler 为例. (下载地址: https://www.telerik.com/fiddler/)
抓包工具就像给网络通话装了个录音机，可以听到浏览器和服务器说的每一句话。
原理：在网络传输的会有路由器等各种设备，如果黑客入清了相关设备，装上抓包工具就可以检测我们的一言一行。
使用fiddler的时候我们需要下载证书
在tools-options-HTTPS一栏中将下面全部对号，然后弹出一个框，点击yes下载证书。
HTTP请求格式
GET http://cdn-file.apkevery.com/cms/project_66/cfg_center/mod_list.js HTTP/1.1
Host: cdn-file.apkevery.com
Accept: */*
Accept-Encoding: gzip
Connection: Keep-Alive[可选的身体部分]
三个重要部分：
⾸⾏: [⽅法] + [url] + [版本]
• Header: 请求的属性, 冒号分割的键值对;每组属性之间使⽤\n分隔;遇到空⾏表⽰Header部分结束
• Body: 空⾏后⾯的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有⼀个
Content-Length属性来标识Body的⻓度;
HTTP响应格式
HTTP/1.1 200 OK
Last-Modified: Wed, 16 Oct 2024 06:33:18 GMT
Etag: "28A51ED17321F5D32BA45D695E4CD42C"
Server: AliyunOSS
Content-Type: application/javascript
x-oss-request-id: 67F87FAF9D4E6438320B62DB
x-oss-object-type: Normal
x-oss-hash-crc64ecma: 15516281555955617374
x-oss-storage-class: Standard
Content-MD5: KKUe0XMh9dMrpF1pXkzULA==
x-oss-server-time: 2
Content-Length: 29
Accept-Ranges: bytes
Connection: keep-alive
Date: Sat, 25 Oct 2025 11:17:24 GMT
Content-Disposition: inline
Access-Control-Allow-Origin: *
EO-LOG-UUID: 15065976731676273367
EO-Cache-Status: HIT{
"t": 15,
"t2": 10
}
也是三部分：
⾸⾏: [版本号] + [状态码] + [状态码解释]
• Header: 请求的属性, 冒号分割的键值对;每组属性之间使⽤\n分隔;遇到空⾏表⽰Header部分结束
• Body: 空⾏后⾯的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有⼀个
Content-Length属性来标识Body的⻓度; 如果服务器返回了⼀个html⻚⾯, 那么html⻚⾯内容就是
在body中.
认识 URL—— 互联网的"地址系统"
URL基本格式：精确的"门牌号"
https://127.0.0.1:8080/path/to/page?name=value#section
· 协议：https:// （用什么方式访问）
· 域名：127.0.0.1（去哪家店）
· 端口：:8080 （走哪个门）
· 路径：/path/to/page （具体位置）
· 查询参数：?name=value （额外要求）
· 锚点：#section （页面内的具体位置）
关于 URL encode（进行转义）
像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现.
⽐如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进⾏转义.
⼀个中⽂字符由 UTF-8 或者 GBK 这样的编码⽅式构成, 虽然在 URL 中没有特殊含义, 但是仍然需要进⾏转义. 否则浏览器可能把 UTF-8/GBK 编码中的某个字节当做 URL 中的特殊符号.
转义的规则如下: 将需要转码的字符转为16进制，然后从右到左，取4位(不⾜4位直接处理)，每2位做⼀位，前⾯加上%，编码成%XY格式，"+" 被转义成了 "%2B"
urldecode就是urlencode的逆过程;
简单来说在查询参数的时候使用汉字等，服务器无法识别，这是一个很恐怖的事情，假如在客户端都是以汉字传入的时候，由于服务器识别不了，导致相关页面广告量点击下降，造成损失。
HTTP方法
GET方法：我要"查看"
特点：· 从服务器获取数据、数据在URL中可见、可以被缓存、有长度限制
使用场景：浏览网页、 搜索内容、 点击链接
比喻：
"GET就像在餐厅看菜单——只查看，不点菜"
POST方法：我要"提交"
特点：向服务器发送数据、 数据在请求体中，不可见、不会被缓存、 不会被缓存、无长度限制
使用场景：用户登录、发表评论、上传文件
比喻：
"POST就像填写订单并提交——把信息打包发给服务器"
其他方法：
· PUT：更新整个资源
· PATCH：更新部分资源
· DELETE：删除资源
· HEAD：只要响应头，不要身体
（说白了剩下的方法基本用不到）
请求头(Header)—— 请求的"附加说明"
Host：你要去哪家店
告诉服务器你要访问哪个网站（一个服务器可能托管多个网站）
Content-Length：你的"包裹"有多大
告诉服务器你发送的数据有多少字节
Content-Type：你的"包裹"里是什么
· text/html：HTML网页
· application/json：JSON数据
· multipart/form-data：表单数据
User-Agent(UA)：你的"身份证"
告诉服务器你用的什么浏览器、什么操作系统
Referer：你从哪来
告诉服务器你是从哪个页面跳转过来的
Cookie：你的"会员卡"
存储一些识别信息，让服务器知道你是谁，当服务器第一次接受到
核心官方定义要点（符合 RFC 6265 标准）：
1. 本质：键值对形式的文本数据（键=值，多个以分号分隔），大小通常限制在 4KB 以内。2. 传输机制：首次请求后，服务器通过 HTTP 响应头 Set-Cookie 发送 Cookie；后续客户端向该服务器发请求时，自动通过请求头 Cookie 携带已存储的对应数据。
3. 存储位置：存储在客户端（浏览器本地文件/内存），具体位置由用户代理管理。
4. 核心用途：弥补 HTTP 协议“无状态”的缺陷，实现状态保持（如登录认证、会话标识、偏好设置、购物车等）。
5. 关键属性（控制行为）：
- Expires/Max-Age ：指定过期时间，未设置则为会话级 Cookie（关闭浏览器即删除）。
- Domain/Path ：限制 Cookie 仅对特定域名、路径的请求生效。
- HttpOnly ：禁止客户端脚本（如 JS）访问，防止 XSS 攻击窃取 Cookie。
- Secure ：仅在 HTTPS 协议下传输，避免明文泄露。
- SameSite ：限制跨域请求时 Cookie 的携带，防范 CSRF 攻击（取值：Strict/Lax/Normal）。
官方定义：Session（会话）
Session 是服务器端为维护客户端与服务器的状态关联而创建的临时存储空间，用于保存单个客户端的会话数据（如登录状态、用户偏好、交互上下文等）。
- 本质：服务器内存/数据库中的“会话对象”，与特定客户端唯一绑定，生命周期通常为“会话存续期”（客户端长时间无操作会自动过期）。
- 核心作用：弥补 HTTP 无状态特性，存储客户端敏感/详细信息（避免这些数据暴露在客户端）。
- 依赖关系：Session 本身无法直接识别客户端，必须通过 Session ID 与客户端建立关联。
官方定义：Session ID（会话标识）
Session ID 是服务器生成的唯一随机字符串（如 3F2504E0-4F89-11D3-9A0C-0305E82C3301 ），是关联客户端 Cookie 与服务器 Session 的核心身份标识。
- 生成与传输：服务器创建 Session 时同步生成 Session ID，通过 Set-Cookie 响应头将其存入客户端 Cookie；后续客户端请求时，通过 Cookie 头携带该 ID 回传服务器。
- 核心作用：作为“索引键”，让服务器能从众多 Session 中精准找到对应客户端的会话数据，实现“身份识别”。
- 安全性：Session ID 具有唯一性和随机性，可防止伪造身份（配合 HttpOnly Secure 等 Cookie 属性进一步提升安全性）。
那么我来用我的理解来说一下cookie，session以及session id（官方解释也要理解）
Cookie = 病人手里的就诊卡：就诊卡上只印着核心标识——你的「就诊卡号」（对应 Session ID），还有就诊日期、科室这些轻量信息，全程由你（客户端）自己保管（不会显示所有信息，重量信息都在医院服务器中储存，医生）
- Session ID = 就诊卡号：是就诊卡上的唯一编号（比如 NO.20240510008 ），是你在医院的“身份代号”，也是连接你和医院系统的关键。
- Session = 医院病历系统里的你的病历档案：档案里存着你的详细信息——病史、检查报告、医嘱、缴费记录（对应登录状态、用户信息等敏感数据），全程存在医院（服务器）里，不会让你自己带，（每次病人看一次病就会产生一次新的会话）
完整流程类比：
1. 你第一次去医院（首次访问服务器）：挂号后，医院（服务器）给你办一张就诊卡（Cookie），卡上印着专属就诊卡号（Session ID），同时在病历系统里建一份你的电子病历（Session）。
2. 你去诊室看病（后续发请求）：每次去不同科室，都要出示就诊卡（Cookie），医生刷一下卡号（Session ID），就能从系统里调出你的病历（Session），不用再重新说一遍病史。
3. 看完病离院（关闭浏览器/会话过期）：你带走就诊卡（Cookie 还存在客户端），但病历（Session）还在医院；下次再来，出示同一张卡（带同一个 Session ID），医生还能找到你的老病历。
HTTP状态码
服务器不会说话，但它会用状态码这种特殊的方式来告诉你它的状态和处理结果。
状态码分为五类，每个类都有自己的独特含义（我们以后发现bug的重要依据）：
1xx：我在处理中...（信息性状态码，不怎么用到）
2xx：成功
200 OK：完美！（最爱的数字）
· 含义：请求成功，一切正常
· 场景：网页正常加载，数据成功返回
201 Created：造出来了！
· 含义：创建资源成功
· 场景：注册新用户、发布新文章
3xx：重定向家族
301 Moved Permanently：永久搬家
· 含义：资源已永久移动到新地址
· 浏览器行为：自动跳转到新地址，并记住这个跳转
生动比喻：
"301就像朋友告诉你：'我换房子了，这是新地址，以后都来这找我！'"
302 Found / 302 Move Temporarily：临时串门
· 含义：资源临时在另一个位置
· 浏览器行为：自动跳转，但下次还访问原地址
"302就像朋友说：'我在咖啡店聊天呢，过来找我吧！'——只是临时位置"
301 vs 302 区别：
· 301：永久重定向，像"公司搬家"
· 302：临时重定向，像"同事临时去会议室开会"
4xx：客户端错误
400 Bad Request：你说啥？
· 含义：请求语法错误，服务器看不懂
· 场景：请求格式错误，参数不对
403 Forbidden：禁止入内！
· 含义：服务器理解请求，但拒绝执行
· 场景：没有权限访问某个资源
生动比喻：
"403就像你想进公司机房，保安说：'抱歉，这里需要特殊权限！'"
404 Not Found：查无此人（老司机懂得都懂）
· 含义：请求的资源不存在
· 场景：链接失效，页面被删除
405 Method Not Allowed：此路不通
· 含义：请求方法不被允许
· 场景：用GET请求需要POST的接口
5xx：服务器错误 (这是我们需要关注的地方，这个是直接是我们代码有问题)
500 Internal Server Error：服务器崩溃了
· 含义：服务器内部错误
· 场景：代码bug，数据库连接失败
502 Bad Gateway：传话员失联了
· 含义：网关错误
· 场景：负载均衡器连接后端服务失败
503 Service Unavailable：服务正忙
· 含义：服务器暂时无法处理请求
· 场景：服务器维护中，流量过大
504 Gateway Timeout：等太久了
· 含义：网关超时
· 场景：后端服务响应太慢
状态码小结：快速记忆口诀
200成功，301永重，302临重
400客户端语法错，403权限不够
404找不到，405方法不对
500服务器崩，502网关坏
503服务忙，504等超时
HTTPS超详细讲解：从入门到精通
HTTPS是什么？
想象一下，我们进行页面登陆的时候需要提交密码等重要信息，这时候黑客黑入路由器、交换机等设备，随便搞个抓包设备，你的所有交互信息不就都被泄露了。那么我们就得想把办法把我们的数据保护起来，加密！！！！！！！
技术定义：HTTPS = HTTP + SSL/TLS加密层
幽默理解：
"HTTPS就像给HTTP戴上了墨镜、假胡子，还配了保镖——谁都认不出它原来长啥样！"
为什么需要HTTPS？
1.实中的"偷窥者"太多
2.防止运营商劫持，比如百度的广告费在记录的时候，客户每点击一次就能获得广告费，这个广告费是很贵的~~~每点击一次就能获利大几十块钱尤其向医院的广告
HTTP的三大危险：
1. 窃听风险：像在公交车上大声说隐私
2. 篡改风险：像有人偷偷改了你写的信
3. 冒充风险：像骗子假装成你的银行客服
真实案例：
"你连咖啡馆WiFi网购，隔壁黑客轻松看到你的密码——这就是为什么需要HTTPS！"公共网络千万别连，万能钥匙也是这个道理。
加密基础课：从"凯撒密码"到现代加密
对称加密：同一把钥匙
工作原理：
明文"hello" + 密钥 → 加密 → 密文"ifmmp"
密文"ifmmp" + 密钥 → 解密 → 明文"hello"
常用算法：AES、DES、3DES
优点：速度快，适合大量数据加密
缺点：密钥分发问题——怎么安全地把密钥给对方？如果直接把钥匙给服务器，黑客也是可以劫持钥匙的并没有解决实际问题~~~~~
生动比喻：
"对称加密就像你和朋友共用一把钥匙——但怎么把钥匙安全寄给对方而不被小偷拿到？"
非对称加密：公钥和私钥的完美搭档
工作原理：
· 公钥：公开的，用于加密数据
· 私钥：保密的，用于解密数据
你用朋友的公钥加密："我喜欢你" → 密文
只有朋友的私钥能解密：密文 → "我喜欢你"
常用算法：RSA、ECC
优点：解决密钥分发问题
缺点：速度慢，计算复杂
幽默理解：
"非对称加密就像魔法信箱——任何人都能往里投信(公钥加密)，但只有主人能用魔法钥匙(私钥)打开！"
****那我用一段HTTPS的进化史一场攻防大战，来将这个https的安全来讲清楚吧~~~
第一代：纯对称加密（想法很美好）
你生成对称密钥 → 用HTTP发给服务器 → 之后用这个密钥加密通信
问题：第一次发送密钥时就被中间人看到了！
失败原因：
你把钥匙都放在一起了，人家早就记下来了！！！！！
第二代：非对称加密（进步但不够）
理想解决方式
服务器会生成一个公钥和私钥，他将私钥留下来公钥公开，然后客户端收到公钥，用公钥加密被对称密钥加密的数据，这时候黑客由于没有私钥无法获得对称密钥，就无法获得数据。（非对称密钥作用是保护对称密钥，对称密钥用到的算法少，传送速度快，我们在之后的对话就只用对称密钥）
问题：这里我在学的时候一开始没有明白为什么后面还继续要用对称密钥，这玩意不是容易被窃听吗？
其实我们引入非对称密钥的初心就是把对称密钥安全送给服务器，服务器收到这个公钥，就会保存下来，这时候黑客是获取不到对称公钥的，这个对话就可以脱离非对称密钥，一直以这种高效的对称密钥来进行数据交互。
服务器给你公钥 → 你用公钥加密对称密钥 → 发给服务器 → 服务器用私钥解密
问题：中间人可能伪装成服务器给你假公钥！
攻击场景：中间人攻击
服务器收到公钥时候，自己生成一套私钥公钥，他把自己的公钥给客户端，客户端用公钥进行加密，黑客又用自己的私钥解锁，获取数据之后又用服务器的公钥加密，再给服务器，而我们的客户端和服务器都被蒙在鼓里！！！！！
第三代：数字证书登场（全方位终极解决方案）
认证过程如何保证安全
服务器会把自己的核心信息（比如网站域名、服务器公钥、有效期等）整理成“申请材料”，提交给权威的证书机构（CA，比如Let's Encrypt、Verisign）。CA就会生成一把私钥，
1. 计算摘要：对证书内容做Hash，得到"指纹"
2. 加密摘要：用CA的私钥加密这个"指纹"
3. 附加签名：把加密后的"指纹"放在证书里。
客户端和服务器用到证书的过程：
1. 计算摘要：对收到的证书内容做同样的Hash
2. 解密签名：用CA的公钥解密数字签名，得到原始摘要
3. 比对：两个摘要一致就通过！
服务器给你"证书"（含公钥+CA签名） → 你验证证书真伪 → 再用里面的公钥加密
数字证书：互联网的"身份证系统"
就像你的身份证：
· 持有者信息：服务器域名、公司名称等
· 公钥：服务器的加密公钥
· 颁发机构：证书是谁签发的
· 数字签名：防伪标识
HTTPS完整握手过程：一场精心编排的加密舞蹈
TLS握手详细步骤：
第一步：Client Hello（客户端打招呼）
```
浏览器："你好！我是Chrome，支持这些加密套件：AES、RSA..."
```第二步：Server Hello（服务器回应）
```
服务器："好的！我们用AES_256_GCM和RSA，这是我的证书"
```第三步：证书验证（浏览器检查身份证）
```
浏览器："让我看看这个证书...嗯，CA是可信的，签名有效，域名匹配！"
```第四步：密钥交换（生成会话密钥）
```
浏览器：生成随机数 → 用证书里的公钥加密 → 发送给服务器
服务器：用私钥解密 → 得到相同的随机数
```第五步：切换加密通道
```
双方："好了，现在开始用对称加密通话！"
```
重点：那么我们就要明白证书是用来保证非对称密钥的公钥是正确的，没有被黑客替换！！
HTTPS常见问题深度解析
Q1：为什么中间人不能篡改证书？
假设攻击场景：
中间人拿到真证书 → 修改里面的公钥 → 重新生成签名
为什么失败：就算修改了公钥，客户端重新计算的hash值不一样就会报错
🚫 结果：
"浏览器：警报！证书签名验证失败！这个网站可能不安全！"
Q2：中间人能不能整个掉包证书？
攻击尝试：
你访问淘宝 → 中间人给你百度的证书
防御机制：证书里明确写着域名"taobao.com"
浏览器发现域名不匹配，立即拒绝浏览器反应：
"你要访问的是淘宝，但这个证书是给百度的——有诈！"
Q3：为什么摘要要先Hash再加密？
性能考虑：
· 非对称加密很慢，只加密固定长度的摘要(256位)很快
· 如果加密整个证书内容(可能几KB)，速度会慢很多安全考虑： Hash函数保证：任何微小改动→ 完全不同的摘要
Q4:如果黑客自己伪造了一份“假证书”，并且在证书里填了自己的公钥（不是真实服务器的公钥），客户端能识别出这是假证书吗？为什么？
第一步：黑客的假证书没有“合法签名”
黑客能仿造证书的“外壳”（填自己的公钥、仿冒域名），但他没有CA的私钥，根本无法生成“CA私钥签名的数字签名”——客户端拿到证书后，用内置的CA公钥验证时，会发现证书里要么没有有效签名，要么签名是黑客乱造的、根本解不开，直接第一步就判定无效。退一万步来说：就算黑客硬凑了个“假签名”，也过不了哈希对比
假设黑客模仿签名格式造了个假签名，客户端用CA公钥解密后，得到的“哈希值”和假证书里（黑客填的自己公钥等信息）重新计算的“新哈希值”肯定对不上——毕竟签名不是基于真实信息、用CA私钥生成的，一对比就露馅，客户端照样会报错。
HTTPS完整数据流
```
[你的浏览器]
→ TLS握手（非对称加密）
→ 协商出对称密钥
→ HTTP数据（对称加密）
→ [服务器]
```实际数据包：
```
[加密的HTTP请求]
GET /secure-data HTTP/1.1
Host: example.com
...（所有内容都是密文）...
```---
HTTPS总结
核心优势：
1. 保密性：数据加密，防止窃听
2. 完整性：防篡改，数据完整到达
3. 身份验证：确保你连接的是真正的服务器技术要点：
· 混合加密：非对称加密交换密钥 + 对称加密传输数据
· 数字证书：解决公钥信任问题
· 数字签名：防篡改的终极武器现实意义：
· 保护密码、信用卡号等敏感信息
· 防止中间人攻击
· SEO排名提升（Google优先展示HTTPS网站）
· 现代浏览器的强制要求
不过呢，黑t客的手段太多了，这个证书机制只是解决了中间人等部分问题~~~~~
现在我们已经完整覆盖了从HTTP基础到HTTPS加密的整个知识体系！希望大家有收获~~~~~~~~~~
助力广东及东莞地区开发者，代码托管、在线学习与竞赛、技术交流与分享、资源共享、职业发展，成为松山湖开发者首选的工作与学习平台
更多推荐
72
0- 0
已为社区贡献1条内容
所有评论(0)