一、HTTP的历史

早在HTTP建立之初，主要就是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。也是说对于前端来说，我们所写的HTML页面将要放在我们的web服务器上，用户端通过浏览器访问url地址来获取网页的显示内容，但是到了WEB2.0以来，我们的页面变得复杂，不仅仅单纯的是一些简单的文字和图片，同时我们的HTML页面有了CSS，Javascript，来丰富我们的页面展示，当ajax的出现，我们又多了一种向服务器端获取数据的方法，这些其实都是基于HTTP协议的。同样到了移动互联网时代，我们页面可以跑在手机端浏览器里面，但是和PC相比，手机端的网络情况更加复杂，这使得我们开始了不得不对HTTP进行深入理解并不断优化过程中。

二、HTTP的基本优化

影响一个HTTP网络请求的因素主要有两个：带宽和延迟。

• 带宽：如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。

• 延迟：

• 浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。

• DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。

• 建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

三、HTTP1.0和HTTP1.1的一些区别

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。
主要区别主要体现在：

1. ** 缓存处理**，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

四、HTTPS与HTTP的一些区别

1. HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。

2. HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。

3. HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4. HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

五、SPDY：HTTP1.x的优化

2012年google如一声惊雷提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：

1. 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。

2. 请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。

3. header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。

4. 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。

5. 服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。SPDY构成图：

SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。

六、HTTP2.0性能惊人

HTTP/2: the Future of the
Internet
是 Akamai 公司建立的一个官方的演示，用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同时请求 379
张图片，从Load time 的对比可以看出 HTTP/2 在速度上的优势。

七、HTTP2.0：SPDY的升级版

HTTP2.0可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：

HTTP2.0和SPDY的区别：

1. HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS

2. HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE

八、HTTP2.0和HTTP1.X相比的新特性

1. 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

2. 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

3. header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

4. 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

九、HTTP2.0的升级改造

1. 前文说了HTTP2.0其实可以支持非HTTPS的，但是现在主流的浏览器像chrome，firefox表示还是只支持基于 TLS 部署的HTTP2.0协议，所以要想升级成HTTP2.0还是先升级HTTPS为好。

2. 当你的网站已经升级HTTPS之后，那么升级HTTP2.0就简单很多，如果你使用NGINX，只要在配置文件中启动相应的协议就可以了，可以参考NGINX白皮书，NGINX配置HTTP2.0官方指南。

3. 使用了HTTP2.0那么，原本的HTTP1.x怎么办，这个问题其实不用担心，HTTP2.0完全兼容HTTP1.x的语义，对于不支持HTTP2.0的浏览器，NGINX会自动向下兼容的。

十、附注

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？

• HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；

• HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

• HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

具体如图：

服务器推送到底是什么？

服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：

• 普通的客户端请求过程：

• 服务端推送的过程：

为什么需要头部压缩？

假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）,
而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）,
则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量。具体参考：[HTTP/2
头部压缩技术介绍](https://link.jianshu.com/?t=https://imququ.com/post/header-
compression-in-http2.html)

HTTP2.0多路复用有多好？

HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP
连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP
慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。

HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

十一、参考

HTTP/2.0
相比1.0有哪些重大改进？

深入研究：HTTP2
的真正性能到底如何

[HTTP/2 头部压缩技术介绍](https://link.jianshu.com/?t=https://imququ.com/post/header-
compression-in-http2.html)

一、序

Hi，大家好，我是承香墨影！

HTTP 协议在网络知识中占据了重要的地位，HTTP 协议最基础的就是请求和响应的报文，而报文又是由报文头（Header）和实体组成。大多数 HTTP
协议的使用方式，都是依赖设置不同的 HTTP 请求/响应 的 Header 来实现的。

本系列《实用 HTTP》就抛开常规的 Header 讲解式的表述方式，从实际问题出发，来分析这些 HTTP
协议的使用方式，到底是为了解决什么问题？同时讲解它是如何设计的和它实现原理。

HTTP
协议是一种无状态的“松散协议”，它不会记录不同请求的状态，并且因为它本身包含了两端（客户端和服务端），根据请求和响应来区分，它大部分的内容都只是一个建议，其实双边是可以不遵守此建议的。

