全栈工程师眼中的HTTP( 二 ) _HTTP

由于浏览器针对资源的域名限制并发连接数，而不是针对浏览器地址栏中的页面域名，所以很多静态资源可以放在其他域名下（不同的子域名也被认为是不同的域名）。如果您只有一台服务器，可以把这些不同的域名同时指向一个IP，也就提高了对这台服务器的并发连接数限制（不过要小心服务器压力过大）。
把静态资源放在非主域名下，这种做法除了可以增加浏览器并发，还有一个好处是，减少HTTP请求中携带的不必要的cookie数据。cookie是某些网站为了辨别用户身份而储存在用户浏览器中的数据。cookie的作用域是整个域名，也就是说如果某个cookie存放在google.com域名下，那么对于google.com域名下的所有HTTP请求头都会带上cookie数据。如果Google把所有的资源都放在google.com下，那么所有资源的请求都会带上cookie数据。对于静态资源来说，这是毫无必要的，因为这对带宽和链接速度都造成了影响。所以我们一般把静态资源放在单独的域名下。
除此之外，前端工程师经常做的优化是合并同一域名下的资源，比如把多个CSS合并为一个CSS，或者将图片组合为CSS贴图。6
还有一些优化建议是省掉不必要的HTTP请求，比如内嵌小型CSS、内嵌小型JAVAScript、设置缓存，以及减少重定向。这些做法虽然各不相同，但是如果了解HTTP请求的过程，就知道这些优化方法的最终目的都是最大化利用有限的请求数。
尽量减少每一个资源的体积我们不光要限制请求数，还要尽量减少每一个资源的体积。因为资源的体积越大，在传输中消耗的流量就越多，等待时间也越久。
在面试应聘者的时候，我会问的一个基础题目是“常用的图片格式有哪些，它们的使用场景是什么” 。如果能选择合适的图片格式，就能够用更小的体积，达到更好的显示效果。对图片格式的敏感，能反映出工程师对带宽和速度的不懈追求。
此外，对于比较大的文本资源，必须开启gzip压缩。因为gzip对于含有重复“单词”的文本文件，压缩率非常高，能有效提高传输过程。
对于一个CSS资源的请求耗时，我想说明两个细节。

这个CSS资源请求的体积是36.4KB（这是gzip压缩过的体积），解压缩之后，CSS内容实际上是263KB，可以算出压缩后体积是原来的13.8% 。
整个连接的建立花费了30%的时间，发出请求到等待收到第一个字节回复花费了20%的时间，下载CSS资源的内容花费了50%的时间。

如果没有设置gzip，下载这个CSS文件会需要好几倍的时间。
后台视角前端工程师对HTTP的关注点在于尽量减少同一域下的HTTP请求数，以及尽量减少每一个资源的体积。与之不同，后台工程师对于HTTP的关注在于让服务器尽快响应请求，以及减少请求对服务器的开销。
后台工程师知道，浏览器限定对某个域的并发连接数，很大程度上是浏览器对服务器的一种保护行为。浏览器作为一种善意的客户端，为了保护服务器不被大量的并发请求弄得崩溃，才限定了对同一个域的最大并发连接数。而一些“恶意”的客户端，比如一些下载软件，它作为一个HTTP协议客户端，不考虑到服务器的压力，而发起大量的并发请求（虽然用户感觉到下载速度很快），但是由于它违反了规则，所以经常被服务器端“防范”和屏蔽。
那么为什么服务器对并发请求数这么敏感？
虽然服务器的多个进程看上去是在同时运行，但是对于单核CPU的架构来说，实际上是计算机系统同一段时间内，以进程的形式，将多个程序加载到存储器中，并借由时间共享，以在一个处理器上表现出同时运行的感觉。由于在操作系统中，生成进程、销毁进程、进程间切换都很消耗CPU和内存，因此当负载高时，性能会明显降低。
提高服务器的请求处理能力在早期系统中（如linux 2.4以前），进程是基本运作单位。在支持线程的系统（Linux2.6）中，线程才是基本的运作单位，而进程只是线程的容器。由于线程开销明显小于进程，而且部分资源还可以共享，因此效率较高。
Apache是市场份额最大的服务器，超过50%的网站运行在Apache上。Apache 通过模块化的设计来适应各种环境，其中一个模块叫做多处理模块（MPM），专门用来处理多请求的情况。Apache安装在不同系统上的时候会调用不同的默认MPM，我们不用关心具体的细节，只需要了解Unix上默认的MPM是prefork 。为了优化，我们可以改成worker模式。
prefork和worker模式的最大区别就是，prefork的一个进程维持一个连接，而worker的一个线程维持一个连接。所以prefork更稳定但内存消耗也更大，worker没有那么稳定，因为很多连接的线程共享一个进程，当一个线程崩溃的时候，整个进程和所有线程一起死掉。但是worker的内存使用要比prefork低得多，所以很适合用在高HTTP请求的服务器上。