前端 http 协议相关

Ashy-

已于 2022-03-14 02:09:37 修改

阅读量2.6k

点赞数

分类专栏：前端面试题计算机网络文章标签：网络 http

于 2022-03-03 10:42:08 首次发布

本文链接：https://blog.csdn.net/weixin_43794299/article/details/123021560

版权

前端面试题同时被 2 个专栏收录

21 篇文章 3 订阅

订阅专栏

计算机网络

2 篇文章 0 订阅

订阅专栏

Http

万字

1. get 请求和 post 请求的区别

post 请求和 get 请求的两种方法，区别如下：

应用场景：get 请求是一个幂等请求，一般 get 请求用于对服务器资源不会产生影响的场景，比如请求一个网页的资源。而 post 不是一个幂等请求，一般用于对服务器资源会产生影响的场景，比如注册用户这一类的操作。
是否缓存：因为两者的应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 post 请求缓存。
发送报文的格式：get 请求的报文中的实体部分为空，post 请求的报文中实体部分一般为向服务器发送的数据。
安全性：get 请求可以将请求的擦书放入 url 中向服务器发送，这样的做法相对于 post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。
请求长度：浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。
参数类型：post 的参数传递支持更多的数据类型。

2. post 请求和 put 请求的区别

put 请求是向服务端发送数据，从而修改数据的内容，但是不会增加数据的种类，也就是说无论进行多少次的 put 操作，其结果并没有不同。
post 请求是向服务器发送数据，该请求会改变数据的种等资源，它会创建新的内容。

3. 常见的请求头和响应头

HTTP Request Header 常见请求头
- Accept：浏览器能处理的内容类型；
- Accept-Charset：浏览器能够显示的字符集；
- Accept-Encoding：浏览器能够处理的压缩编码；
- Accept-Language：浏览器当前设置的语言；
- Connection：浏览器与服务器之间连接的类型；
- Cookie：当前页面设置的任何 Cookie；
- Host：发出请求的页面所在的域；
- Referer：发出请求的页面所在的 URL；
- User-Agent：浏览器用户代理的字符串；
HTTP Responses Header 常见的响应头：
- Date：表示消息发送的实际，时间的藐视格式由 rfc822 定义；
- server：服务器名称；
- Connection：浏览器与服务器之间连接的类型；
- Cache-Control：控制 HTTP 缓存；
- content-type：表示后面的文档属于什么 MIME 类型；
常见的 Content-Type 属性值有以下四种:
- application/x-www-form-unlencoded：浏览器原生的 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-unlencoded 方式提交数据。该种方式提交的数据放在 body 里面，数据按照 key value 的方式进行编码，key 和 value 都进行了 URL 转码。
- multipart/from-data：post 常见的提交文件、图片时的方式，数据流格式。
- application/json：服务器消息主体是序列化后的 JSON 字符串。
- text/xml：这种方式主要用来提交 XML 格式的数据。

4. Http 状态码 304 是多好还是少好

服务器为了提高网站的访问速度，对之前访问的半部分页面指定缓存机制，当客户端在此对这些页面进行请求时，服务器会根据缓存内容判断页面与之前是否相同，若相同变直接返回 304，此时客户端调用缓存内容，不必进行二次下载。
状态码 304 不应该认为是一种错误，而是客户端有缓存服务情况下的一种服务端响应。
搜索引擎会更加青睐内容源更新频繁的网站，通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于 304 状态，那么就会降低对网站抓取此时。相反，网站频繁更新，每次抓取都能获取新内容，那么日积月累网站的回访率也会提高。

产生较多 304 状态码的原因：
- 页面更新周期长或者不更新；
- 纯静态页面或者强制静态 html；
304 状态码出现过多会造成以下问题：
- 网站快照停止；
- 收录减少；
- 权重下降。

5. 常见 HTTP 请求的方法

