【进阶第9期】HTTP详解 —— 入门

前言

大纲

读完本文，希望你能明白：

• HTTP 通信存在什么哪些安全隐患？
• HTTP 各个版本之间区别？
• HTTPS 如何改进HTTP存在那些问题？
• HTTPS 工作原理是什么？

【一】 HTTP 是什么？

定义：超文本传输协议，HyperText Transfer Protocol 概述：HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准。通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息

HTTP 的特点

• 无连接：每次连接只处理一个请求，服务器处理完客户请求，收到用户的应答后，便断开连接，这种方式可以节省传输时间
• 无状态：无状态是指协议对于事物处理没有记忆能力。不对请求和响应之间的通信状态进行保存，缺少状态意味着如果后续处理需要前面的信息，则它必须重传。无状态协议解决办法： 1、通过Cookie 2、通过Session会话保存
• 简单快速：客户向服务器请求服务时，只需要传送请求方法和路径。由于HTTP协议简单，使得通信速度比较快

HTTP 缺点

• 通信明文传输(不加密)，内容可能被窃听
• 不验证通信方身份，有可能遭遇伪装
• 无法证明报文完整性，有可能被篡改

思考：针对这些缺点，黑客如何利用，我们又是如何防御？

【二】 HTTP 报文

HTTP报文是用于HTTP协议交互的信息，可分为两类：请求报文，响应报文。HTTP报文大致可以划分为报文首部和报文主体,他们之间通常同空行隔开。报文首部通常用于处理服务器端或客户端处理请求或响应的内容及属性。

2.1 HTTP 请求报文

HTTP请求头报文由4部分组成：报文首部(请求行+请求头)、空行(CR+LF)、报文主体(请求体) ，格式如下

POST https://example.com/comments HTTP/1.1   #请求行
content-type: application/json   # 请求头
# 空行(CR+LF)
{
    "name": "sample",  #请求体 
    "time": "Wed, 21 Oct 2015 18:27:50 GMT"
}
复制代码

2.1.1 请求行

接下来让我们看下请求行的组成：请求方法(八种)、请求地址、协议版本，中间用空格分开。

POST https://example.com/comments HTTP/1.1

请求方法

HTTP/1.1 协议中共定义了八种方法（也叫“动作”）来以不同的方式操作指定的资源: POST、GET、PUT、DELETE、OPTIONS、HEAD、TRACE、CONNECT。HTTP1.0中只定义了POST/GET/

方法名	说明
GET	向指定的资源发出显示请求，使用 GET 方法应该只用在读取数据上，而不应该用于产生副作用的操作中
POST	指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求文本中。这个请求可能会创建新的资源或者修改现有资源，或两者皆有
PUT	向指定资源位置上传其最新内容
DELETE	请求服务器删除 Request-URI 所标识的资源
OPTIONS	使服务器传回该资源所支持的所有HTTP请求方法。用*来代替资源名称，向 Web 服务器发送 OPTIONS 请求，可以测试服务器功能是否正常运作
HEAD	与 GET 方法一样，都是向服务器发出指定资源的请求，只不过服务器将不传回资源的本文部分，它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中关于该资源的信息（原信息或称元数据）
TRACE	显示服务器收到的请求，主要用于测试或诊断
CONNECT	HTTP/1.1 中预留给能够将连接改为通道方式的代理服务器。通常用于 SSL 加密服务器的链接（经由非加密的 HTTP 代理服务器）

请求地址URI

URI, 全称为(Uniform Resource Identifier), 也就是统一资源标识符，它的作用很简单，就是区分互联网上不同的资源。格式如下:scheme:// user:password@ host:port path ?query #fragemnt

https://juejin.cn/editor/drafts/6899443200332103693
复制代码

字段	描述
scheme	表示协议名，比如http, https, file等等。后面必须和://连在一起。
user:passwd@	表示登录主机时的用户信息，不过很不安全，不推荐使用，也不常用。
host:port	表示主机名和端口。主机名有三种形式：以域名的形式www.tutu.com;,以 IPv4 192.168.0.1地址名，
path	表示请求路径，标记资源所在位置。
query	表示查询参数，为key=val这种形式，多个键值对之间用&隔开。
fragment	表示URI 所定位的资源内的一个锚点，浏览器可以根据这个锚点跳转到对应的位置。

