前言：

当我们使用浏览器访问一个Web站点的时候，我们的电脑会和Web服务器建立一条HTTP的连接，那么在这个连接层面是否可以进行性能优化呢？下面我们要讲解的就是HTTP的长连接和短连接的相关知识。

HTTP连接和TCP连接

在OSI七层模型中，HTTP是应用层的协议，你很容易能得到这样的总结：HTTP长连接和短连接本质上指的是TCP的长连接和短连接，如果你感到惊讶，那么需要重新复习下数据的封装和解封装。

长连接

首先，我们先从长连接开始，因为从HTTP/1.1开始，默认使用长连接。而且主流浏览器和Web服务器默认情况下都使用的是HTTP/1.1。也就是说现在我们使用的浏览器再发起HTTP请求的时候默认会在请求头部告诉Web服务器，我要使用长连接。下面是我访问https://www.unixhot.com/浏览器发送的HTTP请求头信息，可以看到Connection: keep-alive。

本例中Web服务器是Nginx，默认开启了长连接，在http的配置段内设置了：

keepalive_timeout 60;

意思就是开启Nginx的长连接，超时时间为60秒。下面是Web服务器的响应：

在长连接的情况下，当一个网页打开后，客户端和服务器之间传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的资源，会继续使用这条已经建立的连接。

如果在长连接的情况下，你查看服务器的TCP连接可以看到一个TCP的socket，状态是ESTABLISHED。

[root@test conf]#netstat -na | grep  192.168.99.159:80tcp        0     0 192.168.99.159:80       192.168.99.50:24584     ESTABLISHED

还记得我设置的超时时间吗？keepalive_timeout 60;等过了60秒之后，再次查看这个socket的状态，你会发现已经转变为TIME_WAIT，而且在Linux系统中这个状态会持续60秒，在这期间这个Socket是不会被释放。也就是用户访问我们的服务器发起的一个HTTP请求，在Web服务器端会占用一个Socket的连接，加上TCP建立连接的时间要120多秒。

[root@test conf]#netstat -na | grep  192.168.99.159:80tcp        0     0 192.168.99.159:80      192.168.99.50:24584    TIME_WAIT

那么如果在大并发的Web服务器中，长连接会造成什么后果呢？有兴趣的读者，一定要试一试。

短连接

在HTTP/1.0中，默认使用的是短连接。浏览器和服务器每进行一次HTTP操作就建立一次连接，然后请求结束就直接中断连接。试想一下，我们一个普通页面如果有近百个Web资源(JavaScript、CSS、图片),那么浏览器每请求一次资源都会新建一个HTTP会话，而且我们也知道本质上就是每次会创建一个TCP连接，那么每次都要经历TCP的三次握手和四次挥手。

在HTTP短连接的状态下，浏览器和我们的Web服务器重复的进行下面的操作：

建立连接–>数据传输–>关闭连接

至少目前来看HTTP短连接显然是影响性能的，现在我把运行Nginx的Web服务器的长连接关闭，再来进行一次测试：

keepalive_timeout  0;#keepalive_timeout  60;

和我们预想的一样，在TCP层面的Socket并没有长期的处于ESTABLISHED状态。

[root@test conf]#netstat -na | grep  192.168.99.159:80tcp        0     0 192.168.99.159:80      192.168.99.50:26056     TIME_WAIT

HTTP长连接的优点

我们使用了HTTP长连接后，可以省去很多TCP建立和关闭的步骤，节省了时间。而且因为服务器同时打开的连接减少了，可以降低网络阻塞，提高了资源请求的速度，因为后续请求无需再建立连接，减少了三次握手。例如在静态资源服务器中，一个页面往往有很多静态资源如图片、css、js等，那么在Web服务器上开启长连接，可以提高页面的打开速度。

HTTP长连接的缺点

长连接真的就一定好吗？还记得我们前面测试的结果，长连接的状态下，一个Socket的存在时间是建立连接时间+ keepalive_timeout时间+ TIME_WAIT时间。那么如果在高并发的场景下，我们的Web服务器要同时保持大量的Socket连接，那么肯定是占用系统的资源。那么这个时候就要根据实际的情况来修改keepalive_timeout的值，直到一个合理的范围，那么这个需要根据自己的业务特点进行调整。

该如何抉择？

答案是：取决于Web应用的特点和具体需要。这是答案可能让很多人不太满意，但是事实便是如此。不过我可以给出一个生产实践的经验，那就是在大多数应用中应该是开启长连接，然后通过相关的测试，来确定长连接的超时时间，而不是使用网上文档写的某个时间。优化web,首先减少宽带传输，降低程序超时时间，提高访问效率。