GET：向服务器获取数据；
POST：向实体提交到指定的资源，通常会造成服务器资源的修改；
PUT：上传文件，更新数据；
DELETE：删除服务器上的数据、对象；
HEAD：获取报文首部，与 GET 相比，不返回报文主体部分；
OPTIONS：询问支持的请求方法，用来跨域请求；
CONNECT：要求在与代理服务器通信时简历隧道，使用隧道进行 TCP 通信；
TRACE：回显服务器收到的请求，主要用于测试或诊断。

6. `options` 请求方法及使用场景

OPTIONS 是出了 get 和 post 请求之外的另一种 Http 请求的方法
OPTIONS 请求的方法设计用于获取 Request-URL 标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以 **在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。**该请求方法的响应不能缓存。
options 请求方法主要用途：
1. 获取服务器支持的所有 http 请求的方法；（询问支持请求的方法）
2. 用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂的请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有指定的资源的访问权限；

7. HTTP 1.0 和 HTTP 1.1 的区别

连接方面：http1.0 默认使用非持久连接，而 http1.1 默认使用持久连接。http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，一次来避免使用非持久连接时每次需要建立的时延。
资源请求方法：http1.0 存在一些浪费带宽的地方，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并不支持断点续传功能，http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
缓存方面：在 http1.0 中主要使用 header 里的 If-Modified-Since、Expire 来作为缓存判断的标准，http1.1 则引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策略。
http1.1 中增加了 host 字段，用来指定服务器的域名。http1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址。因此有了 host 字段，这样就可以将请求发往到同一台服务器上的不同网站。
http1.1 相对于 http1.0 还增加了很多请求的方法，如 put、HEAD、OPTIONS 等。

8. Http1.0 和 http2.0 的区别

二进制协议：HTTP/2 是一个二进制协议。在 HTTP1.1 版本中，报文头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为“帧”，可以分为头信息帧和数据帧。帧的概念是它实现多路复用的基础。
多路复用：HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 连接，但在一个连接里，客户端和服务端都可以同时发送多个骑牛或回应，而且不用按照顺序一一发送，这样就避免了“队头堵塞”的问题。
数据流：HTTP/2 实现了数据流的概念，因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包可能属于不用的请求。因此，必须要对数据包做标记，指出它属于哪个请求。HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。每一个数据流都有一个独一无二的编号。数据包发送时，都必须标记数据流 ID，用来区分它属于哪个数据流。
头信息压缩：HTTP/2 实现了头信息压缩，由于 HTTP 1.1 协议不呆状态，每次请求都必须附上所有信息。所以请求的很多字段都是重复的，比如 Cookie 和 User Agent，同样的内容每次请求都会附带，这会浪费很多贷款，也影响速度。HTTP/2 对这一点做了优化引入了头信息压缩机制。一方面头信息使用 gzip 或 compress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有的字段都会存入这个表，生成一个索引好，以后就不发送同样的字段了，只发送索引号，这样就能提高速度了。
服务器推送：HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做度武器推送。使用服务器推送提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。这里需要注意的是 HTTP/2 下度武器主动推送的是静态资源，和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。

队头堵塞： 队头堵塞是由 HTTP 基本的 “请求-应答” 模型所导致的。Http规定报文必须是 “一发一收”，这就形成了一个先进先出的 “串行” 队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。

9. HTTP 和 HTTPS 协议的区别

HTTPS 协议需要 CA 证书，费用较高；而 HTTP 协议不需要；
HTTP 协议是超文本传输协议，信息是明文传输的，HTTPS 则是具有安全性的 SSL 加密传输协议；
使用不同的连接方式，端口也不同，HTTP 协议端口是 80，HTTPS 协议端口是 443；
HTTP 协议连接很简单，是无状态的；HTTPS 协议是有 SSL 和 HTTP 协议构建的可进行加密传输、身份认证的网络协议、比 HTTP 更加安全。

