Http长连接

曾经我面试过一位学生，刚好问到HTTP的长短链接，于是我问他短连接的适用场景，他跟我说，WEB网站一般都使用短连接。这让我很惊讶，同时我上网查了不少资料，发现不少人的博客都是这么说的。

而像WEB网站的http服务一般都用"短链接"，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

我一直觉得这是一种错误的误导，我们先看一下什么是长短链接。

长短链接

短连接就是每次都建立链接-->数据传输-->关闭链接。
长连接（持久链接）就是 建立链接-->数据传输-->..保持链接..-->数据传输-->关闭链接

但是每次建立链接都是需要TCP三次握手的，也就是需要1.5个RTT，如果我们都是用短连接，那么每次都要进行握手。我们来看一下。

传输文件

假设客户端与服务器之间的延迟是28ms，我们要传输2个很小的文件（一个服务器响应时间40ms,一个20ms），如果我们都是用TCP短连接的话，那么第一个要152ms，第二个需要132ms，总共284ms。

持久链接

但是，如果我们使用持久链接，那么在传输第二个文件就不需要握手，直接传输，可以减少一个RTT时间，只要228ms。假如客户端与服务器之间只有一个TCP链接的话，我们使用持久链接传输n个文件，可以减少(n-1)个RTT。
所以为了优化WEB性能，我们通常使用的是长链接。

12306

为了印证这个推论，我看了好几个网站，发现的确如此。大部分的HTTP请求都是长连接，带有Connection:keep-alive参数（HTTP/1.1默认有该参数）。好了，长链接是会消耗服务器性能的，服务器是怎么解决这个问题的呢，那就是每个长链接其实都有一个超时时间，一旦超过这个时间服务器就关闭该链接。另外，原则上客户端最后一次请求会带一个close的参数（也只是原则上。。哈哈）