前面两篇文章中关于 HTTP 相关知识基本上介绍的差不多了，这篇文章是对 HTTP 协议的补充，主要介绍以下三点内容：

1. 确保 Web 安全的 HTTPS
2. 确认访问用户身份的认证
3. 基于 HTTP 的功能追加协议

1.确保 Web 安全的 HTTPS

1.1 HTTP 的缺点

HTTP 的不足主要有以下几点：

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

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

1.1.1 通信使用明文可能会被窃听

由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文使用明文（指未经加密的报文）方式发送。

1. TCP/IP 是可能被窃听的网络

因为按 TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭遇到窥视，所以说通信不加密是一个缺点。

即使已经过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

窃听相同段上的通信并非难事。只需要收集在互联网上流动的数据包（帧）就行了。对于收集来的数据包的解析工作，可交给那些抓包或嗅探器工具。

http-defect.png

2. 加密处理防止被窃听

• 通信的加密

  一种方式是将通信加密。HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全传输层协议）的组合使用，加密 HTTP 的通信内容。

http_encrypt.png

用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS （HTTP Secure，超文本传输安全协议）或 HTTP over SSL。

• 内容的加密
  还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP 报文里所含的内容进行加密处理。

http_encrypt1.png

诚然，为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。

1.1.2 不验证通信方的身份就可能遭遇篡改

HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在"服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端"等类似问题。

• 任何人都可发起请求

  在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）。

http_request_all.png

HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患：

1. 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
2. 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
3. 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。
4. 无法判定请求是来自何方、出自谁手。
5. 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击。

• 查明对手的证书

  虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。SSL 不仅提供加密处理，而且还使用一种被称为证书的手段，可用于确定方。

  证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。

http_request.png

通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。另外，客户端持有证书即可完成个人身份的确认，也可用于对 Web 网站的认证环节。

1.1.3 无法证明报文完整性，可能已遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。

• 接收到的内容可能有误
  由于 HTTP 协议无法证明通信的报文的完整性，因此，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

http_revise.png

像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击。

http_revise1.png

• 如何防止篡改

  虽然有使用 HTTP 协议确认报文完整性的方法，但事实上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。

  提供文件下载服务的 Web 网站也会提供相应的以 PGP（Pretty Good Privacy，完美隐私）创建的数字签名及 MD5 算法生成的散列值。PGP 是用来证明创建文件的数字签名，MD5 是由单向函数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。

  可惜的是，这些办法也依然无法百分之百保证确认结果正确。因为 PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。

  为了有效防止这些弊端，有必要使用 HTTPS。SSL 提供认证和加密处理及摘要功能。仅靠 HTTP 确保完整性是非常困难的，因此通过和其他协议组合使用来实现这个目标。

1.2 HTTP + 加密 + 认证 + 完整性保护 = HTTPS

1.2.1 HTTP 加上加密处理和认证及完整性保护后即是 HTTPS

如果在 HTTP 协议通信过程中使用未经加密的明文，比如在 Web 页面中输入信用卡号，如果这条通信线路遭到窃听，那么信用卡号就暴露了。

另外，对于 HTTP 来说，服务器也好，客户端也好，都是没有办法确认通信方的。因为很有可能并不是和原来预想的通信方在实际通信。并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能性。

为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure）。

https.png

1.2.2 HTTPS 是身披 SSL 外壳的 HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。

通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 外壳的 HTTP。

https1.png

在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

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

1.2.3 相互交换密钥的公开密钥加密技术

SSL 采用一种叫做公开密钥加密的加密处理方式。

近代的加密方法中的加密算法是公开的，而密钥确实保密的。通过这种方式得以保持加密方法的安全性。

加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。

• 共享密钥加密的困境
  加密和解密同用一个密钥的方式叫做共享密钥加密，也被称为对称密钥加密。

https2.png

以共享密钥方式加密时必须将密钥也给对方。可究竟怎样才能安全的转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

https3.png

• 使用两把密钥的公开密钥加密

  公开密钥加密方式很好地解决了共享密钥加密的困难。

  公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。私有密钥不能让其他任何人知道，而公有密钥则可以随意发布，任何人都可以获得。

  使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

  另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。

https4.png

• HTTPS 采用混合加密机制
  HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密和共享密钥加密相比，其处理速度要慢。

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

https5.png

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

在公开密钥加密方式中也存在一些问题，那就是无法证明公开密钥本身就是货真价实的公开密钥。

