HTTP 协议详解
作者：王珂
邮箱：49186456@qq.com
文章目录
- HTTP 协议详解
- 简介
- 一、HTTP 协议
- 1.1 简介
- 1.2 HTTP 方法
- 1.3 HTTP 请求报文
- 1.4 HTTP 响应报文
- 1.4.1 响应行
- 1.4.2 响应头
- 1.4.2.1 Allow
- 1.4.2.2 Content-Type
- 1.4.2.3 Content-Length
- 1.4.2.4 Content-Encoding
- 1.4.2.5 Content-Language
- 1.4.2.6 Content-Location
- 1.4.2.7 Cache-Control
- 1.4.2.8 Cookie
- 1.4.2.9 Date
- 1.4.2.10 ETag
- 1.4.2.11 Expires
- 1.4.2.12 Server
- 1.4.2.13 Set-Cookie
- 1.4.2.14 Transfer-Encoding
- 1.4.2.15 Upgrade
- 1.4.2.16 Warning
- 1.4.2.17 WWW-Authenticate
- 1.4.4 响应体
- 1.5 HTTP 状态码
- 1.6 HTTP 认证
- 1.7 与HTTP/2协议交互
- 二、HTTPS 协议
文章目录
- HTTP 协议详解
- 简介
- 一、HTTP 协议
- 1.1 简介
- 1.2 HTTP 方法
- 1.3 HTTP 请求报文
- 1.4 HTTP 响应报文
- 1.4.1 响应行
- 1.4.2 响应头
- 1.4.2.1 Allow
- 1.4.2.2 Content-Type
- 1.4.2.3 Content-Length
- 1.4.2.4 Content-Encoding
- 1.4.2.5 Content-Language
- 1.4.2.6 Content-Location
- 1.4.2.7 Cache-Control
- 1.4.2.8 Cookie
- 1.4.2.9 Date
- 1.4.2.10 ETag
- 1.4.2.11 Expires
- 1.4.2.12 Server
- 1.4.2.13 Set-Cookie
- 1.4.2.14 Transfer-Encoding
- 1.4.2.15 Upgrade
- 1.4.2.16 Warning
- 1.4.2.17 WWW-Authenticate
- 1.4.4 响应体
- 1.5 HTTP 状态码
- 1.6 HTTP 认证
- 1.7 与HTTP/2协议交互
- 二、HTTPS 协议
简介
一、HTTP 协议
1.1 简介
HTTP 协议（Hypertext Transfer Protocol，超文本传输协议）是一种用于在万维网（WWW）中实现客户端与服务器之间资源（包括超文本、图片、视频等）传输的请求 / 响应协议。
HTTP基于TCP/IP通信协议进行数据传输。它采用客户端/服务器（C/S）架构模型，通过一个可靠的连接来交换信息，是一个无状态的请求/响应协议。
Uniform Resource Identifier（URI）
URI（统一资源标识符）是标识资源的字符串，包含 URL（统一资源定位符，标识资源的具体位置，如https://example.com/index.html）和 URN（统一资源名称，标识资源的唯一名称，如urn:isbn:0451450523），URL 是 URI 的子集。
绝对URI的格式如下：
URL: Uniform Resource Locator 是一个具体的地址
URL编码: 详见 url编码介绍
URL只能使用ASCII字符集通过因特网发送；
由于URL常常包含ASCII集合之外的的字符，URL必须转换为有效的ASCII格式；
URL编码使用“%”后面跟随两位的十六进制数来替换非ASCII字符。
URL不能包含空格。URL编码通常使用+来替换空格。
1.2 HTTP 方法
HTTP/1.0 和 HTTP/1.1 支持的方法
| 方法 | 说明 | 支持的协议版本 | 示例 |
|---|---|---|---|
| GET | 获取资源 | 1.0, 1.1 | |
| POST | 用于传输实体的主体；POST的头部和主体中间有一个空行； 不同格式需通过Content-Type请求头指定” | 1.0, 1.1 | application/x-www-form-urlencoded 的参数（需要转码，与URL中参数转码方式一致）格式为：key=value&key=valuemultipart/form-data 用于文件上传 application/json 用于传输 JSON |
| PUT | 更新资源 | 1.0, 1.1 | |
| DELETE | 删除资源 | 1.0, 1.1 | |
| HEAD | 获得报文首部 | 1.0, 1.1 | |
| OPTIONS | 询问支持的方法 | 1.1 | |
| TRACE | 追踪路径 | 1.1 | |
| CONNECT | 要求用隧道协议连接代理 | 1.1 | |
| LINK | 建立和资源之间的连接 | WebDAV 扩展协议的方法 | |
| UNLINK | 断开连接关系 | WebDAV 扩展协议的方法 |
HTTP/1.0 协议的默认瞬时协议
建立一次 TCP 连接，经过 3 次握手，然后发起一个 HTTP 请求，返回一个 HTTP 响应，断开连接。
HTTP/1.1 持久连接
为了解决 HTTP/1.0 发起一次请求前需要进行三次握手，得到响应后断开连接，再次发送请求又需要三次握手，这种频繁的三次握手问题，HTTP/1.1 提出了持久连接（HTTP Persistent Connections，也称 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。HTTP/1.1默认使用持久连接。
管道化
HTTP/1.1 的管道化（Pipelining）允许客户端在收到前一个请求的响应前，向服务器发送多个请求，减少了请求等待时间。但管道化要求服务器按请求顺序返回响应，且若中间某请求失败，后续请求可能受影响，实际应用中较少使用。
1.3 HTTP 请求报文
HTTP请求报文由3部分组成（请求行+请求头+请求体）；
1.3.1 请求行
<请求方法> <请求路径> <请求协议/协议版本>
① 请求方法：GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。
② 请求的URL地址：它和报文头的Host属性组成完整的请求URL。
③ 协议名称及版本号。
1.3.2 请求头
④ HTTP的请求头，请求头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。
HTTP首部字段可以有多个值，多个值之间可以用“,”连接，例如：Keep-Alive: timeout=15, max=100
| 请求头名称 | 说明 | 是否通用头 | 示例 |
|---|---|---|---|
| Accept | 可处理的媒体类型 | text/html | |
| Accept-Charset | 优先的字符集 | utf-8 | |
| Accept-Encoding | 优先的内容编码 | gzip, deflate, br, zstd | |
| Accept-Language | 优先的语言(自然语言) | zh-CN,zh;q=0.9 | |
| Authorization | Web 认证信息 | ||
| Cache-Control | 控制缓存的行为 | 是 | |
| Connection | 连接控制 | 是 | |
| Cookie | 客户端发送的cookie | 是 | |
| Date | 是 | ||
| Expect | 期待服务器的特定行为 | ||
| From | 用户的电子邮箱地址 | ||
| Host | 请求资源所在服务器 | www.example.com | |
| if-Match | 比较实体标记(ETag) | ||
| if-Modified-Since | 比较资源的更新时间 | ||
| if-None-Match | 比较实体标记(与If-Match相反) | ||
| if-Range | 资源未更新时发送实体Byte的范围请求 | ||
| if-Unmodified-Since | 比较资源的更新时间(与If-Modified-Since相反) | ||
| Max-Forwards | 最大传输逐跳数 | ||
| Proxy-Authorization | 代理服务器要求客户端的认证信息 | ||
| Range | 实体的字节范围请求 | ||
| Referer | 对请求中URI的原始获取方 | ||
| TE | 传输编码的优先级 | ||
| Trailer | 报文末端的首部一览 | 是 | |
| Transfer-Encoding | 是 | ||
| User-Agent | HTTP 客户端程序的信息 | ||
| Upgrade | 升级为其他协议 | 是 | |
| Via | 代理服务器的相关信息 | 是 | |
| Warning | 错误通知 | 是 |
1.3.2.1 Accept
用来告知服务器，用户代理能够处理的媒体类型以及其优先级。可以为一个或多个MIME类型的值（描述消息内容类型的因特网标准， 消息能包含文本、图像、音频、视频以及其他应用程序专用的数据）
文本文件
- text/html
- text/plain
- text/css
- application/xhtml+xml
- application/xml
图片文件
image/jpeg
image/gif
image/png
视频文件
video/mpeg
video/quicktime
应用程序
使用的二进制文件application/octet-stream
application/zip
1.3.2.2 Accept-Charset
用来告知服务器，用户代理支持的字符集以及字符集的相对优先级。另外，可以一次性指定多种字符集，用头字段 Accept 相同的是可用权重 q 的值来表示优先级。
1.3.2.3 Accept-Encoding
用来告知服务器，用户代理支持的内容编码以及内容编码的优先级。可一次性指定多种内容编码。
gzip
由压缩程序 gzip(GNU zip) 生成的编码格式（RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循环冗余校验（Cyclic Redundancy Check，通称 CRC）。
compress
由 UNIX 文件压缩程序 compress 生成的编码格式，采用 Lempel-Ziv-Welch 算法(LZW)。
deflate
组合使用 zlib 格式(RFC1950)及由 deflate 压缩算法（RFC1951）生成的编码格式。
identity
不执行压缩或不会变化的默认编码格式
1.3.2.4 Accept-Language
用来告知服务器，用户代理能够处理的自然语言集（中文或英文），以及自然语言集的相对优先级。可一次指定多种自然语言集。和 Accept 头字段一样，按权重 q 来表示相对优先级。
1.3.2.5 Authorization
用于告知服务器客户端的认证信息。常见的认证方案为Basic认证，其内容通常以Base64编码的用户名和密码形式附加在请求头中。例如：。
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=1.3.2.6 Cache-Control
通过指定头 Cache-Control，就能操作缓存的工作机制。指令的参数是可选的，多个指令之间用 “,” 分割。
1.3.2.7 Connection
HTTP/1.1 之前的 HTTP 版本默认的连接都是非持久连接。为此，如果想在旧版本的 HTTP 协议上维持持续连接，则需要指定头 Connection 为 Keep-Alive。
HTTP/1.1 版本的默认连接都是持久连接。为此，客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定Connection 首部字段的值为 Close。
1.3.2.8 Cookie
客户端的 Cookie 就是通过这个报文头传给服务端的。
如下所示：
Cookie: $Version=1; Skin=new;jsessionid=5F4771183629C9834F8382E23服务端是怎么知道客户端的多个请求是隶属于一个Session呢？注意到后台的那个 jsessionid = 5F4771183629C9834F8382E23 就是通过 HTTP 请求报文头的Cookie 属性的 jsessionid 的值关联起来的。
1.3.2.9 Host
Host 会告知服务器，请求的资源所处的互联网主机名和端口号。
Host 头字段在 HTTP1.1 规范内是唯一一个必须被包含在请求内的头字段。Host可以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联，这是首部字段 Host 必须存在的意义。
1.3.2.10 Referer
告知服务器当前请求的原始 URI（即该请求是从哪个页面跳转过来的）。
例如：从https://a.com跳转到https://b.com，则https://b.com的请求头 Referer 为https://a.com。但当直接在浏览器中输入URI，或处于安全考虑时，也可以不发送该头字段。
1.3.2.11 User-Agent
告知服务器，用户代理使用的操作系统、浏览器版本和名称。
1.3.3 请求体
请求头后空一行 \r\n\r\n 为请求体。
POST请求的数据在请求体中
⑤ 是报文体，它将一个页面表单中的组件值通过param1=value1¶m2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1¶m2=value2”的方式传递请求参数。
与缓存相关的规则信息，均包含在header中；
示例：最简单的请求报文
GET / HTTP/1.1 （必须）
Host: hacker.jp （必须）1.4 HTTP 响应报文
HTTP的响应报文也由三部分组成（响应行+响应头+响应体）。
响应行：
① 报文协议及版本；
② 状态码及状态描述；
状态码：和请求报文相比，响应报文多了一个“状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。
响应头：
③ 响应报文头，也是由多个属性组成；
响应体：
④ 响应报文体
即响应的内容。注意：响应报文体与最后一个响应报文头中间有一个空行。
最简单的响应报文
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 362
Content-Type: text/html
…
1.4.1 响应行
<HTTP协议/协议版本> <响应码> <响应信息>
1.4.2 响应头
HTTP响应头也由多个字段组成，主要用于指示响应的元数据，如服务器信息、内容类型、缓存策略等。
| 头字段 | 说明 | 是否通用头 | 是否实体头 | 示例 |
|---|---|---|---|---|
| Allow | 是 | |||
| Accept-Range | 是否接受字节范围请求 | |||
| Age | 推算资源创建经过的时间 | |||
| Content-Encoding | 是 | |||
| Content-Length | 是 | |||
| Content-Language | 是 | |||
| Content-Location | 是 | |||
| Content-MD5 | 是 | |||
| Content-Range | 是 | |||
| Content-Type | 实体内对象的媒体类型 | 是 | ||
| Date | 是 | |||
| Expires | 是 | |||
| ETag | 资源的匹配信息 | |||
| Location | 令客户端重定向至指定的URI | |||
| Last-Modified | 是 | |||
| Proxy-Authentication | 代理服务器对客户端的认证信息 | |||
| Retry-After | 对再次发起请求的时机要求 | |||
| Server | HTTP 服务器的安装信息 | |||
| Transfer-Encoding | 是 | |||
| Vary | 代理服务器缓存的管理信息 | |||
| Upgrade | 是 | |||
| WWW-Authenticate | 服务器对客户端的认证信息 | |||
| Warning | 是 |
1.4.2.1 Allow
用于通知客户端，服务器能够支持的 HTTP 方法。当服务器收到不支持的 HTTP 方法时，会以状态码 405 Method Not Allowed 做为响应。与此同时，还会把所有能支持的 HTTP 方法写入头 Allow 返回。
1.4.2.2 Content-Type
说明了实体内对象的媒体类型。和头字段 Accept 一样，字段值用 type/subtype 的形式赋值。参数 charset 使用 iso-8859-1 或 euc-jp 等字符集进行赋值。
Content-Type: text/html; charset=UTF-8text/event-stream
HTTP协议中text/event-stream是一种用于实现服务器推送事件（Server-Sent Events，SSE）的MIME类型，其处理机制如下：一、协议特性与数据格式
持久连接机制
服务器通过保持长连接，主动向客户端推送事件流数据，客户端无需重复发起请求。数据格式规范
每个事件由字段行组成，以\n\n结束单个事件块。常见字段包括：- data: 事件内容（必选，允许多行）
- id: 事件标识符（用于断线重连）
- event: 自定义事件类型（如message、error）
- retry: 重连间隔（毫秒）
示例：
event: status data: {"progress": 75%} data: 这是第一段内容 data: 这是第二段内容 id: 42
1.4.2.3 Content-Length
实体的长度(单位：字节)
1.4.2.4 Content-Encoding
用于告知客户端，服务器对实体的主体部分选用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行的压缩。
1.4.2.5 Content-Language
用于告知客户端，实体主体使用的自然语言（指中文或英文等）
1.4.2.6 Content-Location
给报文主体部分响应的 URI。和头字段 Location 不同，Content-Location 表示的是报文主体返回资源对应的 URI。
1.4.2.7 Cache-Control
响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。
常见的取值有private、public、no-cache、max-age，no-store，默认为private。
private: 客户端可以缓存
public: 客户端和代理服务器都可缓存（前端的同学，可以认为public和private是一样的）
max-age=xxx: 缓存的内容将在 xxx 秒后失效
no-cache: 需要使用对比缓存来验证缓存数据
no-store: 所有内容都不会缓存
1.4.2.8 Cookie
Cookie 的工作原理
没有 Cookie 信息下的请求
请求报文
首部字段内没有Cookie的相关信息
GET /reader/HTTP/1.1 Host:hackr.jp响应报文
服务端生成 Cookie 信息
HTTP/1.1 200 0K Date:Thu,12 Jul 2012 07:12:20 GMTServer:Apache Set-Cookie: session_id=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Path=/; Secure; HttpOnly Content-Type:text/plain;charset=UTF-8之后的请求自动发送 Cookie
GET /image/ HTTP/1.1 Host:hacker.jp Cookie:sid-1342077140226724
1.4.2.9 Date
1.4.2.10 ETag
一个代表响应服务端资源（如页面）版本的报文头属性，如果某个服务端资源发生变化了，这个ETag就会相应发生变化。它是 Cache-Control 的有力补充，可以让客户端更智能地处理什么时候要从服务端取资源，什么时候可以直接从缓存中返回响应。
1.4.2.11 Expires
会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段 Expires 的响应后，会以缓存来应答请求，在Expires 字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。
1.4.2.12 Server
用于告知客户端，服务器上安装的 HTTP 服务器应用程序的信息。不单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。
1.4.2.13 Set-Cookie
原理：
服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的：
Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
cookie机制：
客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
Cookie的maxAge决定着Cookie的有效期，单位为秒（Second）。Cookie中通过getMaxAge()方法与setMaxAge(int maxAge)方法来读写maxAge属性。
如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效。
如果maxAge为负数，则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该Cookie即失效。
如果maxAge为0，则表示删除该Cookie。
Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。
如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。
Cookie cookie = new Cookie(“username”,“helloweenvsfei”); // 新建Cookie
cookie.setMaxAge(0); // 设置生命周期为0，不能为负数
response.addCookie(cookie); // 必须执行这一句 输出到客户端
当服务器准备开始管理客户端的状态时，会事先告知各种信息
Set-Cookie: status=enable; expires=Tue, 05 Jul 2026 07:26:33 GMT; Path=/; domain=hacker.jp;| 属性 | 说明 | 示例 |
|---|---|---|
| NAME=VALUE | 赋予 Cookie 的名称和其值(必需项) | |
| expires=DATE | Cookie 的有效期(若不明确指定则默认为浏览器关闭前为止) | |
| path=PATH | 将服务器上的文件目录作为Cookie的适用对象(若不指定则默认为当前文档所在的文件目录) | |
| domain=域名 | 作为 Cookie 适用对象的域名(若不指定则默认为创建Cookie的服务器的域名) | |
| Secure | 仅在HTTPS安全通信时才会发送Cookie | |
| HttpOnly | 加以限制，使Cookie不能被JavaScript脚本访问 |
1.4.2.14 Transfer-Encoding
规定了传输报文主体采用的编码方式。
HTTP/1.1 200 OK
Date: Tue, 03 Jul 2012 04:40:56 GMT
Cache-Control: public, max-age=604800
Content-Type: text/javascript; charset=utf-8
Expires: Tue, 10 Jul 2012 04:40:56 GMT
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
Transfer-Encoding: chunked
Connection: keep-alive
16进制值（对应10进制字节数）
3312字节分块数据...
392（16进制，对应10进制914）
914字节分块数据...1.4.2.15 Upgrade
用于检测 HTTP 协议及其它协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。
1.4.2.16 Warning
HTTP/1.1 的 Warning 首部是从 HTTP/1.0 的响应首部(Retry-After)演变过来的。该首部通常会告知用户一些与缓存相关的问题的警告。
Warning:113 gw.hackr.jp:8080 "Heuristic expiration" Tue,03 Jul 2012 05:09:44 GMTWarning 首部的格式如下。最后的日期时间部分可省略。
warning:[警告码][警告的主机:端口号]“[警告内容]”([日期时间])1.4.2.17 WWW-Authenticate
用于 HTTP 访问认证。它会告知客户端适用于访问请求 URI所指定资源的认证方案(Basic或是 Digest)和带参数提示的质询(challenge)。
状态码 401Unauthorized 响应中，肯定带有首部字段 WWW-Authenticate。
1.4.4 响应体
响应体是服务器返回的具体数据内容，格式由响应头的Content-Type指定，例如 HTML 文档、JSON 数据等
1.5 HTTP 状态码
| 状态码 | 类别 | 说明 |
|---|---|---|
| 1xx | 信息性状态码 | 请求已接收，继续处理 |
| 2xx | 成功状态码 | 请求成功处理 |
| 3xx | 重定向状态码 | 需要进一步操作以完成请求 |
| 4xx | 客户端错误状态码 | 客户端请求有错误 |
| 5xx | 服务器错误状态码 | 服务器处理请求出错 |
以下是几个常见的状态码：
200 （OK）处理成功！
204 （No Content）No Content 没有内容
代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。比如，当浏览器发出请求后，返回204响应，那么浏览器显示的页面不发生更新。
一般用在只需要从客户端往服务器发送信息，而客户端不需要接收更新信息。
206（Partial Content）
该状态码表示客户端进行范围请求，而服务器成功执行了这部分GET请求。响应报文中包含由 Content-Range 指定范围的实体内容。
访问一些大的pdf，大的图片时会出现。
301（Moved Permanently）
永久性重定向。该状态码表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。
302（Moved Temporarily）
临时性重定向。该状态码表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问。
302：临时重定向，指出请求的文档已被临时移动到别处, 此文档的新的url在location响应头中给出
303 （See Other）
我把你redirect到其它的页面，目标的URL通过响应报文头的Location告诉你。
304 （Not Modified ）
告诉客户端，你请求的这个资源至你上次取得后，并没有更改，你直接用你本地的缓存吧
307 严格遵循请求方法不变（如 POST 请求重定向后仍为 POST），而 302 可能被浏览器转为 GET
401 (UNAUTHORIZED): 客户端无权访问该资源。这通常会使得浏览器要求用户输入用户名和密码，以登录到服务器。
403 (FORBIDDEN): 客户端未能获得授权。这通常是在401之后输入了不正确的用户名或密码。
404 (NOT FOUND): 在指定的位置不存在所申请的资源。
你最不希望看到的，即找不到页面。如你在google上找到一个页面，点击这个链接返回404，表示这个页面已经被网站删除了，google那边的记录只是美好的回忆。
500 （Internal Server Error）服务端错误。
1.6 HTTP 认证
证书：
1） 服务器将公钥、域名、颁发机构、有效期、版本、序列号、签名算法等数据集合密发给第三方机构；
2） 第三方机构用自己的私钥对数据集合进行加密，得到一个密文，称为签名。然后将原始数据和签名放在一起发送给服务器管理员，这就是TLS证书。
签名：
3） 服务器将证书发送给浏览器。浏览器从CA机构中的公开的公钥对证书中的密文进行解密，如果解密的结果和证书中的密文一致则验证通过。
4） 浏览器从证书中提取出公钥，加密随机数据为密钥发送给服务器和服务器协商好对称加密的密钥；
5） 服务器用密钥加密内容发送给浏览器；
浏览器用密钥解密内容进行展示；
BASIC认证
在HTTP协议进行通信的过程中，HTTP协议定义了基本认证过程以允许HTTP服务器对WEB浏览器进行用户身份证的方法。
当一个客户端向HTTP服务器进行数据请求时，如果客户端未被认证，则HTTP服务器将通过基本认证过程对客户端的用户名及密码进行验证，以决定用户是否合法。
客户端在接收到HTTP服务器的身份认证要求后，会提示用户输入用户名及密码；
然后将用户名和密码用‘:’拼接后进行 BASE64 编码（BASE64 是一种编码方式，非加密，目的是将二进制数据转为可传输的文本格式），并附加到 Authorization 请求头中；
如当用户名为anjuta，密码为：123456时，客户端将用户名和密码用“：”合并，并将合并后的字符串用BASE64加密为密文，并于每次请求数据时，将密文附加于请求头（Request Header）中。
HTTP服务器在每次收到请求包后，根据协议取得客户端附加的用户信息（BASE64加密的用户名和密码），解开请求包，对用户名及密码进行验证，如果用户名及密码正确，则根据客户端请求，返回客户端所需要的数据;否则，返回错误代码或重新要求客户端提供用户名及密码。
1.7 与HTTP/2协议交互
HTTP/2的Stream机制通过多路复用支持并发传输，但text/event-stream本身基于HTTP/1.1设计。在HTTP/2中：
- 每个SSE连接仍对应一个独立的HTTP/2流（Stream）3
- 流状态机（idle → open → half-closed → closed）管理连接生命周期3
- 流量控制通过WINDOW_UPDATE帧动态调整传输速率3
应用场景
| 场景 | 技术实现要点 |
|---|---|
| 实时日志推送 | 服务器持续发送格式化日志事件 |
| 进度状态反馈 | 分阶段发送data字段更新进度条 |
| 即时通讯 | 结合event字段区分消息类型 |
二、HTTPS 协议
Secure Socket Layer（SSL）安全套接层，是由网景Netscape Communication于1990年开发，用于保证Word Wide Web（WWW）通讯安全。主要任务是提供私密性，信息完整性和身份认证。1995年改版为SSL2.0，1996改本为SSL3.0。
Transport Layer Security（TLS）标准协议由IETF1999年颁布，整体来说TLS非常类似SSL3.0，只是对SSL3.0做了些增加和修改。
2.1 原理
HTTPS协议使用TLS（Transport Layer Security）为HTTP协议提供加密保护。在HTTPS中，通信内容被加密，确保数据的私密性和完整性，防止中间人攻击。TLS协议通过使用公钥加密和对称密钥加密来保证数据的安全性。
处理流程
- 用户在浏览器中访问 https://www.alisls.com
- 服务器将带有签名的证书发送给浏览器
- 浏览器用预装的 CA 公钥解密证书中的‘签名’（得到证书内容的哈希值），同时对证书中的原始内容（公钥、域名等）计算哈希值，若两者一致则证书合法
- 浏览器再随机生成一个对称加密的密钥，用公钥对对称加密的密钥进行加密，得到一个密文（对称加密的密钥）将其发
给Web Server : - Web Server用本地私钥对密文（对称加密的密钥）进行解密，取出对称加密的密钥:
- Web Server将内容用对称加密的密钥进行加密，然后发给浏览器:
- 浏览器接受内容，用对称加密的密钥进行解密，内容进行展示;
2.2 证书
2.2.1 Nginx 证书
创建 私钥
openssl genrsa -des3 -out server.key 2048创建签名请求的证书（CSR）
openssl req -new -key server.key -out server.csr加载SSL支持的Nginx并使用私钥时去除口令
cp server.key server.key.bak openssl rsa -in server.key.bak -out server.key自动签发证书
openssl x509 -req -days 10240 -in server.csr -signkey server.key -out server.crt
中的原始内容（公钥、域名等）计算哈希值，若两者一致则证书合法
4. 浏览器再随机生成一个对称加密的密钥，用公钥对对称加密的密钥进行加密，得到一个密文（对称加密的密钥）将其发
给Web Server :
5. Web Server用本地私钥对密文（对称加密的密钥）进行解密，取出对称加密的密钥:
6. Web Server将内容用对称加密的密钥进行加密，然后发给浏览器:
7. 浏览器接受内容，用对称加密的密钥进行解密，内容进行展示;
2.2 证书
2.2.1 Nginx 证书
[外链图片转存中…(img-SbwN0V6P-1759115763739)]
创建 私钥
openssl genrsa -des3 -out server.key 2048创建签名请求的证书（CSR）
openssl req -new -key server.key -out server.csr加载SSL支持的Nginx并使用私钥时去除口令
cp server.key server.key.bak openssl rsa -in server.key.bak -out server.key自动签发证书
openssl x509 -req -days 10240 -in server.csr -signkey server.key -out server.crt
浙公网安备 33010602011771号