网络请求响应

更新: 2025/2/24 字数: 0 字 时长: 0 分钟

网络请求响应是互联网通信的核心机制，几乎所有的网络交互都遵循这种请求-响应模式，这种模式包含两部分内容：一部分是“网络请求”，指的是客户端向服务端发送的请求；另一部分是“网络响应”，指的是服务端向客户端返回的响应。

功能异同

一个基本的爬虫通常包含三大功能：

1. 请求响应：向服务端发起请求获取包含数据的响应（通过第三方库或爬虫框架完成）。
2. 提取信息：从服务端返回的响应中提取出有价值的信息（通过正则或解析库来完成）。
3. 保存数据：将提取出来的信息进行持久化保存（通过文件或数据库完成）。

其中最重要的功能当属“获取响应”了，如果没有“获取响应”，就更无从谈“提取信息”和“保存数据”了。在”获取数据”的功能中又包括了“发送请求”和“接收响应”两部分内容。

相似性

对技术敏感的同学可能已经发现，爬虫的功能和浏览器的功能很像。比如：

• 爬虫请求服务端获取响应数据，相当于人在浏览器中输入网址请求网页。
• 从响应数据中筛选出有效数据，相当于人在网页中寻找有用的信息。
• 将有效数据永久保存到硬盘中，相当于人将网页中的内容保存到本地磁盘。

差异性

不过爬虫和浏览器之间还是有些差异，主要为以下几点：

• 爬虫由代码控制，而浏览器可以由人控制，也可以由代码控制。
• 爬虫的自动化效率远高于浏览器的人工效率。
• 网络上常见的 HTML 网页中基本都会引用其他的资源（例如，JavaScript 脚本，CSS 样式，图片等），爬虫在在爬取网页的过程，是不会再去请求网页所引用的这些资源，而浏览器则会自动去请求网页引用的资源。下图的资源列表中展示了浏览器所请求的 HTML 网页以及网页中引用的资源，其中第一行也就是最先请求和响应的是网页的 HTML 文件，浏览器在解析的过程中发现 HTML 文件还引用了 20200630.css 这个 CSS 文件，于是浏览器接着向服务器请求并获取了该文件，浏览器在解析的过程中又发现 CSS 文件还引用了其他的图片资源（例如 png、jpg、gif），于是乎浏览器又接着向服务器请求并获取这些图片资源。

发送请求

网络上的资源文件（如 HTML、CSS、JS、图片等）通常都是存放在服务端上面的，客户端想要获取这些资源文件，就必须通过 HTTP 或 HTTPS 协议向服务端发起网络 HTTP 请求，请求主要包含四部分：网络地址、请求方法、请求头、请求体。

网络地址

在网络上，每项信息资源都有一个唯一的统一资源定位符，英文全称 Universal Resource Locator，缩写 URL，中文全称“网络地址”，简称“网址”。通过 URL 我们可以在网络中快速定位到具体的某项信息资源，例如，我们通过浏览器访问 https://bkimg.cdn.bcebos.com/pic/3c6d55fbb2fb43165346a4c32ea4462309f7d32a 这个 URL，就能看到下面这副蜡笔小新图片：

那么如何查看 HTTP 请求的 URL 呢？以 Chrome 浏览器的开发者工具为例，查看 URL 的步骤如下：打开开发者工具——选择 Network 选项卡——刷新网页——出现数据包列表——点击任意一个数据包——点击 Headers 选项卡——General——Request URL（请求的 URL）

形成过程

一个 URL 的形成过程大体分为下面三个步骤：

• 资源路由：一般网页的资源文件（如 HTML、CSS、JS、图片等）都存放在服务端上面，那么资源文件在服务端中必定对应一个路径位置。例如，/var/www/index.html 就表示存放在根目录中的 var 文件夹下的 www 文件夹下的 index.html 网页文件，其可能对应网址的根路径 / 下的 index.html 网页文件。

