概念

网站升级为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库显然就无法完成要求了。…

        

计算机网络:OSI、TCP、UDP、IP、HTTP/HTTPS知识总结

计算机网络:OSI、TCP、UDP、IP、HTTP/HTTPS知识总结
播报文章

技术那点事

发布时间: 2019-07-03 08:31
关注

OSI,TCP/IP,五层协议的体系结构

每一层的作用:

物理层:通过媒介传输比特,确定机械及电气规范(比特Bit)数据链路层:将比特组装成帧和点到点的传递(帧Frame)网络层:负责数据包从源到宿的传递和网际互连(包Packet)传输层:提供端到端的可靠报文传递和错误恢复(段Segment)会话层:建立、管理和终止会话(会话协议数据单元SPDU)表示层:对数据进行翻译、加密和压缩(表示协议数据单元PPDU)应用层:允许访问OSI环境的手段(应用协议数据单元APDU)每一层的协议:

物理层:RJ45、CLOCK、IEEE802.3 (中继器,集线器,网关)数据链路:PPP、FR、HDLC、VLAN、MAC (网桥,交换机)网络层:IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 (路由器)传输层:TCP、UDP、SPX会话层:NFS、SQL、NETBIOS、RPC表示层:JPEG、MPEG、ASII应用层:FTP、DNS、Telnet、SMTP、HTTP、WWW、NFSTCP对应的应用层协议

FTP:定义了文件传输协议,使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件,上传主页,都要用到FTP服务。Telnet:它是一种用于远程登陆的端口,用户可以以自己的身份远程连接到计算机上,通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的,支持BBS的服务器将23端口打开,对外提供服务。SMTP:定义了简单邮件传送协议,现在很多邮件服务器都用的是这个协议,用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口,所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏,服务器开放的是25号端口。POP3:它是和SMTP对应,POP3用于接收邮件。通常情况下,POP3协议所用的是110端口。也是说,只要你有相应的使用POP3协议的程序(例如Fo-xmail或Outlook),就可以不以Web方式登陆进邮箱界面,直接用邮件程序就可以收到邮件(如是163邮箱就没有必要先进入网易网站,再进入自己的邮-箱来收信)。HTTP:从Web服务器传输超文本到本地浏览器的传送协议。UDP对应的应用层协议

DNS:用于域名解析服务,将域名地址转换为IP地址。DNS用的是53号端口。SNMP:简单网络管理协议,使用161号端口,是用来管理网络设备的。由于网络设备很多,无连接的服务就体现出其优势。TFTP(Trival File Transfer Protocal):简单文件传输协议,该协议在熟知端口69上使用UDP服务。

        

新姿势!Redis中调用Lua脚本以实现原子性操作

背景:有一服务提供者Leader,有多个消息订阅者Workers。Leader是一个排队程序,维护了一个用户队列,当某个资源空闲下来并被分配至队列中的用户时,Leader会向订阅者推送消息(消息带有唯一标识ID),订阅者在接收到消息后会进行特殊处理并再次推往前端。

问题:前端只需要接收到一条由Worker推送的消息即可,但是如果Workers不做消息重复推送判断的话,会导致前端收到多条消息推送,从而影响正常业务逻辑。…

    

Redlock(redis分布式锁)原理分析

Redlock:全名叫做 Redis Distributed Lock;即使用redis实现的分布式锁;

使用场景:多个服务间保证同一时刻同一时间段内同一用户只能有一个请求(防止关键业务出现并发攻击);

 

官网文档地址如下:https://redis.io/topics/distlock

这个锁的算法实现了多redis实例的情况,相对于单redis节点来说,优点在于 防止了 单节点故障造成整个服务停止运行的情况;并且在多节点中锁的设计,及多节点同时崩溃等各种意外情况有自己独特的设计方法;

 

此博客或者官方文档的相关概念:

1.TTL:Time To Live;只 redis key 的过期时间或有效生存时间

2.clock drift:时钟漂移;指两个电脑间时间流速基本相同的情况下,两个电脑(或两个进程间)时间的差值;如果电脑距离过远会造成时钟漂移值 过大

 

最低保证分布式锁的有效性及安全性的要求如下:

1.互斥;任何时刻只能有一个client获取锁

2.释放死锁;即使锁定资源的服务崩溃或者分区,仍然能释放锁

3.容错性;只要多数redis节点(一半以上)在使用,client就可以获取和释放锁

 

网上讲的基于故障转移实现的redis主从无法真正实现Redlock:

因为redis在进行主从复制时是异步完成的,比如在clientA获取锁后,主redis复制数据到从redis过程中崩溃了,导致没有复制到从redis中,然后从redis选举出一个升级为主redis,造成新的主redis没有clientA 设置的锁,这是clientB尝试获取锁,并且能够成功获取锁,导致互斥失效;

思考题:这个失败的原因是因为从redis立刻升级为主redis,如果能够过TTL时间再升级为主redis(延迟升级)后,或者立刻升级为主redis但是过TTL的时间后再执行获取锁的任务,就能成功产生互斥效果;是不是这样就能实现基于redis主从的Redlock;

 

redis单实例中实现分布式锁的正确方式(原子性非常重要):

1.设置锁时,使用set命令,因为其包含了setnx,expire的功能,起到了原子操作的效果,给key设置随机值,并且只有在key不存在时才设置成功返回True,并且设置key的过期时间(最好用毫秒)

SET key_name my_random_value NX PX 
        

关于队头阻塞(Head-of-Line blocking),看这一篇就足够了

(译)Robin Marx: QUIC 和 HTTP/3 队头阻塞的细节

作者:Robin Marx,原文:Head-of-Line Blocking in QUIC and HTTP/3: The DetailsGitHubrmarx/holblocking-blogpost

您可能已经听说,经过4年的工作,新的 HTTP/3 和 QUIC 协议终于接近正式标准化。预览版现在可以在服务器和浏览器中进行测试

与 HTTP/2 相比,HTTP/3 有很大的性能改进,这主要是因为它将底层传输协议从 TCP 改为基于 UDP 的 QUIC。在这篇文章中,我们将深入了解其中的一项改进,即消除…