前言

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息
HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息
因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息

为了解决HTTP协议的这一缺陷，需要使用另一种协议：
安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份
并为浏览器和服务器之间的通信加密。并且防止钓鱼和加密。防止钓鱼通过网站的证书，网站必须有CA证书，证书类似于一个解密的签名
另外是加密，加密需要一个密钥交换算法，双方通过交换后的密钥加解密

基本作用

HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

区别

https协议需要到ca申请证书，一般免费证书很少，需要交费
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
http和https使用的是完全不同的连接方式用的端口也不一样，前者是80，后者是443
http的连接很简单，是无状态的。HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全

HTTPS工作原理

（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端

（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站

（5）Web服务器利用自己的私钥解密出会话密钥

（6）Web服务器利用会话密钥加密与客户端之间的通信

HTTPS优缺点

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性

（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本

（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行

状态码请求

下面描述了每个状态代码，包括它可以遵循的方法的描述以及响应中所需的任何元信息

信息:1xx

此类状态代码表示临时响应，仅由状态行和可选标题组成，并以空行终止。此类状态代码没有必需的标头
由于 HTTP/1.0 没有定义任何 1xx 状态代码，服务器不得向 HTTP/1.0 客户端发送 1xx 响应，除非在实验条件下

客户端必须准备好在常规响应之前接受一个或多个 1xx 状态响应，即使客户端不期望 100（继续）状态消息。意外的 1xx 状态响应可能会被用户代理忽略

代理必须转发 1xx 响应，除非代理与其客户端之间的连接已关闭，或者除非代理本身请求生成 1xx 响应
（例如，如果一个代理在转发请求时添加了Expect: 100-continue 字段，则不需要转发相应的 100 响应）

100 - 继续

客户端应该继续它的请求
此临时响应用于通知客户端请求的初始部分已收到，但尚未被服务器拒绝
客户端应该继续发送请求的剩余部分，或者，如果请求已经完成，忽略这个响应
服务器必须在请求完成后发送最终响应

101 - 交换协议

服务器理解并愿意遵守客户端的请求，通过升级消息头字段更改此连接上使用的应用程序协议
服务器将在终止 101 响应的空行之后立即将协议切换到由响应的升级标头字段定义的协议

协议应该仅在这样做有利时才进行切换
例如:切换到新版本的 HTTP 比旧版本更有优势，切换到实时同步协议在交付使用此类功能的资源时可能更有利

成功:2xx

此类状态码表示客户端的请求已成功接收、理解和接受

200 - 正常

请求已成功
响应返回的信息取决于请求中使用的方法

请求	说明
GET	响应中发送与请求资源对应的实体
HEAD	请求资源对应的实体头域在响应中发送，不带任何消息体
POST	描述或包含操作结果的实体
TRACE	包含终端服务器接收到的请求消息的实体

201 - 创建

请求已完成并导致创建新资源
新创建的资源可以由响应实体中返回的 URI 引用，其中最具体的 URI 由 Location 头字段给出
响应应该包含一个包含资源特性和位置列表的实体，用户或用户代理可以从中选择最合适的一个
实体格式由 Content-Type 头字段中给出的媒体类型指定。源服务器必须在返回 201 状态码之前创建资源
如果动作不能立即执行，服务器应该响应 202 (Accepted) 响应

一个 201 响应可能包含一个 ETag 响应头字段，指示刚刚创建的请求变体的实体标签的当前值

202 - 接受

请求已被接受进行处理，但处理尚未完成
该请求最终可能会或可能不会被执行，因为在实际进行处理时可能会被禁止。没有从诸如此类的异步操作重新发送状态代码的工具

202 响应是故意不置可否的
它的目的是允许服务器接受对某个其他进程（可能是一个每天只运行一次的面向批处理的进程）的请求，而无需用户代理与服务器的连接持续到该进程完成
与此响应一起返回的实体应该包括请求当前状态的指示以及指向状态监视器的指针或用户期望请求何时被满足的一些估计

203 - 非权威信息

