由于blog各种垃圾评论太多,而且本人审核评论周期较长,所以懒得管理评论了,就把评论功能关闭,有问题可以直接qq骚扰我

Web性能优化之-HTTP长连接

web 西门飞冰 4716℃

声明:本文转载自运维社区,微信公共号文章。

前言

当我们使用浏览器访问一个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。

1

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

keepalive_timeout 60;

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

2

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

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

[root@test conf]#netstat -na | grep  192.168.99.159:80
tcp        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:80
tcp        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:80
tcp        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应用的特点和具体需要。这是答案可能让很多人不太满意,但是事实便是如此。不过我可以给出一个生产实践的经验,那就是在大多数应用中应该是开启长连接,然后通过相关的测试,来确定长连接的超时时间,而不是使用网上文档写的某个时间。

 

转载请注明:西门飞冰的博客-专注于Linux运维 » Web性能优化之-HTTP长连接

喜欢 (2)or分享 (0)