HTTP协议详解与实践-优快云博客

本文链接：https://blog.youkuaiyun.com/yingmu__/article/details/123962429

本文详细介绍了HTTP协议，包括其无状态、请求/应答方式等特点，以及HTTP请求报文和响应报文的结构。此外，还探讨了HTTP的不同版本（HTTP 1.0、1.1和2.0）的特点，如HTTP 1.1的长连接和HTTP 2.0的多路复用。接着，解释了HTTPS协议的SSL/TLS握手过程，以及Cookie、Session和Token在保持会话状态中的作用。最后，简要讨论了Web攻击技术和浏览器输入URL后的完整过程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. HTTP协议

1.1 简介

HTTP（Hypertext Transfer Protocol）是超文本传输协议，是一种无状态的、应用层的、以请求/应答方式运行的协议，它使用可扩展的语义和自描述消息格式，与基于网络的超文本信息系统进行交互。

主要特点如下：

无状态：对于之前的访问状态等信息不会记录。
请求/应答方式：由客户端发起请求，经过服务端处理后，返回响应给客户端。
自描述消息格式：可以通过 Content-Type 来描述传输的消息类型，例如 application/json、text/html 等。
无连接：在不使用 keep-alived 机制时，每次连接只处理一个请求，处理请求后会立即断开连接。
超文本信息系统：传输的内容不局限于文本，还包括图片、视频、音频等。

在 Client-Server 两端通信时，浏览器作为 HTTP 客户端，通过 URL 向 Web 服务器发送请求报文。Web 服务器接收到请求后，经过处理后向客户端发送响应信息，默认端口号为 80。

1.2 URI/URL/URN

URI 为 Web 资源提供了统一的资源命名方式，URI 分为 URL 和 URN，三者关系如下：

URI（Uniform Resource Indentifier，统一资源标识符）：用于标识某一互联网资源。
URL（Uniform Resource Locator，统一资源定位符）：表示资源的地点。
URN（Uniform Resource Name，统一资源名称）：表示资源的名称。

绝对 URI 格式：

http://username:passsword@www.example.com:80/index.html?uid=1#ch1

1.3 HTTP 请求报文

HTTP 请求报文包括三个部分：请求行、请求头、空格和实体。

1.3.1 请求行

请求行包括请求方法、URL和HTTP协议

1.3.1.1 请求方法

方法有 GET、POST、PUT、DELETE 等八种类型。

方法	特点
GET	用来获取服务器端的一些资源，例如页面、`JSON` 字符串等。
POST	向服务器端发送数据，传输实体主体
PUT	传输文件
DELETE	删除文件

1.3.1.2 GET 与 POST 的区别

类型	GET	POST
作用	获取资源	向服务器发送数据
参数	通过 `URL` 请求传递参数 `GET test/login.jsp?name=timber&password=123 HTTP/1.1`	通过请求实体传递参数 `POST test/login.jsp HTTP/1.1` `Host: http://127.0.0.1` `name=timber&password=123`
传输数据大小	有限制，最多1024个字符	无限制
参数的数据类型	ASCII码	无限制
安全性	`URL` 是可见的，可能会泄露个人信息	`POSt` 相较于 `GET` 安全性较高。因为参数存在于Boby中，且不会被保存到浏览器历史或WEB日志中。
后退/刷新	不会产生害处	数据会被重新提交
书签	可被存为书签	不可存为书签(因为post存为书签不会保存数据)
缓存	可以	不可以
历史记录	参数可保存在历史记录中	不能保存
编码类型	只进行url编码	支持多种编码方法
幂等性	`GET` 方法是幂等的。连续调用多次，客户端接收到的结果都一样	`POST` 方法不是幂等的。调用多次就会增加多条记录。

幂等性：同样的请求被执行一次与连续执行多次的效果相同。

get产生一个TCP数据包，POST产生2个TCP数据包
- get会把http header和data一起发送
- post先发送header，服务器响应100 continue，然后再发送data。（火狐浏览器只发送一次）

1.3.2 请求头部

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号":"分隔，请求头部通知服务器有关客户端请求的信息，典型的请求头有：

请求头	值
User-Agent	产生请求的浏览器类型
Accept	客户端可识别的内容类型列表
Host	请求的主机名，允许多个域名同处一个IP地址

1.3.3 空格

1.3.4 请求数据

1.4 响应报文

HTTP 响应报文也包括三个部分：状态行、响应首部和响应实体。状态行中的状态码和短语会反映 HTTP 请求的结果和大致的原因。

1.4.1 状态行

状态行由协议类型及版本号、状态码、状态码文字描述组成。

1.4.1.1 状态码

状态码是客户端向服务器端发送请求时，描述返回的请求结果。主要有以下五种：

–	类别	原因短语
1xx	处理信息	接收的请求正在处理
2xx	成功	请求正常处理完毕
3xx	重定向	需要进行附加操作以完成请求
4xx	客户端错误	服务器无法处理请求
1xx	服务器错误	服务器处理请求出错

