作业

[hanxinran]

找出性能瓶颈

分析资源瀑布
谈到 Web 性能，必然要谈资源瀑布。事实上，资源瀑布很可能是我们可以用来分析网络性能，诊断网络问题的一个最有价值的工具。很多浏览器都内置了一些手段，让我们能查看资源瀑布。此外，还有一些不错的在线工具，比如 WebPageTest
（http://www.webpagetest.org/），可以在不同的浏览器中呈现资源瀑布。必须知道每一个 HTTP 请求都由很多独立的阶段构成（图 10-3）：DNS 解析、TCP 连接握手、TLS 协商（必要时）、发送 HTTP 请求，然后下载内容。这些阶段的时长在不同的浏览器中会略有不同。

代码结构

代码优化:

压缩代码，
减少流量。
合并静态资源，
减少http请求。
服务端开启gzip压缩。
编写高质量的代码
按需加载资源

SSR服务端渲染

来源joeyguo/blog#8

模式:前后分离

1. 用户输入 url，开始拉取静态页面
2. 静态页面加载完成后，解析文档标签，并开始拉取 CSS （一般 CSS 放于头部）
3. 接着拉取 JS 文件（一般 JS 文件放于尾部）
4. 当 JS 加载完成，便开始执行 JS 内容，发出请求并拿到数据
5. 将数据与资源渲染到页面上，得到最终展示效果
   

发起一个 HTTP 的网络请求过程:

DNS解析（100~200ms可以缓存）
       
    建立TCP链接 (三次握手100~200ms )
    
        HTTP Request( 半个RTT ) 
              
          HTTP Response( RTT 不确定优化空间 )

注: RTT 为 Round-trip time 缩写，表示一个数据包从发出到返回所用的时间。

模式:直出 (服务端渲染)

数据请求能放到 server 上，对于数据与HTML结合处理也可以在server上做，从而减少等待 JS 文件的加载时间。

1. server 上获取数据并将数据与页面模板结合，在服务端渲染成最终的 HTML
2. 返回最终的 HTML 展示

网络优化

传输层安全（TLS）

TLS 协议的目标是为在它之上运行的应用提供三个基本服务：加密、身份验证和数
据完整性
针对 TLS 的优化建议
要最大限制提升 TCP 性能，请参考针对 TCP 的优化建议”；
把 TLS 库升级到最新版本，在此基础上构建（或重新构建）服务器；
启用并配置会话缓存和无状态恢复；
监控会话缓存的使用情况并作出相应调整；
在接近用户的地方完成 TLS 会话，尽量减少往返延迟；
配置 TLS 记录大小，使其恰好能封装在一个 TCP 段内；
确保证书链不会超过拥塞窗口的大小；
从信任链中去掉不必要的证书，减少链条层次；
禁用服务器的 TLS 压缩功能；
启用服务器对 SNI 的支持；
启用服务器的 OCSP 封套功能；
追加 HTTP 严格传输安全首部

针对浏览器的优化建议

<link rel="dns-prefetch" href="//hostname_to_resolve.com"> ➊
<link rel="subresource" href="/javascript/myapp.js"> ➋
<link rel="prefetch" href="/images/big.jpeg"> ➌
<link rel="prerender" href="//example.org/next_page.html"> ➍

➊ 预解析特定的域名
➋ 预取得页面后面要用到的关键性资源
➌ 预取得将来导航要用的资源
➍ 根据对用户下一个目标的预测，预渲染特定页面

针对TCP的优化建议

原理
TCP 三次握手增加了整整一次往返时间；
TCP 慢启动将被应用到每个新连接；
TCP 流量及拥塞控制会影响所有连接的吞吐量；
TCP 的吞吐量由当前拥塞窗口大小控制
大多数情况下，TCP 的瓶颈都是延迟而非带宽

服务器配置调优

先把主机操作系统升级到最新版本,有了最新的内核，我们推荐你遵循如下最佳实践来配置自己的服务器。
增大 TCP的初始拥塞窗口
加大起始拥塞窗口可以让 TCP 在第一次往返就传输较多数据，而随后的速度提升也会很明显。对于突发性的短暂连接，这也是特别关键的一个优化。
慢启动重启
在连接空闲时禁用慢启动可以改善瞬时发送数据的长 TCP 连接的性能。
窗口缩放（ • RFC 1323）
启用窗口缩放可以增大最大接收窗口大小，可以让高延迟的连接达到更好吞吐量。
TCP 快速打开
在某些条件下，允许在第一个 SYN 分组中发送应用程序数据。TFO（TCP FastOpen，TCP 快速打开）是一种新的优化选项，需要客户端和服务器共同支持。
为此，首先要搞清楚你的应用程序是否可以利用这个特性。
以上几个设置再加上最新的内核，可以确保最佳性能：每个 TCP 连接都会具有较低
的延迟和较高的吞吐量。