“这里写了建议零售价 2 元…”

“哦，不接受建议！”

文本是本系列的第四篇，前三篇传送门：

• HTTP 的缓存机制

• HTTP 内容实体编码压缩机制

• HTTP 传输编码压缩机制

本身 HTTP 就是一个无状态的协议，但是有时候我们又有需要增加状态的需求，这个时候延伸出来了 Cookie，利用 Cookie
可以让传输的时候保持一些状态信息。

本文就来讲讲 Cookie 的所有细节。

二、Cookie的使用

2.1 什么是 Cookie？

先明确一点，Cookie 就是为了解决 HTTP 协议无状态的问题，接下来举个例子说明。

早年间医院对患者的病例还没有在线建档的时候，都需要患者在就医之前，办理一个病历的小册子，医生会在病历中写上此次就医的情况，什么时间、有什么表现的反映、诊断是什么病、开了一些什么药等等。如果下次又生病了，有病历的情况下，都会要求患者再把病历带上，这样医生就能通过病历了解到之前的情况。

在 Cookie 的实现上，也是这样的。

服务端（医生）在收到客户端（患者）请求的时候，将一些用户标识信息加入到 Cookie （病例）中，随着响应返回给客户端，客户端将 Cookie
中的信息存储在本地，下次再请求此服务器的时候，再将 Cookie 中携带的数据原样传输给服务端，此时服务端就能通过 Cookie
中的用户标识，识别出这是之前请求过的某个用户。

在这个例子中，服务端就是医生的角色、客户端是患者的角色、Cookie 就是病历。

Netscape 官方文档中的定义为：Cookie 是指在 HTTP 协议下，服务器或脚本可以维护客户端计算机上信息的一种方式 。通俗地说，Cookie
是一种能够让网站 Web 服务器把少量数据储存到客户端的硬盘或内存里，或是从客户端的硬盘里读取数据的一种技术。 Cookie 文件则是指在浏览某个网站时，由
Web 服务器的 CGI 脚本创建的存储在浏览器客户端计算机上的一个小文本文件。

2.2 一个完整的 Cookie 传输流程

HTTP 协议中的规则，都是通过在请求头和响应头中写入输入来实现，Cookie 也是这样的。

服务端通过 Set-Cookie 这个响应头来向客户端中写入 Cookie 信息，而客户端读取 Set-Cookie
这个响应头中的信息存储起来，在下次请求的时候取出来，再通过 Cookie 这个请求头，将 Cookie 的数据传输给服务端。

再看一个浏览器中，Cookie 使用的实例。

在响应头（Response Header）中，使用 Set-Cookie 传递不同的 Cookie 数据，多个数据可以分开成多个 Set-Cookie 头。

在请求头中（Request Header）中，使用 Cookie 这个请求头传递 Cookie 数据，不同的数据通过 ;分割。

三、Cookie 的细节

到这里，我想你应该弄清楚了 cookie 的整个执行流程，接下来我们再来探究一些 cookie 的细节。

3.1 Cookie 的类型

cookie 其实都是存储在客户端，通常我们说 cookie 对应的客户端，就是在说浏览器。

对于 cookie，我们可以简单的将 cookie 分为两类：

• 会话 cookie。

• 持久 cookie。

会话 cookie 是一种临时的 cookie，用于存储一些临时的信息，存储在内存中，会话 cookie 在用户退出浏览器的时候，会被清空删除。而持久
cookie 的生存周期会更长久一些，被存储在磁盘上，浏览器重启后它们依然存在，但是他们会有一个过期的时间，只在此时间之后会被置为失效。

会话 cookie 和持久 cookie 之间唯一的区别就是它们的过期时间，只要是设置了过期时间的 cookie 就是持久 cookie，反之则是会话
cookie。

仔细看前面的流程图中，有一个 domain 的字段是用于标识当前 Cookie 支持的域名的，而想要设置过期时间，可以使用 Expires 或者 Max-
Age 参数进行设置，有点类似我们前面讲 HTTP 缓存的参数。

3.2 Cookie 的配置参数

