做外贸的都有那些网站,响应式网站建设报价单,注册公司需要几个人员,免费的软件网站建设SSE(Server-Sent Events):通俗解释起来就是一种基于HTTP的#xff0c;以流的形式由服务端持续向客户端发送数据的技术应用场景由于HTTP是无状态的传输协议,每次请求需由客户端向服务端建立连接,HTTPS还需要交换秘钥#xff0c;所以一次请求,建立连接的过程占了很大比例在http…SSE(Server-Sent Events):通俗解释起来就是一种基于HTTP的以流的形式由服务端持续向客户端发送数据的技术应用场景由于HTTP是无状态的传输协议,每次请求需由客户端向服务端建立连接,HTTPS还需要交换秘钥所以一次请求,建立连接的过程占了很大比例在http1.1中(1.0也有但未写入标准),虽然增加了keep-alive来保持和服务器的长连接,省去了很多建立连接的过程,但通信过程仍然是应答式1:1的方式也就是想要获得数据就必须先发送一个request才能得到一个response,所以在实时监控、推送、视频直播等实时性较高或者带宽利用较苛刻的场景仍然不是很合适SSE技术由于能保持连接并持续接收服务端的数据所以弥补了这一缺点,与其他类似技术方案相比短轮询、Coment、WebSocket在大多数时候SSE仍然是最好的选择各技术方案的优缺点短轮询短轮询很简单即客户端定时的向服务端发送请求如果服务端有数据返回则返回数据否则返回空数据优点:实现简单缺点:如果想实时性好则必须轮询间隔短但会有大量的请求是无效的(返回空数据),如果轮询间隔长则实时性不好数据到达客户端的延时最大会趋近于轮询间隔Coment:一种HACK技术以即时通信为代表的web应用程序对数据的Low Latency要求传统的基于轮询的方式已经无法满足而且也会带来不好的用户体验。于是一种基于http长连接的“服务器推”技术便被hack出来。这种技术被命名为Comet这个术语由Dojo Toolkit 的项目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出并沿用下来。Coment技术有两种实现,分别是长轮询(long-polling)和基于 Iframe 及 htmlfile 的流(http streaming)方式1.长轮询(long-polling)浏览器发出ajax 请求服务器端接收到请求后会阻塞请求直到有数据或者超时才返回浏览器JS在处理请求返回信息(超时或有效数据)后再次发出请求重新建立连接。在此期间服务器端可能已经有新的数据到达服务器会选择把数据保存直到重新建立连接浏览器会把所有数据一次性取回。优缺点这种技术没有明显的优缺点,如果非要说就是需要额外的框架支持吧,且在之前服务端异步编程支持程度并不高的时候,(例如java的servlet3.0之前),后端也需要额外的框架支持2.基于 Iframe 及 htmlfile 的流Iframe是html标记这个标记的src属性会保持对指定服务器的长连接请求服务器端则可以不停地返回数据相对于第一种方式这种方式跟传统的服务器推则更接近。在第一种方式中浏览器在收到数据后会直接调用JS回调函数但是这种方式该如何响应数据呢可以通过在返回数据中嵌入JS脚本的方式如“”服务器端将返回的数据作为回调函数的参数浏览器在收到数据后就会执行这段JS脚本。缺点:IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成而且 IE 上方的图标会不停的转动表示加载正在进行。WebSocket类似TCP socket参考WebSocket详解优点:双工通信缺点:需专门定义数据协议解析数据流且部分服务器支持不完善后台例如java spring boot 2.1.2 仅支持websocket 1.0(最高已达1.3)SSE优点:开发简单和传统的http开发几乎无任何差别,客户端开发简单,有标准支持(EventSource)缺点:和websocket相比只能单工通信建立连接后只能由服务端发往客户端且占用一个连接如需客户端向服务端通信需额外打开一个连接其他在基于spring的开发中,可以使用SseEmitter类进行通信GetMapping(value /watch, produces MediaType.TEXT_EVENT_STREAM_VALUE)public synchronized SseEmitter watch(HttpServletRequest request, RequestParam(point) String point) throws Exception {final HttpSession session request.getSession();//此处超时时间优先级高于servlet容器的request timeout,PS:此超时时间固定无法通过心跳等其他手段保持连接超时后 浏览器端默认会重新连接,但SeeEmitter无法复用SseEmitter emitter new SseEmitter(300 * 1000L);String key String.format(watch:%s, point);WatchConsumer consumer new WatchConsumer(client, emitter, point);if (this.client.watch(point, consumer)) {emitter.onCompletion(() - session.removeAttribute(key));emitter.onTimeout(() - session.removeAttribute(key));emitter.onError(throwable - {throwable.printStackTrace();session.removeAttribute(key);});session.setAttribute(key, consumer);}return emitter;}也可以利用WebFluxGetMapping(/stream-sse)public Flux streamEvents() {return Flux.interval(Duration.ofSeconds(1)).map(sequence - ServerSentEvent. builder().id(String.valueOf(sequence)).event(periodic-event).data(SSE - LocalTime.now().toString()).build());}但相比之下SseEmitter有OnTimeout和OnCompletion等事件更加灵活PS:由于浏览器对于同一个domain,有并发数限制例如chrome最大是6,长连接会持续性的占用一个连接同时会占用一个服务器端的一个连接