应用程序行为调优

消除不必要的数据传输本身就是很大的优化。比如，减少下载不必要的资源，
或者通过压缩算法把要发送的比特数降到最低。然后，通过在不同的地区部署服务
器（比如，使用 CDN），把数据放到接近客户端的地方，可以减少网络往返的延迟，
从而显著提升 TCP 性能。最后，尽可能重用已经建立的 TCP 连接，把慢启动和其
他拥塞控制机制的影响降到最低。

性能检查清单

把服务器内核升级到最新版本（Linux：3.2+）；
确保 cwnd 大小为 10；
禁用空闲后的慢启动；
确保启动窗口缩放；
减少传输冗余数据；
压缩要传输的数据；
把服务器放到离用户近的地方以减少往返时间；
尽最大可能重用已经建立的 TCP 连接。

HTTP

http1.1

减少 • DNS查询
每次域名解析都需要一次网络往返，增加请求的延迟，在查询期间会阻塞请求。
减少 • HTTP请求
任何请求都不如没有请求更快，因此要去掉页面上没有必要的资源。
使用 • CDN
从地理上把数据放到接近客户端的地方，可以显著减少每次 TCP 连接的网络延
迟，增加吞吐量。
添加 • Expires首部并配置ETag标签
相关资源应该缓存，以避免重复请求每个页面中相同的资源。Expires 首部可用
于指定缓存时间，在这个时间内可以直接从缓存取得资源，完全避免 HTTP 请
求。ETag 及 Last-Modified 首部提供了一个与缓存相关的机制，相当于最后一次
更新的指纹或时间戳。
Gzip • 资源
所有文本资源都应该使用 Gzip 压缩，然后再在客户端与服务器间传输。一般来
说，Gzip 可以减少 60%~80% 的文件大小，也是一个相对简单（只要在服务器上
配置一个选项），但优化效果较好的举措。
避免 • HTTP重定向
HTTP 重定向极其耗时，特别是把客户端定向到一个完全不同的域名的情况下，
还会导致额外的 DNS 查询、TCP 连接延迟，等等
DNS 查询和 TCP 慢启动导致的额外消耗对高延迟客户端的影响最大。换
句话说，移动（3G、4G）客户端经常是受过度域名分区影响最大的！

https

推荐使用的TLS协议和cipher suite，在协议和算法层面，我们也做了一些统计来进行对比。在HTTPS握手过程中记录协议类型、加密套件、握手时间，并且将上述内容返回给页面。页面在记录用户的访问速度之后，上报数据的同时，把上述的协议类型等数据也一同上报。
TLS1.2协议的性能要明显优于1.1和1.0。

http2.0

二进制分帧层
流、消息和帧
多向请求与响应
请求优先级
每个来源一个连接
流量控制
服务器推送
首部压缩
每个来源使用一个连接



HTTP 2.0 通过将一个 TCP 连接的吞吐量最大化来提升性能。事实上，在 HTTP2.0 之下再使用多个连接（比如域名分区）反倒成了一种反模式，因为多个连接会抵消新协议中首部压缩和请求优先级的效用。
去掉不必要的文件合并和图片拼接 •
打包资源的缺点很多，比如缓存失效、占用内存、延缓执行，以及增加应用复杂性。有了 HTTP 2.0，很多小资源都可以并行发送，导致打包资源的效率反而更低。
利用服务器推送 •
之前针对 HTTP 1.x 而嵌入的大多数资源，都可以而且应该通过服务器推送来交付。这样一来，客户端就可以分别缓存每个资源，并在页面间实现重用，而不必把它们放到每个页面里了。
要获得最佳性能，应该尽可能把所有资源都集中在一个域名之下。域名分区在 HTTP2.0 之下属于反模式，对发挥协议的性能有害：分区是开始，之后影响会逐渐扩散。
打包资源不会影响 HTTP 2.0 协议本身，但对缓存性能和执行速度有负面影响。