为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其他相关颁发的公开密钥证书。

数字证书认证机构处于客户端和服务器双方都可信赖的第三方机构的立场上。数字证书认证机构的流程是：首先，服务器的运营人员向数字证书认证机构提供公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

https6.png

• 可证明组织真实性的 EV SSL 证书
  证书的一个作用是用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书是 EV SSL 证书。

  EV SSL 证书是基于国际标准的认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针，因此，通过认证的 Web 网站能够获得更高的认可度。

• 用以确认客户端的客户端证书

  HTTPS 中还可以使用客户端证书。以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙。

• 认证机构信誉第一
  SSL 机制中介入认证机构之所以可行，是因为建立在其信用绝对可靠这一大前提下的。

• 由自认证机构颁发的证书称为自签名证书
  如果使用 OpenSSL 这套开源程序，每个人都可以构建一套属于自己的认证机构，从而给自己颁发服务器证书。但该服务器证书在互联网上不可作为证书使用，似乎没什么帮助的。

  独立机构的认证机构叫做自认证机构，由自认证机构颁发的“无用”证书也被戏称为自签名证书。

1.2.5 HTTPS 的安全通信机制

为了更好的理解 HTTPS，我们来观察一下 HTTPS 的通信步骤。

https7.png

• 步骤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 报文。

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

下面是对整个流程的图解。图中说明了从仅适用服务器端的公开密钥证书（服务器证书）建立 HTTPS 通信的整个过程。

https8.png

• SSL 速度慢吗
  HTTPS 也存在一些问题，那就是当使用 SSL 时，它的处理速度会变慢。

https9.png

SSL 的慢是分两种。一种是指通信慢。另一种是指由于大量消耗 CPU 及内存等资源，导致处理速度变慢。

和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和 TCP 连接、发送 HTTP 请求/响应外，还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加。

另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。

针对速度变慢这一问题，并没有根本性的解决方案，我们会使用 SSL 加速器这种（专用服务器）硬件来改善该问题。该硬件为 SSL 通信专用硬件，相对软件来讲，能够提高数倍 SSL 的计算速度。仅在 SSL 处理时发挥 SSL 加速器的功效，以分担负载。

为什么不一直使用 HTTPS
1. 因为与纯文本通信相比，加密通信会消耗更多的 CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量也必然减少。

因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。
2. 除此之外，想要节约购买证书的开销也是原因之一。

2. 确认访问用户身份的认证

2.1 何为认证

计算机本身无法判断坐在显示器前的使用者的身份，为了确认是谁在访问服务器，需要核对“登录者本人才知道的信息”、“登录者本人才会有的信息”。核对的信息通常是指以下这些：

• 密码：只有本人才会知道的字符串信息。
• 动态令牌：仅限本人持有的设备内显示的一次性密码。
• 数字证书：仅限本人（终端）持有的信息。
• 生物认证：指纹和虹膜等本人的生理信息
• IC 卡等：仅限本人持有的信息。

HTTP 使用的认证方式
HTTP/1.1 使用的认证方式如下所示：

• BASIC认证（基本认证）
• DIGEST认证（摘要认证）
• SSL 客户端认证
• FormBase 认证（基于表单认证）

2.2 BASIC 认证

BASIC 认证（基本认证）是从 HTTP/1.0 就定义的认证方式。即便是现在仍有一部分的网站会使用这种认证方式。是 Web 服务器与通信客户端之间进行的认证方式。

• BASIC 认证的认证步骤

basic.png

步骤1：当请求的资源需要 BASIC 认证时，服务器会随状态码 401 Authorization Required，返回带 WWW-Authenticate 首部字段的响应。该字段内包含认证的方式（BASIC）及 Request-URI 安全域字符串（realm）。

步骤2：接收到状态码 401 的客户端为了通过 BASIC 认证，需要将用户 ID 及密码发送给服务器。发送的字符串内容是由用户 ID 和密码构成，两者中间以冒号（：）连接后，再经过 Base64 编码处理。将编码后的字符串写入首部字段 Authorization 后，发送请求。

步骤3：接收到包含首部字段 Authorization 请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含 Request-URI 资源的响应。

BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理。不需要任何附加信息即可对其解密。换言之，由于明文解码后就是用户 ID 和密码，在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程中，如果被人窃听，被盗的可能性极高。

另外，除此之外想再进行一次 BASIC 认证时，一般的浏览器却无法实现认证注销操作，这也是问题之一。

