WebSocket改造过程中遇到的问题

  最近公司有一个数据大屏的项目，即在一个大屏幕上实时显示数据给领导和公司员工看。以前数据变动是通过前端不停的轮询，即每两秒向后台调取数据。这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而HTTP请求可能包含较长的头部，其中真正有效的数据可能只是很小的一部分，显然这样会浪费很多的带宽等资源。而且需要的数据有十多个接口，每次调用会给后端造成一些负担。
  在这种情况下，HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯。
下面简单介绍一些websocket:

WebSocket协议支持（在受控环境中运行不受信任的代码的）客户端与（选择加入该代码的通信的）
远程主机之间进行全双工通信。用于此的安全模型是Web浏览器常用的基于原始的安全模式。
 协议包括一个开放的握手以及随后的TCP层上的消息帧。 该技术的目标是为基于浏览器的、
需要和服务器进行双向通信的
（服务器不能依赖于打开多个HTTP连接（例如，使用XMLHttpRequest或<iframe>和长轮询））
应用程序提供一种通信机制。

简单的说 支持服务端主动推送消息给客户端。
这样就能在后台写一个定时任务，每过5秒检查一下数据是否发生变化，如果变化则推送消息给前端。
下面直接讲如何配置：
在spring配置文件中加入:

xmlns:p="http://www.springframework.org/schema/p"
xmlns:websocket="http://www.springframework.org/schema/websocket"
xsi:schemaLocation="http://www.springframework.org/schema/websocket
                http://www.springframework.org/schema/websocket/spring-websocket.xsd"

<mvc:annotation-driven />

在pom中导入jar包

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-websocket</artifactId>
    <version>4.0.1.RELEASE</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-messaging</artifactId>
    <version>4.0.1.RELEASE</version>
</dependency>

这里的provided是表明该包只在编译和测试的时候用，因为tomcat8以后都支持websocket，在查阅网上资料的时候他们都推荐加这一行，防止冲突。

接下来要用到 @ServerEndpoint("/websocket") 这个注解写一个websocket使用类，具体可以参考百度。
然后前端使用

 

  if ('WebSocket' in window) {
        websocket = new WebSocket("ws://localhost:8080/websocket");
    }
    else {
        alert('当前浏览器 Not support websocket')
    }

这个方法来建立websocket连接。其中地址对应@ServerEndpoint("/websocket") 中的地址。

在完成这个连接和功能设计之后，遇到了一个问题。
我发现没过一段时间，后台会报这样一个错，然后导致断开连接。

 

在仔细检查了功能的io操作之后，觉得不是代码的问题，于是去百度寻找答案。

在参考了大量的文章之后，并通过自己的测试，找到了问题的所在：
当项目部署到服务器上之后，服务器上用了nginx这个HTTP和反向代理服务器。而nginx里有一个参数nginx proxy_read_timeout，如果不设置默认为60s。就是如果60s没有数据传输他会自动断开连接，导致后台在读数据的时候读到结尾了仍然尝试去读，这样就报了一个EOFException。

找到问题所在之后，我马上想到了3个解决办法：
1.前端写一个定时任务，每过20s或30s刷新一次。这样保证连接的时长不会超过60s，不会被断开。
2.前端检测是否断开连接，（通过定时websocket向服务端发消息，看看有没有回应来检测），若断开则重连，如果没有断开，这个消息也会刷新nginx proxy_read_timeout这个参数。想到这里，马上想到第三个方法。
3.与其让前端发消息来检测是否断开连接或者刷新超时时间，不如我后台定时发一个消息，来保持这个连接。经过看了网上的一些资料，我知道这个操作类似心跳机制。而且有更好的解决办法。比如在前端的onclose里reconnect方法重新建立连接。

最终解决方案：
1.我后台加定时发一个心跳消息。
2.前端在onclose里添加reconnect重新建立连接。

链接：https://www.jianshu.com/p/de00cd933ded（原创作者）