QQ空间团队:

注:QUIC使用UDP协议

腾讯优化经验:

轻量交互，其实核心思想就是节省，主要思想是从协议层面以及逻辑层面做一些精简、合并、压缩、消峰、异步等等。
减少交互步骤。客户端一次请求，尽量把信息都拿下去，后台也尽量把相关的信息都加进去，完整地带下去，减少交互步骤。这里要求后台要多主动地做一些聚合工作，一些协议要重新设计。
精简交互信息，尽量减少每一次传输过程中的信息。有个原则，就是不用的信息尽量不要拉，这里要求开发团队在协议设计的时候要非常灵活和细致，要支持增量更新和同步逻辑。
复用包头。一般做协议设计的时候有包头和包体，包头里面放一些账号信息、身份凭证，还有版本信息。尤其随着现在安全压力越来越大，形势越来越严峻，身份凭证可能会越来越长。其实这些信息没必要每次都带，可以在接入server时做一些缓存，后面的包就不需要这些信息了，这样的话每个包可以减少几十个字节，甚至更可观。这样算起来收益是很大的，不光能帮用户省流量，因为传的内容烧，也能加快速度，对体验也有改善，勿以善小而不为。
智能合并压缩。这里需要对业务逻辑有深入的了解。不是所有的包一定要最快响应，可以请求分一下优先级，哪些是需要及时响应的，一定要及时保证。哪些是可以降级的，不需要很及时。可以把大量的不需要及时响应的包做一些延迟，这个延迟不仅是为了解决运营商的消耗问题，延迟以后可以做压缩。当然具体延迟多久，可能要根据具体业务的场景来看。
客户端异步削峰。还是细分问题，把一些不重要的包或者是当前这个不是立即需要的可以往后放，先让用户快点接入进来。同样，客户端也需要注意不要把UI绘制跟存储放在一个线程里面做，避免卡顿。
2.差异服务

1. 路由调度(选快路)
   分布式接入，在南方、北方和中部选择了三个地区，各自部署了一个点，每个点也覆盖了三大运营商，这是基础工作。
   这时还有一个问题，如果中小运营商用户也访问到在三大运营商部署的服务，会存在跨网访问，质量很差。所以又建设了一个内容加速机房，它有独立IP，而且是TCP互联，路由直达，这样中小运营商的质量可以得到明显改善。针对海外用户，最初在香港部署了一个点，后来又在全球各大洲，每个洲选择了一个点，海外用户就近访问加速点，通过加速点再访问国内的服务器。
   部署是在不断优化的，调度也需要更精准的体现。所谓调度，无非就是说什么时候，哪些用户该连到哪些server。所以这里可以分用户、server、时间三个维度。比如说用户，细化到每个网关;server，把用户调度到质量较高的server上面去;时间比较好理解，因为移动网络经常有波动，需要快速地发现波动，并及时自动干预，把它调度走。
   还有一个很常见的问题，就是频繁切换网络。用户可能每天都在不同运营商，不同的网络之间来回切换。连接的时候不用域名，直接用IP，那如何保证用户不管怎么样切换网络，都能连接到连到他应该连接的server上面呢?假如说用户第一次连某个网络时，他会使用本地默认列表，连到server时，如果server发现不是最优的，会及时纠正，下发一份新的server列表。开发团队干脆把用户最近使用的50个接入点统统缓存下来。