实体头中返回的元信息不是源服务器提供的确定集，而是从本地或第三方副本收集的
呈现的集合可以是原始版本的子集或超集

例如，包含有关资源的本地注释信息可能会导致原始服务器已知的元信息的超集。不需要使用此响应代码，仅当响应为 200 (OK) 时才适用。

204 - 无内容

服务器已完成请求但不需要返回实体主体，并且可能想要返回更新的元信息
响应可以包含实体头形式的新的或更新的元信息，如果存在，应该与请求的变体相关联

如果客户端是一个用户代理，它不应该改变导致请求被发送的文档视图
此响应主要是为了允许输入操作，而不会导致用户代理的活动文档视图发生变化，尽管任何新的或更新的元信息都应该应用于当前在用户代理的活动视图中的文档

204 响应不能包含消息体，因此总是由头字段之后的第一个空行终止

205 - 重置内容

服务器已经完成了请求，用户代理应该重置导致请求被发送的文档视图
此响应主要旨在允许通过用户输入进行操作的输入，然后清除给出输入的表单，以便用户可以轻松启动另一个输入操作

响应不得包含实体

206 - 部分内容

服务器已完成对资源的部分 GET 请求
请求必须包含一个 Range 头域指示所需的范围，并且可以包含一个 If-Range 头域以使请求有条件

响应必须包含以下头字段：

- Content-Range 标头字段指示
    此响应中包含的范围，或多部分/字节范围
    Content-Type 包括每个部分的 Content-Range 字段。如果一个
    Content-Length 头域存在于响应中，它的
    值必须与实际传输的 OCTET 数量相匹配
    邮件正文。
- 日期
- ETag 和/或 Content-Location，如果标头已经发送
    在对同一请求的 200 响应中
- 过期、缓存控制和/或变化，如果字段值可能
    与之前针对相同的任何响应中发送的不同
    变体

如果 206 响应是使用强缓存验证器的 If-Range 请求的结果，则响应不应包含其他实体头
如果响应是使用弱验证器的 If-Range 请求的结果，则响应不得包含其他实体头；这可以防止缓存的实体主体和更新的标头之间出现不一致
否则，响应必须包括所有实体头，这些实体头将与对同一请求的 200（OK）响应一起返回

如果 ETag 或 Last-Modified 标头不完全匹配，则缓存不得将 206 响应与其他先前缓存的内容组合在一起

不支持 Range 和 Content-Range 标头的缓存不得缓存 **206（部分）**响应

重定向:3xx

此类状态代码表示用户代理需要采取进一步的行动来满足请求
当且仅当第二个请求中使用的方法是 GET 或 HEAD 时，所需的操作可以由用户代理执行，而无需与用户交互

客户端应该检测无限重定向循环，因为此类循环会为每个重定向生成网络流量

本规范的先前版本建议使用最多五个重定向
内容开发者应该意识到可能有客户实现了这样一个固定的局限性

300 - 多项选择

请求的资源对应于一组表示中的任何一个，每个表示都有自己的特定位置，并且正在提供代理驱动的协商信息，以便用户（或用户代理）可以选择首选表示并重定向其请求到那个位置

除非是 HEAD 请求，否则响应应该包含一个包含资源特性和位置列表的实体，用户或用户代理可以从中选择最合适的一个
实体格式由 Content-Type 头字段中给出的媒体类型指定。取决于格式和功能

用户代理，可以自动执行最合适的选择。但是，本规范没有为这种自动选择定义任何标准

如果服务器有首选的表示形式，它应该在 Location 字段中包含该表示形式的特定 URI；用户代理可以使用 Location 字段值进行自动重定向
除非另有说明，否则此响应是可缓存的

300 - 永久移动

被请求的资源已经被分配了一个新的永久 URI，以后对该资源的任何引用都应该使用返回的 URI 之一
在可能的情况下，具有链接编辑功能的客户端应该自动将请求 URI 的引用重新链接到服务器返回的一个或多个新引用
除非另有说明，否则此响应是可缓存的

新的永久 URI 应该由响应中的 Location 字段给出
除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新 URI 的超链接

