RPC、基于netty的长连接和websocket

1 RPC

RPC也采用C/S的编程模式，以模块调用的简单性忽略通讯的具体细节,以便程序员不用关心C/S之间的通讯协议,集中精力对付实现过程.这就决定了 RPC生成的通讯包不可能对每种应用都有最恰当的处理办法,与Socket方法相比,传输相同的有效数据,RPC占用更多的网络带宽.

RPC实在socket的基础上实现的，但是它比socket需要更多的网络和资源系统。

2 基于netty的长连接

异步、高性能

Boss线程（一个服务器端口对于一个）---接收到客户端连接---生成Channel---交给Work线程池（多个Work线程）来处理。

具体的Work线程---读完已接收的数据到ChannelBuffer---触发ChannelPipeline中的ChannelHandler链来处理业务逻辑。

执行ChannelHandler链的整个过程是同步的，如果业务逻辑的耗时较长，会将导致Work线程长时间被占用得不到释放，从而影响了整个服务器的并发处理能力。

3 websocket

WebSocket连接服务器和客户端，这个链接是一个实时的长连接，服务器端一旦与客户端建立了双向链接，就可以将数据推送到Socket中，客户端只要有一个Socket绑定的地址和端口与服务器建立联系，就可以接收推送来的数据。

WebSocket 还是一个双通道的连接，在同一个 TCP 连接上既可以发也可以收信息.

让服务器和客户端能够发送 Ping/Pong Frame。这种 Frame 是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application 的情况下维持住中间网络的连接状态

时间： 2024-10-12 20:08:33

RPC、基于netty的长连接和websocket的相关文章

基于分布式Http长连接框架--架构模型

我画了个简单的架构图来帮助说明: 其实为发布订阅架构模式. 生产者和消费者我们统一可理解为客户端,消息中间件可认为是服务端. 生产者和消费者做为客户端要跟服务端交互,则先通过代理订阅服务端,订阅成功后即可跟服务端互通互联,此刻的连接通道为长连接. 长连接的优势在于会将消息主动通知到客户端,避免客户端去做大量的轮询工作而造成资源浪费,而且对于移动应用来说,可较大程度上节省GPRS流量. 当连接建立好后,生产者可随时发送消息,如果在发消息过程当中,服务端由于各种原因不能连接,则消息的发送会回放重试,

基于分布式Http长连接框架--代码模型

好的代码应该是方便客户端使用,代码能够自描述,规范化,大众标准化. 而且我相信代码也是有生命的,需要不断的维护它,你以什么样的态度对待它,它就会以同样的态度回敬你,所以在写代码前,先摆好自己的态度(一个心态良好的创造者),只有这样你的生命才会精彩,代码的生命也会精彩. 前面说了简单的框架模型,简单的设计模型,如果具体到客户端使用的话还需要代码模型来描述下,当作集成的sdk说明即可. 生产者如何发送消息: 1:配置服务端地址及名称; 2:注册本身为客户端,并约定一个全局唯一的名称 3:开启代理 4

基于Ajax的长连接

JS代码: 1 <script> 2 function longPolling() { 3 $.ajax({ 4 url: "testlp", 5 data: { "time": 2, "timeout": 3 },//time:假设传输数据时间,timenout:最大延迟 6 dataType:'JSON', 7 success: function (data) { 8 //输出data 9 longPolling(); 10 }

Netty 长连接服务

转自:https://www.dozer.cc/2014/12/netty-long-connection.html 推送服务 还记得一年半前,做的一个项目需要用到 Android 推送服务.和 iOS 不同,Android 生态中没有统一的推送服务.Google 虽然有 Google Cloud Messaging ,但是连国外都没统一,更别说国内了,直接被墙. 所以之前在 Android 上做推送大部分只能靠轮询.而我们之前在技术调研的时候,搜到了 jPush 的博客,上面介绍了一些他们的技

170122、Netty 长连接服务

推送服务 还记得一年半前,做的一个项目需要用到 Android 推送服务.和 iOS 不同,Android 生态中没有统一的推送服务.Google 虽然有 Google Cloud Messaging ,但是连国外都没统一,更别说国内了,直接被墙. 所以之前在 Android 上做推送大部分只能靠轮询.而我们之前在技术调研的时候,搜到了 jPush 的博客,上面介绍了一些他们的技术特点,他们主要做的其实就是移动网络下的长连接服务.单机 50W-100W 的连接的确是吓我一跳!后来我们也采用了他们

Web 通信 之 长连接、长轮询（long polling）(转载)

基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性. 一.什么是长连接.长轮询? 用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息.这里的“不停”其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已. 二.长连接.长轮询的应用场景 长连接.长轮询一般应用与WebIM.ChatRoom和一些需要及时交互的网站应用中.其真实案例有:WebQQ

HTTP 长连接 使用场景

offer 80 非常多应用譬如监控.即时通信.即时报价系统都须要将后台发生的变化实时传送到client而无须client不停地刷新.发送请求. 在 多好科技的那位技术指导问我这个是由于他们做物连网,监控,使用长连接多. Comet:基于 HTTP 长连接的"server推"技术 HTML5后 .WebSocket替代 Comet实现 长连接:WebSocket的维基 从WebSocket看到Jetty :  Jetty(Web Server) Google 选择 Jetty 放弃to

Web 通信 之 长连接、长轮询（long polling）

基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性. 一.什么是长连接.长轮询? 用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息.这里的“不停”其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已. 二.长连接.长轮询的应用场景 长连接.长轮询一般应用与WebIM.ChatRoom和一些需要及时交互的网站应用中.其真实案例有:WebQQ

Web 通信 之 长连接、长轮询(转）

Web 通信 之 长连接.长轮询(long polling) 基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性. 一.什么是长连接.长轮询? 用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息.这里的"不停"其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已. 二.长连接.长轮询的应用场景 长连接.长轮询一般应用与W