有关“短连接”模式的学习

1) 简单说明“长连接”模式

“长连接”的基本含义是长时间保持客户端和服务器之间的连接状态,在长连接模式下,一旦进行accept()操作成功之后,客户端需要持续不断的发送消息,相对应的,服务器端需要持续不断的接收消息。再者来说,长连接是指,在一个TCP连接上可以持续发送多个数据包,在TCP连接期间,就算此时没有消息的发送,他这个TCP连接也不会断开,会一直维持连接的状态。

2)“短连接”

基于上面对“长连接”的了解,接下来解释“短连接”的相关知识:
与“长连接”相对应,“短连接”是指,短期内维持客户端和服务器之间的连接状态,当通信双方存在信息的交互时,就建立一个TCP连接,基于这个连接进行信息的收发,一旦信息的交互完成时,TCP连接就会断开,并不是一直存在,这种模式叫做“短”连接。

在“短连接”模式下,客户端需要维持一个线程去持续不断的侦听服务器端的消息响应,为了对客户端进行更好的管理,可以把发出连接请求的客户端都放到一个公有的容器(池子)中。服务器端并不需要维持一个线程去接收对端的消息,它是通过“轮询”的方式在容器中查看哪个客户端发出了消息“请求”,进而激活一个线程专门处理客户端发过来的消息,并将处理结果作为“响应”返回给客户端。

用以上这种方式处理客户端和服务器之间的通信,需要考虑一个很重要的问题:这个共有的容器肯定是有一定的容量,不可能无境止地容载大量的客户端进入,万一容器“满”了怎么办,该怎么去保证新来的客户端能够顺利进入容器?

在这里给出一种解决方法——换入换出,下面详细来解释这种方法。为了保证客户端进入容器,需要每隔一段时间对容器中存在的客户端进行淘汰。那么,淘汰的原则呢?自然是需要把那些一直不发送请求,也就是活跃度很低的客户端从容器中“踢”出去,不能让那些长时间不“说话”的客户端在容器中占地方。淘汰的方法是。给进入容器的每一个客户端设置一个计数器,每次有客户端发送请求时,就给容器中除这个之外的其他客户端计数加1,。如果某一个客户端一直不发送请求,那它每一次别的客户端发送请求时,它都需要给自身加1,一段时间之后,这个客户端的计数值肯定是最大的,自然就需要淘汰里面计数最大的。根据这种淘汰方法就可以保证新来的客户端可以顺利的进入容器,而不关心容器的容量。

3)“短连接”模式下的客户端和服务器

客户端方面:

首先查看“连接”情况,判断是否存在已有连接;若已经存在连接,则相当于完成了“连接”操作,(这种情况是通过“轮询”在容器中查看连接情况);若不存在连接,需要进行accept()操作对服务器发出连接请求进行真正的“连接”。
连接成功之后,接着是发送请求,等待服务器端的“响应”。

在这涉及到了**“同步”和“异步”**两种模式:

(同步)客户端发出请求后,需要等待服务器返回的响应结果,在这个等待过程中,客户端不能再进行其他的任何操作,也称为“阻塞模式”,只有在客户端接收到服务器返回的响应结果后,对返回结果进行处理,才可以继续进行下一步的操作。
(异步)客户端发出请求后,开启(激活)一个专门的线程去侦听服务器的响应返回结果,此时这种情况就相当于完成了本次会话,实现了“伪断开连接”,客户端本身不需要等待服务器的响应,还是可以继续进行后续的服务操作。

前面提到的“伪断开连接”从严格意义上来说,并不是真正的“短连接”,要实现真正的断开连接,大多是在进行“换入换出”操作的过程中,客户端被迫断开了与服务器之间的连接。客户端上述的一系列过程是一个整体的线程,这个线程并不是一直存在的。只要客户端向服务器发出一个请求,就开启这个整体线程从检查连接开始进行,同时需要开启一个子线程去侦听服务器的响应结果。这两个线程是“主干”和“分支”的关系,分支线程的运行情况并不会影响主干线程的运行。

服务器方面:

首先要明确的是,服务器并不会主动的给客户端发送消息,因为服务器不清楚存在哪些客户端,也不知道在未来哪个客户端会发出请求,而且同一个服务器可以允许多个客户端同时连接,有那么多的客户端上线,服务器不可能一个一个对客户端进行“询问”。
站在服务器的角度来说,客户端发出的请求是“相同”的,服务器不区分发出请求的客户端,也不去判断本次发出请求的客户端是否是上一次已经发送过请求的同一个客户端,服务器并不关心发送请求的客户端,也就是说,服务器不能预知客户端的状况。所以,服务器只是针对已经在容器中的客户端进行“轮询”操作,去查看哪个客户端发出了请求,进而接收请求进行处理,并把处理结果作为“响应”返回给客户端。 相比客户端来说,服务器所要做的事比客户端简单一些。

发布了6 篇原创文章 · 获赞 8 · 访问量 177

猜你喜欢

转载自blog.csdn.net/Ctrl_viviya/article/details/105288620