什么是 HTTP？

HTTP 是 Web 使用的一种名为 HTTP（HyperText Transfer Protocol，超文本传输协议）的协议规范，和 TCP/IP 协议族内的其他众多的协议相同，用于客户端和服务器之间的通信。HTTP 协议规定，请求从客户端发出，服务器端响应该请求并返回响应报文。响应报文由协议版本、状态码、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。

HTTP 协议通过 URI 定位资源。早期的 HTTP1.0 主要为了支持小文本传输，因此，并不支持持久链接，即每进行一次 HTTP 通信就要断开一次 TCP 连接。HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是，只要任意一端 没有明确提出断开连接，则保持 TCP 连接状态。持久连接使得请求以管线化（pipelining）方式发送成为可能，管线化方式的出现，极大的提升了网络传输的效率，节省了数据传输的时间。

HTTP 是一种无状态（stateless）的协议，但可以使用 Cookie 进行状态管理。

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

HTTP 报文大致可分为报文首部和报文主体两块，两者通过空行（CR+LF）来划分。需要注意的是，并不一定要有报文主体。

报文的结构如下图所示：

HTTP 在传输数据时可以按照数据原貌直接传输，也可以在传输过程中通过编码提升传输速率。通过在传输时编码，能高效地处理访问请求的速度。但是，编码的操作需要计算机来完成，因此会消耗更多的 CPU 等资源。

在 HTTP 通信过程中，请求的编码实体资源尚未全部传输完成之前， 浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标 记。使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。

HTTP 还可以发送多种数据，例如，在发送邮件中，我们可以在邮件里写入文字并添加多份附件。这是因为采用了 MIME（Multipurpose Internet Mail Extensions，多用途因特网邮件扩展）机制，它允许邮件处理文本、图片、视频等多个不同类型的数据。

HTTP1.0 和 HTTP1.1 支持的方法如下表所示：

什么是 HTTPS？

上面介绍了诸多 HTTP 的特性，然而，尽管 HTTP 已经如此强大，却还有很多不足之处：

1. 通信使用明文（不加密），内容可能会被窃听
2. 不验证通信方的身份，因此有可能遭遇伪装
3. 无法证明报文的完整性，所以有可能已遭篡改

这些问题不仅在 HTTP 上出现，其他未加密的协议中也会存在这类问题。

除此之外，HTTP 本身还有很多缺点。而且，还有像某些特定的 Web 服务器和特定的 Web 浏览器在实际应用中存在的不足（也可以说成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等编程语言开发的 Web 应用也可能存在安全漏洞。

HTTPS 就是为了解决 HTTP 的这些问题而诞生的，简而言之

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替。通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL协议这层外壳的 HTTP。如下图所示：

SSL是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术。

HTTPS 混合加密机制

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。

其中，共享密钥加密指加密和解密同用一个密钥，这种方式的优点是相对较快，缺点是在互联网上转发密钥时，如果通信被监听，加密使用的密钥落入攻击者手中，加密就失去了意义。

而公开密钥加密使用两把密钥加密，一把叫做私有密钥 （private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。发送密文的一方使用对方的公开密钥进 行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。公开密钥加密与共享密钥加密相比，更安全，但是处理速度要慢。

HTTPS 充分利用两者各自的优势，将两种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

证明公开密钥正确性的证书

公开密钥加密方式还是存在一些问题的，那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

为了解决上述问题，HTTPS 使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。威瑞信（VeriSign）就是其中一家非常有名的数字证书认证机构。

简单介绍一下数字证书认证机构的业务流程。首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证 机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二， 服务器的公开密钥是值得信赖的。认证机关的公开密钥必须安全地转交给客户端。进行通信时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

• 可证明组织真实性的 EV SSL 证书：EV SSL证书是基于国际标准的认证指导方针颁发的证书。严格规定了对运营组织是否真实的确认方针，因此，通过认证的 Web 网站能够获得更高的认可度。
• 用以确认客户端的客户端证书：客户端证书需要付费购买，只有安全性极高的认证机构可颁发客户端证书。
• 认证机构信誉第一：因为证书上有正规认证机构的数字签名，所以浏览器会判定证书是正当的。但当伪造的证书被用做服务器伪装时，用户根本无法察觉到。虽然存在可将证书无效化的证书吊销列表（Certificate Revocation List，CRL）机制，以及从客户端删除根证书颁发机构（Root Certificate Authority，RCA）的对策，但是距离生效还需要一段时间，而在这段时间内，到底会有多少用户的利益蒙受损失就不得而知了。
• 由自认证机构颁发的证书称为自签名证书：如果使用 OpenSSL这套开源程序，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书。独立构建的认证机构叫做自认证机构，由自认证机构颁发的“无用”证书也被戏称为自签名证书。浏览器访问该服务器时，会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等警告消息。值得信赖的第三方机构介入认证，才能让已植入在浏览器内的认证机构颁布的公开密钥发挥作用，并借此证明服务器的真实性。

HTTPS 通信步骤

1. 客户端通过发送 Client Hello 报文进行 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
2. 服务器可进行 SSL通信时，会响应 Server Hello 报文。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
3. 服务器发送 Certificate 报文。报文中包含公开密钥证书。
4. 服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
5. SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
6. 客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
7. 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
8. 服务器同样发送 Change Cipher Spec 报文。
9. 服务器同样发送 Finished 报文。
10. 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
11. 应用层协议通信，即发送 HTTP 响应。
12. 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。

在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。

SSL 和 TLS

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）这两个协议。其中，SSL 协议技术最初是由浏览器开发商网景通信公司率先倡导的，但由于 SSL1.0 协议在设计之初被发现出了问题，就没有实际投入使用。SSL2.0 也被发现存在问题，所以很多浏览器直接废除了该协议版本。目前使用的 SSL3.0 协议是由 IETF（Internet Engineering Task Force，Internet 工程任务组）主导制定的，IETF 以 SSL3.0 为基准，后又制定了 TLS1.0、TLS1.1 和 TLS1.2。

TSL 是以 SSL 为原型开发的协议，有时会统一称该协议 为 SSL。当前主流的版本是 SSL3.0 和 TLS1.0。

HTTPS 引入 SSL 之后，存在两个问题：

1. 客户端和服务器都需要进行加密、解密处理，会消耗更多的 CPU 和内存资源；
2. SSL 需要在通信时额外进行处理，因此会有时间上的延迟；

HTTPS 的网络负载是 HTTP 的 2～100 倍，针对速度慢这一问题，没有根本性的解决方案，唯一可用的方式是使用 SSL 加速器（专用服务器）硬件进行改善。

HTTPS 的缺点

与明文传输相比，HTTPS 每次通信都加密，会消耗相当多的资源，特别是对访问量较多的 Web 网站进行加密处理时，这些额外的负载不可小觑。除此之外，要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。通常，一年的授权需要数万日元（现在一万日元大约折合 600 人民币）。

最后

我的个人主页 里也同步进行了更新，欢迎来逛逛。