下面是一些常见的状态码及其短语：

2xx 成功

200 OK 请求被正常处理
204 No Content 请求已成功处理，但响应报文的实体中没有内容

3xx 重定向

301 Moved Permanently 永久性重定向。表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI
302 Found 临时性重定向。表示请求的资源已被分配了新的 URI，希望用户本次能使用新的 URI 访问。
303 See Other 表示请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源
304 Not Modified 表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回 304 Not Modified    
307 Temporary Redirect 临时重定向。与 302 Found 有相同的含义

4xx 客户端错误

400 Bad Request 表示请求报文中存在语法错误
401 Unauthorized 表示发送的请求需要有通过 HTTP 认证的认证信息
403 Forbidden 表明对请求资源的访问被服务器拒绝
404 Not Found 表明服务器上无法找到请求的资源

1xx 服务器错误

100 Internal Server Error 服务器端在执行请求时发生了错误。
102	Bad Gateway	作为代理或网关的服务器收到了错误响应
103 Service Unavailable 表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

1.4.2 首部字段

首部都是 key-value 形式，保存了一些重要信息。主要有五种类型：通用首部、请求首部、响应首部、实体首部和扩展首部。

常用的通用首部字段：

Date：说明报文创建的日期和时间；
Cache-control：用来控制缓存；

请求首部字段：

Host：请求的服务器主机和端口；
Accept-Charset：客户端可以接受的字符集，防止出现乱码；
Connection：表示是否需要持久连接；
If-Modified-Since：关于缓存的，只有所请求的内容在指定的日期后被修改过才会返回，否则返回 304 Not Modified；

响应首部字段：

Server：服务器应用程序的名称和版本；
Retry-After：告诉客户端在多长时间后再次尝试；

通用首部字段：

Last-Modified：实体最后一次修改日期和时间；
Content-Type：报文实体的 MIME 类型；
Content-Length：报文实体的主体长度；

2. HTTP 不同版本

HTTP 主要有三个版本：HTTP 1.0、HTTP 1.1、HTTP 2.0，但 HTTP 1.1 仍然最为广泛使用。

2.1 HTTP 1.0

HTTP 1.0 是一种无状态、无连接的应用层协议。浏览器每次请求都需要与服务器建立一个 TCP 连接，处理完成后立即断开 TCP 连接，服务器对于发送过的请求或响应都不做持久化处理。但可以借助 Cookie/Session 机制做身份认证和状态记录。

无状态	对于之前的访问状态等信息不会记录。
无连接：	在不使用 keep-alived 机制时，每次连接只处理一个请求，处理请求后会立即断开连接。

2.2 HTTP 1.1

和http1.0相比：

缓存处理
- 引入了更多的缓存策略。在用户首次访问资源时，浏览器会将资源文件添加到缓存池中。当用户再次访问时，浏览器从本地缓存池中查看有无缓存，若有则直接使用该缓存资源，若没有再去服务器请求文件。增加缓存既缓解了服务器压力，也降低了客户端获取资源的延迟。
节约带宽
- 允许只传输头部。HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。
Host域
- 增加了 Host 字段，使得服务器能够用来创建多个 Web 站点。多个虚拟主机共享一个ip地址。
长连接
- HTTP/1.1 中增加了 Connection 字段，通过设置 Connection:Keep-Alive 可以保持 HTTP 连接状态，也就是在一个 TCP 连接上可以传送多个 HTTP 请求和响应，这就不用每次客户端与服务端请求都需要建立和释放 TCP 连接，提高了网络的利用率。

2.3 HTTP 2.0

和http1.x相比：

头部压缩
- HTTP/2.0 对 HTTP 的头部进行一定的压缩，将原来每次都要携带的大量 key-value 在两端建立一个索引表，对相同的头只发送索引表中的索引。这样既避免了对头部的重复传输，又减少了需要传输的数据大小。
二进制分帧
- HTTP/2.0 在应用层和传输层之间增加一个二进制分帧层，把 HTTP/1.x 的请求首部和实体部分用 frame 重新封装了一层，改进了传输性能。
多路复用
- HTTP 2.0 通信都在一个 TCP 连接上完成，这个连接上可以承载任意数量的双向数据流。每个数据流以消息的形式发送，而消息由一个或多个帧组成。这些帧可以乱序发送，然后根据每个帧头部的流标识符重新组装。
  
  另外，每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回给客户端。这样可以防止队列阻塞。
服务器推送
- 服务器推送能把客户所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤，正因为发起请求、建立连接等操作，所以静态资源通过服务器推送的方式可以极大地提升速度。

2.4 总结

2.4.1 短连接、长连接和多路复用