• 地址端口：服务端挂起了后台服务，并且打开了相应的端口，那么其他人就可以通过网络地址，请求到该网页数据。例如，服务端挂起了后台服务，它的公网地址为 10.10.10.10，开放的端口为 8888，那么网络上的其他人就可以通过 http://10.10.10.10:8888/index.html 这个 URL 访问到服务端中的 index.html 网页文件。

• 域名映射：一般的网站都会购买域名来和服务端的公网IP做映射，那么其他人就可以通过域名，请求到该网页数据。例如，公司购买了一个 nixiang.com 的域名同公司的服务端IP进行映射，那么网络上的其他人就可以通过 http://www.nixiang.com/index.html 这个 URL 访问到服务端中的 index.html 网页文件。

这样客户端请求服务端的流程就很好理解了，客户端首先会向 URL 发送请求，如果 URL 中包含域名，那么请求会先来到 DNS（域名服务器），DNS 会先将 URL 中的域名映射为 IP 地址，再通过 IP 地址找到目标服务端，目标服务端接收到请求后，根据 URL 中所包含的文件路径，返回该路径下的网页文件给客户端。

地址操作

一个标准的 URL 由 6 部分组成，每部分的含义如下：

scheme://netloc/path;params?query#fragment
- scheme 协议（例如http或https等）
- netloc 域名
- path 访问路径
- params 参数
- query 查询条件
- fragment 锚点

利用 Python 内置的 HTTP 请求库 Urllib 中 parse 工具模块自带的一些方法，我们可以很方便的对 URL 进行解析、组合、加参等操作，具体代码如下：

urlparse 解析

from urllib.parse import urlparse

# URL拆分为6个部分，没有内容的部分，返回空字符串。
url = 'https://www.baidu.com/index.html;user?id=5#comment'
result = urlparse(url)
print(result)           # 输出：ParseResult(scheme='https', netloc='www.baidu.com', path='/index.html', params='user', query='id=5', fragment='comment')
print(result.scheme)    # 输出：https
print(result.netloc)    # 输出：www.baidu.com
print(result.path)      # 输出：/index.html
print(result.params)    # 输出：user
print(result.query)     # 输出：id=5
print(result.fragment)  # 输出：comment

urlunparse 组合

from urllib.parse import urlunparse

# URL组合必须是6个部分参数，没有内容的部分，传入空字符串。
data = ['https', 'www.baidu.com', 'index.html', 'user', 'a=6', 'comment']
result = urlunparse(data)
print(result)  # 输出：https://www.baidu.com/index.html;user?a=6#comment

urlencode 加参

from urllib.parse import urlencode

# URL加参将字典格式参数转为URL格式的参数
params = {
    "nPageIndex": "1",
    "nPageCount": "0",
    "nPageSize": "20",
}
url = f"https://cx.xxx.com/NewHandler.ashx?{urlencode(params)}"
print(url)  # 输出：https://cx.xxx.com/NewHandler.ashx?nPageIndex=1&nPageCount=0&nPageSize=20

请求方法

客户端可以向服务端发送多种不同方法的 HTTP 请求，每种 HTTP 请求方法都有特定的用途，具体用途解释如下：

那么如何查看 HTTP 请求方法呢？以 Chrome 浏览器的开发者工具为例，查看 HTTP 请求方法的步骤如下：打开开发者工具——选择 Network 选项卡——刷新网页——出现数据包列表——点击任意一个数据包——点击 Headers 选项卡——General——Request Method（请求方法）

上述所有的 HTTP 请求方法中，常用的就是 GET 请求、POST 请求，也是我们要重点掌握的请求方法，因为后面所有的爬虫案例都是围绕着这两种请求方法来展开。关于这两种请求方法的解释如下：

