nginx 资料整理（二）- HTTP

nginx 资料整理（二）

• • [1. HTTP](#1. HTTP)
  • • [1. HTTP是什么？](#1. HTTP是什么？)
    • [2. 什么是超文本？](#2. 什么是超文本？)
    • [3. 协议版本概述](#3. 协议版本概述)
    • [4. 协议版本详解](#4. 协议版本详解)
    • • HTTP/0.9
      • HTTP/1.0
      • HTTP/1.1
      • HTTPS
      • SPDY
      • HTTP/2.0
  • [2. HTTP请求与响应](#2. HTTP请求与响应)
  • • [1. HTTP请求](#1. HTTP请求)
    • • [1. 请求起始行](#1. 请求起始行)
      • [2. 请求头(Request Headers)](#2. 请求头(Request Headers))
      • [3. 空行(Blank Line)](#3. 空行(Blank Line))
      • [4. 请求体(Request Body)](#4. 请求体(Request Body))
    • [2. HTTP响应](#2. HTTP响应)
    • • [1. 状态行](#1. 状态行)
      • [2. 响应头](#2. 响应头)
      • [3. 响应体](#3. 响应体)
    • [3. 查看HTTP请求及响应的工具](#3. 查看HTTP请求及响应的工具)

在对nginx web服务器深入学习之前，我们有必要对http做一定的知识储备，毕竟nginx是http协议的实现。

Nginx是一个高性能的HTTP服务器，主要用于处理HTTP请求和提供Web内容。它支持HTTP协议的各种特性，并且是构建在HTTP协议之上的一个服务。

Nginx的主要功能和特点也体现了其与http密不可分的关系：

• 静态内容服务‌：Nginx可以直接高效地处理HTTP请求，返回静态内容如HTML、CSS、JavaScript文件、图片等‌1。
• 动态内容代理‌：Nginx可以作为反向代理服务器，接收客户端的HTTP请求，并根据配置规则将请求转发给后端应用服务器，同时还可以聚合后端服务器的响应并返回给客户端‌1。
• 负载均衡‌：Nginx利用HTTP协议实现负载均衡，通过轮询、权重分配、IP哈希、最少连接数等方式将用户的HTTP请求分发到多个后端服务器，以提升系统性能和可用性‌1。
• 缓存机制‌：Nginx能够对HTTP响应进行缓存，减轻后端服务器的压力，加快重复请求的响应速度‌1。
• 安全设置‌：Nginx支持SSL/TLS加密协议，通过HTTPS提供安全的HTTP服务，可以配置证书、禁用不安全的加密套件等手段来增强安全性‌。
• 重写与路由‌：Nginx能够根据HTTP请求的URL进行重写和路由，实现URL美化、SEO友好地址转换，或者基于路径、主机名等条件进行复杂的逻辑处理‌。

此外，Nginx还支持其他协议，如HTTP/3，这是基于QUIC协议的新版本HTTP协议，旨在提供更快的连接建立时间和更好的可靠性‌

1. HTTP

1. HTTP是什么？

HTTP（Hypertext Transfer Protocol，超文本传输协议）：是一种用于传输超文本数据（如 HTML、图片、视频等）的应用层协议。

2. 什么是超文本？

超文本是一种文本类型，通过链接将文本、图片、视频等多媒体内容相互关联起来的文本形式，不仅包括文字内容，还可以通过链接（超链接）在文档之间或者文档内部进行非线性的、随意的跳转和浏览。简而言之，就是传输内容不仅仅是文本，还可以是一些其他的资源，如图片、视频、音频等二进制数据

3. 协议版本概述

版本	发布日期	主要功能
‌HTTP/0.9	1991	是最早的HTTP版本，由Tim Berners-Lee设计，只支持简单的GET请求，没有HTTP头信息，也不支持状态码，只能用于传输纯文本‌。
‌HTTP/1.0	1996	引入了HTTP头信息（Headers），允许传输元数据，支持多种请求方法如GET、POST、HEAD，并引入了状态码用于指示请求的结果。然而，每个请求/响应之后都会关闭TCP连接，导致效率低下‌。
‌HTTP/1.1	1997	是当前最广泛使用的HTTP协议版本。相比HTTP/1.0，HTTP/1.1做了很多改进和优化，包括默认启用TCP连接复用（Connection: keep-alive），减少了连接建立的开销；增加了更多的请求方法如OPTIONS、PUT、DELETE、TRACE、CONNECT；支持分块传输编码，允许服务器分块发送响应数据；引入了更多的缓存控制机制如Cache-Control头；改进了错误处理和状态码的定义‌。
‌HTTP/2.0	2015	使用二进制格式而不是文本格式，提升了解析效率。它支持多路复用，在一个TCP连接上可以发送多个并发请求/响应，减少了连接数量。头部压缩通过HPACK算法减少了带宽消耗。此外，HTTP/2引入了服务器推送功能，允许服务器在客户端请求之前主动推送资源，提升了加载速度‌。
‌HTTP/3.0	2022	基于QUIC协议，运行在QUIC之上，QUIC本身是基于UDP的协议，提供了快速连接建立和可靠传输的能力。HTTP/3改进了安全性，支持更好的拥塞控制，并允许连接迁移，保持网络改变时的连接不中断‌

4. 协议版本详解

HTTP/0.9

HTTP 的最早版本诞生在 1991 年，这个最早版本和现在比起来极其简单，没有 HTTP 头，没有状态码，甚至版本号也没有，后来它的版本号才被定为 0.9 来和其他版本的 HTTP 区分。HTTP/0.9 只支持一种方法------ Get，请求只有一行。

响应也是非常简单的，只包含 html 文档本身。

当 TCP 建立连接之后，服务器向客户端返回 HTML 格式的字符串。发送完毕后，就关闭 TCP 连接。由于没有状态码和错误代码，如果服务器处理的时候发生错误，只会传回一个特殊的包含问题描述信息的 HTML 文件。这就是最早的 HTTP/0.9 版本。

HTTP/1.0

1996 年，HTTP/1.0 版本发布，大大丰富了 HTTP 的传输内容，除了文字，还可以发送图片、视频等，这为互联网的发展奠定了基础。相比 HTTP/0.9，HTTP/1.0 主要有如下特性：

• 请求与响应支持 HTTP 头，增加了状态码，响应对象的一开始是一个响应状态行
• 协议版本信息需要随着请求一起发送，支持 HEAD，POST 方法
• 支持传输 HTML 文件以外其他类型的内容

HTTP/1.1

在 HTTP/1.0 发布几个月后，HTTP/1.1 就发布了。HTTP/1.1 更多的是作为对 HTTP/1.0 的完善，在 HTTP1.1 中，主要具有如下改进：

• 持久连接（Persistent Connections） ：通过Connection: keep-alive头部，允许在一个TCP连接上发送多个请求和响应，减少了连接建立和关闭的频率。

• 增加 pipeline：HTTP 管线化是将多个 HTTP 请求整批提交的技术，而在传送过程中不需先等待服务端的回应。管线化机制须通过永久连接（persistent connection）完成。浏览器将HTTP请求大批提交可大幅缩短页面的加载时间，特别是在传输延迟（lag/latency）较高的情况下。有一点需要注意的是，只有幂等的请求可以使用 pipeline，如 GET，HEAD 方法。

• chunked 编码传输：该编码将实体分块传送并逐块标明长度,直到长度为 0 块表示传输结束, 这在实体长度未知时特别有用(比如由数据库动态产生的数据)

• 引入更多缓存控制机制：如 etag，cache-control

• 引入内容协商机制，包括语言，编码，类型等，并允许客户端和服务器之间约定以最合适的内容进行交换

• 请求消息和响应消息都支持 Host 头域：在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。因此，Host 头的引入就很有必要了。

• 新增了 OPTIONS,PUT, DELETE, TRACE, CONNECT 方法

• 范围请求，支持请求资源的一部分，有助于实现断点续传。

虽然 HTTP/1.1 已经优化了很多点，作为一个目前使用最广泛的协议版本，已经能够满足很多网络需求，但是随着网页变得越来越复杂，甚至演变成为独立的应用，HTTP/1.1 逐渐暴露出了一些问题：

• 在传输数据时，每次都要重新建立连接，对移动端特别不友好
• 传输内容是明文，不够安全
• header 内容过大，每次请求 header 变化不大，造成浪费
• keep-alive 给服务端带来性能压力

为了解决这些问题，HTTPS 和 SPDY 应运而生。

HTTPS

HTTPS （Hypertext Transfer Protocol Secure， 超文本传输安全协议）是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

HTTPS 协议的主要作用可以分为两种：

• 一种是建立一个信息安全通道，来保证数据传输的安全；
• 另一种就是确认网站的真实性。

HTTPS 和 HTTP 的区别主要如下：

• HTTPS 协议使用 ca 申请证书，由于免费证书较少，需要一定费用。
• HTTP 是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
• HTTP 和 HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。

SPDY

SPDY（读作"SPeeDY"）是Google开发的基于TCP的会话层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。

SPDY 并不是新的一种协议，而是在 HTTP 之前做了一层会话层。

• 在SSL层上增加一个SPDY会话层，以在一个TCP连接中实现并发流。
• 通常的HTTP GET和POST格式仍然是一样的；然而SPDY为编码和传输数据设计了一个新的帧格式。
• 流是双向的，可以在客户端和服务器端启动。
• SPDY旨在通过基本（始终启用）和高级（可选启用）功能实现更低的延迟。

定位

• 将页面加载时间减少50%。
• 最大限度地减少部署的复杂性。SPDY使用TCP作为传输层，因此无需改变现有的网络设施。
• 避免网站开发者改动内容。 支持SPDY唯一需要变化的是客户端代理和Web服务器应用程序。

具体技术目标

• 单个TCP连接支持并发的HTTP请求。
• 压缩报头和去掉不必要的头部来减少当前HTTP使用的带宽。
• 定义一个容易实现，在服务器端高效率的协议。通过减少边缘情况、定义易解析的消息格式来减少HTTP的复杂性。
• 强制使用SSL，让SSL协议在现存的网络设施下有更好的安全性和兼容性。
• 允许服务器在需要时发起对客户端的连接并推送数据

HTTP/2.0

时间来到 2015 年，HTTP/2.0 问世。先来介绍一下 HTTP/2.0 的特点：

• 使用二进制分帧层 ：在应用层与传输层之间增加一个二进制分帧层，以此达到在不改动 HTTP 的语义，HTTP 方法、状态码、URI 及首部字段的情况下，突破HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层上，HTTP2.0 会将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，其中 HTTP1.x 的首部信息会被封装到 Headers 帧，而我们的 request body 则封装到 Data 帧里面。
  
• 多路复用 ：对于 HTTP/1.x，即使开启了长连接，请求的发送也是串行发送的，在带宽足够的情况下，对带宽的利用率不够，HTTP/2.0 采用了多路复用的方式，可以并行发送多个请求，提高对带宽的利用率。
  
• 数据流优先级：由于请求可以并发发送了，那么如果出现了浏览器在等待关键的 CSS 或者 JS 文件完成对页面的渲染时，服务器却在专注的发送图片资源的情况怎么办呢？HTTP/2.0 对数据流可以设置优先值，这个优先值决定了客户端和服务端处理不同的流采用不同的优先级策略。
• 服务端推送：在 HTTP/2.0 中，服务器可以向客户发送请求之外的内容，比如正在请求一个页面时，服务器会把页面相关的 logo，CSS 等文件直接推送到客户端，而不会等到请求来的时候再发送，因为服务器认为客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源。
• 头部压缩 ：使用首部表来跟踪和存储之前发送的键值对，对于相同的内容，不会在每次请求和响应时发送。
  
  可以看到 HTTP/2.0 的新特点和 SPDY 很相似，其实 HTTP/2.0 本来就是基于 SPDY 设计的，可以说是 SPDY 的升级版。

但是 HTTP/2.0 仍有和 SPDY 不同的地方，主要有如下两点：

• HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS。
• HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE。

2. HTTP请求与响应

1. HTTP请求

HTTP请求是客户端向服务器获取数据或提交数据的方式。了解其结构和内容对于理解Web开发和网络通信至关重要。在实际应用中，根据需要，不同的请求类型、头部和主体组合使用，以实现有效和安全的数据交互。

一个HTTP请求由四个部分组成：

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

使用curl命令可以帮助我们查看网站请求及响应内容

[root@web-svr-01 conf.d]# curl -Lv 127.0.0.1
* About to connect() to 127.0.0.1 port 80 (#0)
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 127.0.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.20.1
< Date: Thu, 10 Oct 2024 07:08:01 GMT
< Content-Type: text/html
< Content-Length: 26
< Last-Modified: Thu, 05 Sep 2024 05:41:01 GMT
< Connection: keep-alive
< ETag: "66d9446d-1a"
< Accept-Ranges: bytes
<
hello, this is test rsync
* Connection #0 to host 127.0.0.1 left intact

1. 请求起始行

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

• 方法(Method): 定义了对资源的操作，如GET、POST、HEAD等
• 请求URI: 指定了请求的资源路径，这里的资源路径指以站点目录为根目录。例如，nginx web服务器的默认站点目录为/usr/share/nginx/html，其首页文件为index.html，那么访问这个首页文件的URI为/index.html。当然如果指定的URI只有一个/，那么同样表示访问首页文件，不过仅是省略了首页文件。
• 协议版本: 通常是HTTP/1.1或HTTP/2.0

例如：GET / HTTP/1.1

请求方法(Method)

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

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

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

请求URI

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

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

协议版本

协议版本标识了客户端用于构造请求的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用来作为消息中各个头部字段的分隔符。

2. 请求头(Request Headers)

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

字段	含义	示例
Host	指定服务器的域名和（可选的）端口号。在HTTP/1.1中，Host是唯一一个必须存在的请求头。可以是域名或者IP	Host: www.example.com，Host: 127.0.0.1
User-Agent	包含了发起请求的客户端信息，比如浏览器类型、版本、操作系统等。	User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)， User-Agent: curl/7.29.0
Accept	描述: 指明客户端能够接受的内容类型，也就是服务器可以返回的媒体资源类型。*/*可以接受任何类型	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8， Accept: */*
Accept-Language	告诉服务器客户端优先选择的语言，通常用于国际化内容。	Accept-Language: en-US,en;q=0.5
Accept-Encoding	告诉服务器客户端支持的内容编码方式，比如gzip或defla te压缩。	Accept-Encoding: gzip, deflate, br
Connection	控制当前事务完成后，客户端和服务器之间连接的处理方式，例如keep-alive或close。	Connection: keep-alive
Cache-Control	指示请求和响应遵循的缓存机制。	Cache-Control: no-cache
Cookie	包含从服务器接收的所有cookies，服务器可以用它来恢复客户端的会话状态。	Cookie: sessionToken=abc123; userId=789
Content-Length	在POST或PUT请求中，指示请求体的大小（以字节计）	Content-Length: 348
Content-Type	当发送POST或PUT请求时，这个请求头必须被使用来指示提交数据的MIME类型。	Content-Type: application/json
Authorization	包含了证明客户端有权查看某资源的证书。它通常涉及一个承载令牌，如JWT或OAuth令牌。	Authorization: Bearer YOUR_TOKEN_HERE
Referer	指示发起请求的前一个页面的URI，可以用来跟踪从何处链接到当前请求的资源。	Referer: http://www.example.com/index.html

内容丰富些的示例

GET /wzdh/stat.html?p=hotword&action=show&cate=webpage&eng=so360&group=hotword&type=normal&orgin=click&refresh=false&version=b&ssid=19ee30748471423997a40803a83588a2&guid=234898968.1080209797284144600.1697793037481.7478&refer=lianmeng&_t=1728542960073.5276 HTTP/2
Host: s.360.cn
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: image/avif,image/webp,*/*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: https://hao.360.com/
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
TE: trailers

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

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

3. 空行(Blank Line)

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

4. 请求体(Request Body)

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

类型	说明	格式
application/x-www-form-urlencoded	这是最常见的请求体类型，通常用于HTML表单提交。	键值对以 & 符号分隔，且键和值都为URL编码。例如，key1=value1&key2=value2。
multipart/form-data	描述: 用于文件上传和发送表单数据时，当表单中有 字段时常用这种类型。	请求体被分割成多个部分，每部分包含一个不同的表单域数据，部分之间由分隔符（boundary）隔开。
application/json	用于发送JSON编码的数据。现代Web APIs和RESTful服务通常用这种格式。	JSON字符串，如 { "key1": "value1", "key2": "value2" }。
text/plain	纯文本数据，不含任何数据类型或结构描述符。	简单的文本字符串，没有特定的结构。
application/xml 或 text/xml	XML数据格式，某些服务或API可能需要使用XML格式进行数据交换。	符合XML规范的字符串，例如 value1value2。
application/octet-stream	用于传输二进制数据或文件内容，指示请求体中的数据是原始的字节。	数据被当作一系列字节处理。

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

2. HTTP响应

HTTP响应通过状态行、响应头和响应体来返回相应的处理结果或资源数据。

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

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

1. 状态行

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

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

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

示例：HTTP/1.1 200 OK

同样使用空格分开

状态码

HTTP状态码是HTTP协议中的一部分，用于表示HTTP请求的结果状态。当客户端（如Web浏览器）向服务器发送HTTP请求时，服务器会返回一个状态码作为响应的一部分，以告知客户端请求的处理结果。

HTTP状态码由三位数字组成，并分为几个不同的类别，每个类别表示不同的响应类型。以下是对一些常见的HTTP状态码及其在C#中如何处理的详细解释：

状态码	说明	详细
1xx	信息性状态码	100 Continue：客户端应继续请求或忽略该响应。
2xx	成功状态码	200 OK：请求成功。 201 Created：请求成功并且服务器创建了新的资源。 204 No Content：请求成功，但响应报文不含实体的主体部分。
3xx	重定向状态码	301 Moved Permanently：永久性重定向，请求的资源已永久移动到新位置。 302 Found：临时性重定向，请求的资源临时从不同的URI响应请求。 304 Not Modified：如果客户端发送了一个带条件的GET请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。
4xx	客户端错误状态码	400 Bad Request：请求报文存在语法错误。 401 Unauthorized：请求需要用户认证。 403 Forbidden：服务器理解请求客户端的请求，但是拒绝执行此请求。 404 Not Found：请求的资源在服务器上不存在，但不一定就是请求有错误。 405 Method Not Allowed：请求行中指定的请求方法不能被用于请求相应的资源。
5xx	服务器错误状态码	500 Internal Server Error：服务器内部错误，无法完成请求。 502 Bad Gateway：作为网关或代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。 503 Service Unavailable：由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。

2. 响应头

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

字段	说明	示例
Content-Type	响应主体的媒体类型	Content-Type: text/html
Content-Length	响应主体的长度	Content-Length: 2381
Server	服务器软件的信息	Server: bfe/1.0.8.18，Server: nginx/1.20.1
Cache-Control	指定请求/响应链中所有的缓存机制必须遵守的指令	Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Expires	响应过期的时间。	Expires: Thu, 10 Oct 2024 07:00:00 GMT
ETag	资源的特定版本的标识符，通常用于缓存	Etag: "588604c1-94d"

3. 响应体

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

3. 查看HTTP请求及响应的工具

1. 通过浏览器查看请求和响应信息，大部分浏览器按下F12都可以查看请求和响应信息

2. 我们还可以使用curl命令：

curl -I xxx仅查看响应头

[root@web-svr-01 conf.d]# curl -I www.baidu.com
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: keep-alive
Content-Length: 277
Content-Type: text/html
Date: Thu, 10 Oct 2024 07:32:06 GMT
Etag: "575e1f59-115"
Last-Modified: Mon, 13 Jun 2016 02:50:01 GMT
Pragma: no-cache
Server: bfe/1.0.8.18

curl -H Host:域名 IP查看响应内容，常用于测试

[root@web-svr-01 conf.d]# curl -H Host:www.test.cn 127.0.0.1
hello, this is test rsync

curl -Lv 域名查看详细的请求及响应信息，如果不够详细可以继续加v

[root@web-svr-01 conf.d]# curl -Lv www.baidu.com
...

3. wireshark抓包查看，篇幅有限不展开说明了，可以查看笔者以往的文章。