WebRTC源码研究（22）socket.io 实现简单聊天_webrtc socket.io websocket-CSDN博客

本文链接：https://blog.csdn.net/kyl282889543/article/details/106816384

文章目录

WebRTC源码研究（22）socket.io 实现简单聊天
1. Socket.io 简介
2. Socket.io 发送消息
- 2.1 Socket.io 发送消息类型

WebRTC源码研究（22）socket.io 实现简单聊天

1. Socket.io 简介

Socket.IO支持及时、双向与基于事件的交流。它可以在每个平台、每个浏览器和每个设备上工作，可靠性和速度同样稳定。

Socket.IO是一个WebSocket库，包括了客户端的js和服务器端的nodejs，它的目标是构建可以在不同浏览器和移动设备上使用的实时应用。它会自动根据浏览器从WebSocket、AJAX长轮询、Iframe流等等各种方式中选择最佳的方式来实现网络实时应用，非常方便和人性化，而且支持的浏览器最低达IE5.5

socket.io特点:

实时分析：将数据推送到客户端，这些客户端会被表示为实时计数器，图表或日志客户。
实时通信和聊天：只需几行代码便可写成一个Socket.IO的”Hello,World”聊天应用。
二进制流传输：从1.0版本开始，Socket.IO支持任何形式的二进制文件传输，例如：图片，视频，音频等。
文档合并：允许多个用户同时编辑一个文档，并且能够看到每个用户做出的修改。

socket.io版本:

Socket.IO目前已经更新到v2.0.3，最新版本下载请到官方下载：点击下载

socket.io相关教程

《ajax教程》
《Node.js教程》
《Java教程》
《JavaScript》
socket.io官方文档中文版翻译自官网：https://socket.io/docs/

Socket.IO 实现了实时双向的基于事件的通讯机制。旨在让各种浏览器与移动设备上实现实时app功能，模糊化各种传输机制。

Socket.IO 是跨平台，多种连接方式自动切换，做即时通讯方面的开发很方便，而且能和expressjs提供的传统请求方式很好的结合，即可以在同一个域名，同一个端口提供两种连接方式：request/response, websocket(flashsocket,ajax…).

Socket.IO 实例代码：

var io = require('socket.io')(80);
var cfg = require('./config.json');
var tw = require('node-tweet-stream')(cfg);
tw.track('socket.io');
tw.track('javascript');
tw.on('tweet', function(tweet){
   
  io.emit('tweet', tweet);
});

1.1 Socket.IO 和Websocket区别

一、性bai质不同

1.Websocket:Websocket是一种支持客户端和服务器之du间双向实时通信zhi的技术。dao

2.套接字。IO:套接字。IO是将WebSocket、AJAX等通信方式封装成统一的通信接口。

二、兼容性是不同的

1.websocket:在使用websocket时，虽然主流浏览器已经被支持，但是可能存在不兼容性。

2,套接字。io:使用插座的时候。io中，不担心兼容性问题，底层会自动选择最佳的通信方式。

三、用途不同

1.websocket：websocket适合用于client和基于node搭建的服务端使用。

2.Socket.IO ：Socket.IO 适合进行服务端和客户端双向数据通信。

1.2 WebSocket 协议

WebSocket是HTML5新增的一种通信协议，其特点是服务端可以主动向客户端推送信息，客户端也可以主动向服务端发送信息，是真正的双向平等对话，属于服务器推送技术的一种。

在WebSocket API中，浏览器和服务器只需要做一个握手的动作，然后浏览器和服务端之间就形成了一条快速通道，两者之间就直接可以数据相互传送，带来的好处是:

相互沟通的Header很小，大概只有2Bytes。
服务器不再被动的接收到浏览器的请求之后才返回数据，而是在有新数据时就主动推送给浏览器。

为了建立一个WebSocket连接，浏览器首先要向服务器发起一个HTTP请求，这个请求和通常的HTTP请求不同，包含了一些附加头信息，其中附加头信息Upgrade: WebSocket表明这是一个申请协议升级的HTTP请求。服务端解析这些头信息，然后产生应答信息返回给客户端，客户端和服务端的WebSocket连接就建立起来了。双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续直到客户端或者服务端的某一方主动关闭连接。

那么为什么要使用WebSocket呢？

Browser已经支持HTTP协议，为什么还要开发一种新的WebSocket协议呢？

我们知道HTTP协议是一种单向的网络协议，在建立连接后，仅允许Browser/UserAgent向WebServer发出请求资源后，WebServer才能返回对应的数据，而WebServer不能主动的推送数据给Browser/UserAgent。

最初这么设计HTTP协议的原因是，假设WebServer能主动的推送数据给Browser/UserAgent，那么Browser/UserAgent就太容易受到攻击了，一些广告商也会主动把广告在不经意间强行的传输给客户端，这不能不说是一个灾难。那么单向的HTTP协议给Web应用开发带哪些问题呢？

现在假设我们要开发一个基于Web的应用去获取当前WebServer的实时数据。例如股票实时行情、火车票剩余票数等。这就需要Browser/UserAgent与WebServer之间反复进行HTTP通信，Browser/UserAgent不断的发送请求去获取当前的实时数据。

推送实现的常见方式:

Polling
Polling轮询是通过Browser/UserAgent定时向WebServer发送HTTP请求，WebServer收到请求后把最新的数据发回给Browser/UserAgent，Browser/UserAgent得到数据后将其显示，然后再定期重复此过程。
虽然这样可以满足需求，但仍存在问题，例如某段时间内WebServer没有更新的数据，但Browser/UserAgent仍然会定时发送请求过来询问，WebServer可以把以前的老数据再传送过去，Browser/UserAgent把这些没有变化的数据再显示出来。这样既浪费网络带宽，有浪费CPU利用率。
如果说把Browser/UserAgent发送请求的周期调大一些，就可以缓解这个问题，但如果WebServer的数据更新很快时，这样又不能保证Web应用获取数据的实时性。
LongPolling
LongPolling是对Polling的一种改进。
Browser/UserAgent发送HTTP请求到WebServer，此时WebServer可以做2件事情：
（1）如果WebServer有新的数据需要传送，就立即把数据发回给Browser/UserAgent，Browser/UserAgent收到数据后，立即再发送HTTP请求给WebServer。
（2）如果WebServer没有新数据需要传送，这里与Polling的方式不同的是，WebServer不是立即发送回应给Browser/UserAgent，而是将这个请求保持住，等待有新的数据来到，再去响应这个请求。当然，如果WebServer的数据长期没有更新，一段时间后，这个HTTP请求就会超时，Browser/UserAgent收到超时信息后，在立即发送一个新的HTTP请求给服务器，然后依次循环这个过程。
LongPolling的方式虽然在某种程度上减少了网络带宽和CPU利用率等问题，但仍存在缺陷。

例如WebServer的数据更新速度较快，WebServer在传送一个数据包给Browser/UserAgent后必须等待Browser的下一个HTTP请求到来，才能传递第二个更新的数据包给Browser。这样的话，Browser显示实时数据最快的时间为2 xRTT（往返时间）。另外在网络拥堵的情况下，这个应该是不能让用户接受的。另外，由于HTTP数据包的头部数据量很大（通常有400多个字节），但真正被服务器需要的数据却很少（有时只有10个字节左右），这样的数据包在网络上周期性传输，难免对网络带宽是一种浪费。

综上所述，要是在Browser有一种新的网路一些，能支持客户端和服务端的双向通信，而且协议的头部又不那么庞大就very nice了。WebSocket正是肩负这样的使命登上了Web的舞台。