web推送WebSocket 是什么原理？如何实现消息实时推送

如何使用WebSocket

这里WebSocketServer对象通过Setup方式对要侦听的IP及端口进行了设置。

然后使用Start方法启动侦听。

　　Setup方法有4种重载，但是我们通常用到的只有设置IP和端口，IP为string类型，如果传入的字符串无法被转换为支持的IP格式，Setup方法会返回false表示设置失败。

　　WebSocketServer还提供了4个事件用以管理与客户端的连接、断开、和接受消息动作。

新版本的WebSocket支持传送的数据格式有 “文本” 和 “二进制”两种，NewMessageReceived事件用于处理文本类型的消息，NewDataReceived事件用于处理二进制类型的消息。

　　到这里 我们已经成功的搭建了一个实现了WebSocket协议的服务端了。

至于服务端的寄宿方式有很多，SuperWebSocket框架支持以 控制台、Winform、IIS以及Windows服务的形式寄宿服务，不过网上很多资料都不建议在IIS中寄宿服务，据说是因为寄宿在IIS中性能比较低。

　　WebSocket既然是双工通信，那么我们就不能光等着接收来自客户端的消息， 我们也需要从服务端向客户端“推送”消息，现在我们来看如何由服务端向客户端发送消息。

　　SuperWebSocket框架中，服务端与客户端创建的连接对象为WebSocketSession类型，也就是说它将每一个客户端的实例视为一个会话，在客户端创建连接的时候，产生这个会话，在客户端断开连接的时候，销毁这个会话，而客户端与服务端进行消息通信的时候，也依赖这个会话进行传递。

我们要实现服务器端向客户端的广播，就要获取到当前正在活动的所有会话，我们通过代码来看如何获取所有的会话 wsServer.Get AllSessions() //获取所有的会话 已断开的会话不会出现在集合中 　　很简单吧，在获取到活动的会话之后 我们就可以向客户端发送消息了，这里我们让服务器向客户端定时发送服务器时间 复制代码 Timer timer = new Timer((data) => { var msg = string.Format("服务器当前时间：{0:HH:MM:ss}", DateTime.Now); //对当前已连接的所有会话进行广播 foreach (var session in wsServer.GetAllSessions()) { session.Send(msg); } }, null, 1000, 1000); 复制代码 　　这样 所有与服务端保持连接的客户端就都可以接受到来自服务器端的消息了。

　　在这个例子里 我们看到了所有的消息都是由会话对象发出的，会话对象Send的消息 也支持“文本”与“二进制两种形式，同时会话对象还提供一个SendCloseHandshakeResponse()方法向客户端发送一个强制断开连接的指令。

　　WebSocketSession对象包含了服务端和客户端的所有信息，以及WebSocketServer对象本身，我们可以利用它做很多事情，下边我们就来实现一个简单的聊天室。

至于聊天室的原理 就是一个人将要说的话发送到服务器，再由服务器广播给在这个聊天室里的所有人看到。

恩 就这么简单。

我们来上代码，多了不解释，相当简单。

View Code 　　关与SuperWebSocket的基本使用就介绍到这里了……顶着老板不时窥屏的压力，可能文章有点语无伦次，希望大家多多体谅，也希望大家提出宝贵意见 共同学习。

下一篇我会考虑介绍“子协议”和SuperWebSocket提供的Json字符串类型数据的处理

微信开发，请问如何用网站推送微信消息

你说的网站是指什么网站，你是要推送微信消息这个就很简单，在微信公众号编辑好你的素材然后发送在你的微信号上，打开消息右上角点开有复制链接，这个链接你可以发到你的网站上面去，当人家打开这个链接就可以进入到你发的这条微信消息去了。

如果不是这个意思，希望你描述得更清晰一点，谢谢

手机弹出的网页推送怎么关闭？

可以通过点击关闭按钮进行关闭，也可以通过设置对这些广告进行拦截。

1.打开手机浏览器，在功能菜单里找到设置，点击打开设置页面。

2.在设置里可以看到有广告屏蔽的选项，点击进行授权系统将会将一些不重要的网站广告进行过滤拦截，并且不会再推送。

在UWP中,如何实现通过服务器为设备推送通知？

对于某些类型的应用来说，服务器推送事件是最佳的选择。

本文对服务器推送技术进行了详细的介绍，包含浏览器端和服务器端的相应实现细节，为在实践中使用该技术提供了指南。

对于一般的Web应用开发，大多数开发人员并不陌生。

在Web应用中，浏览器和服务器之间使用的是请求/响应的交互模式。

