Websocket 心跳机制：全面指南 (websocket和http区别)

Websocket是一种双向通信协议，它允许服务器和客户端进行实时通信。由于网络连接可能不稳定，因此需要一种机制来检测连接是否正常，并保持连接。这就是心跳机制的用武之地。

WebSocket 和 HTTP 的区别

在深入探讨 WebSocket 心跳机制之前，让我们首先了解一下 WebSocket 与 HTTP 之间的主要区别：

WebSocket 心跳机制

WebSocket 心跳机制是一种定时检查连接是否正常的方法。通常，客户端会定期向服务器发送心跳请求（通常是 ping 帧），而服务器则会回复心跳响应（通常是 pong 帧）。如果在一定时间内没有收到心跳响应，则认为连接已断开，客户端将尝试重新连接。

心跳间隔

心跳间隔是客户端发送心跳请求的时间间隔。建议将心跳间隔设置为足够频繁以检测网络中断，但又不要频繁到给服务器造成不必要的开销。常见的间隔时间范围为 5-30 秒。

超时时间

超时时间是服务器在收到心跳响应前等待的时间。如果超时时间内没有收到响应，则认为连接已断开。超时时间应比心跳间隔稍微长一些，以留出一些延迟空间。

面试笔记-Socket MQTT Websocket

是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。 协议是应用层协议不依赖长连接，适合弱网络。 通过topic缓存信息。 符合物联网设备的使用场景。 因为通过topic缓存信息，因此可以实现通过topic与多个端的一对多连接，而不是设备与设备的多对多连接，节省了能耗及带宽。 MQTT的心跳，及非信息的报文，较Websocket更少，更节省带宽及能耗。 更适用于物理网的多种网络协议。 和Http一样在应用层,提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。 本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。 由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。 Socket 连接,至少需要一对套接字，分为 clientSocket，serverSocket 连接分为3个步骤: (1) 服务器监听:服务器并不定位具体客户端的套接字，而是时刻处于监听状态； (2) 客户端请求:客户端的套接字要描述它要连接的服务器的套接字，提供地址和端口号，然后向服务器套接字提出连接请求； (3) 连接确认:当服务器套接字收到客户端套接字发来的请求后，就响应客户端套接字的请求,并建立一个新的线程,把服务器端的套接字的描述发给客户端。 一旦客户端确认了此描述，就正式建立连接。 而服务器套接字继续处于监听状态，继续接收其他客户端套接字的连接请求. Socket为长连接：通常情况下Socket 连接就是 TCP 连接，因此 Socket 连接一旦建立,通讯双方开始互发数据内容，直到双方断开连接。 在实际应用中，由于网络节点过多，在传输过程中，会被节点断开连接，因此要通过轮询高速网络，该节点处于活跃状态。 很多情况下，都是需要服务器端向客户端主动推送数据，保持客户端与服务端的实时同步。 若双方是 Socket 连接，可以由服务器直接向客户端发送数据。 若双方是 HTTP 连接，则服务器需要等客户端发送请求后，才能将数据回传给客户端。 因此，客户端定时向服务器端发送请求，不仅可以保持在线，同时也询问服务器是否有新数据，如果有就将数据传给客户端。 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。 这些特点使它适用于受限环境。 例如： ①网络代价昂贵，带宽低、不可靠。 ②在嵌入设备中运行，处理器和内存资源有限。 该协议的特点有： ①使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。 ②对负载内容屏蔽的消息传输。 ③使用 TCP/IP 提供网络连接。 ④有三种消息发布服务质量： ⑤至多一次，消息发布完全依赖底层 TCP/IP 网络。 会发生消息丢失或重复。 这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。 ⑥至少一次，确保消息到达，但消息重复可能会发生。 ⑦只有一次，确保消息到达一次。 这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。 ⑧小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。 ⑨使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。 实现MQTT协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。 其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。 有三种消息发布服务质量： “至多一次”，消息发布完全依赖底层TCP/IP网络。 会发生消息丢失或重复。 这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。 这一种方式主要普通APP的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。 qos=0 “至少一次”，确保消息到达，但消息重复可能会发生。 qos=1 “只有一次”，确保消息到达一次。 在一些要求比较严格的计费系统中，可以使用此级别。 在计费系统中，消息重复或丢失会导致不正确的结果。 这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送，确保用户收到且只会收到一次。 qos=2 Topic，可以理解为消息的类型，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（payload）； payload，可以理解为消息的内容，是指订阅者具体要使用的内容。 在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、可变头（Variable header）、消息体（payload）三部分构成。 MQTT数据包结构如下： 固定头（Fixed header）。 存在于所有MQTT数据包中，表示数据包类型及数据包的分组类标识。 可变头（Variable header）。 存在于部分MQTT数据包中，数据包类型决定了可变头是否存在及其具体内容。 消息体（Payload）。 存在于部分MQTT数据包中，表示客户端收到的具体内容。 WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。 本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。 由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。 由此可知两者的应用场景不一样：MQTT是为了物联网场景设计的基于TCP的Pub/Sub协议，有许多为物联网优化的特性，比如适应不同网络的QoS、层级主题、遗言等等。 WebSocket是为了HTML5应用方便与服务器双向通讯而设计的协议，HTTP握手然后转TCP协议，用于取代之前的Server Push、Comet、长轮询等老旧实现。 两者之所有有交集，是因为一个应用场景：如何通过HTML5应用来作为MQTT的客户端，以便接受设备消息或者向设备发送信息，那么MQTT over WebSocket自然成了最合理的途径了。

