HTTP 基础

软件架构分类

软件的架构我们将其分为两类：

• C/S 架构：客户端 - 服务端（客户端与服务端进行通讯）

• B/S 架构：浏览器 - 服务端（浏览器与服务端进行通讯）

www 是万维网简写 -> HTTP（超文本指的是文字、声音还有视频）协议（Web 的基座）

 

HTTP 协议，使用 HTML（网页标记语言、静态网页）将文字、声音、视频展示给客户端的浏览器

 

HTTP 访问地址

HTTP 协议访问的地址组成类型

URI：统一资源标识符

• URL（统一资源定位）：www.example.com/test.html （明确地址）

• URN（统一资源命名）：file.txt 资源名称 （P2P典型）

URL 和 URN 是 URI 的子集

 

HTTP 请求流程

1. 建立请求：客户端发送请求给服务端（如果有访问控制策略则可能拒绝）

2. 接受请求：服务端 web 软件读取请求的内容（报文）

3. 处理请求：服务端根据请求的资源从数据存储中返回资源并封装 HTTP 协议

4. 返回响应：将封装好的资源发送到客户端（浏览器），因此客户端可以得到响应并查看资源

5. 记录日志：发送响应完成后，web 服务器软件记录本次事件

 

HTTP 的特点

1. 连接是没有状态的，每一次连接都是向服务器重新发起请求，服务器响应请求后结束连接（没有连接的保持，能够让服务器的资源更优，更快的响应请求）

• 短连接：请求完成后立即断开连接

• 长连接：在网页资源特别多的场景，对服务器发起的请求书就会更多，因此，开启长连接，也就是链路复用，让多个资源通过一个 TCP 连接来完成传输

2. 单向连接：仅客户端发起请求连接服务端

3. 明文传输（对于重要的用户数据要使用 https进行数据加密）

 

HTTP 的版本

HTTP/0.9

• 1991 年推出，原型版本，功能局限性比较大，仅支持 GET 方法

 

HTTP/1.0

• 1996 年推出，新引入 POST 和 HEAD 方法，仅支持单次连接

 

HTTP/1.1

• 1997 年推出，新引入 PUT、PATCH、OPTIONS、DELETE 方法，相对于 HTTP/1.0 增加了持久连接

 

HTTP/2.0

• 2015 年推出，基于 SPDY 升级，引入了头信息压缩机制、服务器推送等功能

• 采用多路复用机制，在一个连接中，客户端和服务端可以同时发送多个请求或响应，且不用按顺序对应，避免了“对头堵塞”

仅支持 https，用户群体较少

 

HTTP/3.0

• 2022 年 6 月 6 日推出，使用 UDP 代替了 TCP，具有更低的延迟

 

HTTP 请求方法

HTTP 的请求方法（所谓的请求方法指的是 HTTP 可以做什么）

• GET：直接获取网页的内容（通过 URL 获取资源）

• POST：传输数据（数据是不直接可见的，指的是在发送的过程中在 URL 中是看不到的）

• HEAD：查看网页的头部信息（包括服务器的版本，操作系统类型，以及程序语言）

• PUT：直接上传内容

• DELETE：删除资源（因此在现代的 web 应用中已经禁止使用 Delete，通过 Web 软件或者动态脚本程序来完成资源的删除，而不是依靠 HTTP 来删除）

• TRACE：显示客户端的真正来路（用户的原始请求）

• OPTIONS：HTTP 支持的一些其他参数

 

HTTP 报文信息

HTTP 请求的方法 URL 地址 HTTP 的版本

HTTP 的字段（包含服务器的地址、连接的类型、认证类型和用户名密码）

网站的内容

 

HTTPS 加密访问

HTTPS 保证 连接安全 数据安全（数据都是加密传输）

加密的方法

• 对称加密：指的是加密和解密使用同一把秘钥

• 非对称加密：指的是加密和解密使用不同的秘钥

 

对称加密

• 优点：对数据的加解密都是非常快的

• 缺点：不是足够的安全（在数据的加解密过程中，秘钥要被传递，因此有泄漏风险）

 

非对称加密

非对称加密，通常是服务器端生成一对公私钥，利用这一组公私钥来鉴别对方的身份 RSA hash（经典的非对称加密算法），此算法是不可逆的

 

一般连接：使用公钥加密，使用私钥解密，私有谁生成谁保管（私钥永远不会在网络中流动）

 