如果收到 301 状态代码以响应除 GET 或 HEAD 之外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会更改发出请求的条件

当自动重定向 POST 请求后
接收 301 状态代码，一些现有的 HTTP/1.0 用户代理
将错误地将其更改为 GET 请求

302 - 发现

请求的资源临时驻留在不同的 URI 下
由于有时可能会更改重定向，因此客户端应该继续使用 Request-URI 来处理未来的请求
如果由 Cache-Control 或 Expires 标头字段指示，则此响应仅可缓存

临时 URI 应该由响应中的 Location 字段给出
除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新 URI 的超链接

如果收到 302 状态码以响应 GET 或 HEAD 以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件

RFC 1945 和 RFC 2068 指定不允许客户端更改重定向请求的方法
然而，大多数现有的用户代理实现将 302 视为 303响应，对 Location 字段值执行 GET，不管原始请求方法状态码 303 和 307
有为希望明确说明哪些服务器添加了期待客户的反应

303 - 见其他

对请求的响应可以在不同的 URI 下找到，并且应该使用该资源的 GET 方法检索
此方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源
新的 URI 不是原始请求资源的替代引用。303 响应不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的

不同的 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新 URI 的超链接

许多 HTTP/1.1 之前的用户代理不理解 303地位
当与此类客户端的互操作性是一个问题时，可以使用 302 状态码来代替，因为大多数用户代理都会做出反应到 302 响应，如此处针对 303 所述

304 - 未修改

如果客户端已经执行了一个有条件的 GET 请求并且允许访问，但是文档没有被修改，服务器应该用这个状态码来响应
304 响应不能包含消息体，因此总是由头字段后的第一个空行终止

如果无时钟源服务器遵守这些规则，并且代理和客户端将他们自己的日期添加到任何没有收到的响应中，缓存将正确运行

如果条件 GET 使用强缓存验证器，则响应不应包含其他实体头
否则（即，条件 GET 使用弱验证器），响应不得包含其他实体头；这可以防止缓存的实体主体和更新的标头之间出现不一致

如果 304 响应指示当前未缓存的实体，则缓存必须忽略响应并在没有条件的情况下重复请求

如果缓存使用收到的 304 响应来更新缓存条目，则缓存必须更新条目以反映响应中给出的任何新字段值

305 - 使用代理

请求的资源必须通过 Location 字段给出的代理访问
Location 字段给出了代理的 URI。接收者应该通过代理重复这个单一的请求
305 响应只能由源服务器生成

RFC 2068 不清楚 305 旨在重定向单个请求，并且仅由源服务器生成
不是遵守这些限制会产生重大的安全后果

306 - 无

306 状态码在之前版本的规范中使用过，不再使用，保留该码

307 - 临时重定向

请求的资源临时驻留在不同的 URI 下
由于有时可能会更改重定向，因此客户端应该继续使用 Request-URI 来处理未来的请求
如果由 Cache-Control 或 Expires 标头字段指示，则此响应仅可缓存

临时 URI 应该由响应中的 Location 字段给出
除非请求方法是 HEAD，否则响应的实体应该包含一个带有指向新 URI 的超链接的短超文本注释，因为许多 HTTP/1.1 之前的用户代理不理解 307 状态
因此，注释应该包含用户在新 URI 上重复原始请求所需的信息

如果收到 307 状态代码以响应 GET 或 HEAD 以外的请求，则用户代理不得自动重定向请求，除非用户确认该请求，因为这可能会更改发出请求的条件

客户端错误:4xx

4xx 类状态代码用于客户端似乎出错的情况
除了响应 HEAD 请求时，服务器应该包含一个实体，其中包含对错误情况的解释，以及它是暂时的还是永久的情况
这些状态代码适用于任何请求方法。用户代理应该向用户显示任何包含的实体

如果客户端正在发送数据，使用 TCP 的服务器实现应该小心确保客户端在服务器关闭输入连接之前确认收到包含响应的数据包
如果客户端在关闭后继续向服务器发送数据，则服务器的 TCP 堆栈将向客户端发送一个重置数据包，这可能会在 HTTP 应用程序读取和解释客户端未确认的输入缓冲区之前擦除它们