公开密钥加密：对称加密。
公有/私有密钥加密：非对称加密（SSL协议）。
混合加密：公有密钥加密公开密钥，然后通过公开密钥传输：
混合加密在安全性和处理速度上都有优势。能够为网络通信提供安全的 SSL 协议也应用了混合加密的方法。SSL 是 Secure Sockets Layer（安全套接层） 的简写，该协议经过版本升级后，现在正是命名为 TLS（Transport Layer Security，传输层安全） 。但是，SSL 这个名字已经深入人心，银川该协议现在也常被称为 SSL协议或者 SSL/TLS 协议。

10. GET 方法 URL 长度限制的原因

实际上 http 协议规范中并没有对 get 方法请求的 url 长度进行限制，这个限制是特定浏览器及服务器对它的现在限制。😊😊😊😊
IE 对 URL 长度的限制是 2083字节（2K+35）。由于 IE 浏览器对 URL 的最大限制为 2083个字符，如果超过这个数字，提交按钮会没有反应。

11. 浏览器输入地址以后到页面渲染的过程？

解析 URL：首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。如果 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则会转义后再进行下一过程。
缓存判断：浏览器会判断所请求的资源是都在缓存里，如果请求的资源在缓存里并没有失败，那么久直接使用，否则向服务器发情期新的请求。（304状态码）
DNS 解析：首先需要获取的是输入 URL 中的域名的 IP 地址，首先会判断本地是都有该域名的 IP 地址的缓存，如果没有就会向本地 DNS 服务器发起请求，本地 DNS 也会先检查是否存在缓存，如果没有就会向根域名服务器发起请求，获得负责的顶级域名服务器地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名 IP 地址后，本地 DNS 服务器再将这个 IP 地址发给用户。用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。
获取 MAC 地址：当浏览器获取到 IP 地址以后，数据传输还需要知道目标主机的 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求数集在同一个子网，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以用过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关地址。
TCP 三次握手：首先客户端向服务端发送一个 SYN 连接请求报文段和一个随机序号，服务端接受到请求后向服务器端发送一个 SYN ACK 报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器确认应答后，进入连接建立的状态，同时向服务器也发送一个 ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。
HTTPS 握手：如果使用的是 HTTPS 协议，在通信前还存在一个 TSL 的一个四次握手的过程。首先由客户端向服务端发送使用的协议的版本号、一个随机数和可以使用的加密方法。服务器收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数并使用证书中的公钥对随机数加密，同时向客户端发送一个前面所有内容的 hash 值供客户检验。这时候双方都有了三个随机数，按照之前约定的方法，使用者三个随机数生成一把密钥，以后双方通信，就使用这个密钥对数据进行加密后再传输。
返回数据：页面请求发送到服务器后，服务器会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。
页面渲染：浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判断是否含有 defer 或者 async 属性，有则同步执行代码，否则异步执行。当 DOM 树和 CSSOM 树建立好以后，根据它们来构建渲染树。渲染树构建好以后，会根据渲染树来进行布局。布局完成后，浏览器的 UI 接口会对页面进行绘制。这个时候整个页面就显示出来了。
TCP 四次挥手：最后一步是 TCP 四次挥手，若客户端认为数据发送完成，则它需要向服务器发送连接释放请求。服务端收到连接释放请求以后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还没有发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入了 LAST-ACK 状态。客户端收到释放的请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，报文在网络中的生存时间，超时会被抛弃）时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，就会进入 CLOSED 状态。

12. 对 keep-alive 的理解

HTTP1.0 中默认在每次请求或应答时，客户端和服务端都要新建一个连接，完成之后立即断开连接，这就是短连接。当使用 Keep-alive 模式时，Keep-alive 功能使客户端到服务端的连接持续有效，当出现对服务器的后继请求时，Keep-alive 功能避免了建立或者新建连接，这就是长连接。

