网页端的消息接收，用什么方式好呢？

页收发消息是一个常见的系统应用场景，通常我们有两种方式来完成消息的发送，一种是通过客户端来拉取消息，一种是服务端推送消息，到底使用哪种方式好一点呢？

具体使用哪种方式，我们需要根据实际的业务场景来分析，没有绝对正确的方式，只有适不适合。所以，我们分析一下网页端的用户一般都存在哪些应用场景：

系统将通知发送给用户——这种场景下，用户对于消息的实时性要求并不高
用户和用户之间发送聊天消息——这种场景下，用户就对实时性的要求很高了，越实时越好

我们抛开纯技术实现不谈，只是从解决方案来谈，由于是使用的是网页端，HTTP协议是通过“请求-响应”的方式传递，网页端和服务端之间是没有消息通道的，那么怎么来实现消息的接收呢？

轮询拉取

轮询拉取可以说是所有消息的实现方案中最简单的一种，实现起来也非常简单。

大致的实现方法如下：

发送方发送消息后，消息先进入队列中暂存（也可以是数据库）
网页端建立一个timer，固定时间（例如：30秒）轮询到队列（或数据库）中拉取消息
无论有没有拉到消息，收到返回的消息后，30秒后再次轮询拉取

这种方式最大的优势就是实现非常简单，而且容易理解，早期的聊天室基本都是这种实现方式，我曾经给朋友做过一个答题的系统，有多个终端，每个终端看到的内容需要有所不同，也是使用的这种实现方式。

当然这种实现方式的缺点也是非常明显：

时效性差：随着timer间隔时间的长短，收到消息的延时时间会被拉长，以30秒为例，消息最大的延时就会达到30秒
效率差：网页端会不停的请求服务器，但是发消息的频率事实上并没有这么高，如果10次轮询才拉到一条消息，那么有效性只有10%，大量的浪费了服务器资源

使用这种方式，时效性和效率是矛盾的，我降低timer的间隔时间，就可以提高时效性，但是会降低效率，例如：间隔时间降低到1秒，这种基本就可以趋近于实时了，但是可能300次轮询才会拉到1条消息，有效性只有0.3%了。

所以，由于这个不可调和的矛盾存在，这种解决方案只能适用于一些同时在线用户少，对实时性要求不高的场景中。

长连接

如果想要同时保证时效性和效率，其实长连接是一个不错的选择，一般我们的PC端聊天软件都是使用的长连接方式来实现。而网页端的长连接实现方式通常有两种：

WebSocket
FlashSocket

FlashSocket就不说了，如果不是网页游戏的话其实很少会用到这个方案来做长连接，它要求用户必须安装了Flash插件。如果是HTML网页端的话，其实更多会选择WebSocket这种方案，WebSocket的优点非常明显，建立一次握手以后，服务端和网页端就可以双向通信了，摆脱了HTTP的Request-Response的限制，消息的及时性和效率都大幅度的提升了。

但是WebSocket也不是那么简单，其中的坑也非常的多，如何单个生产者推送给多个消费者，如何保证不重复推送，断线以后的重连等等。当然更重要的是，不同的浏览器对于WebSocket的支持可能不同，兼容性也是一大问题，所以使用得并不是很多。

那有没有一种更常用的方法来处理消息的接收呢？

HTTP长轮询

想要建立一条HTTP长轮询的通道，我们需要在浏览器和服务器之间建立一条通知连接。

而这条通知连接不同于普通的HTTP连接，它要有一些特殊性：

这个HTTP连接只能用来收取推送的消息
不同于普通的Request-Response HTTP请求，这个HTTP连接不会马上响应，会先被Hold在这里，知道接到通知的消息或者超过了约定的时间（我们都知道，HTTP请求是会有超时的，一般我们都会设置一个请求超时的阈值，如果超过这个阈值，那么请求就会被粗暴的断开，返回一个错误消息，为了保证我们的请求不被粗暴的对待，我们需要在超时之前优雅的返回一个结果）

怎么来Hold住这个请求呢？

场景一：队列里面有消息

发起一个通知连接HTTP请求
发现消息队列里面有消息，于是拿到消息然后立刻返回
收到返回的消息后，立刻再次发起通知连接的请求

场景二：队列里面没有消息

发起一个通知连接HTTP请求
发现消息队列里面没有消息，于是一直等待直到达到时间阈值然后返回
收到返回的消息后，立刻再次发起通知连接的请求

个人认为，长轮询的请求就一直保持对消息队列的数据拉取就行，如果有实时的消息来了，也等到它进入消息队列以后再处理，这样可以防止消息丢失，也可以降低系统的复杂度。

总的来说，网页端的消息接收，用什么方式好呢？拉和推都可以，每种方式有每种方式的优缺点。

如果业务不复杂，实时性不高，建议轮询拉取
最佳方案是推，但是WebSocket和FlashSocket各有局限性，实现起来也麻烦一点
常见方式就是长轮询，需要开辟一条专用的消息通道