HTTP1.0 短连接
- 一次请求-响应，建立一个连接，用完关闭，每一次请求都要建立连接。
- 优点是管理起来比较简单，存在的都是有用的连接，不需要额外的控制手段。适合请求比较少的情况。
- 缺点是请求频繁的话，在tcp的建立和关闭上浪费时间。
HTTP1.1 长连接
- 管道解决方式：建立一个连接，可以传送多个HTTP请求。若干个请求串行化单线程处理，一次只能处理一个请求，后面的请求需要等待前面请求返回后才可以继续执行。那么一旦有某个请求超时，后续的请求都会被阻塞，也就是人们常说的线头阻塞。
- 优点：减少了TCP频繁的建立和关闭操作，节约时间。
- 缺点：存活功能（探测TCP连接的存活）的探测周期过长，遇到恶意的连接时，保活功能就不够使了。在长连接的应用下，客户端一般不会主动关闭连接，如果一直不关闭的话，随着客户端连接越来越多，服务端早晚会扛不住。这时候服务端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致服务端受损。如果条件允许，可以以客户端机器为颗粒度，限制每个客户端的最大连接数，这样可以完全避免一些非法客户端连累后端服务。
HTTP2.0 多路复用
- 在HTTP1.1的基础上，去掉了一次只能通过一次HTTP请求的限制，同一个TCP连接，可以一次通过多个HTTP请求，某个请求任务耗时严重，不会影响到其他连接的正常运行。

2. HTTPS

对于 HTTP 协议来说，由于通信使用的是明文，其内容可能被窃听；没有验证通信方的身份，可能遭遇伪装；无法证明报文的完整性，有可能已遭篡改。所以需要在 HTTP 协议上再加上加密和认证等机制。

HTTPS，实际上就是在 HTTP 协议的基础上，在 TCP 与 HTTP 层之间加入了 SSL/TLS，提供了对称和非对称加密、证书等机制，以此来确保数据传输的安全。可以说，HTTPS 就是 HTTP + 加密 + 认证 + 完整性保护。

SSL（secure sockets layer）是安全套接层，TLS（Transport layer security）是 SSL 的继任者，叫传输层安全协议。以前使用的是 SSL，目前已基本废除，使用的都是 TLS。

HTTPS 协议使用对称加密和非对称加密混合的方式，在建立链路交换密钥时，使用非对称加密的方式，在之后的传输报文阶段，使用对称加密方式。

HTTP	HTTPS
明文传输	密文传输
不需要ca证书	需要证书
响应快	响应慢(加了ssl)
端口80	443

2.1 SSL协议

握手协议
- 建立安全连接
  - 客户端以明文的方式向服务器传输 SSL 协议版本信息、所支持的加密算法等信息。还有一个随机数用于协商对称密钥时使用；
  - 服务器同样以明文的方式向客户端传输 SSL 协议版本信息，并会选择自己支持的对称加密算法返回给客户端。还有一个随机数用于密钥协商。同时服务器也会返回公钥证书；此时，SSL 握手协商部分结束；
- 服务器鉴别和密钥交换
  - 客户端会对证书进行验证，验证可信后会产生一个随机数，用服务端发来的证书中的公钥加密后发送给服务器，作为对称加密密钥；
- 客户端鉴别和密钥交换
  - 服务端使用证书中的私钥对加密信息进行解密，获得对称加密的密钥。
记录协议
- 客户端和服务器鉴别对方确认安全信息的算法
  - 保密性使用握手协议协商的密钥实现
  - 完整性定义了消息认证码MAC保证完整性
警报协议
- 双方发现错误时向对方发送，致命错误关闭ssl连接
如果session已经有了执行会话恢复
- 客户端携带session id发送给服务器端，服务器端检索session的缓存记录，如果存在就返回之间的密钥，过期就正常握手。

SSL 过程：

证书验证
- 浏览器发送请求建立ssl连接，服务器发挥https证书，生成公私钥对，公钥发送给客户端，客户端验证证书。
数据传输
- 客户端生成对称密钥，用服务器的公钥加密对称密钥，然后发送给服务端
- 服务端解密拿到对称密钥
- 通过对称密钥加密数据

bug

可能产生中间人攻击
公钥由第三方认证机构CA认证

3. Cookie 、Session、Token

3.1 Cookie

HTTP 是一种无状态的协议，不会记录之前的访问状态，可以通过 Cookie 来解决，Cookie 是客户端保存用户信息的一种机制，每次 HTTP 请求时，客户端都可以发送相应的 Cookie 信息到服务端。可以设置 Cookie 信息的过期时间。

Cookie 由服务端生成，然后发送给客户端（浏览器）的。一般保存由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间较为短暂。有容量限制，一个站点最多保存20个cookie

工作原理

当用户第一次访问网站时，服务端会为该用户创建一个 Cookie 对象；服务端会将 Cookie 放入到 HTTP 响应报文的 Set-Cookie 字段中，发送给客户端。
浏览器在收到响应报文后，根据报文头里的 Set-Cookie 生成相应的 Cookie，保存在客户端中，其中记录着用户当前的信息。
当用户再次访问该网站时，浏览器首先会检查所有的 Cookie，如果存在该网站的 Cookie，则将其附加在请求报文的 Cookie 字段中，发送给服务器。
服务器在收到用户的 HTTP 请求报文后，从报文头获取到该用户的 Cookie，进行处理。