HTTP1.0 版本是默认没有 Keep-alive 的（也就是默认会发送 keep-alive），所以要想连接得到保持，必须手动配置发送 Connection: keep-alive 字段。若想断开 keep-alive 连接，需要发送 Connection: close 字段；
HTTP1.1 规定了默认保持长连接，数据传输完成后保持 TCP 连接不断开，等待在同域名下继续使用这个传输通道传输数据。如果需要关闭，需要客户端发送 Connection: close 字段。
Keep-Alive 的建立过程：
- 客户端向服务器在发送请求报文同时在首部发送 Connection 字段；
- 服务器在收到请求并处理 Connection 字段；
- 服务器回送 Connection: Keep-Alive 字段给客户端；
- 客户端收到 Connection 字段；
- Keep-Alive 连接建立成功。
服务端自动断开过程（也就是没有 keep-alive）：
- 客户端向服务端只是发送内容报文（不包含 Connection 字段）；
- 服务器收到请求并处理；
- 服务器返回客户端请求的资源并关闭连接；
- 客户端接收资源，发现没有 Connection 字段，断开连接。
客户端请求断开连接过程
- 客户端向服务器发送 Connection: close 字段；
- 服务器收到并处理 connection 字段；
- 服务器回送响应资源并断开连接；
- 客户端接收资源并断开连接。
开启 keep-alive 的优缺点：
- 较少的 CPU 和内存使用（因为同时打开的连接资源数减少了）；
- 允许请求和应答的 HTTP 管线化；
- 降低拥塞控制（TCP 连接减少了）；
- 减少了后续请求的延迟（无需再进行握手）；
- 报告错误无需关闭 TCP 连接；
开启 keep-alive 的缺点：
- 长时间的 TCP 连接容易导致系统资源无效占用，浪费系统资源。

13. 页面有多张图片， HTTP 是如何加载表现的？

在 HTTP1 下，浏览器对一个域名下最大 TCP 连接数为 6，所以会请求多次。可以用多域名部署解决。这样可以提高同时请求的数目，加快页面图片的获取速度。
在 HTTP2 下，可以一瞬间加载出来很多资源，因为 HTTP 2 支持多路复用，可以在一个 TCP 连接中发送多个 HTTP 请求。

14. HTTP2 的头部压缩算法？

HTTP2 的头部压缩是 HPACK 算法。在客户端和服务器两端建立字典，用索引表示重复的字符串，采用哈夫曼编码来叶索整数和字符串，可以达到 50%~90%的高压缩率。

在客户端和服务器端使用 “首部表” 来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送；
首部表在 HTTP/2 的连接存续期内始终存在，由客户端和服务器端共同渐进地更新；
每个新的首部键值对要么被追加到当前表的末尾，要么替换表中国之前的值。

15. HTTP 请求报文是什么样的？

请求报文有 4 部分组成：

请求行
请求头
空行
请求体

请求行包括：请求方法字段、URL 字段、HTTP 协议版本字段。他们分别用空格分隔。例如：GET /index.html HTTP/1.1。
请求头部：请求头部由键/值对组成，每行一对，关键字和值用英文冒号 “:” 分隔。

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

请求体：post、put 等请求携带的数据

16. HTTP 响应报文是什么样的？

请求报文有 4部分组成：

响应行：由网络协议版本，状态码和状态码的原因短语信息组成：HTTP/1.1 200 OK。
响应头：响应部首组成；
空行
响应体：服务器响应的数据。

17. HTTP 协议的优点和缺点

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传输层协议，保证了数据传输的可靠性。
HTTP 协议具有以下优点：

支持客户端/服务器模式（C/S）；
简单快速：客户向服务器请求服务时，只需要传送请求方法和路径。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
无连接：无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。
无状态：无状态就是限制每一次连接都只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。
灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。

缺点：

无状态：HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。
明文传输：协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。
不安全：
1. 使用明文（不加密），内容可能会被窃听；
2. 不验证通信方的身份，因此有可能遭遇伪装；
3. 无法证明报文的完整性，所以有可能已遭篡改；

18. HTTP 3.0

HTTP/3 是基于 UDP 协议实现了类似于 TCP 的多路复用数据流、传输可靠性等功能，这套功能被称为 QUIC 协议。