到现在我们已经介绍了两个 Cookie 配置的信息，Domain 和 Expires/Max-Age，分别用来配置域名和过期策略。

这些都很好理解，毕竟浏览器是开放的，它会访问很多不同的网址，如果每个请求都将所有的 Cookie 信息都传递过去，基本上是不现实的。而这些配置参数，就是对
Cookie 增加一些附加的设置，进行一些简单的限制和过滤，在减少传输量的同时也保证了安全。

Domain 这个参数可以限制只在此域名下的请求，才传递该 Cookie，其他的不传递。

Cookie 其实还支持其他的一些参数配置，打开 Chrome 的调试模式，在 Application 中就可以看到当前页面的 Cookie 信息。

下面以一篇微信文章页面所存储的 Cookie 为例。

这个表中，就是当前存储的所有 Cookie 信息，而表头，则是 Chrome 支持的 Cookie 信息。

下面我们分别来介绍它们。

• Name:Value ：Cookie 存储的数据就是一个 Key-Value 的键值对，所以这两个参数没什么争议，就是数据的 Key 和 Value。

• Domain：Cookie 的域，限制请求头传输的域。

• Path：域中与 Cookie 相关的路径前缀。

• Expires/Max-Age：过期时间或者超时间隔。

• http：此属性为 True，表示只会在 HTTP 请求头中携带此 Cookie 信息，而无法通过 document.cookie 来访问此 Cookie。

• Secure：安全，是否只有在使用 SSL 连接时才发送这个 Cookie。

其实都很好理解，就不展开讲解了。

3.3 Set-Cookie2 和 Cookie2

有些资料里会提到 Set-Cookie2 和 Cookie2 ，这些都是历史遗留问题，当初想对 Cookie
再进行一些功能上的扩展，但并未得到广泛的实施，现在已经弃用了。

大家了解一下即可，有兴趣可以参考 RFC 6265。

RFC 6265:

https://tools.ietf.org/html/rfc6265

3.4 浏览器对 Cookie 的限制

大部分时候我们聊到 Cookie 都在说的是服务器和浏览器进行通信时候，而不同的浏览器对 Cookie 存储的限制是不一样的。例如：单个域名可存储的
Cookie 数量、Cookie 大小等。

我简单找了一些资料，来说明不同浏览器对 Cookie 的支持情况。

这些数据我没有验证过，但是也能说明不同浏览器对 Cookie 的支持情况。在进行页面 Cookie 操作的时候，应该尽量保证 Cookie 的个数小于 20
个，总大小小于 4KB，这是一个安全且保险的范围。

四、Cookie的查缺补漏

4.1 Cookie 安全

前面配置 Cookie 参数的时候，有两个参数：http 和 secure 属性，它们就在一定程度上保证了安全。

1. http 属性

设置了 http 属性，标识它是一个 “HttpOnly” 的，那么通过一些脚本程序（例如 JS的 document.cookie）将无法读取到这个
Cookie 信息，它只会出现在请求的报文头内。

2. secure 属性

secure 属性强制该 Cookie 只有在 SSL 的环境下才会想服务器传输，相对也保证了传输的安全。

4.2 Cookie 不支持跨域

Cookie 本身是不支持跨域的，一定程度也保证了 Cookie 的安全，如果非要跨域其实作为前端基本上能做的很少，大部分都需要服务端的二次配合。

例如：nginx 反向代理、Jsonp、nodejs 的 superagent、iframe 等方法。

有兴趣再单独了解就好了。

五、Cookie 小结

HTTP 中的 Cookie 知识点，基本上都已经讲解清楚了，我们再次总结一下关键知识点。

1. Cookie 主要是为了解决 HTTP 协议无状态的问题。

2. 服务端通过 Set-Cookie 响应头来向客户端设置 Cookie。

3. 客户端通过 Cookie 请求头向服务端发送之前存储的 Cookie 数据。

4. Cookie 依据过期时间进行区分，将类型分为：临时 Cookie 和 持久 Cookie。

5. Cookie 可以通过配置不同的参数，进行限制，例如过期时间、支持的域名、是否安全（secure）等。

6. Cookie 不支持跨域，跨域还需要其他的方式绕开来实现。

