最近网站常常报503错误：“HTTP Error 503. The service is unavailable”。但刷一两下又正常。
估计很可能是超过网站的最大并发连接数了。
究竟什么是http连接？一张页面加载过程中，又是图片又是样式、脚本，对于这些东西的请求，是共用一个连接还是多个连接？
网上有人说，为了节省连接数，应该尽量将外部CSS，js合并，或者内联；甚至图片也合成一张，再用CSS定位。显然，在这里，一个请求就用一个连接，请求完成连接即被关掉。
但IIS里，有选项“保持HTTP连接”，且有超时时间可供设置。如果每请求一样东西，就开启一个连接，并且这个连接迟迟不死，保持激活，那么要多少连接才够用？这里的意思，应该是一个连接可以供多次使用。
究竟哪个才对？
其实都对。
http协议无状态，无连接。无连接的含义就是限制每次连接只处理一个请求，收到应答后即断开。但据说这个是http1.0。
http1.1里，提出了持久连接（persistentconnection）的概念，也就是说同一条 HTTP连接，可以依次处理多个请求。据说目前大多数浏览器都支持这个。想想也有道理，建立一个http连接，消耗的成本是很高的，类似数据库连接，所以我们都尽量在一个数据库连接里完成所有的操作，正如你到超市里买东西，不可能去一趟只买一样，不然的话，买齐所有东西天都黑了。
不过，即使有持久连接的概念，还是有点疑惑:同一张页面真的只用一个连接吗？假如有些东西特别大，比如图片，其他元素等不及了怎么办？会不会另外开辟一个连接？http超时时间如果都设20分钟，未免太浪费了吧？
另外，就算同一张页面只用一个连接，将css、js、图片合并，也有意义。因为数量少了，发送的请求也少了，这个对性能应该也有影响。
附录1：
一个典型的网页，是由一个 html 文件和内嵌的各类元素组成的，这些元素包括页面内的图片，css文件，javascript 文件等等。每一个内嵌的元素在 HTTP 协议的层面上和那个 html文件是没有区别的：也就是都需要浏览器去服务器上抓下来。一个早期典型的浏览器是这样实现的：当用户敲入网址之后，浏览器和服务器建立连接，请求 这个html 页面，然后边接收服务器发送的 html页面，边解析，碰到内嵌元素，可以立即开第二条连接请求。另外，如果内嵌元素很多，他可能会开多条连接同时请求。当所有需要的元素都下载完毕之 后，浏览器就会将页面画出来。这个过程就是最早期的 HTTP/1.0 协议所设想的浏览器实现。
HTTP/1.0 这种多连接的运作模式是可以改进的。建立 TCP连接的过程是这样：客户端给服务器发一个网络包说我要和你建立连接，服务器收到之后回一个网络包说“我愿意”，然后客户端要再发给服务器一个网络包 说“好那咱们开始传数据吧”。这一来一去三个包才能建立 TCP连接。连接建立之后，浏览器给服务器发请求，服务器给浏览器回应。完事之后又要来回几个网络包关闭 TCP连接。如果页面有很多文件长度很短的元素，每个元素都需要单建一条连接就会导致网络上大量的都是 TCP 建立连接和断开连接的网络包。另外，TCP有一个特性叫做 slow start，其含义可以大致这样解释：TCP连接要求发送端发送一定数量的网络包之后接收端就要回一个“我收到”的网络包，而且网络包在经过每个路由器的 时候包头都要被重写，所以在网络不丢包的情况下网络包越大网络的效率就越高。TCP 连接寻找最优网络包大小的方法是，在 TCP连接建立的初期，网络包的大小是很小的，根据网络状况，两端的程序才会逐步增大网络包的大小以适应带宽提高网络传输的效率。所以浏览器给服务器发请 求，如果每发一个请求就关闭连接的话，那这个连接的数据传输很难达到带宽所能承载的速度。
基于这种种原 因，HTTP/1.1 很快出来了，提出了持久连接（persistentconnection）的概念，也就是说同一条 HTTP连接，可以依次处理多个请求，同时用一定的机制保证各个请求之间的分离性。具体的操作过程是：服务器给浏览器发送回应之后，并不马上关闭连接；浏 览器判断上一个请求的回应已经收完的情况下，可以在这同一个连接上发第二个请求。这种运作模式大大减少了网络包，实验也表明这种做法很有效。但是，由于服 务器上保持连接要占用一定的资源，所以一般服务器不会永久保持持久连接，而且也不推荐浏览器和服务器之间建立过多的持久连接。
持久连接可以进一步提速。这就是 pipelining了。上面可以看到，浏览器需要等待持久连接里上一个请求的回应完全收完才能发送后面的请求。如果和服务器的连接比较慢，往往持久连接 大部分时间都花在等待而非数据发送/接收上。pipelining的意思是，浏览器可以在一个持久连接里一次给服务器发送多个请求，服务器在这个连接上依 次回应这些请求。这种运作方式和浏览器缓存结合起来的时候会尤其有效果。比方，图片浏览过后会存在浏览器缓存中，再次请求的时候浏览器会对服务器说，我这 里已经有这个图片的缓存了，修改时间是XXXX，如果服务器上这个图片在这之后没有修改过，就不用重发了。这种情况下，服务器会发一个很短的 304 Not Modified 类型的回应。如果没有pipelining，每次这样问一下都要等待网络上传输打一个来回；而如果有 pipelining，浏览器可以同时问服务器我这里 4个图片是否有修改，如果服务器对 pipelining 支持的好，它甚至可以将四个回应放到同一个网络包里面传回来，这是一个大大的加速。
pipelining 最早提出的时候还有一种设想的用法是，如果服务器对 pipelining 支持的好，可以把同一个 pipeline 里面的两个请求放到两个 CPU 上去处理，这样能进一步加快响应速度。当然这个可能也没什么用。
附录2：http协议详解