400 - 错误请求

由于语法格式错误，服务器无法理解该请求
客户端不应该在没有修改的情况下重复请求

401 - 未授权

该请求需要用户身份验证
响应必须包含一个 WWW-Authenticate 头域，其中包含适用于所请求资源的质询
客户端可以使用合适的 Authorization 头字段重复请求。如果请求已包含授权凭据，则 401 响应指示对这些凭据的授权已被拒绝
如果 401 响应包含与先前响应相同的质询，并且用户代理已经至少尝试过一次身份验证，那么应该向用户呈现响应中给出的实体，因为该实体可能包含相关的诊断信息
HTTP 访问身份验证在“HTTP 身份验证：基本和摘要式访问身份验证” 中进行了解释

402 - 登入错误

此代码保留供将来使用

403 - 禁止

服务器理解请求，但拒绝满足它
授权无济于事，不应重复该请求
如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，它应该在实体中描述拒绝的原因
如果服务器不想让客户端可以使用此信息，则可以使用状态代码 404（未找到）来代替

404 - 未找到

服务器未找到任何与请求 URI 匹配的内容
没有说明这种情况是暂时的还是永久性的
如果服务器通过某些内部可配置机制知道旧资源永久不可用且没有转发地址，则应使用 410（消失）状态代码
当服务器不想透露请求被拒绝的确切原因时，或者当没有其他响应适用时，通常使用此状态代码

405 - 方法不允许

对于由 Request-URI 标识的资源，不允许在 Request-Line 中指定的方法
响应必须包含一个 Allow 头，其中包含所请求资源的有效方法列表

406 - 不可接受

请求标识的资源只能根据请求中发送的 accept 头生成具有不可接受的内容特征的响应实体

除非是 HEAD 请求，否则响应应该包含一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的一个
实体格式由 Content-Type 头字段中给出的媒体类型指定。根据用户代理的格式和能力，可以自动执行最合适的选择
但是，本规范没有为这种自动选择定义任何标准

允许 HTTP/1.1 服务器返回响应根据发送的接受标头是不可接受的要求
在某些情况下，这甚至可能比发送406响应。鼓励用户代理检查确定它是否可接受的传入响应

如果响应可能是不可接受的，用户代理应该暂时停止接收更多数据并询问用户对进一步操作的决定

407 - 需要代理认证

此代码类似于 401（未授权），但表示客户端必须首先向代理进行身份验证
代理必须返回一个 Proxy-Authenticate 头字段，其中包含适用于所请求资源的代理的质询
客户端可以使用合适的 Proxy-Authorization 头域重复请求
HTTP 访问身份验证在“HTTP 身份验证：基本和摘要式访问身份验证”

408 - 请求超时

客户端没有在服务器准备等待的时间内产生请求。客户端可以在以后的任何时间不加修改地重复请求

409 - 冲突

由于与资源的当前状态冲突，无法完成请求
仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应主体应该包括足够的

供用户识别冲突来源的信息。理想情况下，响应实体应包含足够的信息供用户或用户代理解决问题；然而，这可能是不可能的，也不是必需的

响应 PUT 请求时最有可能发生冲突
例如：如果正在使用版本控制并且被 PUT 的实体包含对资源的更改，该更改与之前（第三方）请求所做的更改发生冲突，则服务器可能会使用 409 响应来指示它无法完成请求.在这种情况下，响应实体可能会以响应 Content-Type 定义的格式包含两个版本之间差异的列表

410 - 不见了

请求的资源在服务器上不再可用，并且不知道转发地址
预计这种情况将被视为永久性的
具有链接编辑功能的客户端应该在用户批准后删除对 Request-URI 的引用
如果服务器不知道或无法确定条件是否永久，则应使用状态代码 404（未找到）代替
除非另有说明，否则此响应是可缓存的