举个例子:

https://www.baidu.com/s?wd=HTTP&rsv_spt=1
复制代码

这个 URI 中，https即scheme部分，www.baidu.com为host:port部分（注意，http 和 https 的默认端口分别为80、443），/s为path部分，而wd=HTTP&rsv_spt=1就是query部分。 具体到location对应值如下:

{
  "href": "https://www.baidu.com/s?wd=HTTP&rsv_spt=1",
  "origin": "https://www.baidu.com",
  "protocol": "https:",
  "host": "www.baidu.com",
  "hostname": "www.baidu.com",
  "port": "",
  "pathname": "/s",
  "search": "?wd=HTTP&rsv_spt=1",
  "hash": ""
}
复制代码

URI编码 URI 只能使用ASCII编码(对编码不理解可以查看前端编码那些事), ASCII 之外的字符是不支持显示的，而且还有一部分符号是界定符，如果不加以处理就会导致解析出错。

因此，URI 引入了编码机制，将所有非 ASCII 码字符和界定符转为十六进制字节值，然后在前面加个%。如，空格被转义成了%20，三元被转义成了%E4%B8%89%E5%85%83。

escape escape 函数是全局对象的属性。特色字符如: @*_+-./ 被排除在外。字符的16进制格式值,当该值小于等于0xFF时,用一个2位转移序列: %xx 表示. 大于的话则使用4位序列:%uxxxx 表示.

encodeURI vs encodeURIComponent 它们共同点都是对URI进行编码，区别是它们的编码范围不太一样。

• 1、如果只是编码字符串，不和URI有半毛钱关系，那么用escape
• 2、如果你需要编码整个URI，然后需要使用这个URI，那么用encodeURI
• 3、当你需要编码URI中的参数的时候，那么encodeURIComponent是最好方法