融界2024年7月9日消息，天眼查知识产权信息显示，税友软件集团股份有限公司取得一项名为“一种数据交互方法、系统、电子设备及存储介质“，授权公告号CN113010237B，申请日期为2021年3月。

专利摘要显示，本发明公开了一种数据交互方法，包括：HTML程序利用HTML容器提供的服务接口生成本地资源获取请求，并通过HTML容器的容器进程将本地资源获取请求发送至本地服务容器；本地服务容器利用本地服务容器中包含的业务服务对接收到的本地资源获取请求进行处理，得到相应的本地资源数据，并将本地资源数据发送至HTML容器；HTML容器接收本地资源数据，并将本地资源数据发送至HTML程序；本方法中的HTML程序可直接使用HTML容器及本地服务容器进行本地资源获取，可确保HTML程序摆脱HTTP服务的束缚，以使HTML能够更好地在本地程序中进行应用；本发明还提供数据交互系统、电子设备及存储介质，具有上述有益效果。

本文源自金融界

览器解析HTML文件的过程是网页呈现的关键步骤之一。具体介绍如下：

HTML文档的接收和预处理

网络请求处理：当用户输入URL或点击链接时，浏览器发起HTTP请求，服务器响应并返回HTML文件。此过程中，浏览器需要处理DNS查询、建立TCP连接等底层网络通信操作。
预解析优化：为了提高性能，现代浏览器在主线程解析HTML之前会启动一个预解析线程，提前下载HTML中链接的外部CSS和JS文件。这一步骤确保了后续渲染过程的顺畅进行。

解析为DOM树

词法分析和句法分析：浏览器的HTML解析器通过词法分析将HTML文本标记转化为符号序列，然后通过句法分析器按照HTML规范构建出DOM树。每个节点代表一个HTML元素，形成了多层次的树状结构。
生成对象接口：生成的DOM树是页面元素的结构化表示，提供了操作页面元素的接口，如JavaScript可以通过DOM API来动态修改页面内容和结构。

CSS解析与CSSOM树构建

CSS文件加载与解析：浏览器解析HTML文件中的<link>标签引入的外部CSS文件和<style>标签中的内联CSS，生成CSSOM树。CSSOM树反映了CSS样式的层级和继承关系。
CSS属性计算：包括层叠、继承等，确保每个元素对应的样式能够被准确计算。这些计算过程为后续的布局提供必要的样式信息。

JavaScript加载与执行

阻塞式加载：当解析器遇到<script>标签时，它会停止HTML的解析，转而先加载并执行JavaScript代码。这是因为JS可能会修改DOM结构或CSSOM树，从而影响已解析的部分。
异步和延迟加载：为了不影响页面的初步渲染，可以采用async或defer属性来异步加载JS文件，这样可以在后台进行JS的加载和执行，而不阻塞HTML解析。

渲染树的构建

合并DOM树和CSSOM树：有了DOM树和CSSOM树后，浏览器将它们组合成渲染树，这个树只包含显示界面所需的DOM节点及对应的样式信息。
不可见元素的排除：渲染树会忽略例如<head>、<meta>等不可见元素，只关注<body>内的可视化内容。

布局计算（Layout）

元素位置和尺寸确定：浏览器从渲染树根节点开始，递归地计算每个节点的精确位置和尺寸，这个过程也被称为“回流”或“重排”，是后续绘制的基础。
布局过程的优化：现代浏览器会尽量优化布局过程，例如通过流式布局的方式减少重复计算，确保高效地完成布局任务。

绘制（Paint）

像素级绘制：绘制是一个将布局计算后的各元素绘制成像素点的过程。这包括文本、颜色、边框、阴影以及替换元素的绘制。
层次化的绘制：为了高效地更新局部内容，浏览器会将页面分成若干层次（Layer），对每一层分别进行绘制，这样只需更新变化的部分。

因此，我们开发中要注意以下几点：

避免过度使用全局脚本：尽量减少使用全局脚本或者将它们放在文档底部，以减少对HTML解析的阻塞。
合理组织CSS和使用CSS预处理器：合理组织CSS文件的结构和覆盖规则，利用CSS预处理器进行模块化管理。
利用浏览器缓存机制：通过设置合理的缓存策略，减少重复加载相同资源，提升二次访问的体验。
优化图片和多媒体资源：适当压缩图片和优化多媒体资源的加载，减少网络传输时间和渲染负担。

综上所述，浏览器解析HTML文件是一个复杂而高度优化的过程，涉及从网络获取HTML文档到最终将其渲染到屏幕上的多个步骤。开发者需要深入理解这些步骤，以优化网页性能和用户体验。通过合理组织HTML结构、优化资源加载顺序、减少不必要的DOM操作和合理安排CSS和JavaScript的加载与执行，可以显著提升页面加载速度和运行效率。

在线咨询

上一篇：俄罗斯的黑客，摧毁了多少国家
下一篇：前端开发就业面试题

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。