概念

HTTP/3 重磅来袭

一.现状:

HTTP/3 的基础即谷歌多年探索的基于 UDP 的 QUIC 协议。与 TCP 相比,使用 UDP 可以提供更大的灵活性,并且可以使 QUIC 完全于用户空间中实现——对协议实现的更新不像 TCP 那样需要绑定到操作系统更新。使用 QUIC,可以简单地将 HTTP 级别的流映射到 QUIC 流的顶部,从而继承 HTTP/2 的所有优点,而不会产生队头阻塞。HTTP/3 虽仍处于草案状态,但很多用户已经跃跃欲试。

二.优势

HTTP/3 利用 QUIC 加速 HTTP 请求,QUIC 提供比 TCP 和 TLS 更高的加密和性能
QUIC 是一种默认加密的新传输协议,旨在加快 HTTP

HTTP/3 发布!

6 月 6 日,IETF QUIC(Internet Engineering Task Force,互联网工程任务组,简称 IETF)、比利时的 HTTP 工作组成员 Robin Mark 在 Twitter 上宣布“历时 5 年,HTTP/3 终于被标准化为 RFC 9114。将与 RFC 9204(QPACK header 压缩)和 RFC 9218 (可扩展的优先级)一起开启 Web 的新篇章!”,这意味着该协议已经进入了稳定的状态,而 HTTP/3 是 HTTP 超文本传输协议的第三个主要版本。…

WebTransport 与 WebCodecs 初探

什么是WebTransport?

WebTransport 是WebRTC体系下的一套浏览器API,提供低延迟,client和server之间双向通信的能力。 核心的能力点包括:

  • WebTransport 提供基于QUIC 和 HTTP3实现的API, 自动获得QUIC和HTTP3本身的特性,比如应用层的拥塞,避免队头阻塞。
  • 双向通信的能力,多个传输通道复用一个连接的能力,能够很好的替代WebSocket。
  • 提供发送/接受不可靠UDP的能力,这个是浏览器一直欠缺的能力,

相关的规范如下:

  • WebTransport overview 这个规范介绍了WebTransport整体的情况,
  • WebTransport over QUIC 这个规范介绍WebTransport over QUIC的实现规范, 目前版本(M89)的WebTransport实现是基于QUIC的。
  • WebTransport over HTTP/3 这个规范介绍WebTransport over HTTP/3的实现规范,目前版本(M89)还没有实现这这部分。 按照官方的说法是,WebTransport 最终会完全基于HTTP/3 实现,并移除基于QUIC的实现,这个还需要进一步关注。

在浏览器中可以通过URL 来实例化一个WebTransport 实例,比如:

const url = quic-
            

网站升级为https后引用http报错:This request has been blocked; the content must be served over HTTPS

HTTPS 是 HTTP over Secure Socket Layer,以安全为目标的 HTTP 通道,所以在 HTTPS 承载的页面上不允许出现 http 请求,一旦出现就是提示或报错:

Mixed Content: The page at ‘https://www.taobao.com/‘ was loaded over HTTPS, but requested an insecure image ‘http://g.alicdn.com/s.gif’. This content should also be served over HTTPS.

HTTPS改造之后,我们可以在很多页面中看到如下警报:

很多运营对 https

史上最全的WebRTC服务器技术选型分析

在上一篇文章里我们介绍了我们介绍了MCU和SFU的优缺点,webRTC通信方案SFU和MCU的区别?

下面就来探讨下常见的SFU开源解决方案,当然,你也可以自己实现 SFU 流媒体服务器,但自已实现流媒体服务器困难还是蛮多的,它里面至少要涉及到 DTLS 协议、ICE 协议、SRTP/SRTCP 协议等,光理解这些协议就要花不少的时间,更何况要实现它了。…

        

webRTC通信方案SFU和MCU的区别

想学更多的WebRTC知识,请关注WebRTC中文社区

常见的多方通信架构方案

Webrtc一对一的通信,通常采用的是端到端的方式,那如果多人通信的架构方案一般有这三种常见的方案

Mesh方案

即多个终端之间两两进行连接,形成一个网状结构。比如 A、B、C 三个终端进行多对多通信,当 A 想要共享媒体(比如音频、视频)时,它需要分别向 B 和 C 发送数据。同样的道理,B 想要共享媒体,就需要分别向 A、C 发送数据,依次类推。这种方案对各终端的带宽要求比较高。
avatar
当某个浏览器想要共享它的音视频流时,它会将共享的媒体流分别发送给其他 3 个浏览器,这样就实现了多人通信。这种结构的优势有如下:

  • 不需要服务器中转数据,STUN/TUTN 只是负责 NAT 穿越,这样利用现有 WebRTC 通信模型就可以实现,而不需要开发媒体服务器。
  • 充分利用了客户端的带宽资源。
  • 节省了服务器资源,由于服务器带宽往往是专线,价格昂贵,这种方案可以很好地控制成本。

劣势:

  • 共享端共享媒体流的时候,需要给每一个参与人都转发一份媒体流,这样对上行带宽的占用很大。参与人越多,占用的带宽就越大。除此之外,对 CPU、Memory 等资源也是极大的考验。一般来说,客户端的机器资源、带宽资源往往是有限的,资源占用和参与人数是线性相关的。这样导致多人通信的规模非常有限,通过实践来看,这种方案在超过 4 个人时,就会有非常大的问题。
  • 另一方面,在多人通信时,如果有部分人不能实现 NAT 穿越,但还想让这些人与其他人互通,就显得很麻烦,需要做出更多的可靠性设计。
    

多人实时互动之各WebRTC流媒体服务器比较

前言

随着网络基础设施的提高,音视频实时通信越来越成为人们日常生活和工作中必不可少的需求。2011年 WebRTC的出现,则更加速了这种需求变为现实的可能性。

熟悉 WebRTC 的同学应该都知道,WebRTC规范只定义了实时通信中客户端的行为,而没有规范服务端(包括哪些信令、数据如何流转)的行为。所以,你可以使用WebRTC库方便的实现 1:1 实时通信,但对于多人实时互动,光依靠 WebRTC库显然就无法完成要求了。…