「开位」你所应该知道的HTTP——拓展篇

前言

接上篇，本篇主要对HTTP/1.1版本进行瓶颈分析，介绍为了解决这些问题，所提出的多个扩展协议和加强协议。

《你所应该知道的HTTP》系列的其余篇章：

• 基础篇
• 进阶篇
• 缓存篇
• HTTPS篇
• 优化篇

HTTP/1.1协议的瓶颈

1. 一条TCP链接上只可同时发送一个请求，请求低效。
2. 请求只能从客户端开始，客户端不能够接受除响应之外的指令。
3. 请求/响应头部不经压缩就发送。
4. 每次互相发送相同的头部形成的浪费较多。
5. 非强制性压缩发送。
6. 非强制性使用安全加密（STL/SSL）。

WebSocket协议

概述

做为HTTP的补充协议，能够实现双工通讯，即一问多答，也能够服务器主动推送。其实WebSocket只是借用HTTP完成“握手”，本质已经不一样。
WebSocket协议解决了HTTP/1.1瓶颈中①和②的问题。

WebSocket的“握手”

• 客户端请求头部
  请求报文头里新增：

Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: <随机加密串>
  Sec-WebSocket-Protocol: <自定义服务名>
  Sec-WebSocket-Version: <协议版本号>

• 服务器应答
  状态码：101 Switching Protocols
  响应报文头里新增：

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <加密key>
Sec-WebSocket-Protocol: <自定义服务名>

过程如图：

特色

• 真正的全双工方式：突破HTTP一问一答的模式；
• 减小通讯量：复用TCP链接，只需一次“握手”。

SPDY

概述

谷歌于2012年提出SPDY，它是的基于TCP协议的会话层协议，属于加强HTTP协议。SPDY一直处于草案阶段，如今已经被HTTP/2.0取代，Chrome 51已经移除对SPDY的支持。
SPDY协议解决了HTTP/1.1瓶颈中①、③、⑤和⑥的问题，部分解决了②。

结构

SPDY定义为会话层协议（OSI模型），在TCP/IP模型中能够归类为应用层，介于STL/SSL与HTTP之间。
从底网上分别是：
IP=>TCP=>TLS/SSL=>SPDY=>HTTP

结构如图：（图片来自网络）

特色

• 多路复用（多个请求并发在一个TCP链接上）；
• 请求优化（优先级排序）；
• 消息—帧机制；
• 支持服务器推送技术；
• 强制性压缩（包括HTTP头部）
• 强制使用SSL传输协议。

HTTP/2.0

概述

HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY协议。
HTTP/2.0基本上都能解决上面提到的有关HTTP/1.0遇到的瓶颈。

分层结构

HTTP/2.0在原有的HTTP层前加入了分帧层，相似与SPDY协议的结构，分帧层介于STL/SSL与HTTP之间。

• 分帧层：HTTP/2.0特性的核心部分；
• 数据/HTTP层：其中包含传统上被认为是HTTP及其关联数据的部分。

结构如图：（图片来自网络）

特色：

• 二进制分帧
  HTTP/2.0的分帧层是基于帧的二进制协议，最小消息单位是帧。这方便了机器解析，解析更加高效。每一个数据流都以消息的形式发送，而消息由一个或多个帧组成。多个帧之间能够乱序发送，根据帧首部的流标识能够从新组装。
• 首部压缩
  H2在客户端和服务端使用“首部表”来跟踪和存储以前发送的头部键值对，每次只须要差量更新，不须要重复交换;
  首部表在H2的链接存续期内始终存在，由客户端和服务器共同渐进地更新；
  头部内容也会被压缩处理。
• 多路复用
  基于二进制分帧的特性，全部请求经过一个TCP链接并发完成，不在依赖多开TCP链接去实现并行加载。
• 并行双向字节流的请求和响应
  基于二进制分帧的特性，同一个TCP链接上同时有多个不一样方向的数据流，所以客户端能够一边乱序发送，一边接收响应，服务器也如此。
• 加密传输
  虽然协议并未严格限制，但现代浏览器都要求必须使用HTTPS，已成为了事实上的强制标准。
• 服务器推送
  服务器能够主动将HTML页面相关的js和css文件推送给浏览器，不须要等待浏览器解析HTML后再发起请求获取。遵循同源策略，浏览器可拒绝。
• 请求优先级
  基于二进制分帧的特性，请求能够带上32bit的优先级值，0表示最高优先级，数值越大优先级越低，能够制定策略优化传输。

存在的问题

HTTP/2.0虽然已经解决了HTTP/1.0的诸多瓶颈问题，但依然存在问题，这些问题基本都是因为TCP协议自己的限制致使的。

• 队头阻塞：这是TCP协议自己可靠性的重传机制致使的问题，若是出现丢包，那就会不断重试。这时候又只有一条TCP链接，因此会致使性能还不如HTTP1.1。
• 握手延迟大：TCP协议的三次握手依然没法避免。

QUIC

概述

QUIC是Quick UDP Internet Connections的缩写，读做quick。由Google开发。
能够认为QUIC是为了解决HTTP/2.0在TCP遇到的瓶颈，而在UDP上作探索所设计的方案。（参考上面HTTP2的存在问题）

特性

• 没有队头阻塞的多路复用。
• UDP协议依据id寻找目标设备，在多变的移动网络有优点。
• 前向纠错，每一个包还包括其余包的部分信息，能够在丢包的状况下依靠已接受的包的冗余数据拼凑出丢失的部分，减小重传。
• 不须要屡次握手，下降延迟。