• GET 请求：URL 中可以包含请求的参数，参数以键值对的形式跟在一个 ? 问号后面，参数与参数之间以 & 符号相连，参数长度最大只有1024字节。例如，在 https://httpbin.org/get?name=germey&age=22 这个 URL 中传递的参数部分是 name=germey&age=22，它指定了 name 是 germey，age 是 22。

• POST 请求：URL 中不会包含请求的参数，参数是一般通过表单提交，参数长度没有大小限制。例如，用户登录就是用的 POST 请求，如果使用 GET 请求，那么账号、密码就会全部暴露在 URL 当中。另外，上传文件时，由于文件内容比较大，也会使用 POST 请求。

提醒

在浏览器中输入一个网址并按下回车键的那一刻，其实就向网站的服务器发送了一个 GET 请求。

请求头

请求头（Request Headers）是客户端向服务端发起 HTTP 请求中传递的头部数据，用于向服务端提供客户端的额外信息。那么如何查看请求头呢？以 Chrome 浏览器的开发者工具为例，查看请求头的步骤如下：打开开发者工具——选择 Network 选项卡——刷新网页——出现数据包列表——点击任意一个数据包——点击 Headers 选项卡——Request Headers（请求头）

上面图中的请求头包含许多键值对，用来指定客户端的能力、请求的内容类型、身份验证信息、用户代理信息等。下面我们对一些常见的请求头参数进行解释说明，具体如下：

