高性能网站建设指南总结

延迟

延迟是消息(message)或分组(packet)从起点到终点经历的时间。下面看看路由器这个负责在客户端和服务器之间转发消息的设备，会牵涉哪些影响延迟的因素。

• 传播延迟。消息从发送端到接收端需要的时间，是信号传播距离和速度的函数。
• 传输延迟。把消息中的所有比特转移到链路中需要的时间，是消息长度和链路速率的函数。
• 处理延迟。处理分组首部、检查位错误及确定分组目标所需的时间
• 排队延迟。到来的分组排队等待处理的时间。

以上延迟的时间总和，就是客户端到服务器的总延迟时间。传播时间取决于距离和信号通过的媒介，另外传播速度通常不超过光速。而传输延迟由传输链路的速率决定，与客户端到服务器的距离无关。举个例子，假设有一个 10 MB 的文件，分别通 过两个链路传输，一个 1 Mbit/s，另一个 100 Mbit/s。在 1 Mbit/s 的链路上，需要花 10 s，而在 100 Mbit/s 的链路上，只需 0.1 s。
要想给用户最佳的体验，而且保证他们全神贯注于手边的任务，我们的应用必须在几百ms之内响应。这几乎没有给我们——特别是网络，留出多少出错的余地。必须认真对待网络延迟，在每个开发阶段都为它设立明确的标准。CDN(Content Delivery Network，内容分发网络)服务的用途很多，但最重要的就是通过把内容部署在全球各地，让用户从最近的服务器加载内容， 大幅降低传播消息的时间。

网络核心的带宽

光纤就是一根“光导管”，比人的头发稍微粗一点，专门用来从一端向另一端传送光信号。金属线则用于传送电信号，但信号损失、电磁干扰较大，同时维护成本也较高。这两种线路我们的数据分组很可能都会经过，但一般长距离的分组传输都是通过光纤完成的。光纤可以同时传输很多不同波长(信道)的光，因而具有明显的带宽优势。一条光纤连接的总带宽， 等于每个信道的数据传输速率乘以可复用的信道数。一条光纤的总带宽已经能够达到 70 Tbit/s ，如此大的吞吐量如果换成铜线(传输电信号)可能需要几千条。

三次握手

TCP(传输层)在不可靠的信道上实现了可靠的网络传输。客户端与服务器在交换应用数据之前，必须就起始分组序列号，以及其他一些连接相关的细节达成一致。

• SYN，客户端选择一个随机序列号 x，并发送一个 SYN 分组，其中可能还包括其他 TCP 标志和选项。
• SYN ACK，服务器给 x 加 1，并选择自己的一个随机序列号 y，追加自己的标志和选项，然后返回响应。
• ACK，客户端给 x 和 y 加 1 并发送握手期间的最后一个 ACK 分组。

客户端可以在发送 ACK 分组之后立即发送数据，而服务器必须等接收到 ACK 分组之后才能发送数据。这个启动通信的过程适用于所有 TCP 连接，因此对所有使用 TCP的应用具有非常大的性能影响，因为每次传输应用数据之前，都必须经历一次完整的往返。
三次握手带来的延迟使得每创建一个新 TCP 连接都要付出很大代价。而这也决定了提高TCP应用性能的关键，在于想办法重用连接。
消除不必要的数据传输本身就是很大的优化。比如，减少下载不必要的资源， 或者通过压缩算法把要发送的比特数降到最低。然后，通过在不同的地区部署服务器(比如，使用 CDN)，把数据放到接近客户端的地方，可以减少网络往返的延迟， 从而显著提升TCP性能。最后，尽可能重用已经建立的TCP连接，把慢启动(禁用空闲后的慢启动)和其他拥塞控制机制的影响降到最低。

传输层安全

SSL(Secure Sockets Layer，安全套接字层)协议在直接位于 TCP 上一层的应用层被实现，SSL不会影响上层协议(如HTTP、电子邮件、即时通讯)，但能够保证上层协议的网络通信安全。客户端与服务器在通过 TLS 交换数据之前，必须协商建立加密信道。协商内容包括TLS 版本、加密套件，必要时还会验证证书。TLS在可靠的传输层(TCP)之上运行，这意味着首先必须完成 TCP 的“三次握手”，即一次完整的往返。

减少HTTP请求