浏览器发出请求，服务器根据收到的请求来生成相应的响应。

浏览器再对收到的响应进行处理，展现给用户。

响应的格式可能是HTML、XML或JSON等。

随着REST架构风格和AJAX的流行，服务器地使用JSON作为响应的数据格式。

Web应用使用XMLHttpRequest对象来发送请求，并根据服务器端返回的数据，对页面的内容进行动态更新。

通常来说，用户在页面上的操作，比如点击或移动鼠标，会触发相应的事件。

由XMLHttpRequest对象来发出请求，得到服务器响应之后进行页面的局部更新。

这种方式的不足之处在于：服务器端产生的数据变化不能及时地通知浏览器，而是需要等到下次请求发出时才能被浏览器获取。

对于某些对数据实时性要求很高的应用来说，这种延迟是不能接受的。

为了满足这类应用的需求，就需要有某种方式能够从服务器端推送数据给浏览器，以保证服务器端的数据变化可以在第一时间通知给用户。

目前常见的解决法有不少，主要可以分成两类。

这两类方法的区别在于是否基于HTTP协议来实现。

不使用HTTP协议的做法是使用HTML5新增的WebSocket规范，而使用HTTP协议的做法则包括简易轮询、COMET技术和本文中要介绍的HTML5服务器推送事件。

下面会对这几种技术进行介绍。

简介在介绍HTML5服务器推送事件之前，首先介绍一些上面提到的几种服务器端数据推送技术。

第一种是WebSocket。

WebSocket规范是HTML5中的一个重要组成部分，已经被很多主流浏览器所支持，也有不少基于WebSocket开发的应用。

正如名称所表示的一样，WebSocket使用的是套接字连接，基于TCP协议。

使用WebSocket之后，实际上在服务器端和浏览器之间建立一个套接字连接，可以进行双向的数据传输。

WebSocket的功能是很强大的，使用起来也灵活，可以适用于不同的场景。

不过WebSocket技术也比较复杂，包括服务器端和浏览器端的实现都不同于一般的Web应用。

除了WebSocket之外，其他的实现方式是基于HTTP协议来达到实时推送的效果。

第一种做法是简易轮询，即浏览器端定时向服务器端发出请求，来查询是否有数据更新。

这种做法比较简单，可以在一定程度上解决问题。

不过对于轮询的时间间隔需要进行仔细考虑。

轮询的间隔过长，会导致用户不能及时接收到更新的数据；轮询的间隔过短，会导致查询请求过多，增加服务器端的负担。

COMET技术改进了简易轮询的缺点，使用的是长轮询。

长轮询的方式在每次请求时，服务器端会保持该连接在一段时间内处于打开状态，而不是在响应完成之后就立即关闭。

这样做的好处是在连接处于打开状态的时间段内，服务器端产生的数据更新可以被及时地返回给浏览器。

当上一个长连接关闭之后，浏览器会立即打开一个新的长连接来继续请求。

不过COMET技术的实现在服务器端和浏览器端都需要第三方库的支持。

综合比较上面提到的4种不同的技术，简易轮询由于其本身的缺陷，并不推荐使用。

COMET技术并不是HTML5标准的一部分，从兼容标准的角度出发，也不推荐使用。

WebSocket规范和服务器推送技术都是HTML5标准的组成部分，在主流浏览器上都提供了原生的支持，是推荐使用的。

不过WebSocket规范更加复杂一些，适用于需要进行复杂双向数据通讯的场景。

对于简单的服务器数据推送的场景，使用服务器推送事件就足够了。

在浏览器支持方面，服务器推送事件已经在除IE外的大部分桌面和移动浏览器上得到了支持。

支持服务器推送事件的浏览器及其版本包括：Firefox6.0+、Chrome6.0+、Safari5.0+、Opera11.0+、iOSSafari4.0+、OperaMobile11.1+、ChromeforAndroid25.0+、FirefoxforAndroid19.0+以及BlackberryBrowser7.0+等。

关于IE的支持，在下面的章节中有详细的介绍。

下面对服务器推送事件的规范进行具体的说明。

规范Server-sentEvents规范是HTML5规范的一个组成部分，具体的规范文档见参考资源。

该规范比较简单，主要由两个部分组成：第一个部分是服务器端与浏览器端之间的通讯协议，第二部分则是在浏览器端可供JavaScript使用的EventSource对象。

通讯协议是基于纯文本的简单协议。

服务器端的响应的内容类型是“text/event-stream”。

响应文本的内容可以看成是一个事件流，由不同的事件所组成。

每个事件由类型和数据两部分组成，同时每个事件可以有一个可选的标识符。