7. Cookie 只能做到相对的安全，任何事情没有绝对的安全。

参考：

• Cookie 个数限制及大小：https://my.oschina.net/gaollg/blog/71299。

• RFC 6265：https://tools.ietf.org/html/rfc6265

• cookie 小结：http://www.cnblogs.com/xianyulaodi/p/6476991.html

一个网络请求可以简单分为连接服务器 -> 获取数据两个部分。
其中连接服务器前还包括 DNS 解析的过程；获取数据后可能会对数据进行缓存。

一、连接服务器优化策略

1. 不用域名，用 IP 直连
省去 DNS 解析过程，DNS 全名 Domain Name System，解析意指根据域名得到其对应的 IP 地址。 如
http://www.codekk.com 的域名解析结果就是 104.236.147.76。

首次域名解析一般需要几百毫秒，可通过直接向 IP 而非域名请求，节省掉这部分时间，同时可以预防域名劫持等带来的风险。

当然为了安全和扩展考虑，这个 IP 可能是一个动态更新的 IP 列表，并在 IP 不可用情况下通过域名访问。

2. 服务器合理部署
服务器多运营商多地部署，一般至少含三大运营商、南中北三地部署。

配合上面说到的动态 IP 列表，支持优先级，每次根据地域、网络类型等选择最优的服务器 IP 进行连接。

对于服务器端还可以调优服务器的 TCP 拥塞窗口大小、重传超时时间(RTO)、最大传输单元(MTU)等。

二、获取数据优化策略

1. 连接复用
节省连接建立时间，如开启 keep-alive。

Http 1.1 默认启动了 keep-alive。对于 Android 来说默认情况下 HttpURLConnection 和 HttpClient
都开启了 keep-alive。只是 2.2 之前 HttpURLConnection 存在影响连接池的 Bug，具体可见：[Android
HttpURLConnection 及 HttpClient 选择](http://www.trinea.cn/android/android-http-
api-compare/)

2. 请求合并
即将多个请求合并为一个进行请求，比较常见的就是网页中的 CSS Image Sprites。 如果某个页面内请求过多，也可以考虑做一定的请求合并。

3. 减小请求数据大小
(1) 对于 POST 请求，Body 可以做 Gzip 压缩，如日志。

(2) 对请求头进行压缩
这个 Http 1.1 不支持，SPDY 及 Http 2.0 支持。 Http 1.1 可以通过服务端对前一个请求的请求头进行缓存，后面相同请求头用
md5 之类的 id 来表示即可。

4. CDN 缓存静态资源
缓存常见的图片、JS、CSS 等静态资源。

5. 减小返回数据大小
(1) 压缩
一般 API 数据使用 Gzip 压缩，下图是之前测试的 Gzip 压缩前后对比图。

(2) 精简数据格式
如 JSON 代替 XML，WebP 代替其他图片格式。关注公众号 codekk，回复 20 查看关于 WebP 的介绍。

(3) 对于不同的设备不同网络返回不同的内容 如不同分辨率图片大小。

(4) 增量更新
需要数据更新时，可考虑增量更新。如常见的服务端进行 bsdiff，客户端进行 bspatch。

(5) 大文件下载
支持断点续传，并缓存 Http Resonse 的 ETag 标识，下次请求时带上，从而确定是否数据改变过，未改变则直接返回 304。

6. 数据缓存
缓存获取到的数据，在一定的有效时间内再次请求可以直接从缓存读取数据。

关于 Http 缓存规则 Grumoon 在 Volley
源码解析最后杂谈中有详细介绍。

三、其他优化手段

这类优化方式在性能优化系列总篇中已经有过完整介绍
1. 预取
包括预连接、预取数据。

2. 分优先级、延迟部分请求
将不重要的请求延迟，这样既可以削峰减少并发、又可以和后面类似的请求做合并。

3. 多连接
对于较大文件，如大图片、文件下载可考虑多连接。 需要控制请求的最大并发量，毕竟移动端网络受限。

四、监控

优化需要通过数据对比才能看出效果，所以监控系统必不可少，通过前后端的数据监控确定调优效果。