简单理解：encodeURI对全角日韩汉字其作用。对UR中的特殊字符(;/?:@&=+$,#)不做处理，encodeURIComponent对URI中的特殊字符(;/?:@&=+$,#)做出来，将他们转化成对应的ASCII码

协议版本

用于指定当前通信使用的HTTP协议版本。由于篇幅原因这里不做展开，后续

2.1.2 请求头

请求头可用于传递一些附加信息，格式为：键: 值，注意，冒号后面有一个空格：

2.1.3 请求体

请求体（又叫请求正文）是 post 请求方式中的请求参数，以 key = value 形式进行存储，多个请求参数之间用&连接。如果一个请求当中有请求体，那么在请求头当中的 Content-Length 属性记录的就是该请求体的长度

2.2 HTTP 响应报文

HTTP响应报文分为三个部分：响应状态行，响应头，响应体 大致格式如下

HTTP/1.1 200 ok # 响应状态行
Content-Type: application/json  # 各种首部字段
Server: example.com   
# 空行(CR+LF)
{
    "code": 0,
    "msg": "success",
    "data": {
        "username": "username"
    }
}
复制代码

2.2.1 响应状态行

响应状态行由三部分组成：HTTP版本、状态码、解释状态码的简单短语，它们之间用空格分开，如：

HTTP/1.1 100 Continue
HTTP/1.1 200 Ok
HTTP/1.1 204 No Content
HTTP/1.1 404 Not Fund
复制代码

大致状态码如下：

状态码	描述
1xx	代表请求已被接受，需要继续处理
2xx	请求已成功，请求所希望的响应头或数据体将随此响应返回
3xx	重定向
4xx	客户端原因引起的错误
5xx	服务端原因引起的错误

具体http 有哪些状态码以及每个状态码的对应场景可以查看附录

2.2.2 响应头

【三】HTTP 协议版本

3.1 http/1.0

这个版本:

• 请求方式新增了POST，DELETE，PUT，HEAD等方式
• 增添了请求头和响应头的概念，在通信中指定了 HTTP 协议版本号，以及其他的一些元信息 (比如: 状态码、权限、缓存、内容编码)
• 扩充了传输内容格式，图片、音视频资源、二进制等都可以进行传输

在这个版本主要的就是对请求和响应的元信息进行了扩展，客户端和服务端有更多的获取当前请求的所有信息，进而更好更快的处理请求相关内容。

3.2 http/1.x

HTTP 1.1 是在 1.0 发布之后的半年就推出了，完善了 1.0 版本。目前也还有很多的互联网项目基于 HTTP 1.1 在向外提供服务。

** 特性 **

• 长连接：新增Connection字段，可以设置keep-alive值保持连接不断开
• 管道化：基于上面长连接的基础，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回
• 缓存处理：新增字段cache-control
• 断点传输

3.2.1 持久连接 keep-alive

http1.0 中每进行一次HTTP通信就会断开一次TCP连接。这样每次请求都会有一次TCP连接建立与断开增加通信开销。为解决这个问题，在http/1.1中通过默认Connection:keep-alive开启持久化连接，从而减少TCP重复建立和断开的所造成的额外开销，减轻服务器端的负载。

3.2.2 管线化

基于长连接(tcp连接未断开)的基础，我们对比有无管道化请求响应结果

# tcp没有断开，用的同一个通道，无管道化情况下
请求1 > 响应1 --> 请求2 > 响应2 --> 请求3 > 响应3
# 结果分析：同一个tcp连接只能等待前一个请求结果返回，才能发起下次请求

# 管道化的请求响应
请求1 --> 请求2 --> 请求3 > 响应1 --> 响应2 --> 响应3
# 结果分析：即使服务器先准备好响应2,也是按照请求顺序先返回响应1
复制代码

在持久连接前提下，管线化能够做到同时并发多个请求，而不需要一个接一个等待响应。虽然管道化，可以一次发送多个请求，但是响应仍是顺序返回，仍然无法解决队头阻塞的问题。

3.2.3 断点续传

在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载，如果遇到网络故障，可以从已经上传/下载好的地方继续请求，不用从头开始，提高效率

3.3 http/2.0

HTTP2 相比较于 HTTP1.X 大幅度的提升了 web 性能, 在于 HTTP1.1 完全兼容的基础上, 进一步减少了网络延迟, 而对于前端开发人员来说, 无疑减少了在前端方面的优化工作。 特性:

• 二进制分帧
• 多路复用： 在共享TCP链接的基础上同时发送请求和响应
• 头部压缩
• 服务器推送：服务器可以额外的向客户端推送资源，而无需客户端明确的请求

3.3.1 二进制分帧

HTTP 1.x 的解析是基于文本，HTTP 2之后将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，提高传输效率。

3.3.2 多路复用

在共享TCP链接的基础上同时发送请求和响应，基于二进制分帧，在同一域名下所有访问都是从同一个tcp连接中走，http消息被分解为独立的帧，乱序发送，服务端根据标识符和首部将消息重新组装起来。

3.3.3 头部压缩

由于 HTTP 是无状态的，每一个请求都需要头部信息标识这次请求相关信息，所以会造成传输很多重复的信息，当请求数量增大的时候，消耗的资源就会慢慢积累上去。所以 HTTP 2 可以维护一个头部信息字典，差量进行更新头信息，减少头部信息传输占用的资源，详见 HTTP/2 头部压缩技术介绍。

【四】HTTPS

HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全。HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密。针对HTTP的缺点，HTTTPS是如何改善进行安全传输的：

• 不验证通信方身份，有可能遭遇伪装 ===> 1、利用非对称加密实现身份认证和会话密钥协商
• 通信明文传输(不加密)，内容可能被窃听 ===> 2、利用基于对称加密算法的会话密钥对数据加密
• 无法证明报文完整性，有可能被篡改 ===> 3、基于散列函数验证信息的完整性

4.1 加密方式

4.1.1 对称密钥加密

加密和解密同用一个密钥的方式叫做共享密钥加密，也称为对称密钥加密。也就是说，客户端和服务器端共用一个密钥对消息进行加密。客户端在发送请求时，会用密钥对消息加密。服务器收到后，再用密钥对消息进行解密。

缺点：对称加密虽然保证了消息保密性，但客户端和服务器端用的都是同一个密钥，如果说在传输的过程中出现了中间人或攻击者。密钥就有可能落到攻击者手中，这样就对消息加密就没有什么意义了。

目前常见的对称加密算法有：DES、AES、IDEA 等

4.1.2 非对称密钥加密

非对称密钥加密用的是一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。私有密钥只能是自己所拥有，而公开密钥则是任何人都可以拿到。

• 当客户端发送消息前，使用公共密钥进行加密，
• 而服务器收到消息后，使用私有密钥进行解密。

缺点：

• 公钥任何人都可以拿到，也可能被中间人篡改之后返回给客户端。非对称加密需要在发送端在发送消息时，用公钥加密。但公钥是任何人都可以拿到，中间人也可以。中间人虽然不知道接收方的私钥是什么，但可以截获发送端的公钥，自己另外生成一把公钥或者篡改公钥，把公钥发给接收端。
• 加解密效率低。非对称加密处理起来比对称加密的方式更加复杂，这样就导致了效率变低。

目前常见非对称加密算法：RSA，DSA，DH等。

混合加密机制

数字签名

数字签名是非对称加密和数字摘要两项技术的应用，它将摘要信息用发送者的私钥加密，和原文一起发给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用 Hash 函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果一样，那就说明收到的信息是完整的。否则说明信息被修改过，因此数字签名能够验证信息的完整性。

好处：数字签名是附加在报文上的特殊加密校验码。使用数字签名有以下两点好处。

• 1、签名能确定消息是由发送方签名并发过来的，因为别人假冒不了发送方的签名。
• 2、签名能确定消息的完整性，证明数据没有被篡改过。

数字证书还包括对象的公钥，对象和所用签名算法的描述信息。所有人都可以创建一个数字证书，但并不是所有人都能获得签发权，从而为证书信息担保，并用它私有密钥签发证书。

数字签名生成过程(发送方)： 明文 -> hash运算 -> 摘要 -> 私钥加密 -> 数字签名。 数字签名验证过程(接收方)：原文 + 数字签名 -> (公钥解密数字签名)摘要信息 vs (原文) Hash运算 -->

数字证书

组成： 证书的发布机构CA、证书的有效期、证书所有者、公钥、签名

通信机制

大致过程分为三个阶段：

• 在获取公钥证书环节：客户端从服务器拿到公钥证书之后，会用数字认证机构的公钥验证公钥证书中数字签名，以确认公钥证书的真实性。
• 在交换会话密钥环节：使用非对称加密方式，客户端使用公钥证书中公钥进行加密处理得到会话的密钥，然后对方用自己的私钥解密拿到会话的密钥，这样可以确保交换的密钥是安全的前提下，后续使用对称加密方式（会话秘钥）进行通信。
• 正常报文通信环节：服务器/客户端均使用同一个会话秘钥(对称加密放方式)对报文主体加解密。

详细流程如下：

• 1、首先是客户端向服务器端发起一个 HTTPS 请求。Client知道需要连接Server的443（默认）端口。
• 2、服务器端把事先配置好的公钥证书(在权威CA机构申请的证书)返回给客户端。
• 3、客户端收到公钥证书后，用数字认证机构CA的公钥验证数字签名，以确认服务器的公钥证书的真实性。
• 4、客户端用伪随机数生成器生成临时的会话密钥，然后用服务器返回的证书的公钥对该会话密钥进行加密，发送给服务器端。
• 5、服务器收到消息后，用自己的私钥解密这个消息，得到会话密钥。至此，Client和Server双方都持有了相同的会话密钥
• 6、之后客户端和服务器端就开始了 HTTPS 通信。
• 7、Server使用会话密钥加密“明文内容A”，发送给Client。Client使用会话密钥解密响应的密文，得到“明文内容A”。
• 8、Client再次发起HTTPS的请求，使用会话密钥加密请求的"明文内容B"，然后Server使用会话密钥解密密文，得到"明文内容B"。

HTTPS 安全吗？

HTTPS 如何保证网站安全性的？

从以下三个方面：

• 1、认证用户或者服务器，确保发送到正确的客户端或者服务器
• 2、加密数据以防止数据被中途窃取
• 3、维护数据的完整性，以确保数据在传输过程中不会被篡改

下面就是https的整个架构，现在的https基本都使用TSL了，因为更加安全，所以下图中的SSL应该换为SSL/TSL。 分两个阶段：

• 1、SSL在握手完全阶段依赖数字证书建立安全会话(获取会话秘钥)
• 2、SSL在传输阶段使用上一步获取的会话秘钥对报文进行加密

如何证明浏览器收到的公钥一定是该网站的公钥？或者说如何验证数字证书真假？

CA证书安全吗？

CA 证书目的主要是为了防止篡改，不保证密文被窃听读取。

• 假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

为什么制作数字签名时需要hash一次？

非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加解密就快很多

共享秘钥有可能被中间人窃听吗？

HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？

显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？用session就可以。 服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了

【五】HTTP 请求流程

拓展

本文针对HTTP介绍有很多遗漏或者解释不清楚的，推荐可以购买图解HTTP这本书籍了解更多细节

附录

HTTP/1.1规范定义了 如下47种头部字段。根据实际的通途分为四类:

• 通用首部字段: 请求报文和响应报文都会使用的首部字段
• 请求首部字段: 客户端向服务器发送请求报文时使用的首部字段, 补充了请求的附加内容, 客户端信息, 响应内容相关优先级信息
• 响应首部字段: 从服务端向客户端返回响应报文时使用的首部, 补充了响应的附加内容, 也会要求客户端附加额外的内容信息
• 实体首部字段: 针对请求报文和响应报文的实体部分使用的首部, 补充了资源内容更新时间和实体有关的信息

表1：通用首部字段(General Header Fields)

Header	解释	示例
Cache-Control	控制缓存
Connection	连接管理、逐跳首部
Upgrade	可以用来检测HTTP协议以及其他协议是否可使用, 并用更高的版本进行通信
via	代理服务器的相关信息, 可以用来追踪客户端与服务器之间的请求和响应报文的传输路径. 也可以用于避免请求回环的发生, 常常和trace请求一起使用.
Transfor-Encoding	报文主体的传输编码格式
Trailer 会事先说明在报文主体后面记录了哪些首部字段, 可以应用在分块传输编码的时候
Pragma	报文指令, 是历史遗留字段, 仅仅为了兼容而存在
Date	创建报文的日期

表2：请求首部字段

Header	解释	示例
Accept	指定客户端能够接收的内容类型	Accept: text/plain, text/html
Accept-Charset	浏览器可以接受的字符编码集。	Accept-Charset: iso-8859-5
Accept-Encoding	指定浏览器可以支持的web服务器返回内容压缩编码类型。	Accept-Encoding: compress, gzip
Accept-Language	浏览器可接受的语言	Accept-Language: en,zh
Accept-Ranges	可以请求网页实体的一个或者多个子范围字段	Accept-Ranges: bytes
Authorization	HTTP授权的授权证书	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	指定请求和响应遵循的缓存机制	Cache-Control: no-cache
Connection	表示是否需要持久连接。（HTTP 1.1默认进行持久连接）	Connection: close
Cookie	HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。	Cookie: $Version=1; Skin=new;
Content-Length	请求的内容长度	Content-Length: 348
Content-Type	请求的与实体对应的MIME信息	Content-Type: application/x-www-form-urlencoded
Date	请求发送的日期和时间	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	请求的特定的服务器行为	Expect: 100-continue
From	发出请求的用户的Email	From: user@email.com
Host	指定请求的服务器的域名和端口号	Host: www.zcmhi.com
If-Match	只有请求内容与实体相匹配才有效	If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since	如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range	如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag	If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since	只在实体在指定时间之后未被修改才请求成功	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	限制信息通过代理和网关传送的时间	Max-Forwards: 10
Pragma	用来包含实现特定的指令	Pragma: no-cache
Proxy-Authorization	连接到代理的授权证书	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	只请求实体的一部分，指定范围	Range: bytes=500-999
Referer	先前网页的地址，当前请求网页紧随其后,即来路	Referer: www.zcmhi.com/archives/71…
TE	客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息	TE: trailers,deflate;q=0.5
Upgrade	向服务器指定某种传输协议以便服务器进行转换（如果支持）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	User-Agent的内容包含发出请求的用户信息	User-Agent: Mozilla/5.0 (Linux; X11)
Via	通知中间网关或代理服务器地址，通信协议	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	关于消息实体的警告信息	Warn: 199 Miscellaneous warning

表3：响应首部字段

Header	解释	示例
Accept-Ranges	表明服务器是否支持指定范围请求及哪种类型的分段请求	Accept-Ranges: bytes
Age	从原始服务器到代理缓存形成的估算时间（以秒计，非负）	Age: 12
Allow	对某网络资源的有效的请求行为，不允许则返回405	Allow: GET, HEAD
Cache-Control	告诉所有的缓存机制是否可以缓存及哪种类型	Cache-Control: no-cache
Content-Encoding	web服务器支持的返回内容压缩编码类型。	Content-Encoding: gzip
Content-Language	响应体的语言	Content-Language: en,zh
Content-Length	响应体的长度	Content-Length: 348
Content-Location	请求资源可替代的备用的另一地址	Content-Location: /index.htm
Content-MD5	返回资源的MD5校验值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	在整个返回体中本部分的字节位置	Content-Range: bytes 21010-47021/47022
Content-Type	返回内容的MIME类型	Content-Type: text/html; charset=utf-8
Date	原始服务器消息发出的时间	Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag	请求变量的实体标签的当前值	ETag: “737060cd8c284d8af7ad3082f209582d”
Expires	响应过期的日期和时间	Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified	请求资源的最后修改时间	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location	用来重定向接收方到非请求URL的位置来完成请求或标识新的资源	Location: www.zcmhi.com/archives/94…
Pragma	包括实现特定的指令，它可应用到响应链上的任何接收方	Pragma: no-cache
Proxy-Authenticate	它指出认证方案和可应用到代理的该URL上的参数	Proxy-Authenticate: Basic
refresh	应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）	Refresh: 5; url=www.atool.org/httptest.ph…
Retry-After	如果实体暂时不可取，通知客户端在指定时间之后再次尝试	Retry-After: 120
Server	web服务器软件名称	Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie	设置Http Cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer	指出头域在分块传输编码的尾部存在	Trailer: Max-Forwards
Transfer-Encoding	文件传输编码	Transfer-Encoding:chunked
Vary	告诉下游代理是使用缓存响应还是从原始服务器请求	Vary: *
Via	告知代理客户端响应是通过哪里发送的	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	警告实体可能存在的问题	Warning: 199 Miscellaneous warning
WWW-Authenticate	表明客户端请求实体应该使用的授权方案	WWW-Authenticate: Basic

表4 实体首部字段

Header	解释
Allow	资源可支持 http 请求的方法
Content-Encoding	实体的编码格式, 主要有gzip,compress, deflate, identity四种
Content-Language	实体的资源语言
Content-Location	代替资源的uri, 与Location不同, 该字段表示的是报文主题返回资源对应的URI
Content-Length	实体的大小（字节）
Content-Type	实体媒体类型
Content-MD5	实体报文的摘要, 该字段无法校验内容是否被篡改
Content-Range	针对范围请求, 能告知客户端作为响应返回的实体的哪个部分符合范围请求
Last-Modified	资源最后的修改资源
Expires	实体主体的过期资源

Responses 部分 | Http Response code

状态码	解释短语	描述	使用场景
200	OK
204	No Content	含义与200相同	响应头后没有 body 数据
206	Partial Content	部分内容	使用场景为 HTTP 分块下载和断点续传
301	Moved Permanently	永久重定向，表示资源已被分配了新的 URL。	比如你的网站从 HTTP 升级到了 HTTPS 了，以前的站点再也不用了，应当返回301，这个时候浏览器默认会做缓存优化，在第二次访问的时候自动访问重定向的那个地址
302	Found	临时性重定向，表示资源临时被分配了新的 URL，希望用户(本次)能使用新的URI访问	与301不同的是，浏览器并不会做缓存优化
303	See Other	表示资源存在着另一个 URL，应使用 GET 方法获取资源
307	Temporary Redirect	临时性重定向，表示资源临时被分配了新的 URL
304	Not Modified	表示服务器允许访问资源，但因发生请求未满足条件的情况
400	Bad Request	请求报文存在语法错误
401	Unauthorized	表示发送的请求需要有通过 HTTP 认证的认证信息
403	Forbidden	表示对请求资源的访问被服务器拒绝
404	Not Found	表示在服务器上没有找到请求的资源
500	Internal Sever Error	服务器端在执行请求时发生了错误
503	Service Unavailable	服务器暂时处于超负载或正在停机维护，无法处理请求