BASIC 认证使用上不够灵活，且达不到多数 Web 网站期望的安全性等级，因此它并不常用。

2.3 DIGEST 认证

为弥补 BASIC 认证存在的弱点，从 HTTP/1.1 起就有了 DIGEST 认证。DIGEST 认证同样使用质询/响应的方式（challenge/response），但不会像 BASIC 认证那样直接发送明文密码。

所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的咨询码计算生成响应码。最后将响应码返回给对方进行认证的方式。

digest.png

因为发送给对方的只是响应摘要及由知讯码产生的计算结果，所以比起 BASIC 认证，密码泄露的可能性就降低了。

• DIGEST 认证的认证步骤

digest1.png

步骤1：请求需认证的资源时，服务器会随着状态码 401 Authorication Required，返回带 WWW-Authenticate 首部字段的响应。该字段内包含质问响应方式认证所需要的临时咨询码（随机数，nonce）。

首部字段 WWW-Authenticate 内必须包含 realm 和 nonce 这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。

nonce 是一种每次随返回的 401 响应生成的任意随机字符串。该字符串通常推荐由 Base64 编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现

步骤2：接收到401 状态码的客户端，返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息。首部字段 Authorization 内必须包含 username、realm、nonce、uri 和 response 的字段信息，其中，realm 和 nonce 就是之前从服务器接收到的响应中的字段。

步骤3：接收到包含首部字段 Authorization 请求的服务器，会确认认证信息的正确性。认证通过后则会返回包含 Request-URI 资源的响应。

并且这时会在首部字段 Authorization-Info 写入一些认证成功的相关信息。

2.4 SSL 客户端认证

SSL 客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自登录的客户端。

2.4.1 SSL 客户端认证的认证步骤

为达到 SSL 客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。

步骤1：接收到需要认证资源的请求，服务器会发送 Certificate Request 报文，要求客户端提供客户端证书。

步骤2：用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。

步骤3：服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。

2.4.2 SSL 客户端认证采用双因素认证

在多数情况下，SSL 客户端认证不会仅依靠证书完成认证，一般会和基于表单认证组合形成一种双因素认证来使用。所谓双因素认证就是指，认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为另一个因素，与其组合使用的认证方式。

换言之，第一个认证因素的 SSL 客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。

2.4.3 SSL 客户端认证必要的费用

使用 SSL 客户端认证需要用到客户端证书，而客户端证书需要支付一定费用才能使用。

2.5 基于表单认证

基于表单的认证方法并不是在 HTTP 协议中定义的。客户端会向服务器上的 Web 应用程序发送登录信息，按登录信息的验证结果认证。

多数情况下，输入已事先登录的用户 ID 和密码等登录信息后，发送给 Web 应用程序，基于认证结果来决定认证是否成功。

2.5.1 Session 管理及 Cookie 应用

基于表单认证的标准规范尚未有定论，一般会使用 Cookie 来管理 Session（会话）。

基于表单认证本身是通过服务器端的 Web 应用，将客户端发送过来的用户 ID 和密码与之前登录过的信息做匹配来进行认证的。

但鉴于 HTTP 是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来。即，无法实现状态管理，因此即使该用户下一次继续访问，也无法区分他与其他的用户。于是我们会使用 Cookie 来管理 Session，以弥补 HTTP 协议中不存在的状态管理功能。

cookie_session.png

步骤1：客户端会把用户 ID 和密码等登录信息放入报文的实体部分，通常是以 POST 方法把请求发送给服务器。而这时，会使用 HTTPS 通信来进行 HTML 表单画面的显示和用户输入数据的发送。

步骤2：服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态和 Session ID 绑定后记录在服务器端。

向客户端返回响应时，会在首部字段 Set-Cookie 内写入 Session ID。另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie 内加上 httponly 属性。

步骤3：客户端接收到从服务器端发来的 Session ID 后，会将其作为 Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送 Cookie，所以 Session ID 也随之发送到服务器。服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。

3. 基于 HTTP 的功能追加协议

3.1 基于 HTTP 的协议

HTTP 功能上的不足可通过创建一套全新的协议来弥补。可是目前基于 HTTP 的 Web 浏览器的使用环境已遍布全球，因此无法完全抛弃 HTTP。有一些新协议的规则是基于 HTTP 的，并在此基础上添加了新的功能。

3.2 消除 HTTP 瓶颈的 SPDY

Google 在 2010 年发布了 SPDY，其开发目标旨在解决 HTTP 的性能瓶颈，缩短 Web 页面的加载时间（50%）。