数字签名：使用私钥签名通过公钥来校验（解密），RPM 中开发者通过自己的私钥对 RPM 包签名，以保证包的来源可靠

 

CA

权威机构，专门用来颁发 SSL 的证书，证书可以用在程序、服务器、web 网站等各种需要认证或者加解密的场景

 

CA 在 HTTPS 的场景中

专门用来对网站的公钥进行签名（网站的负责人提交 CSR（CSR 文件中包含了公钥、网站的域名、开设的服务器地址、申请人等 .....）申请信息到权威机构，权威机构 CA 使用自己的私钥对 CSR 进行签名，签名后就会得到证书（证书就是一个 CSR 的文件））

 

网站的证书

单域名证书

也就是证书只对一个特定的域名进行签名，这是所有证书中最便宜的（大部分公有云网站和 CA 机构都提供免费申请，一般是三个月有效期）

 

多域名证书

给多个特定的域名进行签名（这个是最具有性价比的）

 

通配符证书

就是对 *.example.com 所有子域名进行签名（这个是最贵的）

 

CA 在 HTTPS 中的作用

就是验证服务端身份，也就是服务端是否是冒充伪造的

1. 用户发起连接请求

2. 服务器响应请求并发送证书

3. 浏览器就会根据证书的信息使用证书中的 CA 的公钥来进行校验

4. 如果校验得出的信息与证书中的信息一致则说明服务端是可信的

 

HTTPS 的连接过程

接 CA 的过程

5. 如果校验通过，客户端使用服务端的公钥进行加密随机数并发给服务端

6. 服务端通过自己的私钥解密随机数，服务端使用随机数进行对称加密，加密数据发送给客户端

7. 客户端通过本地的随机数解密得到数据

因此在 HTTPS 中，非对称加密用来验证服务端的身份，对称加密用来传递数据

 

HTTP 最成功的应用场景 —— Web 服务

所谓 Web 服务就是提供静态资源（静态网页，或者是文件下载等）和动态资源（php脚本、Python 的应用程序等）的共享访问

 

提供 Web 服务的软件

IIS 微软提供 WEB 服务器的软件

Apache 开源基金会 WEB 软件，在 Linux 中最典型的存在

Nginx 开源的 WEB 软件，具有较高的并发性

Tomcat 开源

Tengine 阿里

stgw 腾讯

 

HTTP 访问模型

HTTP 请求的访问模型

1. 单进程 IO 模型，一个进程接收一个 HTTP 请求，当并发量大时则引起 IO 等待，也就是进程必须等待上一个请求处理完成才会处理下一个请求

2. 多进程 IO 模型，一个进程接收一个 HTTP 请求，但是同时启动多个进程，解决访问量大的问题，但是在高并发场景中依然不适用

3. 复用 IO 进程模型，一个进程派生出多个线程，每个线程可以接受一个请求，能够极大的解决并发的问题，如果有大量的并发依然可以处理过来，但是如果长连接保持的特别多，就依然会引起 IO 等待

4. 复用多进程 IO 模型，通过事件（Linux 的内核特性从 kernel2.6 开始引入 epoll）机制来保证高并发和长连接的处理，在这个模型通过监控线程来处理 HTTP 请求（当请求到达 Linux 后，监控线程将其交给工作线程处理请求，从而导致监控线程释放后接着等待 HTTP 连接）

 

HTTP 响应码

通过 HTTP 的响应码来决定 HTTP 是否访问成功

100-199：信息性状态码

200-299：成功状态码

300-399：重定向状态码

400-499：客户端错误状态码

500-599：服务器错误状态码

 

常见状态码

200：OK，表示连接正常

403：Forbidden，访问被拒绝，大多数是由于客户端对被请求的文件没有访问权限，或者由于被访问资源对应的文件或者目录损坏

404：Not Found，表示无法找到任何资源

503：Server Unavailable，表示服务器当前无法处理客户端的请求，可以尝试刷新重新发送新的请求

504：Gateway Timeout，表示未接收到服务器的及时响应

301：请求的 URL 指向的资源已经被删除，但是响应报文中通过首部 Location 指明了资源现在所处的位置，Moved Permanently

302：响应报文 Location 指明资源临时新位置 Moved Temporarily

304：客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过响应此响应码通知客户端， Not Modified

307：浏览器内部重定向

401：需要输入账号和密码认证方能访问资源：Unauthorized

500：服务器内部错误：Internal Server Error

502：代理服务器从后端服务器接收到了一天伪响应，如无法连接到网关，Bad Gateway