2. 数据传输加速(造快车)
   做完了调度相当于选择了一条快速路线，这是不够的，还要想办法造一辆快的车。
   首先是不用域名，直接用IP。这样可以减少域名解析的开销，更重要的是，可以避免域名解析带来的各种故障，还可以减少一些被屏蔽和封掉的可能。
   第二点是重用连接、预连接。比如说QQ里面发图的时候，其实用户还在选择图片的时候，会先把连接建立起来，而且用户传完图以后连接不会立即断掉，会维持一段时间，后面有批量图的时候可以继续使用，减少一次连接的时间可以减少几百毫秒。
   第三点是精简协议和逻辑。
   第四点是参数调优。比如说“拥塞窗口”(congestion window，CWND)，server的操作系统默认是4，建议调大一点，可以调到10，这样可以减轻慢启动对传输带来的影响。还有最大传输单元(Maximum Transmission Unit，MTU)，之前跟运营商的朋友交流，他们给的建议是不要大于1400，现在基本上都是按照这个策略来做的。还有重新传输超时(Retransmission Timeout, RTO)，一般设3秒左右，系统默认值设的是1。
   还有一点叫高带宽时延积环境，在这种环境下面会遇到带宽吃不满，存在浪费的问题。以前网络都是2G网络的功能机时代。当时传图片大部分用的都是单连接。最近几年，网络越来越多，种类也越来越多，而且网络也越来越好。所以系统也进行了改进，可以根据网络状况动态地选择合适的连接数。比如说经过理论分析以及实验验证，开发团队发现其实在WIFI、3G、4G比较好的网络下面传输大数据时，用双连接比单连接提升至少10%，而且越好的网络提升效果越明显。
   3.移动网络环境不是黑盒(熟路况)
   不能简单地把移动网络环境当成黑核来处理，有些细节知识是需要了解的。
   第一，要了解国内移动网关的一些设置，比如说它会限制某个包传输的大小，如果超过的话直接失败。之前跟设备厂商了解，华为很多网关设置的是10M，但是各家都不一样，也没有什么标准。还有网关很多时候对传输时间有限制，这个也是各家不一样的。了解了这些细节，肯定要很好地支持分片和断点续传，否则在某些地区可能会出问题。
   第二，网关对很多标准的理解和实现，各家也是不一样的，尤其像影响比较大的，比如说对HTTP协议的理解和实现。比如说在HTTP的标准文档里面，提了一个range，但是没有强制去做，有的厂商支持的就不是太好。曾经遇到过一种情况，头部用到了range，在分片传输图片时，运营商网关把它过滤掉了，客户端就不知道下一次该从哪里发，所以可能又从第一片开始发，这种情况下，如果客户端没有做好相关保护，就非常危险，会大量的重传，用户流量会被大量消耗。这就是需要注意的地方，尽量不要在HTTP头部加一些字段，需要传一些信息的话，可以放在包体里面，自己解析和理解。
   第三，tcp_tw_recycle。用户说网络是好的，但是连不上server。抓包分析发现，客户端三次握手的包已经发过来了，但是server没有回。这是什么问题呢?经过深入分析，研究了一下协议栈，以及一些参数设置，后来发现，假如tcp_tw_recycle是开启的，server会检查对端同一个网关IP发过来的包，时间是不是递增的，如果不是递增的可能会丢掉。但是移动网络环境下，这是很难保证的。关闭tcp_tw_recycle，问题就解决了。后来这成了外网接入层的标准配置。
   第四，端口受限。有人反映某些地区的用户连server的某些端口连不上，或者是连接质量比较差。比如曾经发现香港数码通的用户连8080端口的质量非常差，很慢;还发现有些机场WIFI，比如说深圳机场WIFI，除了8080和43之外的断口都封掉了，用其他的端口用户也连不上。开发团队意识到，不应该被动地靠用户的反馈来发现问题和解决问题，所以建设了一套自动的系统，根据海量的数据去分析，根据分析结果，server在给客户端返回合适接入列表时，优先选择质量高的端口，而且也尽量注意端口搭配的多样性，这样可以提升接入质量。
   最后看一下信令风暴。其实从09年开始，手机QQ这边每年会被运营商朋友拉过去一起探讨这个问题，双方本着互相理解、合作共赢的态度来对待这个问题。除了建立一些双方认可的虚拟消耗运算模型之外，双方还就移动业务达成了技术共识。比如说减少定时包，减少不必要的及时包，因为有些包真的不一定要非常及时。可以适当做一些缓存和合并。还有一点就是要有流控，万一客户端有BUG，大量的发包，这时候有压跨移动网络的可能，并不仅仅是数据网，它对电信网也有影响，所以server这时要有能力控制客户端发包的策略和频率，这样HTTP服务才能让人放心一点。
   4.异常处理(会修车)
   比如说业务用的是TCP长连接，但是请求有可能被劫持，可能会返回到奇怪的HTML页面，最常见的是WIFI的认证注册，这时需要及时准确地发现这些问题，展现出来提示用户。
   有一种网络抖动叫先发后到，需要做一些保护。比如说要求客户端发包的时候一定要递增，而且即使进程被杀掉重新再起来，也要保证这次发包比上次大。借助这个大小能知道真实发包时间的先后顺序。