前端实现消息推送、即时通信

信息推送

服务端主动向客户端推送消息，使客户端能够即时接收到信息。

场景

• 页面接收到点赞，消息提醒
• 聊天功能
• 弹幕功能
• 实时更新数据功能

实现即时通讯方式

短轮询

浏览器（客户端）每隔一段时间向服务器发送http请求，服务器端在收到请求后，不论是否有数据更新，都直接进行响应。

本质：客户端通过不停的请求，使客户端能模拟能实时能接收客户端的数据变化

优点：简单易懂，操作方便

缺点：如果每个客户端不停的向服务器发送请求，使用人数增加，请求数量翻倍，造成服务器压力大，反应迟缓。不适合于大型项目或者使用人数太多。

var xhr = new XMLHttpRequest();
setInterval(function(){
    xhr.open('GET','/user');
    xhr.onreadystatechange = function(){

    };
    xhr.send();
},1000)

长轮询(comet)

服务端接收客户端的请求之后不会立即反应，先是将请求挂起，当数据发生改变后，返回响应。当一定时间内数据未变化，计时结束返回响应并关闭连接。客户端处理响应后，向服务器再次发送新一轮长轮询。

优点：比短轮询减少了http请求

缺点：挂起也会浪费资源

function ajax(){
    var xhr = new XMLHttpRequest();
    xhr.open('GET','/user');
    xhr.onreadystatechange = function(){
        ajax();
    };
    xhr.send();
}

短轮询与长轮询都

• 基于HTTP的，两者本身存在着缺陷；轮询需要更快的处理速度，长轮询要求处理并发的能力
• 服务器不会主动推送信息，而是在客户端发送ajax请求后进行返回的响应

长连接(SSE)

SSE基于 HTTP 协议中的持久连接，作为 HTML5 出现的新功能，不用客户端向服务器发请求，而是当服务器数据发生改变，直接对客户端响应

WebSocket

WebSocket是Html5定义的一个新协议，可以实现服务器-客户端全双工通信；需要服务器和客户端建立连接，当连接开始，双方处于平等状态互发信息，不存在请求和相应的关系。

sse	websocket
http 协议	独立的 websocket 协议
轻量，使用简单	相对复杂
默认支持断线重连	需要自己实现断线重连
文本传输	二进制传输
支持自定义发送的消息类型	-
单通道，只能服务端向客户端发消息	双通道，相互发信息

see 前后端原生实现 Web消息推送之SSE_魅Lemon的博客-CSDN博客

see vue3 vue3使用sse_sse vue_OneRepublicSu的博客-CSDN博客

see vue2 在vue2中使用SSE（服务器发送事件）_sse vue_如晴天似雨天~的博客-CSDN博客

websocket实现 js实现WebSocket 连接_js websocket_给你六圆钱的博客-CSDN博客

http

程序员入门必备教程---HTTP协议详解（真的很经典）_哔哩哔哩_bilibili

TCP/IP 协议是传输层的一个面向连接的安全可靠的一个传输协议

三次握手的机制是为了保证能建立一个安全可靠的连接

• 第一次握手是由客户端发起，客户端会向服务端发送一个报文，在报文里面：SYN标志位置为1，表示发起新的连接。
• 当服务端收到这个报文之后就知道客户端要和我建立一个新的连接，于是服务端就向客户端发送一个确认消息包，在这个消息包里面：ack标志位置为1，表示确认客户端发起的第一次连接请求。
• 以上两次握手之后，对于客户端而言：已经明确了我既能给服务端成功发消息，也能成功收到服务端的响应。但是对于服务端而言：两次握手是不够的，因为到目前为止，服务端只知道一件事，客户端发给我的消息我能收到，但是我响应给客户端的消息，客户端能不能收到我是不知道的。所以，还需要进行第三次握手，第三次握手就是当客户端收到服务端发送的确认响应报文之后，还要继续去给服务端进行回应，也是一个ack标志位置1的确认消息。通过以上三次连接，不管是客户端还是服务端，都知道我既能给对方发送消息，也能收到对方的响应。那么，这个连接就被安全的建了。

四次握手

• 机制也是由客户端去发起，客户端会发送一个报文，在报文里面FIN位标志位置一，当服务端收到这个报文之后，我就知道了客户端想要和我断开连接，但是此时服务端不一定能做好准备，因为当客户端发起断开连接的这个消息的时候，对于服务端而言，他和还有可能有未发送完的消息，他还要继续发送，所以呢，此时对于服务端而言，我只能进行一个消息确认，就是我先告诉服务端，我知道你要给我断开连接了，但是我这里边还可能没有做好准备，你需要等我一下，等会儿我会告诉你，于是呢，发完这个消息确认包之后，可能稍过片刻它就会继续发送一个断开连接的一个报文啊，也是一个FIN位置1的报文也是由服务端发给客户端的啊，这个报文表示服务端已经做好了断开连接的准备，那么当这个报文发给客户端的时候，客户端同样要给服务端继续发送一个消息确认的报文一共有四次，那么，通过这四次的相互沟通和连接，我就知道了，不管是服务端还是客户端都已经做好了断开连接的

 输入地址点击回车键，浏览器干了什么

• 输入地址并确认后，浏览器对域名进行访问，浏览器对域名进行解析，如果浏览器有域名对应的DNS相关信息的缓存，有的话可以拿到服务端的IP地址，如果没有的话，会去本地的host文件查看是否进行了配置，如果host文件没有配置相关的信息，那么就会发起DNS的请求用来获取对应的服务器的IP地址。应用端会构造DNS的请求报文，应用层会调用传输层的UDP的相关协议进行数据传输，会在DNS的基础上加上UDP的请求头然后传输信息至网络层，网络层会在UDP的请求报文基础上加上IP的请求头然后到数据链路层，数据链路层会实现二层寻址，会加上自己的mac信息和通过网络层的ARP协议里拿到的下一步基地的mac信息一起通过物理层一起传输出去，通常传到路由器，然后路由器这个三层设备最终会通过运营商的路线传输到下一个路由器地址，达到服务器后信息通过相同步骤进行层层解析HTTP的请求报文，然后构造HTTP响应报文沿着相同的步骤传输至客户端。