现在最基本的发布会做两个事，代码合并和压缩，今天探讨下代码的合并优化了什么。代码合并是最简单的，手动都可以，可以减少HTTP连接数。
在深入的剖析之前，要先讲3个概念。
- TCP和HTTP的通信模型
- HTTP persistent connection / HTTP pipelining
- HTTP的头部和正文
TCP和HTTP的通信模型
分层上TCP是控制层协议，负责在两个通讯程序（比如网站服务器程序和浏览器）之间建立可靠连接，连接的唯一性由IP1 + 端口1 + IP2 + 端口2的唯一组合决定。记住是四个部分的唯一组合，任何一个换了都是不同的TCP连接。在网站的服务器浏览器模式下，我们用IP1代表服务器的IP，用端口1代表服务器的端口，一般为80端口。浏览器的IP就是它所在电脑的IP，端口号由浏览器按一定规则顺序产生。
举例子说明，当我访问Google的时候，Google网站的IP和端口分别为93.64.8.89和80，浏览器的IP和端口分别为127.119.230.57和23456，那么在两者之前就会建立一个93.64.8.89:80 <-> 127.119.230.57:23456的TCP连接。现代的浏览器在访问网站时，通常都会建立不止一个TCP连接，比方说上面的访问中，浏览器会再通过23457端口建立第二个TCP连接：93.64.8.89:80 <-> 127.119.230.57:23457。由于使用了不同的端口号，所以是另一个独立的TCP连接，对通信双方都是如此（服务器和浏览器）。实际上建立的连接数会更多，观察Chrome的行为，会默认建立6个TCP连接（只有浏览器端的端口号是不一样的）。
因为TCP的目的是建立可靠连接，所以通信开始要要先建立连接，结束后要关闭连接。典型的建立需要3次数据交互确认。典型的结束连接需要4次数据交换确认。所以TCP
是一个开销比较大的连接方式。在建立和关闭连接之间，通信两方可以进行业务层内容的交换，比如HTTP。
总结一下TCP和HTTP的过程就是：建立TCP连接 -> 通过该连接交换HTTP内容 -> 关闭TCP连接。
HTTP persistent connection / HTTP pipelining
浏览器打个页面需要很多HTTP请求，所有的HTML页面，CSS文件，JavaScript文件，图片都要通过HTTP请求获取。那个很自然的问题就是每个HTTP请求都要单独重新建立TCP连接嘛？最早版本的HTTP协议确实是这样的，TCP建立，交换一个HTTP请求，TCP关闭。这种方式带来了高开销和高延时的问题，所以HTTP1.1建立了一个TCP交换多个HTTP请求的方式，称为HTTP persistent connection / HTTP pipelining。典型的过程就变为了：建立TCP连接 -> 通过该连接交换多个HTTP内容 -> 关闭TCP连接。
用浏览器的调试工具很容易判断是否支持HTTP persistent connection：
Request和Response都有这个Header，表明支持HTTP persistent connection
这种方式已经获得很普遍的支持。
HTTP的头部和正文
HTTP分成头部和正文，头部都是表示通信属性，正文是内容。对于网页程序来说，正文才是有效信息。正文长度/HTTP总长可以认为是HTTP通信的效率值。另外观察一个网页的JavaScript文件请求，可以发现头部其实是比较相似的。
有了这些概念，我们看一个实际例子，用 WireShark（WireShark是Windows下捕获网络通讯最著名的工具）看一下Chrome打开简书首页时，发生了哪些通讯。
首页Chrome建立了四个TCP连接
四个TCP连接的握手第一步
我们跟踪其中一个连接的TCP流，发现其中交换了两个HTTP请求
第一个HTTP请求
第二个HTTP请求
从这些该概念和例子，我们可以得出结论，合并JavaScript脚本的效果。
第一，能够减少HTTP请求数。减少HTTP请求数对于系统（服务器和浏览器）和网络的影响还需要再评估。
第二，由于HTTP pipelining的存在，并不能减少TCP连接数，所以这方面是没有优化效果的。
第三，合并之后，HTTP的头部数量减少，正文长度/HTTP总长的值变大，传输效率提升。
第四，JavaScript文件需要从服务器的文件系统获取，合并之后能降低系统IO负担，但是这个取决于服务器的设计，比方说是否有缓存。
网友评论