长连接的几种实现方式

在日常项目中,大多的时候我们用的是短连接,一个请求过来,一个线程处理完该请求,线程被线程池回收,这个请求就关闭了.虽然这能满足很大部分的需求,但是也有些问题,比如说:如果客户端发的请求比较多,比较频繁,服务端就会忙于建立连接处理请求,由于服务端的线程数也有限,并发比较大的话有可能会造成服务端的崩溃.那有没有一种办法使连接少一些,让一个线程可以处理多个连接?长连接的出现就是为了解决上面的问题.

     

 1.基于http协议的长连接

         在HTTP1.0和HTTP1.1协议中都有对长连接的支持。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能够支持，而HTTP1.1默认支持.

      http1.0请求与服务端的交互过程:

      a)客户端发出带有包含一个header：”Connection： keep-alive“的请求

      b)服务端接收到这个请求后,根据http1.0和”Connection： keep-alive“判断出这是一个长连接,就会在response的header中也增加”Connection： keep-alive“,同是不会关闭已建立的tcp连接.

      c)客户端收到服务端的response后,发现其中包含”Connection： keep-alive“，就认为是一个长连接，不关闭这个连接。并用该连接再发送request.转到a)

    http1.1请求与服务端的交互过程:

    a)客户端发出http1.1的请求

    b)服务端收到http1.1后就认为这是一个长连接,会在返回的response设置Connection： keep-alive,同是不会关闭已建立的连接.

    c)客户端收到服务端的response后,发现其中包含”Connection： keep-alive“，就认为是一个长连接，不关闭这个连接。并用该连接再发送request.转到a)

     基于http协议的长连接减少了请求,减少了建立连接的时间,但是每次交互都是由客户端发起的,客户端发送消息,服务端才能返回客户端消息.因为客户端也不知道服务端什么时候会把结果准备好,所以客户端的很多请求是多余的,仅是维持一个心跳,浪费了带宽.

 

2.基于Jetty Continuation实现的长连接

     在jetty6中,实现了一种"使HTTP请求可以被暂时挂起，并且当挂起超时或非同步的事件发生时，被挂起的HTTP请求可以被重新恢复"的机制.即一个请求过来后,发现服务端的数据还没准备好,就将该请求放入队列,处理该请求的线程放入线程池处理其它的请求,等数据准备好后再处理该请求,客户端收到数据后再发起新的请求.

     这样就可以减少客户端的请求,保证每个发出的请求都有数据返回,同时不会一直占用一个线程不放,增加服务端线程的使用效率,这个方式又叫"长轮询".

 

3.基于Servlet3实现的长连接

     Servlet3可以实现一旦请求被服务端接受就不再关闭连接,直到超时事件发生才重新建立新的连接  .它和基于http协议不同的是连接不会一直占用线程,并且一旦服务端数据准备好就可以发给客户端,不需要客户端来询问有没有准备好,客户端收到消息好,连接还在,不用重新建立连接.不会浪费带宽,也不会浪费请求,这种方式又叫"Comet 流".