WebSocket心跳重连讲解

最近在开发小程序用到了WebSocket，小程序提供了相应的原生API，与H5的API使用方式上有一些区别，所以流行的H5的一些成熟的类库使用起来有些困难，而原生API又存在一些缺陷，所以就自己实现了一套心跳重连机制。 惯例，先简单介绍一下Websocket。 HTTP 协议是一种无状态的、无连接的、单向的应用层协议。 它采用了请求/响应模型。 通信请求只能由客户端发起，服务端对请求做出应答处理。 所以当我们想服务器主动给客户端发送消息，HTTP是做不到的，我们只能使用轮询或者长轮询来实现类似的功能，这样的方式效率低并且浪费资源，为了解决这样的问题，WebSocket诞生了。 把你给懒得！自己官网看去! 在使用原生WebSocket的时候，我们经常会感觉不太稳定，服务端发送的消息有时候客户端接收不到，或者是客户端发送的消息服务端接收不到，虽然WebSocket也提供了onError和onClose的方法，但是经常会有各种未知情况导致断开连接而并不触发Error或Close事件。 这样就导致实际连接已经断开了，而客户端和服务端却不知道，还在傻傻的等着消息来。 所以我们要解决的问题就很清晰了： 保证连接状态，连接断开时让客户端与服务端都能知道，进而重连。 页面载入后,我们连接socket先 然后调用initEventHandle来绑定各种各样的事件 这个先放在这我们一会往里填东西 我们设置一个锁和最大的重连次数，避免出现无限重连的情况，为了不给服务器太大的压力我这里设置的是5秒重试一次，最多请求12次。 改造一下initEventHandle这样我们就可以实现一般的触发Error的断线重连。 先撸为敬 心跳对象内timeout为每10秒发一次心跳,timeoutObj、serverTimeoutObj是清除定时器用的对象，reset方法重置定时器，start发送心跳。 继续改造我们的initEventHandle

由WebRTC谈起