3.2.1 HTTP 的瓶颈

HTTP 存在以下缺点和不足：

• 一条连接上只可发送一个请求
• 请求只能从客户端开始，客户端不可以接收除响应以外的指令
• 请求/响应首部未经压缩就发送，首部信息越多延迟越大
• 发送冗长的首部，每次互相发送相同的首部造成的浪费较多
• 可任意选择数据压缩格式，非强制压缩发送

http_weakness.png

1. Ajax 的解决办法

Ajax 是一种有效利用 JavaScript 和 DOM 的操作，以达到局部 Web 页面替换加载的异步通信手段。和以前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量会因此而减少。

而利用 Ajax 实时地从服务器获取内容，有可能会导致大量请求产生。

http_ajax.png

2. Comet 的解决办法
   一旦服务器有内容更新了，Comet 不会让请求等待，而是直接给客户端返回响应。这是一种通过延时应答，模拟实现服务器向客户端推送的功能。

内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。期间，为了维持连接会消耗更多的资源。

http_comet.png

3.2.2 SPDY 的设计与功能

SPDY 没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY 规定通信中使用 SSL。

SPDY 以会话层的形式加入，控制对数据的流动，但还是采用 HTTP 建立通信连接。因此，可照常使用 HTTP 的 GET 和 POST 等方法，Cookie 以及 HTTP 报文等。

spdy.png

使用 SPDY 后，HTTP 协议额外获得以下功能。

• 多路复用流：通过单一的 TCP 连接，可以无限制处理多个 HTTP 请求。所有请求的处理都在一条 TCP 连接上完成，因此 TCP 的处理效率得到提高。
• 赋予请求优先级：SPDY 不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
• 压缩 HTTP 首部：压缩 HTTP 请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了
• 推送功能：支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
• 服务器提示功能：服务器可以主动提示客户端请求所需的资源。

3.2.3 SPDY 消除 Web 瓶颈了吗

因为 SPDY 基本上只是将多个域名（IP 地址）的通信多路复用，所以当一个 Web 网站上使用多个域名下的资源，改善效果就会收到限制。

3.3 使用浏览器进行全双工通信的 WebSocket

WebSocket 是为解决 HTTP 协议所面临的困难的一种新的协议及 API。

3.3.1 WebSocket 的设计与功能

WebSocket，即 Web 浏览器与 Web 服务器之间全双工通信标准。仍在开发中的 WebSocket 技术主要是为了解决 Ajax 和 Comet 里 XMLHttpRequest 附带的缺陷所引起的问题。

3.3.2 WebSocket 协议

一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可相互发送 JSON、XML、HTML 或图片等任意格式的数据。

由于是建立在 HTTP 基础上的协议，因此连接的发起方仍是客户端，而一旦确立 WebSocket 通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文。

下面我们列举一下 WebSocket 协议的主要特点：

• 推送功能：支持由服务器向客户端推送数据的推送功能
• 减少通信量：只要建立起 WebSocket 连接，就希望一直保持连接状态。和 HTTP 相比，不但每次连接时的总开销减少，而且由于 WebSocket 的首部信息很小，通信量也相应较少了。

为了实现 WebSocket 通信，在 HTTP 连接建立之后，需要完成一次 “握手” 的步骤。

1. 握手·请求
   为了实现 WebSocket 通信，需要用到 HTTP 的 Upgrade 首部字段，告知服务器通信协议发送改变，已达到握手的目的。

“GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13”

Sec-WebSocket-Protocol 字段内记录着握手过程中必不可少的键值，Sec-WebSocket-Protocol 字段内记录使用的子协议。

子协议按 WebSocket 协议标准在连接分开使用时，定义那些连接的名称。

2. 握手·响应
   对于之前的请求，返回状态码 101 Switching Protocols 的响应。

“HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat”

Sec-WebSocket-Accept 的字段值是由握手请求中的 Sec-WebSocket-Accept 的字段值生成的。

成功握手确立 WebSocket 连接之后，通信时不再使用 HTTP 的数据帧，而采用 WebSocket 独立的数据帧。

websocket.png

3.4 期盼已久的 HTTP/2.0

HTTP/2.0 在 2014 年 11 月实现标准化。

• HTTP/2.0 的特点
  HTTP/2.0 的目标是改善用户在使用 Web 时的速断体验。

HTTP/2.0 围绕着主要的 7 项技术进行讨论。