Http协议解析

一、概述

超文本传输协议（Hyper Text Transfer Protocol，简称HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。

1.1 发展历史

• 起源：HTTP的发展是由蒂姆·伯纳斯-李于1989年在欧洲核子研究组织（CERN）所发起。
• 标准制定：由万维网协会（W3C）和互联网工程任务组（IETF）联合协调，以RFC（请求评论）文档形式发布
• 关键版本：
  • HTTP/1.1（1999年6月，RFC2616）：目前应用最广泛的版本，奠定核心通信机制
  • HTTP/2（2015年5月，RFC7540）：取代HTTP/1.1，优化传输效率（多路复用、头部压缩等）

1.2 核心特性

• 应用层协议：基于TCP/IP协议族，但不依赖特定传输层（仅要求下层提供可靠传输）
• 请求-响应模型：客户端主动发起请求，服务器被动响应，无请求则无响应
• 默认端口：80（HTTP）、443（HTTPS，加密版）
• 通信角色：
  • 客户端（用户代理）：浏览器、爬虫等发起请求的终端
  • 服务器（源服务器）：存储HTML、图像等资源并返回响应的主机
  • 中间层：代理服务器、网关、隧道等转发请求/响应的节点

二、工作原理

2.1 请求

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

以下是HTTP请求/响应的步骤：

1. 客户端连接到Web服务器
   一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.baidu.com。
2. 发送HTTP请求
   通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
3. 服务器接受请求并返回HTTP响应
   Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4. 释放连接TCP连接
   若connection模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5. 客户端浏览器解析HTML内容
   客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1. 浏览器向DNS服务器请求解析该URL中的域名所对应的IP地址;
2. 解析出IP地址后，根据该IP地址和默认端口80，和服务器建立TCP连接;
3. 浏览器发出读取文件(URL中域名后面部分对应的文件)的HTTP请求，该请求报文作为TCP三次握手的第三个报文的数据发送给服务器;
4. 服务器对浏览器请求作出响应，并把对应的html文本发送给浏览器;
5. 释放TCP连接;
6. 浏览器将该html文本并显示内容;
   

http协议是基于TCP/IP协议之上的应用层协议。

基于请求-响应的模式

HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应

无状态保存

HTTP是一种不保存状态,即无状态(stateless)协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别,协议对于发送过的请求或响应都不做持久化处理。

使用HTTP协议,每当有新的请求发送时,就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把HTTP协议设计成如此简单的。可是,随着Web的不断发展,因无状态而导致业务处理变得棘手的情况增多了。比如,用户登录到一家购物网站,即使他跳转到该站的其他页面后,也需要能继续保持登录状态。针对这个实例,网站为了能够掌握是谁送出的请求,需要保存用户的状态。HTTP/1.1虽然是无状态协议,但为了实现期望的保持状态功能,于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管理状态了。有关Cookie的详细内容稍后讲解。

无连接

无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间，并且可以提高并发性能，不能和每个用户建立长久的连接，请求一次相应一次，服务端和客户端就中断了。但是无连接有两种方式，早期的http协议是一个请求一个响应之后，直接就断开了，但是现在的http协议1.1版本不是直接就断开了，而是等几秒钟，这几秒钟是等什么呢，等着用户有后续的操作，如果用户在这几秒钟之内有新的请求，那么还是通过之前的连接通道来收发消息，如果过了这几秒钟用户没有发送新的请求，那么就会断开连接，这样可以提高效率，减少短时间内建立连接的次数，因为建立连接也是耗时的，默认的好像是3秒中现在，但是这个时间是可以通过咱们后端的代码来调整的，自己网站根据自己网站用户的行为来分析统计出一个最优的等待时间。

2.2 URL

超文本传输协议（HTTP）的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中：