多数服务端渲染的页面只有10%-20%的最终用户响应时间花在了所请求的HTML文档上，剩下的80%-90%的时间花在为HTML文档所应用的所有组件(图片，脚本，样式表，Flash等)进行的HTTP请求上。因此改善响应时间的一个途径是减少组件数量。
CSS Sprites是一个减少图片请求的方法。
内联图片，通过使用data: URL模式可以在Web页面中包含图片但无需任何额外的HTTP请求。其格式如下：

   data: [<mediatype>][;base64],<data>
   <img alt="my base64" src="data:image/gif;base64, ...">

如果这样使用在跨越不同页面的时候不会被缓存，更好的做法是使用CSS并将内联图片作为背景，将该CSS规则放在外部样式表中，这意味着虽然这个样式表增加了一个额外的HTTP请求，但图片缓存在样式表内部(CSS对于重复的URL，在没缓存的情况下，只会发出一次请求，如果相同的图片URL已经在页面或者内存中，不会再次请求)

    .home { background-image: url(data:image/gif;base64, ...)}

合并脚本和样式表， 打包多个脚本为一个脚本，打包多个样式表为一个来减少HTTP请求(例如webpack会全部打包成一个文件)

内容发布网络

当用户群增加时，就必须面对服务器放置地点不再适用的事实，此时有必要在多个地理位置不同的服务器上都部署内容。如果组件服务器离用户更近，则多个HTTP请求的响应时间将被缩短。这时就需要使用CDN。CDN可以用于更有效发布静态内容，如图片，脚本，样式表和Flash。CDN会对用户网络可用度进行测量，对特定用户选择不同服务器。
除了缩短响应时间，CDN还可以带来其他优势，他们的服务包括备份，扩展存储能力和进行缓存。

使用缓存

Web服务器通过使用Expire头部来告诉客户端它可以使用组件当前的副本，直到指定的时间为止。添加Expire头不限于图片，还有其他不经常变化的组件，包括脚本，样式表和flash组件。关于缓存可以参考我的另一篇博文 快速掌握前端的HTTP基础(1)

压缩组件

从HTTP1.1开始，Web客户端可以通过HTTP请求中的Accep-Encoding头来标识对压缩的支持。

   Accept-Encoding: gzip

如果Web服务器看到请求中有这个头，就会使用客户端列出来的方法中的一种来压缩响应，gzip是比较流行和有效的压缩方法。压缩脚本和样式表是非常值得的，图片和PDF不应该被压缩，因为它们本来已经被压缩过了，再压缩只会浪费CPU资源。压缩的成本有，服务器花费额外的CPU周期来完成压缩，客户端要对压缩文件进行解压缩。

样式表放在头部

样式表会阻塞页面渲染(为了避免重绘)，在样式表解析完之前，页面不会显示内容，这就是所谓的白屏。所以样式表应该放在头部。

脚本放在底部

当浏览器解析到< script>标签（无论内嵌还是外链）时，浏览器会优先下载、解析并执行该标签中的js代码，而阻塞了其后所有页面内容(包括图片和样式表)的下载和渲染（js不能并行下载，因为js要按照正确的顺序解析和执行。js有可能改变页面输出，所以阻塞渲染）。

避免使用CSS表达式

CSS表达式有可能不断计算，但无法像js一样节流，造成很大的性能损耗。

使用外部js和CSS

原因：可以被缓存

减少DNS查找

DNS是IP地址和URL之间的中间层，DNS也是开销。DNS查找可以被缓存起来以提高性能，很多浏览器拥有自己的缓存，和操作系统的缓存相分离，只有当浏览器没有记录，才会从操作系统中读取，操作系统使用缓存响应，或者将请求发送给一台远程服务器。
服务器可以表明DNS记录可以被缓存多久，查找返回的DNS记录包含了一个存活时间(Time-to-live, TTL)值。但这个TTL值是作为操作系统的缓存时间而不是浏览器的缓存时间。
所以减少DNS查找的方式主要是通过减少唯一主机名，在减少DNS查找和允许高度并行下载之间要做出很好的权衡。

精简js

在打包时去掉多余空格等(可使用JSMin)。然后进行压缩。

避免重定向

当HTTP状态码为301和302的时候，浏览器会自动将用户带到location字段给出的URL。在重定向完毕并且新的URL的HTML文档下载完毕之前，没有任何东西显示给用户。