不同事件的内容之间通过仅包含回车符和换行符的空行（“ ”）来分隔。

每个事件的数据可能由多行组成。

代码清单1给出了服务器端响应的示例。

清单1.服务器端响应的示例data:firsteventdata:secondeventid:100event:myeventdata:thirdeventid:101:mentdata:fourtheventdata:fourtheventcontinue如代码清单1所示，每个事件之间通过空行来分隔。

对于每一行来说，冒号（“:”）前面表示的是该行的类型，冒号后面则是对应的值。

可能的类型包括：类型为空白，表示该行是注释，会在处理时被忽略。

类型为data，表示该行包含的是数据。

以data开头的行可以出现多次。

所有这些行都是该事件的数据。

类型为event，表示该行用来声明事件的类型。

浏览器在收到数据时，会产生对应类型的事件。

类型为id，表示该行用来声明事件的标识符。

类型为retry，表示该行用来声明浏览器在连接断开之后进行再次连接之前的等待时间。

在代码清单1中，第一个事件只包含数据“firstevent”，会产生默认的事件；第二个事件的标识符是100，数据为“secondevent”；第三个事件会产生类型为“myevent”的事件；最后一个事件的数据为“fourthevent fourtheventcontinue”。

当有多行数据时，实际的数据由每行数据以换行符连接而成。

如果服务器端返回的数据中包含了事件的标识符，浏览器会记录最近一次接收到的事件的标识符。

如果与服务器端的连接中断，当浏览器端再次进行连接时，会通过HTTP头“Last-Event-ID”来声明最后一次接收到的事件的标识符。

服务器端可以通过浏览器端发送的事件标识符来确定从哪个事件开始来继续连接。

对于服务器端返回的响应，浏览器端需要在JavaScript中使用EventSource对象来进行处理。

EventSource使用的是标准的事件监听器方式，只需要在对象上添加相应的事件处理方法即可。

EventSource提供了三个标准事件，如表1所示。

表1.EventSource对象提供的标准事件名称说明事件处理方法open当成功与服务器建立连接时产生onopenmessage当收到服务器发送的事件时产生onmessageerror当出现错误时产生onerror如之前所述，服务器端可以返回自定义类型的事件。

对于这些事件，可以使用addEventListener方法来添加相应的事件处理方法。

代码清单2给出了EventSource对象的使用示例。

清单2.EventSource对象的使用示例vares=newEventSource('events');es.onmessage=function(e){console.log(e.data);};es.addEventListener('myevent',function(e){console.log(e.data);});如代码清单2所示，在指定URL创建出EventSource对象之后，可以通过onmessage和addEventListener方法来添加事件处理方法。

当服务器端有新的事件产生，相应的事件处理方法会被调用。

EventSource对象的onmessage属性的作用类似于addEventListener(‘message’)，不过onmessage属性只支持一个事件处理方法。

在介绍完服务器推送事件的规范内容之后，下面介绍服务器端的实现。

如何做安卓推送

在安卓系统上做推送的方法如下： 1. 通过2113SMS进行服务器端和客户端的交流通信。

在Android平台上，你可以通过拦截SMS消息并且解析消息内容来了解服务器的意图，可以实现完全的实时操作。

但是问题是这个方案的成5261本相对比较高，且依赖于运营商。

2. 循环主动定时获取：　　这种方法需要客户端来做一个定时或者周期性的访问服务器端接口，以获得最新的消息。

轮询的频率太慢可能导致某些消息的延迟，太快则会大量消耗网络带宽和电池。

3. 持久连接：4102这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。

我们需要开一个服务来保持和服务器端的1653持久连接（苹果就和谷歌的C2DM是这种版机制）。

但是对于Android系统，当系统可用资源较低，系统会强制关闭我们的服务或者是应用，这种情况下连接会强制中断。

（Apple的推送服务之所以工作的很好，是因为每一台权手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。

即所有的推送服务都是经由一个代理服务器完成的，这种情况下只需要和一台服务器保持持久连接即可。

C2DM=Cloud to Device Messaging）。

WebSocket 是什么原理？如何实现消息实时推送

目前要实现消息实时推送，有两种方法，一种是ajax轮询，由客户端不停地请求服务器端，查询有没有新消息，然后再由服务器返回结果；另外一种就是long poll,通过一次请求，询问服务器有没有新消息更新，如果没有新消息时，会保持长连接，就一直不返回Response给客户端。

直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。

这两种都是单向链接，需要被动的请求服务器，而不是由服务器自动发给客户端。

从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。

何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。

简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。