流量控制、传输可靠性功能：QUIC 在 UDP 的基础上增加了一层来保证数据传输可靠性，它提供了数据包重传、拥塞控制、以及其他一些 TCP 中的特性。
集成 TSL 加密功能：目前 QUIC 使用 TSL1.3，减少了握手所花费的 RTT 数；
多路复用：同一物理连接上可以有多个独立的逻辑数据流，实现了数据流的单独传输，解决了 TCP 的队头堵塞问题；
快速握手：由于基于 UDP，可以实现使用 0~1 个 RTT 来建立连接。

19. HTTP 协议的性能怎么样

HTTP 协议是基于 TCP/IP，并且使用了 请求-应答 的通信模式，所以性能的关键就在这两点。
长连接：

HTTP 协议有两种连接模式：一种是持续连接，一种是非持续连接。
1. 非持续简介指的是服务器必须为每一个请求的对象建立和维护一个全新的连接。
2. 持续连接下，TCP 连接默认不关闭，可以被多个请求复用。采用持续连接的好用是可以避免每次建立连接时的 TCP三次握手时所花费的时间。
对于不同版本采用不同的连接方式：
1. 在 HTTP/1.0 中每发起一个请求，都要新建一次 TCP连接（三次握手），而且是串行请求，做了无畏的 TCP 断开和建立，增加了通信的开销。该版本使用非持续的连接，但是可以在请求时，加上 Connection: keep-alive 来要求服务不要关闭 TCP 连接。
2. 在 HTTP/1.1 提出了**长连接（keep-alive）**的通信方式，也叫持久连接。这种连接方式的好处在于减少了 TCP 的重复建立和断开造成的额外开销，减轻了服务器端的负载。该版本及以后版本默认采用的是持续的连接。目前对同一个域，大多数浏览器支持同时建立 6 个持久连接。

队头堵塞
HTTP 传输的报文必须是一发一收，但是，里面的任务被放在一个任务队列中串行执行，一旦队首的请求处理太慢，就会阻塞后面请求的处理。这就是 HTTP 队头阻塞的问题。

解决方案：
1. 并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其他所有任务。
2. 域名分片：将域名分出很多二级域名，它们都指向同样一台服务器，并且能后并发的长连接数变多，解决了队头堵塞的问题。

20. URL 有哪些组成部分

例如：https://search.bilibili.com/all?keyword=JOJO%E7%9A%84%E5%A5%87%E5%A6%99%E5%86%92%E9%99%A9&from_source=webtop_search&spm_id_from=666.25

协议部分：https:；在 Internet 中可以使用多种协议，如 HTTP，FTP 等等使用的都是 HTTP 协议。在 “http” 后面的 “//” 为分隔符；此外就是 http；
域名部分：search.bilibili.com；即 “//” 之后的 URL ，当然也可以使用 IP 地址作为域名使用；
端口部分：443；跟在域名后面的是端口，域名和端口直接使用 “:” 作为分隔符。端口不是一个 URL 必须的部分，如果省略，将采用默认的端口（http 为 80，https 为 443）；
虚拟目录部分：；从域名后的第一个 “/” 开始到到 “/” 为止，虚拟目录不是 URL 必须的部分。
文件名部分：all；从域名后的第一个 “/” 开始到到 “?” 为止，如果没有 “?”，则是从第一个 “/” 开始到 “#” 为止是文件部分。文件名部分也不是 URL 中必须的部分，如果省略该部分，则使用默认的文件名；
锚部分：从 “#” 开始到最后。锚部分也不是必须的；
参数部分：keyword=JOJO%E7%9A%84%E5%A5%87%E5%A6%99%E5%86%92%E9%99%A9&from_source=webtop_search&spm_id_from=666.25；从 “?” 开始到 “#” 之间的部分，又称搜索部分、查询部分，参数可以有多个，参数与参数之间用 “&” 作为分隔符。