• Accept：客户端可接受的内容类型。比如，文本、图片等内容的先后排序表示客户端接收的先后次序，每种类型之间用逗号隔开，每种类型在分号 ; 后面会加⼀个权重 q 值，表示被客户端接受的期望程度，数值越高，客户端对接受这种类型的期望程度越高。另外，没有权重 q 值，则表示 q 值等于 1。

  Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

  • text/xml 接收 xml 文档的文本类型，没有权重 q 值，默认为 1。
  • application/xhtml+xml 接收 xhtml+xml 文档的应用类型的，没有权重 q 值，默认为 1。
  • application/xml;q=0.9 接收 xml 文档的应用类型，权重 q 值为 0.9。
  • image/webp 接收 webp 格式的图像类型，没有权重 q 值，默认为 1。
  • image/apng 接收 apng 格式的图片类型，没有权重 q 值，默认为 1。
  • */*;q=0.8 接收任何类型，权重 q 值为 0.8。
  • application/signed-exchange;v=b3;q=0.9 返回头不能根据请求头动态改变，权重 q 值为 0.9。

• Accept-Encoding：客户端支持的解码类型。当客户端向服务端发送请求时，如果请求头中添加了该字段，则就是在告诉服务端，客户端可以处理的几种不同压缩格式的响应内容。这时服务端会根据该字段选择它所支持的编码方式对响应内容进行压缩，客户端收到压缩内容后对其解码即可获得原始的响应内容。

  Accept-Encoding: gzip, deflate

  • gzip 是 GNU zip 的缩写，它是一个 GNU 自由软件的文件压缩程序，也经常用来表示 gzip 压缩文件格式，也是现在常用的网络压缩格式。
  • deflate 是一种同时使用了 LZ77 算法与哈夫曼编码（Huffman Coding）的无损数据压缩算法，是⼀种过时的网络压缩格式。

建议

使用 Accept-Encoding 字段的好处就是，在传输较大的 HTML 页面或 JSON 数据时，能节省带宽。另外，较小的数据量可以更快地通过网络传输，从而加快请求的整体响应时间，尤其在网络延迟较高的环境下（这些好处也适用于爬虫）。

• Accept-Language：客户端可接受语言类型，也拥有权重 q 值。

  Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4

  • zh-CN 简体中文，没有权重 q 值，默认为 1。
  • zh;q=0.8 其他中文，权重 q 值为 0.8。
  • en-US;q=0.6 美式英语，权重 q 值为 0.6。
  • en;q=0.4 其他英语，权重 q 值为 0.4。

• Accept-Charset：客户端可接受的字符集类型。⼀般接收 UTF-8（万国码），也拥有权重 q 值。若没有定义，则默认值为 unknown。

  Accept-Charset: gb2312,gbk;q=0.7,utf-8;q=0.7,*;q=0.7

  • gb2312 字符编码为 GB2312。
  • gbk;q=0.7 字符编码为 GBK，权重 q 值为 0.7。
  • utf-8;q=0.7 字符编码为 UTF-8，权重 q 值为 0.7。
  • *;q=0.7 所有的字符编码，权重 q 值为 0.7。

• Cache-Control：缓存控制，指定了客户端和服务端在交互时的缓存机制，即是否要保留缓存页面数据。在使用缓存的情况下，用浏览器访问网站时，会将网页缓存在本地计算机中，当短时间内再次访问网站时，就可能直接加载缓存的网页，而不去请求服务端，以提升用户使用体验。

  Cache-Control: no-cache、no-store、max-age=0

  • no-cache 客户端告诉服务端不读取缓存，只向服务端发起请求。
  • no-store 请求和响应都禁止缓存，即不存储。
  • max-age=0 当访问过此网页后的 0 秒内再次访问，只加载缓存，而不去请求服务端。

建议

爬虫几乎不会从缓存中读取数据，这是因为爬虫需要保证数据的及时性，所以每次采集的都是请求服务端所返回的最新数据。因此在设置 Cache-Control 字段时，要侧重从服务端请求数据，而非加载缓存。上述几个参数都是不加载缓存的，一般爬虫就使用这几个，还有其他的参数都是接受缓存的，就不一一列出了。

• Connection：长连接管理。在客户端与服务端进行通信时，所发送和接受的都是 HTTP 请求/响应，而传输 HTTP 请求/响应的通道是客户端与服务端在通信之前通过 TCP 协议的三次握手建立的 TCP 连接。由于 HTTP 协议是基于请求/响应模式的，只要服务端给了 HTTP 响应，本次通信就结束了。不过 TCP 连接本身不会因为通信的结束而立即关闭，而是保持一段时间的连接状态，这个保持时间由服务端决定（例如，Nginx 的默认保持时间是 75 秒）。在保持时间内，如果需要发送新的 HTTP 请求，客户端与服务端就会复用前面已经建立的 TCP 连接。如果没有需要发送的 HTTP 请求，客户端与服务端就会通过 TCP 协议中四次挥手来关闭 TCP 连接。

  Connection: keep-alive、close

  • keep-alive 客户端希望与服务端保持长连接，即在接收 HTTP 响应后，TCP 连接不会立即关闭。当发送下一个 HTTP 请求时，就可以复用同一个 TCP 连接，避免了每次请求都重新建立 TCP 连接的开销，还减少网络延迟，提高了性能，这在高并发场景中尤为重要（HTTP/1.1 默认支持长连接，因此 keep-alive 在 HTTP/1.1 中是默认选项，除非明确设置 close，否则连接会保持活跃）。
  • close 客户端不希望与服务端保持长连接，即在客户端收到服务端 HTTP 响应后立即关闭 TCP 连接，不进行复用。如果后续需要发送 HTTP 请求，就必须重新进行三次握手来建立 TCP 连接。

提醒

Connection 字段还有一个值是 Upgrade，它表示客户端想将与服务端建立的 TCP 连接升级为 WebSocket 连接，这个会在后面讲到。

重要

Connection 字段需要根据具体的情况进行设置。在不使用代理的情况下，指定 keep-alive 复用 TCP 连接可以显著减少资源消耗和延迟，特别是对于频繁请求同一服务端的爬虫。在使用代理的情况下，则需要指定 close 来关闭长连接，以避免连接失败等问题，这是由于代理服务端通常会限制 TCP 连接的通道数，当代理服务端保持的 TCP 连接达到上限时，就无法与任何服务端建立 TCP 连接了，这时爬虫也就无法抓取数据了。另外，爬虫在请求时默认不会主动复用 TCP 长连接，只有使用 requests.Session 时才会自动复用 TCP 连接，不然下一次访问还是会重新建立 TCP 连接。

• Cookie：服务端给予客户端用户的一个临时身份标识（时效性）。客户端初次请求服务端时，服务端会返回的一个键值对样的 Cookie 给客户端，下一次客户端再访问这个域名下的网页时，就会在请求头中携带 Cookie，这样服务端就能清楚判别这个客户端是否是新访问的用户。

  Cookie: acw_tc=d79d16; JSESSIONID=D757C5F;

  • acw_tc 字段在Cookie中的值为 d79d16。
  • JSESSIONID 字段在Cookie中的值为 D757C5F。

建议

在写爬虫时，如果网站不需要登录，没有签名，也没有任何权限的问题，那么请求头中 Cookie 就不是一个关键字段，否则 Cookie 就是一个关键字段。另外，并不是每个网站都会返回 Cookie，就算返回 Cookie 也并不一定会对 Cookie 进行验证，但需要登录的网站基本都会验证 Cookie，特别是银行网站，只要短时间没有操作就会让你重新登录，这其实就是安全性与便捷性之间的一种平衡。

• Host：服务端网站域名。

  Host: www.主机域名.com

• Referer：上一层网页的 URL。由于 HTTP 协议的无记忆性，服务端可从这里了解到请求访问的前后路径，并做一些判断，如果当前访问的 URL 不能从前一次访问的页面上获得， 在一定程度上说明了请求头有伪造可能，常用于防盗链，极个别爬虫需要加上该参数。

  Referer: https://www.上一层网页URL.com?...

• Authorization：当浏览器接收到来自服务端的 WWW-Authenticate 响应时，回应自己的身份验证信息给服务端，确定符合服务端的要求。

  'Authorization': 'Basic dLVsdDp0ZSN1QDIsMjP='

提醒

在访问公司内部资源时，就需要 Authorization 授权验证，验证的值可以在爬虫项目中找到或者由运维提供。

• Content-Type：请求中的媒体类型信息。

  Content-Type: text/html、image/gif、application/json

  • text/html 代表 HTML 格式。
  • image/gif 代表 GIF 图片。
  • application/json 代表 JSON 类型。

• User-Agent：浏览器用户代理，里面包含了客户端的操作系统类型和版本、电脑 CPU 类型、浏览器种类版本、浏览器渲染引擎等信息。

  User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

  • Mozilla/5.0 (Windows NT 6.3; WOW64) 浏览器 Mozilla 版本 5.0。
  • AppleWebKit/537.36 (KHTML, like Gecko) 浏览器 AppleWebKit 版本 537.36。
  • Chrome/52.0.2743.116 浏览器 Chrome 版本 52.0.2743.11。
  • Safari/537.36 浏览器 Safari 版本 537.36。

重要

User-Agent 是请求头中非常重要的一个字段，当我们使用浏览器时，浏览器就会自动在请求头中添加该字段，并附带浏览器的一些信息。因此，许多服务端都会检测该字段的信息，以此来判断客户端是否是浏览器。如果爬虫的请求头没有此字段，就很容易被服务端识别并封禁。所以，我们在开发爬虫时一定要添加 User-Agent 字段，将其伪装成浏览器进行访问，以避免服务端的检测封禁。

请求体

请求体（Request Body） 是 HTTP 请求的一部分，通常用于在 POST 方法中携带数据到服务器。在 GET 请求中，通常不包含请求体或者说请求体为空。那么如何查看请求体呢？以 Chrome 浏览器的开发者工具为例，查看请求体的步骤如下：打开开发者工具——选择 Network 选项卡——刷新网页——出现数据包列表——点击 POST 请求的数据包——点击 payload 选项卡——Form Data（表单数据，请求体）

建议

在 POST 请求的请求头中出现 Content-Type: application/x-www-form-urlencoded，说明请求参数是以表单的形式进行提交。

接收响应

客户端和服务端之间的 HTTP 通信是基于 HTTP 协议的请求/响应模式，当客户端将 HTTP 请求发送给服务端后，服务端就会返回其对应的 HTTP 响应，响应主要包含三部分：状态码、响应头、响应体。

状态码

状态码（Status Code）就是表示服务端响应状态的三位数字代码，这样客户端只需通过状态码就可以判断出服务端发生了什么情况。那么如何查看状态码呢？以 Chrome 浏览器的开发者工具为例，查看请求头的步骤如下：打开开发者工具——选择 Network 选项卡——刷新网页——出现数据包列表——点击任意一个数据包——点击 Headers 选项卡——General——Status Code（状态码）

状态码按首位数字分成五个类别，共包含一百多种状态码，每一种状态码都有标准或约定的解释。常见的状态码及解释如下：

• 1xx：信息响应代码，表示服务端正在处理已经收到的请求。

  • 100 Continue 客户端应继续其请求。
  • 101 Switching Protocols 服务端已经理解并接受了客户端的请求，将切换协议。
  • 102 Processing 服务端正在处理请求，但尚未完成处理。
  • 103 Early Hints 服务端可以发送响应头，这有助于客户端在等待响应体的同时开始准备处理响应。

• 2xx：成功响应代码，表示服务端成功接收、理解并处理了请求。

  • 200 OK 服务端成功处理了请求。
  • 201 Created 请求已经成功处理，并创建了新的资源。
  • 202 Accepted 请求已经被接受，但是尚未被处理完成。
  • 203 Non-Authoritative Information 服务端成功处理了请求，但是返回的信息来自第三方服务端。
  • 204 No Content 请求已经成功处理，但是没有返回任何内容。
  • 205 Reset Content 请求已经成功处理，但是需要客户端重置视图。

• 3xx：重定向响应代码，客户端必须采取进一步的操作才能完成请求。

  • 300 Multiple Choices 请求有多个响应可供选择，客户端可以从中选择一个。
  • 301 Moved Permanently 请求的资源已经永久移动到新位置。
  • 302 Move Temporarily 请求的资源已经临时移动到新位置。
  • 303 See Other 请求的资源可在不同的 URI 下被找到。
  • 304 Not Modified 资源未被修改，客户端可以使用缓存的版本。
  • 305 Use Proxy 请求必须通过代理访问。
  • 307 Temporary Redirect 请求的资源已临时移动到新位置。

• 4xx：客户端错误响应代码，表示客户端在请求中出现了错误。

  • 400 Bad Request 服务端不理解客户端的请求，未做任何处理。
  • 401 Unauthorized 用户未提供身份验证凭据，或者没有通过身份验证。
  • 403 Forbidden 用户通过了身份验证，但是不具有访问资源所需的权限。
  • 404 Not Found 所请求的资源不存在，或不可用。
  • 405 Method Not Allowed 用户已经通过身份验证，但是所用的 HTTP 方法不在他的权限之内。
  • 409 Conflict 请求与资源的当前状态冲突。
  • 410 Gone 所请求的资源已从这个地址转移，不再可用。
  • 415 Unsupported Media Type 客户端要求的返回格式不支持。
  • 422 Unprocessable Entity 客户端上传的附件无法处理，导致请求失败。
  • 429 Too Many Requests 客户端的请求次数超过限额。

• 5xx：服务端错误响应代码，表示服务端在处理请求时发生了错误。

  • 500 Internal Server Error 客户端请求有效，服务端处理时发生了意外，无法完成请求。
  • 502 Bad Gateway 服务端充当网关或代理时收到无效响应。
  • 503 Service Unavailable 服务端无法处理请求，一般用于网站维护状态。
  • 504 Gateway Timeout 服务端充当网关或代理时，未及时从上游服务端收到请求。
  • 507 Insufficient Storage 服务端无法存储完成请求所必需的数据。
  • 508 Loop Detected 服务端在处理请求时检测到无限循环。
  • 511 Network Authentication Required 客户端需要进行身份验证才能访问网络。

响应头

响应头（Response Headers）是服务端向客户端返回 HTTP 响应中传递的头部数据，用于向客户端提供服务端的额外信息。那么如何查看请求头呢？以 Chrome 浏览器的开发者工具为例，查看请求头的步骤如下：打开开发者工具——选择 Network 选项卡——刷新网页——出现数据包列表——点击任意一个数据包——点击 Headers 选项卡——Response Headers（响应头）

上面图中的响应头包含许多键值对，用来展示服务端的系统、缓存控制、返回的内容编码、内容长度类型等。下面我们对一些常见的响应头参数进行解释说明，具体如下：

• Cache-Control：缓存控制，指定了服务端和客户端在交互时遵循的缓存机制，即是否要保留缓存页面数据。

  Cache-Control: private

• Content-Encoding：响应内容的编码。

  Content-Encoding: gzip、deflate、br、identity

  • gzip 响应的内容是 GZIP 压缩后的数据。
  • deflate 响应的内容是 DEFLATE 压缩后的数据。
  • br 响应的内容是 Brotli 压缩后的数据。
  • identity 响应的内容是原始未压缩的数据。

• Content-Length：响应体的数据大小。

  Content-Length: 5571

• Content-Type：响应内容的类型及编码。

  Content-Type: text/html; charset=gb2312;

  • text/html; charset=gb2312; 响应 html 文档，字符编码集为 gb2312。
  • image/jpeg 代表返回图片。
  • application/x-javascript 返回 JavaScript 文件。

• Date：响应时间（北京时间在时区上位于东八区，因此换算成北京时间还需要加上八个小时）。

  Date: Sat, 18 Jan 2020 14:40:05 GMT

• Server：服务端的一些信息，包括系统、版本号等。

  Server: Microsoft-IIS/8.5

• Set-Cookie：设置客户端的 Cookie，当客户端下次请求需要将此内容放在请求头中的 Cookie 字段中。对于有身份验证的网站来说，这是一个十分重要的字段。

  Set-Cookie: JSESSIONID=aaa_X8RQxJsDkhUTK3anz; path=/

• Vary：用来告诉客户端和缓存服务器，针对请求中某些特定的头部值，服务器可能返回不同的响应。

  Vary: Accept-Encoding

• Last-Modified：指定资源的最后修改时间。

• Expires：指定响应的过期时间，将内容更新到缓存中，再次访问时，直接从缓存中加载，降低服务端负载，缩短加载时间。

响应体

响应体（Response Body）是服务端向客户端返回 HTTP 响应中携带实际数据的部分。那么如何查看请求头呢？以 Chrome 浏览器的开发者工具为例，查看请求头的步骤如下：打开开发者工具——选择 Network 选项卡——刷新网页——出现数据包列表——点击任意一个数据包——点击 Response 选项卡（响应体）

响应体中包含请求操作的结果或相关信息，根据请求（URL、方法、请求头、请求体）的不同，响应体中所包含的内容也不同（例如 HTML 页面、JSON 数据、XML 数据、图片等），举例如下：

• 例如向⼀个 HTML 网页的 URL 发送请求，响应体就是 HTML 代码。

• 例如向⼀个 XML 接口的 URL 发送请求，响应体就是 XML 数据。

• 例如向⼀个 JSON 接口的 URL 发送请求，响应体就是 JSON 数据。

建议

需要注意的是，响应体不一定总是存在，比如当响应代码为 204 No Content 时，响应体会为空。另外，响应体的大小可能影响性能，建议针对较大数据进行压缩（如 Content-Encoding: gzip）。