目录
1.前言
2.正文
2.1状态码
2.2HTTP与HTTPS的关系
2.3SSL协议
2.3.1对称加密
2.3.2非对称加密
2.3.3中间人攻击
2.3.4校验机制
2.3.4.1证书
2.3.4.2数字签名
1. 数字签名的生成过程
2. 数字签名的验证过程
2.4TLS协议（握手过程）
3.小结
1.前言
哈喽大家好吖，今天继续来给大家网络原理相关方面的讲解，主要内容包括状态码以及HTTPS中加密的全过程，让我们开始吧。
2.正文
2.1状态码
想必大家都遇到过这个画面：
这个耳熟能详的“404”，就是状态码啦。
状态码（HTTP与HTTPS互通）是服务器与客户端通信的“语言”，用3位数字直观反馈请求结果。它不仅是开发调试的核心工具，也是优化用户体验和排查问题的关键线索。
HTTP状态码
https://baike.baidu.com/item/http%e7%8a%b6%e6%80%81%e7%a0%81/5053660
HTTP状态码按首位数字分为5类：
类别 范围 含义 核心逻辑 1xx 100-199 信息性状态 请求已被接收，需客户端继续操作 2xx 200-299 成功响应 请求被正确处理并返回预期结果 3xx 300-399 重定向 资源位置变化，需客户端跳转 4xx 400-499 客户端错误 请求语法错误或权限不足 5xx 500-599 服务器错误 服务器无法完成合法请求
在我前面SpringMVC的博文中，状态码为我们的调试工作发挥了举足轻重的作用，下面我们介绍几个比较重要的状态码。
2xx：成功响应：
200 OK
默认成功状态，适用于GET、POST等请求。
常见误区：
POST请求成功后，部分开发者误用200而非201（资源已创建）。
删除操作成功后，建议返回204（无内容）而非200。
201 Created
场景：资源创建成功（如提交表单生成新订单）。
响应头要求：必须包含Location字段指向新资源地址。204 No Content
场景：请求成功但无需返回内容（如删除资源、提交无返回的表单）。
技术细节：响应体必须为空，浏览器不会刷新页面。
4xx：客户端错误：
400 Bad Request
通用错误：请求语法错误（如JSON格式错误、缺少必填参数）。
开发技巧：后端应返回具体错误信息（如{ "error": "Invalid email format" }）。401 Unauthorized
未认证：需身份验证（如未登录用户访问个人中心）。
响应头要求：必须包含WWW-Authenticate字段定义认证方式。403 Forbidden
无权限：身份已认证，但无权访问资源（如普通用户访问管理员页面）。
与401的区别：401是“未证明身份”，403是“身份已知但权限不足”。404 Not Found
资源不存在：URL路径错误或资源已被删除。
SEO影响：过多404错误会降低网站排名，建议配置自定义404页面引导用户。429 Too Many Requests
限流防护：客户端请求频率过高（如API防刷机制）。
响应头要求：应包含Retry-After告知重试时间。
5xx：服务器错误：
500 Internal Server Error
通用服务端错误：代码异常（如未捕获的Exception、数据库连接失败）。
开发建议：记录详细日志（如错误堆栈、请求参数），避免直接返回原始错误给客户端。502 Bad Gateway
网关错误：代理服务器（如Nginx）无法从上游服务器（如Node.js）获取响应。
常见原因：上游服务崩溃、防火墙拦截、请求超时。503 Service Unavailable
服务不可用：服务器临时过载或维护（如电商大促时流量激增）。
优化方案：返回Retry-After头，配合负载均衡和熔断机制。504 Gateway Timeout
网关超时：代理服务器等待上游响应超时。
排查方向：检查后端服务性能、数据库查询效率、网络延迟。
2.2HTTP与HTTPS的关系
通俗理解：
HTTP（HyperText Transfer Protocol）：
一种明文传输协议，数据在客户端与服务器之间以未加密形式传输，如同寄送明信片，内容对所有人可见。
HTTPS（HTTP Secure）：
HTTP的安全升级版，通过 SSL/TLS协议 对传输内容加密，如同将明信片装入防拆封的保险箱。
横向对比HTTP与HTTPS协议：
1)数据传输安全性:
- HTTP:数据以明文传输，容易被窃听、篡改。
- HTTPS:通过 SSL/TLS 协议对数据进行加密传输，提供数据机密性和完整性保障。
2)端口号:
- HTTP:默认使用端口 80。
- HTTPS:默认使用端口 443。
3)性能:
- HTTP:无加密过程，连接建立速度稍快。
- HTTPS:基于 HTTP上又加了SSL(Secure Sockets Layer)或TLS(Transport Layer Security)协议来实现的加密传输,加解密过程增加了计算开销，握手时间较长，但现代硬件和协议优化已使性能差距减小。
下文我们就要展开本文的重中之重，加密的全过程了。
2.3SSL协议
2.3.1对称加密
定义：
对称加密是一种加密方式，加密和解密使用同一个密钥。就像用同一把钥匙锁门和开门，只有持有钥匙的人才能操作。
具体步骤：
- 客户端与服务器通过TLS握手协商出一个会话密钥（Session Key）。
- 双方使用该密钥对HTTP报文进行对称加密传输。
- 会话结束后密钥销毁，下次连接生成新密钥。
对称加密效率较高，但相反的安全性不足：
2.3.2非对称加密
定义：
非对称加密使用一对数学关联的密钥：
公钥（Public Key）：公开给所有人，用于加密数据（如同信箱的投递口）
私钥（Private Key）：严格保密，用于解密数据（如同信箱的专属钥匙）
核心特性：
公钥加密 → 私钥解密：任何人都能用公钥加密数据，但只有私钥持有者能解密。
私钥签名 → 公钥验签：私钥可生成数字签名，公钥可验证签名真实性。
对称加密，成本是比较高的，不适合加密大量的数据。大量的业务数据仍然通过对称密钥来加密
对称密钥，如果数据量小则通过非对称加密的方式来传输 。
当前的场景有三个密钥：
- 客户端生成的对称密钥。
- 服务器生成的公钥，可以给所有设备告知。
- 服务器生成的私钥，只有自己知道 。
上述这样的流程存在重大安全隐患，黑客可以通过特殊手段，来获取到对称密钥~~ 破坏后续传输的安全性~那就是中间人攻击 。
2.3.3中间人攻击
定义：
中间人攻击（Man-in-the-Middle Attack, MITM）指攻击者秘密介入通信双方之间，窃听、拦截甚至篡改数据，而通信双方对此毫无察觉。
核心原理：
伪装身份：攻击者伪造通信一方的身份（如伪装成服务器或路由器）。
劫持通信：将双方的流量引导至攻击者控制的节点。
操纵数据：解密、查看或修改数据后转发给真实接收方。
通俗理解：
正常通信：A → 快递员 → B
中间人攻击：A → 伪装成快递员的黑客 → B
虽然服务器私钥并没有被黑客获取，但请求与相应都被黑客一览无余，所以为了安全，引入了一些校验机制，其中包括证书与数字签名。
2.3.4校验机制
在HTTPS通信中，校验机制需解决两个核心问题：
身份真实性：确保通信的服务器是合法的（防止中间人伪造）。
数据完整性：确保传输的证书和数据未被篡改。
解决方案：
证书 → 证明服务器身份
数字签名 → 验证证书的合法性
2.3.4.1证书
一个标准的证书包含以下关键信息：
| 字段 | 作用 |
|---|---|
| Subject（主体） | 证书持有者的信息（如域名、组织名称） |
| Public Key | 服务器的公钥（用于加密数据或验证签名） |
| Issuer（颁发者） | 签发证书的权威机构（CA，如Let's Encrypt、DigiCert） |
| 有效期 | 证书的有效起止时间 |
证书颁发流程：
生成密钥对：服务器生成公钥和私钥。
CSR（证书签名请求）：服务器向CA提交包含公钥、域名等信息的CSR文件。
CA验证身份：CA通过DNS记录、文件验证或邮件验证确认申请者对域名的控制权。
签发证书：CA用私钥对证书内容签名，生成最终证书。
先讲解完证书的概念，到下文数字签名介绍完后会讲解客户端拿到证书和数字签名会做些什么
2.3.4.2数字签名
数字签名，本质上是一个校验和。
1. 数字签名的生成过程
计算哈希值：对证书内容（除签名外）使用哈希算法生成摘要。
私钥加密哈希值：CA用私钥对哈希值加密，生成数字签名。
2. 数字签名的验证过程
解密签名：浏览器用CA的公钥解密签名，得到哈希值H1。
重新计算哈希值：对收到的证书内容计算哈希值H2。
比对哈希值：若H1=H2，则证书未被篡改；否则判定为伪造证书。
如果校验和一样，则说明收到的数据是原始数据。
验证逻辑：
只有CA的私钥能生成合法签名 → 签名合法则证书可信。
哈希值匹配 → 证书内容未被篡改。
客户端如何确保拿到的 pub2是公证机构的 pub2，而不是黑客伪造的 pub2 呢？？
pub2就不是通过网络传输的，而是操作系统中内置的~(安装好系统,系统就内置了一系列知名公正机构的公钥)只要安装正版系统，不是黑客搞的盗版系统就可以信任 pub2 是正确合法的~
如果黑客想要直接修改证书中的公钥为自己的公钥，此时就会导致客户端计算的校验和和解密出来的原始校验和就对不上。
此时客户端就会报错，浏览器就会弹出一个红色的页面，告诉你该网站不安全，是否要继续访问。
2.4TLS协议（握手过程）
概念
TLS（Transport Layer Security）是SSL的继任者，用于在互联网上建立加密通信通道，解决三大核心问题：
保密性：数据加密传输（防窃听）。
完整性：数据未被篡改（防篡改）。
真实性：验证通信方身份（防伪装）。
握手流程解析：
- 客户端发送 ClientHello 消息给服务器，包含客户端支持的 SSL/TLS 版本、加密套件列表以及一个随机数(Client Random)
- 服务器响应 ServerHello 消息，包含服务器选定的 SSL/TLS 版本、加密套件以及另一个随机数(Server Random)
- 服务器发送证书(Certificate)给客户端，证书包含服务器的公钥以及由受信任的证书颁发机构(CA)签名的数字证书。
- 如果服务器需要客户端认证，则请求客户端证书(Client Certificate Request)。
- 服务器发送 ServerHelloDone 消息，表示握手的初步消息已经发完。
- 客户端验证服务器证书，如果证书有效，它会生成一个预主密钥(Pre-Master Secret)，并使用服务器的公钥加密这个预主密钥，把它发送给服务器。
- 服务器使用私钥解密预主密钥，客户端和服务器使用约定好的算法计算出主密钥(MasterSecret)。
- 客户端发送 ChangeCipherSpec 消息，表示后续的通信将使用协商好的密钥和加密算法。
- 客户端发送 Finished 消息，包含使用主密钥计算的握手消息摘要，以确认握手的完整性。
- 服务器发送 ChangeCipherSpec 消息，也表示后续通信将使用协商好的密钥和加密算法.。
- 服务器发送 Finished 消息，包含使用主密钥计算的握手消息摘要，双方握手完成，后续通信开始使用对称加密进行。
（部分内容参考面试鸭）
握手过程中的安全机制
1. 防中间人攻击
证书验证：确保服务器公钥未被伪造。
签名验证：Server Key Exchange消息中的参数由服务器私钥签名。
2. 前向保密（Perfect Forward Secrecy, PFS）
原理：每次会话使用临时密钥（如ECDHE），即使长期私钥泄露，历史通信仍安全。
启用条件：使用ECDHE密钥交换算法。
3. 防重放攻击
随机数（Client/Server Random）：确保每次会话密钥唯一。
Finished消息：验证握手过程完整性。
3.小结
今天的分享到这里就结束了，喜欢的小伙伴点点赞点点关注，你的支持就是对我最大的鼓励，大家加油！
