十二
Web前端很多优化原则都是从如何提升网络通讯效率的角度提出的，但是这些原则使用的时候还是有很多陷阱在里面，如果我们不能深入理解这些优化原则背后所隐藏的技术原理，很有可能掉进这些陷阱里，最终没有达到最佳的预期效果，今天我在这里分析下浏览器和服务端通讯的一些细节问题，希望通过分析这些细节问题，能给大家一个启迪，能更好的理解这些优化原则背后的隐秘，最终能更好的运用这些原则。
网站的通讯技术是构建在http协议上，http协议底层通讯手段使用的是tcp/ip协议，但是tcp通讯协议在建立连接和断开连接这两个动作上是非常消耗通讯性能的，这主要是因为tcp/ip协议在连接建立时候的三次握手机制和断开连接时候的四次挥手机制所致，我们来看看下面的图形：
图中中间被红色标记的方块就是tcp/ip协议在建立连接时候需要发送三次报文才能确认连接是否建立成功，中间四个蓝色的方框就是说明tcp/ip协议在断开连接时候要发四次报文才能确定连接最终被断开，而一个具体的http请求和响应也就发送两次报文，这也就说明如果浏览器每次和服务端的交互都要新建和关闭一个tcp/ip连接，那么浏览器和服务器之间就要往返9次报文通讯，而真正用来处理用户请求的报文确只有其中的两次，换句话说这样的一个请求大概会有80%左右的性能都不是用来处理业务需求，等于是损失了80%左右的性能，当然这个比率是9次报文交互的数据大小一致情况下得出的，如果用户业务请求和响应的数据量比较大，那么建立连接和断开连接的性能损失占比会降低，不过就算占比降低了那也是在请求处理本身的时间变的更慢的基础上的降低，要是浏览器和服务器之间的距离特别大，那么多出来的7次报文交换的效率问题就更加严重了，不管怎样，tcp/ip的三次握手机制和四次挥手机制只要发生都会对网络请求效率产生重大影响。
为了解决这个报文交互次数过多的问题，http协议本身也发生了改变，那就是http开始采用了长连接，使用长连接后网站只需要开启一个长连接，在用户关闭浏览器关闭之前浏览器里的网页都会复用这个长连接。不过http协议的1.0版本默认是不启用长连接的，所以在使用http协议1.0版本时候我就得手动的打开长连接，这个方法就是在http头里设置Connection: Keep-Alive，而http1.1版本里长连接是默认打开的，所以不需要我们手动的设置，而且时下的浏览器几乎都支持http1.1协议，因此大多时候情况下我们是没有必要手动去打开长连接的。
虽然http协议采用长连接后可以减少网站通讯时候三次握手和四次挥手的次数，但是长连接建立起来后需要浏览器和服务器长时间维护，这本身会消耗浏览器和服务器的性能，特别是服务器端长时间维护长连接本身还会损坏服务器处理并发的能力，所以早期浏览器会限制http1.1开启连接的数量，例如ie7这个古董浏览器，它准许http1.1最多开启2个长连接，而http1.0因为默认使用短连接它默认可以开启4个，下面有张图可以说明，如下所示：
提升浏览器加载效率的手段除了提升每个连接的传输效率外，其实还有一种方式，这个方式就是使用多个连接进行并行加载，这个等于几个人联合起来一起完成一个任务，那么效率肯定就比一个人高，而页面加载时候很符合使用并发加载的场景，例如我们让页面里的图片并行加载肯定会比一个个加载图片的效率要高多了。回到浏览器支持的连接数的问题，由于早期浏览器在http1.0和http1.1连接数的差异，某些网站例如维基百科这样的网站，它的静态资源特别多，为了充分发挥并发的优势，它将存放这些静态资源的服务器采用http1.0协议，这样就能并行加载更多的静态资源，因为这个并行加载的总体效率提升相比tcp/ip握手和挥手的损失要高的多，不过现在这个手法已经起不到什么作用了，因为新版的浏览器已经把两种版本的http协议支持的连接数调整一致了，因为长连接可以复用链路，因此使用长连接的效率会比非长连接更好。
上面连接数也是有一个限制的，这个限制就是必须是在同一个域名下，如果一个页面某些静态资源放在不同域名下面，那么这个做法就可以增加页面里的并发数量，例如我们把一些不是经常变化的静态资源例如图片、外部的css文件以及javascript文件单独放置在一个静态资源服务器上，静态资源服务器对外的url地址和页面本身的url地址不在同一个域名下，那么页面本身的并发加载连接数就会增加一倍，不过这也就意味着浏览器端要维护的长连接数会变得更多，雅虎工程师曾经总结过一个页面里合理的域名数量，那就是两个，这个结论的提出已经过去了好多年了，现在的浏览器和服务器的性能已经今非昔比了，这个跨域数量应该可以增加点，不过我个人认为一个页面的里包含的域名数量还是不要太多，其实如果我们web前端优化手段使用得当，两个不同域名就足够用了，多了价值不大，除非你网站情况是在特殊，例如你看看现在浏览器本身支持的连接数量已经很高了，大部分都是6，ie9甚至还达到了10，翻个倍就有12和20个连接数，我们在翻个倍就是24和40个，这个数字看起来就很恐怖了，一个计算机支持这么多并发，假如你在浏览器还打开个网站也是这么干的，那么浏览器的并发数多的实在太吓人了，我估计到时计算机本身就跑不动了，所以10多个连接数很够用了，你合理发挥下这些连接数网站的性能就能有很大提升，再说了一个网站并发连接数太多那本身就说明了你在减少http个数这个手段没有运用好。
回到web前端优化的手段，我们如果把这些手段再仔细分析下就会发现很多手段使用都是在同步请求这个场景下进行了，当然这些手段在合适情况下也能作用于异步加载场景，但是异步加载场景发生并发加载之前需要一个单线程的异步加载，这个单线程的异步加载就和分布式系统里的单点故障有点像了，它很有可能是整个流程的软肋所在，所以合理使用同步请求还能让异步操作性能更加优秀做好准备。上面我讲到浏览器在同一个域名下最多可以开启多少个连接数，但是从事web前端开发的人都能感觉到，我们做页面开发时候其实是没法控制这个连接数的，那么问题来了，这么多连接到底是在什么条件下被开启的呢？这个问题非常有意思的，我们来看下面的瀑布图：
从上面的瀑布图我们发现，并行下载的是图片，这个推而广之要是我们看见某些网站的网页做过并发优化处理的设计，我们就会发现并发的资源都是纯静态的资源，那么这个并发连接数跟我们页面的设计存在一个怎样的关系呢？首先我们总结一下页面里的静态资源，在页面里静态资源有html，如果html里面有内联的css代码和javascript代码，那么这些代码也会归属于html，除了html外还有外部的css文件、外部的javascript文件和页面里使用到的图片，那么这些要素怎样会促发页面的并行加载了，换个说法这些要素又是如何促使浏览器同时打开更多连接呢？
首先我们要明确一个问题，浏览器之所以可以打开更多连接数，让这么多连接并行执行是有个前提的，这个前提就是这些资源是不是被并行加载的，例如像外部css文件，图片这样的资源，这些资源下载完毕后马上就可以使用，因为它们下载完毕后没有逻辑性问题要处理因此下载完毕后就可以直接拿来使用，因此它们并行加载不会影响到页面的展示问题，这个情况如果碰到javascript就有点麻烦了，外部javascript代码是包含逻辑在里面，而且有些逻辑很有可能会影响页面的展示，所以javascript下载完毕后，浏览器就得马上执行，所以我们就会看到这样的瀑布图，如下图所示：
上面的空白区就是浏览器在执行javascript代码所要花费的时间。浏览器开启多少个连接是浏览器自发的行为，这个自发行为主要出于提升浏览器并发下载效率的角度出发的。由于现在浏览器的连接基本都是采取的是http1.1协议，也就是使用的长连接，那么连接建立后这个连接就会长期维护，如果这个长连接是单独的静态资源服务器上的长连接，这个问题倒没什么，如果这个长连接放在主域名下面，问题就来了，主域名在页面初始化加载时候会用来下载html，如果我们为提高并发下载效率，让这个主域名下还放置其他的静态资源，那么可能会导致浏览器和主域名的服务器下维护更多的长连接，而页面后续操作基本是使用ajax来操作的，而ajax往往只会复用其中一个长连接，那么其他多余的长连接等于要空转了，这个空转还需要消耗浏览器和服务器的系统资源，所以我们发现主域名下的请求资源类型一定要认真加以控制，能迁移到单独的静态资源服务器上的一定要进行迁移，尽量让主域名下处理的请求都是包含业务逻辑的请求，这样就可以有效提升系统资源的使用率。这个问题进一步思考下去，我们就会发现如果服务端的业务应用服务器之前放置一个反向代理，反向代理都是使用静态资源服务器，而静态资源服务器对并发的承载能力是远超业务应用服务器，如果主域名下我们不小心放置了太多静态资源，要是后台使用了反向代理，那么反向代理也可以减轻这种长连接所造成的计算资源损失。
上面这些场景都是在浏览器同步请求下进行了，那么换到异步请求这个并行加载静态资源的手段还有效吗？回答这个问题前，我们首先要想想异步加载会导致新的静态资源被加载吗？这个当然可能，特别是在前端MVC的场景下，我们会把模板技术放到浏览器端完成，这个时候有些html模板一开始可能会包含在javascript代码里，作为一个变量存储下来，而这个模板里很有可能包含好多新的图片被使用，当ajax从服务端获取数据后，解析了这个模板，然后我们把构造好的模板加入到页面的DOM结构里，浏览器重新渲染页面时候看到很多新图片需要加载，就有可能会开启多个连接进行并行加载来提升资源加载效率，如果碰到通过ajax技术动态加载外部CSS文件，那么这个并行加载情况就会更加突出了，因为css文件里很有可能包含大量的图片资源，如果我们把不变的静态资源都放置在了单独的静态资源服务器，那么这个并行加载就不会在主域名下打开更多长连接，由此可见，将静态资源使用单独的域名的静态资源服务器处理的好处非常之多。
现在http2.0协议还在起草之中，http2.0如果落地将会给web前端优化技术产生重大影响，http2.0打算在一个页面里只使用一个tcp/Ip连接，不过http2.0会在这个连接上进行链路复用，也就是让一个连接上也能做到并行操作，让连接的利用率更高，如果http2.0落地后，web前端里那些用于减少http连接数的手段都会失去市场了，因为协议本身就能处理好并发的问题了，到时像外部css文件，外部javascript文件，css sprite技术说不定就要成为历史了。
看来本主题又写不完了，下篇接着写吧，今天是元宵节，这里我祝大家节日快乐。
十三
本篇继续web前端优化的讨论，开始我先讲个我所知道的一个故事，有家大型的企业顺应时代发展的潮流开始投身于互联网行业了，它们为此专门设立了一个事业部，不过该企业把这个事业部里的人事成本，系统运维成本特别是硬件采购的成本都由总公司来承担，当然互联网业务上的市场营销成本这块还是由该事业部自己承担，可是网站一年运维下来，该公司发现该事业部里最大的成本居然不是市场营销的开销，而是短信业务和宽带使用上的开销，是不是有点让人感到意外呢？下面我来分析下这个场景吧。
短信这块是和通讯运营商有关，很难从根本上解决，当然该企业可以考虑使用像微信这样的工具来分摊下短信的成本，但是宽带流量消耗这个问题却很难有第二选择了，可能有人会感到诧异，一家做互联网的企业，用户都是使用自己掏钱的宽带来上网的，为啥企业会有宽带流量的成本呢？其实互联网公司的后台服务都是会放置在IDC即数据中心里的，除非你的企业是真正的高富帅，或者你本身的核心业务就是互联网业务，这样的企业才有可能会自建数据中心，绝大部分企业都会租用第三方的数据中心，而且有些企业为了容灾还会在不同地域建立不同的数据中心，不同数据中心之间是通过专线来通讯的，而专线的成本是很高的，我们想让自己开发的网站让更多人用，可以通过改造服务端并发处理能力来达到这个目的，但是这里还有一个制约因素，那就是服务端使用的带宽，一般而言，企业选择多大带宽是可以估算出来，最终采用一个合理的带宽，但是，如果这家公司是电商类型网站，就很有可能碰到像双十一啊，或者自身做大促销的情况，这个时候服务端的负载压力就会成倍增加，远远超出平时的网络流量，如是企业会提前扩充带宽，而扩充的带宽流量是昂贵的，这样就会无形增加网站运营成本。如果我们不去思考成本问题，当今社会讲求环保，例如淘宝就说它们网站没完成一次交易使用的电量可以煮熟两个鸡蛋，它们网站一天下来消耗的电量相当于中国一个三线城市一天消耗的电量，那么如果我们能节约每次请求消耗的宽带流量其实也就是在节约能源，所以不管是从成本角度还是从环保角度提高宽带的利用率都是有很大的现实意义的。
Web前端优化里有一个技巧就是压缩http请求的数据量，这个技巧很多人都是简单认为http请求的数据越小，那么http处理速度就更快些，不过我认为这结论其实是一个相对的结论，现在的网速是越来越快，很多人家里接入的宽带已经使用上了光纤，50兆，百兆的宽带已经飞进了寻常百姓家了，那么这时候其实网络传输100kb数据和传输300kb数据的效率差异基本可以忽略不计了，当然并非每个人网络访问速度都这么快，例如我们使用手机的2G网络上网，那么100kb和300kb的传输效率还是会有很大差异的，所以压缩http请求大小这个手段在客户端这块是一种解决短板的技巧，这个短板就是照顾那些上网速度太慢的人了，而非对人人平等的技术手段，但是这个问题换到服务端就不同了，减少http报文的数据大小可以提升企业对宽带的利用率，是一种节约网站运营成本的一个重要手段，因此压缩http传输数据的大小是一个很有价值的技术手段。
用来压缩http请求数据大小的手段很多，例如使用Gzip压缩http请求，压缩图片等等，不过我这里要特别说明一个手段那就是减少cookie存储数据的大小，这是一个常常被忽视的压缩http请求大小的技术手段。不过cookie技术对很多初学者常常会感到差异，cookie是客户端的数据，为什么服务端和客户端都能操作它，难道服务端也会存储一份cookie的备份吗？之所以初学者会对cookie使用有疑问，这主要是初学者不太清楚cookie信息除了保存在浏览器端，它还会包含在http报文头里的，每个http请求响应都会带着cookie信息进行传递，所以cookie既可以被客户端操作也能被服务端操作，如果我们忽视cookie这个特点，再加上我们滥用cookie，最后cookie被撑满了，这也就意味每次请求响应的数据量会增加，而这些信息可能大部分都不会被使用，纯粹多余。而网站在开发和维护时候很容易不自觉的让cookie变得越来越多，越来越大，如果我们一开始就明确cookie这个特点，提前设计cookie使用规范，那么就可以一定程度上规避cookie不合理使用导致的http数据量变大的问题。如果网站使用了单独的静态资源服务器，并且把静态资源放置在单独的域名下面，这个时候我们还要避免给静态资源域名下使用cookie技术，因为静态资源基本都不会有状态信息，使用cookie只会无谓的增加请求的数据大小。
网络是存储设备里效率最差的，如果页面加载时候还有些请求是一个坏请求，例如页面访问的某些静态资源突然丢了，浏览器这个时候会有一个容错的做法，这个做法具体是：浏览器不能确定有问题的请求到底是因为网速慢了还是找不到，所以浏览器会多次请求这个url，直到浏览器认为这个url的确是有问题无法访问了，浏览器才不去继续请求了，如果碰到的资源正好是外部javascript文件，那就很有可能阻塞整个页面的加载，所以剔除页面里的坏请求也是要经常留心的事情。
我们如果再进一步分析下web前端优化的一些手段，就会发现很多优化手段其实都是基于静态资源来处理的，静态资源的特点就是在一定时间范围内不会发生变化的，而且当用户请求静态资源时候，服务端不需要任何计算操作即消耗CPU资源就能把结果返回给客户端，静态资源这种不参与计算的特点就可以让静态资源和业务应用服务器解耦，因此我们可以把静态资源单独抽取出来放置在CDN或者是请求效率处理更佳的静态资源服务器上。和静态资源相对的动态资源就很难做到这点，我们仔细回味下网站后台整个应用架构，就会发现所有网站都会使用存储系统即基本都会用数据库，而且应用服务器和数据库又是一种紧耦合的关系，因为我们想消除存储系统的状态问题基本是不可能完成的任务，这就让应用服务器没法做成CDN的形式，因此动态资源处理想使用CDN这种减少距离对网络通讯影响的手段基本是很麻烦的。我觉得网站静态化处理其实是根据web前端优化技术产生的技术，它让网站静态化资源和动态资源分离做的更好，所以我说网站静态化技术是充分发挥web前端优化手段的重要保证，这也就是我为什么会把web前端优化的内容也要放在网站静态化处理系列里的原因了。
静态资源因为在一定时间里不会发生变化，容易被缓存，而且浏览器本身也有缓存机制，那么如果我们把静态资源缓存在浏览器端，用户请求网站就不需要再去请求网络资源，这个效率不就更高了吗？现实情况的确是如此，但是我们想让浏览器端充分发挥这个缓存作用其实并非那么简单，因为我们会碰到如下的问题,具体如下：
问题一：网站对浏览器的控制是一种被动控制，用户才是控制浏览器的主动方，用户的很多行为都会导致网站对浏览器的缓存设计策略失效，如果缓存失效，那么用户再去访问网站时候就得重新请求资源，所以为了弥补浏览器缓存的不可靠性，CDN技术以及静态资源服务器的使用就派上用场了。
问题二：浏览器缓存网页部分资源可以让网页加载的更快，但是要做到这一点之前，我们首先要明确何时采用，同时采用何种方式让客户端缓存这些可以被缓存的资源？那么我们在知道某个用户要访问网站了，我们提前把需要缓存的资源发送个用户，让用户先缓存下这些资源，这个做法肯定是开国际玩笑了，一般我们都是在用户第一次访问网站时候将可以缓存的资源缓存起来，这个时候问题又来了，那就是用户第一次访问网站时候因为需要缓存的资源都没有被缓存，所以全部的资源都要通过网络请求下载，这个时候就会导致用户第一次访问网站页面的效率很差，有人可能认为网站又不是设计为访问一次的产品，只要资源被缓存了网页就会更快的，要是用户觉得第一次访问慢了，就先忍忍吧，以后会快的，这个想法又是再开国际玩笑了。就算用户忍受了第一次访问慢的情形，但是如果用户使用这个网站的时间间隔是很长的，例如某些专业性的网站，它的用户可能会很长一段时间后再访问该网站，而过了这段时间后，浏览器缓存的资源很有可能失效了，这个时候用户再去访问又等于是第一次访问了，那么我们这个缓存设计方案基本就是无效了。
问题二所反映的问题也就表明我们在如何合理使用浏览器缓存这块上是需要考虑用户的使用场景的，需要加入一些业务性的策略了，只有这样浏览器缓存方案才能充分发挥其优势。下面我就来谈论下浏览器端缓存策略设计的问题了。
首先我们来看一个场景，用户第一次访问网站，访问的是网站的首页，我们按照web前端优化原则设计了网站首页，特别是使用了一个优化原则就是把css合并成一个外部css文件，把javascript代码也合并成一个外部文件，首页都引入了这两个外部文件，这种情况首页访问至少会产生三个http请求，可是网站首页其实没有那么复杂，也就是说首页使用的css代码和javascript代码其实并不太多，如果我们把这些代码就放置到页面内部，那么首页加载就只有一个请求，虽然这会导致这个请求的数据量变大，不过按照我前面说到压缩http请求数据大小，其实在提升网络传输速度上这个角度是值得商榷的，但是多个http请求就会导致浏览器打开更多连接，而每个连接的建立和销毁却是十分消耗计算资源的，那么如果我们能把三个请求合并成一个请求完成就一定会让请求处理的更快，可是这个做法就会导致css和javascript文件没法被缓存，那么以后想复用它们就麻烦了。碰到这样的问题我们又该如何来抉择了？最理想的结果就是二者兼顾，但是要兼顾二者，那么页面就一定要处理这三个http请求了，我们到底能不能做到二者兼顾了？答案是肯定的，我们可以做到的。我们仔细的分析下这个场景，就会发现，快速加载页面和缓存静态资源在页面首次访问这个背景下其实是两个不同的业务操作，用户第一次访问首页用户只会关心页面是否快速被加载，至于加载静态资源的行为以及缓存静态资源的行为，用户是不用关心，因此我们就可以拆分这两个操作，首先是让页面快速被加载，等页面加载完毕后，我们在通过异步手段来加载外部的静态资源，这样就可以做到二者兼顾了，至于如何异步加载静态资源，我在以前的文章里讲述过，这篇文章就是《探真无阻塞加载javascript脚本技术，我们会发现很多意想不到的秘密》，不了解这个技术的朋友可以看看本篇文章。
不过要让上面的方案发挥作用是有一个大的前置条件的，那就是我们要判断出用户到底是不是第一次访问，而且因为外部的css文件和外部的javascript文件都被我们合并成了一个文件，这也就是说首页里内嵌的css代码和javascript代码和外部文件是有一个冗余的，如果用户第二次访问时候不需要这些操作了，那么让首页保持这个冗余是不是就没有这个必要了？特别是javascript代码，重复的javascript代码总是让人觉得不放心。这两个问题的核心还是在于如何判断用户是否第一次访问，判断用户的行为那就是属于判断用户状态的问题了，用户的状态标记在服务端使用的是session技术，浏览器端使用的是cookie技术，而session技术是一个临时会话存储技术，因此使用session是没法判断用户以前是否访问过该网站，所以这里只能使用cookie技术（如果浏览器支持html5，客户端保存用户状态的信息手段就更加多了，不一定非要使用cookie了），也就是当用户第一次访问网站时候，我们将一些可以标记用户是否访问过网站的状态信息存储在cookie里，那么用户再次访问这个网站时候，http请求就会把cookie信息传送给服务端，服务端通过cookie信息判定用户是否第一次访问，这个时候服务端可以剔除页面里内嵌的css代码和javascript代码，同时可以阻止浏览器再异步加载外部css文件和外部javascript文件行为，这样用户再次访问网站的行为也不会被用户第一次访问行为干扰了。
上面场景里还有一个优化手段的使用是值得商榷的，那就是我们把网站所有的css代码和javascript代码合并到一个文件里。这里我首先来讲讲把所有javascript代码合并成一个文件的问题，一个网站会包含很多不同页面，不同的页面因为业务场景的不同，就会导致每个页面都有专属的处理业务逻辑的javascript代码，如果我们简单的认为把javascript代码放置到外部文件就会让页面加载的更快，那么当我们合并外部文件时候这些和页面紧耦合的业务代码也会合并到一个文件里，最后就会导致最终的外部javascript文件变得特别大，对于浏览器而言，javascript代码过多也会影响到页面的加载效率和javascript的执行效率，而且这个超大的外部javascript文件对于某一个功能页面而言有太多冗余的代码，所以我们简单把全部外部javascript文件合并成一个外部javascript文件这个做法其实并不是太好，因此到底哪些javascript外部文件应该被合并这是有所选择的。而且把某些业务相关的javascript代码就写在页面，和页面一起被下载可能比我们单独使用外部文件的javascript效率更高，因为单独的外部javascript文件会增加页面http请求的个数，那么我们在开发时候那些javascript代码需要内嵌入页面，那些javascript代码要把放在单独外部文件里这也是我们要注意的策略问题。
我们毫无原则的把外部css文件和javascript文件合并成少量的外部文件还会影响到网站的运维和浏览器的缓存策略，特别是缓存策略的失效机制，例如网站某个页面做了css代码或者javascript代码的修改，而这些代码上生产时候要被合并到一个外部的css文件和javascript文件里，而这些外部文件又被很多网页引用，那么我们就不得不让很多无关的网页也需要刷新浏览器缓存，如果这个修改是作用于公共代码这个问题还好理解，要是这个代码是用于营销活动这个特定场景下，那么这样的刷新缓存操作就会显得非常没有必要，如果有天营销活动结束了，我们是不是还要再刷新下缓存，剔除多余的代码呢？所以如何合并外部的css代码和javascript代码我们还是要应该根据业务场景进行合理的分组的。
Web前端的工作是十分繁重的，网站是和终端用户打交道，这些终端用户都是网站的需求方，而web前端是处理终端用户需求的排头兵，用户那么多，需求那么多，所以网站的前端页面会经常的被修改，修改的页面就要重新发布生产，这个时候我们就要刷新浏览器的缓存了，那如何来刷新页面的缓存了，方法其实很简单就是改变页面url的参数，一般网站的静态资源的url后面我们会专门加上一个版本号参数，例如：
www.cnblogs.com/sharpxiajun/a.css?v=1234556
我们只要改变12345这个参数的值就能让浏览器重新从服务端获取静态资源，这个时候问题来了，如果外部css文件或javascript文件被很多页面引用，那么我们就不得不去手动的更改页面里引用这些外部文件的版本号，这个操作难免会有遗漏，就算遗漏问题好解决，如果我们的页面是使用服务端模板开发的，那么就可能导致生产发布时候重启生产服务器，为了静态资源发布重启服务器的确让人感觉有点得不偿失。那么我们又如何来解决这个问题呢？
我们分析下这个问题的本质就是页面引用外部css文件和javascript文件的行为其实包含一个动态性，那么我们要解决这个问题就是要拆分出这个动态性，也就是把要变化的版本号这个动态性拆分出来进行单独处理，一般我们就会通过模板语言来重新编写link和script标签的代码，例如在jsp技术里我们可以自定义一个标签，将版本号作为参数传入标签里，当项目发布时候，模板引擎会根据版本参数不同重新编译出link和script标签，但是这个做法还是有问题的，例如jsp页面技术，要想更改版本号就得重启服务，所以这个时候我们把版本号的计算功能做到独立的缓存里，当文件改变后我们通过更改配置刷新缓存，这样就可以不用重启服务器就能刷新静态资源的版本号了。如果我们网站使用了网站静态化处理，那么我们可以把这个操作迁移到反向代理这边来做，把该操作作为动静整合的一部分，如果我们使用了ESI技术，那么无非就是刷新下ESI对应的缓存即可。这个动态刷新静态资源版本号的操作在互联网里已经很流行了，但是现在大部分技术都是关注在如何检测静态文件是否发生变化上，例如使用md5技术计算文件的md5值啊，或者是修改下文件的名字啊，但是这些手段使用时候都没考虑到是否重启服务器的问题，最终导致设计方案使用起来比较麻烦，我觉得如何检测文件是否变化很重要，如果方案能实现在检测变化的基础上做到不用重启服务器就能刷新缓存，这样才能让该方案更加完整和实用。
OK了，终于把网站静态系列写完了，后面我将开启一个新的系列那就是分布式和SOA，本来我想把分布式和SOA分成两个系列，最近觉得这两个系列合并在一起比较好，不过写新系列前可能需要一段时间准备，最近一直写博客都没抽出时间好好看书，应该要花点时间看书好好学习下了。
外包加工网吧什么是网络营销网络营销有哪些内容北京科技公司名称家具设计师常去的网站论坛空间申请设计网站属于什么专业桂林网站制作多少钱平台电商有哪些国际公司图片seo推广方式软件定制 杭州在线网站建设询问报价qq自助下单平台网站长沙建站做企业网站公司工业网页设计欣赏制作视频的软件哪个好免费的网片挂钩重庆做app开发的公司万网域名的查询方式离婚协议书正规模板中国知名企业的企业文化足球世界排名国家最新注册网站要多久庆阳门户微信公众号运营团队免费下载公众号重庆十大装饰公司王爷不要啊企业网站制作托管建设网络平台的技术服务合同交印花税吗北京二手房网站今天周五了，我是歌手马上要开始，要准备看电视了，最后还是按照惯例祝大家晚安，生活愉快啦。