原生支持： iOS13开始，使用URLSessionWebSocketTask类可实现像发送HTTP请求一样的WebSocket功能。 如果要对Web套接字（包括客户端和服务器支持）进行较低级别的控制，请查看Network框架：。 一、Socket 是对TCP/IP 协议的封装，本质并不是一个协议，是应用层与 TCP/IP 协议族通信的中间软件抽象层（类似于对底层的封装），它是一组接口，让你在使用的时候更方便操作。 二、WebSocket协议 是HTML5下一种新的协议，也是基于TCP的一种网络协议，它实现了 浏览器/客户端 与 服务器 全双工(full-duplex)通信——连接成功以后允许服务器或客户端的任何一方主动发送信息给对方。 WebSocket协议由两部分组成： 握手 和 数据传输 。 Websocket是一个持久化的协议，只需要一次成功的HTTP握手，服务端会一直保留握手成功时的信息，直到客户端或服务端关闭请求。 创建了WebSocket后，会有一个HTTP请求发送到服务器以发起连接。 取得服务器响应后，建立的连接使用HTTP升级，从 HTTP协议 交换为 WebSocket协议 。 WebSocket使用了自定义的协议，未加密的连接不再是 http:// ，而是 ws:// ，默认端口为 80 ；加密的连接也不是 https:// ，而是 wss:// ，默认端口为 443 。 即，使用标准的HTTP服务器无法实现WebSocket，只有支持WebSocket协议的服务器才能正常工作。 一旦WebSocket连接建立后，后续数据都以 帧序列 的形式传输。 WebSocket协议的特点包括：（1）建立在 TCP 协议之上。 （2）与 HTTP 协议有着良好的兼容性。 握手阶段采用 HTTP 协议，默认端口也是80和443，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。 （3）数据格式比较轻量，性能开销小，通信高效。 如何体现通信高效？WebSocket通信格式没有HTTP协议那么多的固定报头，且不用重复建立连接。 （4）可以发送文本，也可以发送二进制数据。 （5）没有同源限制，客户端可以与任意服务器通信。 （什么是同源限制？协议相同，域名相同，端口相同。 目的是为了保证用户信息的安全，防止恶意的网站窃取数据。 ）（6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。 （7）WebSocket通信协议于2011年被IETF定为标准RFC 6455，WebSocket API被W3C定为标准。 WebSocket如何实现长链接 ？创建了WebSocket后，会有一个HTTP请求发送到服务器以发起连接。 取得服务器响应后，建立的连接使用HTTP升级，从HTTP协议交换为WebSocket协议。 只需要一次成功的HTTP握手，服务端会一直保留握手成功时的信息，直到客户端或服务端关闭请求。 WebSocket之所以能持久连接原因是它运行在TCP协议上，TCP协议自身是长连接协议，所以WebSocket当然可以长连接啦。 WebSocket如何管理连接 ？RFC6455-5.5意见稿指明：WebSocket协议定义了Control Frame 控制帧。 WebSocket的控制帧有： Close 、 Ping 、 Pong 。 Close帧 ：发起关闭请求； Ping帧 ：通信发起方确认链路是否畅通的报文； Pong帧 ：通信接收方回应链路是否畅通的报文。 WebSocket在建立连接之后，通信的基本数据帧格式如下图（来源RFC6455-5.2）没有Http协议那么多固定的报头，且不用重复建立连接，所以通信效率高：WebSocket连接的生命周期： CONNECTING ：使用Http发起请求，RFC6455-4（）规定了Client和Server的报文格式。 Server在响应时使用Http状态码是101（切换协议）。 在握手时，WebSocket连接处于CONNECTING状态。 OPEN ：握手成功之后，进入OPEN状态。 CLOSING ：如果一方发起了CLOSE帧，那么便标志着WebSocket连接进入了CLOSING状态； CLOSED ：当TCP连接关闭之后，那么WebSocet连接便进入了CLOSED状态。 三、WebRTC 名称源自 网页实时通信 （Web Real-Time Communication）的缩写，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术，由Google、Mozilla和Opera等支持的、免费的开放式项目。 通过简单的API为浏览器和移动应用程序提供跨平台的 音视频实时通信 （RTC：Real-Time Communications）功能。 WebRTC使得开发者在浏览器无需安装任何插件就可以实现音视频通信。 WebRTC提供了跨平台的音视频核心技术，包括音视频的采集、编解码、网络传输、显示等功能，支持的平台：Windows、Linux、Mac、Android及iOS。 RTCPeerConnection是用于进行WebRTC调用以流式传输视频和音频以及交换数据的API，WebRTC使用RTCPeerConnection(对等连接)在浏览器之间传递 流数据 ，但也需要一种协调通信和发送控制消息的机制，这一过程称为 信令 。 信令处理过程需要客户端之间来回传递消息，这个过程在WebRTC里面是没有实现的，需要自己创建。 即WebRTC未指定信令方法和协议，需要开发者确保使用安全协议。 所有WebRTC组件都必须进行加密，即 WebRTC是安全的 （如何保证安全？）。 WebRTC这种技术可以让开发者的精力集中在用户体验上而不是媒体流本身，因为API就会处理好媒体引擎的相关工作。 WebRTC 1.0 的重点是提供给开发者更多对媒体、数据通道的控制。 而根据此前的提案（见后面的提案连接）显示，下一版本的 WebRTC 将有可能使数据处理脱离主线程。 使用 RTCDataChannels 传输数据，相比使用 WebSocket 会有更好的拥塞控制。 （该段内容笔者未确认）参考连接：提案连接：如何保证安全 ：当连通性检测完成后，WebRTC会开启 DTLS （Datagram TLS）握手，用于协商出SRTP中加密RTP包的 对称秘钥 。 该过程称为DTLS-SRTP，保证了数据传输的安全性。 参考：RTP/RTCP 和 SRTP/SRTCP协议是什么？参考：基本概念：SDP ： 即会话描述协议（Session Description Protocol ），主要保存当前会话的媒体和传输信息，其中媒体信息包括 媒体类型 、 传输协议 、 媒体格式 等，传输信息包括媒体的远程 地址信息 、 带宽 等；它由多行KV格式的文本信息组成，具体可参考这里（）。 WebRTC通过 信令 建立一个SDP握手的过程，只有通过SDP握手，双方才知道对方的信息，这是建立p2p通道的基础。 Offer ： 通信的发起方对自己的sdp描述 Answer ： 通信的接收方对自己的sdp描述 信令 ：协商通信过程，传递基本的数据信息，其中包括SDP描述信息、会话控制信息（节点加入、退出及各类的业务控制信息等）、网络信息、错误信息等。 是指控制建立连接和断开连接的状态的数据。 在建立连接之前，信令必须发生在 带外 （通过服务器），但一旦建立连接，就可以通过已经建立的通道发送更新信令（如挂断）。 （这里要了解一下什么叫“带外（OOB：Out-Of-Band）”，网络百科：） OOB概述 ：传输层协议使用 带外数据 （out-of-band，OOB）来发送一些重要的数据，如果通信一方有重要的数据需要通知对方时，协议能够将这些数据快速地发送到对方。 为了发送这些数据，协议一般不使用与 普通数据 相同的通道，而是使用另外的通道。 linux系统的套接字机制支持低层协议发送和接受带外数据。 但是TCP协议没有真正意义上的带外数据。 为了发送重要协议，TCP提供了一种称为 紧急模式 （urgent mode）的机制。 TCP协议在数据段中设置 URG 位，表示进入紧急模式。 接收方可以对紧急模式采取特殊的处理。 很容易看出来，这种方式数据不容易被阻塞，并且可以通过在我们的服务器端程序里面捕捉 SIGURG 信号来及时接受数据。 信令通道 ：与服务端建立连接和断开连接的通道，对于WebRTC而言就是信令通道。 STUN 服务器：是用来取外网地址的。 TURN 服务器：是在P2P失败时进行转发的，中继转发。 STUN 和 TURN 服务器的作用主要处理打洞与转发，配合完成 ICE协议 。 ICE ：Interactive Connectivity Establishment，交互式连接建立。 WebRTC通信 基于WebRTC的点对点音视频通信流程如下：1）客户端A初始化本地音视频设备，创建一个用于Offer的SDP对象，该对象中保存当前音视频的相关信息；2）客户端A通过信令服务器将SDP信息发送给客户端B；3）客户端B接收到A的SDP信息后保存，初始化本地音视频设备并创建用于Answer的SDP对象；4）客户端B通过信令服务器将SDP信息发送给客户端A；5）客户端A、B通过交换SDP等信息，建立P2P通道进行音视频传输；示意图如下图所示：WebRTC ICE（交互式连接建立）(ICE：Interactive Connectivity Establishment)以下是呼叫信令期间发生的消息交换的高级过程，即： WebRTC 信令交互流程图 ： ************************************************开始************************************************##关键词 --[SOMETHING]-->：表示从主叫方发送给被叫方的“SOMETHING”类型的消息。 另一解释是： 主叫方所要执行操作 。 <--[SOMETHING]--：表示从被叫方发送给主叫方的“SOMETHING”类型的消息。 另一解释是： 被叫方所要执行的操作 。 SS (Signal Service)：通过服务器发送的信息（通过BCM 服务器发送的信息） DC (Data Channel)：通过WebRTC 数据通道 发送的消息 ### Message Exchange / State Flow Overview （消息交换/状态流概述） | Caller（主叫方） | Callee（被叫方）|+----------------------------+-------------------------+开始拨出电话：`handleOutgoingCall`...--[]-->…并开始生成iceCandidate候选，先保存在本地。 iceCandidate里面包含了SDP、公网地址、用来标识当前ice中流媒体的id(sdpMid)，这个公网地址是由STUN、TURN Server发过来的。 当生成iceCandidate候选后，将会调用方法`handleLocalAddedIceCandidate` ，并把这些iceCandidate保存起来。 被叫方收到来电，通过 `handleReceivedOffer` 发送呼叫应答<--[]--1. 开始生成iceCandidate候选。 2. 立即通过`handleLocalAddedIceCandidate` 将它们发送给主叫方。 <--[]-- (多次发送)主叫方收到应答后调用方法: `handleReceivedAnswer`，接着发送所有前面保存的iceCandidate候选 (在此之后生成的iceCandidate候选会立即发送)--[]-->(多次发送)完成交换iceCandidate候选后…（此时表示双方身份已确认，接下来会通过P2P通道建立音视频会话，这里会涉及NAT技术，有可能失失败。 如果失败，主叫方会一直显示呼叫中，被叫方不会显示任何界面）双方都调用方法: `handleIceConnected`显示远程铃声用户界面1.连接到提供的数据通道2.显示来电界面3.如果被叫人接听电话4.发送连接消息<--[]--接收到的连接消息后显示呼叫已连接。 主叫方挂断（被叫方同样可以挂断）调用方法：--[]-->--[]--> ************************************************结束************************************************ 上面的消息交换可以整理为如下的简化版的WebRTC建立连接过程： 1）主叫方通过 createOffer 生成 SDP 描述2）主叫方通过 setLocalDescription，设置本地的描述信息3）主叫方将 offer SDP 发送给被叫方4）被叫方通过 setRemoteDescription，设置远端的描述信息5）被叫方通过 createAnswer 创建出自己的 SDP 描述6）被叫方通过 setLocalDescription，设置本地的描述信息7）被叫方将 anwser SDP 发送给主叫方8）主叫方通过 setRemoteDescription，设置远端的描述信息。 只有通过 SDP握手 ，双方才知道对方的信息，这是建立p2p通道的基础。 通过SDP握手后，客户端之间就会建立起一个点对点的直接通讯通道。 但是由于我们所处的网络环境错综复杂，用户可能处在私有内网内，使用p2p传输时，将会遇到 NAT (网络地址转换)以及防火墙等阻碍。 这个时候我们就需要在SDP握手时，通过STUN/TURN/ICE相关 NAT穿透技术 (也有称为 打洞 或 穿墙 技术)来保障p2p链接的建立。 WebRTC的视频部分 ，包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。 视频采集支持多种媒体类型，比如I420、YUY2、RGB、UYUY等，并可以进行帧大小和帧率控制。 WebRTC采用I420/VP8编解码技术。 VP8是Google收购ON2后的开源实现，并且也用在WebM项目中。 VP8能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。 视频加密是WebRTC的video_engine一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在Web上视频数据的泄漏。 视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。 视频加密的数据源可能是原始的数据流，也可能是编码后的数据流。 估计是编码后的数据流，这样加密代价会小一些，需要进一步研究。 WebRTC的音频部分 ，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。 WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。 WebRTC还提供NetEQ功能---抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。 另外一个核心功能是基于语音会议的混音处理。 声音处理针对音频数据进行处理，包括回声消除(AEC)、AECM(AEC Mobile)、自动增益(AGC)、降噪(NS)、静音检测(VAD)处理等功能，用来提升声音质量。 丢包补偿原理是什么？ 自动增益（AGC：Automatic Gain Control）概念？TCP协议 ：属于传输层，是可靠的、面向连接的。 主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。 TCP连接的建立依靠“三次握手”，而释放则需要“四次握手”。 IP协议 ：属于网络层，主要解决 网络路由和寻址 问题。 Http协议 ：属于应用层协议，一个简单的请求-响应协议，是一种无状态、非持久的协议，是被动性的，也就是只能客户端发起。 服务端不保留上一次与客户端交互时的任何状态，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。 HTTP的长连接和短连接本质上是TCP长连接和短连接。 HTTP1.1支持keep-alive。 Http与WebSocket区别与联系 （1）Http与WebSocket是两个完全不同的协议，都是基于TCP的。 两者唯一的联系是WebSocket利用Http进行握手；具体说明请看：RFC6455-1.7()（2）WS默认也使用80端口；WSS默认也使用443端口。 （3）Http协议局限性一大堆，比如明文传输、无法保证信息完整性、没有身份验证等。 而WebSocket的出现则是为了解决Http协议只能由Client发起通信请求的问题。 WebSocket是 全双工通信 。 （4）HTTP是运行在TCP协议传输层上的应用协议，而WebSocket是通过HTTP协议协商如何连接，然后独立运行在TCP协议传输层上的应用协议。 WebSocket仅仅是利用了HTTP协议做连接请求。 WebSocket相当于一个简化版的TCP传输子层（实际上WebSocket也是应用层协议）。 WebSocket之所以能持久连接原因是它运行在TCP协议上，TCP协议自身是长连接协议，所以WebSocket当然可以长连接啦。 如果你要问为什么HTTP不是长连接，原因是早期的HTTP在发起每个请求，响应完成后就会关闭Socket。 但是后来加了多路复用KeepAlive协议后HTTP协议已经可以实现长连接了，可以处理长连接事务了。 至于添加WebSocket特性，是为了更好、更灵活，轻量的与服务器通讯。 因为WebSocket提供了简单的消息规范，可以更快的适应长连接的环境，其实现在HTTP协议自身就可以做，但是不太轻便，因为HTTP是一种无状态、非持久的协议，是被动性的，也就是只能客户端发起。 服务端不保留上一次与客户端交互时的任何状态，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁，每次请求和应答都带有完整的Http头，占用网络传输带宽，增加了每次传输的数据量。 为什么HTML4不支持WebSocket？原因是WebSocket的协商机制HTML4底层API没有实现。 WebSocket与Socket是没什么关系的 WebSocket协议 和 Http协议： 都是基于TCP的，所以他们都是可靠的协议，是在应用层。 Socket： 是对TCP/IP 协议的封装，本质并不是一个协议，是应用层与 TCP/IP 协议族通信的中间软件抽象层（类似于对底层的封装），它是一组接口，让你在使用的时候更方便操作。 WebSocket与WebRTC(Web Real-Time Communication)是什么关系？WebSocket： 是WebRTC的基础，为WebRTC负责客服端发现和数据转发。 TCP协议 ：参考SocketRocket ：Facebook的开源框架WebRTC开发和VoIP开发之间有什么区别与联系？ 待完善知识点：WebRTC移动端兼容性检测，如何配置MediaStreamConstraints， 信令(iceCandidate, sessionDescription)传输方式的选择，iceCandidate和sessionDescription设置的先后顺序，STUN和TURN的概念，如何实现截图及录制视频及上传图片和视频功能，如何高效跟踪错误？WebRTC拥塞控制和码率调节策略是怎么样的？在弱网环境下如何保证图像不失真？猜：好像是改RTCRtpEncodingParameters这个类里的ssrc参数。 是改采样频率？ 参考资料：WebRTC百科：WebRTC基础知识：GoogleWebRTC-pod安装文档： https:// /pods/GoogleWebRTC GoogleWebRTC-iOS官网：

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！