• 传送协议。
• 层级URL标记符号(为[//],固定不变)
• 访问资源需要的凭证信息（可省略）
• 服务器。（通常为域名，有时为IP地址）
• 端口号。（以数字方式表示，若为HTTP的默认值“:80”可省略）
• 路径。（以“/”字符区别路径中的每一个目录名称）
• 查询。（GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题）
• 片段。以“#”字符为起点

以http://www.baidu.com:80/news/index.html?id=250&page=1为例，其中：

• http，是协议；
• www.baidu.com，是服务器；
• 80，是服务器上的默认网络端口号，默认不显示；
• /news/index.html，是路径（URI：直接定位到对应的资源）；
• ?id=250&page=1，是查询。

大多数网页浏览器不要求用户输入网页中“http://”的部分，因为绝大多数网页内容是超文本传输协议文件。同样，“80”是超文本传输协议文件的常用端口号，因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分（www.baidu.com:80/news/index.html?id=250&page=1）就可以了。

由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址，因此许多服务器允许用户省略网页地址中的部分，比如www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址，浏览器本身无法决定这个新地址是否通，服务器必须完成重定向的任务。

2.3 连接

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-aliveCopy to clipboardErrorCopied

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

——《HTTP长连接、短连接究竟是什么？》

三、HTTP请求格式

URL包含：/index/index2?a=1&b=2；路径和参数都在这里。

请求头里面的内容举个例子：这个length表示请求体里面的数据长度，其他的请求头里面的这些键值对，陆续我们会讲的，大概知道一下就可以了，其中有一个user-agent，算是需要你记住的吧，就是告诉你的服务端，我是用什么给你发送的请求。

以京东为例，看一下user-agent

看一个爬虫的例子，爬京东的时候没问题，但是爬抽屉的时候必须带着user-agent，因为抽屉对user-agent做了判断，来判断你是不是一个正常的请求，算是反扒机制的一种。

打开我们保存的demo.html文件，然后通过浏览器打开看看就能看到页面效果。

写上面这些内容的意思是让你知道有这么个请求头的存在，有些是有意义的，请求头我们还可以自己定义，就在requests模块里面那个headers={}，这个字典里面加就行。

HTTP请求是浏览器或其他客户端和服务器之间通信的基础。一个HTTP请求由四个部分组成：

• 请求行(request line)
• 请求头(headers)
• 空行(blank line)
• 请求体(body)

3.1 请求行(Request Line)

请求行由方法(Method)、请求URI(Uniform Resource Identifier)、协议版本组成，这三部分通过空格分开。

• 方法(Method): 定义了对资源的操作，如GET、POST、PUT、DELETE等
• 请求URI: 指定了请求的资源路径
• 协议版本: 通常是HTTP/1.1或HTTP/2.0

示例: GET /index.html HTTP/1.1

3.1.1 方法(Method)

方法指明了客户端希望服务器对资源执行的操作。这个部分是一个动词或者一个名词，常见的HTTP方法包括：

• GET: 请求获取指定资源。GET请求应当只用于获取数据而不会引发服务器上数据的改变。
• POST: 用于提交数据，例如表单数据。POST请求可能会导致新的资源的创建或已有资源的修改。
• PUT: 将请求的数据上传到指定的URI（如果指定的URI不存在，则创建它）。
• DELETE: 请求删除指定的URI上可用的资源。
• HEAD: 请求获取资源的元数据（metadata），类似于GET请求，但不返回消息体。
• OPTIONS: 用于描述目标资源的通信选项。
• PATCH: 用于对资源应用部分修改。

其他方法（如TRACE和CONNECT）在Web应用中较少使用。

3.1.2 请求URI

请求URI（Uniform Resource Identifier）指明了请求应当被应用的资源。它告诉服务器要获取或操作的具体资源。例如：

• 绝对路径: /index.html或/images/logo.png
• 带查询字符串: /search?q=http(q=http是查询参数，告诉服务器按照"http"进行搜索)

在HTTP/1.1中，请求URI通常传递的是URI的路径和可选的查询字符串。但是在代理请求中，它可能是完整的URI。

3.1.3 协议版本

协议版本标识了客户端用于构造请求的HTTP协议的版本。这个信息非常重要，因为它告知服务器客户端理解的协议细节和能力。常见的版本有：

• HTTP/1.0: 较早的HTTP版本，简单并且不支持每个连接多个请求（非持续连接）。
• HTTP/1.1: 当今最普遍的版本，支持持续连接、流水线化请求、更高效的缓存处理等。
• HTTP/2: 最新的HTTP版本（直到知识截止日期为止），支持多路复用、头部压缩、服务器推送等。

完整的请求行通常看起来像这样：

GET /index.html HTTP/1.1

这个请求行告诉服务器客户端想要通过GET方法获取根目录下的index.html文件，并且客户端会按照HTTP/1.1版本的规则进行通信。

每个部分由空白字符（通常是个空格）分隔。请求行后面紧接着是请求头部，由一个CRLF（回车加换行，\r\n）标识请求行的结束。在HTTP请求和响应中，CRLF用来作为消息中各个头部字段的分隔符。

3.2 请求头(Request Headers)

HTTP请求头由一系列的键值对组成，它们为HTTP请求提供了额外的上下文和参数设置。以下是一些常见的请求头部字段，以及它们的含义和用途：

1. Host
   描述: 指定服务器的域名和（可选的）端口号。在HTTP/1.1中，Host是唯一一个必须存在的请求头。
   示例: Host: www.example.com

2. User-Agent
   描述: 包含了发起请求的客户端信息，比如浏览器类型、版本、操作系统等。
   示例: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

3. Accept
   描述: 指明客户端能够接受的内容类型，也就是服务器可以返回的媒体资源类型。
   示例: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8

4. Accept-Language
   描述: 告诉服务器客户端优先选择的语言，通常用于国际化内容。
   示例: Accept-Language: en-US,en;q=0.5

5. Accept-Encoding
   描述: 告诉服务器客户端支持的内容编码方式，比如gzip或deflate压缩。
   示例: Accept-Encoding: gzip, deflate

6. Connection
   描述: 控制当前事务完成后，客户端和服务器之间连接的处理方式，例如keep-alive或close。
   示例: Connection: keep-alive

7. Cache-Control
   描述: 指示请求和响应遵循的缓存机制。
   示例: Cache-Control: no-cache

8. Cookie
   描述: 包含从服务器接收的所有cookies，服务器可以用它来恢复客户端的会话状态。
   示例: Cookie: sessionToken=abc123; userId=789

9. Content-Length
   描述: 在POST或PUT请求中，指示请求体的大小（以字节计）。
   示例: Content-Length: 348

10. Content-Type
    描述: 当发送POST或PUT请求时，这个请求头必须被使用来指示提交数据的MIME类型。
    示例: Content-Type: application/json

11. Authorization
    描述: 包含了证明客户端有权查看某资源的证书。它通常涉及一个承载令牌，如JWT或OAuth令牌。
    示例: Authorization: Bearer YOUR_TOKEN_HERE

12. Referer
    描述: 指示发起请求的前一个页面的URI，可以用来跟踪从何处链接到当前请求的资源。
    示例: Referer: http://www.example.com/index.html

示例:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: userID=12345; sessionToken=abcdef

这些请求头部字段是用于客户端和服务器之间交换附加信息，优化请求处理和响应内容。并不是所有的头部字段都会在每个请求中出现，它们依据请求的类型和客户端的需求而变化。

在真实的HTTP通信中，还会有很多其他的请求头部字段，这些字段可以定义非标准的、实验性的或针对某个应用的特定行为。开发者有时也会自定义HTTP头部来传输特定的信息。

3.3 空行(Blank Line)

头部和主体之间的空行是请求的一个重要部分，即使请求没有主体，这个空行也必须存在。它告诉服务器头部结束、接下来是请求体。

3.4 请求体(Request Body)

请求体（Request Body）是HTTP请求消息的可选部分，仅在请求方法支持且需要发送数据时使用。例如，当你提交表单数据时使用POST方法，或使用PUT方法上传内容，对于GET和HEAD请求来说，通常没有请求体。请求体中包含的实际数据类型和格式取决于请求头中的Content-Type字段。以下是一些常见的请求体类型及其使用场景：

1. application/x-www-form-urlencoded
   描述: 这是最常见的请求体类型，通常用于HTML表单提交。
   格式: 键值对以&符号分隔，且键和值都为URL编码。例如，key1=value1&key2=value2。

2. multipart/form-data
   描述: 用于文件上传和发送表单数据时，当表单中有字段时常用这种类型。
   格式: 请求体被分割成多个部分，每部分包含一个不同的表单域数据，部分之间由分隔符（boundary）隔开。

3. application/json
   描述: 用于发送JSON编码的数据。现代Web APIs和RESTful服务通常用这种格式。
   格式: JSON字符串，如{"key1":"value1","key2":"value2"}。

4. text/plain
   描述: 纯文本数据，不含任何数据类型或结构描述符。
   格式: 简单的文本字符串，没有特定的结构。

5. application/xml或text/xml
   描述: XML数据格式，某些服务或API可能需要使用XML格式进行数据交换。
   格式: 符合XML规范的字符串，例如value1value2。

6. application/octet-stream
   描述: 用于传输二进制数据或文件内容，指示请求体中的数据是原始的字节。
   格式: 数据被当作一系列字节处理。

请求体示例

application/x-www-form-urlencoded: username=user1&password=pass123&email=user1%40example.com
multipart/form-data: --boundary12345
Content-Disposition: form-data; name="file"; filename="example.txt"
Content-Type: text/plain... file contents here ...--boundary12345--application/json: { "username": "user1","password": "pass123","email": "user1@example.com"
}text/plain: This is plain text.

请求体被视为消息的负载，并且根据用途可能含有不同的媒体类型、字符集编码以及内容编码（如gzip）。需要注意的是，并非所有HTTP方法都含有请求体（例如，GET和HEAD请求通常没有请求体），并且即使方法支持包含请求体，也不代表每次请求都必须包含请求体内容；这取决于具体的使用场景和需求。

四、HTTP响应格式

HTTP响应同样由三部分组成：

• 状态行
• 响应头
• 响应体

4.1 状态行（Status Line）

状态行包含HTTP协议版本、状态码和状态消息。其格式如下：

<HTTP协议版本> <状态码> <状态消息>

• HTTP协议版本：与请求行中的协议版本相对应。
• 状态码：一个三位数，用于表示请求的处理结果。
• 状态消息：与状态码对应的文本描述。

示例：HTTP/1.1 200 OK

状态码如下：

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

• 1xx消息——请求已被服务器接收，继续处理
• 2xx成功——请求已成功被服务器接收、理解、并接受
• 3xx重定向——需要后续操作才能完成这一请求
• 4xx请求错误——请求含有词法错误或者无法被执行
• 5xx服务器错误——服务器在处理某个正确请求时发生错误

虽然RFC 2616中已经推荐了描述状态的短语，例如"200 OK"，"404 Not Found"，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。

4.2 响应头（Response Headers）

响应头包含关于响应的元数据，同样以键值对的形式存在。这些字段提供了关于响应内容、缓存指令、服务器信息等方面的详细信息。常见的响应头字段包括：

• Content-Type：响应主体的媒体类型。
• Content-Length：响应主体的长度。
• Server：服务器软件的信息。
• Cache-Control：指定请求/响应链中所有的缓存机制必须遵守的指令。
• Expires：响应过期的时间。
• ETag：资源的特定版本的标识符，通常用于缓存。

4.3 响应体（Response Body）

响应体包含服务器返回的实际数据，如HTML页面、图片、JSON数据等。响应体的格式和内容由Content-Type头字段决定。

五、拓展

5.1 HTTP是不保存状态的协议,如何保存用户状态?

HTTP是一种不保存状态，即无状态（stateless）协议。也就是说HTTP协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session机制的存在就是为了解决这个问题，Session的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为HTTP协议是无状态的。服务端给特定的用户创建特定的Session之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个Session，过了时间限制，就会销毁这个Session）。

在服务端保存Session的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然Session存放在服务器端，那么我们如何实现Session跟踪呢？大部分情况下，我们都是通过在Cookie中附加一个Session ID来方式来跟踪。

Cookie被禁用怎么办?

最常用的就是利用URL重写把Session ID直接附加在URL路径的后面。

5.2 Cookie的作用是什么?和Session区别

Cookie和Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

• Cookie一般用来保存用户信息，比如
  1. 我们在Cookie中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
  2. 一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个Token在Cookie中，下次登录的时候只需要根据Token值来查找用户即可(为了安全考虑，重新登录一般要将Token重写)；
  3. 登录一次网站后访问网站其他页面不需要重新登录。
• Session的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为HTTP协议是无状态的。服务端给特定的用户创建特定的Session之后就可以标识这个用户并且跟踪这个用户了。

Cookie数据保存在客户端(浏览器端)，Session数据保存在服务器端。

Cookie存储在客户端中，而Session存储在服务器上，相对来说Session安全性更高。如果要在Cookie中存储一些敏感信息，不要直接写入Cookie中，最好能将Cookie信息加密然后使用到的时候再去服务器端解密。

5.3 HTTP 1.0和HTTP 1.1的主要区别

这部分回答引用这篇文章https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A?的一些内容。

HTTP 1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP 1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP 1.1也是当前使用最为广泛的HTTP协议。主要区别主要体现在：

1. 长连接: 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP1.1起，默认使用长连接，默认开启Connection：keep-alive。HTTP/1.1的持续连接有非流水线方式和流水线方式。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
2. 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 缓存处理:在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP 1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since,If-Match,If-None-Match等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用:HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

5.4 URI和URL的区别

• URI(Uniform Resource Identifier)是统一资源标志符，可以唯一标识一个资源。
• URL(Uniform Resource Locator)是统一资源定位符，可以提供该资源的路径。它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

5.5 HTTP和HTTPS的区别

1. 端口：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
2. 安全性和资源消耗：HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP安全性没有HTTPS高，但是HTTPS比HTTP耗费更多服务器资源。
   • 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
   • 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。