言碎语
今天来做个有趣的东西,就是实时将系统日志输出的前端web页面,因为是实时输出,所有第一时间就想到了使用webSocket,而且在spring boot中,使用websocket超级方便,阅读本文,你会接触到以下关键词相关技术,WebSocket(stopmp服务端),stomp协议,sockjs.min.js,stomp.min.js(stomp客户端),本文使用到的其实就是使用spring boot自带的webSocket模块提供stomp的服务端,前端使用stomp.min.js做stomp的客户端,使用sockjs来链接,前端订阅后端日志端点的消息,后端实时推送,达到日志实时输出到web页面的目的,效果如下图
首先了解下stomp?
STOMP即Simple (or Streaming) Text Orientated Messaging Protocol,简单(流)文本定向消息协议,它提供了一个可互操作的连接格式,允许STOMP客户端与任意STOMP消息代理(Broker)进行交互。STOMP协议由于设计简单,易于开发客户端,因此在多种语言和多种平台上得到广泛地应用。
STOMP协议的前身是TTMP协议(一个简单的基于文本的协议),专为消息中间件设计。
STOMP是一个非常简单和容易实现的协议,其设计灵感源自于HTTP的简单性。尽管STOMP协议在服务器端的实现可能有一定的难度,但客户端的实现却很容易。例如,可以使用Telnet登录到任何的STOMP代理,并与STOMP代理进行交互。
下面是具体的步骤,主要是日志信息的获取和日志信息的推送,不多说,上代码
一.引入spring boot websocket依赖
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId> </dependency>
二.新增日志消息实体
/** * Created by kl on 2017/10/9. * Content :日志消息实体,注意,这里为了减少篇幅,省略了get,set代码 */ public class LoggerMessage{ private String body; private String timestamp; private String threadName; private String className; private String level; public LoggerMessage(String body, String timestamp, String threadName, String className, String level) { this.body=body; this.timestamp=timestamp; this.threadName=threadName; this.className=className; this.level=level; } public LoggerMessage() { } }
三. 创建一个阻塞队列,作为日志系统输出的日志的一个临时载体
public class LoggerQueue { //队列大小 public static final int QUEUE_MAX_SIZE=10000; private static LoggerQueue alarmMessageQueue=new LoggerQueue(); //阻塞队列 private BlockingQueueblockingQueue=new LinkedBlockingQueue<>(QUEUE_MAX_SIZE); private LoggerQueue() { } public static LoggerQueue getInstance() { return alarmMessageQueue; } /** * 消息入队 * @param log * @return */ public boolean push(LoggerMessage log) { return this.blockingQueue.add(log);//队列满了就抛出异常,不阻塞 } /** * 消息出队 * @return */ public LoggerMessage poll() { LoggerMessage result=null; try { result=this.blockingQueue.take(); } catch (InterruptedException e) { e.printStackTrace(); } return result; } }
四.获取logback的日志,塞入日志队列中
1.定义Logfilter拦截输出日志
public class LogFilter extends Filter{ @Override public FilterReply decide(ILoggingEvent event) { LoggerMessage loggerMessage=new LoggerMessage( event.getMessage() , DateFormat.getDateTimeInstance().format(new Date(event.getTimeStamp())), event.getThreadName(), event.getLoggerName(), event.getLevel().levelStr ); LoggerQueue.getInstance().push(loggerMessage); return FilterReply.ACCEPT; } }
2.配置logback.xml,添加我们自定义的filter
<?xml version="1.0" encoding="UTF-8"?> <configuration scan="true"> <include resource="org/springframework/boot/logging/logback/defaults.xml" /> <property name="LOG_FILE" value="${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}/}spring.log}" /> <include resource="org/springframework/boot/logging/logback/file-appender.xml" /> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>${CONSOLE_LOG_PATTERN}</pattern> <charset>utf8</charset> </encoder> <filter class="com.example.websocket.LogFilter"></filter> </appender> <root level="INFO"> <appender-ref ref="FILE" /> <appender-ref ref="CONSOLE" /> </root> </configuration>
五.配置WebSocket消息代理端点,即stomp服务端
@Configuration public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer{ @Override public void registerStompEndpoints(StompEndpointRegistry registry) { registry.addEndpoint("/websocket") .setAllowedOrigins("http://localhost:8976") .withSockJS(); } }
注意:为了连接安全,setAllowedOrigins设置的允许连接的源地址,如果在非这个配置的地址下发起连接会报403,进一步还可以使用addInterceptors设置拦截器,来做相关的鉴权操作
六.启动类,开启webSocket消息代理功能,并推送日志信息
@SpringBootApplication @EnableScheduling @EnableWebSocketMessageBroker public class WebsocketApplication { private Logger logger=LoggerFactory.getLogger(WebsocketApplication.class); public static void main(String[] args) { SpringApplication.run(WebsocketApplication.class, args); } @Autowired private SimpMessagingTemplate messagingTemplate; int info=1; @Scheduled(fixedRate=1000) public void outputLogger(){ logger.info("测试日志输出"+info++); } /** * 推送日志到/topic/pullLogger */ @PostConstruct public void pushLogger(){ ExecutorService executorService=Executors.newFixedThreadPool(2); Runnable runnable=new Runnable() { @Override public void run() { while (true) { try { LoggerMessage log=LoggerQueue.getInstance().poll(); if(log!=null){ if(messagingTemplate!=null) messagingTemplate.convertAndSend("/topic/pullLogger",log); } } catch (Exception e) { e.printStackTrace(); } } } }; executorService.submit(runnable); executorService.submit(runnable); } }
七.html页面,连接stomp服务端,订阅/topic/pullLogger的消息,展示日志信息
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>WebSocket Logger</title> <script src="https://cdn.bootcss.com/jquery/2.1.4/jquery.js"></script> <script src="https://cdn.bootcss.com/sockjs-client/1.1.4/sockjs.min.js"></script> <script src="https://cdn.bootcss.com/stomp.js/2.3.3/stomp.min.js"></script> </head> <body> <button onclick="openSocket()">开启日志</button><button onclick="closeSocket()">关闭日志</button> <div id="log-container" style="height: 450px; overflow-y: scroll; background: #333; color: #aaa; padding: 10px;"> <div></div> </div> </body> <script> var stompClient=null; $(document).ready(function() {openSocket();}); function openSocket() { if(stompClient==null){ var socket=new SockJS('http://localhost:8084/websocket?token=kl'); stompClient=Stomp.over(socket); stompClient.connect({token:"kl"}, function(frame) { stompClient.subscribe('/topic/pullLogger', function(event) { var content=JSON.parse(event.body); $("#log-container div").append(content.timestamp +" "+ content.level+" --- ["+ content.threadName+"] "+ content.className+" :"+content.body).append("<br/>"); $("#log-container").scrollTop($("#log-container div").height() - $("#log-container").height()); },{ token:"kltoen" }); }); } } function closeSocket() { if (stompClient !=null) { stompClient.disconnect(); stompClient=null; } } </script> </body> </html>
相关技术官网参考地址:
stomp.js客户端:http://jmesnil.net/stomp-websocket/doc/
scok.js客户端:https://github.com/sockjs/sockjs-client
spring webSocket:https://docs.spring.io/spring/docs/
源:前端工匠 作者:浪里行舟君
前言
HTTP/2 相比于 HTTP/1.1,可以说是大幅度提高了网页的性能,只需要升级到该协议就可以减少很多之前需要做的性能优化工作,当然兼容问题以及如何优雅降级应该是国内还不普遍使用的原因之一。
虽然 HTTP/2 提高了网页的性能,但是并不代表它已经是完美的了,HTTP/3 就是为了解决 HTTP/2 所存在的一些问题而被推出来的。
一、HTTP/1.1发明以来发生了哪些变化?
如果仔细观察打开那些最流行的网站首页所需要下载的资源的话,会发现一个非常明显的趋势。近年来加载网站首页需要的下载的数据量在逐渐增加,并已经超过了2100K。但在这里我们更应该关心的是:平均每个页面为了完成显示与渲染所需要下载的资源数已经超过了100个。
正如下图所示,从2011年以来,传输数据大小与平均请求资源数量不断持续增长,并没有减缓的迹象。该图表中绿色直线展示了传输数据大小的增长,红色直线展示了平均请求资源数量的增长。
HTTP/1.1自从1997年发布以来,我们已经使用HTTP/1.x 相当长一段时间了,但是随着近十年互联网的爆炸式发展,从当初网页内容以文本为主,到现在以富媒体(如图片、声音、视频)为主,而且对页面内容实时性高要求的应用越来越多(比如聊天、视频直播),于是当时协议规定的某些特性,已经无法满足现代网络的需求了。
二、HTTP/1.1的缺陷
1.高延迟--带来页面加载速度的降低
虽然近几年来网络带宽增长非常快,然而我们却并没有看到网络延迟有对应程度的降低。网络延迟问题主要由于队头阻塞(Head-Of-Line Blocking),导致带宽无法被充分利用。
队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时,在后面排队的所有请求也一并被阻塞,会导致客户端迟迟收不到数据。针对队头阻塞,人们尝试过以下办法来解决:
.icon1 { background: url(data:image/png;base64,<data>) no -repeat; } .icon2 { background: url(data:image/png;base64,<data>) no -repeat; }
2.无状态特性--带来的巨大HTTP头部
由于报文Header一般会携带"User Agent""Cookie""Accept""Server"等许多固定的头字段(如下图),多达几百字节甚至上千字节,但Body却经常只有几十字节(比如GET请求、 204/301/304响应),成了不折不扣的“大头儿子”。Header里携带的内容过大,在一定程度上增加了传输的成本。更要命的是,成千上万的请求响应报文里有很多字段值都是重复的,非常浪费。
3.明文传输--带来的不安全性
HTTP/1.1在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,这在一定程度上无法保证数据的安全性。
你有没有听说过"免费WiFi陷阱”之类的新闻呢?黑客就是利用了HTTP明文传输的缺点,在公共场所架设一个WiFi热点开始“钓鱼”,诱骗网民上网。一旦你连上了这个WiFi热点,所有的流量都会被截获保存,里面如果有银行卡号、网站密码等敏感信息的话那就危险了,黑客拿到了这些数据就可以冒充你为所欲为。
4.不支持服务器推送消息
三、SPDY 协议与 HTTP/2 简介
1.SPDY 协议
上面我们提到,由于HTTP/1.x的缺陷,我们会引入雪碧图、将小图内联、使用多个域名等等的方式来提高性能。不过这些优化都绕开了协议,直到2009年,谷歌公开了自行研发的 SPDY 协议,主要解决HTTP/1.1效率不高的问题。谷歌推出SPDY,才算是正式改造HTTP协议本身。降低延迟,压缩header等等,SPDY的实践证明了这些优化的效果,也最终带来HTTP/2的诞生。
HTTP/1.1有两个主要的缺点:安全不足和性能不高,由于背负着 HTTP/1.x 庞大的历史包袱,所以协议的修改,兼容性是首要考虑的目标,否则就会破坏互联网上无数现有的资产。如上图所示, SPDY位于HTTP之下,TCP和SSL之上,这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式),同时可以使用已有的SSL功能。
SPDY 协议在Chrome浏览器上证明可行以后,就被当作 HTTP/2 的基础,主要特性都在 HTTP/2 之中得到继承。
2.HTTP/2 简介
2015年,HTTP/2 发布。HTTP/2是现行HTTP协议(HTTP/1.x)的替代,但它不是重写,HTTP方法/状态码/语义都与HTTP/1.x一样。HTTP/2基于SPDY,专注于性能,最大的一个目标是在用户和网站间只用一个连接(connection)。从目前的情况来看,国内外一些排名靠前的站点基本都实现了HTTP/2的部署,使用HTTP/2能带来20%~60%的效率提升。
HTTP/2由两个规范(Specification)组成:
四、HTTP/2 新特性
1.二进制传输
HTTP/2传输数据量的大幅减少,主要有两个原因:以二进制方式传输和Header 压缩。我们先来介绍二进制传输,HTTP/2 采用二进制格式传输数据,而非HTTP/1.x 里纯文本形式的报文 ,二进制协议解析起来更高效。HTTP/2 将请求和响应数据分割为更小的帧,并且它们采用二进制编码。
它把TCP协议的部分特性挪到了应用层,把原来的"Header+Body"的消息"打散"为数个小片的二进制"帧"(Frame),用"HEADERS"帧存放头数据、"DATA"帧存放实体数据。HTP/2数据分帧后"Header+Body"的报文结构就完全消失了,协议看到的只是一个个的"碎片"。
HTTP/2 中,同域名下所有通信都在单个连接上完成,该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,根据帧首部的流标识可以重新组装。
2.Header 压缩
HTTP/2并没有使用传统的压缩算法,而是开发了专门的"HPACK”算法,在客户端和服务器两端建立“字典”,用索引号表示重复的字符串,还采用哈夫曼编码来压缩整数和字符串,可以达到50%~90%的高压缩率。
具体来说:
例如下图中的两个请求, 请求一发送了所有的头部字段,第二个请求则只需要发送差异数据,这样可以减少冗余数据,降低开销
3.多路复用
在 HTTP/2 中引入了多路复用的技术。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题,同时也接更容易实现全速传输,毕竟新开一个 TCP 连接都需要慢慢提升传输速度。
大家可以通过 该链接 直观感受下 HTTP/2 比 HTTP/1 到底快了多少。
在 HTTP/2 中,有了二进制分帧之后,HTTP /2 不再依赖 TCP 链接去实现多流并行了,在 HTTP/2中,
这一特性,使性能有了极大提升:
如上图所示,多路复用的技术可以只通过一个 TCP 连接就可以传输所有的请求数据。
4.Server Push
HTTP2还在一定程度上改变了传统的“请求-应答”工作模式,服务器不再是完全被动地响应请求,也可以新建“流”主动向客户端发送消息。比如,在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端,减少等待的延迟,这被称为"服务器推送"( Server Push,也叫 Cache push)
例如下图所示,服务端主动把JS和CSS文件推送给客户端,而不需要客户端解析HTML时再发送这些请求。
另外需要补充的是,服务端可以主动推送,客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过,浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略,换句话说,服务器不能随便将第三方资源推送给客户端,而必须是经过双方确认才行。
5.提高安全性
出于兼容的考虑,HTTP/2延续了HTTP/1的“明文”特点,可以像以前一样使用明文传输数据,不强制使用加密通信,不过格式还是二进制,只是不需要解密。
但由于HTTPS已经是大势所趋,而且主流的浏览器Chrome、Firefox等都公开宣布只支持加密的HTTP/2,所以“事实上”的HTTP/2是加密的。也就是说,互联网上通常所能见到的HTTP/2都是使用"https”协议名,跑在TLS上面。HTTP/2协议定义了两个字符串标识符:“h2"表示加密的HTTP/2,“h2c”表示明文的HTTP/2。
六、HTTP/3 新特性
1.HTTP/2 的缺点
虽然 HTTP/2 解决了很多之前旧版本的问题,但是它还是存在一个巨大的问题,主要是底层支撑的 TCP 协议造成的。HTTP/2的缺点主要有以下几点:
HTTP/2都是使用TCP协议来传输的,而如果使用HTTPS的话,还需要使用TLS协议进行安全传输,而使用TLS也需要一个握手过程,这样就需要有两个握手延迟过程:
①在建立TCP连接的时候,需要和服务器进行三次握手来确认连接成功,也就是说需要在消耗完1.5个RTT之后才能进行数据传输。
②进行TLS连接,TLS有两个版本——TLS1.2和TLS1.3,每个版本建立连接所花的时间不同,大致是需要1~2个RTT。
总之,在传输数据之前,我们需要花掉 3~4 个 RTT。
上文我们提到在HTTP/2中,多个请求是跑在一个TCP管道中的。但当出现了丢包时,HTTP/2 的表现反倒不如 HTTP/1 了。因为TCP为了保证可靠传输,有个特别的“丢包重传”机制,丢失的包必须要等待重新传输确认,HTTP/2出现丢包时,整个 TCP 都要开始等待重传,那么就会阻塞该TCP连接中的所有请求(如下图)。而对于 HTTP/1.1 来说,可以开启多个 TCP 连接,出现这种情况反到只会影响其中一个连接,剩余的 TCP 连接还可以正常传输数据。
读到这里,可能就会有人考虑为什么不直接去修改 TCP 协议?其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长,已经充斥在各种设备中,并且这个协议是由操作系统实现的,更新起来不大现实。
2.HTTP/3简介
Google 在推SPDY的时候就已经意识到了这些问题,于是就另起炉灶搞了一个基于 UDP 协议的“QUIC”协议,让HTTP跑在QUIC上而不是TCP上。而这个“HTTP over QUIC”就是HTTP协议的下一个大版本,HTTP/3。它在HTTP/2的基础上又实现了质的飞跃,真正“完美”地解决了“队头阻塞”问题。
QUIC 虽然基于 UDP,但是在原本的基础上新增了很多功能,接下来我们重点介绍几个QUIC新功能。不过HTTP/3目前还处于草案阶段,正式发布前可能会有变动,所以本文尽量不涉及那些不稳定的细节。
3.QUIC新功能
上面我们提到QUIC基于UDP,而UDP是“无连接”的,根本就不需要“握手”和“挥手”,所以就比TCP来得快。此外QUIC也实现了可靠传输,保证数据一定能够抵达目的地。它还引入了类似HTTP/2的“流”和“多路复用”,单个“流"是有序的,可能会因为丢包而阻塞,但其他“流”不会受到影响。具体来说QUIC协议有以下特点:
虽然UDP不提供可靠性的传输,但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。
由于QUIC是基于UDP的,所以QUIC可以实现使用0-RTT或者1-RTT来建立连接,这意味着QUIC可以用最快的速度来发送和接收数据,这样可以大大提升首次打开页面的速度。0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。
目前QUIC使用的是TLS1.3,相较于早期版本TLS1.3有更多的优点,其中最重要的一点是减少了握手所花费的RTT个数。
和TCP不同,QUIC实现了在同一物理连接上可以有多个独立的逻辑数据流(如下图)。实现了数据流的单独传输,就解决了TCP中队头阻塞的问题。
七、总结
参考文章
近在很多博客上都看到有关于WordPress集成百度实时推送的功能,虽然不知道具体效果如何,但是我想增加这个功能应该总不会是坏事吧,所以就给自己的站点添加试试,以便下次更新Three主题的时候集成进去。
具体操作步骤如下:
1、获取token值
我们只需要登录百度站长平台》网页抓取》点击【链接提交】,在右边的页面中的“链接提交”中选择需要添加百度实时推送功能的站点,然后就可以看到这个站点的token值了。
PS:一个百度站长账号有多个站点,这几个站点的token值都是一样的。
2、修改代码,添加百度实时推送功能
把以下代码中的token值(xxxxxxxxxxx)改为我们第一步获取的token值(其他的不用修改),然后把这些代码添加到主题目录下的 functions.php 文件最后一个?>之前即可。
/**
* WordPress发布文章主动推送到百度,加快收录保护原创【WordPress通用方式】
* 文章地址:http://zhangge.net/5041.html
*/
if(!function_exists('Baidu_Submit')){
function Baidu_Submit($post_ID) {
$WEB_TOKEN='xxxxxxxxxxx'; //这里请换成你的网站的百度主动推送的token值
$WEB_DOMAIN=get_option('home');
//已成功推送的文章不再推送
if(get_post_meta($post_ID,'Baidusubmit',true)==1) return;
$url=get_permalink($post_ID);
$api='http://data.zz.baidu.com/urls?site='.$WEB_DOMAIN.'&token='.$WEB_TOKEN;
$request=new WP_Http;
$result=$request->request( $api , array( 'method'=> 'POST', 'body'=> $url , 'headers'=> 'Content-Type: text/plain') );
$result=json_decode($result['body'],true);
//如果推送成功则在文章新增自定义栏目Baidusubmit,值为1
if (array_key_exists('success',$result)) {
add_post_meta($post_ID, 'Baidusubmit', 1, true);
}
}
add_action('publish_post', 'Baidu_Submit', 0);
}
现在我们发布新文章,文章地址就会被主动推送到百度。被成功推送的文章,将自动出现如下自定义栏目:
为避免代码重复推送的尴尬,如果你需要更新文章再次推送数据,那么在保存/更新文章之前,删除或修改这个自定义栏目即可再次被推送。
Ps:虽然,主动推送的各种方法都支持一次推送多条数据,从我个人的经验来看,对于老文章没必要再次推送,频繁推送容易导致百度“翻脸”!
特别说明:
如果按以上步骤正确操作后,在发布新文章时自定义栏目中不会出现我们期望的baidusubmit,说明实时推送给百度不成功,说明所使用的主机的 curl_exec()函数被禁用了。这个时候,我们只需要把以下代码替换掉第二步的代码即可。
/**
* WordPress发布文章主动推送到百度,加快收录保护原创【file_get_contents方式】
* 文章地址:http://zhangge.net/5041.html
*/
if(!function_exists('Baidu_Submit')) {
function Baidu_Submit($post_ID) {
$WEB_TOKEN='xxxxxxxxx'; //这里换成你的网站的百度主动推送的token值
$WEB_DOMAIN=get_option('home');
//已成功推送的文章不再推送
if(get_post_meta($post_ID,'Baidusubmit',true)==1) return;
$url=get_permalink($post_ID);
$api='http://data.zz.baidu.com/urls?site='.$WEB_DOMAIN.'&token='.$WEB_TOKEN;
$data=array (
'http'=> array (
'method'=> 'POST',
'header'=> "Content-Type: text/plain",
"Content-Length: ".strlen($url)."rn",
'content'=> $url
)
);
$data=stream_context_create($data);
$result=file_get_contents($api, false, $data);
$result=json_decode($result,true);
//如果推送成功则在文章新增自定义栏目Baidusubmit,值为1
if (array_key_exists('success',$result)) {
add_post_meta($post_ID, 'Baidusubmit', 1, true);
}
}
add_action('publish_post', 'Baidu_Submit', 0);
}
文中涉及的技术和代码均来自于张戈博主分享的《WordPress发布文章主动推送到百度,加快收录保护原创》。
*请认真填写需求信息,我们会在24小时内与您取得联系。