410 响应的主要目的是通过通知接收者资源故意不可用以及服务器所有者希望删除到该资源的远程链接来协助 Web 维护任务
这种事件对于限时促销服务和属于不再在服务器站点工作的个人的资源来说很常见。没有必要将所有永久不可用的资源标记为“消失”或将标记保留任何时间长度——这由服务器所有者自行决定

411 - 所需长度

服务器拒绝接受没有定义内容长度的请求
如果客户端在请求消息中添加了包含消息正文长度的有效 Content-Length 头字段，则客户端可以重复该请求

412 - 先决条件失败

当在服务器上测试时，在一个或多个请求头字段中给出的前提条件评估为假
此响应代码允许客户端在当前资源元信息（头字段数据）上设置前提条件，从而防止将请求的方法应用于预期资源之外的资源

413 - 请求实体太大

服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的
服务器可以关闭连接以防止客户端继续请求

如果条件是临时的，服务器应该包含一个 Retry-After 头域来指示它是临时的，并且在什么时间之后客户端可以再试一次

414 - 请求 URI 太长

服务器拒绝为请求提供服务，因为 Request-URI 比服务器愿意解释的要长
这种罕见的情况只可能发生在客户端不正确地将 POST 请求转换为带有长查询信息的 GET 请求时，当客户端下降到重定向的 URI“黑洞”（例如：指向的重定向 URI 前缀）本身的后缀），或者当服务器受到客户端的攻击时，客户端试图利用某些服务器中存在的安全漏洞来读取或操作请求 URI 的固定长度缓冲区

415 - 不支持的媒体类型

服务器拒绝为请求提供服务，因为请求实体的格式不为请求方法的请求资源所支持

416 - 请求范围不满足

如果请求包含 Range request-header 字段，并且该字段中的任何范围说明符值都不与所选资源的当前范围重叠，并且请求没有包括一个 If-Range 请求头字段
（对于字节范围，这意味着所有字节范围规范值的第一个字节位置大于所选资源的当前长度）

当为字节范围请求返回此状态代码时，响应应该包含一个 Content-Range 实体头字段，指定所选资源的当前长度
此响应不得使用 multipart/byteranges 内容类型

417 - 期望失败

该服务器无法满足在 Expect 请求标头字段中给出的期望，或者，如果服务器是代理，则该服务器有明确的证据表明该请求无法被下一跳服务器满足

服务器错误:5xx

以数字“5”开头的响应状态代码表示服务器知道它出错或无法执行请求的情况
除了响应 HEAD 请求时，服务器应该包含一个实体，其中包含对错误情况的解释，以及它是暂时的还是永久的情况

用户代理应该向用户显示任何包含的实体
这些响应代码适用于任何请求方法

500 - 内部服务器错误

服务器遇到意外情况，无法完成请求

501 - 未实现

服务器不支持完成请求所需的功能
当服务器无法识别请求方法并且无法为任何资源支持它时，这是适当的响应

502 - 坏网关

服务器在充当网关或代理时，从它访问的上游服务器收到无效响应，以尝试满足请求

503 - 服务不可用

由于服务器暂时过载或维护，服务器当前无法处理请求
这意味着这是一个暂时的情况，将在一些延迟后得到缓解

如果已知，延迟的长度可以在 Retry-After 头中指示
如果没有给出 Retry-After，客户端应该像处理 500 响应一样处理响应

503 状态码的存在并不意味着服务器在过载时必须使用它
些服务器可能希望简单地拒绝连接

504 - 网关超时

该服务器在充当网关或代理时，没有收到来自 URI（例如：HTTP、FTP、LDAP）指定的上游服务器或它在尝试完成时需要访问的其他辅助服务器（例如：DNS）的及时响应请求

实现者注意：一些部署的代理是已知的当 DNS 查找超时时返回 400 或 500

505 - 不支持 HTTP版本

服务器不支持或拒绝支持请求消息中使用的 HTTP 协议版本
服务器表明它无法或不愿意使用与客户端相同的主要版本完成请求，如上所述，除了此错误消息。响应应该包含一个实体，描述为什么不支持该版本以及该服务器支持哪些其他协议

前言